Stream Control Transmission Protocol

Jump to: navigation, search

Table of Contents >> Optional Protocols


(The following paragraphs have been copied from the SCTP(4) FreeBSD manpage.)

The Stream Control Transmission Protocol (SCTP) provides reliable, flow-controlled, two-way transmission of data. It is a message oriented protocol and can support the SOCK_STREAM and SOCK_SEQPACKET abstractions. SCTP uses the standard Internet address format and, in addition, provides a per-host collection of port addresses. Thus, each address is composed of an Internet address specifying the host and network, with a specific SCTP port on the host identifying the peer entity.

There are two models of programming in SCTP. The first uses the SOCK_STREAM abstraction. In this abstraction sockets utilizing the SCTP protocol are either active or passive. Active sockets initiate connections to passive sockets. By default, SCTP sockets are created active; to create a passive socket, the listen() system call must be used after binding the socket with the bind() or sctp_bindx() system calls. Only passive sockets may use the accept() call to accept incoming connections. Only active sockets may use the connect() call to initiate connections.

The other abstraction SOCK_SEQPACKET provides a connectionless mode of operation in that the user may send to an address (using any of the valid send calls that carry a socket address) and an association will be setup implicitly by the underlying SCTP transport stack. This abstraction is the only one capable of sending data on the third leg of the four-way handshake. A user must still call listen() to allow the socket to accept connections. Calling listen() however does not restrict the user from still initiating implicit connections to other peers.

The SCTP protocol directly supports multi-homing. So when binding a socket with the wildcard address INADDR_ANY, the SCTP stack will inform the peer about all of the local addresses that are deemed in scope of the peer. The peer will then possibly have multiple paths to reach the local host.

The SCTP transport protocol is also multi-streamed. Multi-streaming refers to the ability to send sub-ordered flows of messages. A user performs this by specifying a specific stream in one of the extended send calls such as the sctp_send() function call. Sending messages on different streams will allow parallel delivery of data i.e., a message loss in stream 1 will not block the delivery of messages sent in stream 2.

The SCTP transport protocol also provides an unordered service as well. The unordered service allows a message to be sent and delivered with no regard to the ordering of any other message.


Treck SCTP Implementation

Treck supports a subset of SCTP that includes the SOCK_STREAM abstraction. The SOCK_SEQPACKET abstraction and unordered service are not currently supported. IPv6 is not supported at this time because of multi-homed routing complexities.

Treck supports the following SCTP extensions:

This extension allows addresses to be dynamically added to and deleted from an existing association.

The following items in RFC 4960 are not supported:

  • Multiple associations per SCTP instance.
Treck supports one association per SCTP socket or instance.
  • Multiple inbound and outbound streams.
Treck supports one inbound and one outbound stream per socket.
  • Chunk bundling on send.
Received bundled chunks are supported.
  • Association restart (the peer crashed and restarted).
The association will be aborted.
  • User event notification.
  • Handling ICMP responses (host unreachable, etc.).
Retransmissions will continue up to the maximum allowed.
  • Network Management (SNMP).


Public API

SCTP applications use the standard Treck sockets API for establishing a connection with a remote endpoint. For the most part, the application should be unaware that SCTP is the transport layer. The following standard Treck sockets functions have support for SCTP:

New functions have been added specifically for SCTP:

Initialize the Treck SCTP package.
Stop the Treck SCTP package and free all resources.

The following existing functions have been updated to support SCTP:

You can limit the allocation of SCTP sockets.
Create SCTP sockets.
Dynamically add and delete IP addresses for existing SCTP connections.

SCTP Configuration Macros (view all macros)

  • TM_USE_SCTP
Define this macro to enable support for SCTP. This is a prerequisite for all macros that follow.
Default: undefined.
  • TM_SCTP_FAVOR_PRIMARY_PATH
Define this macro to always use the primary path when it is available. The primary path is the path that was used when the connection was established. If this is undefined, data will continue to be sent on the current path even after the primary path becomes usable again.
Default: undefined.
  • TM_SCTP_ADDIP_ENABLE
Define this macro to enable support for RFC 5061 (dynamic address reconfiguration). If you define this macro, you must also define either TM_SCTP_AUTH_ENABLE or TM_SCTP_ADDIP_NOAUTH_ENABLE.
Default: undefined.
  • TM_SCTP_ADDIP_NOAUTH_ENABLE
Define this macro to allow dynamic address reconfiguration to operate without authentication (in violation of RFC 5061). This may be required to interoperate with older SCTP implementations.
Default: undefined.
  • TM_SCTP_AUTH_ENABLE
Define this macro to enable SCTP chunk authentication RFC 4895.
Default: undefined.
  • TM_SCTP_AUTH_HMAC_ALG
Define the authentication method to use for signing the server state cookie. You may use MD5, SHA-1 or SHA-256.
Valid Options: SCTP_AUTH_HMAC_MD5, SCTP_AUTH_HMAC_SHA1 or SCTP_AUTH_HMAC_SHA256.
Default: SCTP_AUTH_HMAC_SHA1.
  • TM_SCTP_SERVER_DISABLE
Define this macro to exclude the SCTP server code. This can reduce the code size for SCTP client applications.
Default: undefined.
  • TM_SCTP_FAST_REXMIT_DISABLE
Define this macro to exclude the SCTP fast retransmission code. This can reduce the code size by a small amount.
Default: undefined.
  • TM_DISABLE_TCP
Define this macro to exclude the TCP code. This can reduce the code size for applications that use SCTP exclusively.
Default: undefined.
  • TM_SCTP_DEF_RTO_INITIAL
Initial retransmission timeout (RTO.Initial) in milliseconds.
Default: 3s.
  • TM_SCTP_DEF_RTO_MIN
Minimum retransmission timeout (RTO.Min) in milliseconds.
Default: 1s.
  • TM_SCTP_DEF_RTO_MAX
Maximum retransmission timeout (RTO.Max) in milliseconds.
Default: 60s.
  • TM_SCTP_DEF_MAX_BURST
Maximum number of packets to send in one shot.
Default: 4 packets.
  • TM_SCTP_DEF_RTO_ALPHA
RTO Calculation variable 'Alpha' (RTO.Alpha) in thousandths.
Default: 125.
  • TM_SCTP_DEF_RTO_BETA
RTO Calculation variable 'Beta' (RTO.Beta) in thousandths.
Default: 250.
  • TM_SCTP_DEF_COOKIE_LIFE
Cookie lifetime (Valid.Cookie.Life) in milliseconds.
Default: 60s.
  • TM_SCTP_DEF_ASSOC_MAX_RETRANS
Maximum number of consecutive retransmissions (Association.Max.Retrans) before declaring association failure.
Default: 10.
  • TM_SCTP_DEF_PATH_MAX_RETRANS
Maximum number of consecutive retransmissions (Path.Max.Retrans) before declaring path failure.
Default: 5.
  • TM_SCTP_DEF_PATH_HIGH_RETRANS
High water mark on number of consecutive retransmissions before changing paths.
Default: 2.
  • TM_SCTP_DEF_MAX_INIT_RETRANS
Maximum number of consecutive INIT or COOKIE-ECHO retransmissions (Max.Init.Retransmits) before declaring failure.
Default: 8.
  • TM_SCTP_DEF_HB_INTERVAL
Interval for HEARTBEAT transmissions (HB.interval) in milliseconds.
Default: 30s.
  • TM_SCTP_DELAY_ACK_TIME
Delayed acknowledgement timeout in milliseconds.
Default: 200ms.
  • TM_SCTP_ACK_STATE_THRESH
The number of unacknowledged data chunks to receive before sending an acknowledgement.
Default: 2.
  • TM_SCTPVECT_MAX_COUNT
Maximum number of sockets SCTP is permitted to consume.
Default: TM_SOC_INDEX_MAX (all sockets).
  • TM_SCTP_SECRET_SIZE
Size (in bytes) of the secret used to authenticate a server state cookie.
Default: 16.
  • TM_SCTP_DEF_SECRET_LIFE_SEC
Secret lifetime in seconds, at which time a new secret will be generated.
Default: 600s.
  • TM_SCTP_MAPPING_ARRAY_MAX
Maximum number of entries in the TSN mapping array, which is used to indicate the data chunk sequence numbers that have been received.
Default: 512.
  • TM_SCTP_MAPPING_ARRAY_INITIAL
Initial number of entries in the TSN mapping array.
Default: 128.
  • TM_SCTP_MAPPING_ARRAY_INCR
Entry increment for growing the TSN mapping array.
Default: 128.
  • TM_SCTP_AUTH_MAX_SHARED_KEYS
Maximum number of endpoint pair shared keys.
Default: 1.


Table of Contents >> Optional Protocols