AbortInShutPend.seq - ABORT chunk is received in SHUTDOWN-PENDING State
To check that receiving ABORT message in SHUTDOWN-PENDING State can
terminate an association.
./AbortInShutPend.seq [-tooloption ...] -pkt ./AbortInShutPend.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Association is established between endpoint A and B. Arrange
the data in endpoint A such that an ABORT message is sent to
endpoint B.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<---------------- DATA
<----- Terminate
ABORT -----------------> Association is removed
Communication Lost --------->
TEST DESCRIPTION:
1. Attempt to terminate an association between endpoint A and endpoint
B by sending ABORT message.
2. Check A: No Acknowledgement is sent for the ABORT message and
association is removed.
3. Check B: ULP are reported of the association closure.
None
RFC 4960
9.1. Abort of an Association
When an endpoint decides to abort an existing association, it MUST
send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. If the association is aborted
on request of the upper layer, a User-Initiated Abort error cause
(see Section 3.3.10.12) SHOULD be present in the ABORT chunk.
An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT MUST apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint MUST
remove the association from its record and SHOULD report the
termination to its upper layer. If a User-Initiated Abort error
cause is present in the ABORT chunk, the Upper Layer Abort Reason
SHOULD be made available to the upper layer.