From Free net encyclopedia
Internet protocol suite
| Layer
| Protocols
|
| Application
| DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, TELNET, BitTorrent, RTP, rlogin, ENRP, …
|
| Transport
| TCP, UDP, DCCP, SCTP, IL, RUDP, …
|
| Network
| IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, …
|
| Link
| Ethernet, Wi-Fi, Token ring, PPP, SLIP, FDDI, ATM, DTM, Frame Relay, SMDS, …
|
The Stream Control Transmission Protocol (SCTP) is a transport layer protocol defined in 2000 by the IETF Signaling Transport (SIGTRAN) working group. The protocol is defined in RFC 2960, and an introductory text is provided by RFC 3286.
As a transport protocol, SCTP is equivalent in a sense to TCP or UDP. Indeed it provides some similar services as TCP — ensuring reliable, in-sequence transport of messages with congestion control. (In the absence of native SCTP support, it may sometimes be desirable to tunnel SCTP over UDP.)
Message-based Multi-streaming
One of the key differences between TCP & SCTP is that TCP transports a byte-stream while SCTP is capable of transporting multiple message-streams. All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step.
Multi-streaming refers to the capability of SCTP to transmit several independent streams of messages in parallel. For example, transmitting two images in a HTTP application in parallel over the same SCTP association. You might think of multi-streaming as bundling several TCP-connections in one SCTP-association operating with messages instead of bytes.
TCP ensures byte order by conceptually assigning a sequence number to each byte sent and ordering these bytes based on that sequence number when they arrive. SCTP, instead, assigns different sequence numbers on messages sent in a stream. This allows messages in different streams to be ordered independently. However, message ordering is optional in SCTP. If the user application so desires, messages will be processed in the order they are received instead of the order they were sent, should these differ.
Message-based delivery is one of the requirements for PSTN signaling. Multi-Streaming also is an advantage when used to transport Public Switched Telephone Networks Services. If an SCTP connection is set up to carry, say, ten phone calls with one call per stream, then if a single message is lost in only one phone call, the other nine calls will not be affected. To handle ten phone calls in TCP, some form of multiplexing would be required to put all ten phone calls into a single byte-stream. If a single packet for phone call #3 is lost then all packets after that could not be processed until the missing bytes are retransmitted, thus causing unnecessary delays in the other calls.
Benefits
Benefits of SCTP are:
- Multihoming support, where one (or both) endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between hosts or network cards.
- Delivery of data in chunks within independent streams - Eliminates unnecessary head-of-line blocking, as opposed to TCP byte stream delivery.
- Path Selection and Monitoring - Selects a "primary" data transmission path and tests the connectivity of the transmission path.
- Validation and Acknowledgment mechanisms - Protects against flooding attacks and provides notification of duplicated or missing data chunks.
SCTP was originally intended for the transport of telephony (SS7) protocols over IP, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as SIGTRAN. In the meantime, other uses have been proposed, for example the DIAMETER protocol and Reliable server pooling (RSerPool).
Motivations
Transmission Control Protocol (TCP) has been the primary means to transfer data across the internet in a reliable way.
However, several applications have been limited by TCP.
From RFC 2960:
- TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases the head-of-line blocking offered by TCP causes unnecessary delay.
- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts.
- TCP is relatively vulnerable to denial of service attacks, such as SYN attacks.
These limitations are all limitations that affect the performance of using IP for public switched telephone networks.
Implementations
SCTP is implemented in the following Operating Systems:
Various third-party implementations are available for other operating systems.
Packet structure
| Bits
| Bits 0 - 7
| 8 - 15
| 16 - 23
| 24 - 31
|
| +0
| Source port
| Destination port
|
| 32
| Verification tag
|
| 64
| Checksum
|
| 96
| Chunk 1 type
| Chunk 1 flags
| Chunk 1 length
|
| 128
| Chunk 1 data
|
| …
| …
|
| …
| Chunk N type
| Chunk N flags
| Chunk N length
|
| …
| Chunk N data
|
|
The basic structure of an SCTP packet is simpler than that of TCP and UDP. It consists of two basic sections:
- The common header, which occupies the first 12 bytes and is highlighted in blue, and
- The data chunks, which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighted in red.
Common header
The common header is required for all SCTP packets and is shown with the blue background.
- Source port
- This field identifies the sending port.
- Destination port
- This field identifies the receiving port that the hosts uses to route the packet to the appropriate endpoint/application.
- Verification tag
- A 32-bit random value created during initialization to determine stale packets from a previous connection.
- Checksum
- SCTP was originally designed to use Adler-32 but was changed (RFC 3309) to use the CRC32 algorithm.
Chunks
Each SCTP packet consists, in addition to the common header, of chunks.
Each chunk has a common format, but the contents can vary.
One chunk is display in the diagram to the right with the green background.
- Chunk type
- An 8-bit value predefined by the IETF to identify the contents of the chunk value field.
- Chunk flags
- Eight flag bits whose definition varies with the chunk type. The default value is zero.
- Chunk length
- A 16-bit unsigned value specifying the total length of the chunk in bytes (excludes any padding) that includes chunk type, flags, length, and value fields.
- Chunk value
- General purpose data field whose definition varies with the chunk type.
If the chunk length is not a multiple of 4 bytes then padding of zeros are implicitly added after the chunk value.
Optional/variable-length parameter defintion
| +
| Bits 0 - 15
| 16 - 31
|
| 0
| Parameter type
| Parameter length
|
| 32
| Parameter value
|
|
Additionally, each chunk type may define a set of parameters that are included inside the chunk value field (and, consequently, their length in the chunk length).
There are two types of parameters:
- fixed parameters – they must appear and in the order specified
- variable-length or optional parameters – they appear after the fixed parameters and may appear in any order and in any number.
For optional/variable-length paramters, the parameter type, parameter length, and parameter value fields all behave just like their chunk counterparts.
The minimum size of parameter is 4 bytes and this occurs when the parameter value field is empty and the parameter consists only of the type & length fields.
Chunk types
The following is a list of predefined chunk types as provided in RFC 2960.
Following this table each chunk and its parameters are defined. Please note the following color scheme:
- gray: chunk fields
- red: fixed parameters
- green/blue: optional/variable-length parameters that alternate colors
| Value | Abbreviation | Description
|
| 0 | DATA | Payload data
|
| 1 | INIT | Initiation
|
| 2 | INIT ACK | initiation acknowledgement
|
| 3 | SACK | Selective acknowledgement
|
| 4 | HEARTBEAT | Heartbeat request
|
| 5 | HEARTBEAT ACK | Heartbeat acknowledgement
|
| 6 | ABORT | Abort
|
| 7 | SHUTDOWN | Shutdown
|
| 8 | SHUTDOWN ACK | Shutdown acknowledgement
|
| 9 | ERROR | Operation error
|
| 10 | COOKIE ECHO | State cookie
|
| 11 | COOKIE ACK | Cookie acknowledgement
|
| 12 | ECNE | Explicit congestion notification echo (reserved)
|
| 13 | CWR | Congestion window reduced (reserved)
|
| 14 | SHUTDOWN COMPLETE | Shutdown complete
|
| 15-62 | N/A | Reserved by IETF
|
| 63 | IETF-defined chunk extensions
|
| 64-126 | Reserved by IETF
|
| 127 | IETF-defined chunk extensions
|
| 128-190 | Reserved by IETF
|
| 191 | IETF-defined chunk extensions
|
| 192-254 | Reserved by IETF
|
| 255 | IETF-defined chunk extensions
|
DATA chunk
| +
| Bits 0 - 7
| 8 - 12
| 13
| 14
| 15
| 16 - 31
|
| 0
| Chunk type = 0
| Reserved
| U
| B
| E
| Chunk length
|
| 32
| TSN
|
| 64
| Stream identifier
| Stream sequence number
|
| 96
| Payload protocol identifier
|
| 128
|
Data
|
|
- Chunk type
- For payload data (DATA), this value is always zero.
- Chunk flags
- There are currently only 3 flags used
- U – If set, this indicates this data is an unordered chunk and the stream sequence number is invalid. If an unordered chunk is fragmented then each fragment has this flag set.
- B – If set, this marks the beginning fragment. An unfragmented chunk has this flag set.
- E – If set, this marks the end fragment. An unfragmented chunk has this flag set.
- Chunk length
- This is the chunk length which has a minimum value of 16 when chunk value is empty.
- Fixed parameters:
- Transmission sequence number (TSN)
- The sequence number for the entire DATA stream that is used in fragmentation for reassembly.
- Stream identifier
- Identifier of the stream that this data chunk belongs to
- Stream sequence number
- Identifier of the sequence number of for the message in this stream. If a message is fragmented then this value is maintained for all fragments.
- Payload protocol identifier
- Application-specific protocol identifier. SCTP makes no use of this or modification of it. However, devices along the path or the endpoints may use it.
- Data
- Application-specific data.
- Optional parameters: none.
INIT chunk
| +
| Bits 0 - 7
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 1
| Chunk flags
| Chunk length
|
| 32
| Initiate tag
|
| 64
| Advertised receiver window credit
|
| 96
| # of outbound streams
| # of inbound streams
|
| 128
| Initial TSN
|
| 160
| Parameter type = 5
| Parameter length = 8
|
| 192
| IPv4 address of sending endpoint
|
| 224
| Parameter type = 6
| Paremeter length = 20
|
| 256
| IPv6 address of sending endpoint
|
| 288
|
| 320
|
| 352
|
| 384
| Parameter type = 9
| Parameter length = 8
|
| 416
| Suggested cookie life-span increment (milliseconds)
|
| 448
| Parameter type = 11
| Parameter length
|
| 480
| Null-terminated host name
|
| 512
| Parameter type = 12
| Parameter length
|
| 544
| Address type #1
| Address type #2
|
| 576
| Address type #3
| ...
|
| 608
| Parameter type = 32768
| Parameter length
|
| 640
| Explicit congention notification (reserved)
|
|
- Chunk type
- For initiation (INIT), this value is always one.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a minimum value of 20 when chunk value is empty and no optional parameters are used
- Fixed parameters have identical meaning as INIT ACK:
- Initiate tag
- Unsigned 32-bit number that is used in every SCTP packet in the verification tag within the common header.
- Advertised receiver window credit (a_rwnd)
- Amount of dedicated buffer space for this association that should never be reduced.
- # of outbound streams
- Number of outbound streams (from the sender of the INIT) it wishes to use for this association. Zero is an invalid value and the receiver should ABORT the association upon receiving a zero.
- # of inbound streams
- Identical to # of outbound streams but number of inbound streams. No negotiation takes place on the established number but the minimum of requested and offered should be used.
- Initial TSN
- Initial transmission sequence number to be used and may be any value.
- Optional parameters are shown with alternating background colors of green and blue:
- Parameter type = 5
- This parameter lists all the IPv4 addresses used at the sending endpoint. If it is a multihomed connection then the IP address of each may be included.
- Parameter type = 6
- This parameter lists all the IPv6 addresses used at the sending endpoint. If it is a multihomed connection then the IP address of each may be included.
- Parameter type = 9
- This parameter provides a suggested life-span increment the receiver should add to its default cookie life-span (in milliseconds).
- Parameter type = 11
- This parameter is a hostname as defined in RFC 1123, section 2.1. Actual resolution of this name is outside the scope of SCTP. Additionally, a null terminating character must be included and must be included in the parameter length.
- Parameter type = 12
- This parameter lists the address types the sender supports (e.g., IPv4 = 5, IPv6 = 6, hostname = 11).
- Parameter type = 32768
- This parameter is reserved for explicit congestion notification support.
INIT ACK chunk
The INIT ACK chunk is identical to the INIT chunk except the chunk type is always 2.
- Mandatory parameters, only in INIT ACK:
- State Cookie
- The state cookie holds the minimal information to recreate the Transmission Control Block, and is signed with the senders private key.
SACK chunk
| +
| Bits 0 - 7
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 3
| Chunk flags
| Chunk length
|
| 32
| Cumulative TSN ACK
|
| 64
| Advertised receiver window credit
|
| 96
| Number of gap ACK blocks = N
| Number of duplicate TSNs = X
|
| 128
| Gap ACK block #1 start
| Gap ACK block #1 end
|
| ...
| ...
| ...
|
| 96+N*32
| Gap ACK block #N start
| Gap ACK block #N end
|
| 128+N*32
| Duplicate TSN #1
|
| ...
| ...
|
| 96+N*32+X*32
| Duplicate TSN #X
|
|
- Chunk type
- For initiation (SACK), this value is always three.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a minimum value of 16 when no gaps or duplicates are sent.
- Fixed parameters:
- Cumulative TSN ACK
- Acknowledges all sequence numbers received in sequence so is the sequence number of the last received byte. The immediate value after this one has not been received yet.
- Advertised receiver window credit
- Amount of dedicated buffer space for this association that should never be reduced.
- Number of gap ACK blocks
- Indicates the number of gap ACK block start and gap ACK block end pairs included.
- Number of duplicate TSNs
- Indicates the number of duplicate TSNs the endpoint has received.
- Optional parameters are shown with alternating background colors of green and blue:
- Gap ACK block #n start
- Indicates the TSN (added to the cumulative TSN ACK) of a block of TSNs to acknowledge.
- Gap ACK block #n end
- Indicates the TSN (added to the cumulative TSN ACK) of a block of TSNs to acknowledge.
- Duplicate TSN #x
- A TSN that was received more than once. A TSN will appear in this list for each time it is received after the first time.
HEARTBEAT chunk
| +
| Bits 0 - 7
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 4
| Chunk flags
| Chunk length
|
| 32
| Parameter type = 1
| Parameter length
|
| 64+
| Heartbeat info
|
|
- Chunk type
- For heartbeat (HEARTBEAT), this value is always four.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a minimum value of 8 with no parameter value added.
- Fixed parameters: None
- Optional parameters are shown with alternating background colors of green and blue:
- Parameter type = 1
- This parameter contains the sender-specific heartbeat info
HEARTBEAT ACK chunk
| +
| Bits 0 - 7
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 5
| Chunk flags
| Chunk length
|
| 32
| Parameter type = 1
| Parameter length
|
| 64+
| Heartbeat info
|
|
- Chunk type
- For heartbeat acknowledgement (HEARTBEAT ACK), this value is always five.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a minimum value of 8 with no parameter value added.
- Fixed parameters: None
- Optional parameters are shown with alternating background colors of green and blue:
- Parameter type = 1
- This parameter contains the sender-specific heartbeat info received in the request.
ABORT chunk
| +
| Bits 0 - 6
| 8 - 14
| 15
| 16 - 31
|
| 0
| Chunk type = 6
| Reserved
| T
| Chunk length
|
| 32
| Zero or more error causes
|
|
- Chunk type
- For abort (ABORT), this value is always six.
- Chunk flags
- There is currently only one flag used:
- T
- Set if the sender didn't have a TCB; not set if the sender had one (that it destroyed).
- Chunk length
- This is the chunk length which has a minimum value of 4 with no error causes given.
- Optional parameters (the error causes) are defined in the ERROR chunk.
SHUTDOWN chunk
| +
| Bits 0 - 6
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 7
| Chunk flags
| Chunk length
|
| 32
| Zero or more error causes
|
|
- Chunk type
- For shutdown (SHUTDOWN), this value is always seven.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a fixed length of 8.
- Fixed parameters:
- Cumulative TSN ACK
- Contains the last TSN received in sequence by the sender.
SHUTDOWN ACK chunk
| +
| Bits 0 - 6
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 8
| Chunk flags
| Chunk length = 4
|
| 32
| Zero or more error causes
|
|
- Chunk type
- For shutdown acknowledgement (SHUTDOWN ACK), this value is always eight.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a fixed length of 4.
ERROR chunk
| +
| Bits 0 - 7
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 9
| Chunk flags
| Chunk length
|
| 32
| Parameter type = 1
| Parameter length = 8
|
| 64
| Stream identifier
| Zeros (reserved)
|
| 96
| Parameter type = 2
| Parameter length
|
| 128
| Number of missing parameters = N
|
| 160
| Missing parameter type #1
| Missing parameter type #2
|
| 192
| ...
| Missing parameter type #N
|
| 224
| Parameter type = 3
| Parameter length = 8
|
| 256
| Measure of staleness (microseconds)
|
| 288
| Parameter type = 4
| Parameter type = 4
|
| 320
| Parameter type = 5
| Parameter length
|
| 352
| Unresolvable address
|
| 384
| Parameter type = 6
| Parameter length
|
| 416
| Unrecognized chunk
|
| 448
| Parameter type = 7
| Parameter length 4
|
| 480
| Parameter type = 8
| Parameter length
|
| 512
| Unrecognized parameters
|
| 544
| Parameter type = 9
| Parameter length = 8
|
| 576
| TSN value
|
| 608
| Parameter type = 10
| Parameter length = 4
|
|
- Chunk type
- For error (ERROR), this value is always nine.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length which has a minimum value of 8 when only one error is sent with no parameter value. The size is 4 bytes plus the size of all error causes.
- Fixed parameters: None.
- Optional parameters are shown with alternating background colors of green and blue:
- Parameter type = 1
- This parameter identifies that the sender received a stream identifier that is invalid.
- Parameter type = 2
- This parameter indicates that the sender received an INIT or INIT ACK chunk with missing mandatory parameters.
- Parameter type = 3
- This parameter indicates receipt of a valid state cookie but it was stale by a given number of microseconds.
- Parameter type = 4
- This parameter indicates the sender is out of resources; this usually accompanies an ABORT chunk.
- Parameter type = 5
- This parameter identifies an address that the sender could not resolve (possibly because it does not support the address type); this usually accompanies an ABORT chunk.
- Parameter type = 6
- This parameter identifies an unrecognized chunk when the chunk type's most-significant bytes are 01 or 11.
- Parameter type = 7
- This parameter identifies a mandatory parameter in an INIT or INIT ACK chunk has an invalid value.
- Parameter type = 8
- This parameter is directed to the originator of an INIT ACK chunk that contained an unrecognized parameter.
- Parameter type = 9
- This parameter indicates a DATA chunk contained no user data; this usually accompanies an ABORT chunk.
- Parameter type = 10
- This parameter indicates the sender received a COOKIE ECHO while the endpoint was in a SHUTDOWN-ACK-SENT state.
COOKIE ECHO chunk
| +
| Bits 0 - 6
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 10
| Chunk flags
| Chunk length
|
| 32+
| Cookie
|
|
- Chunk type
- For cookie echo (COOKIE ECHO), this value is always ten.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length.
- Chunk value
- Contains the cookie data.
COOKIE ACK chunk
| +
| Bits 0 - 6
| 8 - 15
| 16 - 31
|
| 0
| Chunk type = 11
| Chunk flags
| Chunk length = 4
|
|
- Chunk type
- For cookie acknowledgement (COOKIE ACK), this value is always eleven.
- Chunk flags
- There are currently no flags used.
- Chunk length
- This is the chunk length and is always 4.
ECNE chunk
Not defined yet.
CWR chunk
Not defined yet.
SHUTDOWN COMPLETE chunk
| +
| Bits 0 - 6
| 8 - 14
| 15
| 16 - 31
|
| 0
| Chunk type = 14
| Reserved
| T
| Chunk length = 4
|
|
- Chunk type
- For shutdown complete (SHUTDOWN COMPLETE), this value is always fourteen.
- Chunk flags
- There is currently only one flag defined
- T
- Set if the sender didn't have a TCB; not set if the sender had one (that it destroyed).
- Chunk length
- This is the chunk length which has a fixed length of 4.
External links
RFCs
de:Stream Control Transmission Protocol
es:Stream Control Transmission Protocol
fr:Stream Control Transmission Protocol
it:Stream Control Transmission Protocol
he:Stream Control Transmission Protocol
nl:Stream Control Transmission Protocol
ja:Stream Control Transmission Protocol
nn:Stream Control Transmission Protocol
pl:SCTP
pt:Stream Control Transmission Protocol
ru:SCTP
zh:SCTP