As per Relevance of the word association, we have this rfc below:
Network Working Group R.
Request for Comments: 2960 Q.
Category: Standards Track
K.
C.
H.
T.
Nortel
I.
M.
L.
V.
October 2000
Stream Control Transmission
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes the Stream Control Transmission
(SCTP). SCTP is designed to transport PSTN signaling messages
IP networks, but is capable of broader applications
SCTP is a reliable transport protocol operating on top of
connectionless packet network such as IP. It offers the
services to its users
-- acknowledged error-free non-duplicated transfer of user data
-- data fragmentation to conform to discovered path MTU size
Stewart, et al. Standards Track [Page 1]
RFC 2960 Stream Control Transmission Protocol October 2000
-- sequenced delivery of user messages within multiple streams
with an option for order-of-arrival delivery of individual
messages
-- optional bundling of multiple user messages into a single
packet,
-- network-level fault tolerance through supporting of multi
homing at either or both ends of an association
The design of SCTP includes appropriate congestion avoidance
and resistance to flooding and masquerade attacks
Stewart, et al. Standards Track [Page 2]
RFC 2960 Stream Control Transmission Protocol October 2000
Table of
1. Introduction.................................................. 5
1.1 Motivation.................................................. 6
1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP..................................... 7
1.3.1 Association Startup and Takedown........................ 8
1.3.2 Sequenced Delivery within Streams....................... 9
1.3.3 User Data Fragmentation................................. 9
1.3.4 Acknowledgement and Congestion Avoidance................ 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 Packet Validation....................................... 10
1.3.7 Path Management......................................... 11
1.4 Key Terms................................................... 11
1.5 Abbreviations............................................... 15
1.6 Serial Number Arithmetic.................................... 15
2. Conventions.................................................... 16
3. SCTP packet Format............................................ 16
3.1 SCTP Common Header Field Descriptions....................... 17
3.2 Chunk Field Descriptions.................................... 18
3.2.1 Optional/Variable-length Parameter Format............... 20
3.3 SCTP Chunk Definitions...................................... 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable Length Parameters.............. 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable Length Parameters.............. 33
3.3.4 Selective Acknowledgement (SACK)........................ 33
3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
3.3.7 Abort Association (ABORT)............................... 39
3.3.8 Shutdown Association (SHUTDOWN)......................... 40
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
3.3.10 Operation Error (ERROR)................................ 41
3.3.10.1 Invalid Stream Identifier.......................... 42
3.3.10.2 Missing Mandatory Parameter........................ 43
3.3.10.3 Stale Cookie Error................................. 43
3.3.10.4 Out of Resource.................................... 44
3.3.10.5 Unresolvable Address............................... 44
3.3.10.6 Unrecognized Chunk Type............................ 44
3.3.10.7 Invalid Mandatory Parameter........................ 45
3.3.10.8 Unrecognized Parameters............................ 45
3.3.10.9 No User Data....................................... 46
3.3.10.10 Cookie Received While Shutting Down............... 46
3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
4. SCTP Association State Diagram................................. 48
Stewart, et al. Standards Track [Page 3]
RFC 2960 Stream Control Transmission Protocol October 2000
5. Association Initialization..................................... 52
5.1 Normal Establishment of an Association...................... 52
5.1.1 Handle Stream Parameters................................ 54
5.1.2 Handle Address Parameters............................... 54
5.1.3 Generating State Cookie................................. 56
5.1.4 State Cookie Processing................................. 57
5.1.5 State Cookie Authentication............................. 57
5.1.6 An Example of Normal Association Establishment.......... 58
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO
and COOKIE ACK.............................................. 60
5.2.1 Handle Duplicate INIT in COOKIE-
or COOKIE-ECHOED States................................. 60
5.2.2 Unexpected INIT in States Other than CLOSED
COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
5.2.3 Unexpected INIT ACK..................................... 61
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
5.2.4.1 An Example of a Association Restart................. 64
5.2.5 Handle Duplicate COOKIE ACK............................. 66
5.2.6 Handle Stale COOKIE Error............................... 66
5.3 Other Initialization Issues................................. 67
5.3.1 Selection of Tag Value.................................. 67
6. User Data Transfer............................................. 67
6.1 Transmission of DATA Chunks................................. 69
6.2 Acknowledgement on Reception of DATA Chunks................. 70
6.2.1 Tracking Peer's Receive Buffer Space.................... 73
6.3 Management Retransmission Timer............................. 75
6.3.1 RTO Calculation......................................... 75
6.3.2 Retransmission Timer Rules.............................. 76
6.3.3 Handle T3-rtx Expiration................................ 77
6.4 Multi-homed SCTP Endpoints.................................. 78
6.4.1 Failover from Inactive Destination Address.............. 79
6.5 Stream Identifier and Stream Sequence Number................ 80
6.6 Ordered and Unordered Delivery.............................. 80
6.7 Report Gaps in Received DATA TSNs........................... 81
6.8 Adler-32 Checksum Calculation............................... 82
6.9 Fragmentation............................................... 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP Congestion Control................ 85
7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
7.2.1 Slow-Start.............................................. 87
7.2.2 Congestion Avoidance.................................... 89
7.2.3 Congestion Control...................................... 89
7.2.4 Fast Retransmit on Gap Reports.......................... 90
7.3 Path MTU Discovery.......................................... 91
8. Fault Management.............................................. 92
8.1 Endpoint Failure Detection.................................. 92
8.2 Path Failure Detection...................................... 92
Stewart, et al. Standards Track [Page 4]
RFC 2960 Stream Control Transmission Protocol October 2000
8.3 Path Heartbeat.............................................. 93
8.4 Handle "Out of the blue" Packets............................ 95
8.5 Verification Tag............................................ 96
8.5.1 Exceptions in Verification Tag Rules.................... 97
9. Termination of Association..................................... 98
9.1 Abort of an Association..................................... 98
9.2 Shutdown of an Association.................................. 98
10. Interface with Upper Layer....................................101
10.1 ULP-to-SCTP................................................101
10.2 SCTP-to-ULP................................................111
11. Security Considerations.......................................114
11.1 Security Objectives........................................114
11.2 SCTP Responses To Potential Threats........................115
11.2.1 Countering Insider Attacks.............................115
11.2.2 Protecting against Data Corruption in the Network......115
11.2.3 Protecting Confidentiality.............................115
11.2.4 Protecting against Blind Denial of Service Attacks.....116
11.2.4.1 Flooding...........................................116
11.2.4.2 Blind Masquerade...................................118
11.2.4.3 Improper Monopolization of Services................118
11.3 Protection against Fraud and Repudiation...................119
12. Recommended Transmission Control Block (TCB) Parameters.......120
12.1 Parameters necessary for the SCTP instance.................120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport Address Data.................................122
12.4 General Parameters Needed..................................123
13. IANA Considerations...........................................123
13.1 IETF-defined Chunk Extension...............................123
13.2 IETF-defined Chunk Parameter Extension.....................124
13.3 IETF-defined Additional Error Causes.......................124
13.4 Payload Protocol Identifiers...............................125
14. Suggested SCTP Protocol Parameter Values......................125
15. Acknowledgements..............................................126
16. Authors' Addresses............................................126
17. References....................................................128
18. Bibliography..................................................129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
1.
This section explains the reasoning behind the development of
Stream Control Transmission Protocol (SCTP), the services it offers
and the basic concepts needed to understand the detailed
of the protocol
Stewart, et al. Standards Track [Page 5]
RFC 2960 Stream Control Transmission Protocol October 2000
1.1
TCP [RFC793] has performed immense service as the primary means
reliable data transfer in IP networks. However, an increasing
of recent applications have found TCP too limiting, and
incorporated their own reliable data transfer protocol on top of
[RFC768]. The limitations which users have wished to bypass
the following
-- TCP provides both reliable data transfer and strict order-of
transmission delivery of data. Some applications need
transfer without sequence maintenance, while others would
satisfied with partial ordering of the data. In both of
cases the head-of-line blocking offered by TCP causes
delay
-- The stream-oriented nature of TCP is often an inconvenience
Applications must add their own record marking to delineate
messages, and must make explicit use of the push facility
ensure that a complete message is transferred in a
time
-- The limited scope of TCP sockets complicates the task
providing highly-available data transfer capability using multi
homed hosts
-- TCP is relatively vulnerable to denial of service attacks,
as SYN attacks
Transport of PSTN signaling across the IP network is an
for which all of these limitations of TCP are relevant. While
application directly motivated the development of SCTP,
applications may find SCTP a good match to their requirements
1.2 Architectural View of
SCTP is viewed as a layer between the SCTP user application ("
user" for short) and a connectionless packet network service such
IP. The remainder of this document assumes SCTP runs on top of IP
The basic service offered by SCTP is the reliable transfer of
messages between peer SCTP users. It performs this service
the context of an association between two SCTP endpoints. Section 10
of this document sketches the API which should exist at the
between the SCTP and the SCTP user layers
SCTP is connection-oriented in nature, but the SCTP association is
broader concept than the TCP connection. SCTP provides the means
each SCTP endpoint (Section 1.4) to provide the other
Stewart, et al. Standards Track [Page 6]
RFC 2960 Stream Control Transmission Protocol October 2000
(during association startup) with a list of transport
(i.e., multiple IP addresses in combination with an SCTP port
through which that endpoint can be reached and from which it
originate SCTP packets. The association spans transfers over all
the possible source/destination combinations which may be
from each endpoint's lists
_____________ _____________
| SCTP User | | SCTP User |
| Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node
Figure 1: An SCTP
1.3 Functional View of
The SCTP transport service can be decomposed into a number
functions. These are depicted in Figure 2 and explained in
remainder of this section
Stewart, et al. Standards Track [Page 7]
RFC 2960 Stream Control Transmission Protocol October 2000
SCTP User
-----------------------------------------------------
_____________ ____________________
| | | Sequenced delivery |
| Association | | within streams |
| | |____________________|
| startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport
1.3.1 Association Startup and
An association is initiated by a request from the SCTP user (see
description of the ASSOCIATE (or SEND) primitive in Section 10).
A cookie mechanism, similar to one described by Karn and Simpson
[RFC2522], is employed during the initialization to
protection against security attacks. The cookie mechanism uses
four-way handshake, the last two legs of which are allowed to
user data for fast setup. The startup sequence is described
Section 5 of this document
SCTP provides for graceful close (i.e., shutdown) of an
association on request from the SCTP user. See the description
the SHUTDOWN primitive in Section 10. SCTP also allows
close (i.e., abort), either on request from the user (
Stewart, et al. Standards Track [Page 8]
RFC 2960 Stream Control Transmission Protocol October 2000
primitive) or as a result of an error condition detected within
SCTP layer. Section 9 describes both the graceful and the
close procedures
SCTP does not support a half-open state (like TCP) wherein one
may continue sending data while the other end is closed. When
endpoint performs a shutdown, the association on each peer will
accepting new data from its user and only deliver data in queue
the time of the graceful close (see Section 9).
1.3.2 Sequenced Delivery within
The term "stream" is used in SCTP to refer to a sequence of
messages that are to be delivered to the upper-layer protocol
order with respect to other messages within the same stream. This
in contrast to its usage in TCP, where it refers to a sequence
bytes (in this document a byte is assumed to be eight bits).
The SCTP user can specify at association startup time the number
streams to be supported by the association. This number
negotiated with the remote end (see Section 5.1.1). User
are associated with stream numbers (SEND, RECEIVE primitives,
10). Internally, SCTP assigns a stream sequence number to
message passed to it by the SCTP user. On the receiving side,
ensures that messages are delivered to the SCTP user in
within a given stream. However, while one stream may be
waiting for the next in-sequence user message, delivery from
streams may proceed
SCTP provides a mechanism for bypassing the sequenced
service. User messages sent using this mechanism are delivered
the SCTP user as soon as they are received
1.3.3 User Data
When needed, SCTP fragments user messages to ensure that the
packet passed to the lower layer conforms to the path MTU.
receipt, fragments are reassembled into complete messages
being passed to the SCTP user
1.3.4 Acknowledgement and Congestion
SCTP assigns a Transmission Sequence Number (TSN) to each user
fragment or unfragmented message. The TSN is independent of
stream sequence number assigned at the stream level. The
Stewart, et al. Standards Track [Page 9]
RFC 2960 Stream Control Transmission Protocol October 2000
end acknowledges all TSNs received, even if there are gaps in
sequence. In this way, reliable delivery is kept
separate from sequenced stream delivery
The acknowledgement and congestion avoidance function is
for packet retransmission when timely acknowledgement has not
received. Packet retransmission is conditioned by
avoidance procedures similar to those used for TCP. See Sections 6
and 7 for a detailed description of the protocol
associated with this function
1.3.5 Chunk
As described in Section 3, the SCTP packet as delivered to the
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
user messages into a single SCTP packet. The chunk bundling
of SCTP is responsible for assembly of the complete SCTP packet
its disassembly at the receiving end
During times of congestion an SCTP implementation MAY still
bundling even if the user has requested that SCTP not bundle.
user's disabling of bundling only affects SCTP implementations
may delay a small period of time before transmission (to attempt
encourage bundling). When the user layer disables bundling,
small delay is prohibited but not bundling that is performed
congestion or retransmission
1.3.6 Packet
A mandatory Verification Tag field and a 32 bit checksum field (
Appendix B for a description of the Adler-32 checksum) are
in the SCTP common header. The Verification Tag value is chosen
each end of the association during association startup.
received without the expected Verification Tag value are discarded
as a protection against blind masquerade attacks and against
SCTP packets from a previous association. The Adler-32
should be set by the sender of each SCTP packet to provide
protection against data corruption in the network. The receiver
an SCTP packet with an invalid Adler-32 checksum silently
the packet
Stewart, et al. Standards Track [Page 10]
RFC 2960 Stream Control Transmission Protocol October 2000
1.3.7 Path
The sending SCTP user is able to manipulate the set of
addresses used as destinations for SCTP packets through
primitives described in Section 10. The SCTP path
function chooses the destination transport address for each
SCTP packet based on the SCTP user's instructions and the
perceived reachability status of the eligible destination set.
path management function monitors reachability through
when other packet traffic is inadequate to provide this
and advises the SCTP user when reachability of any far-end
address changes. The path management function is also
for reporting the eligible set of local transport addresses to
far end during association startup, and for reporting the
addresses returned from the far end to the SCTP user
At association start-up, a primary path is defined for each
endpoint, and is used for normal sending of SCTP packets
On the receiving end, the path management is responsible
verifying the existence of a valid SCTP association to which
inbound SCTP packet belongs before passing it for further processing
Note: Path Management and Packet Validation are done at the
time, so although described separately above, in reality they
be performed as separate items
1.4 Key
Some of the language used to describe SCTP has been introduced in
previous sections. This section provides a consolidated list of
key terms and their definitions
o Active destination transport address: A transport address on
peer endpoint which a transmitting endpoint considers
for receiving user messages
o Bundling: An optional multiplexing operation, whereby more
one user message may be carried in the same SCTP packet.
user message occupies its own DATA chunk
o Chunk: A unit of information within an SCTP packet, consisting
a chunk header and chunk-specific content
o Congestion Window (cwnd): An SCTP variable that limits the data
in number of bytes, a sender can send to a particular
transport address before receiving an acknowledgement
Stewart, et al. Standards Track [Page 11]
RFC 2960 Stream Control Transmission Protocol October 2000
o Cumulative TSN Ack Point: The TSN of the last DATA
acknowledged via the Cumulative TSN Ack field of a SACK
o Idle destination address: An address that has not had
messages sent to it within some length of time, normally
HEARTBEAT interval or greater
o Inactive destination transport address: An address which
considered inactive due to errors and unavailable to
user messages
o Message = user message: Data submitted to SCTP by the Upper
Protocol (ULP).
o Message Authentication Code (MAC): An integrity check
based on cryptographic hash functions using a secret key
Typically, message authentication codes are used between
parties that share a secret key in order to validate
transmitted between these parties. In SCTP it is used by
endpoint to validate the State Cookie information that is
from the peer in the COOKIE ECHO chunk. The term "MAC"
different meanings in different contexts. SCTP uses this
with the same meaning as in [RFC2104].
o Network Byte Order: Most significant byte first, a.k.a.,
Endian
o Ordered Message: A user message that is delivered in order
respect to all previous user messages sent within the stream
message was sent on
o Outstanding TSN (at an SCTP endpoint): A TSN (and the
DATA chunk) that has been sent by the endpoint but for which
has not yet received an acknowledgement
o Path: The route taken by the SCTP packets sent by one
endpoint to a specific destination transport address of its
SCTP endpoint. Sending to different destination
addresses does not necessarily guarantee getting separate paths
o Primary Path: The primary path is the destination and
address that will be put into a packet outbound to the
endpoint by default. The definition includes the source
since an implementation MAY wish to specify both destination
source address to better control the return path taken by
chunks and on which interface the packet is transmitted when
data sender is multi-homed
Stewart, et al. Standards Track [Page 12]
RFC 2960 Stream Control Transmission Protocol October 2000
o Receiver Window (rwnd): An SCTP variable a data sender uses
store the most recently calculated receiver window of its peer,
number of bytes. This gives the sender an indication of the
available in the receiver's inbound buffer
o SCTP association: A protocol relationship between SCTP endpoints
composed of the two SCTP endpoints and protocol state
including Verification Tags and the currently active set
Transmission Sequence Numbers (TSNs), etc. An association can
uniquely identified by the transport addresses used by
endpoints in the association. Two SCTP endpoints MUST NOT
more than one SCTP association between them at any given time
o SCTP endpoint: The logical sender/receiver of SCTP packets. On
multi-homed host, an SCTP endpoint is represented to its peers
a combination of a set of eligible destination transport
to which SCTP packets can be sent and a set of eligible
transport addresses from which SCTP packets can be received.
transport addresses used by an SCTP endpoint must use the
port number, but can use multiple IP addresses. A
address used by an SCTP endpoint must not be used by another
endpoint. In other words, a transport address is unique to
SCTP endpoint
o SCTP packet (or packet): The unit of data delivery across
interface between SCTP and the connectionless packet
(e.g., IP). An SCTP packet includes the common SCTP header
possible SCTP control chunks, and user data encapsulated
SCTP DATA chunks
o SCTP user application (SCTP user): The logical higher-
application entity which uses the services of SCTP, also
the Upper-layer Protocol (ULP).
o Slow Start Threshold (ssthresh): An SCTP variable. This is
threshold which the endpoint will use to determine whether
perform slow start or congestion avoidance on a
destination transport address. Ssthresh is in number of bytes
o Stream: A uni-directional logical channel established from one
another associated SCTP endpoint, within which all user
are delivered in sequence except for those submitted to
unordered delivery service
Note: The relationship between stream numbers in opposite
is strictly a matter of how the applications use them. It is
responsibility of the SCTP user to create and manage
correlations if they are so desired
Stewart, et al. Standards Track [Page 13]
RFC 2960 Stream Control Transmission Protocol October 2000
o Stream Sequence Number: A 16-bit sequence number used
by SCTP to assure sequenced delivery of the user messages within
given stream. One stream sequence number is attached to each
message
o Tie-Tags: Verification Tags from a previous association.
Tags are used within a State Cookie so that the newly
association can be linked to the original association within
endpoint that did not restart
o Transmission Control Block (TCB): An internal data
created by an SCTP endpoint for each of its existing
associations to other SCTP endpoints. TCB contains all the
and operational information for the endpoint to maintain
manage the corresponding association
o Transmission Sequence Number (TSN): A 32-bit sequence number
internally by SCTP. One TSN is attached to each chunk
user data to permit the receiving SCTP endpoint to acknowledge
receipt and detect duplicate deliveries
o Transport address: A Transport Address is traditionally
by Network Layer address, Transport Layer protocol and
Layer port number. In the case of SCTP running over IP,
transport address is defined by the combination of an IP
and an SCTP port number (where SCTP is the Transport protocol).
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the
DATA chunk) which has been received by the endpoint but for
an acknowledgement has not yet been sent. Or in the opposite case
for a packet that has been sent but no acknowledgement has
received
o Unordered Message: Unordered messages are "unordered" with
to any other message, this includes both other unordered
as well as other ordered messages. Unordered message might
delivered prior to or later than ordered messages sent on the
stream
o User message: The unit of data delivery across the
between SCTP and its user
o Verification Tag: A 32 bit unsigned integer that is
generated. The Verification Tag provides a key that allows
receiver to verify that the SCTP packet belongs to the
association and is not an old or stale packet from a
association
Stewart, et al. Standards Track [Page 14]
RFC 2960 Stream Control Transmission Protocol October 2000
1.5.
MAC - Message Authentication Code [RFC2104]
RTO - Retransmission Time-
RTT - Round-trip
RTTVAR - Round-trip Time
SCTP - Stream Control Transmission
SRTT - Smoothed
TCB - Transmission Control
TLV - Type-Length-Value Coding
TSN - Transmission Sequence
ULP - Upper-layer
1.6 Serial Number
It is essential to remember that the actual Transmission
Number space is finite, though very large. This space ranges from 0
to 2**32 - 1. Since the space is finite, all arithmetic dealing
Transmission Sequence Numbers must be performed modulo 2**32.
unsigned arithmetic preserves the relationship of sequence numbers
they cycle from 2**32 - 1 to 0 again. There are some subtleties
computer modulo arithmetic, so great care should be taken
programming the comparison of such values. When referring to TSNs
the symbol "=<" means "less than or equal"(modulo 2**32).
Comparisons and arithmetic on TSNs in this document SHOULD use
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is
than 2**31 - 1 above the beginning TSN of its current send window
Doing so will cause problems in comparing TSNs
Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
That is, the next TSN a DATA chunk MUST use after transmitting TSN =
2*32 - 1 is TSN = 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
Stewart, et al. Standards Track [Page 15]
RFC 2960 Stream Control Transmission Protocol October 2000
All other arithmetic and comparisons in this document uses
arithmetic
2.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL,
they appear in this document, are to be interpreted as described
[RFC2119].
3. SCTP packet
An SCTP packet is composed of a common header and chunks. A
contains either control information or user data
The SCTP packet format is shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple chunks can be bundled into one SCTP packet up to the
size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks
These chunks MUST NOT be bundled with any other chunk in a packet
See Section 6.10 for more details on chunk bundling
If a user data message doesn't fit into one SCTP packet it can
fragmented into multiple chunks using the procedure defined
Section 6.9.
All integer fields in an SCTP packet MUST be transmitted in
byte order, unless otherwise stated
Stewart, et al. Standards Track [Page 16]
RFC 2960 Stream Control Transmission Protocol October 2000
3.1 SCTP Common Header Field
SCTP Common Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer
This is the SCTP sender's port number. It can be used by
receiver in combination with the source IP address, the
destination port and possibly the destination IP address
identify the association to which this packet belongs
Destination Port Number: 16 bits (unsigned integer
This is the SCTP port number to which this packet is destined
The receiving host will use this port number to de-multiplex
SCTP packet to the correct receiving endpoint/application
Verification Tag: 32 bits (unsigned integer
The receiver of this packet uses the Verification Tag to
the sender of this SCTP packet. On transmit, the value of
Verification Tag MUST be set to the value of the Initiate
received from the peer endpoint during the
initialization, with the following exceptions
- A packet containing an INIT chunk MUST have a zero
Tag
- A packet containing a SHUTDOWN-COMPLETE chunk with the T-
set MUST have the Verification Tag copied from the packet
the SHUTDOWN-ACK chunk
- A packet containing an ABORT chunk may have the
tag copied from the packet which caused the ABORT to be sent
For details see Section 8.4 and 8.5.
An INIT chunk MUST be the only chunk in the SCTP packet carrying it
Stewart, et al. Standards Track [Page 17]
RFC 2960 Stream Control Transmission Protocol October 2000
Checksum: 32 bits (unsigned integer
This field contains the checksum of this SCTP packet.
calculation is discussed in Section 6.8. SCTP uses the Adler
32 algorithm as described in Appendix B for calculating
3.2 Chunk Field
The figure below illustrates the field format for the chunks to
transmitted in the SCTP packet. Each chunk is formatted with a
Type field, a chunk-specific Flag field, a Chunk Length field, and
Value field
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer
This field identifies the type of information contained in
Chunk Value field. It takes a value from 0 to 254. The value
255 is reserved for future use as an extension field
The values of Chunk Types are defined as follows
ID Value Chunk
----- ----------
0 - Payload Data (DATA
1 - Initiation (INIT
2 - Initiation Acknowledgement (INIT ACK
3 - Selective Acknowledgement (SACK
4 - Heartbeat Request (HEARTBEAT
5 - Heartbeat Acknowledgement (HEARTBEAT ACK
6 - Abort (ABORT
7 - Shutdown (SHUTDOWN
8 - Shutdown Acknowledgement (SHUTDOWN ACK
9 - Operation Error (ERROR
10 - State Cookie (COOKIE ECHO
11 - Cookie Acknowledgement (COOKIE ACK
12 - Reserved for Explicit Congestion Notification Echo (ECNE
13 - Reserved for Congestion Window Reduced (CWR
Stewart, et al. Standards Track [Page 18]
RFC 2960 Stream Control Transmission Protocol October 2000
14 - Shutdown Complete (SHUTDOWN COMPLETE
15 to 62 - reserved by
63 - IETF-defined Chunk
64 to 126 - reserved by
127 - IETF-defined Chunk
128 to 190 - reserved by
191 - IETF-defined Chunk
192 to 254 - reserved by
255 - IETF-defined Chunk
Chunk Types are encoded such that the highest-order two bits
the action that must be taken if the processing endpoint does
recognize the Chunk Type
00 - Stop processing this SCTP packet and discard it, do not
any further chunks within it
01 - Stop processing this SCTP packet and discard it, do not
any further chunks within it, and report the
parameter in an 'Unrecognized Parameter Type' (in either
ERROR or in the INIT ACK).
10 - Skip this chunk and continue processing
11 - Skip this chunk and continue processing, but report in an
Chunk using the 'Unrecognized Chunk Type' cause of error
Note: The ECNE and CWR chunk types are reserved for future use
Explicit Congestion Notification (ECN).
Chunk Flags: 8
The usage of these bits depends on the chunk type as given by
Chunk Type. Unless otherwise specified, they are set to zero
transmit and are ignored on receipt
Chunk Length: 16 bits (unsigned integer
This value represents the size of the chunk in bytes including
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields
Therefore, if the Chunk Value field is zero-length, the
field will be set to 4. The Chunk Length field does not count
padding
Stewart, et al. Standards Track [Page 19]
RFC 2960 Stream Control Transmission Protocol October 2000
Chunk Value: variable
The Chunk Value field contains the actual information to
transferred in the chunk. The usage and format of this field
dependent on the Chunk Type
The total length of a chunk (including Type, Length and Value fields
MUST be a multiple of 4 bytes. If the length of the chunk is not
multiple of 4 bytes, the sender MUST pad the chunk with all
bytes and this padding is not included in the chunk length field
The sender should never pad with more than 3 bytes. The
MUST ignore the padding bytes
SCTP defined chunks are described in detail in Section 3.3.
guidelines for IETF-defined chunk extensions can be found in
13.1 of this document
3.2.1 Optional/Variable-length Parameter
Chunk values of SCTP control chunks consist of a chunk-type-
header of required fields, followed by zero or more parameters.
optional and variable-length parameters contained in a chunk
defined in a Type-Length-Value format as shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Parameter Type: 16 bits (unsigned integer
The Type field is a 16 bit identifier of the type of parameter
It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions.
other than those defined in specific SCTP chunk description
reserved for use by IETF
Stewart, et al. Standards Track [Page 20]
RFC 2960 Stream Control Transmission Protocol October 2000
Chunk Parameter Length: 16 bits (unsigned integer
The Parameter Length field contains the size of the parameter
bytes, including the Parameter Type, Parameter Length,
Parameter Value fields. Thus, a parameter with a zero-
Parameter Value field would have a Length field of 4.
Parameter Length does not include any padding bytes
Chunk Parameter Value: variable-length
The Parameter Value field contains the actual information to
transferred in the parameter
The total length of a parameter (including Type, Parameter Length
Value fields) MUST be a multiple of 4 bytes. If the length of
parameter is not a multiple of 4 bytes, the sender pads the
at the end (i.e., after the Parameter Value field) with all
bytes. The length of the padding is not included in the
length field. A sender SHOULD NOT pad with more than 3 bytes.
receiver MUST ignore the padding bytes
The Parameter Types are encoded such that the highest-order two
specify the action that must be taken if the processing endpoint
not recognize the Parameter Type
00 - Stop processing this SCTP packet and discard it, do not
any further chunks within it
01 - Stop processing this SCTP packet and discard it, do not
any further chunks within it, and report the
parameter in an 'Unrecognized Parameter Type' (in either
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing
11 - Skip this parameter and continue processing but report
unrecognized parameter in an 'Unrecognized Parameter Type' (
either an ERROR or in the INIT ACK).
The actual SCTP parameters are defined in the specific SCTP
sections. The rules for IETF-defined parameter extensions
defined in Section 13.2.
3.3 SCTP Chunk
This section defines the format of the different SCTP chunk types
Stewart, et al. Standards Track [Page 21]
RFC 2960 Stream Control Transmission Protocol October 2000
3.3.1 Payload Data (DATA) (0)
The following format MUST be used for the DATA chunk
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5
Should be set to all '0's and ignored by the receiver
U bit: 1
The (U)nordered bit, if set to '1', indicates that this is
unordered DATA chunk, and there is no Stream Sequence
assigned to this DATA chunk. Therefore, the receiver MUST
the Stream Sequence Number field
After re-assembly (if necessary), unordered DATA chunks MUST
dispatched to the upper layer by the receiver without any
to re-order
If an unordered user message is fragmented, each fragment of
message MUST have its U bit set to '1'.
B bit: 1
The (B)eginning fragment bit, if set, indicates the first
of a user message
E bit: 1
The (E)nding fragment bit, if set, indicates the last fragment
a user message
Stewart, et al. Standards Track [Page 22]
RFC 2960 Stream Control Transmission Protocol October 2000
An unfragmented user message shall have both the B and E bits set
'1'. Setting both B and E bits to '0' indicates a middle fragment
a multi-fragment user message, as summarized in the following table
B E
============================================================
| 1 0 | First piece of a fragmented user message |
+----------------------------------------------------------+
| 0 0 | Middle piece of a fragmented user message |
+----------------------------------------------------------+
| 0 1 | Last piece of a fragmented user message |
+----------------------------------------------------------+
| 1 1 | Unfragmented Message |
============================================================
| Table 1: Fragment Description Flags |
============================================================
When a user message is fragmented into multiple chunks, the TSNs
used by the receiver to reassemble the message. This means that
TSNs for each fragment of a fragmented user message MUST be
sequential
Length: 16 bits (unsigned integer
This field indicates the length of the DATA chunk in bytes
the beginning of the type field to the end of the user data
excluding any padding. A DATA chunk with no user data field
have Length set to 16 (indicating 16 bytes).
TSN : 32 bits (unsigned integer
This value represents the TSN for this DATA chunk. The
range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps
to 0 after reaching 4294967295.
Stream Identifier S: 16 bits (unsigned integer
Identifies the stream to which the following user data belongs
Stream Sequence Number n: 16 bits (unsigned integer
This value represents the stream sequence number of the
user data within the stream S. Valid range is 0 to 65535.
When a user message is fragmented by SCTP for transport, the
stream sequence number MUST be carried in each of the fragments
the message
Stewart, et al. Standards Track [Page 23]
RFC 2960 Stream Control Transmission Protocol October 2000
Payload Protocol Identifier: 32 bits (unsigned integer
This value represents an application (or upper layer)
protocol identifier. This value is passed to SCTP by its
layer and sent to its peer. This identifier is not used by
but can be used by certain network entities as well as the
application to identify the type of information being carried
this DATA chunk. This field must be sent even in fragmented
chunks (to make sure it is available for agents in the middle
the network).
The value 0 indicates no application identifier is specified
the upper layer for this payload data
User Data: variable
This is the payload user data. The implementation MUST pad
end of the data to a 4 byte boundary with all-zero bytes.
padding MUST NOT be included in the length field. A sender
never add more than 3 bytes of padding
3.3.2 Initiation (INIT) (1)
This chunk is used to initiate a SCTP association between
endpoints. The format of the INIT chunk is shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless
noted, each parameter MUST only be included once in the INIT chunk
Stewart, et al. Standards Track [Page 24]
RFC 2960 Stream Control Transmission Protocol October 2000
Fixed Parameters
----------------------------------------------
Initiate Tag
Advertised Receiver Window Credit
Number of Outbound Streams
Number of Inbound Streams
Initial TSN
Variable Parameters Status Type
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Cookie Preservative Optional 9
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Supported Address Types (Note 4) Optional 12
Note 1: The INIT chunks can contain multiple addresses that can
IPv4 and/or IPv6 in any combination
Note 2: The ECN capable field is reserved for future use of
Congestion Notification
Note 3: An INIT chunk MUST NOT contain more than one Host
address parameter. Moreover, the sender of the INIT MUST NOT
any other address types with the Host Name address in the INIT.
receiver of INIT MUST ignore any other address types if the Host
address parameter is present in the received INIT chunk
Note 4: This parameter, when present, specifies all the address
the sending endpoint can support. The absence of this
indicates that the sending endpoint can support any address type
The Chunk Flags field in INIT is reserved and all bits in it
be set to 0 by the sender and ignored by the receiver. The
of parameters within an INIT can be processed in any order
Initiate Tag: 32 bits (unsigned integer
The receiver of the INIT (the responding end) records the value
the Initiate Tag parameter. This value MUST be placed into
Verification Tag field of every SCTP packet that the receiver
the INIT transmits within this association
The Initiate Tag is allowed to have any value except 0.
Section 5.3.1 for more on the selection of the tag value
Stewart, et al. Standards Track [Page 25]
RFC 2960 Stream Control Transmission Protocol October 2000
If the value of the Initiate Tag in a received INIT chunk is
to be 0, the receiver MUST treat it as an error and close
association by transmitting an ABORT
Advertised Receiver Window Credit (a_rwnd): 32 bits (
integer
This value represents the dedicated buffer space, in number
bytes, the sender of the INIT has reserved in association
this window. During the life of the association this buffer
SHOULD not be lessened (i.e. dedicated buffers taken away
this association); however, an endpoint MAY change the value
a_rwnd it sends in SACK chunks
Number of Outbound Streams (OS): 16 bits (unsigned integer
Defines the number of outbound streams the sender of this
chunk wishes to create in this association. The value of 0
NOT be used
Note: A receiver of an INIT with the OS value set to 0
abort the association
Number of Inbound Streams (MIS) : 16 bits (unsigned integer
Defines the maximum number of streams the sender of this
chunk allows the peer end to create in this association.
value 0 MUST NOT be used
Note: There is no negotiation of the actual number of streams
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details
Note: A receiver of an INIT with the MIS value of 0 SHOULD
the association
Initial TSN (I-TSN) : 32 bits (unsigned integer
Defines the initial TSN that the sender will use. The valid
is from 0 to 4294967295. This field MAY be set to the value
the Initiate Tag field
3.3.2.1 Optional/Variable Length Parameters in
The following parameters follow the Type-Length-Value format
defined in Section 3.2.1. Any Type-Length-Value fields MUST
after the fixed-length fields defined in the previous section
Stewart, et al. Standards Track [Page 26]
RFC 2960 Stream Control Transmission Protocol October 2000
IPv4 Address Parameter (5)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer
Contains an IPv4 address of the sending endpoint. It is
encoded
IPv6 Address Parameter (6)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer
Contains an IPv6 address of the sending endpoint. It is
encoded
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
but should instead use an IPv4 Address Parameter for an IPv
address
Combined with the Source Port Number in the SCTP common header
the value passed in an IPv4 or IPv6 Address parameter indicates
transport address the sender of the INIT will support for
association being initiated. That is, during the lifetime of
association, this IP address can appear in the source
field of an IP datagram sent from the sender of the INIT, and
be used as a destination address of an IP datagram sent from
receiver of the INIT
Stewart, et al. Standards Track [Page 27]
RFC 2960 Stream Control Transmission Protocol October 2000
More than one IP Address parameter can be included in an
chunk when the INIT sender is multi-homed. Moreover, a multi
homed endpoint may have access to different types of network,
more than one address type can be present in one INIT chunk, i.e.,
IPv4 and IPv6 addresses are allowed in the same INIT chunk
If the INIT contains at least one IP Address parameter, then
source address of the IP datagram containing the INIT chunk
any additional address(es) provided within the INIT can be used
destinations by the endpoint receiving the INIT. If the INIT
not contain any IP Address parameters, the endpoint receiving
INIT MUST use the source address associated with the received
datagram as its sole destination address for the association
Note that not using any IP address parameters in the INIT
INIT-ACK is an alternative to make an association more likely
work across a NAT box
Cookie Preservative (9)
The sender of the INIT shall use this parameter to suggest to
receiver of the INIT for a longer life-span of the State Cookie
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-span Increment: 32 bits (unsigned integer
This parameter indicates to the receiver how much increment
milliseconds the sender wishes the receiver to add to its
cookie life-span
This optional parameter should be added to the INIT chunk by
sender when it re-attempts establishing an association with a
to which its previous attempt of establishing the association
due 