Stream Control Transmission Protocol
The protocol was defined by the IETF Signaling Transport working group in 2000, and is maintained by the IETF Transport Area (TSVWG) working group. RFC 4960 defines the protocol. RFC 3286 provides an introduction.
In the absence of native SCTP support in operating systems it is possible to tunnel SCTP over UDP, as well as mapping TCP API calls to SCTP ones.
SCTP applications submit their data to be transmitted in messages to the SCTP transport layer. SCTP places messages and control information into separate chunks (data chunks and control chunks), each identified by a chunk header. The protocol can fragment a message into a number of data chunks, but each data chunk contains data from only one user message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol, consists of a packet header, SCTP control chunks (when necessary), followed by SCTP data chunks (when available).
SCTP may be characterized as message-oriented, meaning it transports a sequence of messages, rather than transporting an unbroken stream of bytes as does TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.
The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting web page images together with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages rather than bytes.
TCP preserves byte order in the stream by assigning a sequence number to each packet. SCTP, on the other hand, assigns a sequence number to each message sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order of receipt instead of the order they were sent.
The designers of SCTP originally intended it for the transport of telephony over Internet Protocol, 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).
Each chunk has a type identifier that is one byte long yielding, at most, 255 different chunk types. RFC 4960 defines a list of chunk types and there are currently 15 types defined. The remainder of the chunk is a two byte length and the data. If the chunk does not form a multiple of 4 bytes (i.e., the length isn't a multiple of 4) then it is implicitly padded with zeros which aren't included in the chunk length.
Although encryption wasn't part of the original SCTP design, SCTP was designed with features for improved security, such as 4-way handshake to protect against SYN flooding attacks, and large "cookies" for association verification and authenticity.
Reliability was also a key part of the security design of SCTP. Multihoming enables an association to stay open even when some routes and interfaces are down. This is of particular importance for SIGTRAN as it carries SS7 over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.
SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP support enabled, and, as it isn't as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.
The SCTP reference implementation runs on FreeBSD, Mac OS X, Windows, Linux.
Related Sites for Stream Control Transmission Protocol
- Streamyx Broadband Promo read Stream Control Transmission Protocol
- RFC 2960: Stream Control Transmission Protocol - The RFC Archive read Stream Control Transmission Protocol
- RFC 4960: Stream Control Transmission Protocol - The RFC Archive read Stream Control Transmission Protocol
- The Transmission Control Protocol - DePaul University read Stream Control Transmission Protocol
0 Response to "Stream Control Transmission Protocol is ..."
Post a Comment