Stream Control Transmission Protocol
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:
- Dynamic addressing (RFC 5061).
- 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.
- socket()
- Create SCTP sockets.
- setsockopt() and getsockopt()
- 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.