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