Internet DRAFT - draft-hss-conformance-test-sctp
draft-hss-conformance-test-sctp
INTERNET-DRAFT Sunil Mahajan
Ashok K. Singh
Kuldeep Kumar
Sandeep Mahajan
Hughes Software Systems
Feb 08,2001
expires: SEP 08, 2001
Conformance Test Specification for SCTP
<draft-hss-conformance-test-sctp-00.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.
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.
Sunil, Sandeep,Kuleep,Ashok Hughes Software Systems [Page 1]
Internet Draft Conformance Test For SCTP Feb 2001
Abstract
This document presents the conformance test specification for SCTP
prototcol (RFC2960), which can be used to test SCTP implementations for
conformance to the protocol definition. The list of test is exhaustive
and covers almost all the categories of test, except few test for timer
calculation and congestion) which will be added in the next revision of
the draft.
This draft can also be used in conjunction with SCTP specification by
implementor of protocol as implementors guide, as the pictorial
representation of various scenarios help understand the protocol.
Next revision of the draft will also cover the additions done to the
protocol revision RFC2960 and any subsequent RFC published by IETF.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 2]
Internet Draft Conformance Test For SCTP Feb 2001
TABLE OF CONTENTS
1. INTRODUCTION ----------------------------------------------3
1.1 Purpose ------------------------------------------------- 3
1.2 Scope ------------------------------------------------- 3
1.3 Intended Audience ---------------------------------------- 3
1.4 Document Organization ----------------------------------- 4
1.5 Terms Used ---------------------------------------------- 4
2 GENERAL PRINCIPLES OF SCTP TESTS ------------------------- 6
2.1 Presentation of test descriptions ----------------------- 6
2.2 Presentation of the test list ------------------------ 6
2.3 Pre-Test Condition --------------------------------------- 6
2.4 Post Test Condition -------------------------------------- 6
2.5 Consideration ------------------------------------------ 6
3 TEST CONFIGURATION --------------------------------------- 7
4 TEST ENVIRONMENT ---------------------------------------- 7
4.1 SCTP validation testing ---------------------------------- 7
4.2 SCTP user simulator -------------------------------------- 7
4.3 Test simulator ------------------------------------------- 7
4.4 Link Monitor -------------------------------------------- 8
5 Test List ------------------------------------------------ 8
6 Test Description -----------------------------------------12
7 Acknowledgement -----------------------------------------156
8 Authors Address -----------------------------------------156
9 References ----------------------------------------------156
1. Introduction
1.1 Purpose
This document forms the basis of the testing of the SCTP(Stream Control
Transmission Protocol). It is the reference document for ensuring
that the implementation has met the desired requirements and is
conforming to the Protocol.
1.2 Scope
The scope of this document is limited to listing the Test Specification
for the Stream Control Transmission Protocol.
1.3 Intended Audience
This document is intended to be used by implementers and testing person
to verify the conformance of implementation to RFC 2960. Efforts have
been to make the test cases, explicitly clear and self explanatory. The
flow of messages have been explained with focus on -ve test case to
very the implementation to maximum possible extent .
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 3]
Internet Draft Conformance Test For SCTP Feb 2001
1.4 Document Organization
This document is organized as follows:
Chapter 1 Introduction: This chapter gives the overall scope of this
document and the document organization.
Chapter 2 General Principles of SCTP Tests:This chapter gives present-
ation of the tests and pre-test and post-test conditions for the tests.
Chapter 3 Test configuration: This chapter gives configuration for
testing the Stream Control Transmission Protocol.
Chapter 4 Test Environment: This chapter gives detail about various
tools required for testing the Stream Control Transmission Protocol.
Chapter 5 Test lists : This chapter gives details about the listing of
all the test cases which are covered in detail in chapter 6.
Chapter 6 Test Description : All the tests , listed in chapter 5 , are
discribed in detail . Standard tamplate has been across the chapter,
giving all the details e.g. cross reference to RFC 2960 , test setup
reference , objective etc.
1.5 Terms Used
The following terms are used in this document:
SCTP: Stream Control Transmission Protocol.
SCTP User: The logical upper-layer application entity, which uses
the services of SCTP also called the ULP.
SCTP Datagram: The unit of data delivery across the interface between
SCTP and the underlying Transport Layer (e.g. UDP or IP).
SCTP Host: A physical unit within which SCTP is running.
Transport Address: An address which serves as a source or destination
for the unreliable packet transport service used by SCTP. In IP
networks, a transport address is defined by the combination of an IP
address and an SCTP port number.
SCTP endpoint: The logical sender/receiver of SCTP datagrams. On a
multi-homed host, an SCTP endpoint is represented to its peers as a
combination of a set of eligible destination transport addresses to
which SCTP datagrams can be sent and a set of eligible source transport
addresses from which SCTP datagrams can be received.
Protocol: This refers to the SCTP Stack entity.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 4]
Internet Draft Conformance Test For SCTP Feb 2001
SCTP Association: Representation of an on going logical communication
channel between two SCTP end points on two SCTP Hosts. It is a protocol
relationship between SCTP endpoints, comprising the two SCTP endpoints
and protocol state information.
Chunk: A unit of information within an SCTP datagram, consisting of a
chunk header and chunk-specific content.
Transmission Sequence Number (TSN): A TSN is a 32-bit sequence number
which is assigned to each chunk containing user data to permit the
receiving SCTP endpoint to acknowledge its receipt and detect duplicate
deliveries. In case a datagram is lost, TSN number is used to detect
which datagram has not been acknowledged and hence is retransmitted.
Stream: A uni-directional logical channel established from one to
another associated SCTP endpoints, within which all user messages are
delivered in sequence except for those submitted to the un-ordered
delivery service.
Stream Sequence Number: A 16-bit sequence number used internally by
SCTP to assure sequenced delivery of the user messages within a given
stream. One stream sequence number is attached to each user message.
Bundling: This is an optional multiplexing operation provided to the
SCTP user, whereby more than one user datagram may be carried in the
same SCTP datagram.
Segmentation: This is another multiplexing operation done by the SCTP,
whereby a user datagram of size more than the path MTU size is
segmented into more than one datagrams at the sending end and
de - segmented (reassembled) at the receiving end transparently.
Transmission Control Block (TCB): An internal data structure created by
an SCTP host for each of its existing SCTP associations to maintain and
manage the association.
Receiver Window: This indicates, in number of octets, the available
buffer space for incoming packets at the receiver's inbound buffer.
Congestion Window: An SCTP variable that limits the data, in number of
octets, a sender can send into the network before receiving an
acknowledgement on a particular destination transport address.
SCTP Stack Entity: The SCTP software to be built according to this
functional specifications.
System Management: A management entity that does not use the SCTP
services for transport but performs functions such as initialization
of the stack or handling of error conditions to name a few.
ULP: The Upper Layer Protocol which is the service user of SCTP. ULP
will denote the local ULP unless otherwise specified.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 5]
Internet Draft Conformance Test For SCTP Feb 2001
2 General principles of SCTP tests
These tests aim to verify a given implementation of a protocol in
accordance with the relevant Recommendation. The specification is
independent of a given implementation and does not generally imply any
modification of the endpoint under test. However, it is recognized that
certain tests require capabilities of the system that are not
explicitly defined in the Recommendation, and these capabilities may
not be present in all implementations. As a consequence, certain tests
may not be possible in all implementations. Therefore, for testing
individual Administrations may unilaterally choose the tests to be
performed.
2.1 Presentation of test descriptions
The SCTP tests aim at testing the SCTP protocol conformance in a given
implementation. Although datagrams are transmitted and received
continuously, only the datagram which cause and/or indicate the changes
of endpoint status are shown in the EXPECTED MESSAGE SEQUENCE column of
each test description.
2.2 Presentation of the test list
These tests as a whole, aim at a complete validation of the SCTP
protocol without redundancies. Each test is described as simply as
possible to check precisely each elementary function of the protocol,
which is referred in the columns "reference", "title" and "sub-title"
of each test description.
This list is presented in the form of a succession of tests. The
presentation order is essentially functional. However, the operator
performing these tests may change this order, taking into account some
other practical criteria such as: use pre-test conditions to order the
list, the end of a given test may be the pre-test condition of another
test.
2.3 Pre-Test Condition
Before starting the test we need to get the setup into a condition from
where test can be started. These conditions are specified in Pre-Test
condition.
2.4 Post Test Condition
After executing each test the association should be closed by sending
ABORT from either end.
2.5 CONSIDERATIONS
The test plan covers the functional test to cover all the clause and
sub clause of IETF Draft for SCTP Ver13 with exceptions as listed below
A) Clause 6.3 : Management of Retransmission Timer
B) Clause 7.2 : SCTP Slow -Start and Congestion Avoidance.
C) Clause 7.3 : Path MTU discovery
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 6]
Internet Draft Conformance Test For SCTP Feb 2001
3 Test configuration
Figure 1 shows test configuration involving endpoint A and endpoint B.
Test specifications are written to test the SCTP protocol of endpoint B
____________ ____________
| | | |
|End point A |---------------------------|End point B |
|____________| User Test |____________|
Fig 1: TEST CONFIGURATION OF SCTP
4 Test Environment
________________
| |
|User Simulator |
|_______________|
|
|
______________ ______|________
| | | |
|Endpoint A |--------------------------------|End point B |
|Simulator | | | Under Test |
|_____________| | |_______________|
_____________
| |
|Link Monitor|
|____________|
( Fig 2 )
4.1 SCTP validation testing
The SCTP test environment consists of the following items(see Figure 2)
- The SCTP user simulator;
- The test simulator;
- The link monitor;
- The IP link.
4.2 SCTP user simulator
During the SCTP tests, it is necessary to inject messages and
indications to and from the SCTP endpoint under test. It is desirable
that the SCTP user function used is the actual SCTP user of the SCTP
with some additional functions for test purposes or a more controlled
user function. The application should also provide means to check the
interface interaction with the SCTP implementation under test.
4.3 Test simulator
During SCTP testing it is necessary to inject some abnormal messages
(as well as normal messages) to fully test the SCTP under test, the
test simulator should have this function. In addition, the simulator
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 7]
Internet Draft Conformance Test For SCTP Feb 2001
should have the capability to receive and check messages from the SCTP
under test. The generation of certain abnormal sequences of messages
should also be a capability of the test simulator.
4.4 Link Monitor
During SCTP testing it is necessary to monitor the various messages
being exchanged between the two SCTP endpoints. Link monitor should
have this function. It should also have the capability to show all the
parameters of the message. Test Simulator may be having this
functionality.
5 TEST List
1 Association Setup
1.1 Normal Association
1.2 T1-Init Timer
1.2.1 TI_Init timer for INIT
1.2.2 T1-Cookie timer for COOKIE
1.3 MAX.INIT.RETRANS
1.3.1 MAX.INIT.RETRANS: Failure to receive INIT-ACK
1.3.2 MAX.INIT.RETRANS: Failure to receive COOKIE-ACK
1.4 Failure to receive COOKIE-ECHO Message
1.5 Association Re-establishment (different init-tag)
1.5.1 Different Tag Values in different association being
Initiated from endpoint being tested
1.5.2 Different Tag Values in different association being
initiated from other endpoint
1.6 Optional Parameters
1.6.1 Optional parameters in the INIT message
1.6.2 Optional parameters in the INIT-ACK message
1.7 Stream Parameters Mismatch
1.7.1 Mismatch in the Outbound Stream and Inbound
Stream parameters in NIT
1.7.2 Outbound Stream and Inbound Stream parameters
set to zero in INIT
1.7.3 Mismatch in the Outbound Stream and Inbound Stream
parameters in NIT-ACK
1.7.4 Outbound Stream and Inbound Stream parameters equal
to zero in INIT-ACK
1.8 Unrecognized Parameters parameter in INIT-ACK
1.9 IP address in multiple association
1.10 No Transport Addresses
1.10.1 No Transport addresses in INIT messages
1.10.2 Host Name Address in INIT messages
1.10.3 No Transport addresses in INIT-ACK messages
1.10.4 Host Name Address in INIT-ACK
1.11 Transport addresses
1.11.1 One or more Transport addresses in INIT message
1.11.2 One or more Transport addresses in INIT-ACK messages
1.12 Host Name Address Parameter
1.12.1 Unresolvable Host Name Address in INIT messages
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 8]
Internet Draft Conformance Test For SCTP Feb 2001
1.12.2 Unresolvable Host Name Address in INIT-ACK
1.13 Supported Address Field
1.13.1 Supported Address field in INIT messages
1.13.2 Supported Address Type in INIT messages which the
receiver is incapable of using
1.14 Init-Tag equal to zero
1.14.1 Value of Init-tag equal to zero in INIT message
1.14.2 Value of Init-tag equal to zero in INIT-ACK message
2 Association Termination
2.1 Generation of ABORT
2.2 Termination of an association by receiving ABORT with
no error cause
2.3 Termination of an association by receiving Terminate
primitive from upper layers
2.4 T2-Shutdown timer expires for SHUTDOWN message
2.5 ASSOCIATION.MAX.RETRANS tries exceeds for SHUTDOWN
message
2.6 Receiving SHUTDOWN-ACK message in response to
SHUTDOWN message
2.7 Data From Upper Layers
2.7.1 Data from upper layer in Shutdown sent state
2.7.2 Data from upper layer in Shutdown receive state
2.7.3 Data from upper layer in Shutdown pending state
2.7.4 Data from upper layer in Shutdown-Ack sent state
2.8 Data from Peer in Shutdown sent state
2.9 Data Chunks are received in Shutdown Receive state
2.10 SHUTDOWN from peer in Shutdown receive state
2.11 T2-Shutdown timer expires for SHUTDOWN-ACK message
2.12 ASSOCIATION.MAX.RETRANS tries exceeds for
SHUTDOWN-ACK message
2.13 Receiving SHUTDOWN COMPLETE message in response to
SHUTDOWN-ACK message
3 Invalid Message Handling
3.1 Invalid INIT Message with message length < length of all
mandatory parameters
3.2 INIT-ACK Message with mandatory parameter missing
3.3 Invalid Verification Tag field in a message
3.4 Invalid Adler-32 Checksum in SCTP datagram
3.5 Invalid COOKIE-ECHO message with wrong MD5 signature
3.6 Invalid COOKIE-ECHO message with life time expired
3.7 Invalid ABORT message
3.8 Chunk length greater than packet length
3.9 Invalid SHUTDOWN-ACK message
3.10 Invalid SHUTDOWN COMPLETE message
4 Duplicate Message
4.1 INIT Collision
4.2 Duplicate INIT Message
4.2.1 Duplicate INIT Message in Established state
4.2.2 Duplicate INIT message in Shutdown-Ack sent state
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 9]
Internet Draft Conformance Test For SCTP Feb 2001
4.3 Duplicate INIT-ACK in COOKIE-ECHO Sent state
4.4 Duplicate COOKIE-ACK in established state
4.5 SHUTDOWN Collision
4.6 Duplicate Shutdown Message
4.6.1 Duplicate SHUTDOWN message in Cookie Wait state
4.6.2 Duplicate SHUTDOWN message in closed state
4.6.3 Duplicate SHUTDOWN message in Shutdown Receive state
4.6.4 Duplicate SHUTDOWN message in Shutdown Sent state
4.7 Duplicate SHUTDOWN-ACK
4.7.1 SHUTDOWN-ACK in Cookie_Wait state
4.7.2 SHUTDOWN-ACK in Established state
4.7.3 SHUTDOWN-ACK in SHUTDOWN-ACK Sent state
4.8 Duplicate COOKIE-ECHO Message
4.8.1 Duplicate COOKIE-ECHO Message with invalid MAC
4.8.2 Duplicate COOKIE-ECHO Message with valid MAC but
expired life time
4.8.3 Duplicate valid COOKIE-ECHO Message when Local and
Peer tags don't match the existing TCB but local and
peer tie tag matches the existing TCB
4.9 Duplicate SHUTDOWN COMPLETE message in Cookie Wait state
4.10 Duplicate valid COOKIE-ECHO Message in Shutdown Ack
sent state when Local and Peer tags don't match the
existing TCB but local and peer tie tag matches the
existing TCB
4.11 DATA packet in Shutdown-Ack Sent state
5 Fault Handling
5.1 Association.Max.Retrans Counter
5.1.1 Total number of consecutive retransmission exceeds
Association.Max.Retrans
5.1.2 The counter counting total number of retransmission
to an endpoint is reset on receiving a SACK.
5.2 Retrans.Count counter exceeds the Path.Max.Retrans
5.3 Retrans.Count counter is reset on receiving
HEARTBEAT-ACK or SACK.
5.4 Retrans.Count counter is not reset on receiving SACK
for an outstanding TSN, which was sent on an alternate
transport address
5.5 HEARTBEAT message is sent periodically to an idle
active station
5.6 Heartbeat Request primitive
5.7 HEARTBEAT message is responded with HEARBEAT-ACK
5.8 HEARTBEAT-ACK message comes from an inactive destination
5.9 OOTB datagram
5.9.1 OOTB DATA Packet
5.9.2 OOTB ABORT Packet
5.9.3 OOTB SHUTDOWN-ACK Packet
5.9.4 OOTB SHUTDOWN COMPLETE Packet
5.9.5 OOTB Packet from or to non-unicast address
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 10]
Internet Draft Conformance Test For SCTP Feb 2001
6 ERROR
6.1 ERROR message with cause Stale Cookie Error received in
Cookie Echoed State
6.2 ERROR message with cause Stale Cookie Error received in
state other than Cookie Echoed State
6.3 Generation of error cause Invalid Stream Identifier
6.4 Generation of error cause Missing Mandatory parameter
6.5 Generation of error cause Unrecognized Parameters
6.6 Reception of COOKIE-ECHO bundled with error cause
Unrecognized Parameters
7 Bundling of DATA chunks with Control Chunks
7.1 Chunk Multiplexing with INIT message
7.2 Chunk Multiplexing with INIT-ACK message
7.3 Chunk Multiplexing with SHUTDOWN COMPLETE Chunk
7.4 COOKIE-ECHO is received bundled with data chunks
with cookie as first chunk
7.5 COOKIE-ACK is received bundled with data chunks with
COOKIE-ECHO as first chunk
7.6 SHUTDOWN is received bundled with SACK
7.7 SACK is received bundled with DATA chunks
7.8 SHUTDOWN-ACK is received bundled with DATA
8 DATA
8.1 UN-SEGMENTED DATA
8.2 DATA SEGMENTATION
8.3 SEGMENTED DATA RECEPTION
8.4 CANCEL T3-rtx TIMER
8.5 T3-rtx TIMER EXPIRE
8.6 DUPLICATE DATA
8.7 BUFFER SPACE
8.8 USER DATA IN rwnd=0
8.9 CONGESTION
8.10 RETRANSMISSION
8.11 ORDERED DELIVERY
8.12 UN-ORDERED DELIVERY
8.13 Reception of SACK from Alternate address
8.14 DATA Chunk with no user data
8.15 SACK containing Cumulative TSN less than the
Cumulative TSN Ack point
8.16 TSN missing in SACK which was previously acknowledged
by SACK in Gap Ack block
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 11]
Internet Draft Conformance Test For SCTP Feb 2001
9 Acknowledgement
9.1 NORMAL ACKNOWLEDGE
9.2 DELAYED ACKNOWLEDGE
9.3 CUMULATIVE TSN ACK
10 Miscellaneous Test Case
10.1 CHUNK TYPE Encoding
10.2 Parameter Type Encoding
11 Retransmission Timer
11.1 RTO is incremented if T3-rxt expires for DATA chunk
(Single IP address)
11.2 RTO is incremented if T3-rxt expires for DATA chunk
(Multiple IP addresses)
11.3 When DATA is retransmitted to an alternate address
then RTO value corresponding to that address is used
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 12]
Internet Draft Conformance Test For SCTP Feb 2001
6 Test Description
1.1 Normal Association
TEST NUMBER : 1.1
Reference: SCTP RFC 2960 Clause 5.1 and 5.1.6
TITLE : Association Startup
SUBTITLE : Normal Association
PURPOSE : To check normal association procedure
PRE-TEST CONDITIONS: Association not established between endpoint A
and B. Also arrange the data in endpoint B such that upper layers send
Associate primitive to startup an association with endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<----- Associate
<---------------- INIT
INIT_ACK ----------------->
<----------------- COOKIE-ECHO
COOKIE_ACK ------------------>
Communication Up ---->
<---- Send
<------------------ DATA
SACK ------------------>
DATA ------------------> Data Arrive ----->
<------------------ SACK
TEST DESCRIPTION:
1. Start normal association procedure by sending associate primitive
from ULP in endpoint B.Record the message sequence using a signal
emulator.
2. Check A: Association is established.
3. Check B: First data chunk sent after establishing association is
immediately acknowledged by SACK.
4. Check C: Reception and transmission of various length data chunks on
the established association.
5. Check D: All the DATA messages are received correctly. (No loss of
messages.)
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 13]
Internet Draft Conformance Test For SCTP Feb 2001
1.2 T1-Init Timer
1.2.1 T1-Init timer for INIT
TEST NUMBER : 1.2.1
Reference: SCTP RFC 2960 Clause 5.1.6 and 4
(Note 2)
TITLE : Association Startup
SUBTITLE : T1-Init timer for INIT
PURPOSE: To check that if T1-Init timer expires then INIT message is
transmitted again.
PRE-TEST CONDITION: Association is not established between endpoint A
and B. Arrange the data in Endpoint A such that INIT-ACK is not sent
in response to INIT message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<----- Associate
Note Init-Tag value <---------------- INIT
Don't send Start T1-Init timer
INIT-ACK message |
|
| T1-INIT timer
| Expires
|
|
Note Init-Tag value <----------------- INIT
Restart T1-Init timer
TEST DESCRIPTION:
1. Try to make an association from endpoint B to endpoint A by sending
INIT message from endpoint B. Don't send INIT-ACK in response to
INIT message. Record the message sequence using a signal emulator.
2. Check A: INIT message is sent again after expiry of T1-Init timer.
3. Check B: In the retransmitted message, Init-Tag value is same as
was in the previous INIT message.
4. Check C: Was the message sequence as above
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 14]
Internet Draft Conformance Test For SCTP Feb 2001
1.2.2 T1-Cookie timer for COOKIE
TEST NUMBER : 1.2.2
Reference: SCTP RFC 2960 Clause 5.1.6 and 4
(Note 3)
TITLE : Association Startup
SUBTITLE : T1-Cookie timer for COOKIE-ECHO
PURPOSE: To check that if T1-Cookie timer expires then COOKIE-ECHO
message is transmitted again.
PRE-TEST CONDITION: Association is not established between endpoint
A and B. Arrange the data in Endpoint A such that COOKIE-ACK is not
sent in response to COOKIE-ECHO message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<----- Associate
<---------------- INIT
INIT-ACK ----------------->
<---------------- COOKIE-ECHO
Don't send Start T1-Init timer
COOKIE-ACK message |
|
| T1-Cookie timer expires |
|
|
<---------------- COOKIE-ECHO
Restart T1-Cookie
Timer
TEST DESCRIPTION:
1. Try to make an association from endpoint B to endpoint A by sending
INIT message from endpoint B.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO message is sent again after expiry of
T1-Cookie timer.
3. Check B: Was the message sequence as above
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 15]
Internet Draft Conformance Test For SCTP Feb 2001
1.3 MAX.INIT.RETRANS
1.3.1 MAX.INIT.RETRANS: Failure to receive INIT-ACK
TEST NUMBER : 1.3.1
Reference: SCTP RFC 2960 Clause 4 (Note 2)
and 5.1.6
TITLE : Association Startup
SUBTITLE : MAX.INIT.RETRANS: Failure to receive INIT-ACK
PURPOSE: To verify that if INIT is retransmitted for MAX.INIT.RETRANS
then the process to make the association is aborted.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange the data in Endpoint A such that INIT-ACK is not sent
in response to INIT message. Let MAX.INIT.RETRANS counter for
endpoint B is x.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <------ Associate
<------------ INIT
Don't Send INIT-ACK |
| T1-INIT timer
|
<------------ INIT
Don't Send INIT-ACK |
| T1-INIT timer
|
<------------ INIT
.Retransmit INIT
.x Times
MAX INT. RETRANS
Counter exceeds.
Communications Lost ------->
<------- Associate
<------------------ INIT
INIT-ACK ------------------>
<------------------ COOKIE-ECHO
COOKIE-ACK ------------------>
Communication Up ------->
------------------>
DATA ------------------>
<------------------ SACK
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 16]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to endpoint A by
sending INIT message from endpoint B.
Record the message sequence using a signal emulator.
2. Check A: If INIT message is transmitted for MAX.INIT.RETRANS times
without getting an INIT-ACK, Association is aborted and upper layers
are reported of this.
3. Check B: Can endpoint B start and establish a new association with
endpoint A. Check this by sending Associate primitive from ULP.
4. Check C: Was the message sequence as above.
1.3.2 MAX.INIT.RETRANS: Failure to receive COOKIE-ACK
TEST NUMBER : 1.3.2
Reference: SCTP RFC 2960 Clause 4 (Note 3) and 5.1.6
TITLE : Association Startup
SUBTITLE : MAX.INIT.RETRANS: Failure to receive COOKIE-ACK
PURPOSE: To verify that if COOKIE is retransmitted for MAX.INIT.RETRANS
then association is aborted.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in Endpoint A such that COOKIE-ACK is not sent
in response to COOKIE message. Let MAX.INIT.RETRANS counter for
endpoint B is x.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 17]
Internet Draft Conformance Test For SCTP Feb 2001
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<------ Associate
<------------------ INIT
INIT-ACK ------------------>
<------------------ COOKIE-ECHO
Don't Send COOKIE-ACK |
| T1-Cookie timer
|
<------------------ COOKIE -ECHO
Don't Send COOKIE-ACK |
| T1-Cookie timer
|
<------------------ COOKIE-ECHO
.
. Retransmit x
. times
MAX.INIT.RETRANS
Counter exceeds.
Communication Lost -------->
<--------- Associate
<------------------ INIT
INIT-ACK ------------------>
<------------------ COOKIE-ECHO
COOKIE-ACK ------------------> Communication Up --------->
DATA ------------------>
<------------------ SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to endpoint A by
Sending INIT message from endpoint B.
Record the message sequence using a signal emulator.
2. Check A: If COOKIE-ECHO message is transmitted for MAX.INIT.RETRANS
times without getting an COOKIE-ACK, Association is aborted and
upper layers are reported of this.
3. Check B: Can endpoint B start and establish a new association.
4. Check C: Was the message sequence as above.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 18]
Internet Draft Conformance Test For SCTP Feb 2001
1.4 Failure to receive COOKIE-ECHO Message
TEST NUMBER : 1.4
Reference: SCTP RFC 2960 Clause 5.1 B (Note)
TITLE : Association Startup
SUBTITLE : Failure to receive COOKIE-ECHO Message
PURPOSE: To verify that endpoint remains in closed state if COOKIE-ECHO
message is not received and resources are not allocated for that.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in Endpoint A, such that COOKIE-ECHO is not
sent in response to INIT-ACK message.Also let maximum no of association
which endpoint A can establish is n and n-1of them are already
established. It is necessary to check that resources are not allocated
after sending INIT-ACK messages.We are trying to make the nth
association.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ------------------>
<------------------ INIT_ACK (With Cookie)
Cookie message is
not received.
<--------- Associate
<------------------ INIT
INIT_ACK ------------------>
------------------> COOKIE-ECHO
COOKIE-ACK ------------------>
Communication Up --------->
DATA ------------------>
<------------------ SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B.
Don't send COOKIE-ECHO message in response to INIT-ACK.
Record the message sequence using a signal emulator.
2. Check A: Endpoint B remains in closed state.
3. Check B: Was the message sequence as above.
4. Check C: Can endpoint B start and establish a new association
With endpoint A.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 19]
Internet Draft Conformance Test For SCTP Feb 2001
1.5 Association Re-establishment (different init-tag)
1.5.1 Different Tag Values in different association being initiated
from endpoint being tested
TEST NUMBER : 1.5.1
Reference: SCTP RFC 2960 Clause 5.3.1
TITLE : Association
SUBTITLE: Different Tag Values in different association with same
endpoint.
PURPOSE: To verify that when an association is re-established to a peer
then a different (Different from the previous association between the
two endpoints) Init-Tag value is used.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange the data in endpoint A such that normal association
can be established and terminated between endpoint A and B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<------- Associate
Note Init-Tag Value <------------------ INIT
INIT_ACK ------------------>
<------------------ COOKIE-ECHO
COOKIE_ACK ------------------> Communication Up ------->
<------ Send
<------------------ DATA
SACK ------------------>
DATA ------------------> Data Arrive ----------->
<------------------- SACK
SHUTDOWN ------------------->
<------------------- SHUTDOWN ACK
Communication Lost----->
<----------- Associate
Note Init-Tag value <------------------- INIT
INIT-ACK ------------------->
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 20]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Try to initiate an association between endpoint A and B. Note the
values of Init-Tag parameters received in INIT messages.Terminate
the association by sending SHUTDOWN message and try to re-establish
the association. Again note the value of Init-Tag parameters in INIT
message.
2. Check A: Value of Init-Tag parameter in the new association is
different from the old one.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 21]
Internet Draft Conformance Test For SCTP Feb 2001
1.5.2 Different Tag Values in different association being initiated
from other endpoint
TEST NUMBER : 1.5.2
Reference: SCTP RFC 2960 Clause 5.3.1
TITLE : Association
SUBTITLE: Different Tag Values in different association with same
endpoint.
PURPOSE: To verify that when an association is re-established to a peer
then a different (Different from the previous association between the
two endpoints) Init-Tag value is used.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that normal association can
be established and terminated between endpoint A and B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ------------------>
Note Init-Tag Value <------------------ INIT-ACK
COOKIE-ECHO ------------------>
<------------------ COOKIE-ACK
Communication Up --------->
<---------------- Send
<------------------ DATA
SACK ------------------->
DATA -------------------> Data Arrive ---------->
<------------------ SACK
SHUTDOWN ------------------->
<------------------ SHUTDOWN ACK
Communication Lost ---------->
INIT ------------------->
<------------------- INIT-ACK
Note Init-Tag value
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 22]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Try to initiate an association between endpoint A and B. Note the
values of Init-Tag parameters received in INIT-ACK messages.
Terminate the association by sending SHUTDOWN message and try to
re-establish the association. Again note the value of Init-Tag
parameters in INIT-ACK message.
2. Check A: Value of Init-Tag parameter in the new association is
different from the old one.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 23]
Internet Draft Conformance Test For SCTP Feb 2001
1.6 Optional Parameters
1.6.1 Optional parameters in the INIT message
TEST NUMBER : 1.6.1
Reference: SCTP RFC 2960 Clause 3.3.2
TITLE : Association Startup
SUBTITLE: Optional parameters in the INIT message
PURPOSE: To verify that if there are one or more optional parameters in
the received INIT message then message is accepted and responded.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that all optional parameters
are sent in INIT message. Also endpoint B should be IPv6 enabled.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ------------------>
(All optional Parameters)
------------------> INIT_ACK
COOKIE-ECHO ------------------>
<------------------ COOKIE-ACK
Communication Up ----------->
DATA ------------------->
<------------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B. Send
INIT message containing all optional parameters (IPv4 address, IPv6
address, COOKIE-ECHO preservative, supported address type).
Record the message sequence using a signal emulator.
2. Check A: INIT message is accepted and INIT-ACK is sent.
3. Check B: Association is established between endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 24]
Internet Draft Conformance Test For SCTP Feb 2001
1.6.2 Optional parameters in the INIT-ACK message
TEST NUMBER : 1.6.2
Reference: SCTP RFC 2960 Clause 3.3.3
TITLE : Association Startup
SUBTITLE: Optional parameters in the INIT-ACK message
PURPOSE: To verify that if there are one or more optional parameters
in the received INIT-ACK message then message is accepted and responded
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that all optional parameters
are sent in INIT-ACK messages. Also endpoint B should be IPv6 enabled.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<--------- Associate
<---------------- INIT
INIT_ACK ----------------->
(With all optional Parameters)
<---------------- COOKIE-ECHO
COOKIE-ACK ---------------->
Communication Up --------->
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to endpoint A. Send
INIT-ACK message containing all optional parameters (IPv4 address,
IPv6 address, Unrecognized Parameters).
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK message is accepted and COOKIE-ECHO message is
sent.
3. Check B: Association is established between endpoint A and B.
4. Repeat the above test case if COOKIE is not the first parameter
after the mandatory parameter in the INIT-ACK message but is after
the optional parameter or in between the optional parameter.INIT-ACK
should be accepted in this case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 25]
Internet Draft Conformance Test For SCTP Feb 2001
1.7 Stream Parameters Mismatch
1.7.1 Mismatch in the Outbound Stream and Inbound Stream parameters
in INIT
TEST NUMBER : 1.7.1
Reference: SCTP RFC 2960 Clause 5.1.1
TITLE : Stream parameter mismatch
SUBTITLE: Mismatch in the Outbound Stream and Inbound Stream parameters
in INIT.
PURPOSE: To verify that if there is a mismatch in the Outbound Stream
and Inbound Stream parameters in INIT and INIT-ACK message then either
association is aborted or endpoint settle with minimum of the two
parameters.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Also let the OS of B is Z. Arrange data in endpoint A such that
INIT message is sent from endpoint A with MIS Y<Z.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ----------------> OS of B is Z > Y
(OS = X, MIS = Y)
Note value of OS <---------------- INIT_ACK (Note)
(OS = Y, MIS = X)
COOKIE-ECHO ---------------->
COOKIE-ACK
<---------------- Communication Up --------->
<---------- Send
(Stream id = Y)
Send Failure --------->
OS = Outbound Stream
MIS = Maximal Inbound Stream
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send INIT
message with Maximal Inbound stream parameter less than the Outbound
Stream of B.
Record the message sequence using a signal emulator.
2. Check A: Either the association is aborted or INIT-ACK is received
with Outbound stream parameter equal to the MIS received in INIT.
3. Check B: Range of OS Stream id in endpoint B and MIS stream id in
endpoint A is 0 to Y-1.
4. Check C: Was the message sequence as above.
Note: Association may be aborted in this case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 26]
Internet Draft Conformance Test For SCTP Feb 2001
1.7.2 Outbound Stream and Inbound Stream parameters set to zero in
INIT
TEST NUMBER : 1.7.2
Reference: SCTP RFC 2960 Clause 3.3.2
TITLE : Stream parameter mismatch
SUBTITLE: Outbound Stream and Inbound Stream parameters set to zero in
INIT
PURPOSE: To verify that if OS or MIS are found zero in the received
INIT message then ABORT message is sent for that INIT and endpoint
remains in the closed state.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange data in endpoint A such that INIT message with OS or
MIS equal to 0 is sent from endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) Closed)
INIT ---------------->
(OS = 0, MIS = Y)
<---------------- ABORT
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send INIT
message with OS equal to zero and MIS any value.
2. Check A: ABORT message is received at the endpoint A with cause
"Invalid Mandatory Parameter".
3. Repeat the above test case if value of MIS is zero and OS is having
any value in INIT message.
4. Repeat the above test case if value of MIS and OS are zero.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 27]
Internet Draft Conformance Test For SCTP Feb 2001
1.7.3 Mismatch in the Outbound Stream and Inbound Stream parameters
in INIT-ACK
TEST NUMBER : 1.7.3
Reference: SCTP RFC 2960 Clause 5.1.1
TITLE : Stream parameter mismatch
SUBTITLE: Mismatch in the Outbound Stream and Inbound Stream parameters
in INIT-ACK.
PURPOSE: To verify that if there is a mismatch in the Outbound Stream
and Inbound Stream parameters in INIT and INIT-ACK message then either
association is aborted or endpoint settle with minimum of the two
parameters.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Also let the OS of B is Z. Arrange data in endpoint A such
that INIT-ACK message is sent from endpoint A with MIS X<Z.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<------- Associate
<--------------- INIT
(OS = Z, MIS = Y)
INIT_ACK ---------------->
(OS = Y, MIS = X)
<---------------- COOKIE-ECHO (Note)
COOKIE-ACK ---------------->
Communication Up ------->
<------- Send
<---------------- DATA (Stream id = x-1)
SACK ---------------->
<-------- Send
(Stream id = x)
Send Failure -------->
OS = Outbound Stream
MIS = Maximal Inbound Stream
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 28]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint B to A. Send
INIT-ACK message with Maximal Inbound stream parameter less than
the Outbound Stream of B.
Record the message sequence using a signal emulator.
2. Check A: Either the association is aborted or COOKIE-ECHO is
received
3. Check B: Range of MIS Stream id in endpoint B is 0 to Y-1.
4. Check C: Was the message sequence as above.
Note: Association may be aborted in this case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 29]
Internet Draft Conformance Test For SCTP Feb 2001
1.7.4 Outbound Stream and Inbound Stream parameters equal to zero
in INIT-ACK
TEST NUMBER : 1.7.4
Reference: SCTP RFC 2960 Clause 3.3.3
TITLE : Stream parameter mismatch
SUBTITLE: Outbound Stream and Inbound Stream parameters equal to zero
in INIT-ACK
PURPOSE: To verify that if OS or MIS are found zero in the received
INIT-ACK message then ABORT message is sent for that INIT-ACK and
endpoint remains in the closed state.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Also let the OS of B is Z. Arrange data in endpoint A such
that INIT-ACK message is sent from endpoint A with OS or MIS equal
to zero.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<-------Associate
<---------------- INIT
(OS = Z, MIS = Y)
INIT_ACK ---------------->
(OS = 0, MIS = Z)
<---------------- ABORT
Communication Down ------->
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint B to A. Send INIT-
ACK message with OS equal to zero and MIS equal to Z.
2. Check A: ABORT message is received at the endpoint A.
3. Repeat the above test case if value of MIS is zero and OS is having
value Y. Response should be same.
4. Repeat the above test case if value of both MIS and OS is zero.
Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 30]
Internet Draft Conformance Test For SCTP Feb 2001
1.8 Unrecognized Parameters parameter in INIT-ACK
TEST NUMBER : 1.8
Reference: SCTP RFC 2960 Clause 3.3.3.1
TITLE : Association Startup
SUBTITLE: Unrecognized Parameters parameter in INIT-ACK.
PURPOSE: To verify that if unrecognized TLV parameters are received in
INIT message then they are filled in the Unrecognized Parameters
parameter of INIT-ACK.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that a datagram with
undefined parameter type and MSB two bits in the parameter type equal
to 11 is sent to endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
With undefined Parameter
Accept INIT message
Type optional parameters
Note Unrecognized <---------------- INIT_ACK
Parameters field (Unrecognised parameters
inunrecognised Parameters
field )
COOKIE-ECHO ---------------->
<---------------- COOKIE-ACK
Communication Up ------>
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B by sending
INIT message from A. In the INIT message, send some optional
parameters with undefined parameter type. The most significant two
bits in parameter type is 11.
Record the messages using a signal emulator.
2. Check A: INIT message is accepted and an INIT-ACK is sent.
3. Check B: In the INIT-ACK message, Unrecognised Parameters field is
filled with undefined parameter received in INIT.
4. Check C: Association is established between endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 31]
Internet Draft Conformance Test For SCTP Feb 2001
1.9 IP address in multiple association
TEST NUMBER : 1.9
Reference: SCTP RFC 2960 Clause 1.4
TITLE: Association Startup
SUBTITLE: IP address in multiple association
PURPOSE:To verify that if an INIT message comes for starting
association with a transport address which is already in association,
that INIT message is responded with ABORT message.
PRE-TEST CONDITION: Association is not established between endpoint
A and B. Arrange the data in endpoint A such that INIT message is sent
for making an association with endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
(IP address = x, y
Port = a)
<---------------- INIT-ACK
COOKIE-ECHO ---------------->
<---------------- COOKIE-ACK
Communication up ------>
INIT ---------------->
(IP address = x, z
Port = a)
<---------------- ABORT
DATA ---------------->
<--------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association between endpoint A and endpoint B by
sending INIT message from endpoint A. Endpoint B is already in
association with endpoint A with IP address x and y.
Record the message sequence using a signal emulator.
2. Check A: Association is not established and ABORT message is sent
3. Check B: Existing association between endpoint A and endpoint B
is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 32]
Internet Draft Conformance Test For SCTP Feb 2001
1.10 No Transport Addresses
1.10.1 No Transport addresses in INIT messages
TEST NUMBER : 1.10.1
Reference: SCTP RFC 2960 Clause 5.1.2 A
TITLE : Association Startup
SUBTITLE: No Transport addresses in INIT messages.
PURPOSE:To check the action of the system when INIT message is received
Containing no IP address.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange the data in endpoint A such that no IP addresses are
sent in INIT.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
(No IP Address)
<---------------- INIT_ACK
COOKIE-ECHO ---------------->
----------------> COOKIE-ACK
Communication Up -------->
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing no IP address.
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK is sent at the source IP address from which INIT
is received.
3. Check B: Other messages from endpoint B are sent at the source IP
address from which INIT is received
4. Check C: Association is established between endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 33]
Internet Draft Conformance Test For SCTP Feb 2001
1.10.2 Host Name Address in INIT messages.
TEST NUMBER : 1.10.2
Reference: SCTP RFC 2960 Clause 5.1.2 B
TITLE : Association Startup
SUBTITLE: Host Name address in INIT messages.
PURPOSE:To check the action of the system when INIT message is received
containing Host Name address with no other IP address.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Host Name address is
sent to Endpoint B with no other IP address in INIT message. Also Host
Name address sent by endpoint A is resolvable at Endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
(Host Name Address)
<----------------- INIT_ACK
COOKIE-ECHO ------------------>
<------------------ COOKIE-ACK
Communication Up ------->
DATA ------------------>
<------------------ SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing Host Name address with no other IP address
parameter.
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK is sent at one of the IP address resolved from
the Host Name address received in INIT message.
3. Check B: Other messages from endpoint B are sent at one of the IP
address resolved from the Host Name address received in INIT
message.
4. Check C: Association is established between endpoint A and B.
5. Repeat the above test case if other IP address such as IPv4 and IPv6
addresses is also present in the INIT message along with Host Name
address parameter. Receiver of INIT i.e. Endpoint B should ignore
IPv4 and IPv6 addresses if present along with Host Name address and
continue to establish association with the addresses obtained by
resolving Host Name address parameter.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 34]
Internet Draft Conformance Test For SCTP Feb 2001
1.10.3 No Transport addresses in INIT-ACK messages
TEST NUMBER : 1.10.3
Reference: SCTP RFC 2960 Clause 5.1.2 A
TITLE : Association Startup
SUBTITLE: No Transport addresses in INIT-ACK messages.
PURPOSE: To check the action of the system when INIT-ACK message is
received containing no IP address in the optional IP address field.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange the data in endpoint A such that no IP addresses are
sent in INIT-ACK optional IP address field.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<------- Associate
<----------------- INIT
INIT-ACK ----------------->
(No Optional IP Address)
<----------------- COOKIE-ECHO
COOKIE-ACK -----------------> Communication Up ----------->
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to A. Send INIT-ACK
message containing no IP address.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO is sent at the source IP address from which
INIT-ACK is received.
3. Check B: Other messages from endpoint B are sent at the source IP
address from which INIT-ACK is received.
4. Check C: Association is established between endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 35]
Internet Draft Conformance Test For SCTP Feb 2001
1.10.4 Host Name Address in INIT-ACK
TEST NUMBER : 1.10.4
Reference: SCTP RFC 2960 Clause 5.1.2 B
TITLE : Association Startup
SUBTITLE: Host Name Address in INIT-ACK message without any other IP
address.
PURPOSE: To check the action of the system when INIT-ACK message is
received containing Host Name Address with no other IP address.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B.Arrange the data in endpoint A such that Host Name Address with
no other IP address is sent in INIT-ACK message.Also Endpoint B is able
to resolve the Host Name Address sent by Endpoint A to a list of IP
addresses.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<--------- Associate
<----------------- INIT
INIT-ACK ----------------->
(Host Name Address)
<----------------- COOKIE-ECHO
COOKIE-ACK -----------------> Communication Up --------->
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to A. Send INIT-ACK
message containing Host Name Address with no other IP address.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO is sent at one of the IP address resolved from
the Host Name Address present in INIT-ACK.
3. Check B: Other messages from endpoint B are sent at the IP address
resolved from the Host Name Address present in INIT-ACK.
4. Check C: Association is established between endpoint A and B.
5. Repeat the above test case if other IP address such as IPv4 and IPv6
addresses is also present in the INIT-ACK message along with Host
Name address parameter. Receiver of INIT-ACK i.e. Endpoint B should
ignore IPv4 and IPv6 addresses if present along with Host Name
address and continue to establish association with the addresses
obtained by resolving Host Name address parameter.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 36]
Internet Draft Conformance Test For SCTP Feb 2001
1.11 Transport addresses
1.11.1 One or more Transport addresses in INIT message
TEST NUMBER : 1.11.1
Reference: SCTP RFC 2960 Clause 5.1.2 B
TITLE : Association Startup
SUBTITLE: One or more Transport addresses in INIT message.
PURPOSE:To verify that if there are one or more transport addresses are
received in INIT message then one of these IP address plus the IP
address from where INIT comes combined with the SCTP source port number
is used as the destination transport address.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B.Arrange the data in endpoint A such that one or more IP addresses
are sent in INIT message. Endpoint B is IPv6 capable
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ----------------->
(Transport Address = x, y, z
Port = a ) <---------------- INIT_ACK
COOKIE-ECHO ----------------->
<---------------- COOKIE-ACK
Communication Up ------>
DATA (IP = x Port = a) -------------------->
<---------------- SACK
DATA (IP = y Port = a) ----------------->
<----------------- SACK
DATA (IP = z Port = a) ----------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B. Send
INIT message containing one or more IPv4 addresses.
2. Check A: INIT message is accepted.
3. Check B: INIT-ACK is sent at the transport addresses from where INIT
message was received.
4. Check C: Other messages from endpoint B are sent at the IP addresses
received in INIT message.
5. Check D: Send DATA from each IP address in endpoint A. Check that
they are accepted and responded with SACK.
6. Repeat the above test case when one or more IPv6 addresses are
present.
7. Repeat the above test case when both IPv4 and IPv6 addresses are
present in INIT.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 37]
Internet Draft Conformance Test For SCTP Feb 2001
1.11.2 One or more Transport addresses in INIT-ACK messages
TEST NUMBER : 1.11.2
Reference: SCTP RFC 2960 Clause 5.1.2 B
TITLE : Association Startup
SUBTITLE: One or more Transport addresses in INIT-ACK messages.
PURPOSE:To verify that if there are one or more transport addresses are
received in INIT-ACK message then one of these IP address plus the
address from where the INIT-ACK comes combined with the SCTP source
port number is used as the destination transport address.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that one or more IP
addresses are sent in INIT-ACK messages.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<-------- Associate
<----------------- INIT
INIT-ACK ----------------->
(Transport Address = x, y, z
Port =a)
<---------------- COOKIE-ECHO
COOKIE-ACK ----------------->
Communication Up ---------->
DATA (IP = x Port = a) ----------------->
<----------------- SACK
DATA (IP = y Port = a) ------------------>
<------------------ SACK
DATA (IP = z Port = a) ------------------>
<------------------ SACK
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 38]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to endpoint A. Send
INIT-ACK Message containing one or more IPv4 addresses.
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK message is accepted.
3. Check B: COOKIE-ECHO is sent at one of the transport addresses
received in INIT-ACK plus the address from where INIT-ACK was
received.
4. Check C: Other messages from endpoint B are sent at the IP address
received in INIT-ACK message.
5. Check D: Send data from each of the IP address. Check that they are
accepted and responded with SACK.
6. Repeat the above test case when one or more IPv6 addresses are
present.
7. Repeat the above test case when both IPv4 and IPv6 addresses are
present in INIT-ACK.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 39]
Internet Draft Conformance Test For SCTP Feb 2001
1.12 Host Name Address Parameter
1.12.1 Unresolvable Host Name Address in INIT messages
TEST NUMBER : 1.12.1
Reference: SCTP RFC 2960 Clause 5.1.2 C
TITLE : Association Startup
SUBTITLE: Unresolvable Host Name address in INIT messages.
PURPOSE:To check the action of the system when INIT message is received
containing Unresolvable Host Name address with no other IP address.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Host Name address is
sent to Endpoint B with no other IP address in INIT message. Also Host
Name address sent by endpoint A is not resolvable at Endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ----------------->
(Host Name Address)
<----------------- ABORT (with error
Unresolvable Address)
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing Host Name address with no other IP address
parameter. Record the message sequence using a signal emulator.
2. Check A: ABORT is sent at the IP address from where INIT message is
received with error cause Unresolvable Address.
3. Repeat the above test case if other IP address such as Ipv4 and IPv6
addresses is also present in the INIT message along with Host Name
address parameter. Response will be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 40]
Internet Draft Conformance Test For SCTP Feb 2001
1.12.2 Unresolvable Host Name Address in INIT-ACK
TEST NUMBER : 1.12.2
Reference: SCTP RFC 2960 Clause 5.1.2 C
TITLE : Association Startup
SUBTITLE:Unresolvable Host Name Address in INIT-ACK message without any
other IP address.
PURPOSE: To check the action of the system when INIT-ACK message is
received containing Unresolvable Host Name Address with no other IP
address.
PRE-TEST CONDITIONS:Association is not established between endpoint A
and B.Arrange the data in endpoint A such that Host Name Address with
no other IP address is sent in INIT-ACK message.Also Endpoint B is not
able to resolve the Host Name Address sent by Endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<--------- Associate
<--------------- INIT
INIT-ACK --------------->
(Unresolvable Host Name Address)
<--------------- ABORT (with error
Unresolvable Address)
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to A. Send INIT-ACK
message containing Host Name Address with no other IP address.
Record the message sequence using a signal emulator.
2. Check A: ABORT is sent at the IP address from where INIT-ACK is
received.
3. Repeat the above test case if other IP address such as IPv4 and IPv6
addresses is also present in the INIT-ACK message along with Host
Name address parameter. Response will be same.
Note: After sending ABORT, Endpoint B may send INIT message again to
establish the association.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 41]
Internet Draft Conformance Test For SCTP Feb 2001
1.13 Supported Address Field
1.13.1 Supported Address field in INIT messages
TEST NUMBER : 1.13.1
Reference: SCTP RFC 2960 Clause 5.1.2 Note
TITLE : Association Startup
SUBTITLE: Supported address field in INIT messages.
PURPOSE:To check the action of the system when INIT message is received
containing Supported address field.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Supported Address field
is sent in INIT. Also the endpoint B is capable of using the address
type mentioned in Supported Address filed
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT --------------->
(With Supported Address Field)
<--------------- INIT_ACK
COOKIE-ECHO ---------------->
<---------------- COOKIE-ACK
Communication Up -------->
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing Supported Address field.
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK is sent with the address of the type contained in
the Supported address field in the received INIT.
3. Check B: Association is established between endpoint A and B.
4. Repeat the above test cases for the Supported address filed
containing only IPv4 Address type, only IPv6 Address type and both
address types.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 42]
Internet Draft Conformance Test For SCTP Feb 2001
1.13.2 Supported Address Type in INIT messages which the receiver is
incapable of using
TEST NUMBER : 1.13.2
Reference: SCTP RFC 2960 Clause 5.1.2 Note
TITLE : Association Startup
SUBTITLE: Supported Address Type in INIT messages which the receiver is
incapable of using
PURPOSE:To check the action of the system when INIT message is received
containing Supported Address Type which the receiver is incapable of
using.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Supported address type
field is sent to Endpoint B in INIT message. Also receiver i.e.endpoint
B is not capable of using supported address type.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
(Supported Address Type)
<----------------- INIT-ACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send INIT
message containing Supported Address type parameter. Record the
message sequence using a signal emulator.
2. Check A: INIT-ack is sent at one of the IP address contained in
INIT message.
3. Check B: the optional parameter in INIT-ACK is coded by copying the
parameter from the original INIT message i.e. variable filled up in
Supported Address Type of INIT.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 43]
Internet Draft Conformance Test For SCTP Feb 2001
1.14 Init-Tag equal to zero
1.14.1 Value of Init-tag equal to zero in INIT message
TEST NUMBER : 1.14.1
Reference: SCTP RFC 2960 Clause 3.3.2
TITLE : Association Startup
SUBTITLE: Value of Init-tag equal to zero in INIT message
PURPOSE:To check the action of the system when INIT message is received
containing Init-Tag equal to zero.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Init-tag field equal to
zero is sent to Endpoint B in INIT message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT --------------->
(Init_Tag = 0)
<--------------- ABORT
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B.Send INIT
message containing Init-Tag equal to zero.
2. Check A: ABORT is sent with error cause Invalid mandatory parameter.
3. Repeat the above test case if a_rwnd parameter is zero in the INIT
message and Init-Tag is non zero. Response should be same.
4. Repeat the above test case if verification tag is not zero in the
INIT message and other parameters are valid.Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 44]
Internet Draft Conformance Test For SCTP Feb 2001
1.14.2 Value of Init-tag equal to zero in INIT-ACK message
TEST NUMBER : 1.14.2
Reference: SCTP RFC 2960 Clause 3.3.3
TITLE : Association Startup
SUBTITLE: Value of Init-tag equal to zero in INIT-ACK message
PURPOSE: To check the action of the system when INIT-ACK message is
received containing Init-Tag equal to zero in response to INIT message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that Init-tag field equal to
zero is sent to Endpoint B in INIT-ACK message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<----------Associate
<--------------- INIT
INIT-ACK --------------->
(Init-Tag = 0)
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to A. Send INIT-ACK
message containing Init-Tag equal to zero.
2. Check A: INIT-ACK will be discarded and ABORT will not be sent to
endpoint B.
3. Repeat the above test case if a_rwnd parameter is zero in the INIT-
ACK message and Init-Tag is non zero. Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 45]
Internet Draft Conformance Test For SCTP Feb 2001
2 Association Termination
2.1 Generation of ABORT
TEST NUMBER : 2.1
Reference: SCTP RFC 2960 Clause 9.1
TITLE : Termination
SUBTITLE : Generation of ABORT
PURPOSE: To check that when ULP send Abort primitive, an ABORT message
is sent to the other endpoint and association is aborted.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint B such that ULP sends Abort primitive.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<------- Abort
(with some error cause)
Association is removed <----------------- ABORT
(With error cause)
TEST DESCRIPTION:
1. Attempt to terminate an association between endpoint A and endpoint
B by sending Abort primitive from ULP in endpoint B. Also send the
error cause in Abort primitive.
2. Check A: On receiving Abort primitive, ABORT message is sent to the
peer with error cause received in Abort primitive.
3. Check B: Association is removed.
4. Repeat the above test case when Abort primitive is received with no
error cause.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 46]
Internet Draft Conformance Test For SCTP Feb 2001
2.2 Termination of an association by receiving ABORT with no error
cause.
TEST NUMBER : 2.2
Reference: SCTP RFC 2960 Clause 9.1
TITLE : Termination
SUBTITLE :Termination of an association by receiving ABORT with no
error cause.
PURPOSE: To check that receiving ABORT message with no error cause can
terminate an association.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that an ABORT message is sent to
endpoint B containing no error cause in it.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
ABORT --------------> Association is removed
With no error cause
Communication Lost --------->
TEST DESCRIPTION:
1. Attempt to terminate an association between endpoint A and endpoint
B by sending ABORT message with no error cause.
2. ABORT message is sent either with Peer's V-tag or Local V-tag with
T-bit set.
3. Check A: No Acknowledgement is sent for the ABORT message and
association is removed.
4. Check B: ULP are reported of the association closure.
5. Repeat the above test case with verification tag value equal to the
sender's Init-Tag.
6. Repeat the above test cases when ABORT message is sent with one or
more error causes.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 47]
Internet Draft Conformance Test For SCTP Feb 2001
2.3 Termination of an association by receiving Terminate primitive
from upper layers
TEST NUMBER : 2.3
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE:Termination of an association by receiving Terminate primitive
from upper layers.
PURPOSE: To check that receiving Terminate primitive will cause the
endpoint to send a SHUTDOWN message to its peer only when all the
outstanding DATA has been acknowledged by A.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint B such that Terminate primitive is
received from upper layers.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<--------- Send
Don't send SACK <--------------- DATA
<--------- Send
<--------------- DATA
Don't send SACK <--------- Terminate
<--------------- DATA
<--------------- DATA (retransmission)
SACK ---------------->
(for all outstanding
data at B)
<--------------- SHUTDOWN
SHUTDOWN ACK --------------->
<--------------- SHUTDOWN COMPLETE
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 48]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Try to terminate an association between endpoint A and endpoint B by
sending Terminate primitive to endpoint B from ULP. Before sending
Terminate, send some data to endpoint A and don't send SACK for them
from A.
2. Check A: SHUTDOWN message is sent to endpoint A.
3. Check B: SHUTDOWN is sent only when any data queued up at B has been
sent to A and acknowledged by A.
4. Check C: Value of Cumulative TSN Ack in SHUTDOWN message. It should
be equal to the Initial TSN received in INIT or INIT-ACK message.
5. Send one or two data message from endpoint A to endpoint B before
sending SACK. SACK will be received at endpoint A.Now check the
value of Cumulative TSN field in SHUTDOWN message.It should be equal
to the last TSN acked.
Note: There may be one or more DATA and SACK till all the data at the
endpoint A is not acknowledged.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 49]
Internet Draft Conformance Test For SCTP Feb 2001
2.4 T2-Shutdown timer expires for SHUTDOWN message
TEST NUMBER : 2.4
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: T2-Shutdown timer expires for SHUTDOWN message.
PURPOSE: To check that T2-Shutdown timer is started and after its
expiry, SHUTDOWN message is sent again.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that no SHUTDOWN-ACK or DATA is
sent in response to SHUTDOWN.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) Established)
<---------- Terminate
<----------------- SHUTDOWN
|
| T2-Shutdown
| Timer
|
|
<---------------- SHUTDOWN
|
TEST DESCRIPTION:
1. Try to terminate an association between endpoint A and endpoint B by
sending SHUTDOWN message from endpoint B.Don't send the SHUTDOWN-ACK
or any DATAGRAM from the endpoint A.
2. Check A: After expiry of T2-Shutdown timer, SHUTDOWN message is sent
again.
3. Repeat the test case if endpoint A is multihomed. In this case
Shutdown message will be retransmitted to the alternate address.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 50]
Internet Draft Conformance Test For SCTP Feb 2001
2.5 ASSOCIATION.MAX.RETRANS tries exceeds for SHUTDOWN message
TEST NUMBER : 2.5
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE : ASSOCIATION.MAX.RETRANS tries exceeds for SHUTDOWN message
PURPOSE: To verify that if SHUTDOWN is retransmitted for ASSOCIATION.
MAX.RETRANS then association is removed.
PRE-TEST CONDITIONS: Association is established between endpoint A
and B. Arrange the data in Endpoint A such that in response to SHUTDOWN
no SHUTDOWN-ACK or DATA message is sent.Let the ASSOCIATION.MAX.RETRANS
is x.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Terminate
<----------------- SHUTDOWN
|
| T2-Shutdown timer
|
<----------------- SHUTDOWN
|
| T2-Shutdown timer
|
<----------------- SHUTDOWN
. Retransmit
. SHUTDOWN x
. times
ASSOCIATION.MAX.RETRANS
Counter exceeds.
Close the association
Communication Lost --------------------------->
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message from endpoint B. No SHUTDOWN-ACK or DATA comes from
endpoint A.
2. Check A: If SHUTDOWN message is transmitted for ASSOCIATION.MAX.
RETRANS times without getting an SHUTDOWN-ACK or Data chunks,
association is closed and upper layers are reported of this.
Note: Value of the T2-Shutdown timer will increase after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 51]
Internet Draft Conformance Test For SCTP Feb 2001
2.6 Receiving SHUTDOWN-ACK message in response to SHUTDOWN message
TEST NUMBER : 2.6
Reference: SCTP RFC 2960 Clause 8.5.1 (c)
TITLE : Termination
SUBTITLE:Receiving SHUTDOWN-ACK message in response to SHUTDOWN
message.
PURPOSE: To check that SHUTDOWN-ACK message is accepted in Shutdown
Sent state, SHUTDOWN COMPLETE message is sent and association is
terminated.
PRE-TEST CONDITION: Association is established between endpoint A and B.
Arrange the data in endpoint A such that SHUTDOWN-ACK is sent in
response to SHUTDOWN message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<----------------- SHUTDOWN
SHUTDOWN-ACK -----------------> Remove the association
<----------------- SHUTDOWN COMPLTE
Communication down -------->
TEST DESCRIPTION:
1. Try to terminate association between endpoint A and B by sending
SHUTDOWN message from endpoint B. Send SHUTDOWN-ACK message.
2. Check A: SHUTDOWN COMPLETE message is received at endpoint A.
3. Check B: Association is removed and endpoint B enters closed state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 52]
Internet Draft Conformance Test For SCTP Feb 2001
2.7 Data From Upper Layers
2.7.1 Data from upper layer in Shutdown sent state
TEST NUMBER : 2.7.1
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: Data from upper layer in Shutdown sent state
PURPOSE: To verify that data received for transmission from upper layer
in Shutdown sent state is rejected.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint B such that upper layers send data to
transmit when it is in Shutdown Sent state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<---------- Terminate
<----------------- SHUTDOWN
Shutdown sent state
<---------- Send
Send Failure ----------->
SHUTDOWN-ACK ----------------->
Communication is Lost ----------->
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint B to endpoint A by
sending SHUTDOWN. Now send data from ULP in B to transmit.
Record the message sequence using a signal emulator.
2. Check A: Data is rejected.
3. Check B: Current state is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 53]
Internet Draft Conformance Test For SCTP Feb 2001
2.7.2 Data from upper layer in Shutdown receive state
TEST NUMBER : 2.7.2
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: Data from upper layer in Shutdown receive state
PURPOSE:To verify that data received for transmissions from upper layer
in Shutdown receive state is rejected.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint B such that upper layers send data to
transmit when it is in Shutdown receive state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established) <-------- send
<----------------- DATA
Don't send SACK
SHUTDOWN ----------------->
Shutdown receive state
<----------------- DATA
<-------- Send
Send Failure -------->
SACK ----------------->
<----------------- SHUTDOWN-ACK
SHOTDOWN COMPLETE ----------------->
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint A to endpoint B by
sending SHUTDOWN. Now send data from ULP in B to transmit.
Record the message sequence using a signal emulator.
2. Check A: Data is rejected.
3. Check B: Current state is not disturbed.
4. Check C: Send the Shutdown message with Cumulative TSN field acknow
ledging the DATA received from B. In this case DATA will not be
retransmitted from endpoint A and SHUTDOWN-ACK will be sent on
receiving SHUTDOWN.
5. Send Terminate primitive from ULP while in Shutdown-Receive state.
SHUTDOWN will not be sent.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 54]
Internet Draft Conformance Test For SCTP Feb 2001
2.7.3 Data from upper layer in Shutdown pending state
TEST NUMBER : 2.7.3
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: Data from upper layer in Shutdown pending state
PURPOSE:To verify that data received for transmissions from upper layer
in Shutdown pending state is rejected.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint B such that upper layers send data to
transmit when it is in Shutdown pending state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established) <--------- Send
<----------------- DATA
Don't send SACK <--------- Terminate
SHUTDOWN will not be sent
B is in Shutdown pending state
<--------- Send
Send Failure --------->
SACK ----------------->
<---------------- SHUTDOWN
SHUTDOWN-ACK ----------------->
<----------------- SHUTDOWN COMPLETE
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint B to endpoint A by
sending Terminate primitive. Also prior to this send DATA from
endpoint B and don't acknowledge it.Endpoint B is in Shutdown
pending state. Now send data from ULP to transmit to endpoint A.
Record the message sequence using a signal emulator.
2. Check A: Data is rejected.
3. Check B: Current state is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 55]
Internet Draft Conformance Test For SCTP Feb 2001
2.7.4 Data from upper layer in Shutdown-Ack sent state
TEST NUMBER : 2.7.4
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: Data from upper layer in Shutdown-Ack sent state
PURPOSE:To verify that data received for transmissions from upper layer
in Shutdown-Ack sent state is rejected.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint B such that upper layers send data to
transmit when it is in Shutdown-Ack sent state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ----------------->
<---------------- SHUTDOWN-ACK
<------- Send
Send Failure -------->
SHUTDOWN COMPLETE ----------------->
Communication Down ------->
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint A to endpoint B by
sending SHUTDOWN. SHUTDOWN-ACK will be received at endpoint A. Now
send Send primitive from ULP to SCTP to send DATA to endpoint A.
2. Check A: Send failure is returned.
3. Check B: Current state is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 56]
Internet Draft Conformance Test For SCTP Feb 2001
2.8 Data from Peer in Shutdown sent state
TEST NUMBER : 2.8
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE : Data chunks received in Shutdown Sent state from peer
PURPOSE: To verify that if data chunks are received in Shutdown Sent
state, they are immediately reported by SACK and timer T2-shutdown is
restarted.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint A such that after receiving SHUTDOWN
message,DATA message is sent to endpoint B. Let the value of
T2-Shutdown timer in B is x sec.
EXPECTED MESSAGE SEQUENCE :
Wndpoint A Endpoint B ULP
(Established) (Established)
<---------Terminate
<---------------- SHUTDOWN
(Start T2-Shutdown timer)
DATA ---------------->
<---------------- SACK + SHUTDOWN
(Restart T2-Shutdown Timer)
Don't send |
SHUTDOWN-ACK | time = x sec.
|
<---------------- SHUTDOWN
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message from endpoint B. After receiving Shutdown message,
send some data chunks from the endpoint A.
2. Check A: Data chunks are responded by SACK immediately.
3. Check B: T2-Shutdown timer is restarted with each SACK sent.
Note:SACK may not be bundled with SHUTDOWN in this case but they may go
separately.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 57]
Internet Draft Conformance Test For SCTP Feb 2001
2.9 Data Chunks are received in Shutdown Receive state
TEST NUMBER : 2.9
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE : Data Chunks are received in Shutdown Receive state
PURPOSE: To verify that data chunks received in Shutdown Receive state
are discarded.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint A such that DATA is sent to endpoint B
after sending SHUTDOWN message.Also in endpoint B there is outstanding
DATA for which SACK has not come from endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established ) <-------- Send
<---------------- DATA
Don't send SACK
SHUTDOWN ---------------->
Shutdown Receive State
<---------------- DATA (Retransmission)
DATA ----------------> Discard the data chunks
No SACK
No data Delivery to ULP
SACK ---------------->
<---------------- SHUTDOWN-ACK
SHUTDOWN COMPLETE ----------------->
Communication Lost -------->
TEST DESCRIPTION:
1. Try to terminate an association by sending SHUTDOWN message from
endpoint A. After sending the SHUTDOWN message send the DATA chunks.
Record the message sequence using an emulator.
2. Check A: Data chunks are ignored in this case.
3. Check B: Endpoint B remains in the Shutdown Receive state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 58]
Internet Draft Conformance Test For SCTP Feb 2001
2.10 SHUTDOWN from peer in Shutdown receive state
TEST NUMBER : 2.10
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: SHUTDOWN message from peer in Shutdown receive state
PURPOSE: To verify that SHUTDOWN message received for peer in Shutdown
receive state is discarded.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint A such that it sends SHUTDOWN message to
endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- send
<---------------- DATA
Don't send SACK
SHUTDOWN ---------------->
Shutdown receive state
<---------------- DATA
SHUTDOWN ---------------->
Discard the message
SACK ---------------->
<---------------- SHUTDOWN-ACK
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint A to endpoint B by
sending SHUTDOWN. Send one more SHUTDOWN message to endpoint B from
A before receiving SHUTDOWN-ACK message.
2. Check A: SHUTDOWN message is discarded.
3. Check B: Current state is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 59]
Internet Draft Conformance Test For SCTP Feb 2001
2.11 T2-Shutdown timer expires for SHUTDOWN-ACK message
TEST NUMBER : 2.11
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE: T2-Shutdown timer expires for SHUTDOWN-ACK message.
PURPOSE: To check that after expiry of T2-Shutdown timer, SHUTDOWN-ACK
message is sent again.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that no SHUTDOWN COMPLETE is sent
in response to SHUTDOWN-ACK.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ---------------->
<---------------- SHUTDOWN-ACK
| T2 Shutdown
| Timer
|
<---------------- SHUTDOWN-ACK
TEST DESCRIPTION:
1. Try to terminate an association between endpoint A and endpoint B by
sending SHUTDOWN message from endpoint A. SHUTDOWN-ACK will be sent
from the endpoint A.
Don't send SHUTDOWN COMPLETE message from endpoint A.
2. Check A: After expiry of T2-Shutdown timer, SHUTDOWN-ACK message is
received again at endpoint A.
3. Repeat the test case if endpoint A is multihomed. In this case
SHUTDOWN-ACK message will be retransmitted to the alternate address.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 60]
Internet Draft Conformance Test For SCTP Feb 2001
2.12 ASSOCIATION.MAX.RETRANS tries exceeds for SHUTDOWN-ACK message
TEST NUMBER : 2.12
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE :ASSOCIATION.MAX.RETRANS tries exceeds for SHUTDOWN-ACK
message
PURPOSE: To verify that if SHUTDOWN-ACK is retransmitted for
ASSOCIATION.MAX.RETRANS then association is removed.
PRE-TEST CONDITIONS:Association is established between endpoint A and
B.Arrange the data in Endpoint A such that in response to SHUTDOWN-ACK,
no SHUTDOWN COMPLETE message is sent. Let the ASSOCIATION.MAX.RETRANS
is x.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ---------------->
<--------------- SHUTDOWN-ACK
|
| T2-Shutdown timer
|
<---------------- SHUTDOWN-ACK
|
| T2-Shutdown timer
|
<---------------- SHUTDOWN-ACK
. Retransmit
. SHUTDOWN-ACK
. x times
ASSOCIATION.MAX.RETRANS
Counter exceeds.
Close the association
Communication Lost ------->
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message from endpoint A. SHUTDOWN-ACK comes from endpoint B
Don't send SHUTDOWN COMPLETE message from endpoint A.
2. Check B: SHUTDOWN-ACK will be retransmitted after T2-Shutdown timer.
Again don't send SHUTDOWN COMPLETE message from endpoint A.
3. Check A: If SHUTDOWN-ACK message is transmitted for
ASSOCIATION.MAX.RETRANS times without getting an SHUTDOWN COMPLETE,
association is closed and upper layers are reported of this.
Note: Value of the T2-Shutdown timer will increase after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 61]
Internet Draft Conformance Test For SCTP Feb 2001
2.13 Receiving SHUTDOWN COMPLETE message in response to SHUTDOWN-ACK
message
TEST NUMBER : 2.13
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Termination
SUBTITLE:Receiving SHUTDOWN COMPLETE message in response to SHUTDOWN-
ACK message.
PURPOSE:To check that SHUTDOWN COMPLETE message is accepted in Shutdown
Ack Sent state and association is terminated.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that SHUTDOWN COMPLETE is sent in
response to SHUTDOWN-ACK message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ---------------->
<--------------- SHUTDOWN-ACK
SHUTDOWN COMPLETE ----------------> Remove the association
Communication down ------>
TEST DESCRIPTION:
1. Try to terminate association between endpoint A and B by sending
SHUTDOWN message from endpoint A. SHUTDOWN-ACK message will be
received at endpoint A.
Send SHUTDOWN COMPLETE message from endpoint A.
2. Check A: SHUTDOWN COMPLETE message is received at endpoint A.
3. Check B: Association is removed and endpoint B enters closed state.
4. Repeat the above test case if T bit in SHUTDOWN COMPLETE message is
set to 1 and verification tag is equal to that of peer.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 62]
Internet Draft Conformance Test For SCTP Feb 2001
3 Invalid Message Handling
3.1Invalid INIT Message with message length < length of all mandatory
parameters
TEST NUMBER : 3.1
Reference: SCTP RFC 2960 Clause 5.1
TITLE : Invalid Message Handling
SUBTITLE: Invalid INIT Message with message length < length of all
mandatory parameters
PURPOSE:To check the action of the system on reception of invalid INIT
message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that INIT message is sent to
endpoint B with message length less than the length of all mandatory
parameters.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Closed) (Closed)
a)
INIT ---------------->
(message length < length
of all mandatory parameters)
<---------------- ABORT
(With cause of ABORT)
b)
INIT (OS = 0) ---------------->
<---------------- ABORT
c)
INIT (MIS = 0) ---------------->
<---------------- ABORT
d)
INIT(A_rwnd = 0) ---------------->
<---------------- ABORT
OS= Outbound Stream
MIS= Minimum Inbound Stream
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 63]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B. Send
INIT message with message length <length of all mandatory
parameters. Record the message sequence using a signal emulator.
2. Check A: INIT message is responded with ABORT including cause of
abort.
3. Check B: Verification_Tag field in the common header of Abort is
equal to the initiate tag value of peer received in INIT message.
4. Check C: Was the message sequence as above.
5. Repeat the above test with value of Outbound stream NULL in INIT
message. It will be responded with ABORT.
6. Repeat the above test with value of Inbound stream NULL in INIT
message. It will be responded with ABORT.
Repeat the above test with value of a_rwnd NULL in INIT message. It
will be responded with ABORT.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 64]
Internet Draft Conformance Test For SCTP Feb 2001
3.2 INIT-ACK Message with mandatory parameter missing
TEST NUMBER : 3.2
Reference: SCTP RFC 2960 Clause 5.1
TITLE : Invalid Message handling
SUBTITLE: INIT-ACK Message with mandatory parameter missing
PURPOSE: To check the action of the system on reception of invalid
INIT-ACK message.
PRE-TEST CONDITIONS:Association is not established between endpoint and
B.Arrange the data in endpoint A such that INIT-ACK with message length
less than length of mandatory parameters.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)<-------- Associate
<---------------- INIT
a)
INIT-ACK ---------------->
(message length < length of
all mandatory parameters)
<---------------- ABORT(with cause of abort)
b)
INIT-ACK (OS= 0) ---------------->
<--------------- ABORT
c)
INIT-ACK(MIS= 0) ---------------->
<---------------- ABORT
d)
INIT-ACK(a_rwnd= 0) ---------------->
<---------------- ABORT
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint B to A. Send
INIT-ACK message, in response to INIT message, with message length
less than length of all mandatory parameters.
Record the message sequence using a signal emulator.
2. Check A: INIT-ACK message is responded with ABORT including cause of
abort.
3. Check B: Verification_Tag field in the common header of Abort is
equal to the initiate tag value of peer received in INIT-ACK.
4. Repeat the above test with value of Outbound stream NULL in INIT-ACK
message. ABORT message will be sent in response to INIT-ACK.
5. Repeat the above test with value of Inbound stream NULL in INIT-ACK
message. ABORT message will be sent in response to INIT-ACK.
6. Repeat the above test with value of a_rwnd NULL in INIT-ACK message.
ABORT message will be sent in response to INIT-ACK.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 65]
Internet Draft Conformance Test For SCTP Feb 2001
3.3 Invalid Verification Tag field in a message
TEST NUMBER : 3.3
Reference: SCTP RFC 2960 Clause 8.5
TITLE : Invalid Message Handling
SUBTITLE: Invalid Verification Tag field in a message
PURPOSE: To check the action of the system on reception of invalid
verification tag in a message.
PRE-TEST CONDITIONS: Association is not established between endpoint
A an B. Arrange the data in endpoint A such that COOKIE-ECHO message
with a different verification tag (Different from what received in
INIT-ACK) is sent in response to INIT-ACK.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (closed)
a)
INIT ---------------->
<---------------- INIT_ACK
COOKIE-ECHO ----------------> Discard the message
(With verification tag
different from Init tag
received in INIT-ACK)
b) <------- Associate
<---------------- INIT(Start T1-Init timer)
INIT-ACK -----------------> Discard the message
(With verification tag different
from received in INIT-ACK)
<---------------- T1-Init timer expires
INIT
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 66]
Internet Draft Conformance Test For SCTP Feb 2001
c)
<-------- Associate
<---------------- INIT
INIT-ACK ----------------->
<---------------- COOKIE-ECHO
COOKIE-ACK -----------------> Discard the message
(With verification tag different T1-Init timerfrom expires
received in INIT-ACK)
<----------------- COOKIE-ECHO
For the following cases it is assumed that association exists between
endpoint A and B.
Endpoint A Endpoint B
(Established) (Established)
d)
DATA ----------------> Discard the message
(With verification tag different SACK is not sent
from received in INIT-ACK)
e)
<--------- Send
<------------------ DATA
SACK ------------------> |Discard the message
(With verification tag different |T3-rxt timer
from received in INIT-ACK) |expires
<------------------ DATA
f)
HEARTBEAT ----------------> Discard the message
(With verification tag different HEARTBEAT-ACK is not sent
from received in INIT-ACK)
g)
<--------- Request
Heartbeat
<----------------- HEARTBEAT
HEARTBEAT-ACK -----------------> Discard the message
(With verification tag different Retrans.Count counter is
from received in INIT-ACK) not reset
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 67]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send
COOKIE-ECHO message (in response to INIT-ACK) with verification
tag value different from received in INIT-ACK.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO message is discarded.
3. Check B: Was the message sequence as above.
4. Repeat the test with INIT-ACK, COOKIE-ACK, DATA, HEARTBEAT,
HEARTBEAT-ACK, SACK, ERROR chunks.
Note:Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 68]
Internet Draft Conformance Test For SCTP Feb 2001
3.4 Invalid Adler-32 Checksum in SCTP datagram
TEST NUMBER : 3.4
Reference: SCTP RFC 2960 Clause 6.8
TITLE : Invalid Message Handling
SUBTITLE: Invalid Adler-32 Checksum in SCTP datagram.
PURPOSE: To check the action of the system on reception of invalid
message.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange data in endpoint A such that it sends INIT message to
endpoint B with wrong Adler-32 checksum.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
a)
INIT ----------------> Discard the message
(Wrong Adler-32 checksm)
b) <------- Associate
<---------------- INIT(Start T1-Init timer)
INIT-ACK ----------------> Discard the message
(Wrong Adler-32 Checksum) T1-Init timer expires
<--------------- INIT
c)
INIT ---------------->
<---------------- INIT-ACK
COOKIE-ECHO ----------------> Discard the message
(Wrong Adler-32 Checksum)
d) <------- Associate
<---------------- INIT
INIT-ACK ----------------> COOKIE-ECHO(Start T1-Init timer)
COOKIE-ACK ----------------> Discard the message
(Wrong Adler-32 Checksum) T1-Init timer expires
<---------------- COOKIE-ECHO
e)
INIT ----------------->
<---------------- INIT-ACK
COOKIE-ECHO ----------------->
<---------------- COOKIE-ACK
DATA -----------------> Discard the DATA
(Wrong Adler-32 Checksum) SACK is not sent
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 69]
Internet Draft Conformance Test For SCTP Feb 2001
f)
INIT ----------------->
<---------------- INIT-ACK
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
<-------- Send
<----------------- DATA
SACK T3-rxt timer
(Wrong Adler-32 Checksum) -----------------> Discard SACK expires
DATA
For the following cases, precondition is that endpoint A and B are
having an association between them
Endpoint A Endpoint B ULP
(Established) (Established)
g)
HEARTBEAT -----------------> Discard HEARBEAT
(Wrong Adler-32 Checksum) HEARTBEAT-ACK is not sent
h)
<-------- Heartbeat Request
<----------------- HEARTBEAT
HEARTBEAT-ACK -----------------> HEATBEAT-ACK is discarded
(Wrong Adler-32 Checksum) Retrans.Count counter is not reset
i)
SHUTDOWN -----------------> Discard the message
(Wrong Adler-32 Checksum) <--------- Send
<----------------- DATA
j)
<--------- Terminate
<----------------- SHUTDOWN
SHUTDOWN-ACK ------------------> Discard the message
(Wrong Adler-32 Checksum)
T2-Shutdown timer expires
<------------------
SHUTDOWN
k)
ABORT ------------------> Discard ABORT
(Wrong Adler-32 Checksum) <---------- Send
<----------------- DATA
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 70]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send INIT
message with wrong Adler-32 checksum.
Record the message sequence using a signal emulator.
2. Check A: INIT message is discarded and no other actions are taken.
3. Check B: Was the message sequence as above.
4. Repeat the test if other messages like INIT-ACK, COOKIE-ECHO,
COOKIE-ACK, SHUTDOWN, SHUTDOWN-ACK, ERROR, ABORT, SACK, HEARTBEAT,
HEARTBEAT-ACK and DATA message are received with wrong Adler-32
checksum.
Note:Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 71]
Internet Draft Conformance Test For SCTP Feb 2001
3.5 Invalid COOKIE-ECHO message with wrong MD5 signature
TEST NUMBER : 3.5
Reference: SCTP RFC 2960 Clause 5.1.5 (1)&(2)
TITLE : Invalid Message Handling
SUBTITLE: Invalid COOKIE-ECHO message.
PURPOSE: To check the action of the system on reception of invalid
COOKIE-ECHO message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that COOKIE-ECHO message is
sent with MD5 signature different from received cookie in INIT-ACK.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Closed) (Closed)
INIT ----------------->
<----------------- INIT_ACK
(With Cookie)
COOKIE-ECHO ------------------> Discard the message
(wrong MD5 signature)
COOKIE-ACK will not be sent
TEST DESCRIPTION:
1. Try to initiate an association from endpoint A to B.Send COOKIE-ECHO
message containing different MD5 signature from the one received in
INIT-ACK.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO message is discarded
3. Check B: Association remains in closed state.
4. Check C: COOKIE-ACK will not be sent from endpoint B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 72]
Internet Draft Conformance Test For SCTP Feb 2001
3.6 Invalid COOKIE-ECHO message with life time expired
TEST NUMBER : 3.6
Reference: SCTP RFC 2960 Clause 5.1.5 (3)
TITLE : Invalid Message Handling
SUBTITLE: Invalid COOKIE-ECHO message
PURPOSE: To check the action of the system on reception of invalid
COOKIE-ECHO message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that COOKIE-ECHO message is
sent after life time of the received cookie in INIT-ACK message has
expired. Also let the life time of COOKIE-ECHO sent by B is x sec.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Closed) (Closed)
INIT ----------------->
Time > x sec <----------------- INIT_ACK
(With Cookie having life time x sec.)
COOKIE-ECHO -----------------> Discard the message
(sent after x sec of
receiving INIT-ACK)
<---------------- OPERATIONAL ERROR
(Cause= Stale Cookie Error)
TEST DESCRIPTION:
1. Attempt to initiate an association between endpoint A and B. Send
COOKIE-ECHO message after the life time received in INIT-ACK has
expired.
Record the message sequence using a signal emulator.
2. Check A: COOKIE-ECHO message is discarded and ERROR message with
cause Stale Cookie Error is sent.
3. Check B: In the ERROR message, Measure of staleness is either set to
0 or to the time past the cookie has expired.
4. Check C: Association remains in closed state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 73]
Internet Draft Conformance Test For SCTP Feb 2001
3.7 Invalid ABORT message
TEST NUMBER : 3.7
Reference: SCTP RFC 2960 Clause 8.5.1 (b)
TITLE : Invalid Message Handling
SUBTITLE: Invalid ABORT message.
PURPOSE:To check the action of the system on reception of invalid ABORT
message.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that ABORT message is sent to
endpoint B with incorrect verification tag.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
ABORT ----------------> Message is discarded
(Incorrect
Verification Tag) <-------- Send
<---------------- DATA
TEST DESCRIPTION:
1. Try to terminate an association between endpoint A and endpoint B by
sending ABORT message. In the ABORT message verification tag value
should match neither its own Init-Tag nor of its peer.
2. Check A: ABORT message is discarded and no actions are taken.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 74]
Internet Draft Conformance Test For SCTP Feb 2001
3.8 Chunk length greater than packet length
TEST NUMBER : 3.8
Reference: SCTP RFC 2960
TITLE : Invalid Message Handling
SUBTITLE: Chunk length greater than packet length
PURPOSE:To verify that if the packet length received is smaller than
the Chunk length defined then that packet is discarded.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that chunk length is greater
than the length of the message being sent to other endpoint.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Closed) (Closed)
INIT -----------------> Discard the message
(Chunk Length > packet length)
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B. Send
INIT message with chunk length greater than packet length.
Record the message sequence using a signal emulator.
2. Check A: INIT message is discarded.
3. Repeat the above test cases with other messages like INIT-ACK, SACK,
COOKIE-ECHO, COOKIE-ACK, SHUTDOWN, SHUTDOWN-ACK, HEARTBEAT,
HEARTBEAT-ACK, ABORT, DATA and ERROR.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 75]
Internet Draft Conformance Test For SCTP Feb 2001
3.9 Invalid SHUTDOWN-ACK message
TEST NUMBER : 3.9
Reference: SCTP RFC 2960 8.5.1 (c)
TITLE : Invalid Message Handling
SUBTITLE: Invalid SHUTDOWN-ACK message
PURPOSE: To check the action of the system on reception of invalid
SHUTDOWN-ACK message.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint A such that SHUTDOWN-ACK message with
invalid verification tag is sent to endpoint B in Shutdown Sent state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<------- Terminate
<----------------- SHUTDOWN
SHUTDOWN-ACK -----------------> Ignore the message
(Invalid verification tag)
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Try to send SHUTDOWN-ACK message from endpoint B with verification
tag neither its own nor of its peer while the other end is in
Shutdown Sent state.
2. Check A: SHUTDOWN-ACK message is ignored.
3. Check B: Current state of endpoint B is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 76]
Internet Draft Conformance Test For SCTP Feb 2001
3.10 Invalid SHUTDOWN COMPLETE message
TEST NUMBER : 3.10
Reference: SCTP RFC 2960 8.5.1 (c)
TITLE : Invalid Message Handling
SUBTITLE: Invalid SHUTDOWN COMPLETE message
PURPOSE: To check the action of the system on reception of invalid
SHUTDOWN COMPLETE message.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in endpoint A such that SHUTDOWN COMPLETE message with
invalid verification tag is sent to endpoint B in Shutdown Ack Sent
state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ---------------->
<---------------- SHUTDOWN-ACK
SHUTDOWN COMPLETE ----------------> Ignore the message
(Invalid verification tag)
SHUTDOWN COMPLETE ---------------->
Communication Down -------->
TEST DESCRIPTION:
1. Try to send SHUTDOWN COMPLETE message from endpoint B with
verification tag neither its own tag nor of its peer while the other
end is in Shutdown Ack Sent state.
2. Check A: SHUTDOWN COMPLETE message is ignored.
3. Check B: Current state of endpoint B is not disturbed.
4. Repeat the above test case if verification tag in the SHUTDOWN
COMPLETE message matches the peer verification tag but T bit is not
set to 1.Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 77]
Internet Draft Conformance Test For SCTP Feb 2001
4 Duplicate Message
4.1 INIT Collision
TEST NUMBER : 4.1
Reference: SCTP RFC 2960 Clause 5.2.1
TITLE : Duplicate Message
SUBTITLE : INIT Collision
PURPOSE: To check the action of the system on reception of duplicate
INIT message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A and endpoint B such that INIT
message is sent from both ends simultaneously.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <-------Associate
<----------------- INIT
Start T1-Init Timer
INIT ----------------->
<----------------- INIT-ACK
T1-Init timer expires
<----------------- INIT
TEST DESCRIPTION:
1. Attempt to make an association between endpoint B and A by sending
associate primitive from ULP. INIT will be sent to endpoint A. Send
INIT message in response to INIT.
2. Check A: INIT-ACK message is received in response to INIT message.
3. Check B: In the INIT-ACK message, Verification Tag field of common
header is set to the tag value received from the INIT and Initiate
Tag set to its own value (same tag used by it while sending INIT
message).
4. Check C: T1-Init timer is left running after sending INIT-ACK
message in response to duplicate INIT and endpoint will remain in
the Cookie_Wait state.
5. Repeat the above test case if INIT is sent by endpoint A after
receiving COOKIE-ECHO from the other end. In this case Tie Tag
filed of Cookie parameter in INIT-ACK message should be populated
with tag information of endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 78]
Internet Draft Conformance Test For SCTP Feb 2001
4.2 Duplicate INIT Message
4.2.1 Duplicate INIT Message in Established state
TEST NUMBER : 4.2.1
Reference: SCTP RFC 2960 Clause 5.2.2
TITLE : Duplicate Message
SUBTITLE: Duplicate INIT Message in established state
PURPOSE: To check the action of the system on reception of duplicate
INIT message.
PRE-TEST CONDITIONS: Arrange the data in Endpoint A such that an INIT
message is sent to Endpoint B when association is established between
endpoint A and endpoint B. Also source IP address and destination IP
address are same as in the established association.
EXPECTED MESSAGE SEQUENCE :
Endpoint A (Established) Endpoint B (Established)
INIT ----------------->
Note Init-Tag and <---------------- INIT-ACK
Verification Tag
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B when
both endpoints have an association between them.
2. Check A: INIT-ACK message is sent in response to INIT message.
3. Check B: In the INIT-ACK message, verification tag field is set to
the peer's new tag value received in the duplicate INIT message.
4. Check C: In the INIT-ACK message, Init Tag is not equal to the Init
Tag in the existing association and it is a new value generated
randomly.
5. Check D: Cookie, sent in the INIT-ACK message,is the newly generated
Cookie with the information in the duplicate INIT message with local
tie tag and peer tie tag equal to current verification tag and peer
verification tag
6. Check :Other parameters in the INIT-ACK are copied from the existing
association like number of OS, a_rwnd.
7. Check F:After sending INIT-ACK message,no other action is taken i.e.
existing association is not disturbed.
8. Repeat the above test case if INIT message is sent to endpoint B
after receiving SHUTDOWN message from endpoint B. response should be
same.
9. Repeat the above test case if INIT message is sent to endpoint B in
Shutdown pending state and Shutdown receive state.Response should be
same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 79]
Internet Draft Conformance Test For SCTP Feb 2001
4.2.2 Duplicate INIT message in Shutdown-Ack sent state
TEST NUMBER : 4.2.2
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate INIT message in Shutdown-Ack sent state
PURPOSE: To check the action of the system on reception of duplicate
INIT message in Shutdown-Ack Sent state
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Arrange the data in Endpoint A such that after receiving SHUTDOWN-ACK
message,INIT message is sent to endpoint B.Let the T2-Shutdown timer at
endpoint B is x sec.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ----------------->
<---------------- SHUTDOWN-ACK
(Start T2-Shutdown timer)
INIT ----------------->
Discard INIT message
<---------------- SHUTDOWN-ACK
(Restart T2-Shutdown Timer)
Don't send SHUTDOWN COMPLETE |
|
| x sec.
|
<----------------- SHUTDOWN-ACK
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message from endpoint A. After Receiving SHUTDOWN-ACK
message, send INIT message with same transport addresses with which
association is established from the endpoint A.
2. Check A: INIT message is discarded and SHUTDOWN-ACK message is
transmitted again.
3. Check B: T2-Shutdown Timer is restarted after sending SHUTDOWN-ACK
again.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 80]
Internet Draft Conformance Test For SCTP Feb 2001
4.3 Duplicate INIT-ACK in COOKIE-ECHO Sent state
TEST NUMBER : 4.3
Reference: SCTP RFC 2960 Clause 5.2.3
TITLE : Duplicate Message
SUBTITLE : Duplicate INIT-ACK in Cookie-Sent state
PURPOSE: To check the action of the system on reception of duplicate
INIT-ACK message.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arrange the data in endpoint A such that INIT-ACK message is
sent to endpoint B after receiving COOKIE-ECHO message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <--------Associate
<---------------- INIT
INIT-ACK ----------------->
<----------------- COOKIE-ECHO
INIT-ACK ------------------>
Discard INIT-ACK
COOKIE-ACK ------------------>
Communication up ------->
DATA ------------------>
<------------------ SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint B to endpoint A. Send
INIT-ACK message after receiving COOKIE-ECHO message.
2. Check A:INIT-ACK message received in Cookie-Sent state is discarded.
3. Check B:Current state is not disturbed and an association can be
completed between A and B.
4. Repeat the above test case when INIT-ACK is received in other states
like Closed, Established, Shutdown Sent, Shutdown pending, Shutdown-
Ack sent and Shutdown Receive. In all the cases INIT-ACK should be
ignored.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 81]
Internet Draft Conformance Test For SCTP Feb 2001
4.4 Duplicate COOKIE-ACK in established state
TEST NUMBER : 4.4
Reference: SCTP RFC 2960 Clause 5.2.5
TITLE : Duplicate message
SUBTITLE : Duplicate COOKIE-ACK in established state
PURPOSE: To check the action of the system on reception of duplicate
COOKIE-ACK message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that COOKIE-ACK message is
sent to endpoint B after association is established between endpoint A
and endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <-------- Associate
<---------------- INIT
INIT-ACK ----------------->
<----------------- COOKIE-ECHO
COOKIE-ACK ----------------->
Communication Up --------->
COOKIE-ACK ----------------->
Discard COOKIE-ACK
DATA ----------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B. Send
COOKIE-ACK message after establishing an association between them.
2. Check A:COOKIE-ACK message received in Established state is
discarded without affecting current association.
3. Check B: Current association is not disturbed.
4. Repeat the above test case for other states like Closed, Cookie_Wait
,Shutdown pending, Shutdown sent, Shutdown receive and Shutdown-Ack
sent state. COOKIE-ACK will be discarded in all cases.
5. Repeat these test cases with ERROR message with cause Stale Cookie
Error instead of COOKIE-ACK message. This will also be discarded.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 82]
Internet Draft Conformance Test For SCTP Feb 2001
4.5 SHUTDOWN Collision
TEST NUMBER : 4.5
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : SHUTDOWN Collision
PURPOSE: To check the action of the system on reception of SHUTDOWN
message from both ends simultaneously.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
.Arrange the data in endpoint A such that SHUTDOWN message is sent
after receiving SHUTDOWN message from the other end.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Terminate
<---------------- SHUTDOWN
(Start T2-Shutdown timer)
SHUTDOWN ---------------->
<---------------- SHUTDOWN-ACK
(Restart T2-Shutdown Timer)
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message.Also send SHUTDOWN message from the other endpoint.
2. Check A: SHUTDOWN message is responded with SHUTDOWN-ACK
3. Check B: T2-Shutdown timer is restarted.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 83]
Internet Draft Conformance Test For SCTP Feb 2001
4.6 Duplicate Shutdown Message
4.6.1 Duplicate SHUTDOWN message in Cookie Wait state
TEST NUMBER : 4.6.1
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate SHUTDOWN message in Cookie Wait state
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B.Arrange the data in endpoint A such that SHUTDOWN message is sent
to endpoint B after receiving INIT message from it.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<-------- Associate
<---------------- INIT
(Start T1-Init timer)
SHUTDOWN ----------------->
Discard SHUTDOWN message
T1-Init timer expires
<---------------- INIT
TEST DESCRIPTION:
1. Try to create an association between endpoint A and B by sending
INIT message. Send SHUTDOWN message from the other endpoint.
Record the message sequence using an emulator.
2. Check A: SHUTDOWN message is discarded.
3. Check B: After expiry of T1-Init timer INIT message is transmitted
again.
4. Repeat the above test case when SHUTDOWN is received in other states
like Cookie Echoed state. Response will be the same as in the above
case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 84]
Internet Draft Conformance Test For SCTP Feb 2001
4.6.2 Duplicate SHUTDOWN message in closed state
TEST NUMBER : 4.6.2
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate SHUTDOWN message in Closed state
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN message in closed state.
PRE-TEST CONDITIONS: Arrange the data in endpoint A such that SHUTDOWN
message is sent to endpoint B which is in closed state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Closed)
SHUTDOWN ---------------->
<---------------- ABORT
TEST DESCRIPTION:
1. Try to send SHUTDOWN message from one endpoint while the other end
is in closed state.
2. Check A: SHUTDOWN message is responded by ABORT message.
3. Check B: Verification tag field in ABORT message is set to
verification tag received in SHUTDOWN message.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 85]
Internet Draft Conformance Test For SCTP Feb 2001
4.6.3 Duplicate SHUTDOWN message in Shutdown Receive state
TEST NUMBER : 4.6.3
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate SHUTDOWN message in Shutdown Receive state
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN message in Shutdown receive state.
PRE-TEST CONDITIONS: Arrange the data in endpoint A such that SHUTDOWN
message is sent to endpoint B which is in established state.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<---------- send
<---------------- DATA
SHUTDOWN ---------------->
<---------------- DATA(retransmission)
SHUTDOWN -----------------> ignore the SHUTDOWN
SACK ----------------->
<----------------- SHUTDOWN-ACK
Communication Lost ---------->
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
SHUTDOWN message. While endpoint B is in Shutdown receive state,send
another SHUTDOWN from endpoint A.
Record the message sequence using an emulator.
2. Check A: SHUTDOWN message is ignored.
3. Check B: Current state of endpoint B is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 86]
Internet Draft Conformance Test For SCTP Feb 2001
4.6.4 Duplicate SHUTDOWN message in Shutdown Sent state
TEST NUMBER : 4.6.4
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate SHUTDOWN message in Shutdown Sent state
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN message in Shutdown sent state.
PRE-TEST CONDITIONS:Association is established between endpoint A and
B. Arrange the data in endpoint B such that terminate primitive is
received from ULP to terminate the association. Arrange data in
endpoint A such that SHUTDOWN message is sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Terminate
<---------------- SHUTDOWN
SHUTDOWN ---------------->
<---------------- SHUTDOWN-ACK
T2-Shutdown timer is restarted
|
|
| T2-Shutdown timer expires
|
|
<----------------- SHUTDOWN-ACK
TEST DESCRIPTION:
1. Try to terminate the association between endpoint A and B by sending
terminate primitive from ULP. While endpoint B is in Shutdown sent
state, send SHUTDOWN message from endpoint A.
2. Check A: SHUTDOWN-ACK message is sent in response to the SHUTDOWN
message.
3. Check B: T2-Shutdown timer is restarted.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 87]
Internet Draft Conformance Test For SCTP Feb 2001
4.7 Duplicate SHUTDOWN-ACK
4.7.1 SHUTDOWN-ACK in Cookie_Wait state
TEST NUMBER : 4.7.1
Reference: SCTP RFC 2960 Clause 8.5.1 (e)
TITLE : Duplicate Message
SUBTITLE: SHUTDOWN-ACK in Cookie_Wait state.
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN-CK message.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B. Arranged the data in Endpoint A such that SHUTDOWN-ACK message
is sent to endpoint B after receiving INIT message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<-------- Associate
<---------------- INIT
(Cookie_Wait State)
SHUTDOWN-ACK ----------------->
<---------------- SHUTDOWN COMPLETE
INIT-ACK ------------------>
<----------------- COOKIE-ECHO
COOKIE-ACK ------------------>
Communication Up -------->
DATA ------------------>
<----------------- SACK
TEST DESCRIPTION:
1. Try to send SHUTDOWN-ACK message with correct verification tag from
one endpoint while the other end is in Cookie_Wait state.
2. Check A: SHUTDOWN COMPLETE message is received with the verification
tag equal to the verification tag received in SHUTDOWN-ACK message
and T bit set to 1.
3. Check B: Current state of endpoint A is not disturbed.
4. Repeat the above test case if endpoint B is in Cookie Echoed state.
Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 88]
Internet Draft Conformance Test For SCTP Feb 2001
4.7.2 SHUTDOWN-ACK in Established state
TEST NUMBER : 4.7.2
Reference: SCTP RFC 2960 Clause 8.5.1 (e)
TITLE : Duplicate Message
SUBTITLE: SHUTDOWN-ACK in Established state.
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN-ACK message in Established state.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B. Arranged the data in Endpoint A such that SHUTDOWN-ACK message is
sent to endpoint B with correct verification tag.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN-ACK ---------------> Discard the message
<--------------- DATA
SACK ---------------->
TEST DESCRIPTION:
1. Try to send SHUTDOWN-ACK message with correct verification tag from
one endpoint while the other end is in stablished state.
2. Check A: The message is discarded as theend point has send SHUTDOWN
and as such not expecting SHUTDOWN-ACK.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 89]
Internet Draft Conformance Test For SCTP Feb 2001
4.7.3 SHUTDOWN-ACK in SHUTDOWN-ACK Sent state
TEST NUMBER : 4.7.3
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE: SHUTDOWN-ACK in SHUTDOWN-ACK Sent state.
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN-ACK message.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B. Arranged the data in Endpoint A such that SHUTDOWN message is sent
to endpoint B. Also SHUTDOWN-ACK message is sent to endpoint B after
receiving SHUTDOWN-ACK message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Established) (Established)
SHUTDOWN ----------------->
<----------------- SHUTDOWN-ACK
SHUTDOWN-ACK ----------------->
<----------------- SHUTDOWN COMPLETE
Communication Down --------->
TEST DESCRIPTION:
1. Send SHUTDOWN message from endpoint A to B to terminate the
association. SHUTDOWN-ACK will be received. Send SHUTDOWN-ACK
message on receiving SHUTDOWN-ACK message.
2. Check A: SHUTDOWN COMPLETE message is received.
3. Check B: Association move to the closed state and communication down
indication is given to ULP.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 90]
Internet Draft Conformance Test For SCTP Feb 2001
4.8 Duplicate COOKIE-ECHO Message
4.8.1 Duplicate COOKIE-ECHO Message with invalid MAC
TEST NUMBER : 4.8.1
Reference: SCTP RFC 2960 Clause 5.2.4
TITLE : Duplicate COOKIE-ECHO Message
SUBTITLE : Duplicate COOKIE-ECHO Message with invalid MAC.
PURPOSE: To check the action of the system on reception of duplicate
COOKIE-ECHO with invalid MAC in established state.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B. Arrange the data in endpoint A such that COOKIE-ECHO message with
invalid MAC is sent to B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Established) (Established)
COOKIE-ECHO ---------------> Discard the COOKIE-ECHO
(Invalid MAC)
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Try to send a message with invalid MAC in the Established state from
endpoint A to B.
2. Check A: COOKIE-ECHO message is discarded.
3. Check B: Existing association is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 91]
Internet Draft Conformance Test For SCTP Feb 2001
4.8.2 Duplicate COOKIE-ECHO Message with valid MAC but expired life
time.
TEST NUMBER : 4.8.2
Reference: SCTP RFC 2960 Clause 5.2.4
TITLE : Duplicate COOKIE-ECHO Message
SUBTITLE : Duplicate COOKIE-ECHO Message with valid MAC but expired
life time .
PURPOSE: To check the action of the system on reception of duplicate
COOKIE-ECHO with expired life time.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Let the life time of COOKIE-ECHO sent by B is x sec. Arrange the
data in endpoint A such that COOKIE-ECHO message with expired lifetime
is sent to B after establishing an association with a valid MAC and
verification tags in the cookie don't match current association's
verification tags.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
INIT ----------------->
<----------------- INIT-ACK
(Cookie life time = x sec.)
COOKIE-ECHO ---------------->
COOKIE-ACK
Communication Up ---------->
COOKIE-ECHO ----------------->
(send after x
sec of receiving
INIT-ACK)
<----------------- ERROR
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Try to send a COOKIE-ECHO message with expired life time in the
Established state from endpoint A to B.
2. Check A: COOKIE-ECHO message is discarded and ERROR message with
"Stale cookie error" is received at endpoint A.
3. Check B: Existing association is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 92]
Internet Draft Conformance Test For SCTP Feb 2001
4.8.3 Duplicate valid COOKIE-ECHO Message when Local and Peer tags
don't match the existing TCB but local and peer tie tag matches the
existing TCB.
TEST NUMBER : 4.8.3
Reference: SCTP RFC 2960 Clause 5.2.4
TITLE : Duplicate COOKIE-ECHO Message
SUBTITLE : Duplicate valid COOKIE-ECHO Message when Local and Peer tags
don't match the existing TCB but local and peer tie tag matches the
existing TCB
PURPOSE: To check the action of the system on reception of duplicate
valid COOKIE-ECHO.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B.Arrange the data in endpoint A such that valid COOKIE-ECHO message in
which local and peer tag don't match the existing association but local
and peer tie tags matches the TCB of existing association is sent to B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
COOKIE-ECHO --------------->
(valid)
<--------------- COOKIE-ACK
Restart -------->
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Try to send a valid COOKIE-ECHO message in the Established state
from endpoint A to B.
2. Check A: COOKIE-ACK message is sent in response to COOKIE-ECHO
message.
3. Check B: Restart indication is given to the ULP.
4. Check C: Association is established.
Note: Valid COOKIE-ECHO means that it is having correct MAC and
verification tags matches the tags in the current association.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 93]
Internet Draft Conformance Test For SCTP Feb 2001
4.9 Duplicate SHUTDOWN COMPLETE message in Cookie Wait state
TEST NUMBER : 4.9
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Duplicate Message
SUBTITLE : Duplicate SHUTDOWN COMPLETE message in Cookie Wait state
PURPOSE: To check the action of the system on reception of duplicate
SHUTDOWN COMPLETE message.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that SHUTDOWN COMPLETE
message is sent to endpoint B after receiving INIT message from it.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<--------- Associate
<---------------- INIT
(Start T1-Init timer)
SHUTDOWN COMPLETE ----------------->
Discard the message
T1-Init timer expires
<----------------- INIT
TEST DESCRIPTION:
1. Try to create an association between endpoint A and B by sending
INIT message.Send SHUTDOWN COMPLETE message from the other endpoint.
2. Check A: SHUTDOWN COMPLETE message is ignored.
3. Check B: After expiry of T1-Init timer INIT message is transmitted
again.
4. Repeat the above test case when SHUTDOWN COMPLETE is received in
other states like Cookie Echoed, established, Cookie wait, Shutdown
pending, Shutdown receive and Shutdown sent state. Response will be
the same as in the above case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 94]
Internet Draft Conformance Test For SCTP Feb 2001
4.10 Duplicate valid COOKIE-ECHO Message in Shutdown Ack sent state
when Local and Peer tags don't match the existing TCB but local and
peer tie tag matches the existing TCB.
TEST NUMBER : 4.10
Reference: SCTP RFC 2960 Clause 5.2.4
TITLE : Duplicate COOKIE-ECHO Message
SUBTITLE : Duplicate valid COOKIE-ECHO Message in Shutdown Ack sent
state when Local and Peer tags don't match the existing TCB but local
and peer tie tag matches the existing TCB
PURPOSE: To check the action of the system on reception of duplicate
valid COOKIE-ECHO.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B.Arrange the data in endpoint A such that valid COOKIE-ECHO message in
which local and peer tag don't match the existing association but local
and peer tie tags matches the TCB of existing association is sent to B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ----------------->
<----------------- SHUTDOWN-ACK
COOKIE-ECHO ----------------->
<----------------- SHUTDOWN-ACK
<------------------ ERROR
TEST DESCRIPTION:
1. Try to send a valid COOKIE-ECHO message in the Shutdown Ack sent
state from endpoint A to B.
2. Check A: COOKIE-ACK message is discarded and SHUTDOWN-ACK message
is sent again.
3. Check B: ERROR message is also sent to endpoint A with error cause
"Cookie received while shutting down".
4. Check C: Current state is not disturbed.
Note: Valid COOKIE-ECHO means that it is having correct MAC and
verification tags matches the tags in the current association.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 95]
Internet Draft Conformance Test For SCTP Feb 2001
4.11 DATA packet in Shutdown-Ack Sent state
TEST NUMBER : 4.11
Reference: SCTP RFC 2960 Clause 6
TITLE : Duplicate Message
SUBTITLE : DATA packet in Shutdown-Ack Sent state
PURPOSE: To check the action of the system on reception of duplicate
data packet in Shutdown-Ack sent state.
PRE-TEST CONDITIONS:Association is established between endpoint A and
B.Arrange the data in endpoint A such that Shutdown message is sent to
endpoint B. Also DATA message is sent from endpoint A to B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ----------------->
<----------------- SHUTDOWN-ACK
----------------->
DATA
Data is discarded
TEST DESCRIPTION:
1. Try to send a valid DATA message in the Shutdown Ack sent state from
endpoint A to B.
2. Check A: DATA message is discarded.
3. Check C: Current state is not disturbed.
4. Repeat the above test case for DATA in other states like Shutdown
receive, Cookie Wait and Cookie Echoed.
5. Repeat the above test case for SACK in place of DATA chunk in states
Shutdown-Ack sent, Cookie Wait and Shutdown sent state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 96]
Internet Draft Conformance Test For SCTP Feb 2001
5 Fault Handling
1 Association.Max.Retrans Counter
5.1.1 Total number of consecutive retransmission exceeds
Association.Max.Retrans
TEST NUMBER : 5.1.1
Reference: SCTP RFC 2960 Clause 8.1
TITLE : Fault Handling
SUBTITLE: Total number of consecutive retransmission exceeds
Association.Max.Retrans
PURPOSE: To check that when total number of consecutive retransmission
to a peer exceeds the Association.Max.Retrans,the destination transport
address is marked unreachable and association is closed.
PRE-TEST CONDITION: Association is established between endpoint A and
B. The IP addresses of A in association with B are x, y and z. The
Association. Max.Retrans counter for endpoint B is X. Arrange the data
in endpoint A such that no SACK is sent in response to DATA received
from endpoint B. Let the counter name which keeps track of total
retransmission is P.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Send
<----------------- DATA (IP = x)
Don't send SACK | T3-rxt expires
|
<------------------ DATA (IP = Note)
Don't send SACK | Increment P.
| T3-rxt expires
<----------------- DATA (IP = Note)
Increment P
Retrans.Count exceeds
Path.Max.Retrans
DATA (IP = Note) Increment P
Don't send SACK <----------------- T3-rxt expires
DATA (IP = Note) Increment P
Don't send SACK <-----------------
P has exceeded X.
Association is closed
Communication Lost ------->
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 97]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state,send DATA to another endpoint.
Don't send the SACK from another endpoint and let the T3-rxt timer
expire. Retrans.Count counter will be incremented. DATA will be
retransmitted to the same IP address until Retrans.Count counter
exceeds Path.Max.Retrans. After that data will be retransmitted to
IP address y.
Record the message sequence using a signal emulator.
2. Check A: When the total retransmission to endpoint X exceeds
Association. Max.Retrans then that endpoint is marked unreachable.
3. Check B: ULP are also reported of failure.
Note: The Data may be retransmitted to the same IP address or to an
alternate IP address. In each retransmission the counter Retrans.Count
corresponding to each IP address to which DATA is retransmitted will be
incremented.
Note1: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 98]
Internet Draft Conformance Test For SCTP Feb 2001
5.1.2 The counter counting total number of retransmission to an
endpoint is reset on receiving a SACK.
TEST NUMBER : 5.1.2
Reference: SCTP RFC 2960 Clause 8.1
TITLE : Fault Handling
SUBTITLE:The counter counting total number of retransmission to
endpoint is reset on receiving SACK.
PURPOSE: To check that when SACK comes from other endpoint for a DATA
which was being retransmitted then the counter which counts the total
retransmission to an endpoint is reset.
PRE-TEST CONDITION: Association is established between endpoint A and
B.The Association.Max.Retrans counter for endpoint B is X. Arrange the
data in endpoint A such that SACK is sent in response to DATA received
from endpoint B only when the DATA has been retransmitted for two to
three times. Let the counter name which keeps track of total
retransmission is P.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<--------- Send
<----------------- | DATA
Don't send SACK |
| T3-rxt expires
<----------------- DATA Increment counter P
Don't send SACK |
| T3-rxt expires
|
<----------------- DATA Increment counter P
SACK ----------------->
Reset counter P
<--------- Send
<----------------- DATA
Don't send SACK T3-rxt expires
<----------------- DATA Increment counter P
Don't send SACK T3-rxt expires
<----------------- DATA Increment counter P
Don't send SACK
P exceeds X
Endpoint A is marked unreachable
Communication Lost --------->
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 99]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state,send DATA to another endpoint.
Dont send the SACK from another endpoint and let the T3-rxt timer
expires Retrans.Count counter will be incremented. DATA will be
retransmitted and counter counting total number of retransmission to
same IP address will be incremented. Now send SACK. Record the
message sequence using a signal emulator.
2. Check A: The counter counting the total number of retransmission to
endpoint A is reset on receiving SACK.
3. Check B: PATH. MAX. RETRANS counter is also reset.
4. Repeat the above test case if endpoint A is multihomed.
Note: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 100]
Internet Draft Conformance Test For SCTP Feb 2001
5.2 Retrans.Count counter exceeds the Path.Max.Retrans
TEST NUMBER : 5.2
Reference: SCTP RFC 2960 Clause 8.2
TITLE : Fault Handling
SUBTITLE: Retrans.Count counter exceeds the Path.Max.Retrans.
PURPOSE: To check that when Retrans.Count counter exceeds the Path.Max.
Retrans, the destination transport address is marked inactive.
PRE-TEST CONDITION: Association is established between endpoint A and B
The IP addresses of A in association with B are x and y and port is a.
Arrange the data in endpoint A such that no SACK is sent in response to
DATA received from endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<----------------- Send
<----------------- DATA (IP = x port = a)
|
| T3-rxt expires
Increment Retrans.Count
<----------------- DATA (IP = Note, Port = a)
|
| T3-rxt expires
|Increment Retrans.Count
Retrans Count exceeds
Path Max.Retrans
IP address x is marked inactive
Network Status Change ------->
TEST DESCRIPTION:
1. From an endpoint in established state,send DATA to another endpoint.
Don't send the SACK from another endpoint and let the T3-rxt timer
expire. Retrans.Count counter will be incremented. Again send DATA
till Retrans.Count counter exceeds Path.Max.Retrans.
Record the message sequence using a signal emulator.
2. Check A: Endpoint B transport address is marked inactive.
3. Check B: DATA chunks are sent to alternate transport address if one
is available.However this is implementation specific.
Note: The Data may be retransmitted to the same IP address or to an
alternate IP address. In each retransmission the counter Retrans.Count
corresponding to each IP address to which DATA is retransmitted will be
incremented.
Note1: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 101]
Internet Draft Conformance Test For SCTP Feb 2001
5.3 Retrans.Count counter is reset on receiving HEARTBEAT-ACK or
SACK.
TEST NUMBER : 5.3
Reference: SCTP RFC 2960 Clause 8.2
TITLE : Fault Handling
SUBTITLE: Retrans.Count counter is reset on receiving HEARTBEAT-ACK or
SACK.
PURPOSE: To check that when HEARTBEAT-ACK or SACK for an outstanding
TSN is received from a destination transport address then Retrans.Count
counter corresponding to that destination address is reset.
PRE-TEST CONDITION: Association is established between endpoint A
(with IP address y and z and port c) and B. Let the Path.Max.Retrans
counter of endpoint B is x. Arrange the data in endpoint A such that
SACK is sent after DATA is received in a retransmission.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<------- Send
<----------------- DATA (IP =y, Port = a ) (IP = y)
|
| T3-rxt expires
| Increment Retrans.Count
<----------------- DATA (IP =Note, Port = a)
|
| T3-rxt expires
| Increment Retrans.Count
SACK ----------------->
Retrans.Count counter is reset
<---------------------- Send
<----------------- DATA(IP =y, Port = a)
T3-rxt timer expires
<----------------- DATA(IP =Note, Port = a)
. T3-Rxt timer expires
DATA is retransmitted x times
IP address y is marked inactive
Network Status change ------->
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 102]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state,send DATA to another endpoint.
Don't send the SACK from another endpoint and let the T3-rxt timer
expire. Retrans.Count counter will be incremented. Again send DATA
and let the T3-rxt timer expire again. Now send SACK from another
endpoint for the DATA received.
Record the message sequence using a signal emulator.
2. Check A: Retrans.Count counter is reset on receiving SACK.
3. Check B: Is the message sequence as above.
4. Repeat the above test case when HEARTBEAT-ACK message comes in place
of SACK.Note: The Data may be retransmitted to the same IP address
or to an alternate IP address. In each retransmission the counter
Retrans.Count corresponding to each IP address to which DATA is
retransmitted will be incremented.
Note1: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 103]
Internet Draft Conformance Test For SCTP Feb 2001
5.4 Retrans.Count counter is not reset on receiving SACK for an
outstanding TSN, which was sent on an alternate transport address.
TEST NUMBER : 5.4
Reference: SCTP RFC 2960 Clause 8.2
TITLE : Fault Handling
SUBTITLE: Retrans.Count counter is not reset on receiving SACK for an
outstanding TSN, which was sent on an alternate transport address.
PURPOSE: To check that when SACK for an outstanding TSN sent on an
alternate address is received, then Retrans.Count counter corresponding
to that destination address is not reset.
PRE-TEST CONDITION: Association is established between endpoint A
(with IP address x and y and port c) and B.Arrange the data in endpoint
B such that if SACK doesn't come for DATA sent in T3-rxt time then DATA
is sent again on an alternate transport address.Let the
Path.Max.Retrans counter for address x is a and for y is b.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Send
<----------------- DATA (IP Add = x Port = c) (IP add = x)
|
| T3-rxt expires
Increment Retrans.Count
<----------------- DATA (IP Add = x Port = c)
T3-rxt expires
<----------------- DATA (IP Add = Note Port = c)
. Retransmit "a" times
Path.Max.Retrans for x exceeds
Network Status change ----------->
<----------------- DATA (IP add = y Port = c)
(retransmission)
SACK ----------------->
Retrans.Count counter is not reset
<-------- Send
(IP add = x)
<----------------- DATA (IP add = y Port = c)
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 104]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state,send DATA to another endpoint.
Don't send the SACK from another endpoint and let the T3-rxt timer
expire. Retrans.Count counter will be incremented. Again retransmit
DATA to an alternate transport address of the receiver. Now send
SACK from peer for the DATA received. Record the message sequence
using a signal emulator.
2. Check A: Retrans.Count counter is not reset on receiving SACK and
data is sent on alternate address.
Note: The Data may be retransmitted to the same IP address or to an
alternate IP address. In each retransmission the counter Retrans.Count
corresponding to each IP address to which DATA is retransmitted will be
incremented.
Note1: This case is implementation specific.
Note2: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 105]
Internet Draft Conformance Test For SCTP Feb 2001
5.5 HEARTBEAT message is sent periodically to an idle active station
TEST NUMBER : 5.5
Reference: SCTP RFC 2960 Clause 8.3
TITLE : Fault Handling
SUBTITLE: HEARTBEAT message is sent periodically to an idle active
station.
PURPOSE: To check that when a destination transport address is idle for
a long time then HEARTBEAT message is sent to that address.
PRE-TEST CONDITION: Association is established between endpoint A
(with IP address y and z and port c) and B. Arrange the data in
endpoint A and B such that no DATA or control chunk is exchanged
between them. Let the retrans.count counter for endpoint A is x.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
No message is exchanged within current
Heartbeat period
<----------------- HEARTBEAT(IP = y, Port = c)
| (Increment Retrans.Count Counter)
| Current Heartbeat Interval
|
<----------------- HEARTBEAT(IP = y, Port = c)
(Increment Retrans.Count Counter)
|
| Send HEARTBEAT x
| times
IP address y is marked inactive
Network Status Change ------->
<----------------- HEARTBEAT(IP = y, Port = c)
Retrans.Count Counter is not
incremented as it has reached
the maximum value x
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 106]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state, do not send any message to
another endpoint within the current Heartbeat period.
2. Check A: HEARTBEAT message is sent from one endpoint to its peer.
3. Check B: Retrans.Count counter is incremented.
4. Check C: If DATA message is sent in between sending HEARTBEAT from
endpoint B to A then heartbeat interval is started from the time
when DATA message was sent.
5. Check D: Heartbeat interval is equal to the RTO for that destination
plus the HB interval set by the SCTP user.
6. Repeat the above test case when the endpoint A has been marked
inactive.
7. Repeat the above test case if endpoint A is multihomed and all are
idle. Only one HEARTBEAT message to on destination should be sent in
one HB interval.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 107]
Internet Draft Conformance Test For SCTP Feb 2001
5.6 Heartbeat Request primitive
TEST NUMBER : 5.6
Reference: SCTP RFC 2960 Clause 8.3
TITLE : Fault Handling
SUBTITLE: Heartbeat Request primitive.
PURPOSE: To check that when ULP send Heartbeat Request primitive then
HEARTBEAT message is sent to that address.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint B such that ULP in B send Heartbeat
Request primitive.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<--------- Heartbeat request
<----------------- HEARTBEAT
(Increment Retrans.count counter)
TEST DESCRIPTION:
1. From ULP of endpoint B in established state, send Heartbeat Request
primitive for endpoint A.
Record the message sequence using a signal emulator.
2. Check A: HEARTBEAT message is sent from endpoint B to endpoint A.
3. Check B: Retrans.Count counter is incremented.
4. Repeat the above test case when the other endpoint has been marked
inactive.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 108]
Internet Draft Conformance Test For SCTP Feb 2001
5.7 HEARTBEAT message is responded with HEARBEAT-ACK
TEST NUMBER : 5.7
Reference: SCTP RFC 2960 Clause 8.3
TITLE : Fault Handling
SUBTITLE: HEARTBEAT message is responded with HEARBEAT-ACK.
PURPOSE: To check that when HEARTBEAT message is sent to an idle
destination transport address, it is responded by HEARTBEAT-ACK with
the information carried in the Heartbeat message.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in endpoint A such that HEARTBEAT message is sent to
its peer.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Established) (Established)
HEARTBEAT ----------------->
<----------------- HEARTBEAT-ACK
Information copied from the
HEARTBEAT message
TEST DESCRIPTION:
1. From an endpoint in established state, send HEARTBEAT message to
another endpoint.
Record the message sequence using a signal emulator.
2. Check A: HEARTBEAT-ACK message will be sent in response to HEARTBEAT
message.
3. Check B: Information carried in the HEARTBEAT message is carried
back into the HEARTBEAT-ACK message.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 109]
Internet Draft Conformance Test For SCTP Feb 2001
5.8 HEARTBEAT-ACK message comes from an inactive destination
TEST NUMBER : 5.8
Reference: SCTP RFC 2960 Clause 8.3
TITLE : Fault Handling
SUBTITLE: HEARTBEAT-ACK message comes from an inactive destination.
PURPOSE:To check that when HEARTBEAT-ACK message comes from an inactive
destination transport address, that destination is marked active and
Retrans.Count counter for that destination transport address is reset.
PRE-TEST CONDITION: Association is established between endpoint A (with
IP address y and z and port c) and B. Arrange the data in endpoint A
such thatHEARTBEAT-ACK message is sent to its peer. Let the
Path.Max.Retrans counter for endpoint A is x.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<------- Send
<----------------- DATA (IP = y, Port = c)
Don't send SACK |
| T3-rxt expires
| Increment Retrans.Count
<----------------- DATA (IP = Note, Port = c)
Don't send SACK
| T3-rxt expires|
| Increment Retrans.Count
| . x times
Retrans.Count exceeds
Path.Max.Retrans
IP y is marked inactive -------->
Network Status Change
<-------- Heartbeat
request
<----------------- HEARTBEAT (IP = y, Port = c) (IP = y)
HEARTBEAT-ACK -----------------> IP address is marked active
Network Status Change ----->
<----------------- DATA <-------- Send
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 110]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. From an endpoint in established state, which is inactive, send
HEARTBEAT-ACK message to another endpoint in response to HEARTBEAT
message. Record the message sequence using a signal emulator.
2. Check A: On receiving HEARTBEAT-ACK message from inactive transport
address that transport address is marked active.
3. Check B: Retrans.Count counter for that transport address is reset.
Note: The Data may be retransmitted to the same IP address or to an
alternate IP address. In each retransmission the counter Retrans.Count
corresponding to each IP address to which DATA is retransmitted will be
incremented.
Note1: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 111]
Internet Draft Conformance Test For SCTP Feb 2001
5.9 OOTB datagram
5.9.1 OOTB DATA Packet
TEST NUMBER : 5.9.1
Reference: SCTP RFC 2960 Clause 8.4
TITLE : Fault Handling
SUBTITLE: Valid DATA packet comes from an address with which endpoint
has no association. (OOTB datagram)
PURPOSE: To check that a data packet, received from a destination
address corresponding to which there is no association, is responded
with ABORT message.
PRE-TEST CONDITION: No association exists between endpoint A and B.
Arrange the data in endpoint A such that DATA is sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed)
DATA -----------------> Passes Adler-32 checksum
<----------------- ABORT
Discard the DATA
<-------- Associate
<----------------- INIT
INIT-ACK ----------------->
<----------------- COOKIE-ECHO
COOKIE-ACK ------------------>
<--------- Send
<----------------- DATA
TEST DESCRIPTION:
1. From endpoint A, send valid DATA message to endpoint B, when there
is no association between them.
Record the message sequence using a signal emulator.
2. Check A: ABORT message will be sent.
3. Check B: Verification tag in the ABORT will be set equal to the
verification tag in the received DATA
4. Check C: DATA is discarded.
5. Check D: State of endpoint B is not disturbed.
6. Check E: T-Bit in the ABORT chunk is set to 1.
7. Repeat the above test case for SHUTDOWN, INIT-ACK and SACK chunk.
Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 112]
Internet Draft Conformance Test For SCTP Feb 2001
5.9.2 OOTB ABORT Packet
TEST NUMBER : 5.9.2
Reference: SCTP RFC 2960 Clause 8.4
TITLE : Fault Handling
SUBTITLE: Valid ABORT chunk comes from an address with which endpoint
has no association. (OOTB datagram)
PURPOSE: To check that ABORT, received from a destination address
corresponding to which there is no association, is silently discarded.
PRE-TEST CONDITION: No association exists between endpoint A and B.
Arrange the data in endpoint A such that ABORT is sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed)
ABORT ----------------> Passes Adler-32 checksum
Discard the ABORT chunk
<------- Associate
<----------------- INIT
INIT-ACK ------------------>
<------------------ COOKIE-ECHO
COOKIE-ACK ------------------>
<------- Send
<------------------ DATA
TEST DESCRIPTION:
1. From endpoint A, send valid ABORT message to endpoint B, when there
is no association between them.
2. Check A: ABORT message will be silently discarded.
3. Check C: State of endpoint B is not disturbed.
4. Repeat the test case with T bit set to 0 and 1.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 113]
Internet Draft Conformance Test For SCTP Feb 2001
5.9.3 OOTB SHUTDOWN-ACK Packet
TEST NUMBER : 5.9.3
Reference: SCTP RFC 2960 Clause 8.4
TITLE : Fault Handling
SUBTITLE: Valid SHUTDOWN-ACK packet comes from an address with which
endpoint has no association. (OOTB datagram)
PURPOSE: To check that a SHUTDOWN-ACK packet, received from a
destination address corresponding to which there is no association,
is responded with SHUTDOWN-COMPLETE message.
PRE-TEST CONDITION: No association exists between endpoint A and B.
Arrange the data in endpoint A such that SHUTDOWN-ACK is sent to
endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed)
SHUTDOWN-ACK ----------------> Passes Adler-32 checksum
<---------------- SHUTDOWN COMPLETE
Discard the DATA
<--------- Associate
<---------------- INIT
INIT-ACK ---------------->
COOKIE-ECHO
COOKIE-ACK ---------------->
<---------- end
<---------------- DATA
TEST DESCRIPTION:
1. From endpoint A, send valid SHUTDOWN-ACK message to endpoint B, when
there is no association between them.
2. Check A: SHUTDOWN COMPLETE message will be sent.
3. Check B: Verification tag in the SHUTDOWN COMPLETE message will be
set equal
to the verification tag in the received SHUTDOWN-ACK message.
4. Check C: T bit in the chunk flags is set to 1.
5. Check D: State of endpoint B is not disturbed.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 114]
Internet Draft Conformance Test For SCTP Feb 2001
5.9.4 OOTB SHUTDOWN COMPLETE Packet
TEST NUMBER : 5.9.4
Reference: SCTP RFC 2960 Clause 8.4
TITLE : Fault Handling
SUBTITLE: Valid SHUTDOWN COMPLETE packet comes from an address with
which endpoint has no association. (OOTB datagram)
PURPOSE: To check that a SHUTDOWN COMPLETE packet, received from a
destination address corresponding to which there is no association, is
silently discarded.
PRE-TEST CONDITION: No association exists between endpoint A and B.
Arrange the data in endpoint A such that SHUTDOWN COMPLETE is sent
to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed)
SHUTDOWN COMPLETE ----------------> Passes Adler-32 checksum
Discard SHUTDOWN COMPLETE
<--------- Associate
<---------------- INIT
INIT-ACK ----------------->
<----------------- COOKIE-ECHO
COOKIE-ACK ----------------->
<--------- Send
<------------------ DATA
TEST DESCRIPTION:
1. From endpoint A, send valid SHUTDOWN COMPLETE message to endpoint B,
when there is no association between them.
2. Check A: SHUTDOWN COMPLETE message will be discarded.
3. Check B: State of endpoint B is not disturbed.
4. Repeat the test case with T bit set to 0 and 1.
5. Repeat the test case if instead of SHUTDOWN COMPLETE message,
"stale cookie" ERROR is received. Response should be same.
6. Repeat the test case if instead of SHUTDOWN COMPLETE message,
COOKIE ACK message is received. Response should be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 115]
Internet Draft Conformance Test For SCTP Feb 2001
5.9.5 OOTB Packet from or to non-unicast address
TEST NUMBER : 5.9.5
Reference: SCTP RFC 2960 Clause 8.4
TITLE : Fault Handling
SUBTITLE:Valid packet comes from non-unicast address with which
endpoint has no association. (OOTB datagram)
PURPOSE: To check that a valid packet, received from a non-unicast
address or destined to non-unicast address is silently discarded.
PRE-TEST CONDITION: No association exists between endpoint A and B.
Arrange the data in endpoint A such that COOKIE ECHO is sent to
endpoint B with non unicast source address.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed)
COOKIE ECHO ----------------> Passes Adler-32 checksum
Discard COOKIE ECHO
<--------- Associate
<---------------- INIT
INIT-ACK ---------------->
<---------------- COOKIE-ECHO
COOKIE-ACK ---------------->
<--------- Send
<---------------- DATA
TEST DESCRIPTION:
1. From endpoint A, send valid COOKIE ECHO message with non-unicast
source address to endpoint B, when there is no association between
them.
2. Check A: COOKIE-ECHO message will be discarded.
3. Check B: State of endpoint B is not disturbed.
4. Repeat the above with other messages with non unicast source
address.
5. Repeat the above test case for non unicast destination transport
address.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 116]
Internet Draft Conformance Test For SCTP Feb 2001
6 ERROR
6.1 ERROR message with cause Stale Cookie Error received in Cookie
Echoed State
TEST NUMBER : 6.1
Reference: SCTP RFC 2960 Clause 5.2.6
TITLE : ERROR
SUBTITLE:ERROR message with cause Stale Cookie Error received in Cookie
Echoed State.
PURPOSE: To verify that ERROR message, with cause Stale Cookie Error,
received in Cookie Echoed state is properly handled.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that ERROR message with
cause stale cookie error is sent in response to COOKIE message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <--------- Send
<---------------- INIT
INIT-ACK ----------------->
<----------------- COOKIE-ECHO
OPERATION ERROR ------------------> Note
Cause Stale Cookie Error
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send OPEARTION
ERROR message with cause Stale Cookie Error after receiving COOKIE
message.
2. CHECK A: The action taken by an endpoint on receiving OPERATION
ERROR with cause Stale Cookie Error should be one of the following:
a. Send a new INIT message to the endpoint to generate a new cookie and
reattempt the setup procedure.
b. Discard the TCB and report to the upper layers the inability of
setting up the association.
c. Send a new INIT message to the endpoint adding a cookie preservative
parameter requesting the extension on lifetime of cookie.
Note: Actions to be taken depend upon the implementation
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 117]
Internet Draft Conformance Test For SCTP Feb 2001
6.2 ERROR message with cause Stale Cookie Error received in state
other than Cookie Echoed State
TEST NUMBER : 6.2
Reference: SCTP RFC 2960 Clause 5.2.6
TITLE : ERROR
SUBTITLE: ERROR message with cause Stale Cookie Error received in state
other than Cookie Echoed State.
PURPOSE: To verify that ERROR message, with cause Stale Cookie Error,
received in a state other than Cookie Echoed state is properly handled.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that ERROR message with
cause stale cookie error is sent in response to COOKIE-ECHO message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <------- Associate
<---------------- INIT
INIT_ACK ---------------->
<---------------- COOKIE-ECHO
COOKIE-ACK ---------------->
Communication Up ------->
<--------------------- Send
<---------------- DATA
SACK ---------------->
ERROR ----------------> Discard the EROOR message
Cause stale cookie
---------------->
DATA <---------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to B. Send OPEARTION
ERROR message with cause Stale Cookie Error in established state.
Record the message sequence using a signal emulator.
2. CHECK A: ERROR with cause Stale Cookie Error is discarded.
3. CHECK B: Association is not disturbed.
4. Repeat the above test case when ERROR message is received in other
states except Cookie Sent state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 118]
Internet Draft Conformance Test For SCTP Feb 2001
6.3 Generation of error cause Invalid Stream Identifier
TEST NUMBER : 6.3
Reference: SCTP RFC 2960 Clause 3.3.10.1
TITLE : ERROR
SUBTITLE: Generation of different error causes
PURPOSE: To verify that if a data is sent to a nonexistent stream then
an ERROR message with cause Invalid Stream Identifier is sent.
PRE-TEST CONDITIONS:Association is established between endpoint A and B
Also let the MIS for endpoint B is x.Arrange the data in endpoint A
such that a DATA is sent to endpoint B on a stream which is not
existing for the association.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B
(Established) (Established)
DATA ---------------->
(Stream_id = x)
<---------------- ERROR (cause = Invalid Stream
Identifier with stream identifier)
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send DATA
from endpoint A on a stream non-existent for the association.
Record the messages using a signal emulator.
2. Check A: ERROR message with cause Invalid Stream Identifier is sent
to Endpoint A.
3. Check B: In the ERROR message, Stream identifier on which the
message comes is included.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 119]
Internet Draft Conformance Test For SCTP Feb 2001
6.4 Generation of error cause Missing Mandatory parameter
TEST NUMBER : 6.4
Reference: SCTP RFC 2960 Clause 3.3.10.2
TITLE : ERROR
SUBTITLE: Generation of different error causes
PURPOSE: To verify that if a INIT-ACK is sent without COOKIE message
then ERROR message with cause Missing Mandatory Parameter is sent.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that INIT-ACK is sent to
endpoint B without Cookie parameter.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpint B ULP
(Closed) Closed)
<-------- Associate
<---------------- INIT
INIT-ACK ----------------->
(Without Cookie)
<---------------- ERROR (cause = Missing
Mandatory Parameter )
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send
INIT-ACK from endpoint A without Cookie parameter..
Record the messages using a signal emulator.
2. Check A: ERROR message with cause Missing Mandatory Parameter is
sent to Endpoint A.
3. Check B: In the ERROR message, missing parameter is included.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 120]
Internet Draft Conformance Test For SCTP Feb 2001
6.5 Generation of error cause Unrecognized Parameters
TEST NUMBER : 6.5
Reference: SCTP RFC 2960 Clause 3.3.10.8
TITLE : ERROR
SUBTITLE: Generation of different error causes
PURPOSE: To verify that if a INIT-ACK is sent with a TLV parameter not
recognized by the receiver then ERROR message with cause Unrecognized
Parameter is sent.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that INIT-ACK is sent to
endpoint B with IPv6 address. Also endpoint B is not able to recognize
IPv6 addresses.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
<---------------------- Associate
<---------------- INIT
INIT-ACK ---------------->
(With IPv6 address )
<---------------- ERROR (cause = Unrecognized
Parameter )
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send
INIT-ACK from endpoint A without Cookie parameter..
Record the messages using a signal emulator.
2. Check A: ERROR message with cause Missing Mandatory Parameter is
sent to Endpoint A.
3. Check B: In the ERROR message, missing parameter is included.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 121]
Internet Draft Conformance Test For SCTP Feb 2001
6.6 Reception of COOKIE-ECHO bundled with error cause Unrecognized
Parameters
TEST NUMBER : 6.6
Reference: SCTP RFC 2960 Clause 3.3109
TITLE : ERROR
SUBTITLE: Reception of COOKIE-ECHO bundled with error cause
Unrecognized Parameters
PURPOSE: To verify that if a COOKIE-ECHO message bundled with ERROR
message (cause unrecognized parameter) is sent then endpoint continues
to establish association.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B.Arrange the data in endpoint A such that COOKIE-ECHO bundled with
ERROR (cause = Unrecognized Parameter) is sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
<---------------- INIT-ACK
COOKIE-ECHO
(Bundled with ---------------->
ERROR )
<---------------- COOKIE-ACK
Association Up ------>
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send
COOKIE-ECHO bundled with ERROR having cause Unrecognized Parameter
from endpoint A.
Record the messages using a signal emulator.
2. Check A: COOKIE-ACK message is sent to endpoint A.
3. Check B: Association is established between endpoint A and B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 122]
Internet Draft Conformance Test For SCTP Feb 2001
7 Bundling of DATA chunks with Control Chunks
7.1 Chunk Multiplexing with INIT message
TEST NUMBER : 7.1
Reference: SCTP RFC 2960 Clause 6.10
TITLE: Bundling of DATA chunks with control chunks
SUBTITLE: Chunk Multiplexing with INIT message.
PURPOSE: To verify that any data chunks multiplexed with INIT message
is discarded.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that data chunks are
multiplexed with INIT message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ----------------> Discard the Datagram
(data chunks
multiplexed)
INIT ---------------->
<---------------- INIT-ACK
COOKIE-ECHO ---------------->
COOKIE-ACK
Communication Up -------->
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send INIT
message multiplexed with data chunks. INIT chunk should be first
chunk in the packet.
2. Check A: Whole packet will be discarded and no action will be taken.
3. Check C: Endpoint B remains in the closed state.
4. Repeat the above test case if other chunks are bundled with INIT.
Response should be same. INIT may be the first or last chunk in the
packet.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 123]
Internet Draft Conformance Test For SCTP Feb 2001
7.2 Chunk Multiplexing with INIT-ACK message
TEST NUMBER : 7.2
Reference: SCTP RFC 2960 Clause 6.10
TITLE: Bundling of DATA chunks with control chunks
SUBTITLE: Chunk Multiplexing with INIT-ACK message.
PURPOSE: To verify that any data chunks multiplexed with INIT-ACK
message is discarded.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that data chunks are
multiplexed with INIT-ACK message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <--------- Associate
<---------------- INIT
INIT-ACK (data ----------------> Discard INIT-ACK
Chunks Multiplexed) | T1-Init
| Timer expires
<---------------- INIT
INIT-ACK ---------------->
<---------------- COOKIE-ECHO
COOKIE-ACK ---------------->
Communication Up ----->
DATA
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint B to A. Send INIT-
ACK message multiplexed with data chunks. INIT-ACK chunk should be
first chunk in the packet.
Record the messages using a signal emulator.
2. Check A: Packet will be discarded and no action will be taken.
3. Check C: Current State of endpoint B is not disturbed.
4. Repeat the above test case if other chunks are also bundled with
INIT-ACK. Response should be same.
5. Repeat the above test case if INIT-ACK is not the first chunk in the
packet. Response will be the same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 124]
Internet Draft Conformance Test For SCTP Feb 2001
7.3 Chunk Multiplexing with SHUTDOWN COMPLETE Chunk
TEST NUMBER : 7.3
Reference: SCTP RFC 2960 Clause 6.10
TITLE: Bundling of DATA chunks with control chunks
SUBTITLE: Chunk Multiplexing with SHUTDOWN COMPLETE Chunk.
PURPOSE: To verify that any data chunks multiplexed with SHUTDOWN
COMPLETE message are discarded.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that data chunks are
multiplexed with SHUTDOWN COMPLETE chunk.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
<---------------- INIT_ACK
COOKIE-ECHO ---------------->
<---------------- COOKIE_ACK
Communication up -------->
SHUTDOWN ---------------->
<---------------- SHUTDOWN ACK
SHUTDOWN COMPLETE ---------------->
( Bundled with DATA chunk)
<---------------- ABORT
TEST DESCRIPTION:
1. Attempt to terminate an association between endpoint A and B by
sending SHUTDOWN message from endpoint A. SHUTDOWN-ACK messages will
be received. Send SHUTDOWN COMPLETE chunk bundled with data chunks
in response to SHUTDOWN-ACK Chunk. SHUTDOWN COMPLETE chunk should
be first chunk in the packet.
2. Check A: SHUTDOWN COMPLETE message will be discarded in this case
and endpoint B will remain in Shutdown-ack sent state.
3. Repeat the above test case if DATA is the first chunk. DATA would
have been discarded and association enter closed state. ABORT would
not be received in that case.
4. Repeat the above test case if SHUTDOWN COMPLETE is bundled with
control chunks.SHUTDOWN COMPLETE will be discarded in this case
and endpoint B will remain in Shutdown-Ack sent state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 125]
Internet Draft Conformance Test For SCTP Feb 2001
7.4 COOKIE-ECHO is received bundled with data chunks with cookie as
first chunk
TEST NUMBER : 7.4
Reference: SCTP RFC 2960 Clause 5.1.5(6) & 6.10
TITLE : Bundling of DATA chunks with control chunks
SUBTITLE: COOKIE-ECHO is received bundled with data chunks with
COOKIE-ECHO as first chunk
PURPOSE: To verify that COOKIE-ECHO received bundled with data chunks
with COOKIE-ECHO as first chunk is accepted and responded by
COOKIE-ACK.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that data chunks are bundled
with COOKIE-ECHO message with COOKIE-ECHO as the first chunk.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ---------------->
<---------------- INIT-ACK
COOKIE-ECHO ----------------->
(bundled with data chunks) COOKIE-ECHO is accepted
<---------------- COOKIE-ACK
Communication Up --------->
<---------------- SACK
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to endpoint B.
Now send COOKIE-ECHO message bundled with data chunks with
COOKIE-ECHO as the first chunk.
2. Check A: COOKIE-ECHO is accepted and COOKIE-ACK is sent.
Check B : SACK is sent for the DATA chunk , bundled with COOKIE-ECHO
and received at A.
3. Repeat the above test case if DATA is the first chunk in the bundled
packet. Whole packet should be discarded in this case.
4. Repeat the above test case if control chunks are bundled with
COOKIE-ECHO. In this case also whole packet should be discarded.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 126]
Internet Draft Conformance Test For SCTP Feb 2001
7.5 COOKIE-ACK is received bundled with data chunks
TEST NUMBER : 7.5
Reference: SCTP RFC 2960 Clause 5.1.5 (5) & 6.10
TITLE : Bundling of DATA chunks with control chunks
SUBTITLE: COOKIE-ACK is received bundled with data chunks with
COOKIE-ACK as first chunk
PURPOSE: To verify that COOKIE-ACK received bundled with data chunks
with COOKIE-ACK as first chunk is accepted.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint A such that data chunks are bundled
with COOKIE-ACK message with COOKIE-ACK as the first chunk.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed) <-------- Associate
<---------------- INIT
INIT-ACK ---------------->
<---------------- COOKIE-ECHO
COOKIE-ACK ----------------> COOKIE-ACK is accepted
(bundled with data
chunks) Communication Up ------->
<---------------- SACK
DATA ---------------->
<---------------- SACK
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint B to endpoint A.
Send COOKIE-ACK message from endpoint A bundled with data chunks
with COOKIE-ACK as the first chunk. In response to INIT-ACK.
2. Check A: COOKIE-ACK is accepted and association is established.
3. Repeat the above test case if DATA is the first chunk in the bundle.
In this case whole chunk should be discarded.
4. Repeat the above test case if SACK is bundled with COOKIE-ACK with
COOKIE-ACK as the first chunk. Response should be same.
5. Repeat the above test case if SACK is bundled with COOKIE-ACK with
COOKIE-ACK as the last chunk. Whole packet will be discarded in this
case.
6. Repeat the above test case if control chunks are bundled with
COOKIE-ECHO. In this case also whole packet should be discarded.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 127]
Internet Draft Conformance Test For SCTP Feb 2001
7.6 SHUTDOWN is received bundled with SACK
TEST NUMBER : 7.6
Reference: SCTP RFC 2960 Clause 6.10 & 9.2
TITLE : Bundling of SACK with SHUTDOWN
SUBTITLE: SHUTDOWN is received bundled with SACK
PURPOSE:To verify that SHUTDOWN received bundled with SACK is accepted.
PRE-TEST CONDITIONS: Arrange the data in endpoint A such that SACK is
bundled with SHUTDOWN message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
SHUTDOWN ----------------> SHUTDOWN is accepted
(bundled with SACK) and endpoint enters
Shutdown Receive State
<---------------- SHUTDOWN-ACK
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint A to endpoint B.
Now send SHUTDOWN message bundled with SACK with SACK as the last
chunk.
2. Check A: SHUTDOWN is accepted and endpoint B enters Shutdown Receive
state.
3. Repeat the above test case with SACK as the first chunk in the
bundled datagram. Response should be same.
4. Repeat the above test case if DATA is bundled with SHUTDOWN chunk as
the first or last chunk.Whole packet will be discarded in this case.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 128]
Internet Draft Conformance Test For SCTP Feb 2001
7.7 SACK is received bundled with DATA chunks
TEST NUMBER : 7.7
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Bundling of SACK with data chunks
SUBTITLE: SACK is received bundled with DATA chunks
PURPOSE: To verify that SACK received bundled with DATA chunks is
accepted.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B.Arrange the data in endpoint A such that SACK bundled with DATA
chunks is sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<--------- Send
<---------------- DATA
SACK (bundled with ---------------->
DATA chunks) SACK is accepted ---------> Data
<---------------- SACK (For DATA received
Bundled with SACK)
TEST DESCRIPTION:
1. Send DATA from endpoint B to endpoint A. Now send SACK message
bundled with some DATA chunks from endpoint A for the DATA received
(There could be multiple data chunks in single packet)
Record the message sequence using a signal emulator.
2. Check A: SACK is accepted and SACK is also sent for the DATA
received in SACK.
3. Repeat the above test case if SACK is the last chunk in the bundle.
The SACK is dropped.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 129]
Internet Draft Conformance Test For SCTP Feb 2001
7.8 SHUTDOWN-ACK is received bundled with DATA
TEST NUMBER : 7.8
Reference: SCTP RFC 2960 Clause 9.2
TITLE : Bundling
SUBTITLE: SHUTDOWN ACK is received bundled with DATA
PURPOSE: To verify that SHUTDOWN ACK received bundled with DATA is
discarded.
PRE-TEST CONDITIONS: Association is established between endpoint A and
B.Arrange the data in endpoint A such that DATA is bundled with
SHUTDOWN-ACK message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<--------- Terminate
<---------------- SHUTDOWN
SHUTDOWN-ACK ---------------->
(Bundled with DATA) Discard the packet
TEST DESCRIPTION:
1. Attempt to terminate an association from endpoint B by sending
terminate primitive from ULP. Now send SHUTDOWN-ACK message bundled
with DATA with DATA as the last chunk.
2. Check A: Whole Packet is discarded.
3. Check B: State of endpoint B is not disturbed.
4. Repeat the above test case with DATA as the first chunk in the
bundled datagram. Response should be same.
5. Repeat the above test case if control chunks is bundled with
SHUTDOWN-ACK chunk as the first or last chunk. The control chunks
a valid chunk at B.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 130]
Internet Draft Conformance Test For SCTP Feb 2001
8 DATA
8.1 UN-SEGMENTED DATA
TEST NUMBER : 8.1
Reference: SCTP RFC 2960 Clause 3.3 and 6.9
TITLE : DATA
SUBTITLE : Un-Segmented DATA
PURPOSE: To check that if the data length is less then or equal to MTU
size endpoint B is able to send Un-segmented user message
PRE-TEST CONDITION: Arrange the data from user part such that size
is less then or equal to MTU size
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<--------------- DATA
B Bit =1 [TSN=1,Strm=0,seq=1] <----- Send
E Bit = 1 Data<=data <= MTU
MTU
TEST DESCRIPTION:
1. Check that the B bit is 1 for message received at endpoint A a
un-segmented data
2. Check that the E bit is 1 for message received at endpoint A a
un-segmented data
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 131]
Internet Draft Conformance Test For SCTP Feb 2001
8.2 DATA SEGMENTATION
TEST NUMBER : 8.2
Reference: SCTP RFC 2960 Clause 3.3 and 6.9
TITLE : DATA
SUBTITLE : DATA Segmentation
PURPOSE: To check that in the endpoint B is able to perform data
segmentation and transmission
PRE-TEST CONDITION: Arrange the large size data from user part such
that size exceeding MTU
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
B bit =1, E bit =0 <---------------
DATA [TSN=1,Strm=0,seq=1]<-------
(First peace of a segmented data ) Send
data>4
SACK
MTU ---------------->
[TSN ACK=1,Frag=0]
B bit =0, E bit =0 <--------------- DATA [TSN=2,Strm=0,seq=1]
(Middle peace of a segmented data)
B bit =0, E bit =0 <--------------- DATA [TSN=3,Strm=0,seq=1]
| Repeat Data as per MTU size
|
|
<---------------- DATA [TSN=n,Strm=0,seq=1]
B bit =1, E bit =1 (Last peace of segmented data)
TEST DESCRIPTION:
1.Check that segmentation is performed by the endpoint B as per MTU
size.
2.Check that the B bit =1 , E bit =0 first peace of segmented data.
3.Check that the B bit & E bit is 0 middle peace of a segmented data.
4.Check that the E bit =1, B bit =0 last peace of segmented data.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 132]
Internet Draft Conformance Test For SCTP Feb 2001
8.3 SEGMENTED DATA RECEPTION
TEST NUMBER : 8.3
Reference: SCTP RFC 2960 Clause 3.3 and 6.9
TITLE : DATA
SUBTITLE : Segmented DATA Reception
PURPOSE: To check that in the endpoint B is able to receive segmented
data
PRE-TEST CONDITION: Arrange the segmented data such that endpoint B
receive first , middle and end peace of a segmented data
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA [TSN=1,Strm=0,seq=1] ---------------->
<---------------- SACK
[TSN ACK=1,Frag=0]
DATA [TSN=2,Strm=0,seq=1] ---------------->
<---------------- SACK
DATA [TSN=3,Strm=0,seq=1] ---------------->
<---------------- SACK
DATA [TSN=n,Strm=0,seq=1] ---------------->
(Last peace of segmented data)
<---------------- SACK Total
Packet
TEST DESCRIPTION:
1 Check that endpoint B is able to receive complete data packet
Note: Its not necessary to get SACK in the same sequence.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 133]
Internet Draft Conformance Test For SCTP Feb 2001
8.4 CANCEL T3-rtx TIMER
TEST NUMBER : 8.4
Reference: SCTP RFC 2960 Clause 6.1 , 6.3.2 and
6.3.3
TITLE : DATA
SUBTITLE : T3-rtx timer cancel
PURPOSE: To check that after receiving SACK timer T3-rtx is canceled
PRE-TEST CONDITION: Arrange the data in Endpoint A such that SACK in
response of DATA message.T3 rxt timer is X sec for endpoint B
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<---------------- DATA [TSN=1] <------ Send
(Start T3-rtx timer)
|
| Time= Y sec (<X)
|
SACK ---------------->
[TSN ACK=2,Frag=0] (Cancel T3-rtx timer)
<---------------- DATA [TSN=2] <------ Send
|
|
|
| Time= X sec
<---------------- DATA [TSN=2]
TEST DESCRIPTION:
1. Check that whenever a transmission is made to any address,the sender
should start t3-rtx timer.
2. Check that after receiving the acknowledgement T3 timer is canceled.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 134]
Internet Draft Conformance Test For SCTP Feb 2001
8.5 T3-rtx TIMER EXPIRE
TEST NUMBER : 8.5
Reference: SCTP RFC 2960 Clause 6.1 , 6.3.2 and
6.3.3
TITLE : DATA
SUBTITLE : T3-rtx timer expire
PURPOSE: To check that after expiry of timer T3-rtx message will be
sent again.
PRE-TEST CONDITION: Association is established between endpoint A and
B.Arrange the data in Endpoint A such that no SACK in response of DATA
message.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<---------------- DATA[TSN=1] <----- Send
(Start T3-rtx timer)
|
| T3-rtx timer expired
|
<---------------- DATA[TSN=1]
T3-rtx timer expired
|
|
|
<---------------- DATA [ TSN=1]
(Start T3-rtx timer)
TEST DESCRIPTION:
1. Check that whenever a transmission is made to any address, the
sender should start t3-rtx timer.
2. Check that data is sent again after expiry of T3-rtx timer.
3. Check that when data is re transferred again T3 timer is started.
Note: Value of T3-rxt timer will be calculated after every
retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 135]
Internet Draft Conformance Test For SCTP Feb 2001
8.6 DUPLICATE DATA
TEST NUMBER : 8.6
Reference: SCTP RFC 2960 Clause 6.2
TITLE : DATA
SUBTITLE : Duplicate DATA
PURPOSE: To check that any duplicate data chunk received should be
reported in SACK and number of duplicate TSN count should be reset
once reported in SACK.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange the data in Endpoint A such that it will send duplicate DATA to
endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA ---------------->
[TSN=x] Data ------->
<---------------- SACK
[TSN ACK=x]
DATA ----------------->
[TSN=x]
DATA <---------------- SACK
[TSN=x] [TSN ACK=x]
No of duplicate TSN=2
Duplicate TSN=x
Duplicate TSN=x
DATA ----------------->
[TSN = x]
<---------------- SACK
[TSN Ack=x]
No. of duplicate TSN=1
Duplicate TSN=x
TEST DESCRIPTION:
1. Send DATA chunk from endpoint A to B with TSN x. SACK will be
received with Cum TSN x. Again send two DATA chunks with same TSN.
2. Check A: Number of duplicate TSNs field is 2 and TSN x is reported
duplicate two times.
3. Again Send DATA with same TSN from endpoint B to A.
4. Check B: SACK should be received immediately on receiving duplicate
TSN with number of duplicate TSN 1 and duplicate TSN x.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 136]
Internet Draft Conformance Test For SCTP Feb 2001
8.7 BUFFER SPACE
TEST NUMBER : 8.7
Reference: SCTP RFC 29605.1 and 6.2.1
TITLE : DATA
SUBTITLE : Buffer space
PURPOSE : To verify that if its peers rwnd indicates that the peer has
no buffer space, then data should not be transmitted
PRE-TEST CONDITIONS : Arrange the data in Endpoint A such that rwnd =0
is sent in SACK in response to DATA message.
Data should be in large size so it will be transmitted in segments
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<--------
<---------------- DATA [TSN=1] Send
SACK
[TSN ACK=1,Frag=0 ---------------->
a_rwnd=0 ]
<-----
Send
<---------------- DATA [TSN=2]
(one data packet in flight)
Data Send Failure <-----
Send
SACK ---------------->
[a_rwnd=20]
<---------------- DATA [TSN=3]
<-------- Send
<----------------- DATA [TSN=4]
SACK ---------------->
TEST DESCRIPTION:
1 To verify that at any given time the sender must not transmit new
data if its peers rwnd=o that the peer has no buffer space
2 To verify that the sender can always have one data packet in flight
to the receiver
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 137]
Internet Draft Conformance Test For SCTP Feb 2001
8.8 USER DATA IN rwnd=0
TEST NUMBER : 8.8
Reference: SCTP RFC 29605.1 and 6.2.1
TITLE : DATA
SUBTITLE : User Data in rwnd=0
PURPOSE :To verify that if rwnd=0 indicates then endpoint should accept
data from user part
PRE-TEST CONDITIONS: Arrange the data in Endpoint A such that rwnd =0
is sent in SACK in response to DATA message. Data should be in large
size so it will be transmitted in segments.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<------
<----------------- DATA [TSN=1] Send
SACK
[TSN ACK=1,Frag=0 <-----------------
a_rwnd=0 ] <------
Send
Data cant be transmitted as a_rwnd=0
but it will be accepted from user part
DATA [TSN=2 ]
/
/ <------
/ Send
/ / DATA [TSN=3 ]
/ /
SACK --------------/--> /
/ /
[a_rwnd=20 ] <----------------/ /
/
<----------------/
TEST DESCRIPTION:
1. To verify that endpoint B is accepting data from user part when
rwnd=0 is received from endpoint A
2. Verify that after receiving buffer space all outstanding data
should be transmitted
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 138]
Internet Draft Conformance Test For SCTP Feb 2001
8.9 CONGESTION
TEST NUMBER : 8.9
Reference: SCTP RFC 29606.1 and 7.2
TITLE : DATA
SUBTITLE : Congestion
PURPOSE : To verify that sender should not transmit new data if it has
cwnd =un Ack data size
PRE-TEST CONDITIONS :Arrange the Endpoint A such that It sends SACK
with all pending data acknowledge after congestion to Endpoint B
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<----------------- DATA [TSN=1] | <---------
| Send
|
<----------------- DATA [TSN=2] | <---------
| Send
<----------------- DATA [TSN=3] | <---------
Cwnd=Un Ack Data size | Send
| No data transfer |
| because of cwnd |
| |
| | <------
| | Send
| |
|
SACK -----------------> |
|
<----------------- DATA [TSN=4] |
|<---------- Send
<----------------- DATA [TSN=5]
TEST DESCRIPTION:
1 To verify that at any given time the sender must not transmit new
data if its has cwnd bytes of unacknowledged data .
2 To verify that whenever cwnd is greater then zero, the sender is
allowed to have cwnd octets of data outstanding on that transport
address.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 139]
Internet Draft Conformance Test For SCTP Feb 2001
8.10 RETRANSMISSION
TEST NUMBER : 8.10
Reference: SCTP RFC 29606.1 and 6.2
TITLE : DATA
SUBTITLE : Retransmission
PURPOSE: To verify that before sending new data chunks the sender must
first transmit any outstanding data chunk, which are marked for
retransmission.
PRE-TEST CONDITION: Arrange the segmented data such that endpoint A
ignore TSN 3 and sends SACK receive with gap in DATA
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<--------
<----------------- DATA [TSN=1] Send
SACK ----------------->
[TSN ACK=1,Frag=0]
<----------------- DATA [TSN=2] Send
(Don't send Ack) <----------------- DATA [TSN=3] <--------
Send
<--------
<----------------- DATA [TSN=4] Send
SACK (With Gap) ----------------->
[TSN ACK=2,Frag=1,
Strt=2,End=2]
Rtx expires for DATA[TSN=3]
<----------------- DATA [TSN=3]
SACK[TSN ACK =3,Frag=0]
<----------------- DATA [TSN=5]
<-------- Send
TEST DESCRIPTION:
1. Check that if SACK with fragment report shall be received,the data
at endpoint A not removed form the queue.
2. Check that rtx expires for DATA[TSN=3].It is retransmitted .The data
Chunk with TSN=1 to 4 are removed from the pending Queue after
recieving the SACK for TSN=3.
3. Verify that before sending the new data chunks the sender must first
transmit any any data chunks, which are marked for retransmission.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 140]
Internet Draft Conformance Test For SCTP Feb 2001
8.11 ORDERED DELIVERY
TEST NUMBER : 8.11
Reference: SCTP RFC 2960 Clause 6.6
TITLE : DATA
SUBTITLE : Ordered Delivery
PURPOSE: To check that if receiver deliver data to the upper layer
according to the order of there stream sequence number
PRE-TEST CONDITION: Arrange the data such that endpoint A sends ordered
DATA
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA [TSN=1,Seq=3] -----------------> U bit=0 |
| No DATA
----------------
|
|
DATA [TSN=2,Seq=2] -----------------> |
------------------
<----------------- SACK | No DATA
|
| |
DATA [TSN=3,Seq=1] -----------------> DATA | | Seq 1
----------| Seq 2
Seq 3
TEST DESCRIPTION:
1. Check that if receiver detects gap in the received data chunk
sequence, and SACK with fragment report shall be sent back
immediately.
2. To check that if DATA chunks arriving out of order of there stream
sequence number the receiver hold the received DATA chunks from
delivery until they are re-ordered .
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 141]
Internet Draft Conformance Test For SCTP Feb 2001
8.12 UN-ORDERED DELIVERY
TEST NUMBER : 8.12
Reference: SCTP RFC 2960 6.6
TITLE : DATA
SUBTITLE : Un-Ordered Delivery
PURPOSE: To check that if receiver deliver data to the upper layer
according to the order it receives data
PRE-TEST CONDITION: Arrange the segmented data such that endpoint A
send un-ordered DATA
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA [TSN=1,Sq=2] ----------------->
--------->Seq 2
<----------------- SACK Delivered
DATA [TSN=2,Sq=X] ----------------->
U bit=1 Data
<----------------- SACK
DATA [TSN=3,Sq=1] -----------------> --------> Seq 2
Delivered
-----------------> SACK
TEST DESCRIPTION:
1. To check that if DATA chunks arriving out of order of there stream
sequence number the receiver transfer the received DATA chunks to
upper layer as they are received .
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 142]
Internet Draft Conformance Test For SCTP Feb 2001
8.13 Reception of SACK from Alternate address
TEST NUMBER : 8.13
Reference: SCTP RFC 2960 6.6
TITLE : DATA
SUBTITLE : Reception of SACK from Alternate address
PURPOSE: To check that if data is sent to a multihomed endpoint on one
address and SACK comes from the alternate address in that host then it
is accepted
PRE-TEST CONDITION: Endpoint A is multihomed with two addresses X and
Y and association is established between endpoint A and B. Arrange data
in Endpoint B such that ULP sends data send primitive to endpoint A on
address X. Arrange data in endpoint B such that SACK is sent from
address Y to endpoint A.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------------------- Send
-----------------> DATA (IP add X)
SACK(From Add Y) ----------------->
Data should not be retransmitted
TEST DESCRIPTION:
1. Send DATA message from endpoint B to endpoint A on address X by
sending data primitive from ULP. Send SACK from endpoint A from
address Y.
2. Check A:SACK should be accepted and DATA should not be
retransmitted.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 143]
Internet Draft Conformance Test For SCTP Feb 2001
8.14 DATA Chunk with no user data
TEST NUMBER : 8.14
Reference: SCTP RFC 2960 Clause 6.2
TITLE : DATA
SUBTITLE : DATA chunk with no user data
PURPOSE: To check that if DATA chunk with no user data is received then
ABORT is sent.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange data in endpoint A such that DATA chunk with no user data is
sent to endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA ----------------->
<----------------- ABORT
Communication Down --------->
TEST DESCRIPTION:
1. Send DATA chunk from endpoint A to B with no user data i.e. length
should be 16.
2. Check A: ABORT should be received at endpoint A.
3. Check B: Error cause in ABORT is set to "No User Data".
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 144]
Internet Draft Conformance Test For SCTP Feb 2001
8.15 SACK containing Cumulative TSN less than the Cumulative TSN Ack
point.
TEST NUMBER : 8.15
Reference: SCTP RFC 2960 Clause 6.2.1
TITLE : DATA
SUBTITLE: SACK containing Cumulative TSN less than the Cumulative TSN
Ack point.
PURPOSE: To check that if a SACK containing Cumulative TSN field less
than the current Cumulative TSN Ack point, then that SACK is discarded.
PRE-TEST CONDITION:Association is established between endpoint A and B.
Arrange data in endpoint A such that SACK chunk with cumulative TSN
less than the cumulative TSN ack point of endpoint B is sent to
endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<------------- Send
<----------------- DATA [ TSN = x]
SACK[CTSN = x] -----------------> <------------- Send
<----------------- DATA [TSN = x+1]
SACK[CTSN = x] ------------------>
SACK is dropped
TEST DESCRIPTION:
1. Send "send" primitive from ULP at endpoint B. DATA chunk will be
received at endpoint A. Sned SACK from endpoint B with cumulative
TSN which has already been acknowledged.
2. Check A: SACK will be dropped and endpoint B will not update any of
its parameter based on this SACK.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 145]
Internet Draft Conformance Test For SCTP Feb 2001
8.16 TSN missing in SACK which was previously acknowledged by SACK in
Gap Ack block
TEST NUMBER : 8.16
Reference: SCTP RFC 29606.2.1
TITLE : DATA
SUBTITLE : TSN missing in SACK which was previously acknowledged by
SACK in Gap Ack block.
PURPOSE: To verify that if SACK is missing a TSN that was previously
acked via a Gap Ack Block, then that data chunk is retransmitted and
T3-rxt timer is started for that destination address.
PRE-TEST CONDITION: Association is established between endpoint A and
B.Arrange data in endpoint A such that SACk is sent to endpoint B on
reception of DATA with Gap ACK block acknowledging data.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
<------------- Send
<----------------- DATA [TSN=1]
<------------- Send
<----------------- DATA [TSN=2]
<------------- Send
<----------------- DATA [TSN=3]
SACK[CTSN=1, ----------------->
Gap Start=2, end=2] <------------- Send
<----------------- DATA [TSN=4]
SACK[CTSN=2, ----------------->
Gap Start =2 end =3] <-------------- Send
<----------------- DATA [TSN=5]
SACK[CTSN=1, ----------------->
Gap Start=2, end=4] <------------- Send
<----------------- DATA [TSN=6]
SACK[CTSN=2, ----------------->
Gap Start =2 end =5]
<----------------- Retransmit
DATA [TSN=2]
SACK[TSN=2] ------------------>
TEST DESCRIPTION:
1. Send "send" primitive from ULP to send DATA message from endpoint B
to A. Send two or three DATA messages. Send SACK from endpoint A
acknowledging TSN 1 and 3. Send one more data from endpoint B to A.
Send SACK this time acknowledging upto 2 and not three.
2. Check A: DATA with TSN 2 should be retransmitted.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 146]
Internet Draft Conformance Test For SCTP Feb 2001
9 Acknowledgement
9.1 NORMAL ACKNOWLEDGE
TEST NUMBER : 9.1
Reference: SCTP RFC 2960 Clause 3.3.3 and 6.2.1
TITLE : Acknowledgement
SUBTITLE : Normal Acknowledge
PURPOSE : To verify that SCTP receiver B acknowledge the SCTP sender A
about the reception of each data chunk
PRE-TEST CONDITIONS: : Arrange the data such that endpoint A send one
TSN and wait for SACK
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA ----------------->
[TSN=1] Data Arrive ------->
<----------------- SACK
[TSN ACK=1,Frag=0]
DATA ----------------->
[TSN=2] Data Arrive ------->
<---------------- SACK
TEST DESCRIPTION:
1. Check that TSN ACK value is same as TSN sent by endpoint A
2. Check that endpoint B is sending SACK before T3-rtx timer expires.
3. Check that all the messages are received correctly. (No loss of
messages.)
4. A SACK chunk can acknowledge the reception of multiple data chunk
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 147]
Internet Draft Conformance Test For SCTP Feb 2001
9.2 DELAYED ACKNOWLEDGE
TEST NUMBER : 9.2
Reference: SCTP RFC 2960 Clause 6.2.1
TITLE : Acknowledgement
SUBTITLE : Delayed Acknowledge
PURPOSE : To verify that SCTP receiver B can acknowledge the SCTP
sender A about the reception of multiple data chunk
PRE-TEST CONDITIONS: Arrange the Endpoint A such that it sends multiple
DATA is chunks before receiving SACK
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA [TSN=1] -----------------> --------->
DATA [TSN=2] -----------------> --------->
<----------------- SACK
[TSN ACK=2,Frag=0]
TEST DESCRIPTION:
1. Check that endpoint B is sending SACK before T3-rtx timer expires.
2. Check that SACK chunk can acknowledge the reception of multiple data
chunk.
3. Check that , before a sender transmits a data packet if any
received data chunk have not been acknowledged ( due to delay Ack)
the sender should create a SACK and bundle it with outbound data
chunk (this test assumes that endpoint shall ack atleast every
second datagram).
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 148]
Internet Draft Conformance Test For SCTP Feb 2001
9.3 CUMULATIVE TSN ACK
TEST NUMBER : 9.3
Reference: SCTP RFC 2960 Clause 6.2.1
TITLE : SACK
SUBTITLE : cumulative TSN ACK
PURPOSE: To check that if receiver detects gap in the received data
chunk sequence, and SACK with fragment report shall be sent back
immediately.
PRE-TEST CONDITION: Arrange the segmented data such that endpoint B
receive gap in DATA
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
DATA [TSN=1] -----------------> Data Arrive ------>
<----------------- SACK
DATA [TSN=2] -----------------> Data Arrive ------->
(Skip TSN 3 )
DATA [TSN=4] -----------------> (TNS 3 lost ,gap detected
immediately send ACK)
-----------------> SACK
[TSN ACK=2,Frag=1,
Strt=2,End=2]
TEST DESCRIPTION:
1. Check that if receiver detects gap in the received data chunk
sequence, and SACK with fragment report shall be sent back
immediately.
2. Check that receiver hold or deliver data to ULP as per ordered or
un-ordered delivery bit.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 149]
Internet Draft Conformance Test For SCTP Feb 2001
10 Miscellaneous Test Case
10.1 CHUNK TYPE Encoding
TEST NUMBER : 10.1
Reference: SCTP RFC 2960 Clause 3.2
TITLE : Miscellaneous Test Case
SUBTITLE: Chunk type encoding.
PURPOSE: To verify that if a chunk type is not recognized by the
receiver then the highest order 2 bits decide the action that must
be taken.
PRE-TEST CONDITIONS: Association is not established between endpoint
A and B.Arrange the data in endpoint B such that a datagram with
reserved chunk type is sent to endpoint A bundled with DATA chunk in
any state and higher two bytes are set to 11.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ----------------->
<----------------- INIT_ACK
COOKIE-ECHO ------------------>
<------------------ COOKIE_ACK
Communication Up -------->
Chunk type 20 + DATA ------------------>
<------------------ ERROR
<------------------ SACK
DATA ------------------->
<------------------ SACK
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 150]
Internet Draft Conformance Test For SCTP Feb 2001
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. In the
established state send a datagram with reserved chunk type bundled
with DATA. Highest order two bits have been set to 11 in the
reserved chunk type.
2. Check A: Datgram with reserved chunk type is discarded and SACK is
sent for the DATA chunk.
3. Check B: ERROR is also received at endpoint A with cause
"Unrecognized Chunk type".
4. Check B: Association is not disturbed.
5. Repeat the above test case if highest order two bits are 00. In this
case, neither ERROR nor SACK will be received at endpoint A and
whole datagram will be discarded.
6. Repeat the above test case if highest order two bits are 01. In this
case, SACK will not be received at endpoint A but ERROR with cause
"Unrecognized Chunk Type" will be received at endpoint A and whole
datagram will be discarded.
7. Repeat the above test case if highest order two bits are 10. In this
case, ERROR will not be received at endpoint A but SACK will be
received at endpoint A.
8. Repeat the above test case for reserved chunk type in other state
like Cookie Wait, Cookie Echoed, Shutdown Sent, Shutdown received,
Shutdown pending and Shutdown-Ack sent. In each state bundle the
appropriate chunk type with reserved chunk type i.e. chunk type
which is allowed in each state.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 151]
Internet Draft Conformance Test For SCTP Feb 2001
10.2 Parameter Type Encoding
TEST NUMBER : 10.2
Reference: SCTP RFC 2960 Clause 3.2
TITLE : Miscellaneous Test Case
SUBTITLE: Parameter type encoding.
PURPOSE: To verify that if a parameter type is not recognized by the
receiver then the highest order 2 bits decide the action that must be
taken.
PRE-TEST CONDITIONS: Association is not established between endpoint A
and B. Arrange the data in endpoint B such that INIT message with
optional parameter which is not defined for INIT is sent from endpoint
A to B. The highest order two bits of parameter type is 11.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Closed) (Closed)
INIT ------------------>
<------------------ INIT-ACK(with Unrecognized
Parameter type)
COOKIE-ECHO ------------------->
<------------------- COOKIE_ACK
Communication Up ----------->
TEST DESCRIPTION:
1. Attempt to initiate an association from endpoint A to B. Send INIT
message with one optional parameter which is not defined in INIT.The
highest order two bits in that parameter should be 11.
2. Check A: That parameter is skipped and INIT-ACK is received at
endpoint A.
3. Check B: Unrecognized parameter type in INIT-ACK contains the
parameter which was not recognized at endpoint B.
4. Repeat the above test case if highest order two bits are 00. In this
case INIT chunk will be discarded.
5. Repeat the above test case if highest order two bits are 01. In this
case, INIT will be discarded but ERROR with cause "Unrecognized
Parameter Type" will be received at endpoint A.
6. Repeat the above test case if highest order two bits are 10. In this
case, INIT-ACK will be received at endpoint A without unrecognized
parameter type.
7. Repeat the above test case for undefined parameter type in INIT-ACK
message. Response will be same.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 152]
Internet Draft Conformance Test For SCTP Feb 2001
11 Retransmission Timer
11.1 RTO is incremented if T3-rxt expires for DATA chunk(Single IP
address)
TEST NUMBER : 11.1
Reference: SCTP RFC 2960 Clause 6.3.3
TITLE : Retransmission Timer
SUBTITLE: RTO is incremented if T3-rxt expires for a DATA chunk
PURPOSE: To verify that if T3-rxt expires on a destination address then
value of RTO is increased for that address.
PRE-TEST CONDITIONS:Association is established between endpoint A and
B.Arrange the data in endpoint A such that SACK is not sent for the
data received from endpoint B.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-----------------Send
<------------------ DATA
Don't send SACK |
| T3-rxt timer expires
|
<------------------ DATA
Don't send SACK |
|
| T3-rxt timer expires
|
<------------------ DATA
TEST DESCRIPTION:
1. Attempt to send DATA from endpoint B to A. Don't send SACK from A.
Let the timer T3-rxt expire. DATA will be retransmitted. Note the
timer. Don't send SACK for the retransmitted DATA. T3-rxt will be
expired again and again DATA will be retransmitted.
Record the messages using a signal emulator.
2. Check A: Value of the second T3-rxt is greater than the first.
Note:Exact calculation of RTO is not tested here. Only it is tested
that it is being incremented.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 153]
Internet Draft Conformance Test For SCTP Feb 2001
11.2 RTO is incremented if T3-rxt expires for DATA chunk(Multiple IP
addresses)
TEST NUMBER : 11.2
Reference: SCTP RFC 2960 Clause 6.3.3
TITLE : Retransmission Timer
SUBTITLE: RTO is incremented if T3-rxt expires for a DATA chunk
PURPOSE: To verify that if T3-rxt expires on a destination address then
value of RTO is increased for that address.
PRE-TEST CONDITIONS: Association is established between endpoint A
(With IP addresses x and y and Port z) and B. Arrange the data in
endpoint A such that SACK is not sent for the data received.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------- Send
<------------------ DATA (IP = x)
Don't send SACK |
| T3-rxt timer expires
<------------------ DATA (IP = y)
Don't send SACK |
| T3-rxt timer expires
|
<------------------ DATA (IP = x)
Don't send SACK |
| T3-rxt timer expires
|
<------------------ DATA (IP = y)
TEST DESCRIPTION:
1. Attempt to send DATA from endpoint B to A. Don't send SACK from A.
Let the timer T3-rxt expire. DATA will be retransmitted on an
alternate address. Don't send SACK for it also. Now DATA will again
be retransmitted on IP address on which it was initially sent. Don't
send SACK for it and let T3- rxt expire. Note the timer value.Record
the messages using a signal emulator.
2. Check A: Value of the second T3-rxt is greater than the first for IP
address x.
Note: Endpoint B may be having association with more than two IP
addresses. Each time data will be retransmitted on an alternate address
and when DATA has been retransmitted on all addresses then again it
will be retransmitted on the IP address on which it was initially sent.
Note1: Exact calculation of RTO is not tested here. Only it is tested
that it is being incremented.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 154]
Internet Draft Conformance Test For SCTP Feb 2001
11.3 When DATA is retransmitted to an alternate address then RTO
value corresponding to that address is used.
TEST NUMBER : 11.3
Reference: SCTP RFC 2960 Clause 6.3.3
TITLE : Retransmission Timer
SUBTITLE: When DATA is retransmitted to an alternate address then RTO
value corresponding to that address is used.
PURPOSE: To verify that if DATA is retransmitted on an alternate
address hen RTO value of that address is used and not that of the
previous address.
PRE-TEST CONDITIONS: Association is established between endpoint A
(With IP addresses x and y and Port z) and B. Arrange the data in
endpoint A such that SACK is not sent for the data received. Before
sending the DATA note the T3-rxt value corresponding to both IP
addresses.
EXPECTED MESSAGE SEQUENCE :
Endpoint A Endpoint B ULP
(Established) (Established)
<-------------------Send
<------------------ DATA (IP = x)
Don't send SACK |
| T3-rxt timer expires
<------------------ DATA (IP = y)
Don't send SACK |
| T3-rxt timer expires
|
<------------------ DATA (IP = x)
TEST DESCRIPTION:
1. Attempt to send DATA from endpoint B to A. Don't send SACK from A.
Let the timer T3-rxt Expire. Note this value. DATA will be
retransmitted on an alternate address. Don't send SACK for it Also.
Let T3-rxt expire.
Note the timer value again.
Record the messagesusing a signal emulator.
2. Check A: Value of the second T3-rxt is that corresponding to the IP
address Y.
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 155]
Internet Draft Conformance Test For SCTP Feb 2001
7. Acknowledgement
Authors are highly greatful to Sunil , Harsh and all the members of
VoIP-Stacks group members at Hughes Software Systems . Authors are
thankful to all the members of SIGTRAN mailing list who have floated
their comments on the drafts of SCTP , making it more transparent for
better understanding.
8. Authors Address
Sunil, Sandeep,Kuleep,Ashok
email: hsssigtran@hss.hns.com
Hughes Software Systems
Plot#31, Sector 18
Electronic City
Gurgaon, Haryana
INDIA - 122015
Tel# +91-124-6346666 , 6455 5555
Fax# +91-124- 634 6530
9. References
[1] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Scharzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson
Simple Control Transmission Protocol RFC 2960
Sunil, Sandeep,Kuleep,Ashok , Hughes Software Systems [Page 156]
