Network Working Group Vikas Bhola INTERNET-DRAFT Gayatri Singla Hughes Software Systems Expires in 6 months 6th Dec,2002 Conformance Test Specification for IUA 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 . 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 UP/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 Mandatory 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 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 Vikas & Gayatri [Page 3] Internet Draft IUA Conformance Test Plan Dec 2002 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). 1.1 Terminology Interface - For the purposes of this document an interface supports the relevant ISDN signaling channel. This signaling channel MAY be a 16 kbps D channel for an ISDN BRA as well as 64 kbps primary or backup D channel for an ISDN PRA. For QSIG, the signaling channel is a Qc channel. Q.921-User - Any protocol normally using the services of the ISDN Q.921 (e.g., Q.931, QSIG, etc.). Backhaul - A SG terminates the lower layers of an SCN protocol and backhauls the upper layer(s) to MGC for call processing. For the purposes of this document the SG terminates Q.921 and backhauls Q.931 to MGC. Association - An association refers to a SCTP association. The association will provide the transport for the delivery of Q.921-User protocol data units and IUA adaptation layer peer messages. Stream - A stream refers to an SCTP stream; a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the un-ordered delivery service. Interface Identifier - The Interface Identifier identifies the physical interface at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP. Significance is not implied across SGs served by an AS. Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the Q.931 and call processing for D channels terminated by the Signaling Gateways. Practically speaking, an AS is modeled at Vikas & Gayatri [Page 4] Internet Draft IUA Conformance Test Plan Dec 2002 the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances. Fail-over - The capability to re-route signaling traffic as required between related ASPs in the event of failure or unavailability of the currently used ASP (e.g., from primary MGC to back-up MGC). Fail- over also applies upon the return to service of a previously unavailable process. Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the IUA layer and a local management entity. Network Byte Order - Most significant byte first, a.k.a Big Endian. Host - The computing platform that the ASP process is running on. 2. TEST SETUP ========== 2.1 Test Environment 2.1.1 Simulated Test Setup +-------+ | USER | | STUB | +-------+ | PCO| | +-------+ +-------+ | | | | | IUT |-----------------------|PEER | | | PCO |END | +-------+ +-------+ 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). Vikas & Gayatri [Page 5] Internet Draft IUA Conformance Test Plan Dec 2002 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. ASP1 and ASP2 can be in OVERRIDE or LOADSHARE mode of traffic handling. +--------------+ | AS IID X-Z | +-------------+ | ------- | | |-------------------------------|-| ASP1 | | | | | ------- | | SG | | ------- | | (IUT) | | | ASP2 | | | |-------------------------------|- ------- | +-------------+ +--------------+ Peer Fig 2: Configuration B Vikas & Gayatri [Page 6] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 Vikas & Gayatri [Page 7] Internet Draft IUA Conformance Test Plan Dec 2002 +-------------+ +--------------+ | | | 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. ASP1 and ASP2 can be in OVERRIDE or LOADSHARE mode of traffic handling. +--------------+ | AS IID X-Z | +-------------+ | ------- | | |-------------------------------|-| ASP1 | | | | | ------- | | SG | | ------- | | | | | ASP2 | | | |-------------------------------|- ------- | +-------------+ +--------------+ Peer IUT Fig 5: Configuration E 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. Vikas & Gayatri [Page 8] Internet Draft IUA Conformance Test Plan Dec 2002 +--------------+ | | | -------- | ----------| | 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. +-------------+ | | | | | SG1 |--------------- | | | +--------------+ | | | | AS1 IID X-Z | +-------------+ | | ------- | ---------------| | ASP1 | | ---------------| ------- | | +--------------+ | | +-------------+ | | | | | | | | SG2 |-------------- | | | | +-------------+ Fig 7: Configuration G Vikas & Gayatri [Page 9] Internet Draft IUA Conformance Test Plan Dec 2002 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. Verify that an M-ASP-UP confirm primitive is invoked by the ASP. c) Verify that the ASP state is moved to Inactive. d) Invoke an M-ASP-ACTIVE request from LM for ASP1. Verify that an ASPAC message is sent to the SG. 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 Active. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-UP----------> Request Vikas & Gayatri [Page 10] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------ASPUP--------------> <--------------ASPUP-ACK----------- <-------M-ASP-UP--------- confirm ASP state is now Inactive -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- <------M-ASP-ACTIVE----- Confirm ASP state is now 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 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP and SG. ASP is in 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. 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 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 Down. --------------------------------------------------------------- Vikas & Gayatri [Page 11] Internet Draft IUA Conformance Test Plan Dec 2002 Expected Message Sequence LM/SU ASP Peer(SG) ASP state is Active --------M-ASP-INACTIVE---> Request ----------------ASPIA-------------> <---------------ASPIA-ACK---------- <-------M-ASP-INACTIVE--- confirm ASP state is Inactive -------M-ASP-DOWN-----> Request ---------------ASP-DOWN-----------> <--------------ASP-DOWN-ACK------- <------M-ASP-DOWN----- Confirm ASP state is now Down -------------------------------------------------------------- --------------------------------------------------------------- 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 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 Inactive state. c) Invoke an M-ASP-UP request from LM for ASP2. An ASPUP message should be sent to the peer(SG). Vikas & Gayatri [Page 12] Internet Draft IUA Conformance Test Plan Dec 2002 d) Send an ASPUP ACK from peer to the ASP side. Verify that state of ASP2 is moved to Inactive. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) ASP state is Active --------M-ASP-UP-------> Request ----------------ASPUP-------------> <---------------ASPUP-ACK---------- <-------M-ASP-UP------- confirm ASP1 state is Inactive <-------NOTIFY (AS-Inactive)------- for AS1 <-------NOTIFY (AS-Inactive)------- for AS2 --------M-ASP-UP-------> Request ----------------ASPUP-------------> <---------------ASPUP-ACK---------- <-------M-ASP-UP------- confirm ASP2 state is 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 Inactive state. ---------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 13] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 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. 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 Active <-------NOTIFY (AS-Active)------- --------M-ASP-ACTIVE----> Request ----------------ASPAC-------------> <---------------ASPAC-ACK---------- <-------M-ASP-ACTIVE------- confirm Vikas & Gayatri [Page 14] Internet Draft IUA Conformance Test Plan Dec 2002 ASP2 state is 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 (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 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 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 Inactive. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-UP--------> Request (ASP1) ---------------ASPUP-------------> <--------------ASPUP-ACK--------- Vikas & Gayatri [Page 15] Internet Draft IUA Conformance Test Plan Dec 2002 <-------M-ASP-UP--------- confirm (ASP1) ASP1 state is now Inactive <----------NOTIFY (AS-Inactive)--- --------M-ASP-UP--------> Request (ASP2) ---------------ASPUP-------------> <--------------ASPUP-ACK---------- <-------M-ASP-UP--------- confirm (ASP2) ASP2 state is now Inactive -------------------------------------------------------------- --------------------------------------------------------------- 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 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 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. Vikas & Gayatri [Page 16] Internet Draft IUA Conformance Test Plan Dec 2002 f) Send an ASPAC ACK from peer to ASP2 in response. Verify that ASP2 is moved to Active state. g) Send a Notify(Alternate ASP Active) from peer to ASP1. ASP1 should be moved to 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) ---------------ASP ACTIVE-------------> <--------------ASP ACTIVE-ACK--------- <-------M-ASP-ACTIVE---- confirm (ASP1) ASP1 state is now 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 Active <-----NOTIFY (Alternate ASP Active)---- ASP1 state is now Inactive -------Unit Data Request-----------> <------Unit Data Indication--------- -------------------------------------------------------------- Vikas & Gayatri [Page 17] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 Inactive state. ASP2 is in 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. 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 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 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----- Vikas & Gayatri [Page 18] Internet Draft IUA Conformance Test Plan Dec 2002 Confirm (ASP1) ASP1 state is now 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 Active in AS2 <-----------NOTIFY (AS-Active)----- ------------Unit Data Request----> <-------Unit Data Indication----- -------------------------------------------------------------- --------------------------------------------------------------- 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 Active/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 Vikas & Gayatri [Page 19] Internet Draft IUA Conformance Test Plan Dec 2002 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 Active/Inactive state. --------------------------------------------------------------- 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". Vikas & Gayatri [Page 20] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer(SG). ASP1 is in 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 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) -------M-ASP-ACTIVE-----> Request --------ASPAC (smile and john)------> <-------------ASPAC-ACK ------------- <------M-ASP-ACTIVE----- Confirm AS1/ASP1 state is now Active <----------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 Vikas & Gayatri [Page 21] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 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 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. 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 Active in AS2 <--------NOTIFY(AS-Active)--------- -------M-ASP-ACTIVE-----> Request (ASP1) ------------ASPAC (IID 1)----------> <---------ASPAC-ACK (IID 1)-------- <------M-ASP-ACTIVE----- Confirm (ASP1) Vikas & Gayatri [Page 22] Internet Draft IUA Conformance Test Plan Dec 2002 ASP1 is now 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. ---------------------------------------------------------------- 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 Active state. --------------------------------------------------------------- Test Description : a) Send an ASPIA ACK message from peer to ASP1. Verify that ASP state is moved to Inactive. b) Send a ASPDN ACK message from peer to ASP1. Verify that ASP state is moved to 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 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 Active. --------------------------------------------------------------- Expected Message Sequence Vikas & Gayatri [Page 23] Internet Draft IUA Conformance Test Plan Dec 2002 LM/SU ASP Peer(SG) <-------------ASPIA-ACK------------ ASP state moved to Inactive <-------------ASPDN ACK------------ ASP state moved to Down --------M-ASP-UP----------> Request ---------------ASPUP--------------> <--------------ASPUP-ACK----------- <-------M-ASP-UP--------- confirm ASP state is now Inactive -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- <------M-ASP-ACTIVE----- Confirm ASP state is now 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 Active state. --------------------------------------------------------------- Test Description : a) Send a ASPDN ACK message from peer to ASP1. b) Verify that ASP state is moved to 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 Inactive. Vikas & Gayatri [Page 24] Internet Draft IUA Conformance Test Plan Dec 2002 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 Active. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) <-------------ASPDN ACK------------ ASP state moved to Down --------M-ASP-UP----------> Request ---------------ASPUP--------------> <--------------ASPUP-ACK----------- <-------M-ASP-UP--------- confirm ASP state is now Inactive -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- <------M-ASP-ACTIVE----- Confirm ASP state is now 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 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 Vikas & Gayatri [Page 25] Internet Draft IUA Conformance Test Plan Dec 2002 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 Down to Up. 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 Down state and a negative indication is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-UP-----> Request --------------ASPUP---------------> After Max retransmissions, ASP remains in Down state -------M-ASP-UP-----> Request <-------------------------------- ASP-UP ACK <-------------------------------- Notify (AS-INACTIVE) -------M-ASP-DOWN-----> Request --------------ASPDN---------------> After Max retransmissions, ASP is brought to 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 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in Inactive state. Vikas & Gayatri [Page 26] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 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 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 Inactive state and a negative indication is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> After Max retransmissions, ASP remains in Inactive state -------M-ASP-ACTIVE-----> Request <-------------------------------- ASP-ACTIVE ACK <-------------------------------- Notify (AS-ACTIVE) -------M-ASP-INACTIVE-----> Request --------------ASPIA---------------> After Max retransmissions, ASP brought to 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 are stopped if ASPIA ACK is received in Vikas & Gayatri [Page 27] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 Inactive state. Also verify that ASPAC retransmissions are stopped. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPIA-ACK------------ ASPAC retransmissions are stopped ASP state remains in Inactive --------------------------------------------------------------- --------------------------------------------------------------- 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 Active/Inactive state. --------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 28] Internet Draft IUA Conformance Test Plan Dec 2002 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 UP/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 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 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 Active. --------------------------------------------------------------- Expected Message Sequence Vikas & Gayatri [Page 29] Internet Draft IUA Conformance Test Plan Dec 2002 LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> ----------NOTIFY (AS-INACTIVE)-----> ASP and AS state moved to Inactive <---------------ASPAC------------- --------------ASPAC-ACK-----------> ----------NOTIFY (AS-ACTIVE)-----> ASP and AS state moved to 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 and AS is in active state. --------------------------------------------------------------- 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 INACTIVE and AS state is moved to 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 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 Down. --------------------------------------------------------------- Vikas & Gayatri [Page 30] Internet Draft IUA Conformance Test Plan Dec 2002 Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPIA-------------- ----------------ASPIA-ACK-----------> ------------NOTIFY(AS-PENDING)------> ASP state moves to Inactive AS state moves to Pending Pending timer Expires ------NOTIFY(AS-INACTIVE)----------> <--------------ASPDN--------------- -------------ASPDN-ACK------------ ASP and AS state moved to 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 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP and AS state is ACTIVE. --------------------------------------------------------------- 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 DOWN and AS state moves to Pending. c) Allow the pending timer to expire. Verify that after pending timer expiry, AS state moves to Down. d) Verify that SG does not send any Notify message to the peer. Vikas & Gayatri [Page 31] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPDN-------------- ----------------ASPDN-ACK-----------> ASP state moves to Down AS state moves to Pending Pending timer Expires ASP and AS state moves to 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 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 Inactive. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP-------------- ----------------ASPUP-ACK-----------> ----------NOTIFY (AS-Inactive)------> ----------NOTIFY (AS-Inactive)------> ASP1 is now Inactive in both AS1 and AS2 Vikas & Gayatri [Page 32] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- --------------------------------------------------------------- 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 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 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 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 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) Vikas & Gayatri [Page 33] Internet Draft IUA Conformance Test Plan Dec 2002 <----------------ASPAC-------------- ----------------ASPAC-ACK-----------> ----------NOTIFY (AS-Active)--------> AS1/ASP1 state is now Active <-------Unit Data Request--------- -------Unit Data Indication------> <----------------ASPAC-------------- ----------------ASPAC-ACK-----------> ----------NOTIFY (AS-Active)------> ASP1 is now 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 --------------------------------------------------------------- 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 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 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 Inactive. Vikas & Gayatri [Page 34] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 Inactive <---------------ASPUP----------- --------------ASPUP-ACK---------> ASP2 state is now 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 --------------------------------------------------------------- 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. --------------------------------------------------------------- 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 Active. c) Send an ASPAC message is sent 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 Active. e) Send a Unit Data Request Message from peer(ASP1) to SG. Verify that corresponding indication is given to NIF. Vikas & Gayatri [Page 35] Internet Draft IUA Conformance Test Plan Dec 2002 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 Active <-----------ASPAC (IID 16)---------- ----------ASPAC-ACK (IID 15-20)-----> ----------NOTIFY(AS-Active)---------> AS2/ASP2 state is now Active <------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 Down state. Vikas & Gayatri [Page 36] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 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 Inactive. Verify that state of ASP2 is now Inactive. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> -----------NOTIFY (AS-Inactive)----> AS1/ASP1 state is now Inactive <---------------ASPUP------------- ---------------ASPUP-ACK----------> ASP2 state is now 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 Inactive state. --------------------------------------------------------------- Vikas & Gayatri [Page 37] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 Active state. g) Also verify that SG sends a Notify(Alternate ASP Active) to peer(ASP1). Verify that ASP1 should be moved to Inactive state. AS1 should remain in 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 Active <-------Unit Data Request----------- --------Unit Data Indication--------> --------Unit Data Indication--------> <---------------ASPAC ------------- ------------ASPAC-ACK -------------> -------NOTIFY (Alt ASP Active)-----> for ASP1 ASP2 state is now Active Vikas & Gayatri [Page 38] Internet Draft IUA Conformance Test Plan Dec 2002 ASP1 state is now Inactive <-------Unit Data Request----------- --------Unit Data Indication--------> --------Unit Data Indication--------> --------------------------------------------------------------- --------------------------------------------------------------- 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 --------------------------------------------------------------- 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 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 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 Active <-------Unit Data Request----------- -------Unit Data Indication--------- Vikas & Gayatri [Page 39] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- --------------------------------------------------------------- 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. --------------------------------------------------------------- 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 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 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 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. Vikas & Gayatri [Page 40] Internet Draft IUA Conformance Test Plan Dec 2002 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 Active <----------ASPAC (IID 1)----------- ----------ASPAC-ACK (IID 1)--------> ---------NOTIFY (AS-Active)--------> ASP1 is now 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 Active state. Minimum two ASP's are required to handle traffic. --------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 41] Internet Draft IUA Conformance Test Plan Dec 2002 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)---> --------------------------------------------------------------- --------------------------------------------------------------- 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 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 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) Vikas & Gayatri [Page 42] Internet Draft IUA Conformance Test Plan Dec 2002 <-----------------ASPIA------------- ---------------ASPIA-ACK------------> ----Notify(Insufficient Resources)--> ASP1 state is Inactive -----Unit Data Indication (ASP2)---> -----Unit Data Indication (ASP2)---> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.14 ASPM_V_SG_14 : AS-Active again before pending timer expires --------------------------------------------------------------- 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 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 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 Pending and ASP state is moved to 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 Vikas & Gayatri [Page 43] Internet Draft IUA Conformance Test Plan Dec 2002 LM/NIF SG Peer(ASP) <---------------ASPIA-------------- --------------ASPIA-ACK------------> ------------NOTIFY (AS-Pending)----> AS state is pending and ASP state is Inactive Data Indication primitive invoked from NIF and Data buffered Before Pending timer expiry <------------------ASPAC----------- -----------------ASPAC-ACK---------> ----------NOTIFY(AS-Active)--------> ---------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 Active/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) Vikas & Gayatri [Page 44] Internet Draft IUA Conformance Test Plan Dec 2002 <--------------Heartbeat----------- --------------Heartbeat Ack--------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.16 ASPM_V_SG_16 : Mandatory parameter handling --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that IUA stack is able to handle an IUA message without any optional parameter. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.2, 3.3.2.5 --------------------------------------------------------------- Test Configuration :- A --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in Down state. --------------------------------------------------------------- Test Description : a) Send ASPUP message without 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 without the 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 Inactive <---------------ASPAC------------- --------------ASPAC-ACK-----------> ----------NOTIFY (AS-ACTIVE)-----> ASP and AS state moved to Active --------------------------------------------------------------- Vikas & Gayatri [Page 45] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 identifiers. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in 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 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 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)--------> Vikas & Gayatri [Page 46] Internet Draft IUA Conformance Test Plan Dec 2002 (for AS2) ASP1 is now 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 Inactive in both AS1 and AS2 --------------------------------------------------------------- 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 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 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. Vikas & Gayatri [Page 47] Internet Draft IUA Conformance Test Plan Dec 2002 f) Verify that the SG sends an ASPDN-ACK message to the peer. Verify that the ASP and AS states are moved to 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 Inactive <----------------ASPUP------------- ---------------ASPUP-ACK-----------> <----------------ASPDN------------- ---------------ASPDN-ACK-----------> ASP and AS state move to 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 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) Vikas & Gayatri [Page 48] Internet Draft IUA Conformance Test Plan Dec 2002 message to the peer. Verify that the ASP and AS states are moved to 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 Inactive. 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 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 Inactive <---------------ASPIA------------- --------------ASPIA-ACK-----------> --------------------------------------------------------------- Vikas & Gayatri [Page 49] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 ACTIVE state in both AS1 and AS2. --------------------------------------------------------------- Test Description : 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 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 DOWN state. --------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 50] Internet Draft IUA Conformance Test Plan Dec 2002 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)-----> --------------------------------------------------------------- --------------------------------------------------------------- 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 Inactive state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer without the mandatory Traffic Mode parameter. b) Verify that SG silently rejects the message and remains in Inactive state. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPAC------------- Message Rejected --------------------------------------------------------------- Vikas & Gayatri [Page 51] Internet Draft IUA Conformance Test Plan Dec 2002 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 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in 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 <-------------------- Vikas & Gayatri [Page 52] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 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 Vikas & Gayatri [Page 53] Internet Draft IUA Conformance Test Plan Dec 2002 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 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in 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 <-------------------- Vikas & Gayatri [Page 54] Internet Draft IUA Conformance Test Plan Dec 2002 <--------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 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in 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 <-------------------- Vikas & Gayatri [Page 55] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 ACTIVE state. ---------------------------------------------------------------- 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 --------------------> Vikas & Gayatri [Page 56] Internet Draft IUA Conformance Test Plan Dec 2002 -------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 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 ACTIVE state. ---------------------------------------------------------------- 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 Vikas & Gayatri [Page 57] Internet Draft IUA Conformance Test Plan Dec 2002 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 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in ACTIVE state. ---------------------------------------------------------------- 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 <-------------------- Vikas & Gayatri [Page 58] Internet Draft IUA Conformance Test Plan Dec 2002 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 --------------------------------------------------------------- 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 ACTIVE state. ---------------------------------------------------------------- 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--------------- Vikas & Gayatri [Page 59] Internet Draft IUA Conformance Test Plan Dec 2002 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 Active state. AS is in Loadshare mode. AS is having multiple interface identifiers say 1-5. --------------------------------------------------------------- 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) --------------------------------------------------------------- Vikas & Gayatri [Page 60] Internet Draft IUA Conformance Test Plan Dec 2002 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 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. 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---> Vikas & Gayatri [Page 61] Internet Draft IUA Conformance Test Plan Dec 2002 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 ACTIVE state. ---------------------------------------------------------------- Test Description : 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---------> Vikas & Gayatri [Page 62] Internet Draft IUA Conformance Test Plan Dec 2002 <-----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 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in 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. Vikas & Gayatri [Page 63] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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) --------------------------------------------------------------- --------------------------------------------------------------- 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 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 Vikas & Gayatri [Page 64] Internet Draft IUA Conformance Test Plan Dec 2002 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 -------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. --------------------------------------------------------------- Vikas & Gayatri [Page 65] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 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 --------------------------------------------------------------- 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 Inactive state. ---------------------------------------------------------------- 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. Vikas & Gayatri [Page 66] Internet Draft IUA Conformance Test Plan Dec 2002 Verify that ASP1 and AS1 states are moved to 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--------- ------------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 Down state. ---------------------------------------------------------------- Vikas & Gayatri [Page 67] Internet Draft IUA Conformance Test Plan Dec 2002 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 --------------------------------------------------------------- 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 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". Vikas & Gayatri [Page 68] Internet Draft IUA Conformance Test Plan Dec 2002 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 Inactive state. ---------------------------------------------------------------- Test Description : a) Send a Unitdata Request message from peer to SG. 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 Vikas & Gayatri [Page 69] 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 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 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 0)----------- -----------ERROR---------------------> (Invalid Stream Identifier) --------------------------------------------------------------- --------------------------------------------------------------- 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 Inactive state. ---------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 70] Internet Draft IUA Conformance Test Plan Dec 2002 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 Down state. ASP is locked out for management reasons. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG. b) Verify that SG sends an Error Message with reason as "Refused - Management Blocking". c) Verify that AS/ASP state is still 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 Vikas & Gayatri [Page 71] Internet Draft IUA Conformance Test Plan Dec 2002 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 Down state. --------------------------------------------------------------- Test Description : 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 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 Inactive. ASP ACTIVE PROCEDURES a) Invoke an M-ASP-ACTIVE request from LM for ASP1. b) An ASPAC message is sent to the SG. Vikas & Gayatri [Page 72] Internet Draft IUA Conformance Test Plan Dec 2002 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 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 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 Inactive --------M-ASP-UP--------> Request (ASP2) -------ASPUP--------> <------ASPUP-ACK----- <-------M-ASP-UP--------- confirm (ASP2) ASP2 state is now 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 Active -------M-ASP-ACTIVE-----> Request (ASP2) ----ASPAC (IID vikas)--> Vikas & Gayatri [Page 73] Internet Draft IUA Conformance Test Plan Dec 2002 <---ASPAC-ACK (IID vikas)-- <------M-ASP-ACTIVE----- Confirm (ASP2) ASP2 state is now 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 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 LM/NIF SG Peer(ASP) <----------ASPUP -------------------- -----------ERROR---------------------> (ASP Identifier Required) --------------------------------------------------------------- --------------------------------------------------------------- 3.4.2.2 ASPI_I_SG_02 : Invalid ASP Identifier --------------------------------------------------------------- Vikas & Gayatri [Page 74] 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 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 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 --------------------------------------------------------------- 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 Active state. --------------------------------------------------------------- Vikas & Gayatri [Page 75] Internet Draft IUA Conformance Test Plan Dec 2002 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 Down at SG side. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) ASP is in 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 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 Active state. --------------------------------------------------------------- Test Description : a) Kill the ASP side (IUA stack). 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 Down State. --------------------------------------------------------------- Expected Message Sequence Vikas & Gayatri [Page 76] Internet Draft IUA Conformance Test Plan Dec 2002 LM/NIF SG Peer(ASP) IUA(at SG) receives a CDI indication from SCTP ASP is brought to 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 --------------------------------------------------------------- --------------------------------------------------------------- 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 Vikas & Gayatri [Page 77] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 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 Active state via both the SG's. --------------------------------------------------------------- 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). Vikas & Gayatri [Page 78] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Expected Message Sequence LM/SU ASP SG1 SG2 <-------SCTP_COMM_LOST------- (with SG1) -----------Unit Data Request-------> --------------------------------------------------------------- 4. Acknowledgements The author would like to thank 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-01.txt. Morneault K. 6. Authors' Address Vikas Bhola Gayatri Singla Hughes Software Systems Electronic City, Plot 31, Sector 18 , Gurgaon 122015 Haryana, India Vikas & Gayatri [Page 79] Internet Draft IUA Conformance Test Plan Dec 2002 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.