FM_UnSegDataMTU.seq - Un-Fragment DATA is send if the data size equal to the current MTU
To check that if the data size equal to the current MTU then the
endpoint should send Un-segmented user message.
./FM_UnSegDataMTU.seq [-tooloption ...] -pkt ./FM_UnSegDataMTU.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Association established between endpoint A and B. Also arrange the
data in endpoint B such that DATA message with data size equal to
the current MTU is sent to endpoint A.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----- Send
<----------------- DATA
(B Bit =1, E Bit = 1, size=MTU)
SACK ----------------->
TEST DESCRIPTION:
1. Send DATA message from endpoint B to A with data size equal to
the current MTU.
2. Check that the B bit is 1 for message received at endpoint A a
un-segmented data.
3. Check that the E bit is 1 for message received at endpoint A a
un-segmented data.
None
RFC 4960
6.9. Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but
it MUST support reassembly when receiving DATA chunks. If an
endpoint supports fragmentation, it MUST fragment a user message if
the size of the user message to be sent causes the outbound SCTP
packet size to exceed the current MTU. If an implementation does not
support fragmentation of outbound user messages, the endpoint MUST
return an error to its upper layer and not attempt to send the user
message.
Note: If an implementation that supports fragmentation makes
available to its upper layer a mechanism to turn off fragmentation,
it may do so. However, in so doing, it MUST react just like an
implementation that does NOT support fragmentation, i.e., it MUST
reject sends that exceed the current Path MTU (P-MTU).
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed
in Section 10.1 would need to return an error to the upper layer.
If its peer is multi-homed, the endpoint shall choose a size no
larger than the association Path MTU. The association Path MTU is
the smallest Path MTU of all destination addresses.
Note: Once a message is fragmented, it cannot be re-fragmented.
Instead, if the PMTU has been reduced, then IP fragmentation must be
used. Please see Section 7.3 for details of PMTU discovery.
When determining when to fragment, the SCTP implementation MUST take
into account the SCTP packet header as well as the DATA chunk
header(s). The implementation MUST also take into account the space
required for a SACK chunk if bundling a SACK chunk with the DATA
chunk.
Fragmentation takes the following steps:
1) The data sender MUST break the user message into a series of DATA
chunks such that each chunk plus SCTP overhead fits into an IP
datagram smaller than or equal to the association Path MTU.
2) The transmitter MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series. The transmitter assigns
the same SSN to each of the DATA chunks. If the user indicates
that the user message is to be delivered using unordered
delivery, then the U flag of each DATA chunk of the user message
MUST be set to 1.
3) The transmitter MUST also set the B/E bits of the first DATA
chunk in the series to '10', the B/E bits of the last DATA chunk
in the series to '01', and the B/E bits of all other DATA chunks
in the series to '00'.
An endpoint MUST recognize fragmented DATA chunks by examining the
B/E bits in each of the received DATA chunks, and queue the
fragmented DATA chunks for reassembly. Once the user message is
reassembled, SCTP shall pass the reassembled user message to the
specific stream for possible reordering and final dispatching.
Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the reassembly of the message,
it should dispatch part of its inbound message through a partial
delivery API (see Section 10), freeing some of its receive buffer
space so that the rest of the message may be received.