SCTP ( Stream Control Transmission Protocol )

• Acknowledged error-free non-duplicated transfer of user data.


• Data fragmentation to conform to discovered path MTU size.


• Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages.


• Optional bundling of multiple user messages into a single SCTP packet.


• Network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

                   SCTP User Application

         -----------------------------------------------------

          _____________                  ____________________

         |             |                | Sequenced delivery |

         | Association |                |   within streams   |

         |             |                |____________________|

         |   startup   |

         |             |         ____________________________

         |     and     |        |    User Data Fragmentation |

         |             |        |____________________________|

         |   takedown  |

         |             |         ____________________________

         |             |        |     Acknowledgement        |

         |             |        |          and               |

         |             |        |    Congestion Avoidance    |

         |             |        |____________________________|

         |             |

         |             |         ____________________________

         |             |        |       Chunk Bundling       |

         |             |        |____________________________|

         |             |

         |             |     ________________________________

         |             |    |      Packet Validation         |

         |             |    |________________________________|

         |             |

         |             |     ________________________________

         |             |    |     Path Management            |

         |_____________|    |________________________________|

• Association Startup and Takedown
  An association is initiated by a request from the SCTP user. A cookie mechanism is employed during the initialization to provide protection against security attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup.
  
  SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP user. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT primitive) or as a result of an error condition detected within the SCTP layer.
  
  SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close.



• Sequenced Delivery within Streams
  The term "stream" is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document a byte is assumed to be eight bits).
  
  The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end. User messages are associated with stream numbers (send, receive primitives). Internally, SCTP assigns a stream sequence number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed.
  
  SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received.



• User Data Fragmentation
  When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user.



• Acknowledgement and Congestion Avoidance
  SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any stream sequence number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery.
  
  The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP.



• Chunk Bundling
  The SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user messages into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.
  
  During times of congestion an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission.



• Packet Validation
  A mandatory Verification Tag field and a 32 bit checksum field are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association.



• Path Management
  The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user.
  
  At association start-up, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets.
  
  On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
  
  Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items.

• Source Port Number
  This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.



• Destination Port Number
  This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.



• Verification Tag
  The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.
  
  For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.



• Checksum
  Contains the checksum of this SCTP packet. SCTP uses the Adler-32 algorithm for calculating the checksum.

• Chunk Type
  Identifies the type of information contained in the Chunk data. The value of 255 is reserved for future use as an extension field.
  
  Chunk types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Chunk type.


• 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.


• 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).


• 10 - Skip this chunk and continue processing.


• 11 - Skip this chunk and continue processing, but report in an ERROR Chunk using the 'Unrecognized Chunk Type' cause of error.

The total length of a chunk MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.



Chunk type	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, Reserved for Explicit Congestion Notification Echo.
13	CWR, Reserved for Congestion Window Reduced.
14	SHUTDOWN COMPLETE, Shutdown Complete.
15-191
192	Forward TSN.
193-255




• Chunk Flags
  The usage of these bits depends on the chunk type as given by the Chunk Type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt.



• Chunk Length
  This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding.



• Chunk Value
  The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.

Example 1: Normal Association Establishment



In the following example, "A" initiates the association and then sends a user message 

to "Z", then "Z" sends two user messages to "A" later (assuming no bundling or 

fragmentation occurs):



          Endpoint A                                          Endpoint Z

          {app sets association with Z}

          (build TCB)

          INIT [I-Tag=Tag_A

                & other info]  --------

          (Start T1-init timer)         

          (Enter COOKIE-WAIT state)      ---> (compose temp TCB and Cookie_Z)



                                          /--- INIT ACK [Veri Tag=Tag_A,

                                         /              I-Tag=Tag_Z,

          (Cancel T1-init timer) <------/               Cookie_Z, & other info]

                                               (destroy temp TCB)

          COOKIE ECHO [Cookie_Z] ------

          (Start T1-init timer)         

          (Enter COOKIE-ECHOED state)    ---> (build TCB enter ESTABLISHED state)



                                         /---- COOKIE-ACK

                                        /

          (Cancel T1-init timer, <-----/

           Enter ESTABLISHED state)

          {app sends 1st user data; strm 0}

          DATA [TSN=initial TSN_A

              Strm=0,Seq=1 & user data]--

           (Start T3-rtx timer)            

                                            ->

                                        /----- SACK [TSN Ack=init

                                                    TSN_A,Block=0]

          (Cancel T3-rtx timer) <------/



                                               ...

                                               {app sends 2 messages;strm 0}

                                         /---- DATA

                                        /        [TSN=init TSN_Z

                                    <--/          Strm=0,Seq=1 & user data 1]

          SACK [TSN Ack=init TSN_Z,      /---- DATA

                Block=0]     --------  /        [TSN=init TSN_Z +1,

                                      /          Strm=0,Seq=2 & user data 2]

                               <------/

                                        

                                         ------>



If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the 

same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State 

Cookie shall be retransmitted and the timer restarted. This shall be repeated 

Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure 

to its upper layer (and thus the association enters the CLOSED state).

Example 2: Association Restart



In the following example, "A" initiates the association after a restart has 

occurred. Endpoint "Z" had no knowledge of the restart until the exchange 

(i.e. Heartbeats had not yet detected the failure of "A"). (assuming no 

bundling or fragmentation occurs):



          Endpoint A                                          Endpoint Z

          <-------------- Association is established---------------------->

          Tag=Tag_A                                             Tag=Tag_Z

          <--------------------------------------------------------------->

          {A crashes and restarts}

          {app sets up a association with Z}

          (build TCB)

          INIT [I-Tag=Tag_A'

                & other info]  --------

          (Start T1-init timer)         

          (Enter COOKIE-WAIT state)      ---> (find a existing TCB

                                                compose temp TCB and Cookie_Z

                                                with Tie-Tags to previous

                                                association)

                                          /--- INIT ACK [Veri Tag=Tag_A',

                                         /               I-Tag=Tag_Z',

          (Cancel T1-init timer) <------/                Cookie_Z[TieTags=

                                                         Tag_A,Tag_Z

                                                          & other info]

                                               (destroy temp TCB,leave original in place)

          COOKIE ECHO [Veri=Tag_Z',

                       Cookie_Z

                       Tie=Tag_A,

                       Tag_Z]----------

          (Start T1-init timer)         

          (Enter COOKIE-ECHOED state)    ---> (Find existing association,

                                                Tie-Tags match old tags,

                                                Tags do not match i.e.

                                                case X X M M above,

                                                Announce Restart to ULP

                                                and reset association).

                                         /---- COOKIE-ACK

                                        /

          (Cancel T1-init timer, <-----/ Enter ESTABLISHED state)

          {app sends 1st user data; strm 0}

          DATA [TSN=initial TSN_A

               Strm=0,Seq=1 & user data]--

          (Start T3-rtx timer)            

                                           ->

                                        /----- SACK [TSN Ack=init TSN_A,Block=0]

          (Cancel T3-rtx timer) <------/

■ Parent layer
■ Child layer

IP

SCTP