NAME

  FM_UnSegDataMTU.seq - Un-Fragment DATA is send if the data size equal to the current MTU


PURPOSE

  To check that if the data size equal to the current MTU then the
  endpoint should send Un-segmented user message.


SYNOPSIS

  ./FM_UnSegDataMTU.seq [-tooloption ...] -pkt ./FM_UnSegDataMTU.def
    -tooloption : v6eval tool option
  See Also: ../common/STD_PKT_COMMON.def
            ../common/SCTP_COMMON.def


PRE-TEST CONDITION

  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.


TEST PROCEDURE

  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.


NOTE

  None


REFERENCE

  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.