SCTP association startup and shutdown

Edit online

SCTP association startup and shutdown guidelines are described here.

SCTP association is comprised of a four way handshake that takes place in the following order:

  1. The client sends an INIT signal to the server to initiate an association.
  2. On receipt of the INIT signal, the server sends an INIT-ACK response to the client. This INIT-ACK signal contains a state cookie. This state cookie must contain a Message Authentication Code (MAC), along with a time stamp corresponding to the creation of the cookie, the life span of the state cookie, and the information necessary to establish the association. The MAC is computed by the server based on a secret key only known to it.
  3. On receipt of this INIT-ACK signal, the client sends a COOKIE-ECHO response, which just echoes the state cookie.
  4. After verifying the authenticity of the state cookie using the secret key, the server then allocates the resources for the association, sends a COOKIE-ACK response acknowledging the COOKIE-ECHO signal, and moves the association to ESTABLISHED state.

SCTP supports also graceful close of an active association upon request from the SCTP user. The following sequence of events occurs:

  1. The client sends a SHUTDOWN signal to the server, which tells the server that the client is ready to close the connection.
  2. The server responds by sending a SHUTDOWN-ACK acknowledgement.
  3. The client then sends a SHUTDOWN-COMPLETE signal back to the server.

SCTP also supports abrupt close (ABORT signal) of an active association upon the request from the SCTP client or due to an error in the SCTP stack. However, SCTP does not support half open connections. More information about the protocol and its internals can be found in RFC 4960.

In addition to the differences specified above between SCTP and existing transport protocols, SCTP provides the following features:
  • Sequenced delivery within streams: A stream in SCTP context refers to a sequence of user messages that are transferred between endpoints. An SCTP association can support multiple streams. At the time of association setup, the user can specify the number of streams. The effective value of number of stream is fixed after negotiating with the peer. Within each stream the order of data delivery is strictly maintained. However across the streams data delivery is independent. Thus, the loss of data from one stream does not prevent data from being delivered in another stream. This allows a user application to use different streams for logically independent data. Data can also be delivered in an unordered fashion using a special option. This can be useful to send urgent data.
  • User data fragmentation: SCTP can fragment user messages to ensure that the packet size passed to the lower layer does not exceed the path MTU. At the time of receipt the fragments are reassembled into a complete message and passed to the user. Although fragmentation can also be performed at the network level, transport-layer fragmentation provides various advantages over IP-layer fragmentation. Some of these advantages including not having to re-send entire messages when fragments are lost in the network and reducing the burden on routers, which would otherwise possibly have to perform IP fragmentation.
  • Acknowledgment and Congestion Control: Packet acknowledgment is necessary for reliable data delivery. When SCTP does not get a acknowledgment for a packet it sends within a specified time, it triggers a retransmission of the same packet. SCTP follows congestion control algorithms similar to those used by TCP. In addition to using cumulative acknowledgements like TCP, SCTP uses Selective Acknowledgment (SACK) mechanism which allows it to acknowledge packets selectively.
  • Chunk bundling: A chunk may contain user data or SCTP control information. Multiple chunks can be bundled together under the same SCTP header. Chunk bundling requires assembly of chunks into SCTP packet at the sending end and subsequently disassembly of the packet into chunks at the receiver end.
  • Packet validation: Each SCTP packet has a verification tag field that is set during the time of association startup by each endpoint. All packets are sent with the same verification tag through the lifetime of the association. If, during the lifetime of the association, a packet is received with an unexpected verification tag, the packet is discarded. Also the CRC-32 checksum should be set by sender of each SCTP packet to provide increased protection for the data corruption in the network. Any packet received with an invalid CRC-32 checksum is discarded.
  • Path management: At the time of association setup, each endpoint may advertise the list of transport addresses it has. However only one primary path is defined for the SCTP association and is used for the normal data transfer. In case the primary path goes down, the other transport addresses are used. During the lifetime of the association, heartbeats are sent at regular interval through all the paths to monitor the status of the path.