Network Working Group                                     R. R. Stewart
INTERNET-DRAFT                                                   Q. Xie
                                                               Motorola
                                                           K. Morneault
                                                               C. Sharp
                                                                  Cisco
                                                     H. J. Schwarzbauer
                                                                Siemens
                                                              T. Taylor
                                                        Nortel Networks
                                                              I. Rytina
                                                               Ericsson
                                                               M. Kalla
                                                              Telcordia
                                                               L. Zhang
                                                                   UCLA
                                                              V. Paxson
                                                                  ACIRI

expires in six months                                      April 19,2000                                      June 16,2000

                 Stream Control Transmission Protocol
                   <draft-ietf-sigtran-sctp-09.txt>
                   <draft-ietf-sigtran-sctp-10.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Stewart, et al                                               [Page  1]

Abstract

This document describes the Stream Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications.

SCTP is a reliable datagram transfer transport protocol operating on top of an
unreliable routed a
connectionless packet network such as IP. It offers the following
services to its users:

  -- acknowledged error-free non-duplicated transfer of user data,
  -- data segmentation 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 multiplexing bundling of multiple user messages into a single SCTP datagrams,
     packet, and
  -- 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 behavior
and resistance to flooding and masquerade attacks.

Stewart, et al                                               [Page  2]

                        TABLE OF CONTENTS

1.  Introduction..................................................5  Introduction..................................................  5
  1.1 Motivation..................................................5 Motivation..................................................  5
  1.2 Architectural View of SCTP..................................5 SCTP..................................  6
  1.3 Functional View of SCTP.....................................6 SCTP.....................................  6
    1.3.1 Association Startup and Takedown........................7 Takedown........................  7
    1.3.2 Sequenced Delivery within Streams.......................7 Streams.......................  8
    1.3.3 User Data Segmentation..................................8 Fragmentation.................................  8
    1.3.4 Acknowledgment Acknowledgement and Congestion Avoidance.................8 Avoidance................  8
    1.3.5 Chunk Multiplex.........................................8 Bundling .........................................  8
    1.3.6 Message Validation......................................8 Packet Validation.......................................  9
    1.3.7 Path Management.........................................9 Management.........................................  9
  1.4 Recapitulation of Key Terms.................................9 Terms................................................... 10
  1.5 Abbreviations...............................................11 Abbreviations............................................... 12
  1.6 Serial Number Arithmetic.................................... 13
2. Conventions....................................................11 Conventions.................................................... 13
3.  SCTP Datagram Format..........................................12 packet Format............................................ 13
  3.1 SCTP Common Header Field Descriptions.......................12 Descriptions....................... 14
  3.2 Chunk Field Descriptions....................................13 Descriptions.................................... 15
    3.2.1 Optional/Variable-length Parameter Format...............14
    3.2.2 Vendor-Specific Extension Parameter Format..............15 Format............... 17
  3.3 SCTP Chunk Definitions......................................17 Definitions...................................... 18
    3.3.1 Payload Data (DATA)..................................... 18
    3.3.2 Initiation (INIT).......................................17
      3.3.1.1 (INIT)....................................... 20
      3.3.2.1 Optional or Variable Length Parameters..............19
    3.3.2 Parameters.............. 23
    3.3.3 Initiation Acknowledgment Acknowledgement (INIT ACK)....................20
      3.3.2.1 ACK)................... 25
      3.3.3.1 Optional or Variable Length Parameters..............21
    3.3.3 Selective Acknowledgment (SACK).........................22 Parameters.............. 28
    3.3.4 Selective Acknowledgement (SACK)........................ 28
    3.3.5 Heartbeat Request (HEARTBEAT)...........................25
    3.3.5 (HEARTBEAT)........................... 31
    3.3.6 Heartbeat Acknowledgment Acknowledgement (HEARTBEAT ACK)................26
    3.3.6 ACK)............... 32
    3.3.7 Abort Association (ABORT)...............................26
    3.3.7 (ABORT)............................... 33
    3.3.8 Shutdown Association (SHUTDOWN).........................27
    3.3.8 (SHUTDOWN)......................... 34
    3.3.9 Shutdown Acknowledgment Acknowledgement (SHUTDOWN ACK)..................28
    3.3.9 ACK)................. 34
    3.3.10 Operation Error (ERROR).................................28
    3.3.10 State (ERROR)................................ 35
      3.3.10.1 Invalid Stream Identifier.......................... 36
      3.3.10.2 Missing Mandatory Parameter........................ 36
      3.3.10.3 Stale Cookie Error................................. 37
      3.3.10.4 Out of Resource.................................... 37
      3.3.10.5 Unresolvable Address............................... 38
      3.3.10.6 Unrecognized Chunk Type............................ 38
      3.3.10.7 Invalid Mandatory Parameter........................ 38
      3.3.10.8 Unrecognized Parameters............................ 39
      3.3.10.9 No User Data....................................... 39
      3.3.10.10 Cookie (COOKIE)..................................30 Received While Shutting Down............... 39
    3.3.11 Cookie Acknowledgment Echo (COOKIE ACK).....................31 ECHO).............................. 40
    3.3.12 Payload Data (DATA)....................................31
  3.4 Vendor-Specific Chunk Extensions............................33 Cookie Acknowledgement (COOKIE ACK).................... 40
    3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 41
4. SCTP Association State Diagram.................................34 Diagram................................. 41
5. Association Initialization.....................................36 Initialization..................................... 44
  5.1 Normal Establishment of an Association......................37 Association...................... 45
    5.1.1 Handle Stream Parameters................................39 Parameters................................ 46
    5.1.2 Handle Address Parameters...............................39 Parameters............................... 47
    5.1.3 Generating State Cookie.................................39 Cookie................................. 48
    5.1.4 State Cookie Processing.......................................40 Processing................................. 49
    5.1.5 State Cookie Authentication...................................40 Authentication............................. 49
    5.1.6 An Example of Normal Association Establishment..........41 Establishment.......... 50
  5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE, COOKIE ECHO,
      and COOKIE ACK.....42 ACK.............................................. 51
    5.2.1 Handle Duplicate INIT in COOKIE-WAIT
          or COOKIE-SENT States...................................43 COOKIE-ECHOED States................................. 52
    5.2.2 Handle Duplicate Unexpected INIT in States Other States...................43 than CLOSED,
          COOKIE-ECHOED and COOKIE-WAIT........................... 52
    5.2.3 Handle Duplicate Unexpected INIT ACK...............................43 ACK..................................... 53
    5.2.4 Handle Duplicate COOKIE.................................43 a COOKIE ECHO when a TCB exists.................. 53
    5.2.5 Handle Duplicate COOKIE-ACK.............................45 COOKIE ACK............................. 55
    5.2.6 Handle Stale COOKIE Error...............................45 Error............................... 55
  5.3 Other Initialization Issues.................................45
Stewart, et al                                               [Page  3] Issues................................. 56
    5.3.1 Selection of Tag Value..................................45 Value.................................. 56
6. User Data Transfer.............................................46 Transfer............................................. 56
  6.1 Transmission of DATA Chunks.................................47 Chunks................................. 57
  6.2 Acknowledgment of Acknowledgement on Reception of DATA Chunks..................48 Chunks................. 59
    6.2.1 Tracking Peer's Receive Buffer Space....................49 Space.................... 61
  6.3 Management Retransmission Timer.............................50 Timer............................. 62
    6.3.1 RTO Calculation.........................................50 Calculation......................................... 63
    6.3.2 Retransmission Timer Rules..............................51 Rules.............................. 64
    6.3.3 Handle T3-rxt Expiration................................52 T3-rtx Expiration................................ 65
  6.4 Multi-homed SCTP Endpoints..................................53 Endpoints.................................. 66
    6.4.1 Failover from Inactive Destination Address..............54 Address.............. 66
  6.5 Stream Identifier and Stream Sequence Number................54 Number................ 67
  6.6 Ordered and Un-ordered Delivery.............................54 Unordered Delivery.............................. 67
  6.7 Report Gaps in Received DATA TSNs...........................55 TSNs........................... 68
  6.8 Adler-32 Checksum Calculation...............................56 Calculation............................... 69
  6.9 Segmentation................................................57 Fragmentation............................................... 70
  6.10 Bundling and Multiplexing..................................58 .................................................. 71
7. Congestion Control	..........................................58	.......................................... 71
  7.1 SCTP Differences from TCP Congestion Control................59 Control................ 72
  7.2 SCTP Slow-Start and Congestion Avoidance....................59 Avoidance.................... 73
    7.2.1 Slow-Start..............................................60 Slow-Start.............................................. 73
    7.2.2 Congestion Avoidance....................................61 Avoidance.................................... 74
    7.2.3 Congestion Control......................................61 Control...................................... 75
    7.2.4 Fast Retransmit on Gap Reports..........................62 Reports.......................... 75
  7.3 Path MTU Discovery..........................................63 Discovery.......................................... 76
8.  Fault Management..............................................64 Management.............................................. 77
  8.1 Endpoint Failure Detection..................................64 Detection.................................. 77
  8.2 Path Failure Detection......................................64 Detection...................................... 78
  8.3 Path Heartbeat..............................................65 Heartbeat.............................................. 78
  8.4 Handle "Out of the blue" Packets............................66 Packets............................ 80
  8.5 Verification Tag............................................67 Tag............................................ 81
    8.5.1 Exceptions in Verification Tag Rules....................67 Rules.................... 81
9. Termination of Association.....................................68 Association..................................... 82
  9.1 Close Abort of an Association.....................................68 Association..................................... 82
  9.2 Shutdown of an Association..................................68 Association.................................. 83
10. Interface with Upper Layer....................................69 Layer.................................... 85
  10.1 ULP-to-SCTP................................................70 ULP-to-SCTP................................................ 85
  10.2 SCTP-to-ULP................................................78 SCTP-to-ULP................................................ 94
11. Security Considerations.......................................82 Considerations....................................... 97
  11.1 Security Objectives........................................82 Objectives........................................ 97
  11.2 SCTP Responses To Potential Threats........................82 Threats........................ 97
    11.2.1 Countering Insider Attacks.............................82 Attacks............................. 97
    11.2.2 Protecting against Data Corruption in the Network......83 Network...... 97
    11.2.3 Protecting Confidentiality.............................83 Confidentiality............................. 98
    11.2.4 Protecting against Blind Denial of Service Attacks.....83 Attacks..... 98
      11.2.4.1 Flooding...........................................84 Flooding........................................... 98
      11.2.4.2 Masquerade.........................................84 Masquerade......................................... 99
      11.2.4.3 Improper Monopolization of Services................85 Services................100
  11.3 Protection against Fraud and Repudiation...................85 Repudiation...................100
12. Recommended Transmission Control Block (TCB) Parameters.......86 Parameters.......101
  12.1 Parameters necessary for the SCTP instance.................86 instance.................101
  12.2 Parameters necessary per association (i.e. the TCB)........87 TCB)........101
  12.3 Per Transport Address Data.................................88 Data.................................103
  12.4 General Parameters Needed..................................89 Needed..................................104
13. IANA Consideration............................................89 Consideration............................................104
  13.1 IETF-defined Chunk Extension...............................89 Extension...............................104
  13.2 IETF-defined Chunk Parameter Extension.....................90
  13.3 IETF-defined Additional Error Causes.......................91
  13.4 Causes.......................105
  13.3 Payload Protocol Identifiers...............................92
Stewart, et al                                               [Page  4] Identifiers...............................105
14. Suggested SCTP Protocol Parameter Values......................92 Values......................106
15. Acknowledgments...............................................92 Acknowledgements..............................................106
16. Authors' Addresses............................................93 Addresses............................................106
17. References....................................................94 References....................................................107
18. Bibliography..................................................108
Appendix A .......................................................95 .......................................................109
Appendix B .......................................................110

1. Introduction

This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description
of the protocol.

1.1 Motivation

TCP [8] [RFC793] has performed immense service as the primary means of
reliable data transfer in IP networks. However, an increasing number of
recent applications have found TCP too limiting, and have incorporated
their own reliable data transfer protocol on top of UDP [9]. [RFC768]. The
limitations which users have wished to bypass include the following:

     -- 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.

Transport of PSTN signaling across the IP network is an application
for which all of these limitations of TCP are relevant. While this
application directly motivated the development of SCTP, other
applications may find SCTP a good match to their requirements.

1.2 Architectural View of SCTP

SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and an unreliable routed a connectionless packet network service such
as IP. The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of
user messages between peer SCTP users. It performs this service

Stewart, et al                                               [Page  5]
within the context of an association between two SCTP nodes. Chapter 9 endpoints.
Section 10 of this document sketches the API which should exist at the
boundary between the SCTP and the SCTP user layers.

SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint (Section 1.4) to provide the other during endpoint (during
association startup startup) with a list of transport addresses (e.g. (i.e., multiple
IP addresses in combination with an SCTP port) through which that
endpoint can be reached and from which it will originate messages. SCTP packets.
The association spans transfers over all of the possible
source/destination combinations which may be generated from the two
endpoint 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 B

                    Figure 1: An SCTP Association

1.3 Functional View of SCTP

The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the
remainder of this section.

                   SCTP User Application

  ..-----------------------------------------------------
  .. _____________                  ____________________
    |             |                | Sequenced delivery |
    | Association |                |   within streams   |
    |             |                |____________________|
    |   startup   |
  ..|             |         ____________________________
    |     and     |        |    User Data Segmentation Fragmentation |
    |             |        |____________________________|
    |   takedown  |

Stewart, et al                                               [Page  6]
  ..|             |         ____________________________
    |             |        |     Acknowledgment     Acknowledgement        |
    |             |        |          and               |
    |             |        |    Congestion Avoidance    |
  ..|             |        |____________________________|
    |             |
    |             |         ____________________________
    |             |        |       Chunk Multiplex Bundling       |
    |             |        |____________________________|
    |             |
    |             |     ________________________________
    |             |    |     Message      Packet Validation         |
    |             |    |________________________________|
    |             |
    |             |     ________________________________
    |             |    |     Path Management            |
    |______________    |________________________________|

   Figure 2: Functional View of the SCTP Transport Service

1.3.1 Association Startup and Takedown

An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Chapter 9). Section 10).

A cookie mechanism, taken from that devised similar to one described by Karn and Simpson in RFC
2522 [6],
[RFC2522], is employed during the initialization to provide protection
against security attacks. The cookie mechanism uses a four-way
handshaking, but
handshake, the last two legs of which are allowed to carry user
data for fast setup. The startup sequence is described in chapter 4 Section 5 of
this document.

SCTP provides for graceful takedown close (i.e., shutdown) of an active
association on request from the SCTP user. See the description of the TERMINATE
SHUTDOWN primitive in chapter Section 10. SCTP also allows ungraceful takedown, 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. Chapter 8 Section
9 describes both the graceful and the ungraceful takedown close procedures.

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 (see Section 9).

1.3.2 Sequenced Delivery within Streams

The term "stream" is used in SCTP to refer to a sequence of user
messages. This is in contrast
messages that are to its usage be delivered to the upper-layer protocol in TCP, 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. 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 (see section Section 5.1.1). User messages are associated
with stream numbers (SEND, RECEIVE primitives, Chapter 9). Section 10). Internally,
SCTP assigns a stream sequence number to each message passed to it by

Stewart, et al                                               [Page  7]
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.

1.3.3 User Data Segmentation Fragmentation

When needed, SCTP can segment fragments user messages to ensure that the SCTP datagram
packet passed to the lower layer conforms to the path MTU. Segments On receipt,
fragments are reassembled into complete messages before being passed to
the SCTP user.

1.3.4 Acknowledgment Acknowledgement and Congestion Avoidance

SCTP assigns a Transmission Sequence Number (TSN) to each user data
segment
fragment or unsegmented 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 Acknowledgment acknowledgement and Congestion Avoidance congestion avoidance function is responsible
for message packet retransmission when timely acknowledgment acknowledgement has not been
received. Message Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. See Chapters 5
and Sections 6
and 7 for a detailed description of the protocol procedures associated
with this function.

1.3.5 Chunk Multiplex Bundling

As described in Chapter 2, Section 3, the SCTP datagram 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", or multiplexing bundling of more than one user
messages into a single SCTP datagram. packet. The chunk
multiplex bundling function of SCTP
is responsible for assembly of the complete SCTP datagram 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.

1.3.6 Message Packet Validation

A mandatory verification tag Verification Tag field and an Adler-32 a 32 bit checksum [2] fields field (see
Appendix B for a description of the Adler-32 checksum) are included in
the SCTP common header. The verification tag Verification Tag value is chosen by each
end of the association during association startup.
Messages Packets received
without the verification tag value expected by the
receiver Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale datagrams SCTP
packets from a previous association.

Stewart, et al                                               [Page  8] The Adler-32 checksum should be
set by the sender of each SCTP datagram, packet to provide additional protection
against data corruption in the
network beyond that provided by lower layers  (e.g. network.  The receiver of an SCTP packet
with an invalid Adler-32 checksum silently discards the IP checksum). packet.

1.3.7 Path Management

The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP datagrams, packets through the
primitives described in Chapter Section 10. The SCTP path management function
chooses the destination transport address for each outgoing SCTP
datagram
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 heartbeat
messages heartbeats
when other message packet traffic is inadequate to provide this
information, information
and advises the SCTP user when reachability of any far-
end 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 destination transport address path is defined for each SCTP
endpoint, and is used for normal sending of SCTP
datagrams. packets.

On the receiving end, the path management is responsible for verifying
the existence of a valid SCTP association to which the inbound SCTP
datagram
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.

1.4 Recapitulation of Key Terms

The

Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the key
terms and their definitions.

 o SCTP user application (SCTP user): The logical higher-layer
   application entity which uses the services of SCTP, also called
   the Upper-layer Protocol (ULP). Active destination transport address: A transport address on a peer
   endpoint which a transmitting endpoint considers available for
   receiving user messages.

 o User message: the unit of data delivery across Bundling: An optional multiplexing operation, whereby more than one
   user message may be carried in the interface
   between same SCTP and packet.  Each user
   message occupies its user. own DATA chunk.

 o SCTP datagram: the Chunk: A unit of data delivery across the interface
   between information within an SCTP packet, consisting of
   a chunk header and the unreliable packet network (e.g. IP) which
   it is using. chunk-specific content.

 o Congestion Window (cwnd): An SCTP datagram includes variable that limits the common SCTP header,
   possible SCTP control chunks, and user data encapsulated within
   SCTP DATA chunks.

 o Transport address: an address which serves as data, in
   number of bytes, a source or
   destination for the unreliable packet transport service used by
   SCTP. In IP networks, sender can send to a particular destination
   transport address is defined by the
   combination of an IP address and before receiving an SCTP port number.

Stewart, et al                                               [Page  9]
   Note, only one SCTP port may be defined for each endpoint,
   but each endpoint may have multiple IP addresses. acknowledgement.

 o SCTP endpoint: Cumulative TSN Ack Point: The TSN of the logical sender/receiver last DATA chunk
   acknowledged via the Cumulative TSN Ack field of SCTP datagrams. On a
   multi-homed host, an SCTP endpoint is represented SACK.

 o Idle destination address: An address that has not had user messages
   sent to its peers as a
   combination of a set it within some length of eligible time, normally the HEARTBEAT
   interval or greater.

 o Inactive destination transport addresses to address: An address which SCTP datagrams can be sent and a set of eligible source
   transport addresses from which SCTP datagrams can be received.

   Note, a source or destination transport address can only be
   included in one unique SCTP endpoint, i.e., it is NOT allowed
   considered inactive due to errors and unavailable to
   have the same SCTP source or destination transport address appear
   in more than one SCTP endpoint. user
   messages.

 o Message = user message:  Data submitted to SCTP association: by the Upper Layer
   Protocol (ULP).

 o Message Authentication Code (MAC):  An integrity check mechanism
   based on cryptographic hash functions using a protocol relationship secret key.
   Typically, message authentication codes are used between SCTP endpoints,
   comprising the two SCTP endpoints and protocol state information
   including verification tags and the currently active set of
   Transmission Sequence Numbers (TSNs), etc.

 o Chunk:
   parties that share a unit of secret key in order to validate information within an
   transmitted between these parties. In SCTP datagram, consisting of
   a chunk header and chunk-specific content.

 o Transmission Sequence Number (TSN): a 32-bit sequence number it is used
   internally by SCTP. One TSN is attached to each chunk containing
   user data to permit the receiving SCTP an
   endpoint to acknowledge its
   receipt and detect duplicate deliveries.

 o Stream: a uni-directional logical channel established validate the State Cookie information that is
   returned from one to
   another associated the peer in the COOKIE ECHO chunk.  The term "MAC"
   has different meanings in different contexts.  SCTP endpoints, within which all uses this
   term with the same meaning as in [RFC2104].

 o Network Byte Order: Most significant byte first, a.k.a., Big Endian.

 o Ordered Message: A user messages
   are message that is delivered in sequence except for those submitted order with
   respect to all previous user messages sent within the
   un-ordered delivery service.

   Note: The relationship between stream numbers in opposite
   directions is strictly a matter of how the applications use
   them. It is the responsibility of the SCTP user to create and
   manage these correlations if they are so desired.
   message was sent on.

 o Stream Sequence Number: a 16-bit sequence number used internally by Outstanding TSN (at an SCTP to assure sequenced delivery of endpoint): A TSN (and the user messages within a
   given stream. One stream sequence number is attached to each user
   message. associated
   DATA chunk) that has been sent by the endpoint but for which it has
   not yet received an acknowledgement.

 o Path: the The route taken by the SCTP datagrams packets sent by one SCTP
   endpoint to a specific destination transport address of its peer
   SCTP endpoint. Note, sending Sending to different destination transport
   addresses does not necessarily guarantee getting separate paths.

 o Bundling: an optional multiplexing operation, whereby more than one
   user messages may be carried in Primary Path: The primary path is the same SCTP datagram.  Each user
   message occupies its own DATA chunk.

 o Outstanding TSN (at an SCTP endpoint): destination and
   source address that will be put into a TSN (and packet outbound
   to the associated DATA
   chunk) which have been sent peer endpoint by default. The definition includes
   the endpoint but for which it has not
   yet received an acknowledgment.

Stewart, et al                                               [Page  10]
 o Unacknowledged TSN (at source address since an SCTP endpoint): a TSN (and implementation MAY wish to
   specify both destination and source address to better
   control the associated DATA
   chunk) which have been received return path taken by the endpoint but for reply chunks and on which an
   acknowledgment has not yet been sent.
   interface the packet is transmitted when the data sender
   is multi-homed.

 o Receiver Window (rwnd): The An SCTP variable a data sender uses to store
   the most recently calculated receiver
   window, window of its peer, in number
   of octets. bytes. This gives the sender an indication of the space available
   in the receiver's inbound buffer.

 o Congestion Window (cwnd): An SCTP variable that limits association: A protocol relationship between SCTP endpoints,
   composed of the data, in
   number two SCTP endpoints and protocol state information
   including Verification Tags and the currently active set of octets, a sender
   Transmission Sequence Numbers (TSNs), etc.  An association can send into be
   uniquely identified by the network before
   receiving transport addresses used by the endpoints
   in the association. Two SCTP endpoints MUST NOT have more than one
   SCTP association between them at any given time.

 o SCTP endpoint: The logical sender/receiver of SCTP packets. On a
   multi-homed host, an acknowledgment on SCTP endpoint is represented to its peers as a particular
   combination of a set of eligible destination Transport
   address. transport addresses to
   which SCTP packets can be sent and a set of eligible source
   transport addresses from which SCTP packets can be received.
   All transport addresses used by an SCTP endpoint must use the
   same port number, but can use multiple IP addresses.

 o SCTP packet (or packet): The unit of data delivery across the
   interface between SCTP and the connectionless packet network (e.g.,
   IP).  An SCTP packet includes the common SCTP header, possible SCTP
   control chunks, and user data encapsulated within SCTP DATA chunks.

 o SCTP user application (SCTP user): The logical higher-layer
   application entity which uses the services of SCTP, also called
   the Upper-layer Protocol (ULP).

 o Slow Start Threshold (ssthresh): An SCTP variable. This is the
   threshold which the endpoint will use to determine whether to
   perform slow start or congestion avoidance on a particular
   destination transport address. Ssthresh is in number of octets. bytes.

 o Transmission Control Block (TCB): an internal data structure
   created by an SCTP endpoint for each of its existing SCTP
   associations Stream: A uni-directional logical channel established from one to other
   another associated SCTP endpoints. TCB contains endpoint, within which all the status
   and operational information for the endpoint user messages
   are delivered in sequence except for those submitted to maintain the
   unordered delivery service.

   Note: The relationship between stream numbers in opposite
   directions is strictly a matter of how the applications use
   them. It is the responsibility of the SCTP user to create and
   manage
   the corresponding association. these correlations if they are so desired.

 o Network Byte Order: Most significant byte first, a.k.a Big Endian.

1.5. Abbreviations

ICV    - Integrity Check Value [4]

RTO    - Retransmission Time-out

RTT    - Round-trip Time

RTTVAR - Round-trip Time Variation

SCTP   - Stream Control Transmission Protocol

SRTT   - Smoothed RTT

TCB    - Sequence Number: A 16-bit sequence number used internally by
   SCTP to assure sequenced delivery of the user messages within a
   given stream. One stream sequence number is attached to each user
   message.

 o Transmission Control Block

TLV    - Type-Length-Value Coding Format

TSN    - Transmission Sequence Number

ULP    - Upper-layer Protocol

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC 2119 [18].

Stewart, et al                                               [Page  11]

3.  SCTP Datagram Format (TCB): An internal data structure
   created by an SCTP datagram is composed endpoint for each of a common header its existing SCTP
   associations to other SCTP endpoints. TCB contains all the status
   and chunks. operational information for the endpoint to maintain and manage
   the corresponding association.

 o Transmission Sequence Number (TSN): A 32-bit sequence number used
   internally by SCTP. One TSN is attached to each chunk
contains either control information or containing
   user data.

The data to permit the receiving SCTP datagram 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 multiplexed into one SCTP datagram up endpoint to acknowledge its
   receipt and detect duplicate deliveries.

 o Transport address:  A Transport Address is traditionally defined by
   Network Layer address, Transport Layer protocol and Transport Layer
   port number.  In the MTU size, except for case of SCTP running over IP, a transport
   address is defined by the INIT, INIT ACK, combination of an IP address and SHUTDOWN ACK
chunks. These chunks MUST NOT be multiplexed with any other chunk in a
datagram. See Section 6.10 for more details on chunk multiplexing.

If an user data message doesn't fit into one SCTP datagram it can be
segmented into multiple chunks using
   port number (where SCTP is the procedure defined in
Section 6.9.

All integer fields in Transport protocol).

 o Unacknowledged TSN (at an SCTP datagram MUST be transmitted endpoint): A TSN (and the associated
   DATA chunk) which has been received by the endpoint but for which an
   acknowledgement has not yet been sent. Or in the
network byte order, unless otherwise stated.

3.1 SCTP Common Header Field Descriptions

                     SCTP Common Header Format

  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                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Adler-32 Checksum                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port Number: 16 bit u_int

  This is the SCTP sender's port number. It can be used by the
  receiver, in combination opposite case,
   for a packet that has been sent but no acknowledgement has
   been received.

 o Unordered Message: Unordered messages are "unordered" with the source IP address, to identify the
  association respect
   to which this datagram belongs.

Destination Port Number: 16 bit u_int

  This is the SCTP port number to which this datagram is destined. The
  receiving host will use any other message, this port number to de-multiplex the
  SCTP datagram includes both other unordered messages
   as well as other ordered messages. Unordered message might be
   delivered prior to or later than ordered messages sent on the correct receiving endpoint/application.

Stewart, et al                                               [Page  12]

Verification Tag: 32 bit u_int
   same stream.

 o User message: The receiver unit of this datagram uses the Verification Tag to validate data delivery across the sender of this interface
   between SCTP datagram. On transmit, the value of this
  Verification Tag MUST be set and its user.

1.5. Abbreviations

MAC    - Message Authentication Code [RFC2104]

RTO    - Retransmission Time-out

RTT    - Round-trip Time

RTTVAR - Round-trip Time Variation

SCTP   - Stream Control Transmission Protocol

SRTT   - Smoothed RTT

TCB    - Transmission Control Block

TLV    - Type-Length-Value Coding Format

TSN    - Transmission Sequence Number

ULP    - Upper-layer Protocol

1.6 Serial Number Arithmetic

It is essential to remember that the value of the Initiate Tag
  received actual Transmission Sequence
Number space is finite, though very large.  This space ranges from 0 to
2**32 - 1. Since the peer endpoint during space is finite, all arithmetic dealing with
Transmission Sequence Numbers must be performed modulo 2**32.  This
unsigned Arithmetic preserves the association
  initialization.

  For datagrams carrying the INIT chunk, the transmitter MUST set the
  Verification Tag relationship of sequence numbers as
they cycle From 2**32 - 1 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
  neither INIT nor SHUTDOWN ACK or ABORT, the receiver MUST drop
  the datagram. For datagrams carrying the SHUTDOWN ACK chunk, the
  transmitter SHOULD set the Verification Tag 0 again.  There are some subtleties to the Initiate Tag
  received from the peer endpoint during the association
  initialization, if known. Otherwise, the Verification Tag
  MUST
computer modulo arithmetic, so great care should be set to all 0's.

  Note: Special rules apply to the ABORT message see Section 8.5.

Adler-32 Checksum: 32 bit u_int

  This field MUST contain an Adler-32 checksum of this SCTP
  datagram. Its calculation is discussed taken in Section 6.8.

3.2  Chunk Field Descriptions

The figure below illustrates the field format for
programming the chunks comparison of such values.  When referring to be
transmitted in TSNs, the SCTP datagram. Each
symbol "=<" means "less than or equal"(modulo 2**32).

Comparisons and arithmetic on TSNs in this document SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.

An endpoint SHOULD NOT transmit a DATA chunk is formatted with a Chunk
ID field, a chunk-specific Flag field, a Length field, and a Value
field.

   0 TSN that is more
than 2**31 - 1                   2                   3
   0 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 2 3 4 is TSN = 0.

Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number
Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.

All other arithmetic and comparisons in this document uses normal
arithmetic.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].

3.  SCTP packet Format

An SCTP packet is composed of a common header and chunks. A chunk
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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Chunk ID                        Common Header                          | Chunk  Flags
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Chunk Length #1                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \                                                               \
  /                          Chunk Value                          /
  \                                                               \
  |                           ...                                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Chunk ID: 8 bits, u_int

  This field identifies #n                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Multiple chunks can be bundled into one SCTP packet up to
the type of information contained in MTU size, except for the Chunk
  Value field. It takes INIT, INIT ACK, and SHUTDOWN COMPLETE
chunks. These chunks MUST NOT be bundled with any other chunk in a value from 0x00 to 0xFF. The value of 0xFE
  is reserved for vendor-specific extensions. The value of 0xFF is
  reserved for future use as an extension field. Procedures
packet. See Section 6.10 for
  extending this field by vendors are more details on chunk bundling.

If a user data message doesn't fit into one SCTP packet it can be
fragmented into multiple chunks using the procedure defined in
Section 3.4.

  The values of Chunk ID are defined as follows:

Stewart, et al                                               [Page  13]
  ID Value    Chunk Type
  -----       ----------
  00000000  - Payload Data (DATA)
  00000001  - Initiation (INIT)
  00000010  - Initiation Acknowledgment (INIT ACK)
  00000011  - Selective Acknowledgment (SACK)
  00000100  - Heartbeat Request (HEARTBEAT)
  00000101  - Heartbeat Acknowledgment (HEARTBEAT ACK)
  00000110  - Abort (ABORT)
  00000111  - Shutdown (SHUTDOWN)
  00001000  - Shutdown Acknowledgment (SHUTDOWN ACK)
  00001001  - Operation Error (ERROR)
  00001010  - State Cookie (COOKIE)
  00001011  - Cookie Acknowledgment (COOKIE ACK)
  00001100  - Reserved for Explicit Congestion Notification Echo (ECNE)
  00001101  - Reserved for Congestion Window Reduced (CWR)
  00001110 to 11111101 - reserved by IETF
  11111110  - Vendor-specific Chunk Extensions
  11111111  - IETF-defined Chunk Extensions

Note: The ECNE and CWR chunk types are reserved for future use of Explicit
Congestion Notification (ECN).

Chunk Flags: 8 bits

  The usage of these bits depends on the chunk type as given by the
  Chunk ID. Unless 6.9.

All integer fields in an SCTP packet MUST be transmitted in
network byte order, unless otherwise specified, they are set to zero on
  transmit and are ignored on receipt.

Chunk Length: stated.

3.1 SCTP Common Header Field Descriptions

                     SCTP Common Header Format

   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 (u_int) (unsigned integer)

  This value represents is the size of SCTP senders port number. It can be used by the chunk
  receiver in octets including combination with the
  Chunk ID, Flags, Length, source IP address, the
  SCTP destination port and Value fields.  Therefore, if possibly the Value
  field is zero-length, destination IP address
  to identify the Length field will be set association to 0x0004.  The
  Length field does not count any padding.

Chunk Value: variable length which this packet belongs.

Destination Port Number: 16 bits (unsigned integer)

  This is the SCTP port number to which this packet is destined. The Chunk Value field contains
  receiving host will use this port number to de-multiplex the actual information
  SCTP packet to be
  transferred in the chunk. correct receiving endpoint/application.

Verification Tag: 32 bits (unsigned integer)

  The usage and format receiver of this field is
  dependent on packet uses the Chunk ID. The Chunk Value field Verification Tag to validate
  the sender of this SCTP packet. On transmit, the value of this
  Verification Tag MUST be aligned on
  32-bit boundaries. If set to the length value of the chunk does not align on
  32-bit boundaries, it is padded at Initiate Tag
  received from the end peer endpoint during the association
  initialization, with all the following exceptions:
   - A packet containing an INIT chunk MUST have a zero octets.

SCTP defined chunks are described in detail in
     Verification Tag.
   - A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit
     set MUST have the Verification Tag copied from the packet
     with the SHUTDOWN-ACK chunk.
   - A packet containing an ABORT chunk may have the verification
     tag copied from the packet which caused the ABORT to be sent.
     For details see Section 3.3. The
guideline for vendor-specific 8.4 and 8.5.

 An INIT chunk extensions MUST be the only chunk in the SCTP packet carrying it.

Checksum: 32 bits (unsigned integer)

  This field contains the checksum of this SCTP packet. Its calculation
  is discussed in Section
3.4. And 6.8.  SCTP uses the guidelines Adler-32 algorithm as
  described in Appendix B for IETF-defined chunk extensions can calculating the checksum

3.2  Chunk Field Descriptions

The figure below illustrates the field format for the chunks to be found
transmitted in Section 13.1 of this document.

3.2.1  Optional/Variable-length Parameter Format

The optional and variable-length parameters contained in a the SCTP packet. Each chunk
are defined in is formatted with a Type-Length-Value format as shown below.

Stewart, et al                                               [Page  14] Chunk
Type field, a chunk-specific Flag field, a Chunk Length field, and a
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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Parameter   Chunk Type  |       Parameter Chunk  Flags  |        Chunk Length           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \                                                               \
  /                       Parameter                          Chunk Value                          /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter

Chunk Type:  16 bit u_int

  The Type 8 bits (unsigned integer)

  This field is a 16 bit identifier of identifies the type of parameter. information contained in the Chunk
  Value field. It takes a value of 0x0000 from 0 to 0xFFFF. 254. The value of 0xFFFE 255 is
  reserved for vendor-specific extensions if
  the specific chunk allows such extensions. future use as an extension field.

  The value values of 0xFFFF is
  reserved Chunk Types are defined as follows:

  ID Value    Chunk Type
  -----       ----------
  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)
  14         - Shutdown Complete (SHUTDOWN COMPLETE)
  15 to 63   - reserved by IETF
  63         - IETF-defined extensions.  Values other than those
  defined in specific SCTP chunk description are Chunk Extensions
  64 to 126  - reserved for use by
  IETF.

Parameter Length:  16 bit u_int

  The Length field contains the size of IETF
  127        - IETF-defined Chunk Extensions
  128 to 190 - reserved by IETF
  191        - IETF-defined Chunk Extensions
  192 to 254 - reserved by IETF
  255        - IETF-defined Chunk Extensions

  Chunk Types are encoded such that the parameter in octets,
  including highest-order two bits
  specify the Type, Length, and Value 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 in an Operation Error Chunk
       using the 'Unrecognized Chunk Type' cause of error.

  10 - Skip this chunk and continue processing.

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

  Note: The ECNE and CWR chunk types are reserved for future use of
  Explicit Congestion Notification (ECN).

Chunk Flags: 8 bits

  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: 16 bits (unsigned integer)
  This value represents the size of the chunk in bytes including the
  Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.  Thus, a parameter
  with a zero-length
  Therefore, if the Chunk Value field would have a is zero-length, the Length
  field of
  0x0004. will be set to 4.  The Chunk Length field does not include count
  any padding octets.

Parameter padding.

Chunk Value: variable-length. variable length

  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 value of the Type field. Chunk Type.

The value
  field total length of a chunk (including Type, Length and Value fields)
MUST be aligned on 32-bit boundaries. a multiple of 4 bytes. If the value field length of the chunk is not aligned on 32-bit boundaries it is padded at a
multiple of 4 bytes, the end with all
  zero octets.  The value field must be an integer number of octets.

The actual SCTP parameters are defined sender MUST pad the chunk with all zero bytes
and this padding is NOT included in the specific SCTP chunk
sections. length field. The guidelines for vendor-specific parameter extensions sender
should never pad with more than 3 bytes. The receiver MUST ignore the
padding bytes.

SCTP defined chunks are discussed described in detail in Section 3.2.2. And the rules 3.3. The
guidelines for IETF-defined
parameter chunk extensions are defined can be found in Section 13.2.

3.2.2 Vendor-Specific Extension
13.1 of this document.

3.2.1  Optional/Variable-length Parameter Format

This is to allow vendors to support their own extended parameters not
defined by the IETF. It MUST not affect the operation

Chunk values of SCTP.

Endpoints not equipped to interpret the vendor-specific information
sent SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters. The
optional and variable-length parameters contained in a remote endpoint MUST ignore it (although it may be
reported). Endpoints that do not receive desired vendor-specific
information SHOULD make an attempt to operate without it, although
they may do so (and report they chunk are doing so)
defined in a degraded mode.

A summary of the Vendor-specific extension Type-Length-Value format is as shown below. The
fields are transmitted from left to right.

Stewart, et al                                               [Page  15]

   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 = 0xFFFE       |       Parameter Length        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Vendor-Id                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \                                                               \
  /                       Parameter Value                         /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Parameter Type:  16 bits (unsigned integer)

  The Type field is a 16 bit u_int

     0xFFFE identifier of the type of parameter. It
  takes a value of 0 to 65534.

  The value of 65535 is reserved for all Vendor-Specific parameters. IETF-defined extensions.
  Values other than those defined in specific SCTP chunk
  description are reserved for use by IETF.

Chunk Parameter Length:  16 bit u_int

     Indicate bits (unsigned integer)

  The Parameter Length field contains the size of the parameter in octets, bytes,
  including the Parameter Type, Parameter Length, Vendor-Id, and Parameter
  Value fields.

  Vendor-Id: 32 bit u_int

     The high-order octet is 0 and the low-order 3 octets are the
     SMI Network Management Private Enterprise Code Thus, a parameter with a zero-length Parameter
  Value field would have a Length field of the Vendor
     in network byte order, as defined in the Assigned Numbers (RFC
     1700). 4. The Parameter Length
  does not include any padding bytes.

Chunk Parameter Value: variable length variable-length.

  The Parameter Value field is one or more octets.  The actual format of contains the actual information is site or application specific, and a robust
     implementation SHOULD support to be
  transferred in the field as undistinguished
     octets. parameter.

The codification of the range of allowed usage of this field is
     outside the scope total length of this specification.

     It SHOULD a parameter (including Type, Parameter Length and
Value fields) MUST be encoded as a sequence multiple of vendor type / vendor 4 bytes. If the length
     / value fields, as follows.  The of the
parameter field is
     dependent on the vendor's definition of that attribute.  An
     example encoding not a multiple of the Vendor-Specific attribute using this
     method follows:

    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 = 0xFFFE    |      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor-Id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VS-Type              |             VS-Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          VS-Value                             /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart, et al                                               [Page  16]
   VS-Type: 16 bit u_int

     This field identifies bytes, the parameter included in sender pads the VS-Value field.
     It is assigned by Parameter
at the vendor.

   VS-Length: 16 bit u_int

     This field is end (i.e., after the Parameter Value field) with all zero
bytes. The length of the vendor-specific parameter and
     Includes the VS-Type, VS-Length and VS-Value (if included) fields.

   VS-Value:  Variable Length

     This field contains padding is NOT included in the parameter identified by the VS-Type
length field.
     It's meaning is identified by A sender should NEVER pad with more than 3 bytes. The
receiver MUST ignore the vendor. padding bytes.

The Parameter 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 Parameter 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 a Operational Error or
     in the  INIT ACK).

10 - Skip this parameter and continue processing.

11 - Skip this parameter and continue processing but report the
     the unrecognized parameter in an 'Unrecognized Parameter Type'
     (in either a Operational Error or in the  INIT ACK).

The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2.

3.3 SCTP Chunk Definitions

This section defines the format of the different SCTP chunk types.

3.3.1 Initiation (INIT) (00000001)

This chunk is used to initiate a SCTP association between two
endpoints. Payload Data (DATA) (0)

The following format of MUST be used for the INIT message is shown below: 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0
   |   Type = 0 1|  Chunk Flags    |      Chunk Reserved|U|B|E|    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Initiate Tag                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Advertised Receiver Window Credit (a_rwnd)                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Number of Outbound Streams      Stream Identifier S      |   Stream Sequence Number of Inbound Streams n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Initial TSN                  Payload Protocol Identifier                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /              Optional/Variable-Length Parameters                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The INIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only

Reserved: 5 bits
  Should be included once in set to all '0's and ignored by the INIT chunk.

Fixed Parameters                     Status
----------------------------------------------
Initiate Tag                        Mandatory
Advertised Receiver Window Credit   Mandatory
Number of Outbound Streams          Mandatory
Number of Inbound Streams           Mandatory
Initial TSN                         Mandatory

Stewart, et al                                               [Page  17]

Variable Parameters                  Status     Type Value
-------------------------------------------------------------
IPv4 Address (Note 1)               Optional    0x0005
IPv6 Address (Note 1)               Optional    0x0006
Cookie Preservative                 Optional    0x0009
Reserved for ECN Capable (Note 2)   Optional    0x000a
Host Name Address (Note 3)          Optional    0x000b
Supported Address Types (Note 4)    Optional    0x000c

Note 1: receiver.

U bit: 1 bit
  The INIT chunks may contain multiple addresses (U)nordered bit, if set to '1', indicates that may be
IPv4 and/or IPv6 in any combination.

Note 2: The ECN capable field this is reserved for future use of Explicit
Congestion Notification.

Note 3: The INIT chunks may contain AT MOST one Host Name address
parameter. Moreover, the sender of the INIT SHALL not combine any other
address types with the Host Name address in the INIT while an
  unordered DATA chunk, and there is no Stream Sequence Number assigned
  to this DATA chunk. Therefore, the receiver
of INIT MUST ignore any other address types if the Host Name address
parameter is present in the received INIT chunk.

Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address types.

Chunk Flags field in INIT is reserved, and all bits in it should Stream
  Sequence Number field.

  After re-assembly (if necessary), unordered DATA chunks MUST be
set
  dispatched to 0 by the sender and ignored upper layer by the receiver. The sequence of
parameters within an INIT may be processed in any order.

Initiate Tag: 32 bit u_int

  The receiver without any attempt to
  re-order.

  If an unordered user message is fragmented, each fragment of the INIT (the responding end) records the value of
  the Initiate Tag parameter. This value
  message MUST be placed into have its U bit set to '1'.

B bit: 1 bit

  The (B)eginning fragment bit, if set, indicates the
  Verification Tag field first fragment of every SCTP datagram that the responding
  end transmits within this association.
  a user message.

E bit:  1 bit
  The valid range for Initiate Tag is from 0x1 to 0xffffffff. See
  Section 5.3.1 for more on (E)nding fragment bit, if set, indicates the selection last fragment of a
  user message.

An unfragmented user message shall have both the tag value.

  If the value B and E bits set
to '1'. Setting both B and E bits to '0' indicates a middle fragment of the Initiate Tag
a multi-fragment user message, as summarized in the following table:

       B E                  Description
    ============================================================
    |  1 0 | First piece of a received INIT chunk 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 found
  to be 0x0, fragmented into multiple chunks, the TSNs are

used by the receiver MUST treat it as an error and silently
  discard to reassemble the datagram.

Advertised Receiver Window Credit (a_rwnd): 32 bit u_int message.  This value represents means that the dedicated buffer space, in number
TSNs for each fragment of
  octets, a fragmented user message MUST be strictly
sequential.

Length:  16 bits (unsigned integer)

  This field indicates the sender length of the INIT has placed DATA chunk in association with this
  window. During the life of the association this buffer space SHOULD
  not be lessened (i.e. dedicated buffers taken away bytes from this
  association).

Number of Outbound Streams (OS):  16 bit u_int

  Defines the number
  beginning of outbound streams the sender of this INIT chunk
  wishes type field to create in this association. The value of 0 MUST NOT be
  used.

Number of Inbound Streams (MIS) : 16 bit u_int

  Defines the MAXIMUM number end of streams the sender of this INIT user data field
  excluding any padding.  A DATA chunk
  allows the peer end with no user data field will
  have Length set to create in this association. The value 0 MUST
  NOT be used.

Initial 16 (indicating 16 bytes).

TSN (I-TSN) : 32 bit u_int

  Defines bits (unsigned integer)

  This value represents the initial TSN that the sender will use. for this DATA chunk. The valid range
  of TSN is from 0x0 0 to 0xffffffff. This field MAY be set 4294967295 (2**32 - 1).  TSN wraps back to 0
  after reaching 4294967295.

Stream Identifier S: 16 bits (unsigned integer)

  Identifies the value of the
  Initiate Tag field.

Stewart, et al                                               [Page  18]

Vendor-specific parameters are allowed in INIT. However, they MUST be
appended stream to which the end of following user data belongs.

Stream Sequence Number n: 16 bits (unsigned integer)

  This value represents the above INIT chunks. The format stream sequence number of the
vendor-specific parameters MUST follow following
  user data within the Type-Length-value format as
defined in Section 3.2.2. In case an endpoint does not support stream S. Valid range is 0 to 65535.

  When a user message is fragmented by SCTP for transport, the
vendor-specific chunks received, it
  same stream sequence number MUST ignore them.

3.3.1.1 Optional/Variable Length Parameters in INIT

The following parameters follow the Type-Length-Value format as
defined be carried in Section 3.2.1. The IP address fields MUST come after each of the fixed-length fields defined in fragments
  of the previous Section. message.

Payload Protocol Identifier: 32 bits (unsigned integer)

  This value represents an application (or upper layer) specified
  protocol identifier. This value is passed to SCTP by its upper layer
  and sent to its peer. This identifier is not used by SCTP but can be
  used by certain network entities as well as the peer application to
  identify the type of information being carried in this DATA chunk.
  This field must be sent even in fragmented DATA chunks (to make
  sure it is available for agents in the middle of the network).

  The value 0 indicates no application identifier is specified by
  the upper layer for this payload data.

User Data: variable length

  This is the payload user data. The implementation MUST pad the end
  of the data to a 4 byte boundary with all-zero bytes. Any extensions SHOULD come after padding
  MUST NOT be included in the IP address fields.

IPv4 Address Parameter length field. A sender MUST never add
  more than 3 bytes of padding.

3.3.2 Initiation (INIT) (1)

This chunk is used to initiate a SCTP association between two
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0
   |   Type = 1 0 0 0|    |  Chunk Flags  |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv4 Address                         Initiate Tag                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  IPv4 Address: 32 bit

    Contains an IPv4 address
   |           Advertised Receiver Window Credit (a_rwnd)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Number of the sending endpoint. It is binary
    encoded.

IPv6 Address Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         IPv6 Address                          | Outbound Streams   |  Number of Inbound Streams    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Initial TSN                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  IPv6 Address: 128 bit

    Contains an IPv6 address of the sending endpoint. It is binary
    encoded.

  Combining with
   \                                                               \
   /              Optional/Variable-Length Parameters              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The INIT chunk contains the Source Port Number following parameters. Unless otherwise
noted, each parameter MUST only be included once in the SCTP common header, the
  value passed in an INIT chunk.

Fixed Parameters                     Status
----------------------------------------------
Initiate Tag                        Mandatory
Advertised Receiver Window Credit   Mandatory
Number of Outbound Streams          Mandatory
Number of Inbound Streams           Mandatory
Initial TSN                         Mandatory

Variable Parameters                  Status     Type Value
-------------------------------------------------------------
IPv4 or Address (Note 1)               Optional    5
IPv6 Address parameter indicates a
  transport (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 be
IPv4 and/or IPv6 in any combination.

Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.

Note 3: An INIT chunk MUST NOT contain more than one Host Name address
parameter. Moreover, the sender of the INIT will support for the
  association being initiated. That is, during the lifetime of this
  association, this IP address may appear in the source MUST NOT combine any other
address field

Stewart, et al                                               [Page  19]
  of a datagram sent from the sender of types with the INIT, and may be used as a
  destination Host Name address of a datagram sent from in the INIT. The receiver
of INIT MUST ignore any other address types if the
  INIT.

  More than one IP Address Host Name address

parameter can be included is present in an the received INIT
  chunk chunk.

Note 4: This parameter, when present, specifies all the INIT sender is multi-homed. Moreover, a multi-homed
  endpoint may have access to different address types
the sending endpoint can support. The absence of network, thus more
  than one this parameter
indicates that the sending endpoint can support any address type may be present type.

The Chunk Flags field in one INIT chunk, i.e., IPv4 is reserved and IPv6 transport addresses are allowed all bits in it should be
set to 0 by the same INIT message.

  If the INIT contains at least one IP Address parameter, then only sender and ignored by the
  transport address(es) provided receiver. The sequence of
parameters within the an INIT may can be used as
  destinations by processed in any order.

Initiate Tag: 32 bits (unsigned integer)

  The receiver of the INIT (the responding end. If end) records the INIT does not contain any
  IP Address parameters, value of
  the responding end Initiate Tag parameter. This value MUST use the source
  address associated with be placed into the received
  Verification Tag field of every SCTP datagram as its sole
  destination address for packet that the association.

Cookie Preservative

  The sender receiver of the
  INIT shall use transmits within this parameter to suggest to the
  receiver of the INIT association.

  The Initiate Tag is allowed to have any value except 0. See
  Section 5.3.1 for a longer life-span of more on 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Suggested Cookie Life-span Increment (msec.)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Suggested Cookie Life-span Increment: 32bit u_int

  This parameter indicates to selection of the receiver how much increment tag value.

  If the
  sender wishes value of the receiver to add Initiate Tag in a received INIT chunk is found
  to its default cookie life-span.

  This optional parameter should be added to the INIT message by 0, the
  sender when receiver MUST treat it re-attempts establishing as an association with a peer
  to which its previous attempt of establishing error and close
  the association failed
  due to a Stale COOKIE error. Note, by transmitting an ABORT.

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)

  This value represents the receiver MAY choose to ignore dedicated buffer space, in number of
  bytes, the suggested cookie life-span increase for its own security
  reasons.

Host Name Address

  The sender of the INIT uses has reserved in association with this parameter to pass its Host Name (in
  place
  window. During the life of its IP addresses) to its peer. The peer is responsible for
  resolving the name.

   0                   1                   2                   3
   0 1 2 3 association this buffer space SHOULD
  not be lessened (i.e. dedicated buffers taken away from this
  association); however, an endpoint MAY change the value of 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 INIT chunk
  wishes to create in this association. The value of 0 MUST NOT be
  used.

  Note: A receiver of an INIT with the OS value set to 0 SHOULD ABORT
  the association.

Number of Inbound Streams (MIS) : 16 bits (unsigned integer)

  Defines the maximum number of streams the sender of this INIT chunk
  allows the peer end to create in this association. The value 0 MUST
  NOT be used.

  Note: There is no negotiation of the actual number of streams
  but 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 ABORT
  the association.

Initial TSN (I-TSN) : 32 bits (unsigned integer)

  Defines the initial TSN that the sender will use. The valid range is
  from 0 to 4294967295. This field MAY be set to the value of the
  Initiate Tag field.

3.3.2.1 Optional/Variable Length Parameters in INIT

The following parameters follow the Type-Length-Value format as
defined in Section 3.2.1. Any Type-Length-Value fields MUST come
after the fixed-length fields defined in the previous section.

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|
   |        Type = 5               |      Length = 8               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  /                          Host Name                            /
  \                                                               \
   |                        IPv4 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Host Name: variable length

  Defined as a zero terminated ASCII string with a variable
  length. The syntax

  IPv4 Address: 32 bits (unsigned integer)

    Contains an IPv4 address of the host name sending endpoint. It is out of scope of SCTP.

Supported binary
    encoded.

IPv6 Address Types

  The sender of INIT uses this parameter to list all the address types
  it can support. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|
   |            Type = 6           |          Length = 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Type #1                                                               |
   |                         IPv6 Address Type #2                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ......
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Address Type: 16                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  IPv6 Address: 128 bit u_int

  This (unsigned integer)

    Contains an IPv6 address of the sending endpoint. It is filled binary
    encoded.

  Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
  but should instead use an IPv4 Address Parameter for an IPv4 address.

  Combined with the type value of Source Port Number in the corresponding address
  TLV (e.g., SCTP common header, the
  value passed in an IPv4 = 0x0005, or IPv6 = 0x0006).

3.3.2 Initiation Acknowledgment (INIT ACK) (00000010):

The Address parameter indicates a
  transport address the sender of the INIT ACK chunk is used to acknowledge will support for the initiation
  association being initiated. That is, during the lifetime of this
  association, this IP address can appear in the source address field
  of an SCTP
association.

The parameter part IP datagram sent from the sender of INIT ACK is formatted similarly to the INIT
chunk. It uses two extra variable parameters: The State Cookie INIT, and can be used
  as a destination address of an IP datagram sent from the Unrecognized Parameter:

The format receiver of
  the INIT ACK message INIT.

  More than one IP Address parameter can be included in an INIT
  chunk when the INIT sender is shown below:

Stewart, et al                                               [Page  20] multi-homed. Moreover, a multi-homed
  endpoint may have access to different types of network, thus 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 the
  source address of the IP datagram containing the INIT chunk and any
  additional address(es) provided within the INIT can be used as
  destinations by the endpoint receiving the INIT.  If the INIT does
  not contain any IP Address parameters, the endpoint receiving the
  INIT MUST use the source address associated with the received IP
  datagram as its sole destination address for the association.

  Note that not using any IP address parameters in the INIT and INIT-ACK
  is an alternative to make an association more likely to work across
  a NAT box.

Cookie Preservative (9)

  The sender of the INIT shall use this parameter to suggest to the
  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 1 0|  Chunk Flags  |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Initiate Tag                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Advertised Receiver Window Credit                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Number of Outbound Streams          Type = 9             |  Number of Inbound Streams          Length = 8           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Initial TSN         Suggested Cookie Life-span Increment (msec.)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /              Optional/Variable-Length Parameters              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The INIT ACK contains

  Suggested Cookie Life-span Increment: 32 bits (unsigned integer)

    This parameter indicates to the following parameters. Unless otherwise
noted, each receiver how much increment in
    milliseconds the sender wishes the receiver to add to its default
    cookie life-span.

  This optional parameter MUST only should be included once in added to the INIT ACK chunk.

Fixed Parameters                     Status
----------------------------------------------
Initiate Tag                        Mandatory
Advertised Receiver Window Credit   Mandatory
Number of Outbound Streams          Mandatory
Number chunk by the
  sender when it re-attempts establishing an association with a peer
  to which its previous attempt of Inbound Streams           Mandatory
Initial TSN                         Mandatory

Variable Parameters                  Status     Type Value
-------------------------------------------------------------
State Cookie                        Mandatory   0x0007
IPv4 Address (Note 1)               Optional    0x0005
IPv6 Address (Note 1)               Optional    0x0006
Unrecognized Parameters             Optional    0x0008
Reserved establishing the association failed
  due to a stale cookie operation error.  The receiver MAY choose to
  ignore the suggested cookie life-span increase for ECN Capable (Note 2)   Optional    0x000a its own security
  reasons.

Host Name Address (Note 3)          Optional    0x000b

Note 1: The INIT ACK chunks may contain any number of IP address
parameters that may be IPv4 and/or IPv6 in any combination.

Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.

Note 3: (11)
  The INIT ACK chunks may contain AT MOST one Host Name address
parameter. Moreover, the sender of the INIT ACK SHALL not combine any
other address types with the uses this parameter to pass its Host Name address in the INIT ACK while
the receiver (in
  place of its IP addresses) to its peer. The peer is responsible for
  resolving the INIT ACK MUST ignore any other address types if
the Host Name address name. Using this parameter is present.

Same as with INIT, in combination with might make it more likely
  for the Source Port carried in the
SCTP common header, each IP Address parameter in the INIT ACK indicates association to the receiver of the INIT ACK work across a valid transport address supported by
the sender of the INIT ACK NAT box.

   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 = 11            |          Length               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  /                          Host Name                            /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Host Name: variable length

    This field contains a host name in "host name syntax" per RFC1123
    Section 2.1 [RFC1123].  The method for resolving the lifetime host name is
    out of the association being
initiated.

If the INIT ACK contains at scope of SCTP.

    Note: At least one IP Address parameter, then only
the transport address(es) explicitly indicated null terminator is included in the INIT ACK may Host Name
    string and must be
used as the destination(s) by included in the receiver length.

Supported Address Types (12)

  The sender of the INIT ACK. However,
if uses this parameter to list all the INIT ACK contains no IP address types
  it can support.

   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 = 12            |          Length               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Address parameter, Type #1        |        Address Type #2        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        ......
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Address Type: 16 bits (unsigned integer)

    This is filled with the receiver type value of the
INIT ACK MUST take the source IP corresponding address associated with this
    TLV (e.g., IPv4 = 5, IPv6 = 6, Hostname = 11).

3.3.3 Initiation Acknowledgement (INIT ACK) (2):

The INIT ACK
as its sole destination address for this chunk is used to acknowledge the initiation of an SCTP
association.

Stewart, et al                                               [Page  21]

The parameter part of INIT ACK is formatted similarly to the INIT
chunk. It uses two extra variable parameters: The State Cookie
and Unrecognized Parameters use the Type-Length-
Value format as defined in Section 3.2.1 and are described below. Unrecognized Parameter:

The
other fields are defined the same as their counterparts in format of the INIT
message.

3.3.2.1 Optional or Variable ACK 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 = 2    |  Chunk Flags  |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Initiate Tag                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Advertised Receiver Window Credit                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Number of Outbound Streams   |  Number of Inbound Streams    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Initial TSN                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /              Optional/Variable-Length Parameters

State Cookie: variable size, depending on Size              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Initiate Tag: 32 bits (unsigned integer)

  The receiver of Cookie the INIT ACK (the responding end) records the value
  of the Initiate Tag parameter. This field value MUST contain all the necessary state and parameter
  information required for be placed into the sender
  Verification Tag field of this every SCTP packet that the INIT ACK to create
  receiver transmits within this association.

  The Initiate Tag MUST NOT take the
  association, along with an Integrity Check Value (ICV). value 0.  See Section 5.1.3 5.3.1 for details
  more on Cookie definition. The Cookie MUST be
  padded with '0' to the next 32-bit word boundary. The internal
  format selection of the Cookie is implementation-specific.

Unrecognized Parameters: Variable Size.

  This parameter is returned to Initiate Tag value.

  If the originator value of the Initiate Tag in a received INIT message if ACK chunk is
  found to be 0, the receiver does not recognize one or more Optional TLV parameters
  in MUST treat it as an error and close the INIT chunk.
  association by transmitting an ABORT.

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)

  This parameter field will contain value represents the
  unrecognized parameters copied from dedicated buffer space, in number of
  bytes, the sender of the INIT message complete
  with TLV.

Vendor-Specific parameters are allowed ACK has reserved in INIT ACK. However, they
MUST be defined using association with
  this window. During the format described in Section 3.2.2, and life of the association this buffer space
  SHOULD not be
appended to lessened (i.e. dedicated buffers taken away from this
  association).

Number of Outbound Streams (OS):  16 bits (unsigned integer)

  Defines the end number of outbound streams the above sender of this INIT ACK chunk. In case the
  chunk wishes to create in this association. The value of 0 MUST NOT
  be used.

  Note: A receiver of the an INIT ACK does not support the vendor-specific parameters
received, it MUST ignore those fields.

3.3.3 Selective Acknowledgment (SACK) (00000011):

This chunk is sent to  with the remote endpoint to acknowledge received DATA
chunks and OS value set to inform 0 SHOULD destroy
  the remote endpoint association discarding its TCB.

Number of gaps in Inbound Streams (MIS) : 16 bits (unsigned integer)

  Defines the received
subsequences maximum number of DATA chunks as represented by their TSNs.

The SACK MUST contain streams the Cumulative TSN sender of this INIT ACK and Advertised Receiver
Window Credit (a_rwnd) parameters. By definition,
  chunk allows the peer end to create in this association. The value of the
Cumulative TSN ACK parameter 0
  MUST NOT be used.

  Note: There is no negotiation of the last TSN received at actual number of streams but
  instead the time two endpoints will use the
Selective min(requested,
  offered). See Section 5.1.1 for details.

  Note: A receiver of an INIT ACK is sent, before a break in  with the sequence of received TSNs
occurs; MIS value set to 0 SHOULD destroy
  the next association discarding its TCB.

Initial TSN value following this one has not yet been
received at (I-TSN) : 32 bits (unsigned integer)

  Defines the reporting end. initial TSN that the INIT-ACK sender will use. The valid
  range is from 0 to 4294967295. This parameter therefore acknowledges
receipt of all TSNs up field MAY be set to and including the value given.

The handling of the a_rwnd by the receiver of the SACK is discussed in
detail in Section 6.2.1.

The Selective ACK also contains zero or more fragment reports. Each
fragment report acknowledges a subsequence
  of TSNs received following
a break in the sequence Initiate Tag field.

Fixed Parameters                     Status
----------------------------------------------
Initiate Tag                        Mandatory
Advertised Receiver Window Credit   Mandatory
Number of received TSNs.  By definition, all TSNs
acknowledged by fragment reports are higher than the value Outbound Streams          Mandatory
Number of the
Cumulative Inbound Streams           Mandatory
Initial TSN ACK.

Stewart, et al                                               [Page  22]
     0                   1                   2                   3
     0 1 2 3 4 5 6                         Mandatory

Variable Parameters                  Status     Type Value
-------------------------------------------------------------
State Cookie                        Mandatory   7 8 9 0 1 2 3 4
IPv4 Address (Note 1)               Optional    5
IPv6 Address (Note 1)               Optional    6 7
Unrecognized Parameters             Optional    8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 0 1 1|Chunk  Flags   |      Chunk Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Cumulative TSN
Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
Host Name Address (Note 3)          Optional    11

  Note 1: The INIT ACK                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Advertised Receiver Window Credit (a_rwnd)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Number of Fragments = N    |  Number of Duplicate TSNs = X |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Fragment #1 Start         |   Fragment #1 End             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Fragment #N Start         |   Fragment #N End             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Duplicate TSN 1                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Duplicate TSN X                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

  Set to all zeros on transmit and ignored on receipt.

Cumulative TSN ACK: 32 bit u_int

  This parameter contains the TSN chunks can contain any number of the last DATA chunk received IP address
  parameters that can be IPv4 and/or IPv6 in
  sequence before a gap.

Advertised Receiver Window Credit (a_rwnd): 32 bit u_int

  This any combination.

  Note 2: The ECN capable field indicates the updated receive buffer space in octets is reserved for future use of Explicit
  Congestion Notification.

  Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
  address parameter. Moreover, the sender of this SACK, see Section 6.2.1 for details.

Number of Fragments: 16 bit u_int

  Indicates the number of TSN fragments included INIT ACK MUST NOT
  combine any other address types with the Host Name address in this Selective
  ACK.

Number of Duplicate TSNs: 16 bit

  This field contains the number
  INIT ACK. The receiver of duplicate TSNs the endpoint
  has received. Each duplicate TSN is listed following the fragment
  list.

Fragments:

  These fields contain INIT ACK MUST ignore any other
  address types if the ack fragments. They are repeated for each
  fragment up Host Name address parameter is present.

    IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
    a INIT ACK that is quite large (more than 1500 bytes) due to
    the number variable size of fragments defined in the Number of
  Fragments field. All DATA chunks with TSNs between state cookie AND the (Cumulative
  TSN ACK + Fragment Start) and (Cumulative TSN ACK + Fragment End) of
  each fragment are assumed variable address
    list. For example if a responder to have been received correctly.

Stewart, et al                                               [Page  23]

Fragment Start: 16 bit u_int

  Indicates the Start offset TSN for this fragment. To calculate the
  actual TSN number the Cumulative TSN ACK is added INIT has 1000 IPv4
    addresses it wishes to this
  offset number send, it would need at least 8,000 bytes
    to yield encode this in the TSN. This calculated TSN identifies INIT ACK.

In combination with the first TSN Source Port carried in this fragment that has been received.

Fragment End:  16 bit u_int

  Indicates the End offset TSN for this fragment. To calculate the
  actual TSN number SCTP common header,
each IP Address parameter in the Cumulative TSN INIT ACK is added to this
  offset number indicates to yield the TSN. This calculated TSN identifies the TSN receiver of
the last DATA chunk received in this fragment.

Duplicate TSN: 32 bit u_int

  Indicates INIT ACK a TSN that was received in duplicate.

For example, assume valid transport address supported by the receiver has sender of the following datagrams newly
arrived at
INIT ACK for the time when it decides to send a Selective ACK,

                 ----------
                 | TSN=17 |
                 ----------
                 |        | <- still missing
                 ----------
                 | TSN=15 |
                 ----------
                 | TSN=14 |
                 ----------
                 |        | <- still missing
                 ----------
                 | TSN=12 |
                 ----------
                 | TSN=11 |
                 ----------
                 | TSN=10 |
                 ----------

then, lifetime of the parameter part association being initiated.

If the INIT ACK contains at least one IP Address parameter, then the
source address of the Selective IP datagram containing the INIT ACK MUST and any
additional address(es) provided within the INIT ACK may be constructed used as
follows (assuming the new a_rwnd is set to 0x1234
destinations by the sender):

        +---------------+--------------+
        |   Cumulative TSN ACK = 12    |
        ----------------+---------------
        |        a_rwnd = 0x1234       |
        ----------------+---------------
        | num of frag=2 | num of dup=0 |
        ----------------+---------------
        |frag #1 strt=2 |frag #1 end=3 |
        ----------------+---------------
        |frag #2 strt=5 |frag #2 end=5 |
        --------------------------------

Stewart, et al                                               [Page  24]

3.3.4 Heartbeat Request (HEARTBEAT) (00000100):

An endpoint should send this chunk to its peer endpoint receiver of the current
association to probe INIT-ACK.  If the reachability INIT ACK does not
contain any IP Address parameters, the receiver of a particular the INIT-ACK MUST
use the source address associated with the received IP datagram as its
sole destination
transport address defined in for the present association.

The parameter field contains State Cookie and Unrecognized Parameters use the Heartbeat Information which is a
variable length opaque data structure understood only by Type-Length-
Value format as defined in Section 3.2.1 and are described below. The
other fields are defined the sender.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 same as their counterparts in the INIT
chunk.

3.3.3.1 Optional or Variable Length Parameters

State Cookie
    Parameter Type Value: 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 1 0 0| Chunk  Flags  |      Heartbeat Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /            Heartbeat Information (Variable-Length)            /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

  Set to zero

    Parameter Length:  variable size, depending on transmit Size of Cookie

    Parameter Value:
      This parameter value MUST contain all the necessary state and ignored
      parameter information required for the sender of this INIT ACK to
      create the association, along with Message Authentication Code
      (MAC). See Section 5.1.3 for details on receipt.

Heartbeat State Cookie definition.

Unrecognized Parameters:
    Parameter Type Value: 8

    Parameter Length:

  Set  Variable Size.

    Parameter Value:
      This parameter is returned to the size originator of the INIT chunk in octets, including the chunk header
  and
      when the Heartbeat Information field.

Heartbeat Information:

  defined as a variable-length INIT contains an unrecognized parameter using which has a value
      that indicates that it should be reported to the format described in
  Section 3.2.1, i.e.:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Heartbeat Info Type=1      |         HB Info Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                  Sender-specific Heartbeat Info               /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Sender-specific Heartbeat Info sender. This parameter
      value field should normally include
  information about will contain unrecognized parameters copied from
      the sender's current time when this HEARTBEAT
  message INIT chunk complete with Parameter Type, Length and Value fields.

3.3.4 Selective Acknowledgement (SACK) (3):

This chunk is sent and to the destination transport address peer endpoint to which this
  HEARTBEAT is sent (see Section 8.3).

Stewart, et al                                               [Page  25]

3.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK) (00000101):

An endpoint should send this chunk acknowledge received DATA
chunks and to its inform the peer endpoint of gaps in the received
subsequences of DATA chunks as represented by their TSNs.

The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver
Window Credit (a_rwnd) parameters.

By definition, the value of the Cumulative TSN Ack parameter is the
last TSN received before a response break in the sequence of received TSNs
occurs; the next TSN value following this one has not yet been received
at the endpoint sending the SACK. This parameter therefore acknowledges
receipt of all TSNs less than or equal to a Heartbeat Request (see its value.

The handling of a_rwnd by the receiver of the SACK is discussed in
detail in Section 8.3). 6.2.1.

The parameter field SACK also contains zero or more Gap Ack Blocks. Each
Gap Ack Block acknowledges a variable length opaque data structure. subsequence of TSNs received following
a break in the sequence of received TSNs.  By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 1 0 1| Chunk
    |   Type = 3    |Chunk  Flags   |    Heartbeat Ack      Chunk Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    |                      Cumulative TSN Ack                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Advertised Receiver Window Credit (a_rwnd)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Number of Gap Ack Blocks = N  |  Number of Duplicate TSNs = X |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Gap Ack Block #1 Start       |   Gap Ack Block #1 End        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /            Heartbeat Information (Variable-Length)                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

  Set to zero on transmit and ignored on receipt.

Heartbeat
    |   Gap Ack Length: Block #N Start      |  Gap Ack Block #N End         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Duplicate TSN 1                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Duplicate TSN X                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

  Set to all zeros on transmit and ignored on receipt.

Cumulative TSN Ack: 32 bits (unsigned integer)

  This parameter contains the size TSN of the last DATA chunk received in octets, including
  sequence before a gap.

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)

  This field indicates the chunk header
  and updated receive buffer space in bytes of
  the Heartbeat Information field.

Heartbeat Information:

  The values sender of this field SHALL be copied from SACK, see Section 6.2.1 for details.

Number of Gap Ack Blocks: 16 bits (unsigned integer)

  Indicates the Heartbeat
  Information field found number of Gap Ack Blocks included in the Heartbeat Request to which this
  Heartbeat Acknowledgment is responding.

3.3.6 Abort Association (ABORT) (00000110):

The ABORT chunk is sent to SACK.

Number of Duplicate TSNs: 16 bit

  This field contains the peer number of an association to terminate duplicate TSNs the
association. The ABORT chunk may endpoint
  has received. Each duplicate TSN is listed following the Gap Ack
  Block list.

Gap Ack Blocks:

  These fields contain cause parameters to inform the receiver Gap Ack Blocks. They are repeated for each
  Gap Ack Block up to the reason number of Gap Ack Blocks defined in the abort.
  Number of Gap Ack Blocks field. All DATA chunks MUST not be bundled
with ABORT. Control chunks MAY be bundled with an ABORT but they MUST
be placed before the ABORT in the SCTP datagram, or they will be
ignored by the receiver.

If an endpoint receives an ABORT with a format error TSNs greater
  than or for an
association that doesn't exist, it MUST silently discard it.
Moreover, under any circumstances, an endpoint that receives an ABORT
MUST never respond to that ABORT by sending an ABORT of its own.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 1 1 0| Chunk  Flags  |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                   zero or more Error Causes                   /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stewart, et al                                               [Page  26]

Chunk Flags:

  Set equal to zero on transmit (Cumulative TSN Ack + Gap Ack Block Start) and ignored on receipt.

Length:

  Set less
  than or equal to the size (Cumulative TSN Ack + Gap Ack Block End) of each Gap
  Ack Block are assumed to have been received correctly.

Gap Ack Block Start: 16 bits (unsigned integer)

  Indicates the chunk in octets, including Start offset TSN for this Gap Ack Block. To calculate
  the chunk header
  and all actual TSN number the Error Cause fields present.

See Section 3.3.9 for Error Cause definitions.

Note: Special rules apply Cumulative TSN Ack is added to this
  offset number. This calculated TSN identifies the Verification Tag field of SCTP
datagrams which carry an ABORT, see Section 8.5.1 for details.

3.3.7 SHUTDOWN (00000111):

An endpoint first TSN in an association MUST use this chunk to initiate a
graceful termination of the association with its peer.  This chunk
  Gap Ack Block that has been received.

Gap Ack Block End:  16 bits (unsigned integer)

  Indicates the following format.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 1 1 1|Chunk  Flags   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Cumulative End offset TSN ACK                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

  Set to zero on transmit and ignored on receipt. for this Gap Ack Block. To calculate the
  actual TSN number the Cumulative TSN ACK: 32 bit u_int Ack is added to this
  offset number. This parameter contains calculated TSN identifies the TSN of the last
  DATA chunk received in
  sequence before any gaps.

Stewart, et al                                               [Page  27]

3.3.8 Shutdown Acknowledgment (SHUTDOWN ACK) (00001000):

This chunk this Gap Ack Block.

For example, assume the receiver has the following DATA chunks newly
arrived at the time when it decides to send a Selective ACK,

                 ----------
                 | TSN=17 |
                 ----------
                 |        | <- still missing
                 ----------
                 | TSN=15 |
                 ----------
                 | TSN=14 |
                 ----------
                 |        | <- still missing
                 ----------
                 | TSN=12 |
                 ----------
                 | TSN=11 |
                 ----------
                 | TSN=10 |
                 ----------

then, the parameter part of the SACK MUST be used constructed as
follows (assuming the new a_rwnd is set to acknowledge 4660 by the receipt sender):

        +--------------------------------+
        |   Cumulative TSN Ack = 12      |
        +--------------------------------+
        |        a_rwnd = 4660           |
        +----------------+---------------+
        | num of block=2 | num of dup=0  |
        +----------------+---------------+
        |block #1 strt=2 |block #1 end=3 |
        +----------------+---------------+
        |block #2 strt=5 |block #2 end=5 |
        +----------------+---------------+

Duplicate TSN: 32 bits (unsigned integer)

  Indicates the SHUTDOWN
chunk at the completion number of times a TSN was received in duplicate since
  the shutdown process, see Section 9.2 for
details.

The SHUTDOWN ACK chunk has no parameters.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 1 0 0 0|Chunk  Flags   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:

  Set last SACK was sent. Every time a receiver gets a duplicate TSN
  (before sending the SACK) it adds it to the list of duplicates. The
  duplicate count is re-initialized to zero on transmit and ignored on receipt.

Note: after sending each SACK.

  For example, if the endpoint that receives the SHUTDOWN message does not have a TCB or tag for the sender of receiver were to get the SHUTDOWN, TSN 19 three times
  it would list 19 twice in the receiver MUST still
respond. In such cases, outbound SACK. After sending the receiver MUST send back
  SACK if it received yet one more TSN 19 it would list 19 as a stand-alone
SHUTDOWN ACK chunk
  duplicate once in an SCTP datagram with the Verification Tag field
of the common header filled with all '0's.

3.3.9 Operation Error (ERROR) (00001001):

This next outgoing SACK.

3.3.5 Heartbeat Request (HEARTBEAT) (4):

An endpoint should send this chunk is sent to the other its peer endpoint to probe the
reachability of a particular destination transport address defined in
the association to notify
certain error conditions. It present association.

The parameter field contains one or more error causes. It has the following parameters: Heartbeat Information which is a
variable length opaque data structure understood only by the sender.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 1 0 0 1|
    |   Type = 4    | Chunk  Flags  |      Heartbeat Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                    one or more Error Causes            Heartbeat Information TLV (Variable-Length)        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits
  Set to zero on transmit and ignored on receipt.

Heartbeat Length: 16 bits (unsigned integer)

  Set to the size of the chunk in octets, bytes, including the chunk header
  and all the Error Cause fields present.

Error causes are defined Heartbeat Information field.

Heartbeat Information: variable length

  Defined as a variable-length parameters parameter using the format described in
  Section 3.2.1, i.e.:

Stewart, et al                                               [Page  28]

  Variable Parameters                  Status     Type Value
  -------------------------------------------------------------
  Heartbeat Info                       Mandatory   1

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Cause Code    Heartbeat Info Type=1      |       Cause         HB Info Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                    Cause-specific Information                  Sender-specific Heartbeat Info               /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cause Code: 16 bit u_int

  Defines

  The Sender-specific Heartbeat Info field should normally include
  information about the type senders current time when this HEARTBEAT
  chunk is sent and the destination transport address to which this
  HEARTBEAT is sent (see Section 8.3).

3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):

An endpoint should send this chunk to its peer endpoint as a response
to a HEARTBEAT chunk (see Section 8.3).  A HEARTBEAT ACK is always
sent to the source IP address of error conditions being reported.

Cause the IP datagram containing the
HEARTBEAT chunk to which this ack is responding.

The parameter field contains a variable length opaque data structure.

     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    | Chunk  Flags  |    Heartbeat Ack Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /            Heartbeat Information TLV (Variable-Length)        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits
  Set to zero on transmit and ignored on receipt.

Heartbeat Ack Length:  16 bit u_int bits (unsigned integer)

  Set to the size of the parameter chunk in octets, bytes, including the Cause Code,
  Cause Length, chunk header
  and Cause-Specific the Heartbeat Information fields

Cause-specific field.

Heartbeat Information: variable length

  This field carries MUST contain the details Heartbeat Information parameter of
  the error condition.

Currently SCTP defines the following error causes:

  Cause of error
  ---------------
  Invalid Stream Identifier: indicating receiving a DATA sent Heartbeat Request to a
  nonexistent stream.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=1              |      Cause Length=8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Stream Identifier      |         (Reserved)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Cause of error
  ---------------
  Missing Mandatory Parameter: indicating that mandatory one or more
  TLV parameters are missing in a received INIT or INIT ACK.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=2              |      Cause Length=8+N*2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Number of missing params=N                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Missing Param Type #1       |   Missing Param Type #2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Missing Param Type #N-1     |   Missing Param Type #N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Each missing mandatory parameter type should be specified.

Stewart, et al                                               [Page  29]
  Cause of error
  --------------
  Stale Cookie Error: indicating the receiving of a valid cookie which this Heartbeat Acknowledgement is however expired.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=3              |       Cause Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Measure of Staleness (usec.)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  responding.

  Variable Parameters                  Status     Type Value
  -------------------------------------------------------------
  Heartbeat Info                       Mandatory   1

3.3.7 Abort Association (ABORT) (6):

The sender of this error cause MAY choose ABORT chunk is sent to report how long past
  expiration the cookie is, by putting in the Measure peer of Staleness
  field the difference, in microseconds, between the current time and an association to close the time
association. The ABORT chunk may contain Cause Parameters to inform
the cookie expired. If receiver the sender does not wish to provide
  this information it should set Measure of staleness to 0.

  Cause of error
  ---------------
  Out reason of Resource: indicating that the sender is out of resource. This
  is usually sent in combination abort. DATA chunks MUST NOT be bundled
with or within an ABORT.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=4              |      Cause Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Cause of error
  ---------------
  Unresolvable Address: indicating that Control chunks (except for INIT, INIT ACK and SHUTDOWN
COMPLETE) MAY be bundled with an ABORT but they MUST be placed before
the sender is not able to
  resolve ABORT in the specified address parameter (e.g., type of address is
  not supported SCTP packet, or they will be ignored by the sender). This is sent within receiver.

If an ABORT. endpoint receives an ABORT with a format error or for an
association that doesn't exist, it MUST silently discard it.
Moreover, under any circumstances, an endpoint that receives an ABORT
MUST NOT respond to that ABORT by sending an ABORT of its own.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Cause Code=5              |      Cause   Type = 6    |Reserved     |T|           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                  The Unresolvable Address                   zero or more Error Causes                   /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

  Reserved:  7 bits
    Set to 0 on transmit and ignored on receipt.

  T bit:  1 bit
    The parameter field contains T bit is set to 0 if the complete TLV of sender had a TCB that it destroyed. If
    the unresolvable
  address.

  Cause of error
  ---------------
  Unrecognized Parameters: This error cause is returned sender did NOT have a TCB it should set this bit to 1.

Note: Special rules apply to this chunk for verification, please

see Section 8.5.1 for details.

Length:  16 bits (unsigned integer)

  Set to the
  originator size of the INIT ACK message if the receiver does not
  recognize one or more Optional TLV parameters chunk in bytes, including the INIT ACK chunk.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=8              |      Cause Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                  The Unrecognized Parameters                  /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The error field will contain the unrecognized parameters copied
  from the INIT ACK message complete with TLV. This error is normally
  bundled with the Cookie chunk when responding to the INIT ACK, when
  the sender of header
  and all the Cookie wishes to report unrecognized parameters.

Guidelines Error Cause fields present.

See Section 3.3.10 for IETF-defined Error Cause extensions are discussed definitions.

3.3.8 Shutdown Association (SHUTDOWN) (7):

An endpoint in
Section 13.3 of an association MUST use this document.

3.3.10 State Cookie (COOKIE) (00001010):

This chunk is used only during the initialization to initiate a
graceful close of an association.
It is sent by the initiator of an association to with its peer to complete
the initialization process. peer.  This chunk MUST precede any chunk
sent within the association, but MAY be bundled with one or more DATA
chunks in has
the same datagram. following format.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 1 0 1 0|Chunk
    |   Type = 7    | Chunk  Flags  |      Length = 8               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Cookie                      Cumulative TSN Ack                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bit bits

  Set to zero on transmit and ignored on receipt.

Length:  16 bit u_int

  Set to bits (unsigned integer)
  Indicates the size length of the chunk in octets, including parameter.  Set to 8.

Cumulative TSN Ack: 32 bits (unsigned integer)

  This parameter contains the 4 octets TSN of the last chunk header and the size of the Cookie.

Stewart, et al                                               [Page  30]

Cookie: variable size

  This field must contain the exact cookie received in
  sequence before any gaps.

  Note:  Since the
  State Cookie parameter from a previous INIT ACK.

3.3.11 Cookie Acknowledgment (COOKIE ACK) (00001011):

This chunk is used only during the initialization of an association.
It is SHUTDOWN message does not contain Gap Ack Blocks, it
  cannot be used to acknowledge the receipt TSNs received out of order.  In a COOKIE chunk. SACK,
  lack of Gap Ack Blocks that were previously included indicates that
  the data receiver reneged on the associated DATA chunks.  Since
  SHUTDOWN does not contain Gap Ack Blocks, the receiver of the
  SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege.
  (see Section 6.2 for information on reneging)

3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (8):

This chunk MUST precede any be used to acknowledge the receipt of the SHUTDOWN
chunk sent within at the association, but MAY be
bundled with one or more DATA chunks in completion of the same SCTP datagram. shutdown process, see Section 9.2 for
details.

The SHUTDOWN ACK chunk has no parameters.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 1 0 1 1|Chunk
    |   Type = 8    |Chunk  Flags   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|   |      Length = 4               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags:  8 bits

  Set to zero on transmit and ignored on receipt.

3.3.12 Payload Data (DATA) (00000000):

The following format MUST

3.3.10 Operation Error (ERROR) (9):

An endpoint sends this chunk to its peer endpoint to notify it of
certain error conditions. It contains one or more error causes. An
Operation Error is not considered fatal in and of itself, but may be
used for with an ABORT chunk to report a fatal condition. It has the DATA chunk:
following parameters:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0| Reserved|U|B|E|    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S
    |   Stream Sequence Number n   Type = 9    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk  Flags  |                  Payload Protocol Identifier           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                 User Data (seq n of Stream S)                    one or more Error Causes                   /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved: 5

Chunk Flags:  8 bits
  should be set

  Set to all '0's zero on transmit and ignored by the receiver.

U bit: 1 bit
  The (U)nordered bit, if set, indicates that this is an unordered
  data chunk, and there is NO Stream Sequence Number assigned to this
  DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence
  Number field.

Stewart, et al                                               [Page  31]
  After re-assembly (if necessary), unordered data chunks MUST be
  dispatched to the upper layer by the receiver without any attempt of
  re-ordering.

  Note, if an unordered user message is segmented, each segment of the
  message MUST have its U bit set on receipt.

Length:  16 bits (unsigned integer)

  Set to 1.

B bit: 1 bit

  The (B)eginning segment bit, if set, indicates the first segment size of
  a user message.

E bit:  1 bit
  The (E)nding segment bit, if set, indicates the last segment of a
  user message.

A non-segmented user message shall have both chunk in bytes, including the B and E bits set
to 1. Setting both B chunk header
  and E bits to 0 indicates a middle segment of a
multi-segment user message, all the Error Cause fields present.

Error causes are defined as summarized in variable-length parameters using the following table:

       B E                  Description
    ============================================================
    |
format described in 3.2.1, i.e.:

     0                   1                   2                   3
     0 | First piece of a segmented user message           |
    +----------------------------------------------------------+
    | 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 | Middle piece of a segmented user message          |
    +----------------------------------------------------------+
    | 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Last piece of a segmented user message            |
    +----------------------------------------------------------+
    |  1 1           Cause Code          | Un-segmented Message       Cause Length            |
    ============================================================

Length:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                    Cause-specific Information                 /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cause Code: 16 bits (16 bit u_int)

  This field indicates (unsigned integer)

  Defines the length type of the DATA chunk in octets.  It
  includes the Type field, the Reserved field, the U and B/E bits, the
  Length field, TSN, the Stream Identifier, the error conditions being reported.

  Cause Code
  Value           Cause Code
  ---------      ----------------
   1              Invalid Stream Sequence
  Number, and the Identifier
   2              Missing Mandatory Parameter
   3              Stale Cookie Error
   4              Out of Resource
   5              Unresolvable Address
   6              Unrecognized Chunk Type
   7              Invalid Mandatory Parameter
   8              Unrecognized Parameters
   9              No User Data fields. It does not include any padding.

TSN : 32
  10              Cookie Received While Shutting Down

Cause Length: 16 bits (32 bit u_int)

  This value represents (unsigned integer)

  Set to the TSN for this DATA chunk. The valid range size of TSN is from 0x0 to 0xffffffff.

Stream Identifier S: 16 bit u_int

  Identifies the stream to which parameter in bytes, including the following user data belongs.

Stream Sequence Number n: 16 bit u_int Cause Code,
  Cause Length, and Cause-Specific Information fields

Cause-specific Information: variable length

  This value presents field carries the stream sequence number details of the following user
  data within the stream S. Valid range is 0x0 to 0xFFFF.

  Note, when a user message is segmented by SCTP error condition.

Sections 3.3.10.1 - 3.3.10.8 define error causes for SCTP.  Guidelines
for transport, the
  same stream sequence number MUST be carried IETF to define new error cause values are discussed in each Section
13.3.

3.3.10.1	 Invalid Stream Identifier (1)

  Cause of error
  ---------------
  Invalid Stream Identifier:  Indicates endpoint received a DATA chunk
  sent to a nonexistent stream.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=1              |      Cause Length=8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Stream Identifier      |         (Reserved)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Stream Identifier: 16 bits (unsigned integer)
     Contains the segments Stream Identifier of the message.

Stewart, et al                                               [Page  32]

Payload Protocol Identifier: 32 DATA chunk received in
     error.

   Reserved: 16 bits (32 bit u_int)
    This value represents an application (or upper layer) specified
  protocol identifier. This value field is passed to SCTP by its upper layer
  and sent to its peer. This identifier reserved.  It is not used by SCTP but may be
  used by certain network entities as well as the peer application set to
  identify the type all 0's on transmit and
    Ignored on receipt.

3.3.10.2	 Missing Mandatory Parameter (2)

  Cause of information being carried error
  ---------------
  Missing Mandatory Parameter:  Indicates that one or more
  mandatory TLV parameters are missing in this DATA chunk.

  The value 0x0 indicates no application identifier is specified by
  the upper layer for this payload data.

User Data: variable length a received INIT or INIT ACK.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=2              |      Cause Length=8+N*2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Number of missing params=N                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Missing Param Type #1       |   Missing Param Type #2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Missing Param Type #N-1     |   Missing Param Type #N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Number of Missing params:  32 bits (unsigned integer)

     This is the payload user data. The implementation MUST pad field contains the end number of parameters contained in the data to
     Cause-specific Information field.

   Missing Param Type:  16 bits (unsigned integer)

    This field contains a 32 bit boundary with 0 octets. Any padding MUST
  NOT be included mandatory parameter that was missing in the length field.

3.4 Vendor-Specific Chunk Extensions
    INIT or INIT ACK message.  This Chunk type is available to allow vendors to support their own
extended data formats not defined by field contains the IETF. It MUST not affect complete
    Parameter, including Type, Length and Value fields.

3.3.10.3	 Stale Cookie Error (3)

  Cause of error
  --------------
  Stale Cookie Error:  Indicates the
operation receipt of SCTP. In particular, when adding a Vendor Specific chunk
type, the vendor defined chunks MUST obey the congestion avoidance
rules defined in this document if they carry user data. User data is
defined as any data transported over the association that is delivered
to the upper layer of the receiver.

Endpoints not equipped to interpret the vendor-specific chunk sent by
a remote endpoint MUST ignore it. Endpoints valid State Cookie
  that do not receive
desired vendor specific information SHOULD make an attempt to operate
without it, although they may do so (and report they are doing so) in
a degraded mode.

A summary of the Vendor-Specific Chunk format is shown below.  The
fields are transmitted from left to right.

    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 has expired.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Flags     Cause Code=3              |             Length       Cause Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Vendor-Id                 Measure of Staleness (usec.)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                    Value                                      /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: 8 bit u_int

      0xFE for all Vendor-Specific chunks.

Stewart, et al                                               [Page  33]
   Flags: 8 bit u_int

      Vendor specific flags.

   Length: 16 bit u_int

      Size

  Measure of this Vendor-Specific chunks in octets, including the Type,
      Flags, Length, Vendor-Id, and Value fields.

   Vendor-Id: Staleness:  32 bit u_int bits (unsigned integer)
    This field contains the difference, in microseconds, between
    The high-order octet is 0 current time and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order, as defined in time the Assigned Numbers (RFC 1700).

   Value: Variable length

      The Value field is one or more octets. State Cookie expired.

  The actual format sender of this error cause MAY choose to report how long past
  expiration the
      information State Cookie is site or application specific, and by including a robust
      implementation SHOULD support non-zero value in the field as undistinguished
      octets.

      The codification
  Measure of Staleness field. If the range of allowed usage of this field is
      outside the scope of sender does not wish to provide
  this specification.

4. SCTP Association State Diagram

During information it should set the lifetime Measure of an SCTP association, the SCTP endpoints
progress from one state to another in response Staleness field to various events. The
events the
  value of zero.

3.3.10.4	 Out of Resource (4)

  Cause of error
  ---------------
  Out of Resource: Indicates that may potentially advance an endpoint's state include:

  o SCTP user primitive calls, e.g., [ASSOCIATE], [TERMINATE], [ABORT],

  o reception the sender is out of INIT, COOKIE, ABORT, SHUTDOWN, etc. control
    chunks, or

  o some timeout events.

The state diagram resource. This
  is usually sent in the figures below illustrates state changes,
together combination with the causing events and resulting actions. Note that some or within an ABORT.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=4              |      Cause Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.5	 Unresolvable Address (5)

  Cause of the error conditions are
  ---------------
  Unresolvable Address: Indicates that the sender is not shown in able to
  resolve the state diagram. Full
description specified address parameter (e.g., type of all special cases should be found in address is
  not supported by the text.

Note, chunk names are given sender). This is usually sent in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE chunk type vs.
Cookie parameter.

Stewart, et al                                               [Page  34]
                    -----          -------- (frm any state)
                  /       \      /  rcv ABORT      [ABORT]
 rcv INIT        |         |    |   ---------- combination
  with or ----------
 --------------- within an ABORT.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         v    v   delete TCB     snd ABORT
 generate Cookie  \    +---------+                 delete TCB
 snd INIT.ACK       ---|  CLOSED     Cause Code=5              |
                       +---------+      Cause Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                  Unresolvable Address                         /
   \      [ASSOCIATE]
                       /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Unresolvable Address:  variable length
    The unresolvable address field contains the complete Type, Length
    and Value of the address parameter (or Host Name parameter) that
    contains the unresolvable address or host name.

3.3.10.6	 Unrecognized Chunk Type (6)

  Cause of error
  ---------------
  Unrecognized Chunk Type:  This error cause is returned to the
  originator of the chunk if the receiver does not understand
  the chunk and the upper bit of the 'Chunk Type' is set to one.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=6              |    create TCB
                      |      Cause Length             |    snd
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                  Unrecognized Chunk                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Unrecognized Chunk:  variable length

    The Unrecognized Chunk field contains the unrecognized
    Chunk from the SCTP packet complete with Chunk Type,
    Chunk Flags and Chunk Length.

3.3.10.7	 Invalid Mandatory Parameter (7)

  Cause of error
  ---------------
  Invalid Mandatory Parameter:  This error cause is returned to the
  originator of an INIT or INIT ACK chunk when one of the mandatory
  parameters is set to a invalid value.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Cause Code=7              |    strt init timer
     rcv valid COOKIE |          v
 (1) ---------------- |      +------------+
     create TCB       |      | COOKIE_WAIT| (2)
     snd COOKIE.ACK   |      +------------+
                      |          |
                      |          |    rcv INIT.ACK
                      |          |    -----------------
                      |          |    snd COOKIE
                      |          |    stop init timer
                      |          |    strt cookie timer
                      |          v
                      |      +------------+
                      |      | COOKIE_SENT| (3)
                      |      +------------+
                      |          |
                      |          |    rcv COOKIE.ACK      Cause Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.8	 Unrecognized Parameters (8)

  Cause of error
  ---------------
  Unrecognized Parameters:  This error cause is returned to the
  originator of the INIT ACK chunk if the receiver does not
  recognize one or more Optional TLV parameters in the INIT ACK chunk.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    -----------------     Cause Code=8              |      Cause Length             |    stop cookie timer
                      v          v
                    +---------------+
                    |  ESTABLISHED  |
                    +---------------+

                   (from the ESTABLISHED state only)
                                 |
                                 |
                        /--------+--------\
    [TERMINATE]
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                  Unrecognized Parameters                      /
   \
    -----------------  |                   |
    check outstanding  |                   |
    data chunks        |                   |
                       v                   |
                  +---------+              |
                  |SHUTDOWN |              | rcv SHUTDOWN
                  |PENDING  |              | ----------------
                  +---------+              |         x
                       |                   |                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Unrecognized Parameters:  variable length
    The Unrecognized Parameters field contains the unrecognized
    parameters copied from the INIT ACK chunk complete with TLV. This
    error cause is normally contained in an ERROR chunk bundled with
    the COOKIE ECHO chunk when responding to the INIT ACK, when the
    sender of the COOKIE ECHO chunk wishes to report unrecognized
    parameters.

3.3.10.9	 No more outstanding  |                   |
  -------------------  |                   |
  snd SHUTDOWN         |                   |
  strt shutdown timer  | User Data (9)

  Cause of error
  ---------------
  No User Data:  This error cause is returned to the
  originator of a DATA chunk if a received DATA chunk has no user data.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
                       v                   v

Stewart, et al                                               [Page  35]
                  +---------+        +-----------+
              (4) |SHUTDOWN     Cause Code=9              |      Cause Length=8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                  TSN value                                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  TSN value:  32 bits (+unsigned integer)
    The TSN value field contains the TSN of the DATA chunk received
    with no user data field.

 This cause code is normally returned in an ABORT chunk
 (see Section 6.2)

3.3.10.10	 Cookie Received While Shutting Down (10)

  Cause of error
  ---------------
  Cookie Received While Shutting Down:  A COOKIE ECHO was received
  While the endpoint was in SHUTDOWN-ACK-SENT state. This error is
  usually returned in an ERROR chunk bundled with the retransmitted
  SHUTDOWN ACK.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (5)
                  |SENT     |        | RECEIVED  |
                  +---------+        +-----------+
                       |                   |
  rcv SHUTDOWN.ACK     |                   |         x
  -------------------  |                   |-----------------
  stop shutdown timer     Cause Code=10              |      Cause Length=4          | retransmit missing DATA
  delete TCB
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.11 Cookie Echo (COOKIE ECHO) (10):

This chunk is used only during the initialization of an association.
It is sent by the initiator of an association to its peer to complete
the initialization process. This chunk MUST precede any DATA chunk
sent within the association, but MAY be bundled with one or more DATA
chunks in the same packet.

     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 = 10   |Chunk  Flags   |         Length                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Cookie                                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bit

  Set to zero on transmit and ignored on receipt.

Length: 16 bits (unsigned integer)

  Set to the size of the chunk in bytes, including the 4 bytes of
  the chunk header and the size of the Cookie.

Cookie: variable size

  This field must contain the exact cookie received in the
  State Cookie parameter from the previous INIT ACK.

  An implementation SHOULD make the cookie as small as possible
  to insure interoperability.

3.3.12 Cookie Acknowledgement (COOKIE ACK) (11):

This chunk is used only during the initialization of an association.
It is used to acknowledge the receipt of a COOKIE ECHO chunk.  This
chunk MUST precede any DATA or SACK chunk sent within the association,
but MAY be bundled with one or more DATA chunks or SACK chunk in the
same SCTP packet.

     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 = 11   |Chunk  Flags   |     Length = 4                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

  Set to zero on transmit and ignored on receipt.

3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (12):

This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK
chunk at the completion of the shutdown process, see Section 9.2 for
details.

The SHUTDOWN COMPLETE chunk has no parameters.

     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 = 12   |Reserved     |T|      Length = 4               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

  Reserved:  7 bits
    Set to 0 on transmit and ignored on receipt.

  T bit:  1 bit
    The T bit is set to 0 if the sender had a TCB that it destroyed. If
    the sender did NOT have a TCB it should set this bit to 1.

Note: Special rules apply to this chunk for verification, please
see Section 8.5.1 for details.

4. SCTP Association State Diagram

During the lifetime of an SCTP association, the SCTP endpoints association
progress from one state to another in response to various events. The
events that may potentially advance an association's state include:

  o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],

  o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc. control
    chunks, or

  o Some timeout events.

The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that some
of the error conditions are not shown in the state diagram. Full
description of all special cases should be found in the text.

  Note:  Chunk names are given in all capital letters, while parameter
  names have the first letter capitalized, e.g., COOKIE ECHO chunk type
  vs. State Cookie parameter. If more than one event/message can occur
  which causes a state transition it is labeled (A), (B) etc.

                    -----          -------- (frm any state)
                  /       \      /  rcv ABORT      [ABORT]
 rcv INIT        |         |    |   ----------  or ----------
 --------------- |         v    v   delete TCB     snd ABORT
 generate Cookie  \    +---------+                 delete TCB
 snd INIT ACK       ---|  CLOSED |
                       +---------+
                        /      \      [ASSOCIATE]
                       /        \     ---------------
                      |          |    create TCB
                      |          |    snd INIT
                      |          |    strt init timer
       rcv valid      |          |
     COOKIE  ECHO     |          v
 (1) ---------------- |      +------------+
     create TCB       |      | COOKIE-WAIT| (2)
     snd COOKIE ACK   |      +------------+
                      |          |
                      |          |    rcv INIT ACK
                      |          |    -----------------
                      |          |    snd COOKIE ECHO
                      |          |    stop init timer
                      |          |    strt cookie timer
                      |          v
                      |      +--------------+
                      |      | COOKIE-ECHOED| (3)
                      |      +--------------+
                      |          |
                      |          |    rcv COOKIE ACK
                      |          |    -----------------
                      |          |    stop cookie timer
                      v          v
                    +---------------+
                    |  ESTABLISHED  |
                    +---------------+

                   (from the ESTABLISHED state only)
                                 |
                                 |
                        /--------+--------\
    [SHUTDOWN]         /                   \
    -------------------|                   |
    check outstanding  |                   |
    DATA chunks        |                   |
                       v                   |
                  +---------+              |
                  |SHUTDOWN-|              | rcv SHUTDOWN/check
                  |PENDING  |              | outstanding DATA
                  +---------+              | chunks
                       |                   |------------------
  No more outstanding  |                   |
  ---------------------|                   |
  snd SHUTDOWN         |                   |
  strt shutdown timer  |                   |
                       v                   v
                  +---------+        +-----------+
              (4) |SHUTDOWN-|        | SHUTDOWN- |  (5,6)
                  |SENT     |        | RECEIVED  |
                  +---------+        +-----------+
                       |  \                |
 (A) rcv SHUTDOWN ACK  |   \               |
 ----------------------|    \              |
 stop shutdown timer   |     \rcv:SHUTDOWN |
 send SHUTDOWN COMPLETE|      \  (B)       |
 delete TCB            |       \           |
                       |        \          | No more outstanding
                       |         \         |-----------------
                       |          \        | send SHUTDOWN ACK
 (B)rcv SHUTDOWN       |           \       | strt shutdown timer
 ----------------------|            \      |
 send SHUTDOWN ACK     |             \     |
 start shutdown timer  |              \    |
 move to SHUTDOWN-     |               \   |
 ACK-SENT              |                |  |
                       |                v  |
                       |             +-----------+
                       |             | SHUTDOWN- | (7)
                       |             | ACK-SENT  |
                       |             +-----------+
                       |                   | (C)rcv SHUTDOWN COMPLETE
                       |                   |-----------------
                       |                   | stop shutdown timer
                       |                   | delete TCB
                       |                   |
                       |                   | (D)rcv SHUTDOWN ACK
                       |                   |--------------
                       |                   | stop shutdown timer
                       |                   | send SHUTDOWN COMPLETE
                       |                   | delete TCB
                       |                   |
                       \    +---------+    /
                        \-->| CLOSED  |<--/
                            +---------+

           Figure 3: State Transition Diagram of SCTP

Notes:

(1) If the State Cookie in the received COOKIE ECHO is invalid (i.e.,
    failed to pass the integrity check), the receiver MUST silently
    discard the packet. Or, if the received State Cookie is expired
    (see Section 5.1.5), the receiver MUST send back an ERROR chunk.
    In either case, the receiver stays in the CLOSED state.

(2) If the T1-init timer expires, the endpoint MUST retransmit INIT
    and re-start the T1-init timer without changing state. This MUST be
    repeated up to 'Max.Init.Retransmits' times. After that, the
    endpoint MUST abort the initialization process and report the
    error to SCTP user.

(3) If the T1-cookie timer expires, the endpoint MUST retransmit
    COOKIE ECHO and re-start the T1-cookie timer without changing
    state. This MUST be repeated up to 'Max.Init.Retransmits'
    times. After that, the endpoint MUST abort the initialization
    process and report the error to SCTP user.

(4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received
    DATA chunks without delay.

(5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new
    send request from its SCTP user.

(6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit
    data and leave this state when all data inqueue is transmitted.

(7 In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new
    send request from its SCTP user.

The CLOSED state is used to indicate that an association is not
created (i.e., doesn't exist).

5. Association Initialization

Before the first data transmission can take place from one SCTP
endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must
complete an initialization process in order to set up an SCTP
association between them.

The SCTP user at an endpoint should use the ASSOCIATE primitive to
initialize an SCTP association to another SCTP endpoint.

  IMPLEMENTATION NOTE: From an SCTP-user's point of view, an
  association may be implicitly opened, without an ASSOCIATE primitive
  (see 10.1 B) being invoked, by the initiating endpoint's sending of
  the first user data to the destination endpoint. The initiating SCTP
  will assume default values for all mandatory and optional parameters
  for the INIT/INIT ACK.

Once the association is established, unidirectional streams are
open for data transfer on both ends (see Section 5.1.1).

5.1 Normal Establishment of an Association

The initialization process consists of the following steps (assuming
that SCTP endpoint "A" tries to set up an association with SCTP
endpoint "Z" and "Z" accepts the new association):

A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must
   provide its Verification Tag (Tag_A) in the Initiate Tag field.
   Tag_A SHOULD be a random number in the range of 1 to 4294967295
   (see 5.3.1 for Tag value selection). After sending the INIT, "A"
   starts the T1-init timer and enters the COOKIE-WAIT state.

B) "Z" shall respond immediately with an INIT ACK chunk.  The
   destination IP address of the INIT ACK MUST be set to the source
   IP address of the INIT to which this INIT ACK is responding.  In
   the response, besides filling in other parameters, "Z" must set the
   Verification Tag field to Tag_A, and also provide its own
   Verification Tag (Tag_Z) in the Initiate Tag field.

   Moreover, "Z" MUST generate and send along with the INIT ACK a
   State Cookie. See Section 5.1.3 for State Cookie generation.

   Note: After sending out INIT ACK with the State Cookie parameter,
   "Z" MUST NOT allocate any resources, nor keep any states for the new
   association. Otherwise, "Z" will be vulnerable to resource attacks.

C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-init
   timer and leave COOKIE-WAIT state. "A" shall then send the State
   Cookie received in the INIT ACK chunk in a COOKIE ECHO chunk, start
   the T1-cookie timer, and enter the COOKIE-ECHOED state.

   Note: The COOKIE ECHO chunk can be bundled with any pending outbound
   DATA chunks, but it MUST be the first chunk in the packet and
   until the COOKIE ACK is returned the sender MUST NOT send any
   other packets to the peer.

D) Upon reception of the COOKIE ECHO chunk, Endpoint "Z" will reply
   with a COOKIE ACK chunk after building a TCB and moving to
   the ESTABLISHED state. A COOKIE ACK chunk may be bundled with
   any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK
   chunk MUST be the first chunk in the packet.

  IMPLEMENTATION NOTE: An implementation may choose to send the
  Communication Up notification to the SCTP user upon reception
  of a valid COOKIE ECHO chunk.

E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
   COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie
   timer. It may also notify its ULP about the successful
   establishment of the association with a Communication Up
   notification (see Section 10).

An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.

They MUST be the only chunks present in the SCTP packets that carry
them.

  IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
  doesn't control the source IP address that is used for transmitting),
  an endpoint might need to include in its INIT or INIT ACK all possible
  IP addresses from which packets to the peer could be transmitted.

An endpoint MUST send the INIT ACK to the IP address from which it
received the INIT.

  Note: T1-init timer and T1-cookie timer shall follow the same rules
  given in Section 6.3.

If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter values,
or lack of local resources, it MUST respond with an ABORT chunk. It
SHOULD also specify the cause of abort, such as the type of the
missing mandatory parameters, etc., by including the error cause
parameters with the ABORT chunk.  The Verification Tag field in the
common header of the outbound SCTP packet containing the ABORT chunk
MUST be set to the Initiate Tag value of the peer.

After the reception of the first DATA chunk in an association
the endpoint MUST immediately respond with a SACK to acknowledge
the DATA chunk.  Subsequent acknowledgements should be done as
described in Section 6.2.

When the TCB is created, each endpoint MUST set its internal Cumulative
TSN Ack Point to the value of its transmitted Initial TSN minus one.

  IMPLEMENTATION NOTE:  The IP addresses and SCTP port are generally
  used as the key to find the TCB within an SCTP instance.

5.1.1 Handle Stream Parameters

In the INIT and INIT ACK chunks, the sender of the chunk shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint.

After receiving the stream configuration information from the other
side, each endpoint shall perform the following check:  If the peer's
MIS is less than the endpoint's OS, meaning that the peer is incapable
of supporting all the outbound streams the endpoint wants to
configure, the endpoint MUST either use MIS outbound streams,
or abort the association and report to its upper layer the resources
shortage at its peer.

After the association is initialized, the valid outbound stream
identifier range for either endpoint shall be 0 to
min(local OS, remote MIS)-1.

5.1.2 Handle Address Parameters

During the association initialization, an endpoint shall use the
following rules to discover and collect the destination transport
address(es) of its peer.

  A) If there are no address parameters present in the received INIT
  or INIT ACK chunk, the endpoint shall take the source IP address
  from which the chunk arrives and record it, in combination with
  the SCTP source port number, as the only destination transport
  address for this peer.

  B) If there is a Host Name parameter present in the received INIT or
  INIT ACK chunk, the endpoint shall resolve that host name to a
  list of IP address(es) and derive the transport address(es) of this
  peer by combining the resolved IP address(es) with the SCTP source
  port.

  The endpoint MUST ignore any other IP address parameters if
  they are also present in the received INIT or INIT ACK chunk.

  The time at which the receiver of an INIT resolves the host
  name has potential security implications to SCTP. If the receiver of
  an INIT resolves the host name upon the reception of the chunk, and
  the mechanism the receiver uses to resolve the host name involves
  potential long delay (e.g. DNS query), the receiver may open itself
  up to resource attacks for the period of time while it is waiting for
  the name resolution results before it can build the State Cookie and
  release local resources.

  Therefore, in cases where the name translation involves potential
  long delay, the receiver of the INIT MUST postpone the name
  resolution till the reception of the COOKIE ECHO chunk from the
  peer. In such a case, the receiver of the INIT SHOULD build the
  State Cookie using the received Host Name (instead of destination
  transport addresses) and send the INIT ACK to the source IP
  address from which the INIT was received.

  The receiver of an INIT ACK shall always immediately attempt to
  resolve the name upon the reception of the chunk.

  The receiver of the INIT or INIT ACK MUST NOT send SHUTDOWN.ACK
                       |                   |    delete TCB
                       |                   |
                       \    +---------+    /
                        \-->| CLOSED  |<--/
                            +---------+

Note:

(1) user data
  (piggy-backed or stand-alone) to its peer until the host name is
  successfully resolved.

  If the received COOKIE name resolution is invalid (i.e., failed not successful, the endpoint MUST
  immediately send an ABORT with "Unresolvable Address" error cause to
  its peer. The ABORT shall be sent to pass the
    authentication check), source IP address from which
  the last peer packet was received.

  C) If there are only IPv4/IPv6 addresses present in the received
  INIT or INIT ACK chunk, the receiver MUST silently discard shall derive and record all
  the
    datagram. Or, if transport address(es) from the received COOKIE is expired (see Section
    5.1.5), chunk AND the
  source IP address that sent the INIT or INIT ACK. The transport
  address(es) are derived by the combination of SCTP source port (from
  the common header) and the IP address parameter(s) carried in the
  INIT or INIT ACK chunk and the source IP address of the IP datagram.
  The receiver should use only these transport addresses as
  destination transport addresses when sending subsequent packets
  to its peer.

After all transport addresses are derived from the INIT or INIT ACK
chunk using the above rules, the endpoint shall select one of the
transport addresses as the initial primary path.

Note: The INIT-ACK MUST be sent to the source address of the INIT.

The sender of INIT may include a 'Supported Address Types'
parameter in the INIT to indicate what types of address are
acceptable. When this parameter is present, the receiver SHALL send back an ERROR chunk. In of INIT
(initiatee) MUST either
    case, use one of the receiver stays address types indicated in the CLOSED state.

(2) If the init timer expires, the endpoint SHALL retransmit INIT
    and re-start the init timer without changing state. This SHALL be
    repeated up
Supported Address Types parameter when responding to 'Max.Init.Retransmits' times. After that, the
    endpoint SHALL INIT, or
abort the initialization process and report the association with an "Unresolvable Address" error to SCTP user.

(3) If cause if it
is unwilling or incapable of using any of the T1-cookie timer expires, address types indicated
by its peer.

  IMPLEMENTATION NOTE: In the endpoint SHALL retransmit
    COOKIE and re-start case that the T1-cookie timer without changing
    state. This SHALL be repeated up receiver of an INIT ACK
  fails to 'Max.Init.Retransmits'
    times. After that, resolve the endpoint SHALL address parameter due to an unsupported type,
  it can abort the initialization initiation process and report then attempt a re-initiation
  by using a 'Supported Address Types' parameter in the error new INIT to SCTP user.

(4) In SHUTDOWN-SENT state
  indicate what types of address it prefers.

5.1.3 Generating State Cookie

When sending an INIT ACK as a response to an INIT chunk, the endpoint SHALL acknowledge any received
    DATA chunks without delay

(5) In SHUTDOWN-RECEIVED state, sender
of INIT ACK creates a State Cookie and sends it in the endpoint MUST NOT accept any new
    send request from its SCTP user.

5. Association Initialization

Before State Cookie
parameter of the INIT ACK. Inside this State Cookie, the sender should
include a MAC (see [RFC2104] for an example), a time stamp on when the
State Cookie is created, and the first data transmission can take place from one SCTP
endpoint ("A") lifespan of the State Cookie, along
with all the information necessary for it to another SCTP endpoint ("Z"), establish the two endpoints must
complete an initialization process in order association.

The following steps SHOULD be taken to set up generate the State Cookie:

1) Create an SCTP association between them.

The SCTP user at an endpoint should use TCB using information from both the ASSOCIATE primitive received
   INIT and the outgoing INIT ACK chunk,

2) In the TCB, set the creation time to
initialize an SCTP association the current time of day, and
   the lifespan to another SCTP endpoint.

Stewart, et al                                               [Page  36]
  IMPLEMENTATION NOTE: From the protocol parameter 'Valid.Cookie.Life',

3) Generate a MAC using the TCB and a secret key (see [RFC2104] for an SCTP-user's point
   example of view, an
  association may be implicitly opened, without an ASSOCIATE primitive
  (see 10.1 B) being invoked, generating a MAC), and

4) Generate the State Cookie by combining the initiating endpoint's sending smallest amount of
   information needed to generate a TCB and the first user data resultant MAC.

After sending the INIT ACK with the State Cookie parameter, the sender
SHOULD delete the TCB and any other local resource related to the destination endpoint. new
association, so as to prevent resource attacks.

The initiating SCTP
  will assume default values for all mandatory and optional parameters hashing method used to generate the MAC is strictly a
private matter for the INIT/INIT ACK.

Once receiver of the association INIT chunk. The use of a MAC
is established, unidirectional streams will be
open for data transfer on both ends (see Section 5.1.1).

5.1 Normal Establishment mandatory to prevent denial of an Association service attacks. The initialization process consists of secret key
SHOULD be random ([RFC1750] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the following steps (assuming
that SCTP endpoint "A" tries
timestamp in the State Cookie MAY be used to set up determine which key should
be used to verify the MAC.

An implementation SHOULD make the cookie as small as possible to
insure interoperability.

5.1.4 State Cookie Processing

When an association with SCTP endpoint "Z" and "Z" accepts the new association):

A) "A" shall first send receives an INIT message ACK chunk with a State Cookie
parameter, it MUST immediately send a COOKIE ECHO chunk to "Z". In the INIT, "A" must
   provide its security tag "Tag_A" in the Initiate Tag field. Tag_A
   SHOULD be a random number in peer
with the range of 0x1 received State Cookie.  The sender MAY also add any pending
DATA chunks to 0xffffffff (see
   5.3.1 for Tag value selection). After the packet after the COOKIE ECHO chunk.

The endpoint shall also start the T1-cookie timer after sending out the INIT, "A" starts
COOKIE ECHO chunk. If the T1-init timer expires, the endpoint shall retransmit
the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated
until either a COOKIE ACK is received or 'Max.Init.Retransmits' is
reached causing the peer endpoint to be marked unreachable (and thus
the association enters the COOKIE-WAIT state.

B) "Z" shall respond immediately with CLOSED state).

5.1.5 State Cookie Authentication

When an INIT ACK message. In endpoint receives a COOKIE ECHO chunk from another endpoint
with which it has no association, it shall take the
   message, besides filling in other parameters, "Z" must set following actions:

1) Compute a MAC using the
   Verification Tag field to Tag_A, and also provide its own security
   tag "Tag_Z" TCB data carried in the Initiate Tag field.

   Moreover, "Z" MUST generate State
   Cookie and send along with the INIT ACK an secret key (note the timestamp in the State Cookie. See Section 5.1.3 Cookie
   MAY be used to determine which secret key to use).  Reference
   [RFC2104] can be used as a guideline for generating the MAC,

2) Authenticate the State Cookie generation.

   Note: after sending out INIT ACK with as one that it previously generated by
   comparing the cookie, "Z" MUST not
   allocate any resources, nor keep any states for computed MAC against the new
   association. Otherwise, "Z" will be vulnerable to resource attacks.

C) Upon reception of one carried in the INIT ACK from "Z", "A" shall stop
   State Cookie. If this comparison fails, the T1-init
   timer SCTP packet, including
   the COOKIE ECHO and leave COOKIE-WAIT state. "A" shall then send any DATA chunks, should be silently discarded,

3) Compare the cookie
   received creation timestamp in the INIT ACK message State Cookie to the current
   local time. If the elapsed time is longer than the lifespan carried
   in a cookie chunk, start the
   T1-cookie timer, and enter State Cookie, then the COOKIE-SENT state.

   Note, packet, including the cookie chunk can be bundled with COOKIE ECHO and
   any pending outbound attached DATA chunks, but it MUST SHOULD be discarded and the first endpoint MUST
   transmit an ERROR chunk in with a "Stale Cookie" error cause to the datagram AND
   until
   peer endpoint,

4) If the COOKIE ACK State Cookie is returned the sender MUST NOT send any
   other datagrams valid, create an association to the peer.

D) Upon reception sender of
   the COOKIE chunk, Endpoint "Z" will reply with COOKIE ECHO chunk with the information in the TCB data carried
   in the COOKIE ECHO, and enter the ESTABLISHED state,

5) Send a COOKIE ACK chunk after building a TCB and marking itself to the ESTABLISHED state. A peer acknowledging reception of
   the COOKIE ECHO. The COOKIE ACK chunk may MAY be combined bundled with
   any pending an outbound
   DATA chunks (and/or chunk or SACK chunks), but chunk; however, the COOKIE ACK
   chunk MUST be the first
   chunk in the datagram.

  IMPLEMENTATION NOTE: an implementation may choose to send the
  Communication Up notification to the SCTP user upon reception
  of a valid COOKIE.

Stewart, et al                                               [Page  37]

E) Upon reception of packet.

6) Immediately acknowledge any DATA chunk bundled with the COOKIE ACK, endpoint "A" will move from the
   COOKIE-SENT state to the ESTABLISHED state, stopping the T1-cookie
   timer, and it may also notify its ULP about the successful
   establishment of the associate ECHO
   with a Communication Up notification
   (see Section 10).

Note: A SACK (subsequent DATA chunk MUST NOT be carried in the INIT or INIT ACK message.

Note: T1-init timer and T1-cookie timer shall acknowledgement should follow the same
   rules
given defined in Section 6.3.

Note: if an endpoint receives an INIT, INIT ACK, or COOKIE chunk but
decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter values,
or, lack of local resources, it SHALL respond with an ABORT chunk. It
SHOULD also specify the cause of abort, such as the type of the
missing mandatory parameters, etc., by either including cause
parameters or bundling with the ABORT one or more Operational ERROR
chunks.  The Verification Tag field in the common header of the
outbound abort datagram MUST be set to equal the Initiate Tag value of
the peer.

Note: After the reception of the first data chunk 6.2).  As mentioned in an association step 5), if the receiver MUST immediately respond with a SACK to acknowledge
   is bundled with the data chunk, subsequent acknowledgments should be done as
described in section 6.2.

Note: When an SCTP endpoint sends an INIT or INIT COOKIE ACK, the COOKIE ACK it SHOULD
include all of its transport addresses MUST appear first in
   the parameter section. This SCTP packet.

If a COOKIE ECHO is because it may NOT be possible to control received from an endpoint with which the "sending" address
that a
receiver of the COOKIE ECHO has an SCTP datagram sees. A receiver thus MUST know
every address that may be a source address for a peer SCTP endpoint,
this assures that existing association, the inbound SCTP datagram can procedures
in Section 5.2 should be matched to followed.

5.1.6 An Example of Normal Association Establishment

In the
proper association.

Note: At 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
x
{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]
                     <------/\
                              \
                               \------>

                  Figure 4: INITiation Example

If the time when T1-init timer expires at "A" after the TCB is created, either end MUST set its
internal cumulative TSN acknowledgment point to its peer's Initial TSN
minus one.

  IMPLEMENTATION Note: The IP address and SCTP port(s) INIT or COOKIE ECHO
chunks are generally
  used as the key to find the TCB within an SCTP instance.

5.1.1 Handle Stream Parameters

In sent, the same INIT and INIT ACK messages, the sender of or COOKIE ECHO chunk with the message same
Initiate Tag (i.e., Tag_A) or State Cookie shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximal inbound streams (MIS) it will
accept from the other endpoint.

After receiving these stream configuration information from be retransmitted and
the other
side, each endpoint timer restarted. This shall perform the following check: if the peer's
MIS is less than the endpoint's OS, meaning that the peer is incapable
of supporting all the outbound streams the endpoint wants to
configure, the endpoint MUST either settle with MIS outbound streams,
or abort the association be repeated Max.Init.Retransmits times
before "A" considers "Z" unreachable and report reports the failure to its
upper layer the resources
shortage at its peer.

Stewart, et al                                               [Page  38]

After (and thus the association is initialized, enters the valid outbound stream
identifier range for either endpoint shall be 0 to
min(local OS, remote MIS)-1.

5.1.2 Handle Address Parameters

During CLOSED state). When
retransmitting the INIT, the association initialization, an endpoint shall use MUST follow the
following rules to discover and collect the destination transport
address(es) of its peer.

  A) If there are no address parameters present
defined in 6.3 to determine the received INIT proper timer value.

5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
COOKIE ACK message,

During the receiver shall take lifetime of an association (in one of the source IP address possible
states), an endpoint may receive from which its peer endpoint one of the message arrives
setup chunks (INIT, INIT ACK, COOKIE ECHO, and record it, COOKIE ACK). The
receiver shall treat such a setup chunk as a duplicate and process it
as described in combination with this section.
  Note:  An endpoint will not receive the SCTP source port number, as chunk unless the only destination chunk was
  sent to a SCTP transport address for and is from a SCTP transport address
  associated with this peer. endpoint.  Therefore, the endpoint processes
  such a chunk as part of its current association.

The following scenarios can cause duplicated or unexpected chunks:

A) The peer has crashed without being detected, re-started
   itself and sent out a new INIT chunk trying to restore the
   association,

B) If there Both sides are trying to initialize the association at about the
   same time,

C) The chunk is from a Host Name parameter stale packet that was used to establish
   the present association or a past association that is no
   longer in the existence,

D) The chunk is a false packet generated by an attacker, or

E) The peer never received the COOKIE ACK and is retransmitting its
   COOKIE ECHO.

The rules in the following sections shall be applied in order to
identify and correctly handle these cases.

5.2.1 INIT received in COOKIE-WAIT or
  INIT ACK message, COOKIE-ECHOED State (Item B)

This usually indicates an initialization collision, i.e., each
endpoint is attempting, at about the receiver shall resolve that host name same time, to a
  list of IP address(es) and derive establish an
association with the transport address(es) other endpoint.

Upon receipt of this
  peer by combining an INIT in the resolved IP address(es) COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the SCTP source
  port.

  Note: the receiver MUST ignore any other IP address same parameters if
  they are also present it
sent in its original INIT chunk (including its Verification Tag,
unchanged). These original parameters are combined with those from the
newly received INIT or INIT ACK message.

  Note: when chunk. The endpoint shall also generate a State
Cookie with the receiver of an INIT resolves the host name may have
  potential security implications to SCTP. If ACK. The endpoint uses the receiver of an parameters sent in its
INIT
  resolves to calculate the host name upon State Cookie.

After that, the reception of endpoint MUST not change its state, the message, T1-init
timer shall be left running and the
  mechanism corresponding TCB MUST NOT be
destroyed. The normal procedures for handling State Cookies when
a TCB exists will resolve the receiver uses duplicate INITs to resolve a single association.

5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED and
COOKIE-WAIT

Unless otherwise stated, upon reception of an unexpected INIT for this
association, the host name involves
  potential long delay (e.g. DNS query), endpoint shall generate an INIT ACK with a State
Cookie. In the receiver may open itself
  up outbound INIT ACK the endpoint MUST copy its current
Verification Tag and Peers Verification tag into a reserved place
within the state cookie. We shall refer to resource attacks for these locations as the period of time while it is waiting for
Peers-Tie-Tag and the name resolution results before it can build Local-Tie-Tag. The INIT ACK MUST contain a new
Verification Tag (randomly generated see Section 5.3.1). Other
parameters for the cookie and
  release local resource.

  Therefore, in cases where endpoint SHOULD be copied from the name translation involves potential
  long delay, existing
parameters of the receiver association (e.g. number of outbound streams) into
the INIT SHOULD postpone ACK and cookie.

After sending out the name
  resolution till INIT ACK, the reception of endpoint shall take no further
actions, i.e., the COOKIE message from existing association, including its current state,
and the
  peer. In such corresponding TCB MUST NOT be changed.

Note: Only when a case, TCB exists and the receiver of association is NOT in a
COOKIE-ECHOED or COOKIE-WAIT state are the Tie-Tags populated. For a
normal association INIT SHOULD build (i.e. the
  cookie using endpoint ARE in a COOKIE-ECHOED or
COOKIE-WAIT state), the received Host Name (instead of destination
  transport addresses) Tie-Tags MUST be set to 0 (indicating that no
previous TCB existed). The INIT ACK and send the State Cookie are populated
as specified in section 5.2.1.

5.2.3 Unexpected INIT ACK to

If an INIT ACK is received by an endpoint in any state
other than the source IP
  address from where COOKIE-WAIT state, the endpoint should discard
the INIT is received.

  The receiver ACK chunk. An unexpected INIT ACK usually indicates the
processing of an old or duplicated INIT ACK shall always immediately attempt to
  resolve chunk.

5.2.4 Handle a COOKIE ECHO when a TCB exists

When a COOKIE ECHO chunk is received by an endpoint in any state for an
existing association (i.e., not in the name upon CLOSED state) the reception following
rules shall be applied:

1) Compute a MAC as described in Step 1 of Section 5.1.5,

2) Authenticate the message.

  The receiver State Cookie as described in Step 2 of the INIT or INIT ACK MUST NOT send user data
  (piggy-backed Section
   5.1.5 (this is case C or stand-alone) D above).

3) Compare the timestamp in the State Cookie to its peer until the host name is
  successfully resolved. current time. If
   the name resolution State Cookie is older than the lifespan carried in the State
   Cookie and the Verification Tags contained in the State Cookie do
   not successful, match the current association's Verification Tags, the packet,
   including the COOKIE ECHO and any DATA chunks, should be discarded.
   The endpoint SHALL
  immediately send also MUST transmit an ABORT ERROR chunk with Unresolvable Address a "Stale Cookie"
   error cause to its
  peer. The ABORT shall be sent to the source IP address from where the last peer message was received.

  C) endpoint (this is case C or D above).

   If there are only IPv4/IPv6 addresses present both Verification Tags in the received
  INIT or INIT ACK message, State Cookie match the receiver shall derive and record all Verification
   Tags of the transport address(es) from current association, consider the received message. The transport
  address(es) are derived by State Cookie valid
   (this is case E) even if the combination of SCTP source port (from lifespan is exceeded.

4) If the common header) and State Cookie proves to be valid, unpack the IP address parameter(s) carried TCB into a
   temporary TCB.

5) If the Verification Tags in the
  INIT or INIT Temporary TCB match the
   Verification Tags in the existing TCB, the State Cookie is a
   duplicate cookie. A COOKIE ACK message. The receiver should use only these
  transport addresses as destination transport addresses when sending
  subsequent datagrams be sent to the peer
   endpoint but no update should be made to its peer.

After all transport addresses are derived from the INIT or INIT ACK
message using above rules, existing
   TCB (only the local Verification Tag needs to be compared if
   the peer's Verification Tag is not yet available).

   The endpoint shall select one doesn't leave the current state and all timers
   remain running.

6) If either of the
transport addresses as Verification Tags do NOT match, refer to the initial primary destination transport
address.

Note: following
   table to determine the sender correct action to be taken.

  +------------+------------+---------------+--------------+-------------+
  |  Local Tag |  Peers Tag | Local-Tie-Tag | Peers-Tie-Tag|   Action/   |
  |            |            |               |              | Description |
  +------------+------------+---------------+--------------+-------------+
  |    X       |     X      |      M        |      M       |     (A)     |
  +------------+------------+---------------+--------------+-------------+
  |    X       |     M      |      M        |      M       |     (B)     |
  +------------+------------+---------------+--------------+-------------+
  |    X       |     M      |      M        |      X       |     (C)     |
  +------------+------------+---------------+--------------+-------------+
  |    M       |     X      |      X        |      M       |     (D)     |
  +------------+------------+---------------+--------------+-------------+
  |    M       |     X      |      M        |      M       |     (E)     |
  +------------+------------+---------------+--------------+-------------+
  |    X       |     X      |      X        |      X       |     (F)     |
  +======================================================================+
  |       Table 2: Handling of INIT may include a 'Supported Address Types'
parameter in Cookie when a TCB exists                |
  +======================================================================+

  Legend:
     X - Tag does not match the INIT to indicate what types of address are
acceptable. When this parameter is present, existing TCB
     M - Tag matches the receiver of INIT
(initiatee) SHALL either use one of existing TCB.

Actions

(A)In this case, the address types indicated in peer may have restarted. When the
'Supported Address Types' parameter when responding to endpoint
   recognizes this potential 'restart', the INIT, or
abort existing session is
   treated the association with an Unresolvable Address error same as if it received an ABORT followed by a new
   Cookie Echo with the following exceptions:

    - Any SCTP Data Chunks MAY be retained (this is
unwilling or incapable an implementation
      specific option).

    - A notification of using any RESTART SHOULD be sent to the ULP instead
      of a "COMMUNICATION LOST" notification.

   All the address types indicated by
its peer.

  IMPLEMENTATION NOTE: In congestion control parameters (e.g., cwnd, ssthresh) related
   to this peer MUST be reset to their initial values (see Section
   6.2.1).

   After this the case that endpoint shall enter the receiver of an INIT ACK
  fails to resolve ESTABLISHED state.

   If the address parameter due to an unsupported type,
  it can abort endpoint is in the initiation process SHUTDOWN-ACK-SENT state and then attempt a re-initiation
  by using a 'Supported Address Types' parameter in recognizes
   the new INIT to
  indicate what types of address peer has restarted (Action A), it prefers.

5.1.3 Generating State Cookie

When sending an INIT MUST NOT setup a new
   association but instead resend the SHUTDOWN ACK as and send an ERROR
   chunk with a response "Cookie Received while Shutting Down" error cause to
   its peer.

(B)In this case, both sides may be attempting to start an INIT message,
   association at about the sender same time but the INIT-Ack of INIT ACK should create an State Cookie one side
   was lost, and send it as part of the other side completed the INIT ACK. Inside sequence.
   In this State Cookie, case, the sender should include a ICV
security signature endpoint MUST update the Local Verification
   Tag from the Cookie, stay in or MAC (message Authentication code) [4], a time
stamp on when move to the Established State,
   stop any init or cookie is created, timers that may be running and
   send a Cookie Ack.

(C)In this case, a software error may have occurred in the lifespan of the cookie,
along with all the information necessary for peer. The
   peer changed its Verification Tag while it to establish was in the
association. Cookie Sent
   state. The following steps SHOULD be taken endpoint MAY stay in or move to generate the cookie:

1) create an association TCB using information Established state,
   but it must stop any init or cookie timers that may be running,
   update its Verification Tag from both the received
   INIT Cookie and the outgoing INIT ACK messages,

2) send a
   Cookie Ack.

(D)In this case, a software error may have occurred in the TCB, set the creation time to the current time of day, and local
   endpoint. The Verification Tag has been changed when in
   the lifespan to COOKIE-ECHOED state. The endpoint MAY stay in or enter the protocol parameter 'Valid.Cookie.Life',

3) Generate a MAC signature using
   Established state but it MUST update its peers Verification
   Tag from the TCB Cookie, stop any init or cookie timers that may
   be running and send a Private Key (see [4] for
   details on generating the MAC), and

Stewart, et al                                               [Page  39]

4) generate the State Cookie by combining the TCB and Ack.

(E)In this case, both sides may be attempting to start an
   association at about the
   resultant ICV signature.

After sending same time but the peer endpoint
   started its INIT ACK with the cookie, the sender SHOULD delete
the TCB and any other local resource related to the new association,
so as to prevent resource attacks.

The ICV and hashing method used after responding to generate the MAC is strictly local endpoints
   INIT. Thus it picked a
private matter for the receiver new Verification Tag not being aware
   of the INIT message. previous Tag it had sent this endpoint. The use of endpoint
   should stay in or enter the Established state but it MUST update
   its peers Verification Tag from the Cookie, stop any init
   or cookie timers that may running and send a MAC
is mandatory to prevent denial of service attacks. Cookie Ack.

(F)In this case, an invalid cookie has been sent. The Private Key Cookie
   MUST be random per RFC1750 [1]; it SHOULD be changed reasonably
frequently, and silently discarded.

Note: The "peer's Verification Tag" is the timestamp tag received in the cookie MAY be used to determine
which key should be used to verify
Initiate Tag field of the MAC.

5.1.4 Cookie Processing

When INIT or INIT ACK chunk.

5.2.5 Handle Duplicate COOKIE-ACK.

At any state other than COOKIE-ECHOED, an endpoint receives an INIT should silently
discard a received COOKIE ACK chunk.

5.2.6 Handle Stale COOKIE Error

Receipt of an Operational ERROR chunk with a State Cookie
parameter, it MUST immediately send "Stale Cookie" error
cause indicates one of a COOKIE chunk to its peer with number of possible events:

A) That the received cookie.  The sender MAY also add any pending DATA chunks association failed to completely setup before the message.

The sender shall also start the T1-cookie timer after sending out
the COOKIE chunk. If the timer expires,
   State Cookie issued by the sender shall retransmit was processed.

B) An old State Cookie was processed after setup completed.

C) An old State Cookie is received from someone that the COOKIE chunk receiver is
   not interested in having an association with and restart the T1-cookie timer. This is repeated until
either ABORT
   chunk was lost.

When processing an Operational ERROR chunk with a COOKIE ACK "Stale Cookie" error cause an
endpoint should first examine if an association is received or 'Max.Init.Retransmits' in the process of
being setup, i.e. the association is reached
causing in the endpoint to COOKIE-ECHOED state. In all
cases if the association is NOT in the COOKIE-ECHOED state, the ERROR
chunk should be marked unreachable (and thus silently discarded.

If the association
enters is in the COOKIE-ECHOED state, the CLOSED state).

5.1.5 Cookie Authentication

When an endpoint receives a COOKIE chunk from another endpoint with
which it has no association, it shall take may elect
one of the following actions: three alternatives.

1) compute Send a MAC signature using the TCB data carried in new INIT chunk to the cookie endpoint to generate a new State
   Cookie and re-attempt the Private Key (note the timestamp in setup procedure.

2) Discard the cookie MAY be
   used TCB and report to determine which Private Key the upper layer the inability to use) reference [4] SHOULD
   be used has a guideline for generating
   setup the MAC,

2) authenticate association.

3) Send a new INIT chunk to the cookie as one that it previously generated by
   comparing endpoint, adding a Cookie
   Preservative parameter requesting an extension to the computed MAC signature against lifetime of
   the one carried in State Cookie. When calculating the
   cookie. If this comparison fails, time extension, an
   implementation SHOULD use the datagram, including RTT information measured based on the
   previous COOKIE ECHO / ERROR exchange, and should add no more
   than 1 second beyond the attached user data, measured RTT, due to long State Cookie
   lifetimes making the endpoint more subject to a replay attack.

5.3 Other Initialization Issues

5.3.1 Selection of Tag Value

Initiate Tag values should be silently discarded,

3) compare selected from the creation time stamp range of 1 to
2**32 - 1. It is very important that the Initiate Tag value be
randomized to help protect against "man in the cookie middle" and "sequence
number" attacks.  The methods described in [RFC1750] can be used for
the Initiate Tag randomization.  Careful selection of Initiate Tags is
also necessary to prevent old duplicate packets from previous
associations being mistakenly processed as belonging to the current local
   time, if the elapsed time is longer than
association.

Moreover, the lifespan carried Verification Tag value used by either endpoint in a given
association MUST NOT change during the cookie, then the datagram, including the COOKIE and the
   attached user data, SHOULD lifetime of an
association. A new Verification Tag value MUST be discarded and used each
time the endpoint MUST
   transmit a stale cookie operational error to the sending endpoint,

4) if the cookie is valid, create tears-down and then re-establishes an association to
the sender of the
   COOKIE message with the information in the TCB data carried same peer.

6. User Data Transfer

Data transfer MUST only happen in the
   COOKIE, ESTABLISHED, SHUTDOWN-PENDING,
and enter the ESTABLISHED state,

5) immediately acknowledge any SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunk in the datagram with a SACK
   (subsequent datagram acknowledgment should follow the rules defined
   in Section 6.2), and,

Stewart, et al                                               [Page  40]

6) send a COOKIE ACK chunk
chunks are allowed to the sender acknowledging reception of
   the cookie. The COOKIE ACK MAY be piggy-backed bundled with any an outbound
   DATA COOKIE ECHO chunk or SACK chunk.

Note
when in COOKIE-WAIT state.

A SCTP receiver MUST be able to receive a minimum of 1500 bytes
in one SCTP packet. This means that if a COOKIE is received from an SCTP endpoint with which MUST NOT
indicate less than 1500 bytes in its Initial a_rwnd sent in the
receiver
INIT or INIT ACK.

For transmission efficiency, SCTP defines mechanisms for bundling of the COOKIE has an existing association, the procedures in
section 5.2 should be followed.

5.1.6 An Example
small user messages and fragmentation of large user messages.
The following diagram depicts the flow of Normal Association Establishment user messages through SCTP.

In this section the following example, "A" initiates term "data sender" refers to the association and then sends endpoint that
transmits a user message to "Z", then "Z" sends two user messages DATA chunk and the term "data receiver" refers to "A" later
(assuming no bundling or segmentation occurs):

Endpoint the
endpoint that receives a DATA chunk.  A                                          Endpoint Z

{app sets association with Z}
(build TCB)
INIT [INIT 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,
                               /               INIT Tag=Tag_Z,
(Cancel T1-init timer) <------/                Cookie_Z, & other info]
                                     (destroy temp TCB)
COOKIE [Cookie_Z] -----------\
(Start T1-init timer)         \
(Enter COOKIE-SENT state)      \---> (build TCB enter ESTABLISHED state)

                               /---- COOKIE-ACK
                              /
(Cancel T1-init timer, <-----/
 Enter established state)
...
{app sends 1st data receiver will transmit
SACK chunks.

              +--------------------------+
              |      User Messages       |
              +--------------------------+
    SCTP user data; strm 0}        ^  |
   ==================|==|=======================================
                     |  v (1)
          +------------------+    +--------------------+
          | SCTP DATA [TSN=initial TSN_A
    Strm=0,Seq=1 & Chunks |    |SCTP Control Chunks |
          +------------------+    +--------------------+
                     ^  |             ^  |
                     |  v (2)         |  v (2)
                  +--------------------------+
                  |      SCTP packets        |
                  +--------------------------+
    SCTP                      ^  |
   ===========================|==|===========================
                              |  v
          Connectionless Packet Transfer Service (e.g., IP)

   Notes:
   (1) When converting user data]--\
(Start T3-rxt timer)            \
                                 \->

                              /----- SACK [TSN ACK=init TSN_A,Frag=0]
(Cancel T3-rxt timer) <------/
...

Stewart, et al                                               [Page  41]
                                     ...
                                     {app sends 2 datagrams;strm 0}
                               /---- messages into DATA
                              /        [TSN=init TSN_Z
                          <--/          Strm=0,Seq=1 & chunks, an endpoint
       will fragment user data 1]
SACK [TSN ACK=init TSN_Z,      /---- messages larger than the current association
       path MTU into multiple DATA
      Frag=0]      --------\  /        [TSN=init TSN_Z +1,
                            \/          Strm=0,Seq=2 & user chunks. The data 2]
                     <------/\
                              \
                               \------>

Note that If T1-init timer expires at "A" after receiver will
       normally reassemble the INIT or COOKIE fragmented message from DATA chunks are sent, the same INIT or cookie chunk with
       before delivery to the same Initiate
Tag (i.e., Tag_A) or cookie shall be retransmitted user (see Section 6.9 for details).

   (2) Multiple DATA and the timer
restarted. This shall control chunks may be repeated Max.Init.Retransmits times before "A"
considers "Z" unreachable and reports bundled by the failure to its upper layer
(and thus
       sender into a single SCTP packet for transmission, as long as
       the association enters final size of the CLOSED state). When
retransmitting packet does not exceed the INIT, current path
       MTU. The receiver will unbundle the endpoint SHALL following packet back into
       the rules
defined original chunks. Control chunks MUST come before
       DATA chunks in 6.3 to determine the proper timer value.

5.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK

During the life time of an association (in one of the possible
states), an endpoint may receive from its peer endpoint one packet.

          Figure 5: Illustration of the
setup chunks (INIT, INIT ACK, COOKIE, and COOKIE ACK). User Data Transfer

The receiver
shall treat such a setup chuck as a duplicate fragmentation and process it bundling mechanisms, as
described detailed in this section.

The following scenarios can cause duplicated chunks:

A) The peer has crashed without being detected, and re-started itself Sections 6.9
and sent out a new INIT Chunk trying to restore the association,

B) Both sides 6.10, are trying OPTIONAL to initialize the association at about implement by the
   same time,

C) The chunk is from a staled datagram that was used to establish data sender, but they MUST
be implemented by the present association data receiver, i.e., an endpoint MUST
properly receive and process bundled or a past association which fragmented data.

6.1  Transmission of DATA Chunks

This document is no longer in
   existence,

D) The chunk specified as if there is a false message generated by an attacker, or

E) single retransmission
timer per destination transport address, but implementations MAY have
a retransmission timer for each DATA chunk.

The peer never received the COOKIE ACK and is retransmitting its
   COOKIE.

In case A), following general rules MUST be applied by the endpoint shall reset data sender for
transmission and/or retransmission of outbound DATA chunks:

A) At any given time, the present association and set a data sender MUST NOT transmit new association with data to any
   destination transport address if its peer. Case B) is unique and peer's rwnd indicates that the
   peer has no buffer space (i.e. rwnd is discussed in 0, see Section 5.2.1. 6.2.1).

   However, in cases C), D) and E), regardless of the endpoint must retain value of rwnd (including if it is 0),
   the present association.

The rules data sender can always have one DATA chunk in flight to the following sections shall be applied
   receiver if allowed by cwnd (see rule B below). This rule
   allows the sender to probe for a change in order rwnd that the sender
   missed due to
identify and correctly handle these cases.

Stewart, et al                                               [Page  42]

5.2.1 Handle Duplicate INIT the SACK having been lost in COOKIE-WAIT or COOKIE-SENT State

This usually indicates an initialization collision, i.e., both
endpoints are attempting at about transit from
   the same time data receiver to establish an
association with the other endpoint.

In such data sender.

B) At any given time, the sender MUST NOT transmit new data to a case, each
   given transport address if it has cwnd or more bytes of the two side shall respond data
   outstanding to that transport address.

C) When the other side
with an INIT ACK, with the Verification Tag field of time comes for the common header
set sender to transmit, before sending
   new DATA chunks, the tag value received from the INIT message, and sender MUST first transmit any outstanding
   DATA chunks which are marked for retransmission (limited by the Initiate
Tag field set to its own tag value (the same tag used in
   current cwnd).

D) Then, the INIT
message sent sender can send out by itself). Each responder shall also generate as many new DATA chunks as Rule A and
   Rule B above allow.

Multiple DATA chunks committed for transmission MAY be
bundled in a
cookie with the INIT ACK.

After that, no other actions shall single packet. Furthermore, DATA chunks being
retransmitted MAY be taken by either side, i.e., bundled with new DATA chunks, as long as the
endpoint shall
resulting packet size does not change its state, and exceed the T1-init timer shall path MTU. A ULP
may request that no bundling is performed but this should only turn off
any delays that a SCTP implementation may be
left running. The normal procedures for handling cookies will
resolve the duplicate INITs using to a single association.

5.2.2 Handle Duplicate INIT increase
bundling efficiency.  It does not in Other States

Upon reception itself stop all bundling
from occurring (i.e. in case of the duplicated INIT, the receiver shall generate an
INIT ACK with congestion or retransmission).

Before an State Cookie.

In the outbound INIT ACK, the endpoint shall set the Verification Tag
field in the common header to the peer's new tag value (from the
duplicated INIT message), and the Initiate Tag field transmits a DATA chunk, if any received DATA
chunks have not been acknowledged (e.g., due to its own tag
value (unchanged from the existing association). The included
State Cookie shall be generated using delayed ack), the current time and
sender should create a
temporary TCB constructed SACK and bundle it with the information provided in the
duplicated INIT message (see Section 5.1.3). This temporary TCB MUST
be destroyed after the outbound INIT ACK is built.

After sending out DATA
chunk, as long as the INIT ACK, size of the endpoint shall take no further
actions, i.e., final SCTP packet does not exceed
the existing association, including its current state,
and MTU. See Section 6.2.

  IMPLEMENTATION NOTE: When the corresponding TCB MUST not be changed.

5.2.3 Handle Duplicate INIT ACK

If an INIT ACK window is received full (i.e., transmission is
  disallowed by an endpoint in any state
other than the COOKIE-WAIT state, the endpoint should discard
the INIT ACK message. Rule A duplicate INIT ACK usually indicates and/or Rule B), the
processing of an old INIT sender MAY still accept
  send requests from its upper layer, but MUST transmit no more DATA
  chunks until some or duplicated INIT message.

5.2.4 Handle Duplicate Cookie

When a duplicated COOKIE chunk is received in any state for an
existing association the following rules shall be applied:

1) compute a MAC signature using the TCB data carried in the cookie
   along with the receiver's private security key,

Stewart, et al                                               [Page  43]

2) authenticate all of the cookie outstanding DATA chunks are
  acknowledged and transmission is allowed by comparing the computed MAC signature
   against Rule A and Rule B
  again.

Whenever a transmission or retransmission is made to any address, if
the one carried in T3-rtx timer of that address is not currently running, the cookie. sender
MUST start that timer. If this comparison fails,
   the datagram, including the COOKIE and the attached user data,
   should be silently discarded (this timer for that address is case C or D above).

3) compare the timestamp in already
running, the cookie to sender MUST restart the current time, timer if the cookie earliest
(i.e., lowest TSN) outstanding DATA chunk sent to that address is older than the lifespan carried in being
retransmitted.  Otherwise, the cookie, data sender MUST NOT restart the datagram, including timer.

When starting or restarting the COOKIE and T3-rtx timer, the attached user data,
   should timer value must be discarded and
adjusted according to the endpoint MUST transmit timer rules defined in Sections 6.3.2,
and 6.3.3.

  Note: The data sender SHOULD NOT use a stale cookie
   error to TSN that is more than
  2**31 - 1 above the sending beginning TSN of the current send window.

6.2  Acknowledgement on Reception of DATA Chunks

The SCTP endpoint only if MUST always acknowledge the Verification tags reception of each valid
DATA chunk.

The guidelines on delayed acknowledgement algorithm specified in
Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an
acknowledgement SHOULD be generated for at least every second packet
(not every second DATA chunk) received, and SHOULD be generated within
200 ms of the
   cookie's TCB does NOT match arrival of any unacknowledged DATA chunk. In some
situations it may be beneficial for an SCTP transmitter to be more
conservative than the current tag values algorithms detailed in this document allow.
However, an SCTP transmitter MUST NOT be more aggressive than the association
   (this is case C or D above). If both Verification tags do match
   consider
following algorithms allow.

A SCTP receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the cookie valid (this is case E).

4) If offered window as the cookie proves to
receiving application consumes new data.

  IMPLEMENTATION NOTE: The maximum delay for generating an
  acknowledgement may be valid, unpack the TCB into a
   temporary TCB.

5) If configured by the Verification Tags SCTP administrator, either
  statically or dynamically, in order to meet the Temporary TCB matches the
   Verification Tags in specific
  timing requirement of the existing TCB, protocol being carried.

An implementation MUST NOT allow the cookie is a
   duplicate cookie. A cookie ack should maximum delay to be sent configured to the peer
   endpoint
be more than 500 ms. In other words an implementation MAY lower this
value below 500ms but NO update should MUST NOT raise it above 500ms.

Acknowledgements MUST be made to the existing
   TCB.

6) If the sent in SACK chunks unless shutdown was
requested by the local Verification Tag ULP in which case an endpoint MAY send an
acknowledgement in the temporary TCB
   does not match SHUTDOWN chunk. A SACK chunk can acknowledge the local Verification Tag in
reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk
format. In particular, the existing
   TCB, then SCTP endpoint MUST fill in the cookie is an old stale cookie and does
   not correspond Cumulative
TSN Ack field to indicate the latest sequential TSN (of a valid DATA
chunk) it has received. Any received DATA chunks with TSN greater than
the existing association (case C above).
   The datagram should be silently discarded.

7) If value in the peer's Verification Tag Cumulative TSN Ack field SHOULD also be reported in
the temporary TCB Gap Ack Block fields.

  Note:  The SHUTDOWN chunk does not
   match the peer's Verification Tag in the existing TCB,
   then a restart of the peer has occurred (case A above).
   In such a case, contain Gap Ack Block fields.
  Therefore, the endpoint should report use a SACK instead of the restart SHUTDOWN
  chunk to its ULP acknowledge DATA chunks received out of order .

When a packet arrives with duplicate DATA chunk(s) and respond with no new
DATA chunk(s), the peer endpoint MUST immediately send a SACK with no
delay. If a COOKIE ACK message. It shall also
   update the Verification Tag, initial TSN, and packet arrives with duplicate DATA chunk(s) bundled with
new DATA chunks, the destination
   address list endpoint MAY immediately send a SACK.  Normally
receipt of duplicate DATA chunks will occur when the existing TCB with original SACK
chunk was lost and the information from peer's RTO has expired. The duplicate TSN
number(s) SHOULD be reported in the
   temporary TCB. After that SACK as duplicate.

When an endpoint receives a SACK, it MAY use the temporary TCB can be discarded.

   Furthermore, all Duplicate TSN

information to determine if SACK loss is occurring. Further use of
this data is for future study.

The data receiver is responsible for maintaining its receive buffers.
The data receiver SHOULD notify the congestion control parameters data sender in a timely manner of
changes in its ability to receive data.  How an implementation manages
its receive buffers is dependent on many factors (e.g., cwnd,
   ssthresh) related to this peer shall be reset to their initial
   values (see Operating
System, memory management system, amount of memory, etc.).  However,
the data sender strategy defined in Section 6.2.1).

  IMPLEMENTATION NOTE: It 6.2.1 is an implementation decision based on how
  to handle any pending datagrams. The implementation may elect
  to either A) send all messages back to its upper layer with the
  restart report, or B) automatically re-queue any datagrams
  pending by marking all
assumption of them as never-sent and assigning
  new TSN's at receiver operation similar to the time following:

      A) At initialization of their initial transmissions based upon the updated starting TSN (as defined in section 5).

  Note: The "peer's Verification Tag" is association, the tag received endpoint tells the
      peer how much receive buffer space it has allocated to the
      association in the INIT or INIT ACK chunk.

Stewart, et al                                               [Page  44]

5.2.5 Handle Duplicate COOKIE-ACK.

At any state other than COOKIE-SENT, an ACK.  The endpoint may receive a
duplicated COOKIE ACK chunk. If so, sets a_rwnd
      to this value.

      B) As DATA chunks are received and buffered, decrement a_rwnd by
      the chunk should be silently
discarded.

5.2.6 Handle Stale COOKIE Error

A stale cookie error indicates one of a number of possible events:

A) that the association failed to completely setup before the
   cookie issued by bytes received and buffered.  This is, in effect,
      closing rwnd at the data sender was processed.

B) an old cookie was processed after setup completed. and restricting the amount of
      data it can transmit.

      C) an old cookie is received from someone that As DATA chunks are delivered to the receiver is
   not interested in having an association with ULP and released from the ABORT
   message was lost.

When processing a stale cookie an endpoint should first examine
if an association is in the process
      receive buffers, increment a_rwnd by the number of being setup, i.e. bytes
      delivered to the
association is upper layer.  This is, in effect, opening up
      rwnd on the COOKIE-SENT state. In all cases data sender and allowing it to send more data.  The
      data receiver SHOULD NOT increment a_rwnd unless it has released
      bytes from its receive buffer.  For example, if the association receiver is NOT
      holding fragmented DATA chunks in the COOKIE-SENT state, the stale
cookie message a reassembly queue, it should be silently discarded.

If the association is in
      not increment a_rwnd.

      D)  When sending a SACK, the COOKIE-SENT state, data receiver SHOULD place the endpoint may elect
one
      current value of a_rwnd into the following three alternatives.

1) Send a new INIT message to a_rwnd field.  The data
      receiver SHOULD take into account that the endpoint, to generate a new cookie
   and re-attempt data sender will not
      retransmit DATA chunks that are acked via the setup procedure.

2) Discard Cumulative TSN Ack
      (i.e., will drop from its retransmit queue).

Under certain circumstances, the TCB and report data receiver may need to drop
DATA chunks that it has received but hasn't released from its receive
buffers (i.e., delivered to the upper layer the inability of
   setting-up ULP).  These DATA chunks may have
been acked in Gap Ack Blocks.  For example, the association.

3) Send data receiver may be
holding data in its receive buffers while reassembling a new INIT fragmented
user message to the endpoint, adding from its peer when it runs out of receive buffer space.
It may drop these DATA chunks even though it has acknowledged them in
Gap Ack Blocks.  If a cookie
   preservative parameter requesting an extension on data receiver drops DATA chunks, it MUST NOT include
them in Gap Ack Blocks in subsequent SACKs until they are received again
via retransmission.  In addition, the life time of endpoint should take into account the cookie. When
dropped data when calculating the time extension, an implementation its a_rwnd.

An endpoint SHOULD NOT revoke a SACK and discard data. Only in extreme
circumstance should an endpoint use this procedure (such as out of buffer
space).  The data receiver should take into account that dropping data that
has been acked in Gap Ack Blocks can result in suboptimal retransmission
strategies in the RTT information measured based on data sender and thus in suboptimal performance.

The following example illustrates the previous
   COOKIE use of delayed acknowledgements:

Endpoint A                                      Endpoint Z

{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)

DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
                              /------- SACK [TSN Ack=8,block=0]
(cancel T3-rtx timer)  <-----/
...
...

DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rtx timer)
                                       ...
                                       {App sends 1 message; strm 1}
                                       (bundle SACK with DATA)
                                /----- SACK [TSN Ack=9,block=0] \
                               / Stale COOKIE message exchange, and should add         DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rtx timer)  <------/        (Start T3-rtx timer)

(ack delayed)
...
(send ack)
SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)

       Figure 5:  Delayed Acknowledgment Example

If an endpoint receives a DATA chunk with no more
   than 1 second beyond user data (i.e., the measured RTT, due
Length field is set to a long cookie life
   time makes the endpoint more subject 16) it MUST send an ABORT with error cause set
to "No User Data".

An endpoint SHOULD NOT send a replay attack.

5.3 Other Initialization Issues

5.3.1 Selection of Tag Value

Initiate Tag values should be selected from DATA chunk with no user data part.

6.2.1  Processing a Received SACK

Each SACK an endpoint receives contains an a_rwnd value. This value
represents the amount of buffer space the range data receiver, at the time
of 0x1 to
0xffffffff. It is very important that transmitting the Tag value be randomized to
help protect against "man SACK, has left of its total receive buffer space (as
specified in the middle" INIT/INIT ACK).  Using a_rwnd, Cumulative TSN Ack and "sequence number" attacks.
It is suggested that RFC 1750 [1] be used for the Tag randomization.

Stewart, et al                                               [Page  45]

Moreover, Gap
Ack Blocks, the tag value used by either endpoint in data sender can develop a given association
MUST never be changed during representation of the lifetime peer's
receive buffer space.

One of the association. However, problems the data sender must take into account when processing
a new tag value MUST SACK is that a SACK can be used each time the endpoint tears-down and
then re-establishes the association to the same peer.

6. User Data Transfer

For transmission efficiency, SCTP defines mechanisms for bundling received out of
small user messages order.  That is, a SACK sent
by the data receiver can pass an earlier SACK and segmentation of large user messages.
The following diagram depicts be received first by the flow
data sender.  If a SACK is received out of user messages through SCTP.

              +--------------------------+
              |      User Messages       |
              +--------------------------+
    SCTP user        ^  |
   ==================|==|=======================================
                     |  v (1)
          +------------------+    +--------------------+
          | SCTP DATA Chunks |    |SCTP Control Chunks |
          +------------------+    +--------------------+
                     ^  |             ^  |
                     |  v (2)         |  v (2)
                  +--------------------------+
                  |      SCTP datagrams      |
                  +--------------------------+
    SCTP                      ^  |
   ===========================|==|===========================
                              |  v
          Unreliable Packet Transfer Service (e.g., IP)

   Note:
   (1) When converting user messages into Data chunks, SCTP sender
       will segment user messages larger than order, the current path MTU
       into multiple data chunks. The segmented message will normally sender can
develop an incorrect view of the peer's receive buffer space.

Since there is no explicit identifier that can be reassembled from used to detect

out-of-order SACKs, the data chunks before delivery sender must use heuristics to determine if a
SACK is new.

An endpoint SHOULD use the user by following rules to calculate the SCTP receiver (see Section 6.9 for details).

   (2) Multiple data and control chunks may be multiplexed by rwnd, using the
       sender into
a_rwnd value, the Cumulative TSN Ack and Gap Ack Blocks in a single SCTP datagram for transmission, as long as received SACK.

A) At the final size establishment of the datagram does not exceed association, the current path
       MTU. The receiver will de-multiplex endpoint
    initializes the datagram back into rwnd to the original chunks.

The segmentation and bundling mechanisms, as detailed Advertised Receiver Window
    Credit (a_rwnd) the peer specified in Sections 6.9
and 6.10, are optional the INIT or INIT ACK.

B) Any time a DATA chunk is transmitted (or retransmitted)
    to implement by a peer, the endpoint subtracts the data sender, but they MUST size of the
    chunk from the rwnd of that peer.

C) Any time a DATA chunk is marked for retransmission (via
    either T3-rtx timer expiration (Section 6.3.3)or via fast
    retransmit (Section 7.2.4)), add the data size of
    those chunks to the rwnd.

    Note: If the implementation is maintaining a timer on each
    DATA chunk then only DATA chunks whose timer expired would
    be implemented by marked for retransmission.

D) Any time a SACK arrives, the endpoint performs the following:

    i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point,
    then drop the SACK.   Since Cumulative TSN Ack is monotonically
    increasing, a SACK whose Cumulative TSN Ack is less than the data receiver, i.e.,
    Cumulative TSN Ack Point indicates an SCTP receiver MUST be
prepared out-of-order SACK.

    ii) Set rwnd equal to receive and process bundled or segmented data.

Stewart, et al                                               [Page  46]

6.1  Transmission of DATA Chunks

The following general rules SHALL be applied by the sender for
transmission and/or retransmission newly received a_rwnd minus the number
    of outbound DATA chunks:

A) At any given time, bytes still outstanding after processing the sender MUST NOT transmit new data onto any
   destination transport address if its peer's rwnd indicates that Cumulative TSN Ack
    and the
   peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1).

   However, regardless of Gap Ack Blocks.

    iii) If the value of rwnd (including if it SACK is 0), missing a TSN that was previously
    acknowledged via a Gap Ack Block (e.g., the sender can always have ONE data packet in flight to the receiver if allowed by cwnd (see rule B below). This rule
   allows
    reneged on the sender to probe data), then mark the corresponding DATA chunk
    as available for a change retransmit:  Mark it as missing for fast
    retransmit as described in rwnd that Section 7.2.4 and if no retransmit
    timer is running for the sender
   missed due destination address to which the update having been lost in transmission from
   the receiver DATA
    chunk was originally transmitted, then T3-rtx is started for
    that destination address.

6.3 Management of Retransmission Timer

An SCTP endpoint uses a retransmission timer T3-rtx to ensure data
delivery in the sender.

B) At absence of any given time, the sender MUST NOT transmit new data onto feedback from its peer. The duration of
this timer is referred to as RTO (retransmission timeout).

When an endpoint's peer is multi-homed, the endpoint will calculate a
   given
separate RTO for each different destination transport address if it has cwnd or more octets of data
   outstanding on that transport address.

C) When its
peer endpoint.

The computation and management of RTO in SCTP follows closely how

TCP manages its retransmission timer. To compute the current RTO, an
endpoint maintains two state variables per destination transport
address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time comes for the sender to transmit, before sending
   new DATA chunks,
variation).

6.3.1 RTO Calculation

The rules governing the sender MUST first transmit any outstanding
   DATA chunks which computation of SRTT, RTTVAR, and RTO are marked
as follows:

C1) Until an RTT measurement has been made for retransmission (limited by a packet sent
    to the
   current cwnd).

D) Then, given destination transport address, set RTO to the sender can send out as many new DATA chunks as Rule A
    protocol parameter 'RTO.Initial'.

C2) When the first RTT measurement R is made, set SRTT <- R,
    RTTVAR <- R/2, and
   Rule B above allow.

Note: multiple DATA chunks committed for transmission MAY be
bundled in RTO <- SRTT + 4 * RTTVAR.

C3) When a single packet, unless bundling new RTT measurement R' is explicitly disallowed
by ULP made, set

    RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
    SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

    Note: The value of SRTT used in the update to RTTVAR is its value
    before updating SRTT itself using the second assignment.

    After the computation, update RTO <- SRTT + 4 * RTTVAR.

C4) When data sender. Furthermore, DATA chunks being
retransmitted MAY is in flight and when allowed by rule C5 below, a new
    RTT measurement MUST be bundled with made each round trip.  Furthermore, new DATA chunks, as long as the
resulting packet size RTT
    measurements SHOULD be made no more than once per round-trip for a
    given destination transport address. There are two reasons for this
    recommendation:  First, it appears that measuring more frequently
    often does not exceed the path MTU.

Note: before a sender transmits a data packet, if in practice yield any received DATA
chunks have not been acknowledged (e.g., due to delayed ack), significant benefit
    [ALLMAN99]; second, if measurements are made more often, then the
sender
    values of RTO.Alpha and RTO.Beta in rule C3 above should create a SACK be
    adjusted so that SRTT and bundle it with RTTVAR still adjust to changes at roughly
    the outbound DATA
chunk, same rate (in terms of how many round trips it takes them to
    reflect new values) as long they would if making only one measurement
    per round-trip and using RTO.Alpha and RTO.Beta as given in rule
    C3. However, the size exact nature of the final SCTP datagram does not exceed
the current MTU. See Section 6.2.

  IMPLEMENTATION Note: when the window is full (i.e., transmission these adjustments remains a
    research issue.

C5) Karn's algorithm: RTT measurements MUST NOT be made using
    packets that were retransmitted (and thus for which it is
  disallowed by Rule A and/or Rule B),
    ambiguous whether the sender MAY still accept
  send requests from its upper layer, but SHALL transmit no more DATA
  chunks until some or all reply was for the first instance of the outstanding DATA chunks are
  acknowledged and transmission is allowed by Rule A and Rule B
  again.

Whenever a transmission
    packet or retransmission a later instance).

C6) Whenever RTO is made to any address, computed, if
the T3-rxt timer of that address it is less than RTO.Min seconds
    then it is rounded up to RTO.Min seconds. The reason for this
    rule is not currently running, the sender
MUST start that timer. However, if the timer of RTOs that address do not have a high minimum value are
    susceptible to unnecessary timeouts [ALLMAN99].

C7) A maximum value may be placed on RTO provided it is
already running, at least
    RTO.max seconds.

There is no requirement for the sender SHALL restart clock granularity G used for computing
RTT measurements and the timer ONLY IF different state variables, other than:

    G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust
    RTTVAR <- G.

Experience [ALLMAN99] has shown that finer clock granularities
(<= 100 msec) perform somewhat better than more coarse granularities.

6.3.2 Retransmission Timer Rules

The rules for managing the
earliest (i.e., lowest TSN) outstanding retransmission timer are as follows:

R1) Every time a DATA chunk is sent to that any address is being retransmitted.

Stewart, et al                                               [Page  47]

When starting or restarting the T3-rxt timer, the timer value must be
adjusted according to (including
    a retransmission), if the T3-rtx timer rules defined in Sections 6.3.2,
and 6.3.3.

Note: The sender SHOULD not use a TSN of that address is more than 2**31 - 1
above the beginning TSN of the current send window.

6.2  Acknowledgment on Reception of DATA Chunks

The SCTP receiver MUST always acknowledge the SCTP sender about not
    running, start it running so that it will expire after the
reception RTO of each DATA chunk.
    that address. The guidelines RTO used here is that obtained after any doubling
    due to previous T3-rtx timer expirations on delayed acknowledgment algorithm specified the corresponding
    destination address as discussed in
Section 4.2 of RFC 2581 [3] SHOULD be followed. Specifically, rule E2 below.

R2) Whenever all outstanding data sent to an
acknowledgment SHOULD be generated for at least every second datagram
received, and SHOULD be generated within 200 ms of address have been
    acknowledged, turn off the arrival T3-rtx timer of any
unacknowledged datagram.

  IMPLEMENTATION NOTE: that address.

R3) Whenever a SACK is received that acknowledges the maximal delay DATA chunk with
    the earliest outstanding TSN for that address, restart T3-rtx timer
    for that address with its current RTO.

(R4) Whenever a SACK is received missing a TSN that was previously acknowledged
     via a Gap Ack Block, start T3-rtx for generating an
  acknowledgment may be configured by the SCTP user, either
  statically or dynamically, in order destination address to meet which
     the specific
  timing requirement DATA chunk was originally transmitted if it is not already running.

The following example shows the use of various timer rules (assuming
the signaling protocol being carried.

Acknowledgments MUST be sent in SACK control chunks. receiver uses delayed acks).

Endpoint A                                         Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
                                        {App sends 1 message; strm 1}
                                        (bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\     /-- SACK chunk can
acknowledge the reception of multiple [TSN Ack=7,Block=0] \
                               \   /      DATA chunks. See Section 3.3.3
for [TSN=6,Strm=1,Seq=2]
                                \ /     (Start T3-rtx timer)
                                 \
                                / \
(Re-start T3-rtx timer) <------/   \--> (ack delayed)
(ack delayed)
...
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
                                        ..
                                        (send ack)
(Cancel T3-rtx timer)  <-------------- SACK chunk format. In particular, the SCTP receiver MUST fill in
the Cumulative TSN ACK field to indicate the latest cumulative TSN
number it has received, and any received segments beyond the
Cumulative TSN SHALL also be reported.

Upon reception of [TSN Ack=8,Block=0]

              Figure 6 - Timer Rule Examples

6.3.3 Handle T3-rtx Expiration

Whenever the SACK, retransmission timer T3-rtx expires for a destination
address, do the data sender MUST adjust its total
outstanding data count and following:

E1) For the outstanding data count on those destination addresses address for which one or more data chunks is
acknowledged by the SACK.

Note: When a datagram arrives timer expires, adjust its
    ssthresh with duplicate DATA chunk(s) rules defined in Section 7.2.3 and no new
DATA chunk(s), set the receiver MUST immediately send a SACK with no
delay. Normally this will occur when
    cwnd <- MTU.

E2) For the original SACK was lost, and destination address for which the peers timer expires, set
    RTO has expired. <- RTO * 2 ("back off the timer"). The duplicate TSN number(s) SHOULD be
reported maximum value discussed
    in rule C7 above (RTO.max) may be used to provide an upper bound
    to this doubling operation.

E3) Determine how many of the SACK as duplicate.

When a receiver prepares a SACK, any duplicate earliest (i.e., lowest TSN) outstanding
    DATA chunks received
SHOULD be reported in the SACK.

When a SACK is received the receiver MAY use for the Duplicate TSN
information to determine if SACK loss is occurring. Further use
of this data is address for future study.

Note: If a SACK is received that indicates a previously out of order
chunk which the T3-rtx has been discarded by expired will
    fit into a single packet, subject to the receiver (due MTU constraint for the
    path corresponding to a buffer space
shortage), the sender should mark destination transport address to which
    the chunk as having a first strike retransmission is being sent (this may be different from the
    address for retransmit against which the chunk timer expires [see Section 6.4]). Call this
    value K. Bundle and start retransmit those K DATA chunks in a single
    packet to the destination endpoint.

E4) Start the retransmission timer T3-rtx on the last
transmitted destination address (if one
    to which the retransmission is not already running on that
destination address). sent, if rule R1 above indicates to
    do so.  The sender SHOULD not retransmit the chunk until RTO to be used for starting T3-rtx should be the fast retransmit algorithm indicates it should. This will allow
    one for the
receiver time destination address to clear up which the receive buffer problem that caused it to
discard retransmission is
    sent, which, when the chunk.

The following example illustrates receiver is multi-homed, may be different
    from the use of delayed acknowledgments:

Endpoint A                                      Endpoint Z

{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rxt timer)

Stewart, et al                                               [Page  48]

DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
                              /------- SACK [TSN ACK=8,Frag=0]
(cancel T3-rxt timer)  <-----/
...
...

DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rxt timer)
                                       ...
                                       {App sends 1 message; strm 1}
                                       (bundle SACK with DATA)
                                /----- SACK [TSN Ack=9,Frag=0] \
                               /         DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rxt timer)  <------/        (Start T3-rxt timer)

(ack delayed)
...
(send ack)
SACK [TSN ACK=6,Frag=0] -------------> (cancel T3-rxt timer)

Note: If destination address for which the timer expired (see
    Section 6.4 below).

After retransmitting, once a new RTT measurement is obtained
(which can happen only when new data has been sent and acknowledged,
per rule C5, or for a receiver receives measurement made from a DATA chunk with 0 length (no user data
part) it MUST follow HEARTBEAT [see Section
8.3]), the normal procedures for handling TSN and stream
sequence number. However, computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down
after it MAY choose not has been subject to deliver the NULL data doubling (rule E2).

  Note: Any DATA chunks that were sent to the upper layer.

6.2.1 Tracking Peer's Receive Buffer Space

Whenever address for which the
  T3-rtx timer expired but did not fit in one MTU (rule E3 above),
  should be marked for retransmission and sent as soon as cwnd allows
  (normally when a SACK arrives, arrives).

The final rule for managing the retransmission timer concerns failover
(see Section 6.4.1):

F1) Whenever an endpoint switches from the current destination
    transport address to a new updated a_rwnd arrives with it. This
value represents different one, the amount of buffer space current retransmission
    timers are left running. As soon as the sender of endpoint transmits a packet
    containing DATA chunk(s) to the SACK, at new transport address, start the time of transmitting
    timer on that transport address, using the SACK, has left RTO value of its total receive
buffer space (as specified in the INIT/INIT-ACK). After processing
    destination address to which the
SACK, data is being sent, if rule R1
    indicates to do so.

6.4 Multi-homed SCTP Endpoints

An SCTP endpoint is considered multi-homed if there are more than one
transport address that can be used as a destination address to reach
that endpoint.

Moreover, the ULP of an endpoint shall select one of the receiver multiple
destination addresses of a multi-homed peer endpoint as the SACK primary
path (see Sections 5.1.2 and 10.1 for details).

By default, an endpoint SHOULD use the following rules always transmit to
re-calculate the rwnd, using the received a_rwnd value.

A) At the establishment of primary
path, unless the association, SCTP user explicitly specifies the destination
transport address (and possibly source transport address) to use.

An endpoint initializes
   the rwnd SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the Advertised Receiver Window Credit (a_rwnd)
   the peer specified in same destination transport address from which it received
the INIT or INIT ACK.

B) Any time a DATA or control chunk is transmitted to a peer, which it is replying. This rule should
also be followed if the endpoint
   subtracts the data size of is bundling DATA chunks together
with the chunk reply chunk.

However, when acknowledging multiple DATA chunks received in packets
from the rwnd of that peer.

C) Any time different source addresses in a SACK arrives, the endpoint performs the following:

   If all outstanding TSNs are acknowledged by the single SACK, adopt
   the a_rwnd value in the SACK as chunk may be
transmitted to one of the new rwnd.

   Otherwise, take destination transport addresses from which
the value DATA or control chunks being acknowledged were received.

When a receiver of the current rwnd, and add a duplicate DATA chunk sends a SACK to a multi-homed
endpoint it MAY be beneficial to vary the
   data size destination address and not
use the source address of any newly acknowledged TSNs the DATA chunk. The reason being that has its BE bits set
   to 11, OR
receiving a duplicate from a multi-homed endpoint might indicate that moved
the cumulative TSN point forward. Then, set
   the rwnd to return path (as specified in the lesser source address of the calculated value and the a_rwnd carried
   in the SACK.

D) Any time DATA chunk)
for the T3-rxt timer expires on any address, causing all
   outstanding chunks sent SACK is broken.

Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk to an active destination transport address that is
different from the last destination address to be marked for
   retransmission, add all of which the DATA chunk was
sent.

Retransmissions do not affect the total outstanding data sizes of those chunks to
count. However, if the rwnd.

Stewart, et al                                               [Page  49]

E) Any time a DATA chunk is marked for retransmission via retransmitted onto a different
destination address, both the
   fast retransmit algorithm (section 6.2.4), add outstanding data counts on the DATA chunks
   size new
destination address and the old destination address to which the rwnd.

6.3 Management data
chunk was last sent shall be adjusted accordingly.

6.4.1 Failover from Inactive Destination Address

Some of the transport addresses of Retransmission Timer

SCTP uses a retransmission timer T3-rxt multi-homed SCTP endpoint may
become inactive due to ensure data delivery in either the
absence occurrence of any feedback certain error
conditions (see Section 8.2) or adjustments from SCTP user.

When there is outbound data to send and the remote primary path becomes
inactive (e.g., due to failures), or where the SCTP user explicitly
requests to send data receiver. The duration of
this timer is referred to as RTO (retransmission timeout).

When an inactive destination transport address,
before reporting an error to its ULP, the receiver SCTP endpoint is multi-homed, should try to
send the data sender endpoint
will calculate a separate RTO for each different to an alternate active destination transport
addresses of address if
one exists.

When retransmitting data, if the receiver endpoint.

The computation and management of RTO endpoint is multi-homed, it should
consider each source-destination address pair in SCTP follows closely with how
TCP manages its retransmission timer. To compute
selection policy. When retransmitting the current RTO, endpoint should attempt to
pick the most divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.

  Note: Rules for picking the most divergent source-destination pair
  are an
SCTP sender maintains two state variables per destination transport
address: SRTT (smoothed round-trip time) implementation decision and RTTVAR (round-trip time
variation).

6.3.1 RTO Calculation

The rules governing the computation of SRTT, RTTVAR, is not specified within this
  document.

6.5 Stream Identifier and RTO are
as follows:

C1) Until Stream Sequence Number

Every DATA chunk MUST carry a valid stream identifier. If an RTT measurement has been made for endpoint
receives a packet sent
    to DATA chunk with an invalid stream identifier, it shall
acknowledge the given destination transport address, set RTO to reception of the
    protocol parameter 'RTO.Initial'.

C2) When DATA chunk following the first RTT measurement R is made, normal
procedure, immediately send an ERROR chunk with cause set SRTT <- R,
    RTTVAR <- R/2, to "Invalid
Stream Identifier" (see Section 3.3.10) and RTO <- SRTT + 4 * RTTVAR.

C3) When a new RTT measurement R' is made, set

    RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
    SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'

    Note, discard the DATA chunk.
The endpoint may bundle the ERROR chunk in the same packet as the SACK
as long as the ERROR follows the value of SRTT used SACK.

The stream sequence number in all the update to RTTVAR streams shall start from 0
when the association is its value
    *before* updating SRTT itself using established. Also, when the second assignment.

    After stream sequence
number reaches the computation, update RTO <- SRTT + 4 * RTTVAR.

Stewart, et al                                               [Page  50]

C4) When data is in flight value 65535 the next stream sequence number shall
be set to 0.

6.6 Ordered and when allowed by rule C5 below, Unordered Delivery

Within a new
    RTT measurement stream, an endpoint MUST be made each round trip.  Furthermore,
    it is RECOMMENDED that new RTT measurements should be made no
    more than once per round-trip for a given destination transport
    address. There are two reasons for this recommendation:  first,
    it appears that measuring more frequently often does not in
    practice yield any significant benefit [5]; second, if
    measurements are made more often, then deliver DATA chunks received with the values of RTO.Alpha and
    RTO.Beta in rule C3 above should be adjusted so that SRTT and
    RTTVAR still adjust
U flag set to 0 to changes at roughly the same rate (in terms
    of how many round trips it takes them upper layer according to reflect new value) as
    they would if making only one measurement per round-trip and
    using RTO.Alpha and RTO.Beta as given in rule C3. However, the
    exact nature order of these adjustments remains a research issue.

C5) Karn's algorithm: RTT measurements their
stream sequence number. If DATA chunks arrive out of order of their
stream sequence number, the endpoint MUST NOT be made using
    packets hold the received DATA chunks
from delivery to the ULP until they are re-ordered.

However, an SCTP endpoint can indicate that were retransmitted (and thus for which it no ordered delivery is
    ambiguous whether the reply was
required for a particular DATA chunk transmitted within the first instance stream by
setting the U flag of the
    packet or DATA chunk to 1.

When an endpoint receives a later instance).

C6) Whenever RTO is computed, if it is less than RTO.Min seconds
    then DATA chunk with the U flag set to 1, it is rounded up
must bypass the ordering mechanism and immediately deliver the data to RTO.Min seconds. The reason for this
    rule
the upper layer (after re-assembly if the user data is that RTOs that do not have fragmented by
the data sender).

This provides an effective way of transmitting "out-of-band" data in a high minimum value are
    susceptible
given stream. Also, a stream can be used as an "unordered" stream by
simply setting the U flag to unnecessary timeouts [5].

C7) A maximum value 1 in all DATA chunks sent through that
stream.

  IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an
  implementation may be placed on RTO provided it choose to place the DATA chunk in an outbound
  packet that is at least
    RTO.max seconds.

There is no requirement for the clock granularity G used for computing
RTT measurements and head of the different state variables, other than

G1) Whenever RTTVAR is computed, outbound transmission queue if RTTVAR = 0, then adjust
    RTTVAR <- G.

Experience [5] has shown that finer clock granularities (<= 100 msec)
perform somewhat better than more coarse granularities.

6.3.2 Retransmission Timer Rules
  possible.

The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1
has no significance. The rules for managing sender can fill it with arbitrary value, but
the retransmission timer are as follows:

R1) Every time receiver MUST ignore the field.

  Note:  When transmitting ordered and unordered data, an endpoint does
  not increment its Stream Sequence Number when transmitting a packet containing data is sent DATA
  chunk with U flag set to any address (including 1.

6.7 Report Gaps in Received DATA TSNs

Upon the reception of a retransmission), if new DATA chunk, an endpoint shall examine
the T3-rxt timer continuity of that address is not
    running, start it running so that the TSNs received. If the endpoint detects a gap
in the received DATA chunk sequence, it will expire SHOULD send a SACK with Gap Ack
Blocks immediately. The data receiver continues sending a SACK after the RTO
receipt of each SCTP packet that address. The RTO used here doesn't fill the gap.

Based on the Gap Ack Block from the received SACK, the endpoint
can calculate the missing DATA chunks and make decisions on whether to
retransmit them (see Section 6.2.1 for details).

Multiple gaps can be reported in one single SACK (see Section 3.3.4).

When its peer is that obtained after any doubling
    due multi-homed, the SCTP endpoint SHOULD always
try to previous T3-rxt timer expirations on send the corresponding SACK to the same destination address as discussed in rule E2 below.

R2) Whenever from which the
last DATA chunk was received.

Upon the reception of a SACK, the endpoint MUST remove all DATA
chunks which have been acknowledged by the SACK's Cumulative TSN Ack
from its transmit queue. The endpoint MUST also treat all outstanding data on an address has been acknowledged,
    turn off the T3-rxt timer of that address.

Stewart, et al                                               [Page  51]

R3) Whenever a SACK is received that acknowledges new data DATA
chunks
    including the one with TSNs not included in the earliest outstanding TSN on that address,
    restart T3-rxt timer Gap Ack Blocks reported by the
SACK as "missing". The number of that address with its current RTO. "missing" reports for each outstanding
DATA chunk MUST be recorded by the data sender in order to make
retransmission decisions.  See Section 7.2.4 for details.

The following example shows the use of various timer rules (assuming
the receiver uses delayed acks). SACK to report a gap.

Endpoint A                                    Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rxt T3-rtx timer)
                                        {App sends 1 message; strm 1}
                                        (bundle ack with data)

DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)

DATA [TSN=8,Strm=0,Seq=4] ----\     /-- ---------------> (gap detected,
                                            immediately send ack)
                                /----- SACK [TSN ACK=7,Frag=0] \
                               \   /      DATA [TSN=6,Strm=1,Seq=2]
                                \ /     (Start T3-rxt timer)
                                 \ Ack=6,Block=1,
                               / \
(Re-start T3-rxt timer) <------/   \--> (ack delayed)
(ack delayed)
...
{send ack}             Strt=2,End=2]
                        <-----/
(remove 6 from out-queue,
 and mark 7 as "1" missing report)

           Figure 8 - Reporting a Gap using SACK [TSN ACK=6,Frag=0] --------------> (Cancel T3-rxt timer)
                                        ..
                                        (send ack)
(Cancel T3-rxt timer)  <--------------

The maximum number of Gap Ack Blocks that can be reported within a
single SACK [TSN ACK=8,Frag=0]

6.3.3 Handle T3-rxt Expiration

Whenever chunk is limited by the current path MTU. When a single
SACK can not cover all the Gap Ack Blocks needed to be reported due to
the MTU limitation, the endpoint MUST send only one SACK, reporting the
Gap Ack Blocks from the lowest to highest TSNs, within the size limit
set by the retransmission timer T3-rxt expires MTU, and leave the remaining highest TSN numbers
unacknowledged.

6.8 Adler-32 Checksum Calculation

When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on a destination
address, do the following:

E1) On packet, as described below.

After the destination address where packet is constructed (containing the timer expires, adjust its
    ssthresh with rules defined SCTP common header
and one or more control or DATA chunks), the transmitter shall:

1) Fill in Section 7.2.3 the proper Verification Tag in the SCTP common header and set
   initialize the
    cwnd <- MTU.

E2) On checksum field to 0's.

2) Calculate the destination address where Adler-32 checksum of the timer expires, set
    RTO <- RTO * 2 ("back off whole packet, including the timer"). The maximum
   SCTP common header and all the chunks. Refer to appendix B
   for details of the Adler-32 algorithm. And,

3) Put the resultant value discussed into the checksum field in rule C7 above (RTO.max) may be used to provide the
   common header, and leave the rest of the bits unchanged.

When an upper bound
    to this doubling operation.

E3) Determine how many SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:

1) Store the received Adler-32 checksum value aside,

2) Replace the 32 bits of the earliest (i.e., lowest TSN) outstanding
    Data chunks on checksum field in the address where received
   SCTP packet with all '0's and calculate an Adler-32 checksum
   value of the T3-rxt has expired whole received packet. And,

3) Verify that will
    fit into a single packet, subject to the MTU constraint for calculated Adler-32 checksum is the same as the
    path corresponding to
   received Adler-32 checksum, If not, the destination transport address where receiver MUST treat the
    retransmission
   packet as an invalid SCTP packet.

The default procedure for handling invalid SCTP packets is being sent to (this may be different from the
    address where the timer expires [see Section 6.4]). Call this
    value K. Bundle
silently discard them.

6.9 Fragmentation and retransmit those K data chunks in Reassembly

An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint
supports fragmentation, it MUST fragment a single
    packet to the address.

Stewart, et al                                               [Page  52]

E4) Start the retransmission timer T3-rxt on user message if the destination address
    to where size of
the retransmission is sent, if rule R1 above indicates user message to
    do so. Note, be sent causes the RTO outbound SCTP packet size to be used for starting T3-rxt should be
exceed the
    one current MTU. If an implementation does not support
fragmentation of outbound user messages, the destination address endpoint must return an
error to where its upper layer and not attempt to send the retransmission is
    sent, which, when user message.

  IMPLEMENTATION NOTE:  In this error case, the receiver Send primitive
  discussed in Section 10.1 would need to return an error to the upper
  layer.

If its peer is multi-homed, may be different
    from the destination address where the timer expired (see Section
    6.4 below).

Note that after retransmitting, once a new RTT measurement is obtained
(which can happen only when new data has been sent and acknowledged,
per rule C5, or for a measurement made from endpoint shall choose a Heartbeat [see Section
8.3]),
size no larger than the computation in rule C3 association Path MTU. The association Path
MTU is performed, including the
computation smallest Path MTU of RTO, which may result in "collapsing" RTO back down
after all destination addresses.

  Note: Once a message is fragmented it cannot be re-fragmented.
  Instead if the PMTU has been subject to doubling (rule E2).

The final rule reduced, then IP fragmentation must be
  used.  Please see Section 7.3 for managing details of PMTU discovery.

When determining when to fragment, the retransmission timer concerns failover
(see Section 6.4.1):

F1) Whenever SCTP switches from the current destination transport
    address to a different one, implementation MUST take
into account the current retransmission timers are
    left running. As soon as SCTP transmits a packet containing data
    to the new transport address, start header as well as the timer on that transport
    address, using DATA chunk
header(s). The implementation MUST also take into account the RTO value of space
required for a SACK chunk if bundling a SACK chunk with the destination address where DATA chunk.

Fragmentation takes the following steps:

1) The data is being sent, if rule R1 indicates to do so.

6.4 Multi-homed SCTP Endpoints

An sender MUST break the user message into a series of
   DATA chunks such that each chunk plus SCTP endpoint is considered multi-homed if there are more overhead fits into an IP
   datagram smaller than one
transport addresses that can be used as a destination address or equal to reach
that endpoint.

Moreover, at the sender side, one of the multiple destination
addresses association Path MTU.

2) The transmitter MUST then assign, in sequence, a separate TSN to
   each of the multi-homed receiver endpoint shall be selected as
the primary destination transport address by the UPL (see Sections
5.1.2 and 10.1 for details).

When the SCTP sender is transmitting to DATA chunks in the multi-homed receiver, by
default series.  The transmitter assigns the transmission SHOULD always take place on
   same SSN to each of the primary
transport address, unless DATA chunks.  If the SCTP user explicitly specifies indicates that the
destination transport address
   user message is to use.

The acknowledgment SHOULD be transmitted to the same destination
transport address from which delivered using unordered delivery, then the U
   flag of each DATA or control chunk being
acknowledged were received.

However, when acknowledging multiple DATA chunks in a single SACK, of the
SACK user message may MUST be transmitted set to one of 1.

3) The transmitter MUST also set the destination transport
addresses from which B/E bits of the first DATA or control chunks being acknowledged
were received.

Stewart, et al                                               [Page  53]

Furthermore, when the receiver is multi-homed, the SCTP data sender
SHOULD try to retransmit a chunk
   in the series to an active destination transport
address that is different from '10', the last destination address where B/E bits of the
data last DATA chunk was sent to.

Note, retransmissions do not affect in the total outstanding data
count. However, if
   series to '01', and the data chunk is retransmitted onto a different
destination address, both B/E bits of all other DATA chunks in the outstanding data counts on
   series to '00'.

An endpoint MUST recognize fragmented DATA chunks by examining the new
destination address B/E
bits in each of the received DATA chunks, and queue the old destination address where fragmented DATA
chunks for re-assembly. Once the data
chunk was last sent to user message is reassembled, SCTP
shall be adjusted accordingly.

6.4.1 Failover from Inactive Destination Address

Some of pass the re-assembled user message to the specific stream for
possible re-ordering and final dispatching.

  Note: If the destination transport addresses of a multi-homed SCTP data receiver may become inactive due runs out of buffer space while still
  waiting for more fragments to either complete the occurrence re-assembly of certain
error conditions the
  message, it should dispatch part of its inbound message through a
  partial delivery API (see Section 8.2) or adjustments from SCTP user.

When there is 10), freeing some of its receive
  buffer space so that the rest of the message may be received.

6.10 Bundling

An endpoint bundles chunks by simply including multiple chunks in one
outbound data to send and SCTP packet. The total size of the primary destination
transport address becomes inactive (e.g., due to failures), or where resultant IP datagram,
including the SCTP user explicitly requests to send data to an inactive
destination transport address, before reporting an error packet and IP headers, MUST be less or equal to the
current Path MTU.

If its ULP, peer endpoint is multi-homed, the SCTP sender should try to send sending endpoint shall choose
a size no larger than the data to an alternate active
destination transport address if one exists.

6.5 Stream Identifier and Stream Sequence Number

Every latest MTU of the current primary path.

When bundling control chunks with DATA chunk chunks, an endpoint MUST carry place
control chunks first in the outbound SCTP packet. The transmitter
MUST transmit DATA chunks within a valid stream identifier. If SCTP packet in increasing order of
TSN.
  Note:  Since control chunks must be placed first in a packet and
  since DATA chunk chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK
  chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK
  chunks.

Partial chunks MUST NOT be placed in an invalid stream identifier is received, SCTP packet.

An endpoint MUST process received chunks in their order in the packet.
The receiver shall,
after acknowledging the reception of uses the DATA chunk following the normal
procedure, respond immediately with an ERROR message with cause set length field to
Invalid Stream Identifier (see Section 3.3.9) determine the end of a
chunk and discard beginning of the DATA
chunk.

The stream sequence number in next chunk taking account of the fact that
all chunks end on a 4 byte boundary. If the streams shall start from 0x0
when receiver detects a partial
chunk, it MUST drop the association chunk.

An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with
any other chunks.

7. Congestion control

Congestion control is established. Also, when the stream sequence
number reaches the value 0xffff one of the next stream sequence number shall basic functions in SCTP.
For some applications, it may be set to 0x0.

6.6 Ordered and Un-ordered Delivery

By default the SCTP receiver shall ensure the DATA chunks within any
given stream likely that adequate resources will
be delivered allocated to the upper layer according SCTP traffic to the order of
their stream sequence number. If there are DATA chunks arriving out assure prompt delivery of
time-critical data - thus it would appear to be unlikely, during
normal operations, that transmissions encounter severe congestion
conditions. However SCTP must operate under adverse operational
conditions, which can develop upon partial network failures or
unexpected traffic surges.  In such situations SCTP must follow correct
congestion control steps to recover from congestion quickly in order of their stream sequence number,
to get data delivered as soon as possible.  In the receiver MUST hold absence of network
congestion, these preventive congestion control algorithms should show
no impact on the
received DATA chunks from delivery until they protocol performance.

  IMPLEMENTATION NOTE: As far as its specific performance requirements
  are re-ordered.

However, met, an SCTP sender can indicate that no ordered delivery implementation is
required on always allowed to adopt a particular DATA chunk within more
  conservative congestion control algorithm than the stream one defined
  below.

The congestion control algorithms used by setting SCTP are based on

[RFC2581].  This section describes how the U
flag of algorithms defined in
RFC2581 are adapted for use in SCTP.  We first list differences in
protocol designs between TCP and SCTP, and then describe SCTP's
congestion control scheme.  The description will use the DATA chunk same
terminology as in TCP congestion control whenever appropriate.

SCTP congestion control is always applied to 1.

Stewart, et al                                               [Page  54]

In this case, the receiver must bypass the ordering mechanism entire association,
and
immediately delivery the data NOT to individual streams.

7.1 SCTP Differences from TCP Congestion control

Gap Ack Blocks in the upper layer (after re-assembly if SCTP SACK carry the user data is segmented by same semantic meaning as the sender).

This provides an effective way of transmitting "out-of-band" data
TCP SACK. TCP considers the information carried in a
given stream. Also, a stream can be used the SACK as an "unordered" stream by
simply setting advisory
information only. SCTP considers the U flag to 1 information carried in all outbound DATA chunks sent
through that stream.

  IMPLEMENTATION NOTE: when sending an unordered DATA chunk, an
  implementation may choose to place the Gap Ack
Blocks in the SACK chunk as advisory.  In SCTP, any DATA chunk in an outbound
  datagram that is has
been acknowledged by SACK, including DATA that arrived at the head receiving
end out of order, are NOT considered fully delivered until the outbound transmission queue if
  possible.

Note that
Cumulative TSN Ack Point passes the 'Stream Sequence Number' field in an un-ordered data TSN of the DATA chunk (i.e., the
DATA chunk has no significance; been acknowledged by the sender can fill it with arbitrary
value, but Cumulative TSN Ack field in the receiver MUST ignore
SACK). Consequently, the field.

6.7 Report Gaps in Received DATA TSNs

Upon value of cwnd controls the reception amount of a new DATA chunk, an SCTP receiver shall examine
outstanding data, rather than (as in the continuity case of non-SACK TCP) the TSNs received. If
upper bound between the receiver detects that gaps
exist in highest acknowledged sequence number and the received
latest DATA chunk sequence, an SACK with fragment
reports shall that can be sent back immediately.

Based on the segment reports from the SACK, the data sender can
calculate within the missing DATA chunks and make decisions on whether to
retransmit them (see Section 6.3 for details).

Multiple gaps can be reported in one single congestion window. SCTP
SACK (see Section 3.3.3).

Note that when the data sender leads to different implementations of fast-retransmit and fast-
recovery than non-SACK TCP. As an example see [FALL96].

The biggest difference between SCTP and TCP, however, is multi-homed, the multi-homing.
SCTP receiver
SHOULD always try is designed to send the SACK establish robust communication associations
between two endpoints each of which may be reachable by more than one
transport address.  Potentially different addresses may lead to
different data paths between the same network from where the
last DATA chunk was received.

Upon the reception two endpoints, thus ideally one may
need a separate set of congestion control parameters for each of the SACK,
paths.  The treatment here of congestion control for multi-homed
receivers is new with SCTP and may require refinement in the data sender SHALL remove all DATA
chunks which have been acknowledged by
future. The current algorithms make the SACKs cumulative TSN. following assumptions:

o The
data sender MUST also treat all usually uses the DATA chunks which fall into same destination address until being
  instructed by the
gaps between upper layer otherwise; however, SCTP may change to
  an alternate destination in the fragments reported by event an address is marked inactive
  (see Section 8.2).  Also, SCTP may retransmit to a different
  transport address than the SACK as "missing". original transmission.

o The
number of "missing" reports sender keeps a separate congestion control parameter set for each outstanding DATA chunk MUST be
recorded by
  of the data sender in order destination addresses it can send to make retransmission decision,
see Section 7.2.4 (NOT each
  source-destination pair but for details. each destination) . The following example shows parameters
  should decay if the use address is not used for a long enough
  time period.

o For each of SACK the destination addresses, an endpoint does slow-start
  upon the first transmission to report a gap.

Endpoint A                                    Endpoint Z
{App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rxt timer)

Stewart, et al                                               [Page  55]

DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)

DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
                                            immediately send ack)
                                /----- SACK [TSN ACK=6,Frag=1,
                               /             Strt=2,End=2]
                        <-----/
(remove 6 and 8 from out-queue,
 and strike 7 as "1" missing report) that address.

Note: in order  TCP guarantees in-sequence delivery of data to keep its upper-layer
       protocol within a single TCP session.  This means that when TCP
       notices a gap in the size received sequence number, it waits until
       the gap is filled before delivering the data that was received
       with sequence numbers higher than that of the outbound missing data.  On
       the other hand, SCTP datagram not can deliver data to
exceed its upper-layer
       protocol even if there is a gap in TSN if the current path MTU, Stream Sequence
       Numbers are in sequence for a particular stream (i.e., the maximal number of fragments that can
be reported within
       missing DATA chunks are for a single SACK chunk different stream) or if unordered
       delivery is limited. When a single SACK
can indicated.  Although this does not cover all the fragments needed to affect cwnd, it
       might affect rwnd calculation.

7.2 SCTP Slow-Start and Congestion Avoidance

The slow start and congestion avoidance algorithms MUST be reported due to the MTU
limitation, the used by an
endpoint SHALL send only one SACK, reporting the
fragments from the lowest to highest TSNs, within control the size limit set
by amount of data being injected into the MTU, and leave network.
The congestion control in SCTP is employed in regard to the remaining highest TSN fragment numbers
unacknowledged.

6.8 Adler-32 Checksum Calculation

When sending
association, not to an individual stream.  In some situations it
may be beneficial for an SCTP datagram, sender to be more conservative than the
algorithms allow; however, an SCTP sender MUST strengthen NOT be more aggressive
than the data
integrity of following algorithms allow.

Like TCP, an SCTP endpoint uses the following three control variables
to regulate its transmission by including the Adler-32 checksum
value calculated on the datagram, as described below.

After rate.

o Receiver advertised window size (rwnd, in bytes), which is set by
  the datagram receiver based on its available buffer space for incoming
  packets.

  Note: This variable is constructed (containing kept on the SCTP common header
and one or more entire association.

o Congestion control or DATA chunks), the sender shall:

1) fill window (cwnd, in bytes), which is adjusted by
  the proper Verification Tag sender based on observed network conditions.

  Note: This variable is maintained on a per-destination address basis.

o Slow-start threshold (ssthresh, in bytes), which is used by the SCTP common header
  sender to distinguish slow start and
   initialize the Adler-32 checksum filed congestion avoidance phases.

  Note: This variable is maintained on a per-destination address basis.

SCTP also requires one additional control variable,
partial_bytes_acked, which is used during congestion avoidance phase to 0's.

2) calculate the Adler-32 checksum
facilitate cwnd adjustment.

Unlike TCP, an SCTP sender MUST keep a set of the whole datagram, including the these control variables
for EACH destination address of its peer (when its peer is multi-
homed).

7.2.1 Slow-Start

Beginning data transmission into a network with unknown conditions or
after a sufficiently long idle period requires SCTP common header and all to probe the chunks. Refer
network to Sections 2.2 and 9
   in [2] determine the available capacity.  The slow start algorithm
is used for details of this purpose at the Adler-32 algorithm. And,

3) put beginning of a transfer, or after

repairing loss detected by the resultant retransmission timer.

o The initial cwnd before data transmission or after a sufficiently
  long idle period MUST be <= 2*MTU.

o The initial cwnd after a retransmission timeout MUST be no more
  than 1*MTU.

o The initial value into of ssthresh MAY be arbitrarily high (for example,
  implementations MAY use the Adler-32 checksum field in size of the
   common header, and leave receiver advertised window).

o Whenever cwnd is greater than zero, the rest endpoint is allowed to have
  cwnd bytes of the bits unchanged. data outstanding on that transport address.

o When cwnd is less than or equal to ssthresh an SCTP datagram endpoint MUST use
  the slow start algorithm to increase cwnd (assuming the current
  congestion window is received, being fully utilized). If an incoming SACK
  advances the receiver Cumulative TSN Ack Point, cwnd MUST first check be increased by at
  most the
Adler-32 checksum: lesser of 1) store the received Adler-32 checksum value aside, total size of the previously outstanding
  DATA chunk(s) acknowledged, and 2) replace the 32 bits of destination's path MTU.
  This protects against the Adler-32 checksum field ACK-Splitting attack outlined in the received
   SCTP datagram with all '0's and calculate
  [SAVAGE99].

  In instances where its peer endpoint is multi-homed, if an Adler-32 checksum
   value of the whole received datagram. And,

3) verify endpoint
  receives a SACK that advances its Cumulative TSN Ack Point, then it
  should update its cwnd (or cwnds) apportioned to the calculated Adler-32 checksum is destination
  addresses to which it transmitted the same as acknowledged data. However if
  the received Adler-32 checksum, If not, SACK does not advance the receiver Cumulative TSN Ack Point, the
  endpoint MUST treat NOT adjust the
   datagram as an invalid SCTP datagram.

The default procedure cwnd of handling invalid SCTP datagrams any of the destination
  addresses.

  Because an endpoint's cwnd is not tied to
silently discard them.

Stewart, et al                                               [Page  56]

6.9 Segmentation

Segmentation MUST be performed by the data sender if its Cumulative TSN Ack
  Point, as duplicate SACKs come in, even though they may not advance
  the user message Cumulative TSN Ack Point an endpoint can still use them to be sent has a large size that causes clock
  out new data.  That is, the outbound SCTP datagram
size exceeding data newly acknowledged by the current MTU.

Note, if SACK
  diminishes the amount of data receiver is multi-homed, the sender shall choose a
size no larger now in flight to less than cwnd; and so
  the latest MTU current, unchanged value of the current primary destination
address.

When determining when cwnd now allows new data to segment, be sent.
  On the SCTP implementation MUST take
into account other hand, the SCTP datagram header as well increase of cwnd must be tied to the
  Cumulative TSN Ack Point advancement as specified above.  Otherwise
  the DATA chunk
header. The implementation MAY duplicate SACKs will not only clock out new data, but also take account of will
  adversely clock out more new data than what has just left the space required
for
  network, during a SACK chunk.

  IMPLEMENTATION NOTE: if segmentation is time of possible congestion.

o When the endpoint does not support by transmit data on a given transport
  address, the sender,
  an error cwnd of the transport address should be reported adjusted to the sender's SCTP user
  max(cwnd/2, 2*MTU) per RTO.

7.2.2 Congestion Avoidance

When cwnd is greater than ssthresh, cwnd should be incremented
by 1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding transport address.

In practice an implementation can achieve this goal in the
following way:

o partial_bytes_acked is initialized to
  be sent has a size exceeding 0.

o Whenever cwnd is greater than ssthresh, upon each SACK arrival that
  advances the current MTU. In such cases Cumulative TSN Ack Point, increase partial_bytes_acked
  by the Send
  primitive discussed total number of bytes of all new chunks acknowledged in Section 10.1 would need to return an error that
  SACK including chunks acknowledged by the new Cumulative TSN Ack and
  by Gap Ack Blocks.

o When partial_bytes_acked is equal to or greater than cwnd and before
  the upper layer.

Segmentation takes arrival of the following steps:

1) SACK the data sender SHALL break the large user message into a series had cwnd or more bytes of
   DATA chunks, such that each data
  outstanding (i.e., before arrival of the chunks can be fit into an IP
   datagram smaller SACK, flightsize was greater
  than or equal to the current cwnd), increase cwnd by MTU,

2) the data sender MUST then assign, in sequence, a separate TSN and reset
  partial_bytes_acked to
   each of the DATA chunks (partial_bytes_acked - cwnd).

o Same as in the series,

3) slow start, when the data sender MUST also set does not transmit data on
  a given transport address, the B/E bits cwnd of the first DATA chunk
   in the series transport address should
  be adjusted to '10', the B/E bits max(cwnd / 2, 2*MTU) per RTO.

o When all of the last DATA chunk in data transmitted by the
   series to '01', and sender has been acknowledged
  by the B/E bits receiver, partial_bytes_acked is initialized to 0.

7.2.3 Congestion Control

Upon detection of all other DATA chunks in packet losses from SACK  (see Section 7.2.4),
An endpoint should do the
   series following:

  ssthresh = max(cwnd/2, 2*MTU)
  cwnd = ssthresh

Basically, a packet loss causes cwnd to '00'.

The data receiver MUST recognize the segmented DATA chunks, by
examining the B/E bits be cut in each of half.

When the received DATA chunks, T3-rtx timer expires on an address, SCTP should perform
slow start by:

  ssthresh = max(cwnd/2, 2*MTU)
  cwnd = 1*MTU

and queue
the segmented assure that no more than one DATA chunks for re-assembly. Then, it shall pass the
re-assembled user message to the specific stream chunk will be in flight for possible
re-ordering and final dispatching.

Note, if that
address until the data receiver runs out of buffer space while still
waiting endpoint receives acknowledgement for more segments to complete the re-assembly of the message,
it should dispatch part of its inbound message through a partial successful
delivery API (see Section 10), freeing some of its receive buffer space
so data to that address.

7.2.4 Fast Retransmit on Gap Reports

In the rest absence of the message may be received.

Stewart, et al                                               [Page  57]

6.10 Bundling and Multiplexing

An SCTP sender achieves data bundling by simply including multiple
DATA chunks loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in one outbound SCTP datagram. Note that the total size of
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the resultant IP datagram, including hole is filled.

Whenever an endpoint receives a SACK that indicates some TSN(s)

missing, it SHOULD wait for 3 further miss indications (via subsequent
SACK's) on the SCTP datagram and IP headers,
MUST be less or equal same TSN(s) before taking action with regard to Fast
Retransmit.

When the current MTU.

Note, if the data receiver TSN(s) is multi-homed, reported as missing in the fourth consecutive SACK,
the data sender shall choose a
size no larger than shall:

1) Mark the latest MTU missing DATA chunk(s) for retransmission,

2) Adjust the ssthresh and cwnd of the current primary destination
address.

When multiplexing control chunks with address(es) to which
   the missing DATA chunks, control chunks have were last sent, according to the priority and MUST be placed first formula
   described in Section 7.2.3.

3) Determine how many of the outbound SCTP datagram
and be transmitted first. The transmitter MUST transmit earliest (i.e., lowest TSN) DATA
   chunks
within marked for retransmission will fit into a SCTP datagram in increasing order single packet,
   subject to constraint of TSN.

Partial chunks MUST NOT be placed in a SCTP datagram.

The receiver MUST process the path MTU of the destination transport
   address to which the packet is being sent. Call this value K.
   Retransmit those K DATA chunks in order in a single packet.

4) Restart T3-rtx timer only if the datagram.  The
receiver uses last SACK acknowledged the chunk length field lowest
   outstanding TSN number sent to determine that address, or the end of a chunk
and beginning of endpoint is
   retransmitting the next first outstanding DATA chunk taking account of the fact sent to that all
chunks end on a thirty-two-bit word boundary. If
   address.

   Note: Before the receiver detects
a partial chunk, it MUST drop above adjustments, if the chunk.

7. Congestion control

Congestion control is one of received SACK also
   acknowledges new DATA chunks and advances the basic functions in Cumulative TSN Ack
   Point, the SCTP protocol.
For some applications, it may be likely that adequate resources will
be allocated to SCTP traffic to assure prompt delivery of
time-critical SCTP data - thus it would appear to be unlikely, during
normal operations, that SCTP transmissions encounter severe congestion
condition. However SCTP cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
   must prepare itself be applied first.

A straightforward implementation of the above keeps a counter for adverse operational
conditions, which can develop upon partial network failures or
unexpected traffic surges.  In such situations SCTP must follow correct
congestion control steps each
TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole.  After reaching 4 and starting
the fast retransmit procedure, the counter resets to recover from congestion quickly 0.

Because cwnd in order
to get data delivered as soon as possible.  In SCTP indirectly bounds the absence number of network
congestion, these preventive congestion control algorithms should show
no impact on outstanding
TSN's, the protocol performance.

  IMPLEMENTATION NOTE: as far as its specific performance requirements
  are met, an implementation effect of TCP fast-recovery is always allowed achieved automatically with
no adjustment to adopt a more
  conservative congestion control algorithm than the one defined
  below.

The congestion control algorithms used by SCTP are based on RFC 2581
[3], "TCP Congestion Control".  This section describes how window size.

7.3 Path MTU Discovery

[RFC1191] specifies "Path MTU Discovery", whereby an endpoint
maintains an estimate of the
algorithms defined in RFC 2581 are adopted maximum transmission unit (MTU) along a
given Internet path and refrains from sending packets along that path
which exceed the MTU, other than occasional attempts to probe for use a
change in SCTP.  We first
list differences the Path MTU (PMTU).  RFC 1191 is thorough in protocol designs between TCP and SCTP, its discussion
of the MTU discovery mechanism and then
describe SCTP's congestion control scheme.  The description will use strategies for determining the
current end-to-end MTU setting as well as detecting changes in this
value.  [RFC1981] specifies the same terminology as in TCP congestion control whenever
appropriate.

Note: mechanisms for IPv6. An SCTP congestion control is always applied to
sender using IPv6 MUST use Path MTU Discovery unless all packets are
less than the entire association, minimum IPv6 MTU [RFC2460].

An endpoint SHOULD apply these techniques, and NOT to individual streams.

Stewart, et al                                               [Page  58]

7.1 SHOULD do so on a
per-destination-address basis.

There are 4 ways in which SCTP Differences differs from TCP Congestion control

One difference between SCTP and TCP is that the Selective
Acknowledgment function (SACK) is designed into SCTP, rather than an
enhancement that is added description in RFC 1191
of applying MTU discovery to TCP:

1)  SCTP associations can span multiple addresses.
    An endpoint MUST maintain separate MTU estimates for each
    destination address of its peer.

2)  Elsewhere in this document, when the protocol later as term "MTU" is discussed,
    it refers to the case for
TCP. SCTP SACK carries the same semantic meaning MTU associated with that of TCP
SACK. TCP and SCTP considers the information carried in the SACK as
advisory information only. In SCTP, any DATA chunk that has been
acknowledged by SACK, including DATA that arrived at destination address
    corresponding to the receiving end
out context of order, are NOT considered fully delivered until the Cumulative
Acknowledgment point passes the acknowledged DATA chunk. Consequently, discussion.

3)  Unlike TCP, SCTP does not have a notion of "Maximum Segment
    Size".  Accordingly, the MTU for each destination address
    SHOULD be initialized to a value of cwnd controls no larger than the amount link MTU
    for the local interface to which packets for that remote
    destination address will be routed.

4)  Since data transmission in SCTP is naturally structured in
    terms of outstanding data, TSNs rather than
the upper bound between the highest acknowledged sequence number and
the latest DATA chunk that can be sent within the congestion window,
as bytes (as is the case for TCP), the
    discussion in non-SACK TCP. SCTP SACK leads to different
implementations of fast-retransmit and fast-recovery from that Section 6.5 of
non-SACK TCP. As RFC 1191 applies: When retransmitting
    an example see [16].

The biggest difference between SCTP and TCP, however, is multi-homing.
SCTP is designed to establish robust communication associations
between two end points each of which may be reachable by more than one
transport address.  Potentially different addresses may lead IP datagram to
distinguished data paths between the two points, thus ideally one may
need a separate set of congestion control parameters remote address for each of which the
paths.  The treatment here of congestion control IP datagram
    appears too large for multi-homed
receivers is new with SCTP and may require refinement in the
future. The current algorithms make path MTU to that address, the following assumptions:

o IP datagram
    SHOULD be retransmitted without the DF bit set, allowing it to
    possibly be fragmented. Transmissions of new IP datagrams MUST have
    DF set.

5)  The sender always uses should track an association PMTU which will be
    the same smallest PMTU discovered for all of the peer's destination address until being
  instructed by
    addresses. When fragmenting messages into multiple parts this
    association PMTU should be used to calculate the upper layer otherwise.

o The sender keeps a separate congestion control parameter set for size of
    each fragment. This will allow retransmissions to be seamlessly
    sent to an alternate address without encountering IP fragmentation.

Other than these differences, the discussion of TCP's use of the destination addresses it can send MTU
discovery in RFCs 1191 and 1981 applies to (NOT each
  source-destination pair but for each destination) . The parameters
  should decay if the address is not used for SCTP on a long enough
  time period.

o
per-destination-address basis.

  Note: For each of the IPv6 destination addresses, do slow-start upon addresses the first
  transmission to that address.

7.2 SCTP Slow-Start and Congestion Avoidance

The slow start and congestion avoidance algorithms MUST DF bit does not exist,
  instead the IP datagram must be used by fragmented as described in [RFC2460].

8.  Fault Management

8.1 Endpoint Failure Detection

An endpoint shall keep a
SCTP sender counter on the total number of consecutive
retransmissions to control its peer (including retransmissions to all the amount
destination transport addresses of outstanding data being injected
into the network.  The congestion control in SCTP peer if it is employed multi-homed).  If
the value of this counter exceeds the limit indicated in regard
to the association, not protocol
parameter 'Association.Max.Retrans', the endpoint shall consider the
peer endpoint unreachable and shall stop transmitting any more data to an individual stream.  In some situations
it
may be beneficial for an SCTP sender to be more conservative than (and thus the
algorithms allow, however an SCTP sender MUST NOT be more aggressive
than association enters the following algorithms allow.

Like TCP, an SCTP sender uses CLOSED state). In addition, the following three control variables
to regulate its transmission rate.

Stewart, et al                                               [Page  59]

o Receiver advertised window size (rwnd, in octets), which is set by
endpoint shall report the receiver based on its available buffer space for incoming packets.

  Note: This variable is kept on failure to the entire association.

o Congestion control window (cwnd, upper layer, and optionally
report back all outstanding user data remaining in octets), which its outbound queue.
The association is adjusted by automatically closed when the sender based on observed network conditions.

  Note: This variable peer endpoint

becomes unreachable.

The counter shall be reset each time a DATA chunk sent to that peer
endpoint is maintained on acknowledged (by the reception of a per-destination basis.

o Slow-start threshold (ssthresh, in octets), which SACK), or a HEARTBEAT-
ACK is used by received from the
  sender to distinguish slow start and congestion avoidance phases.

  Note: This variable peer endpoint.

8.2 Path Failure Detection

When its peer endpoint is maintained multi-homed, an endpoint should keep a error
counter for each of the destination transport addresses of the peer
endpoint.

Each time the T3-rtx timer expires on any address, or when a per-destination basis.

SCTP also requires one additional control variable, partial_bytes_acked,
which is used during congestion avoidance phase HEARTBEAT
sent to facilitate cwnd
adjustment.

Unlike TCP, an SCTP sender MUST keep idle address is not acknowledged within a set RTO, the error
counter of these control variables
for EACH that destination address will be incremented.  When the
value in the error counter exceeds the protocol parameter
'Path.Max.Retrans' of its peer (when its peer that destination address, the endpoint should
mark the destination transport address as inactive, and a notification
SHOULD be sent to the upper layer.

When an outstanding TSN is multi-homed).

7.2.1 Slow-Start

Beginning data transmission into acknowledged or a network HEARTBEAT sent to that
address is acknowledged with unknown conditions
requires SCTP a HEARTBEAT ACK, the endpoint shall
clear the error counter of the destination transport address
to probe which the network to determine DATA chunk was last sent (or HEARTBEAT was sent). When the available capacity.
The slow start algorithm
peer endpoint is used for this purpose at multi-homed and the beginning of last chunk sent to it was a
transfer, or after repairing loss detected by the
retransmission timer.

o The initial cwnd before data transmission to an alternate address, there exists an ambiguity as to
whether or after a sufficiently
  long idle period MUST be <= 2*MTU.

o The initial cwnd after a retransmission timeout MUST be no more
  than 1*MTU.

o The initial value of ssthresh MAY not the acknowledgement should be arbitrarily high (for example,
  some implementations use credited to the size address of
the receiver advertised window).

o Whenever cwnd is greater than zero, the sender is allowed last chunk sent. However, this ambiguity does not seem to have cwnd
  octets of data outstanding on that transport address.

o When cwnd is less than or equal bear any
significant consequence to ssthresh an SCTP sender MUST use behavior. If this ambiguity is
undesirable, the slow start algorithm transmitter may choose not to increase cwnd (assuming clear the current
  congestion window is being fully utilized). If
error counter if the incoming SACK
  advances last chunk sent was a retransmission.

  Note: When configuring the cumulative TSN, cwnd MUST be increased by at most SCTP endpoint, the
  lesser user should avoid
  having the value of 1) 'Association.Max.Retrans' larger than the total size
  summation of the 'Path.Max.Retrans' of all the destination addresses
  for the remote endpoint. Otherwise, all the destination addresses may
  become inactive while the endpoint still considers the peer endpoint
  reachable. When this condition occurs, how the previously outstanding DATA
  chunk(s) acknowledged, and 2) SCTP chooses to
  function is implementation specific.

When the destinations primary path MTU.
  This prevents against is marked inactive (due to excessive
retransmissions, for instance), the ACK-Splitting attack outlined in [15].

  NOTE: In instances where sender MAY automatically transmit
new packets to an alternate destination address if one exists and is
active. If more than one alternate address is active when the data receiver endpoint primary
path is multi-homed,
  if a SACK arrives at marked inactive only ONE transport address SHOULD be chosen
and used as the data sender that advances new destination transport address.

8.3 Path Heartbeat

By default, an SCTP endpoint shall monitor the
  sender's cumulative TSN point, then reachability of the data sender should update
idle destination transport address(es) of its cwnd (or cwnds) apportioned peer by sending a
HEARTBEAT chunk periodically to the destination addresses where
  the data was transmitted to. However transport

address(es).

A destination transport address is considered "idle" if no new chunk
which can be used for updating path RTT (usually including first
transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no
HEARTBEAT has been sent to it within the SACK does not advance
  the cumulative TSN point, current heartbeat period of
that address. This applies to both active and inactive destination
addresses.

The upper layer can optionally initiate the data sender MUST not adjust following functions:

A) Disable heartbeat on a specific destination transport address of a
   given association,
B) Change the cwnd HB.interval,
C) Re-enable heartbeat on a specific destination transport address of any
   a given association, and,
D) Request an on-demand HEARTBEAT on a specific destination transport
   address of a given association.

The endpoint should increment the respective error counter
of the destination addresses.

Stewart, et al                                               [Page  60]
  NOTE: because an SCTP data sender's cwnd transport address each time a HEARTBEAT is not tied sent to its
  cumulative TSN point, as duplicate SACKs come in, even though they
  may
that address and not advance the cumulative TSN point an SCTP sender can still
  use them to clock out new data.  That is, the data newly acknowledged by the SACK diminishes the amount of data now in
  flight to less than cwnd; and so within one RTO.

When the current, unchanged value of
  cwnd now allows new data to be sent.  On this counter reaches the other hand, protocol parameter
'Path.Max.Retrans', the
  increase of cwnd must be tied to endpoint should mark the cumulative TSN advancement corresponding
destination address as
  specified above.  Otherwise the duplicate SACKs will inactive if it is not only clock
  out new data, but so marked, and may also will adversely clock out *more* new data
  than what has just left
optionally report to the network, during a time upper layer the change of possible
  congestion.

o When reachability of
this destination address. After this, the sender does not transmit data endpoint should continue
HEARTBEAT on a given transport address, this destination address but should stop increasing the cwnd
counter.

The sender of the transport address should be adjusted to
  max(cwnd / 2, 2*MTU) per RTO.

7.2.2 Congestion Avoidance

When cwnd is greater than ssthresh, cwnd HEARTBEAT chunk should be incremented
by 1*MTU per RTT if include in the sender has cwnd or more octets Heartbeat
Information field of data
outstanding on the corresponding transport address.

In practice an chunk the current time when the packet is
sent out and the destination address to which the packet is sent.

   IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
   mechanism that can achieve this goal in be used is to increment the
following way:

o partial_bytes_acked error counter
   variable every time a HEARTBEAT is initialized sent to 0.

o a destination. Whenever cwnd is greater than ssthresh, upon each SACK arrival,
  increase partial_bytes_acked by
   a HEARTBEAT ACK arrives, the total number of octets sender SHOULD clear the
   error counter of all
  new chunks acknowledged in the destination that SACK.

o When partial_bytes_acked is equal or greater than cwnd and before the arrival HEARTBEAT was
   sent to. This in effect would clear the previously stroked
   error (and any other error counts as well).

The receiver of the SACK HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the sender has cwnd or more octets Heartbeat Information field copied
from the received HEARTBEAT chunk.

Upon the receipt of data
  outstanding, increase cwnd by MTU, and reset partial_bytes_acked to
  (partial_bytes_acked - cwnd).

o Same as in the slow start, when HEARTBEAT ACK, the sender does not transmit data on
  a given transport address, of the cwnd HEARTBEAT
should clear the error counter of the destination transport
address should
  be adjusted to max(cwnd / 2, 2*MTU) per RTO.

o When all of which the data transmitted by HEARTBEAT was sent, and mark the sender has been acknowledged
  by destination
transport address as active if it is not so marked. The endpoint may
optionally report to the receiver, partial_bytes_acked upper layer when an inactive destination
address is initialized marked as active due to 0.

7.2.3 Congestion Control

Upon detection the reception of packet losses from SACK reports (see the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also

clear the association overall error count as well (as defined
in section 7.2.4), 8.1).

The receiver of the sender HEARTBEAT ACK should do also perform an RTT
measurement for that destination transport address using the following:

  ssthresh = max(cwnd/2, 2*MTU)
  cwnd = ssthresh

Stewart, et al                                               [Page  61]

Basically, a packet loss causes cwnd to be cut time
value carried in half.

When the T3-rxt timer expires on HEARTBEAT ACK chunk.

On an address, SCTP should perform
slow start by:

  ssthresh = max(cwnd/2, 2*MTU)
  cwnd = 1*MTU

and assure idle destination address that no more than one data packet will is allowed to heartbeat,a HEARTBEAT
chunk is RECOMMENDED to be in flight on sent once per RTO of that destination
address until plus the sender receives acknowledgment for successful delivery protocol parameter 'HB.interval' , with
jittering of data +/- 50%, and exponential back-off of the RTO if the
previous HEARTBEAT is unanswered.

A primitive is provided for the SCTP user to that address.

7.2.4 Fast Retransmit change the HB.interval
and turn on Gap Reports

In or off the absence of data losses, heartbeat on a given destination address. The
heartbeat interval set by the SCTP receiver performs delayed
acknowledgment. However, whenever a receiver notices a hole in user is added to the
arriving TSN sequence, it RTO of that
destination (including any exponential backoff). Only one heartbeat
should start sending a SACK back every be sent each time
a packet arrives carrying data.

At the sender end, whenever the sender receives heartbeat timer expires (if multiple
destinations are idle). It is a SACK that indicate
some TSN(s) missing, it SHOULD wait for 3 further miss indications
(via subsequent SACKs) implementation decision on how to
choose which of the same TSN(s) before taking action. candidate idle destinations to heartbeat to (if
more than one destination is idle).

Note: When tuning the TSN(s) heartbeat interval, there is reported a side effect that
SHOULD be taken into account. When this value is increased, i.e.  the
HEARTBEAT takes longer, the detection of lost ABORT messages takes
longer as missing in consecutive SACKs well. If a peer endpoint ABORTs the association for
any reason and the
4th time, ABORT chunk is lost, the sender shall:

1) Mark local endpoint will only
discover the missing lost ABORT by sending a DATA chunk(s) for retransmission,

2) Adjust chunk or HEARTBEAT chunk
(thus causing the ssthresh and cwnd of peer to send another ABORT). This must be considered
when tuning the destination address(es) where HEARBEAT timer. If the missing data chunks were last sent, according HEARTBEAT is disabled only
sending DATA to the formula
   described in Section 7.2.3.

3) Determine how many of the earliest (i.e., lowest TSN) missing Data
   chunks association will fit into discover a single packet, subject to constraint of lost ABORT from the
   path MTU
peer.

8.4 Handle "Out of the destination transport address to which blue" Packets

An SCTP packet is called an "out of the blue" (OOTB) packet if it
is being sent. Call this value K. Retransmit those K data chunks in
   a single packet.

4) Restart T3-rxt timer ONLY IF correctly formed, i.e., passed the last SACK acknowledged receiver's Adler-32 check (see
Section 6.8), but the lowest
   outstanding TSN number sent receiver is not able to that address, or we are retransmitting identify the first outstanding Data chunk sent association
to that address.

   Note, before which this packet belongs.

The receiver of an OOTB packet MUST do the above adjustments, if following:

1) If the received SACK also
   acknowledges new data chunks and advances OOTB packet is to or from a non-unicast address, silently
   discard the packet. Otherwise,

2) If the cumulative TSN point, OOTB packet contains an ABORT chunk, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must
   be applied first.

A straightforward implementation of receiver MUST
   silently discard the above requires that OOTB packet and take no further action.
   Otherwise,

3) If the sender
keeps a counter for each TSN hole first reported by packet contains an INIT chunk with a SACK; Verification Tag set to
   '0', process it as described in Section 5.1. Otherwise,

4) If the
counter keeps track of whether 3 subsequent SACKs have reported packet contains a COOKIE ECHO in the
same hole.

Stewart, et al                                               [Page  62]

Because cwnd first chunk, process it
   as described in SCTP indirectly bounds Section 5.1. Otherwise,

5) If the number of outstanding
TSN's, packet contains a SHUTDOWN ACK chunk, the effect of TCP fast-recovery is achieved automatically with
no adjustment receiver should
   respond to the congestion control window size.

7.3 Path MTU Discovery

RFC 1191 [11] discusses "Path MTU Discovery", whereby a sender
maintains an estimate of the maximum transmission unit (MTU) along OOTB packet with a
given Internet path and refrains from SHUTDOWN COMPLETE.
   When sending datagrams along that
path which exceed the MTU, other than occasional attempts to probe for
a change in SHUTDOWN COMPLETE, the path MTU.  RFC 1191 is thorough in its discussion receiver of the MTU discovery mechanism and strategies for determining the current
end-to-end MTU setting as well as detecting changes OOTB packet
   must fill in this value.
RFC 1981 [12] discusses applying the same mechanisms for IPv6.

An SCTP sender SHOULD apply these techniques, and SHOULD do so on a
per-destination-address basis.

There are 4 ways in which SCTP differs from Verification Tag field of the description outbound packet with
   the Verification Tag received in RFC 1191
of applying MTU discovery to TCP:

1)  SCTP associations can span multiple the SHUTDOWN ACK and set of addresses.
    Per the above comment, an SCTP sender MUST maintain separate
    MTU estimates for each destination address of its peer.

2)  Elsewhere
   T-bit in this document, when the term "MTU" is discussed,
    it refers Chunk Flags to indicate that no TCB was found.
   Otherwise,

6) If the MTU associated with packet contains a SHUTDOWN COMPLETE chunk, the destination address
    corresponding receiver
   should silently discard the packet and take no further action.
   Otherwise,

7) The receiver should respond to the context sender of the discussion.

3)  Unlike TCP, SCTP does not have a notion OOTB packet with
   an ABORT. When sending the ABORT, the receiver of "Maximum Segment
    Size".  Accordingly, the MTU for each destination address
    SHOULD be initialized to a OOTB packet
   MUST fill in the Verification Tag field of the outbound packet
   with the value no larger than found in the link MTU
    for Verification Tag field of the local interface OOTB
   packet and set the T-bit in the Chunk Flags to which datagrams for indicate that remote
    destination address will be routed.

4)  Since data transmission in SCTP is naturally structured in
    terms no
   TCB was found. After sending this ABORT, the receiver of TSNs rather than bytes (as is the case for TCP),
   OOTB packet shall discard the
    discussion OOTB packet and take no further
   action.

8.5 Verification Tag

The Verification Tag rules defined in this section 6.5 of RFC 1191 applies: apply when retransmitting
    a datagram to a remote address for sending
or receiving SCTP packets which the datagram appears
    too large do not contain an INIT, SHUTDOWN
COMPLETE, COOKIE ECHO (see Section 5.1) or ABORT chunk. The rules for the path MTU to that address, the datagram SHOULD
    be retransmitted without the DF bit set, allowing it to possibly
    be fragmented. Transmissions
sending and receiving SCTP packets containing one of new datagrams MUST have DF set.

Other than these differences, chunk types
are discussed separately in Section 8.5.1.

When sending an SCTP packet, the discussion of TCP's use of MTU
discovery endpoint MUST fill in RFCs 1191 and 1981 applies to SCTP, too, on a
per-destination-address basis.

Note: For IPv6 destination addresses the DF bit does not exist,
instead Verification
Tag field of the datagram must be fragmented as described outbound packet with the tag value in RFC1883 [17].

Stewart, et al                                               [Page  63]

8.  Fault Management

8.1 Endpoint Failure Detection

The data sender shall keep a counter on the total number Initiate Tag
parameter of
consecutive retransmissions to the INIT or INIT ACK received from its peer (including retransmissions to
ALL peer.

When receiving an SCTP packet, the destination transport addresses endpoint MUST ensure that the
value in the Verification Tag field of the peer if it is
multi-homed). received SCTP packet
matches its own Tag. If the received Verification Tag value of this counter exceeds the limit
indicated in does not
match the protocol parameter 'Association.Max.Retrans', receiver's own tag value, the
data sender receiver shall consider silently
discard the peer endpoint unreachable packet and shall
stop transmitting any more data to not process it (and thus the association enters
the CLOSED state). In addition, the data sender shall report the
failure to the upper layer, and optionally report back all outstanding
user data remaining any further except for
those cases listed in its outbound queue. Section 8.5.1 below.

8.5.1 Exceptions in Verification Tag Rules

A) Rules for packet carrying INIT:

 - The association is
automatically terminated when sender MUST set the peer Verification Tag of the packet to 0.

 - When an endpoint becomes unreachable.

The counter shall be reset each time a datagram sent receives an SCTP packet with the Verification Tag
   set to 0, it should verify that
destination address is acknowledged by the peer endpoint, or
a HEARTBEAT-ACK is received from packet contains only an INIT
   chunk. Otherwise, the peer endpoint.

8.2 Path Failure Detection

When receiver MUST silently discard the remote packet.

B) Rules for packet carrying ABORT:

 - The endpoint is multi-homed, shall always fill in the data sender should keep a
'retrans.count' counter for each Verification Tag field of the destination transport
addresses of
   outbound packet with the remote endpoint.

Each time destination endpoint's tag value if it
   is known.

 - If the T3-rxt timer on any address, or when a HEARTBEAT ABORT is sent in response to an idle address is not acknowledged, OOTB packet, the 'retrans.count' counter of
that destination address will be incremented.  When endpoint
   MUST follow the value procedure described in
'retrans.count' exceeds Section 8.4.

 - The receiver MUST accept the protocol parameter 'Path.Max.Retrans' packet if the Verification Tag
   matches either its own tag, OR the tag of
that destination address, its peer. Otherwise, the data sender should mark
   receiver MUST silently discard the destination
transport address as inactive, packet and a notification SHOULD be sent to
the upper layer. take no further
   action.

C) Rules for packet carrying SHUTDOWN COMPLETE:

 - When an outstanding TSN is acknowledged or sending a HEARTBEAT sent to that
address is acknowledged with SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN
   ACK has a HEARTBEAT-ACK, TCB then the destination endpoint's tag MUST be used. Only
   where no TCB exists should the data sender shall
clear use the 'retrans.count' counter Verification Tag from
   the SHUTDOWN ACK.

 - The receiver of a SHUTDOWN COMPLETE shall accept the destination transport address
to which packet if the datagram was last sent (or HEARTBEAT was sent). Note,
when
   Verification Tag field of the data receiver packet matches its own tag OR it is multi-homed
   set to its peer's tag and the last sent was a
retransmission to an alternate address of T bit is set in the receiver, there exists
an ambiguity as to whether or not Chunk Flags.
   Otherwise, the acknowledgment should be
credited to receiver MUST silently discard the address of packet and take
   no further action. An endpoint MUST ignore the last sent. However, this ambiguity does
not seem to bear any significant consequence to SCTP behavior. If this
ambiguity SHUTDOWN COMPLETE if
   it is undesirable, the data sender may choose not to clear the
'retrans.count' counter if in the last sent was SHUTDOWN-ACK-SENT state.

D) Rules for packet carrying a retransmission.

Stewart, et al                                               [Page  64]

Note, when configuring the SCTP endpoint, COOKIE ECHO

- When sending a COOKIE ECHO, the user should avoid
having endpoint MUST use the value of 'Association.Max.Retrans' larger than the
summation of
  Initial Tag received in the 'Path.Max.Retrans' INIT ACK.

- The receiver of all the destination addresses
for the remote endpoint. Otherwise, all the destination addresses may
become inactive while the endpoint still considers a COOKIE ECHO follows the peer procedures in Section 5.

9. Termination of Association

An endpoint
reachable. When this condition occurs, how the SCTP chooses to function
is implementation specific.

Note, should terminate its association when it exits from
service. An association can be terminated by either abort or
shutdown. A abort of an association is abortive by definition in that
any data pending on either end of the primary destination address association is marked inactive (due discarded and NOT
delivered to
excessive retransmissions, for instance), the sender MAY automatically
transmit new datagrams to peer. A shutdown of an alternate destination address if one
exists and association is active. This is, however, an implementation option.

8.3 Path Heartbeat

By default, an SCTP considered a
graceful close where all data in queue by either endpoint shall monitor is delivered
to the reachability of respective peers. However, in the
idle destination transport address(es) case of its peer by a shutdown, SCTP does
not support a half-open state (like TCP) wherein one side may continue
sending
HEARTBEAT messages periodically to data while the destination transport
address(es).

A destination transport address other end is considered "idle" if no closed. When either endpoint
performs a shutdown, the association on each peer will stop accepting
new chunk
which can be used for updating path RTT (usually including first
transmission DATA, INIT, COOKIE, etc.) data from its user and no heartbeat has been sent
to it within only deliver data in queue at the current heartbeat period time of that address. This
applies to both active and inactive destination addresses.

The upper layer can optionally initiate
sending or receiving the following functions:

A) disable heart beat on a specific destination transport address of a
   given association,
B) re-enable heart beat on a specific destination transport address SHUTDOWN chunk.

9.1 Abort of
   a given an Association

When an endpoint decides to abort down an existing association, and,
C) request it
shall send an on-demand heartbeat on a specific destination transport
   address of a given association. ABORT chunk to its peer endpoint. The endpoint should increment sender MUST fill
in the respective 'retrans.count' counter
of peer's Verification Tag in the destination transport address each time a HEARTBEAT is sent outbound packet and MUST NOT

bundle any DATA chunk with the ABORT.

An endpoint MUST NOT respond to any received packet that address and not acknowledged.

When contains an
ABORT chunk (also see Section 8.4).

An endpoint receiving an ABORT shall apply the value of this counter reaches special Verification Tag
check rules described in Section 8.5.1.

After checking the protocol parameter
'Path.Max.Retrans', Verification Tag, the receiving endpoint should mark shall
remove the corresponding
destination address as inactive if it is not so marked, association from its record, and may also
optionally shall report the
termination to its upper layer.

9.2 Shutdown of an Association

Using the SHUTDOWN primitive (see Section 10.1), the upper layer the change of reachability of
this destination address. After this, the an
endpoint should continue
heartbeat on this destination address but should stop increasing in an association can gracefully close the
counter.

The sender association.
This will allow all outstanding DATA chunks from the peer of
the HEARTBEAT message should include in shutdown initiator to be delivered before the Heartbeat
Information field association
terminates.

Upon receipt of the message the current time when SHUTDOWN primitive from its upper layer, the message is
sent out
endpoint enters SHUTDOWN-PENDING state and the information on the destination address remains there until all
outstanding TSNs have been acknowledged by its peer. The endpoint
accepts no new data from its upper layer, but retransmits data to which the
message is sent.

   IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
   mechanism that can be used is
far end if necessary to increment fill gaps.

Once all its outstanding TSNs have been acknowledged, the 'retrans.count'
   variable every time endpoint
shall send a HEARTBEAT is sent SHUTDOWN chunk to a destination. Whenever
   a HEARTBEAT-ACK arrives, the sender SHOULD be clearing the
   'retrans.count' of the destination that the HEARTBEAT was
   sent to. This its peer including in effect would clear the previously stroked
   error (and any other error counts as well).

Stewart, et al                                               [Page  65]

The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information Cumulative
TSN Ack field copied out
from the last sequential TSN it has received HEARTBEAT message.

Upon the receipt of the HEARTBEAT ACK, the sender of from the HEARTBEAT
should clear peer.
It shall then start the 'retrans.count' counter of T2-shutdown timer and enter the destination transport
address to which SHUTDOWN-SENT
state. If the HEARTBEAT was sent, and mark timer expires, the destination
transport address as active if it is not so marked. The endpoint may
optionally report to the upper layer when an inactive destination
address is marked as active due to must re-send the reception of SHUTDOWN
with the latest
HEARTBEAT ACK. updated last sequential TSN received from its peer.

The receiver of the HEARTBEAT ACK should also perform an RTT
measurement for that destination transport address using rules in Section 6.3 MUST be followed to determine the time proper timer
value carried for T2-shutdown. To indicate any gaps in TSN, the HEARTBEAT ACK message.

On an idle destination address that is allowed to heartbeat, HEARTBEAT
messages is RECOMMENDED to be sent once per RTO of that destination
address, endpoint may
also bundle a SACK with jittering of +/- 50%, and exponential back-off if the
previous HEARTBEAT is unanswered.

A primitive is provided for SHUTDOWN chunk in the same SCTP user packet.

An endpoint should limit the number of retransmissions of the SHUTDOWN
chunk to change the heart
beat interval protocol parameter 'Association.Max.Retrans'. If this
threshold is exceeded the endpoint should destroy the TCB and turn on or off MUST
report the heart beat on a given destination
address. Note, peer endpoint unreachable to the heartbeat interval set by upper layer (and thus the SCTP user on
association enters the CLOSED state). The reception of any packet from
its peer (i.e. as the peer sends all of its queued DATA chunks) should
clear the idle destination addresses SHOULD be no smaller than endpoint's retransmission count and restart the RTO T2-Shutdown
timer,  giving its peer ample opportunity to transmit all of its queued
DATA chunks that destination address. Separate timers may be used to control have not yet been sent.

Upon the
heartbeat transmission for different idle destination addresses.

8.4 Handle "Out reception of the blue" Packets

An SHUTDOWN, the peer endpoint shall
  - enter the SHUTDOWN-RECEIVED state,

  - stop accepting new data from its SCTP datagram is called an "out user

  - verify, by checking the Cumulative TSN Ack field of the blue" (OOTB) datagram if it
is correctly formed, i.e., passed chunk, that
    all its outstanding DATA chunks have been received by the receiver's Adler-32 check (see
Section 6.8), but SHUTDOWN
    sender.

Once a endpoint as reached the receiver is not able SHUTDOWN-RECEIVED state it MUST NOT
send a SHUTDOWN in response to identify a ULP request.

If there are still outstanding DATA chunks left, the association
to which this datagram belongs.

The SHUTDOWN receiver of an OOTB datagram MUST do the following:

1) check if the OOTB datagram contains an ABORT chunk. If so,
shall continue to follow normal data transmission procedures defined in
Section 6 until all outstanding DATA chunks are acknowledged; however,
the SHUTDOWN receiver MUST silently discarded NOT accept new data from its SCTP user.

While in SHUTDOWN-SENT state, the OOTB datagram SHUTDOWN sender shall immediately
respond to each received DATA chunk with a SACK and take restart the
T2-shutdown timer.

If it has no
   further action. Otherwise,

2) more outstanding DATA chunks, the SHUTDOWN receiver should respond shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering
the SHUTDOWN-ACK-SENT state.

The sender of the OOTB datagram with an
   ABORT. When sending the ABORT, SHUTDOWN ACK should limit the receiver number of
retransmissions of the OOTB datagram
   MUST fill in SHUTDOWN ACK chunk to the Verification Tag field of protocol parameter
'Association.Max.Retrans'. If this threshold is exceeded the outbound datagram
   with endpoint
should destroy the value found in TCB and may report the Verification Tag field of peer endpoint unreachable to
the OOTB
   datagram. After sending this ABORT, upper layer (and thus the receiver association enters the CLOSED state).

Upon the receipt of the OOTB
   datagram SHUTDOWN ACK, the SHUTDOWN sender shall discard stop
the OOTB datagram and take no further
   action.

Stewart, et al                                               [Page  66]

8.5 Verification Tag

The Verification Tag rules defined in this section apply when sending
or receiving SCTP datagrams which do NOT contain an INIT, T2-shutdown timer, send a SHUTDOWN
ACK, or ABORT chunk. The rules for sending COMPLETE chunk to its
peer, and receiving SCTP
datagrams containing one remove all record of these chunk types are discussed separately the association.

An endpoint SHOULD assure that all its outstanding DATA chunks have
been acknowledged before initiating the shutdown procedure.

An endpoint should reject any new data request from its upper
layer if it is in Section 8.5.1.

When sending SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or
SHUTDOWN-ACK-SENT state.

If an SCTP datagram, the sender MUST fill in the
Verification Tag field of the outbound datagram with the tag value of
the peer endpoint to which this SCTP datagram is destined.

When receiving in SHUTDOWN-ACK-SENT state and receives an SCTP datagram, the receiver MUST ensure that INIT chunk
(e.g., if the
value SHUTDOWN COMPLETE was lost) with source and destination
transport addresses (either in the Verification Tag field of the received SCTP datagram
matches its own Tag. If the received tag value does not match the
receiver's own tag value, IP addresses or in the receiver shall silently INIT chunk)
that belong to this association, it should discard the
datagram INIT chunk and shall not process it any further.

8.5.1 Exceptions in Verification Tag Rules

A) Rules for datagram carrying INIT:

 - The sender MUST set
retransmit the Verification Tag SHUTDOWN ACK chunk.
  Note:  Receipt of the datagram to 0.
 - The receiver, when noticing an incoming SCTP datagram INIT with the
   Verification Tag set to 0, should continue same source and destination IP
  addresses as used in transport addresses assigned to process the datagram
   only if an INIT chunk is present. Otherwise, the receiver MUST
   silently discard endpoint but
  with a different port number indicates the datagram and take no further action.

B) Rules for datagram carrying ABORT:

 - initialization of a
  separate association.

The sender shall always fill of the INIT should respond to the receipt of a SHUTDOWN-ACK
with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the
Verification Tag field of its common header set to the
   outbound datagram with the destination endpoint's same tag value if it
   is known.
 - If that
was received in the ABORT SHUTDOWN ACK packet. This is sent in response to considered an OOTB datagram, the sender
   MUST follow Out of
the procedure described Blue packet as defined in Section 8.4.
 -  The receiver MUST accept sender of the datagram IF INIT lets
T1-init continue running and remains in the Verification Tag
   matches either its own tag, OR COOKIE-WAIT state. Normal
T1-init timer expiration will cause the tag of INIT chunk to be retransmitted
and thus start a new association.

If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN chunk
from its peer. Otherwise, peer, the
   receiver MUST silently discard endpoint shall respond immediately with a SHUTDOWN
ACK to its peer, and move into a SHUTDOWN-ACK-SENT state restarting its
T2-shutdown timer.

If an endpoint is in the datagram SHUTDOWN-ACK-SENT state and take no further
   action.

C) Rules for datagram carrying SHUTDOWN ACK:

 - When sending receives a
SHUTDOWN ACK, it shall stop the sender is allowed T2-shutdown timer, send a
SHUTDOWN COMPLETE chunk to either use its peer, and remove all record of the destination endpoint's tag or
association.

10. Interface with Upper Layer

The Upper Layer Protocols (ULP) shall request for services by passing
primitives to SCTP and shall receive notifications from SCTP for
various events.

The primitives and notifications described in this section should be
used as a guideline for implementing SCTP. The following functional
description of ULP interface primitives is shown for illustrative
purposes. Different SCTP implementations may have different ULP
interfaces. However, all SCTPs must provide a certain minimum set the Verification Tag field of
services to guarantee that all SCTP implementations can support the outbound datagram
same protocol hierarchy.

10.1 ULP-to-SCTP

The following sections functionally characterize a ULP/SCTP interface.
The notation used is similar to 0.
 - most procedure or function calls in
high level languages.

The receiver of a SHUTDOWN ACK shall accept ULP primitives described below specify the datagram IF basic functions the
   Verification Tag field
SCTP must perform to support inter-process communication. Individual
implementations must define their own exact format, and may provide
combinations or subsets of the datagram matches basic functions in single calls.

A) Initialize

Format: INITIALIZE ([local port], [local eligible address list])
-> local SCTP instance name

This primitive allows SCTP to initialize its own tag OR internal data structures
and allocate necessary resources for setting up its operation
environment. Once SCTP is
   set initialized, ULP can communicate
directly with other endpoints without re-invoking this primitive.

SCTP will return a local SCTP instance name to 0. Otherwise, the receiver MUST silently discard the
   datagram and take no further action. NOTE: the receiver ULP.

Mandatory attributes:

None.

Optional attributes:

The following types of attributes may be passed along with the
   SHUTDOWN ACK MUST ignore the chunk
primitive:

 o local port - SCTP port number, if ULP wants it to be specified;

 o local eligible address list - An address list that the local SCTP
   endpoint should bind. By default, if an address list is not in
   included, all IP addresses assigned to the SHUTDOWN
   SENT state.

Stewart, et al                                               [Page  67]

9. Termination of Association

All existing associations host should be terminated when an endpoint exits
from service. An association can be terminated used by
   the local endpoint.

   IMPLEMENTATION NOTE: If this optional attribute is supported by either close or
shutdown.

9.1 Close of an Association

When an endpoint decides to close down an existing association, it
shall send an ABORT message to its peer endpoint. The sender MUST fill
in
   implementation, it will be the peer's Verification Tag in responsibility of the outbound datagram and MUST NOT
bundle any DATA chunk with implementation
   to enforce that the ABORT.

No acknowledgment is required for an ABORT message. In IP source address field of any
circumstances, an SCTP packets
   sent out by this endpoint MUST NOT respond to any received datagram
that contains an ABORT with its own ABORT (also see Section 8.4).

The receiver shall apply one of the special Verification Tag check rules
described IP addresses
   indicated in Section 8.5.1 when handling the datagram carrying an
ABORT.

After checking the Verification Tag, the peer shall remove the local eligible address list.

B) Associate

Format: ASSOCIATE(local SCTP instance name, destination transport addr,
        outbound stream count)
-> association from its record, and shall report the termination to its
upper layer.

9.2 Shutdown of an Association

Using the TERMINATE id [,destination transport addr list] [,outbound stream
   count]

This primitive (see Section 10.1), allows the upper layer of an
endpoint in to initiate an association can gracefully shutdown the association.
This will guarantee that all outstanding datagrams from the to a
specific peer of
the shutdown initiator endpoint.

The peer endpoint shall be delivered before the association
terminates.

Upon receipt specified by one of the TERMINATE primitive from its upper layer, transport addresses
which defines the
initiator endpoint enters SHUTDOWN-PENDING state and remains there
until all outstanding TSNs have been acknowledged by the far end. It
accepts no new data from its upper layer, but retransmits data to the
far end if necessary to fill gaps.

Once all outstanding TSNs have (see Section 1.4).  If the local SCTP
instance has not been acknowledged, initialized, the initiator
endpoint shall send ASSOCIATE is considered an
error.

An association id, which is a SHUTDOWN message local handle to the peer of the SCTP association,
and shall include
will be returned on successful establishment of the last cumulative TSN it has received from association. If
SCTP is not able to open an SCTP association with the peer in endpoint,
an error is returned.

Other association parameters may be returned, including the 'Cumulative TSN ACK' field. It shall then start complete
destination transport addresses of the
T2-shutdown timer and enter peer as well as the Shutdown-sent state. If outbound
stream count of the timer
expires, local endpoint. One of the initiator must re-send transport address from
the SHUTDOWN with returned destination addresses will be selected by the updated last
TSN received from its local
endpoint as default primary path for sending SCTP
packets to this peer.  The same rules in 6.3 SHALL returned "destination transport addr
list" can be followed to determine used by the proper timer
value for T2-shutdown. The sender of ULP to change the SHUTDOWN message may also
optionally include default primary path or to
force sending a SACK packet to indicate any gaps by bundling both a specific transport address.

  IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
  blocking function call, the
SACK and SHUTDOWN message together.

Stewart, et al                                               [Page  68]

Note ASSOCIATE primitive can return
  association parameters in addition to the sender of association id upon
  successful establishment. If ASSOCIATE primitive is implemented as a shutdown should limit
  non-blocking call, only the association id shall be returned and
  association parameters shall be passed using the COMMUNICATION UP
  notification.

Mandatory attributes:

 o local SCTP instance name - obtained from the number INITIALIZE operation.

 o destination transport addr - specified as one of
retransmissions the transport
   addresses of the shutdown message to peer endpoint with which the protocol parameter
'Association.Max.Retrans'. If this threshold association is exceeded the endpoint
should destroy to be
   established.

 o outbound stream count - the TCB and may report number of outbound streams the endpoint unreachable ULP
   would like to open towards this peer endpoint.

Optional attributes:

None.

C) Shutdown

Format: SHUTDOWN(association id)
-> result

Gracefully closes an association. Any locally queued user data
will be delivered to the
upper layer (and thus the peer. The association enters the CLOSED state).

Upon the reception of the SHUTDOWN, will be terminated only
after the peer shall enter the
Shutdown-received state, and shall verify, by checking acknowledges all the TSN ACK
field SCTP packets sent.  A success code
will be returned on successful termination of the message, that all its outstanding datagrams have been
received by the initiator. association. If there are still outstanding datagrams left, the peer shall mark
them for retransmission and start
attempting to terminate the retransmit procedure as defined
in Section 6.3.

While association results in Shutdown-sent state, the initiator a failure, an error
code shall immediately respond be returned.

Mandatory attributes:

 o association id - local handle to each inbound the SCTP datagram containing association

Optional attributes:

None.

D) Close

Format: ABORT(association id [, cause code])
-> result

Ungracefully closes an association. Any locally queued user data from the peer with
a SACK
will be discarded and restart the T2-shutdown timer.

If there an ABORT chunk is no more outstanding datagrams, the peer shall send a
SHUTDOWN ACK and then remove all record of the association.

Upon sent to the receipt peer. A success
code will be returned on successful abortion of the SHUTDOWN ACK, association. If
attempting to abort the initiator association results in a failure, an error
code shall stop the
T2-shutdown timer and remove all record of the association.

Note: that it should be returned.

Mandatory attributes:

 o association id - local handle to the responsibility SCTP association

Optional attributes:

 o cause code - reason of the initiator abort to be passed to assure
that all the outstanding datagrams on its side have been resolved
before it initiates peer.

None.

E) Send

Format: SEND(association id, buffer address, byte count [,context]
        [,stream id] [,life time] [,destination transport address]
        [,unorder flag] [,no-bundle flag] [,payload protocol-id] )
-> result

This is the shutdown procedure.

Note: an endpoint shall reject any new main method to send user data request from its upper
layer if it is in Shutdown-sent or Shutdown-received state until
completion of via SCTP.

Mandatory attributes:

 o association id - local handle to the sequence.

Note: if an endpoint is in Shutdown-sent state and receives an INIT
message from its peer, it should discard SCTP association

 o buffer address - the INIT message and
retransmit location where the shutdown message. user message to be
   transmitted is stored;

 o byte count - The sender size of the INIT should respond
with a stand-alone SHUTDOWN ACK user data in number of bytes;

Optional attributes:

 o context - an SCTP datagram with optional 32 bit integer that will be carried in the
Verification Tag field of its common header set
   sending failure notification to 0, and let the
normal T1-init timer cause ULP if the INIT message transportation of
   this User Message fails.

 o stream id - to be retransmitted and
thus restart the association.

Note: if an endpoint is in Shutdown-sent state and receives a
SHUTDOWN message from its peer, indicate which stream to send the endpoint shall respond
immediately with a SHUTDOWN ACK and shall stop data on. If not
   specified, stream 0 will be used.

 o life time - specifies the T2-shutdown timer
and remove all record life time of the association.

10. Interface with Upper Layer user data. The Upper Layer Protocols (ULP) shall request for services user data
   will not be sent by passing
primitives to SCTP and shall receive notifications from SCTP for
various events.

Stewart, et al                                               [Page  69]

The primitives and notifications described in this section should after the life time expires. This
   parameter can be used as a guideline for implementing SCTP. The following functional
description of ULP interface primitives is shown for illustrative
purposes. We must warn readers that different SCTP implementations may
have different ULP interfaces. However, all SCTPs must provide a
certain minimum set of services to guarantee that all avoid efforts to transmit stale
   user messages. SCTP
implementations can support notifies the same protocol hierarchy.

10.1 ULP-to-SCTP

The following sections functionally characterize a ULP/SCTP interface.
The notation used is similar to most procedure or function calls in
high level languages.

The ULP primitives described below specify if the basic functions data cannot be
   initiated to transport (i.e. sent to the destination via SCTP's
   send primitive) within the life time variable. However, the
   user data will be transmitted if SCTP must perform has attempted to support inter-process communication. Individual
implementations must define their own exact format, and transmit a
   chunk before the life time expired.

  IMPLEMENTATION NOTE: In order to better support the data lifetime
  option, the transmitter may provide
combinations or subsets hold back the assigning of the basic functions in single calls.

A) Initialize

Format: INITIALIZE ([local port], [local eligible address])
-> local SCTP instance name

This primitive allows SCTP TSN
  number to initialize its internal data structures
and allocate necessary resources an outbound DATA chunk to the last moment. And, for setting up its operation
environment. Note that
  implementation simplicity, once SCTP is initialized, ULP can communicate
directly with other endpoints without re-invoking a TSN number has been assigned the
  sender should consider the send of this primitive.

A local SCTP instance name will be returned DATA chunk as committed,
  overriding any lifetime option attached to the ULP by DATA chunk.

 o destination transport address - specified as one of the SCTP.

Mandatory attributes:

None.

Optional attributes:

The following types destination
   transport addresses of attributes may the peer endpoint to which this packet
   should be passed along with sent. Whenever possible, SCTP should use this destination
   transport address for sending the
primitive: packets, instead of the current
   primary path.

 o local port unorder flag - SCTP port number, this flag, if ULP wants it present, indicates that the user
   would like the data delivered in an unordered fashion to be specified; the peer
   (i.e., the U flag is set to 1 on all DATA chunks carrying this
   message).

 o local eligible address no-bundle flag - A single address that the local instructs SCTP
   endpoint should bind. By default all transport interface cards
   should be used by the local endpoint.

   IMPLEMENTATION NOTE: if not to bundle this user data with
   other outbound DATA chunks. SCTP MAY still bundle even when
   this optional attribute flag is supported by an
   implementation, it will present, when faced with network congestion.

 o payload protocol-id - A 32 bit unsigned integer that is to be the responsibility of the implementation
   passed to enforce that the IP source address field peer indicating the type of any SCTP datagrams
   sent out payload protocol data
   being transmitted. This value is passed as opaque data by this endpoint MUST contain the IP addresses
   indicated in the local eligible address.

Stewart, et al                                               [Page  70]

B) Associate SCTP.

F) Set Primary

Format: ASSOCIATE(local SCTP instance name, SETPRIMARY(association id, destination transport
addr, outbound stream count)
-> association id [,destination address,
                   [source transport addr list] [,outbound stream
count]

This primitive allows address] )
-> result

Instructs the upper layer to initiate an association local SCTP to a
specific peer endpoint. use the specified destination transport
address as primary path for sending packets.

The peer endpoint result of attempting this operation shall be specified by one of the transport addresses
which defines the endpoint (see section 1.4). returned. If the local SCTP
instance has
specified destination transport address is not been initialized, present in the ASSOCIATE is considered
"destination transport address list" returned earlier in an
error.

An associate
command or communication up notification, an error shall be returned.

Mandatory attributes:

 o association id, which is a id - local handle to the SCTP association,
will be returned on successful establishment of the association. If
SCTP is not able to open an SCTP association with the peer endpoint,
an error is returned.

Other association parameters may be returned, including the complete

 o destination transport addresses of the peer as well as the outbound
stream count of the local endpoint. One of the transport address from - specified as one of the returned destination transport
   addresses will be selected by of the local
endpoint peer endpoint, which should be used as default primary destination
   address for sending SCTP
datagrams to this peer.  The returned "destination transport addr
list" can be used packets. This overrides the current primary
   address information maintained by the ULP local SCTP endpoint.

Optional attributes:

 o source transport address - optionally, some implementations may
   allow you to change set the default primary destination source address or to force sending a datagram to a specific transport address.

  IMPLEMENTATION NOTE: If ASSOCIATE placed in all
   outgoing IP datagrams.

G) Receive

Format: RECEIVE(association id, buffer address, buffer size
        [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
   number] [,partial flag] [,delivery number] [,payload protocol-id]

This primitive shall read the first user message in the SCTP in-queue
into the buffer specified by ULP, if there is implemented as a
  blocking function call, one available. The size
of the ASSOCIATE primitive can return
  association parameters message read, in addition to bytes, will be returned. It may, depending on
the association specific implementation, also return other information such as the
senders address, the stream id on which it is received, whether there
are more messages available for retrieval, etc. For ordered messages,
their stream sequence number may also be returned.

Depending upon
  successful establishment. If ASSOCIATE the implementation, if this primitive is implemented as a
  non-blocking call, only invoked when

no message is available the association id shall be returned and
  association parameters shall be passed using implementation should return an indication
of this condition or should block the COMMUNICATION UP
  notification. invoking process until data does
become available.

Mandatory attributes:

 o association id - local handle to the SCTP instance name association

 o buffer address - obtained from the INITIALIZE operation. memory location indicated by the ULP to store
   the received message.

 o destination transport addr buffer size - specified as one of the transport
   addresses maximum size of the peer endpoint with which the association is data to be
   established. received, in bytes.

Optional attributes:

 o outbound stream count id - to indicate which stream to receive the data on.

 o stream sequence number - the stream sequence number assigned by the
   sending SCTP peer.

 o partial flag - if this returned flag is set to 1, then this
   Receive contains  a partial delivery of outbound streams the ULP
   would like whole message. When
   this flag is set, the stream id and stream sequence number MUST
   accompany this receive. When this flag is set to open towards 0, it indicates
   that no more deliveries will be received for this stream sequence
   number.

 o payload protocol-id - A 32 bit unsigned integer that is received
   from the peer endpoint.

Optional attributes:

None.

Stewart, et al                                               [Page  71]

C) Terminate indicating the type of payload protocol of the
   received data. This value is passed as opaque data by SCTP.

H) Status

Format: TERMINATE(association STATUS(association id)
-> result

Gracefully terminates an association. Any locally queued user status data
will be delivered to

This primitive should return a data block containing the peer. The following
information:
  association will be terminated only
after the peer acknowledges all the messages sent.  A success code
will be returned connection state,
  destination transport address list,
  destination transport address reachability states,
  current receiver window size,
  current congestion window sizes,
  number of  unacknowledged DATA chunks,
  number of DATA chunks pending receipt,
  primary path,
  most recent SRTT on successful termination of the association. If
attempting to terminate the association results in a failure, an error
code shall be returned. primary path,
  RTO on primary path,
  SRTT and RTO on other destination addresses, etc.

Mandatory attributes:

 o association id - local handle to the SCTP association

Optional attributes:

 None.

D) Abort

I) Change Heartbeat

Format: ABORT(association id [, cause code]) CHANGEHEARTBEAT(association id, destination transport address,
        new state [,interval])
-> result

Ungracefully terminates an association. Any locally queued user data
will be discarded and an ABORT message is sent to

Instructs the peer. A success
code will be returned local endpoint to enable or disable heartbeat on successful abortion of the association. If
specified destination transport address.

The result of attempting to abort the association results in a failure, an error
code this operation shall be returned.

  Note: If possible the SCTP should attempt to return all un-acknowledged
data to the upper layer, however this behavior is implementation
dependent.

Mandatory attributes:

 o association id - local handle to the SCTP association

Optional attributes:

 o cause code - reason of the abort to be passed to Even when enabled, heartbeat will not take place if the peer.

None.

Stewart, et al                                               [Page  72]

E) Send

Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination
  destination transport address] [,un-order
flag] [,no-bundle flag] [,payload protocol-id] )
-> result

This address is the main method to send user data via SCTP. not idle.

Mandatory attributes:

 o association id - local handle to the SCTP association

 o buffer destination transport address - the location where the user message to be
   transmitted is stored;

 o byte count - The size specified as one of the user data in number transport
   addresses of octets;

Optional attributes:

 o context - optional information that will be carried in the
   sending failure notification to the ULP if the transportation of
   this datagram fails. peer endpoint.

 o stream id new state - to indicate which stream to send the data on. If not
   specified, stream 0 will be used. new state of heartbeat for this destination
   transport address (either enabled or disabled).

Optional attributes:

 o life time interval - specifies if present, indicates the life time frequency of the user data. The user data
   will not be sent by SCTP after the life time expires. This
   parameter can be used to avoid efforts to transmit stale
   user messages. SCTP notifies the ULP, heartbeat if the data cannot be
   initiated to transport (i.e. sent
   this is to the enable heartbeat on a destination via SCTP's
   send primitive) within transport
   address. Default interval is the life time variable. However, RTO of the
   user data will be transmitted if a chunk has been attempted to
   be transmitted before destination address.

J) Request HeartBeat

Format: REQUESTHEARTBEAT(association id, destination transport
        address)
-> result

Instructs the life time expired.

  IMPLEMENTATION NOTE: in order local endpoint to better support perform a HeartBeat on the data lifetime
  option, specified
destination transport address of the data sender MAY  hold back given association. The returned
result should indicate whether the assigning transmission of the TSN number
  to an outbound data HEARTBEAT
chunk to the last moment. And, for implementation
  simplicity, once a TSN number has been assigned the sender MAY consider
  the send of this data chunk as committed, overriding any lifetime option
  attached destination address is successful.

Mandatory attributes:

 o association id - local handle to the data chunk. SCTP association

 o destination transport address - specified as one of the destination transport addresses address of the peer endpoint to
   association on which this message a heartbeat should be sent. Whenever possible, SCTP should use this issued.

K) Get SRTT Report

Format: GETSRTTREPORT(association id, destination transport address for sending address)
-> srtt result

Instructs the datagram, instead of local SCTP to report the current
   primary SRTT measurement on the
specified destination transport address.

 o un-order flag - this flag, if present, indicates that the user
   would like address of the data delivered in given association. The
returned result can be an un-ordered fashion to integer containing the peer. most recent SRTT in
milliseconds.

Mandatory attributes:

 o no-bundle flag association id - instructs SCTP not local handle to bundle the user data with
   other outbound DATA chunks. Note: SCTP may still bundle even when
   this flag is present, when faced with network congestion. association

 o payload protocol-id destination transport address - A 32 bit u_int that is to be passed to the
   peer indicating the type transport address of payload protocol data being
   transmitted. This value the
   association on which the SRTT measurement is passed as opaque data by SCTP.

Stewart, et al                                               [Page  73]

F) to be reported.

L) Set Primary Failure Threshold

Format: SETPRIMARY(association SETFAILURETHRESHOLD(association id, destination transport address)
        address, failure threshold)
-> result

Instructs

This primitive allows the local SCTP to use customize the specified destination transport
address as primary destination address reachability
failure detection threshold 'Path.Max.Retrans' for sending datagrams.

The result of attempting this operation shall be returned. If the specified
destination address.

Mandatory attributes:

 o association id - local handle to the SCTP association

 o destination transport address is not present in - the
"destination transport address list" returned earlier in an associate
command or communication up notification, an error shall of the
   association on which the failure detection threshold is to be returned. set.

 o failure threshold - the new value of 'Path.Max.Retrans' for the
   destination address.

M) Set Protocol Parameters

Format: SETPROTOCOLPARAMETERS(association id, [,destination transport
        address,] protocol parameter list)
-> result

This primitive allows the local SCTP to customize the protocol
parameters.

Mandatory attributes:

 o association id - local handle to the SCTP association

 o destination transport address protocol parameter list - specified as one The specific names and values of the
   protocol parameters (e.g., Association.Max.Retrans [see Section 14])
   that the SCTP user wishes to customize.

Optional attributes:

 o destination transport
   addresses address - some of the peer endpoint, which should protocol parameters may
   be used as primary
   address for sending datagrams. This overrides the current primary set on a per destination transport address information maintained by the local SCTP endpoint.
Stewart, et al                                               [Page  74]

G) basis.

N) Receive unsent message

Format: RECEIVE(association RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
        [,stream id])
-> byte count [,transport address] [,stream id] [,stream [, stream sequence number] [,partial flag] [,delivery number]
        [,payload protocol-id]

This primitive shall read the first user message in the SCTP in-queue
to ULP, if there is one available, into the specified buffer. The size
of the message read, in octets, will be returned. It may, depending on
the specific implementation, also return other information such as the
sender's address, the stream id on which it is received, whether there
are more messages available for retrieval, etc. For ordered messages,
their stream sequence number may also be returned.

Depending upon the implementation, if this primitive is invoked when
no message is available the implementation should return an indication
of this condition or should block the invoking process until data does
become available.

Mandatory attributes: protocol-id])

 o association data retrieval id - local handle The identification passed to the SCTP association ULP in the
   failure notification.

 o buffer address - the memory location indicated by the ULP to store
   the received message.

 o buffer size - the maximum size of data to be received, in octets. bytes.

Optional attributes:

 o stream id - this is a return value that is set to  indicate
   which stream to receive the data on. was sent to.

 o stream sequence number - this value is returned indicating
   the stream sequence number assigned by that was associated with the
   sending SCTP peer. message.

 o partial flag - if this returned flag is set to 1, then this
   message is a partial delivery of the whole message. When
   this flag is set, the stream id and stream sequence number MUST
   accompany this receive. When this flag is set to 0, it indicates
   that no more deliveries will be received for this stream sequence
   number.

 o payload protocol-id - A The 32 bit u_int unsigned integer that is received from the
   peer indicating the type of payload protocol of the received
   data. This value is passed as opaque data by SCTP.

Stewart, et al                                               [Page  75]

H) Status

Format: STATUS(association id)
-> status data

This primitive should return a data block containing the following
information:
  association connection state,
  destination transport address list,
  destination transport address reachability state,
  current receiver window size,
  current congestion window sizes,
  number of DATA chunks awaiting acknowledgment,
  number of DATA chunks pending receipt,
  primary destination transport address,
  SRTT on primary destination address,
  RTO on primary destination address,
  SRTT and RTO on other destination addresses, etc.

Mandatory attributes:

 o association id - local handle to the SCTP association

Optional attributes:

 None.

I) Change Heartbeat

Format: CHANGEHEARTBEAT(association id, destination transport address,
   new state [,interval])
-> result

Instructs the local endpoint to enable or disable heart beat on the
specified destination transport address.

The result of attempting this operation shall be returned.
Note, even when enabled, heart beat will not take place if the
destination transport address is not idle.

Mandatory attributes:

 o association id - local handle to the SCTP association

 o destination transport address - specified as one of the transport
   addresses of the peer endpoint.

 o new state - the new state of heart beat for this destination
   transport address (either enabled or disabled).

Optional attributes:

 o interval - if present, indicates the frequency of the heart beat if
   this is to enable heart beat on a destination transport
   address. Default interval is the RTO of the destination address.

Stewart, et al                                               [Page  76]

J) Request HeartBeat

Format: REQUESTHEARTBEAT(association id, destination transport
   address)
-> result

Instructs the local endpoint was sent to
   be sent to perform a HeartBeat on the specified
destination transport address of the given association. The returned
result should indicate whether peer indicating the transmission type of payload protocol of the HEARTBEAT
   received data.

O) Receive unacknowledged message to the destination address is successful.

Mandatory attributes:

Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,
        [,stream id] [, stream sequence number] [,partial flag]
        [,payload protocol-id])

 o association data retrieval id - local handle The identification passed to the SCTP association ULP in the
   failure notification.

 o destination transport buffer address - the transport address of the
   association on which a heartbeat should be issued.

K) Get SRTT Report

Format: GETSRTTREPORT(association id, destination transport address)
-> srtt result

Instructs memory location indicated by the local SCTP ULP to report store
   the current SRTT measurement on received message.

 o buffer size - the
specified destination transport address maximum size of the given association. The
returned result can data to be an integer containing the most recent SRTT received, in
milliseconds.

Mandatory bytes.

Optional attributes:

 o association stream id - local handle this is a return value that is set to  indicate
   which stream the SCTP association data was sent to.

 o destination transport address stream sequence number - the transport address of the
   association on which the SRTT measurement this value is to be reported.

Stewart, et al                                               [Page  77]

L) Set Failure Threshold

Format: SETFAILURETHRESHOLD(association id, destination transport
address, failure threshold)
-> result

This primitive allows the local SCTP to customize the reachability
failure detection threshold 'Path.Max.Retrans' for returned indicating
   the specified
destination address.

Mandatory attributes:

 o association id - local handle to stream sequence number that was associated with the SCTP association message.

 o destination transport address partial flag - the transport address if this returned flag is set to 1, then this
   message is a partial delivery of the
   association on which whole message. When
   this flag is set, the failure detection threshold stream id and stream sequence number MUST
   accompany this receive. When this flag is set to 0, it indicates
   that no more deliveries will be set. received for this stream sequence
   number.

 o failure threshold payload protocol-id - The 32 bit unsigned integer that was sent to
   be sent to the new value of 'Path.Max.Retrans' for peer indicating the
   destination address.

M) Set Protocol Parameters

Format: SETPROTOCOLPARAMETERS(association id, [,destination transport
address,] type of payload protocol parameter list)
-> result

This primitive allows of the local
   received data.

P) Destroy SCTP to customize the protocol
parameters.

Mandatory attributes: instance

Format: DESTROY(local SCTP instance name)

o association id - local handle to the SCTP association

 o protocol parameter list instance name - The specific names and values of this is the
   protocol parameters (e.g., Association.Max.Retrans [see Section
   14]) value that was
  passed to the application in the initialize primitive and
  it indicates which SCTP user wishes instance to customize.

Optional attributes:

 o destination transport address - some of the protocol parameters may be set on a per destination transport address basis. destroyed.

10.2 SCTP-to-ULP

It is assumed that the operating system or application environment
provides a means for the SCTP to asynchronously signal the ULP
process. When SCTP does signal an ULP process, certain information is
passed to the ULP.

  IMPLEMENTATION NOTE: in In some cases this may be done through a
  seperate
  separate socket or error channel.

Stewart, et al                                               [Page  78]

A) DATA ARRIVE notification

SCTP shall invoke this notification on the ULP when a user message is
successfully received and ready for retrieval.

The following may be optionally be passed with the notification:

 o association id - local handle to the SCTP association

 o stream id - to indicate which stream the data is received on.

B) SEND FAILURE notification

If a message can not be delivered SCTP shall invoke this notification
on the ULP.

The following may be optionally be passed with the notification:

 o association id - local handle to the SCTP association

 o data retrieval id - the location ULP can find the un-delivered message. an identification used to retrieve
   unsent and unacknowledged data.

 o cause code - indicating the reason of the failure, e.g., size too
   large, message life-time expiration, etc.

 o context - optional information associated with this message (see
   D in section Section 10.1).

C) NETWORK STATUS CHANGE notification

When a destination transport address is marked down inactive (e.g., when
SCTP detects a failure), or marked up active (e.g., when SCTP detects a
recovery), SCTP shall invoke this notification on the ULP.

The following shall be passed with the notification:

 o association id - local handle to the SCTP association

 o destination transport address - This indicates the destination
   transport address of the peer endpoint affected by the change;

 o new-status - This indicates the new status.

Stewart, et al                                               [Page  79]

D) COMMUNICATION UP notification

This notification is used when SCTP becomes ready to send or receive
user messages, or when a lost communication to an endpoint is
restored.

  IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
  blocking function call, the association parameters are returned as a
  result of the ASSOCIATE primitive itself. In that case,
  COMMUNICATION UP notification is optional at the association
  initiator's side.

The following shall be passed with the notification:

 o association id - local handle to the SCTP association

 o status - This indicates what type of event that has occurred

 o destination transport address list - the complete set of transport
   addresses of the peer

 o outbound stream count - the maximum number of streams allowed to be
   used in this association by the ULP

 o inbound stream count - the number of streams the peer endpoint
   has requested with this association (this may not be the same
   number has as 'outbound stream count').

Stewart, et al                                               [Page  80]

E) COMMUNICATION LOST notification

When SCTP loses communication to an endpoint completely (via

Heartbeats) or detects that the endpoint has performed an abort or graceful shutdown
operation, it shall invoke this notification on the ULP.

The following shall be passed with the notification:

 o association id - local handle to the SCTP association

 o status - This indicates what type of event that has occurred;
            The following status may be optionally passed with the notification:

 o unsent-messages - The number and location of un-sent messages
   still indicate a failure OR a normal
            termination event occurred in hold by SCTP;

 o unacknowledged-messages - The number and location of messages
   that were attempted response to a
            shutdown or abort request.

The following may be transported to the destination, but were
   not acknowledged when passed with the loss of communication was detected. notification:

 o data retrieval id - an identification used to retrieve
   unsent and unacknowledged data.

 o last-acked - the sequence number TSN last acked by that peer endpoint;

 o last-sent - the sequence number TSN last sent to that peer endpoint;

 o received-but-not-delivered - messages that were received by SCTP
   but not yet delivered to the ULP.

Note: the un-send data report may not be accurate for those user
messages which are segmented by SCTP during transmission.

F) COMMUNICATION ERROR notification

When SCTP receives an ERROR chunk from its peer and decides to notify
its ULP, it can invoke this notification on the ULP.

The following can be passed with the notification:

 o association id - local handle to the SCTP association

 o error info - this indicates the type of error and optionally some
   additional information received through the ERROR chunk.

Stewart, et al                                               [Page  81]

G) RESTART notification

When SCTP detects that the peer has restarted, it may send
this notification to its ULP.

The following can be passed with the notification:

 o association id - local handle to the SCTP association

H) SHUTDOWN COMPLETE notification

When SCTP completes the shutdown procedures (section 9.2) this
notification is passed to the upper layer.

The following can be passed with the notification:

 o association id - local handle to the SCTP association

11. Security Considerations

11.1 Security Objectives

As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signaling messages for
telephony services, between two networked endpoints, SCTP has the
following security objectives.

  - availability of reliable and timely data transport services
  - integrity of the user-to-user information carried by SCTP

11.2 SCTP Responses To Potential Threats

It is clear that

SCTP may potentially be used in a wide variety of risk situations.  It
is important for operator(s) of the systems
concerned running SCTP to analyze their
particular situations and decide on the appropriate counter-measures.

Where the SCTP system serves a group of users, it is probably
operating as part

Operators of a professionally managed corporate or service
provider network.  It is reasonable to expect that this management
includes an appropriate security policy framework.  [RFC 2196, "Site
Security Handbook", B. Fraser Ed., September 1997] systems running SCTP should be
consulted consult [RFC2196] for guidance.

The case is more difficult where the SCTP system is operated by a
private user. The service provider with whom that user has a
contractual arrangement SHOULD provide help to ensure that the
user's site is secure, ranging from advice on configuration through
downloaded scripts and security software.
guidance in securing their site.

11.2.1 Countering Insider Attacks

The principles of the Site Security Handbook [13] [RFC2196] should be applied to minimize the risk of
theft of information or sabotage by insiders.  These  Such procedures include
publication of security policies, control of access at the physical,
software, and network levels, and separation of services.

Stewart, et al                                               [Page  82]

11.2.2 Protecting against Data Corruption in the Network

Where the risk of undetected errors in datagrams delivered by the lower
layer transport services is considered to be too great, additional checksum
integrity protection may be required.  The question is
whether required.  If this is appropriately provided as an SCTP service because it
is needed by most potential users of SCTP, or whether instead it
should be additional protection were
provided by in the application-layer, the SCTP user application.  (The SCTP protocol
overhead, as opposed header would remain
vulnerable to deliberate integrity attacks.  While the signaling payload, is protected adequately
by the Adler-32 checksum and measures taken in existing SCTP
mechanisms for detection of packet replays are considered sufficient
for normal operation, stronger protections are needed to prevent replay protect SCTP
when the operating environment contains significant risk of deliberate
attacks and masquerade.) from a sophisticated adversary.

In any event, order to promote software code-reuse, to avoid re-inventing the checksum must be
specifically designed
wheel, and to ensure that it detects avoid gratuitous complexity to SCTP, the errors left behind
by IP
Authentication Header [RFC2402] SHOULD be used when the Adler-32 checksum. threat
environment requires stronger integrity protections, but does not
require confidentiality.

A widely implemented BSD Sockets API extension exists for applications
to request IP security services, such as AH or ESP from an operating
system kernel.  Applications can use such an API to request AH whenever
AH use is appropriate.

11.2.3 Protecting Confidentiality

In most cases, the risk of breach of confidentiality applies to the
signaling data payload, not to the SCTP or lower-layer protocol
overheads. If that is true, encryption of the SCTP user data only
may might
be considered. As with the supplementary checksum service, user data
encryption may MAY be performed by the SCTP user application.  Alternately,
the user application MAY use an implementation-specific API to request
that the IP Encapsulating Security Payload (ESP) [RFC2406] be used to
provide confidentiality and integrity.

Particularly for mobile users, the requirement for confidentiality
may
might include the masking of IP addresses and ports.  In this case
IPSEC ESP should
SHOULD be used instead of application-level encryption.
Similarly, where other reasons prompt the use confidentiality. If ESP is
used to protect confidentiality of the IPSEC SCTP traffic, an ESP
service, application-level encryption cryptographic
transform that includes cryptographic integrity protection MUST be
used, because if there is unnecessary. It a confidentiality threat there will also be up
to the SCTP system operators to configure the application
appropriately. a
strong integrity threat.

Whenever ESP is in use, application-level encryption is not generally
required.

Regardless of which level performs the encryption, where confidentiality is provided, the IPSEC ISAKMP
service should [RFC2408]
and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key
management.

Operators should consult [RFC 2401, "Security Architecture for the
Internet Protocol", S. Kent, R. Atkinson,  November 1998] [RFC2401] for more information on the configuration of IPSEC security
services between hosts
with available at and without intervening firewalls. immediately above the Internet Protocol
layer.

11.2.4 Protecting against Blind Denial of Service Attacks

A blind attack is one where the attacker is unable to intercept or
otherwise see the content of data flows passing to and from the target
SCTP node where it is not a party to the association. node.  Blind denial of service attacks may take the form of
flooding, masquerade, or improper monopolization of services.

Stewart, et al                                               [Page  83]

11.2.4.1 Flooding

The objective of flooding is to cause loss of service and incorrect
behavior at target systems through resource exhaustion, interference
with legitimate transactions, and exploitation of buffer-related
software bugs.  Flooding may be directed either at the SCTP node or at
resources in the intervening IP Access Links or the Internetwork. Internet.
Where the latter entities are the target, flooding will manifest
itself as loss of network services, including potentially the breach
of any firewalls in place.

In general, protection against flooding begins at the equipment
design level, where it includes measures such as:

 - avoiding commitment of limited resources before determining that
   the request for service is legitimate
 - giving priority to completion of processing in progress over the
   acceptance of new work
 - identification and removal of duplicate or stale queued requests
   for service.
 - not responding to unexpected packets sent to non-unicast
   addresses.

Network equipment should be capable of generating an alarm and log
if a suspicious increase in traffic occurs.  The log should provide
information such as the identity of the incoming link and source
address(es) used which will help the network or SCTP system operator
to take protective measures.  Procedures should be in place for the
operator to act on such alarms if a clear pattern of abuse emerges.

The design of SCTP is resistant to flooding attacks, particularly in
its use of a four-way start-up handshake, its use of a cookie to
defer commitment of resources at the responding SCTP node until the
handshake is completed, and its use of a verification tag Verification Tag to prevent
insertion of extraneous messages packets into the flow of an established
association.

The IP Authentication Header and Encapsulating Security Payload might
be useful in reducing the risk of certain kinds of denial of service
attacks."

The use of the Host Name feature in the INIT chunk could be used to
flood a target DNS server. A large backlog of DNS queries, resolving
the Host Name received in the INIT chunk to IP addresses, could be
accomplished by sending INIT's to multiple hosts in a given domain.
In addition, an attacker could use the Host Name feature in an indirect
attack on a third party by sending large numbers of INITs to random
hosts containing the host name of the target.  In addition to the
strain on DNS resources, this could also result in large numbers of
INIT ACKs being sent to the target.  One method to protect against this
type of attack is to verify that the IP addresses received from DNS
include the source IP address of the original INIT.  If the list of IP
addresses received from DNS does not include the source IP address of
the INIT, the endpoint MAY silently discard the INIT.  This last option
will not protect against the attack against the DNS.

11.2.4.2 Masquerade

Masquerade can be used to deny service in several ways:

 - by tying up resources at the target SCTP node to which the
   impersonated node has limited access.  For example, the target node
   may by policy permit a maximum of one SCTP association with the
   impersonated SCTP node. The masquerading attacker may attempt to
   establish an association purporting to come from the impersonated
   node so that the latter cannot do so when it requires it.
 - by deliberately allowing the impersonation to be detected,
   thereby provoking counter-measures which cause the impersonated node
   to be locked out of the target SCTP node.

 - by interfering with an established association by inserting
   extraneous content such as a SHUTDOWN request.

Stewart, et al                                               [Page  84]

SCTP prevents reduces the risk of masquerade attacks through IP spoofing by use
of the four-way
startup handshake.  Because four-way startup handshake.  Because the initial exchange is
memoryless, no lockout mechanism is triggered by masquerade attacks.
In addition, the INIT ACK containing the State Cookie is transmitted
back to the IP address from which it received the INIT.  Thus the
attacker would not receive the initial exchange is memoryless, no
lockout mechanism is triggered by masquerade attacks. INIT ACK containing the State Cookie.
SCTP protects against insertion of extraneous messages packets into the flow of
an established association by use of the verification tag. Verification Tag.

Logging of received INIT requests and abnormalities such as
unexpected INIT ACKs might be considered as a way to detect patterns
of hostile activity.  However, the potential usefulness of such
logging must be weighed against the increased SCTP startup
processing it implies, rendering the SCTP node more vulnerable to
flooding attacks.  Logging is pointless without the establishment of
operating procedures to review and analyze the logs on a routine
basis.

11.2.4.3 Improper Monopolization of Services

Attacks under this heading are performed openly and legitimately by
the attacker.  They are directed against fellow users of the target
SCTP node or of the shared resources between the attacker and the
target node.  Possible attacks include the opening of a large number
of associations between the attacker's node and the target, or
transfer of large volumes of information within a legitimately-
established association.

Such attacks take advantage of policy deficiencies at the target
SCTP node.  Defense begins with a contractual prohibition of
behavior directed to denial of service to others.

Policy limits should be placed on the number of associations per
adjoining SCTP node.  SCTP user applications should be capable of
detecting large volumes of illegitimate or "no-op" messages within a
given association and either logging or terminating the association as
a result, based on local policy.

11.3 Protection against Fraud and Repudiation

The objective of fraud is to obtain services without authorization
and specifically without paying for them.  In order to achieve this
objective, the attacker must induce the SCTP user application at the
target SCTP node to provide the desired service while accepting
invalid billing data or failing to collect it.  Repudiation is a
related problem, since it may occur as a deliberate act of fraud or
simply because the repudiating party kept inadequate records of
service received.

Potential fraudulent attacks include interception and misuse of
authorizing information such as credit card numbers, blind
masquerade and replay, and man-in-the middle attacks which modify
the messages packets passing through a target SCTP association in real time.

Stewart, et al                                               [Page  85]

The interception attack is countered by the confidentiality measures

discussed in section Section 11.2.3 above.

Section 11.2.4.2 describes how SCTP is resistant to blind masquerade
attacks, as a result of the four-way startup handshake and the
validation tag.
Verification Tag.  The validation tag Verification Tag and TSN together are
protections against blind replay attacks, where the replay is into an
existing association.

However, SCTP does not protect against man-in-the-middle attacks
where the attacker is able to intercept and alter the messages packets sent
and received in an association.  Where a significant possibility of
such attacks is seen to exist, or where possible repudiation is an
issue, the use of the IPSEC AH service is recommended to ensure both
the integrity and the authenticity of the messages SCTP packets passed.

SCTP also provides no protection against attacks originating at or
beyond the SCTP node and taking place within the context of an
existing association.  Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in
section
Section 11.2.1.

12. Recommended Transmission Control Block (TCB) Parameters

This section details a recommended set of parameters that should
be contained within the TCB for an implementation. This section is
for illustrative purposes and should not be deemed as requirements
on an implementation NOR or as an exhaustive list of all parameters
inside an SCTP TCB. Each implementation may need its own additional
parameters to optimize their implementation. for optimization.

12.1 Parameters necessary for the SCTP instance

Associations

Associations: A list of current associations and mappings to the
              data consumers for each association. This may be in
              the form of a hash table or other implementation
              dependent structure. The data consumers may be process
              identification information such as file descriptors,
              named pipe pointer, or table pointers dependent on how
              SCTP is implemented.

Secret Key Key:   A secret key used by this endpoint to sign all cookies. compute the MAC.
              This SHOULD be a cryptographic quality random number with
              a sufficient length. Discussion in RFC 1750 [1] [RFC1750] can be
              helpful in selection of the key.

Address List List: The list of IP addresses that this instance has bound.
              This information is passed to one's peer(s) in INIT and
             INIT-ACK messages.
              INIT ACK chunks.

SCTP Por Port:    The local SCTP port number the endpoint is bound to.

Stewart, et al                                               [Page  86]

12.2 Parameters necessary per association (i.e. the TCB)

Peer        : Tag value to be sent in every datagram packet and is received
Verification
Verification: in the INIT or INIT ACK message. chunk.
Tag         :

My          : Tag expected in every inbound datagram packet and sent in the
Verification
Verification: INIT or INIT ACK message. chunk.
Tag         :

State       : A state variable indicating what state the association is
            : in, i.e . COOKIE_WAIT, COOKIE_SENT, i.e. COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
             SHUTDOWN_PENDING, SHUTDOWN_SENT, SHUTDOWN_RECEIVED.
            : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
            : SHUTDOWN-ACK-SENT.

              Note: No "CLOSED" state is illustrated since if a
              association is "CLOSED" its TCB SHOULD be removed.

Peer        : A list of SCTP transport addresses that the peer is
Transport   : bound to. This information is derived from the INIT or
Address      INIT-ACK     : INIT ACK and is used to associate an inbound datagram packet
List        : with a given association. Normally this information is
            : hashed or keyed for quick lookup and access of the TCB.

Primary     : This is the current primary destination transport
Destination
Path        : address of the peer endpoint.  It may also specify a
            : source transport address on this endpoint.

Overall     : The overall association error count.
Error Count :

Overall     : The threshold for this association that if the Overall
Error       : Error Count reaches will cause this association to be
Threshold   : torn down.

Peer Rwnd   : Current calculated value of the peer's rwnd.

Next TSN     My    : The next TSN number I will assign. to be assigned to a new DATA chunk.
            : This is sent in the INIT or INIT-ACK message INIT ACK chunk to the peer
            : and incremented each time a DATA chunk is assigned a
            : TSN (normally just prior to transmit or during
             segmentation).
            : fragmentation).

Last Rcvd   : This is the last TSN I received and is the
TSN          current cumulative TSN point. in sequence. This value is
TSN         : set initially by taking the peers initial peer's Initial TSN,
            : received in the INIT or INIT-ACK message, INIT ACK chunk, and
            : subtracting one from it.

Mapping     : An array of bits or bytes indicating which out of
Array       : order TSN's have been received (relative to the
             cumulative TSN i.e.
            : Last Rcvd TSN). If no GAP's gaps exist, i.e. no out of order messages
            : packets have been received, this array will be set to all
            : zero. This structure may be in the form of a circular
            : buffer or bit array.

Stewart, et al                                               [Page  87]

Ack State   : This flag indicates if the next received datagram packet
            : is to be responded to with a SACK. This is initialized
            : to 0,  when 0.  When a datagram packet is received it is incremented.
            : If this value reaches 2, 2 or more, a SACK is sent and the
            : value is reset to 0. Note: this This is used only when no datagrams DATA
            : chunks are received out of order, when order. When DATA chunks are
            : out of order order, SACK's are not delayed (see Section 6).

Inbound     : An array of structures to track the inbound streams.
Streams     : Normally including the next sequence number expected
            : and possibly the stream number.

Outbound    : An array of structures to track the outbound streams.
Streams     : Normally including the next sequence number to
            : be sent on the stream.

Reasm Queue : A re-assembly queue.

Local       : The list of local IP addresses bound in to this
Transport   : association.
Address     :
List        :

Association : The smallest PMTU discovered for all of the
PMTU        : peer's transport addresses.

12.3 Per Transport Address Data

For each destination transport address in the peer's address list
derived from the INIT or INIT ACK message, chunk, a number of data elements
needs to be maintained including:

Error count : The current error count for this destination.

Error       : Current error threshold for this destination i.e.
Threshold   : what value marks the destination down if Error count
            : reaches this value.

cwnd        : The current congestion window.

ssthresh    : The current ssthresh value.

RTO         : The current retransmission timeout value.

SRTT        : The current smoothed round trip time.

RTTVAR      : The current RTT variation.

partial     : The tracking method for increase of cwnd when in
bytes acked : congestion avoidance mode (see section Section 6.2.2)

state       : The current state of this destination, i.e. DOWN, UP,
            : ALLOW-HB, NO-HEARTBEAT, etc.

P-MTU

PMTU       : The current known path MTU.

Per         : A timer used by each destination.
Destination :
Timer

Stewart, et al                                               [Page  88]       :

RTO-Pending : A flag used to track if one of the datagrams DATA chunks sent to
             this address is currently being used to compute a RTT. If
             this flag is 0, the next datagram DATA chunk sent to this
             destination should be used to compute a RTT and this flag
             should be set. Every time the RTT calculation
             completes (i.e. the datagram DATA chunk is SACK'd) clear this flag.

last-time   : The time this destination was last sent to. This can be
used        : used to determine if a HEARTBEAT is needed.

12.4 General Parameters Needed

Out Queue   : A queue of outbound datagrams. DATA chunks.

In Queue    : A queue of inbound datagrams. DATA chunks.

13. IANA Consideration

This protocol will require port reservation like TCP for the use of
"well known" servers within the Internet. It is suggested that all All current TCP ports should shall
be automatically reserved in the SCTP port address space. New requests
should follow IANA's current mechanisms for TCP.

This protocol may also be extended through IANA in three ways:
 -- through definition of additional chunk types,
 -- through definition of additional parameter types, or
 -- through definition of additional cause codes within Operation
    Error chunks

In the case where a particular ULP using SCTP desires to have its own
ports, the ULP should be responsible for registering with IANA for
getting its ports assigned.

13.1 IETF-defined Chunk Extension

The appropriate use of specific chunk types is an integral part of the
SCTP protocol.  In consequence, the intention is that new IETF-defined
chunk types MUST be supported by standards-track RFC documentation.
As a transitional step, a new chunk type MAY be introduced in an
Experimental RFC. Chunk type codes MUST remain permanently associated
with the original documentation on the basis of which they were
allocated.  Thus if the RFC supporting a given chunk type is
deprecated in favor of a new document, the corresponding chunk type
code value is also deprecated and a new code value is allocated in
association with the replacement document.

Stewart, et al                                               [Page  89]

The documentation for a new chunk code type must include the following
information:
(a) a long and short name for the new chunk type;
(b) a detailed description of the structure of the chunk, which MUST
    conform to the basic structure defined in section 3.2;
(c) a detailed definition and description of intended use of each field
    within the chunk, including the chunk flags if any;
(d) a detailed procedural description of the use definition of the new chunk type additional cause codes within
    ERROR chunks

In the operation of the protocol.

If case where a particular ULP using SCTP desires to have its own
ports, the primary numbering space reserved ULP should be responsible for IETF registering with IANA for
getting its ports assigned.

13.1 IETF-defined Chunk Extension

The definition and use (0x00 to 0xFD) of new chunk types is
exhausted, an integral part of
SCTP.  Thus, new codes shall subsequently be allocated in the extension
range 0x0000 chunk types are assigned by IANA through 0xFFFF. Chunks allocated in this range MUST
conform to the following structure:

First word (32 bits): an
IETF Consensus action as shown defined in section 3.2, with chunk type code equal to 0xFF.

Second word:
  first octet MUST be all 1's (0xFF). Next octet MUST be all 0's
  (0x00).  Final two octets contain the allocated extension code value.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|Chunk  Flags   |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|    Extension Type Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                    Value                                      /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

13.2 IETF-defined Chunk Parameter Extension [RFC2434].

The allocation of documentation for a new chunk parameter type code from the IETF
numbering space MUST be supported by RFC documentation.  As with chunk
type codes, parameter type codes are uniquely associated with their
supporting document and MUST be replaced if new documentation is
provided.  This documentation may be Informational, Experimental, or
standards-track at the discretion of the IESG.  It MUST contain must include the following
information:
(a) Name of the parameter type. A long and short name for the new chunk type;
(b) Detailed A detailed description of the structure of the parameter field. This
    structure chunk, which MUST
    conform to the general type-length-value format
    described basic structure defined in section 3.2.1. Section 3.2;
(c) Detailed A detailed definition and description of each component intended use of each field
    within the parameter value. chunk, including the chunk flags if any;
(d) Detailed A detailed procedural description of the intended use of this parameter type,
    and an indication of whether and under what circumstances
    multiple instances of this parameter the new chunk type may be found
    within the
    same chunk.

Stewart, et al                                               [Page  90]

Additional parameter type codes may be allocated initially from operation of the
range 0x0000 through 0xFFFD.  If this space protocol.

The last chunk type (255) is exhausted, reserved for future extension if
necessary.

13.2 IETF-defined Chunk Parameter Extension

The assignment of new chunk parameter type codes shall be allocated in the range 0x0000 is done through 0xFFFF.  Where an
extension code has been allocated, the format
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter must
conform to the following structure:

First word (32 bits):
  contains the parameter type code 0xFFFF and parameter length as
  described in section 3.2.1.

Second word:
  first octet MUST be all 1's (0xFF).  Next octet MUST be all 0's
  (0x00). Final two octets contain the allocated extension code
  value.

The Value portion of the parameter, if any, follows the second word.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|    Extension Type Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                    Value                                      /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the following information:

(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field. This
    structure MUST conform to the general type-length-value format
    described in Section 3.2.1.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
    and an indication of whether and under what circumstances
    multiple instances of this parameter type may be found within the
    same chunk.

13.3 IETF-defined Additional Error Causes

Additional cause codes may be allocated in the range 0x0004 11 to 0xFFFF
upon receipt of any permanently-available public 65535
through a Specification Required action as defined in [RFC2434].
Provided documentation
containing must include the following information:

(a) Name of the error condition.
(b) Detailed description of the conditions under which an SCTP
    endpoint should issue an Operation Error ERROR (or ABORT) with this cause code.
(c) Expected action by the SCTP endpoint which receives an Operation
    Error ERROR
    (or ABORT) chunk containing this cause code.
(d) Detailed description of the structure and content of data fields
    which accompany this cause code.

The initial word (32 bits) of a cause code parameter MUST conform to
the format shown in section 3.3.9, Section 3.3.10, i.e.:
 -- first two octets bytes contain the cause code value
 -- last two octets bytes contain length of the cause parameter.

Stewart, et al                                               [Page  91]

13.4 Cause Parameter.

13.3 Payload Protocol Identifiers

Except for value 0x00000000 0 which is reserved by SCTP to indicate the
absence of a an
unspecified payload protocol identifier in a DATA chunk, SCTP will
not be responsible for standardizing or verifying any payload protocol
identifiers; SCTP simply receives the identifier from the upper layer
and carries it with the corresponding payload data.

The upper layer, i.e, i.e., the SCTP user, SHOULD standardize any specific
protocol identifier with IANA if it is so desired. The use of any
specific payload protocol identifier is out of the scope of SCTP.

14. Suggested SCTP Protocol Parameter Values

The following protocol parameters are RECOMMENDED:

RTO.Initial              - 3  seconds
RTO.Min                  - 1  second
RTO.Max                 -  60 seconds
RTO.Alpha                - 1/8
RTO.Beta                 - 1/4
Valid.Cookie.Life        - 5 60  seconds
Association.Max.Retrans  - 10 attempts
Path.Max.Retrans         - 5  attempts (per destination address)
Max.Init.Retransmits     - 8  attempts

'retrans.count'          - counter (per destination address)
'receiver.buffer'
HB.interval              - variable (per peer endpoint) 30 seconds

  IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
  customize some of these protocol parameters (see Section 10).

  Note: RTO.Min SHOULD be set as recommended above.

15. Acknowledgments Acknowledgements

The authors wish to thank Mark Allman, R.J.Atkinson, Richard Band,
Scott Bradner, Steve Bellovin, Ram Dantu, R. Ezhirpavai, Mike Fisk,
Sally Floyd, Matt Holdrege, Henry Houh, Christian Huetima, Huitema, Gary
Lehecka, John Loughney, Daniel Luan, Thomas Narten, Erik Nordmark,
Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno
Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez,
A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their
invaluable comments.

Stewart, et al                                               [Page  92]

16.  Authors' Addresses

Randall R. Stewart                      Tel: +1-847-632-7438 +1-815-479-8536
Motorola, Inc.                          EMail: rstewar1@email.mot.com rstewart@flashcom.net
1501 W. Shure Drive, #2315
Arlington Heights, IL 60004
USA

Qiaobing Xie                            Tel: +1-847-632-3028
Motorola, Inc.                          EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA

Ken Morneault                           Tel: +1-703-484-3323
Cisco Systems Inc.                      EMail: kmorneau@cisco.com
13615 Dulles Technology Drive
Herndon, VA. 20171
USA

Chip Sharp                              Tel: +1-919-392-3121
Cisco Systems Inc.                      EMail:chsharp@cisco.com
7025 Kit Creek Road
Research Triangle Park, NC  27709
USA

Hanns Juergen Schwarzbauer              Tel: +49-89-722-24236
SIEMENS AG
Hofmannstr. 51
81359 Munich
Germany
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de

Tom Taylor                              Tel: +1-613-736-0961
Nortel Networks
1852 Lorraine Ave.
Ottawa, Ontario
Canada K1H 6Z8
EMail:taylor@nortelnetworks.com

Ian Rytina                              Tel: +61-3-9301-6164
Ericsson Australia                      EMail:ian.rytina@ericsson.com
37/360 Elizabeth Street
Melbourne, Victoria 3000
Australia

Malleswar Kalla                         Tel: +1-973-829-5212
Telcordia Technologies
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA
EMail: kalla@research.telcordia.com

Stewart, et al                                               [Page  93]

Lixia Zhang                             Tel: +1-310-825-2695
UCLA Computer Science Department        EMail: lixia@cs.ucla.edu
4531G Boelter Hall
Los Angeles, CA 90095-1596
USA

Vern Paxson                             Tel: +1-510-642-4274 x 302
ACIRI                                   EMail: vern@aciri.org
1947 Center St., Suite 600,
Berkeley, CA 94704-1198
USA

17. References

[1]  Eastlake , D. (ed.), "Randomness Recommendations for Security",
     RFC 1750, December 1994.

[2]  Deutsch, P., and Gailly, J-L., "ZLIB Compressed Data Format
     Specification version 3.3", RFC 1950, May 1996.

[3]  Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
     Control", RFC 2581, April 1999.

[4]  Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for
     Message Authentication", RFC 2104, March 1997.

[5]  Allman, M., and Paxson, V., "On Estimating End-to-End Network
     Path Properties", Proc. SIGCOMM'99, 1999.

[6]  Karn, P., and Simpson, W., "Photuris: Session-Key Management
     Protocol", RFC 2522, March 1999.

[7]  Bradner, S., "The Internet Standards Process -- Revision 3",
     RFC 2026, October 1996.

[8]  Postel, J. (ed.), "Transmission Control Protocol", RFC 793,
     September 1981.

[9] 90095-1596
USA

Vern Paxson                             Tel: +1-510-642-4274 x 302
ACIRI                                   EMail: vern@aciri.org
1947 Center St., Suite 600,
Berkeley, CA 94704-1198
USA

17. References

[RFC768]  Postel, J. (ed.), "User Datagram Protocol", RFC 768, August
          1980.

[10] Reynolds, J., and

[RFC793]  Postel, J. (ed.), "Assigned Numbers", "Transmission Control Protocol", RFC 1700, 793,
          September 1981.

[RFC1123] Braden, R., "Requirements for Internet hosts - application
          and support.", RFC 1123, October 1994.

[11] 1989.

[RFC1191] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191,
          November 1990.

[12]

[RFC1700] Reynolds, J., and Postel, J. (ed.), "Assigned Numbers",
          RFC 1700,

[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery
          for IP version 6", RFC 1981, August 1996.

[13]

[RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982,
          August 1996.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
          RFC 2026, October 1996.

[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the
          Internet Protocol", RFC 2401,  November 1998.

[RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.",
          RFC 2402, November 1998.

[RFC2406] S. Kent, R. Atkinson., "IP Encapsulating Security Payload
          (ESP)." RFC-2406, November 1998.

[RFC2408] D. Maughan, M. Schertler, M. Schneider, J. Turner.,
          "Internet Security Association and Key Management Protocol"
          RFC 2408, November 1998.

[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
          RFC 2409, November 1998.

[RFC2434] T. Narten, and H. Avestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs.", RFC2434,  October 1998.

[RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version
          6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
          Control", RFC 2581, April 1999. October 1994.

18. Bibliography

[ALLMAN99] Allman, M., and Paxson, V., "On Estimating End-to-End
           Network Path Properties", Proc. SIGCOMM'99, 1999.

[FALL96]   Fall, K., and Floyd, S., Simulation-based Comparisons of
           Tahoe, Reno, and SACK TCP, Computer Communications Review,
           V. 26 N. 3, July 1996, pp. 5-21.

[RFC1750]  Eastlake , D. (ed.), "Randomness Recommendations for
           Security", RFC 1750, December 1994.

[RFC1950]  Deutsch P., Gailly J-L., "ZLIB Compressed Data Format
           Specification version 3.3" , RFC1950, May 1996.

[RFC2104]  Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
           for Message Authentication", RFC 2104, March 1997.

[RFC2196]  Fraser, B. (ed.), "Site Security Handbook", RFC 2196,
           September 1997.

Stewart, et al                                               [Page  94]

[14] Kent, S.,

[RFC2522]  Karn, P., and Atkinson, R., "Security Architecture for the
     Internet Simpson, W., "Photuris: Session-Key Management
           Protocol", RFC 2401,  November 1998.

[15] 2522, March 1999.

[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
           "TCP Congestion Control with a Misbehaving Receiver",  ACM
           Computer Communication Review, 29(5), October 1999.

[16] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe,
     Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3,
     July 1996, pp. 5-21.

[17] Deering, S., and R. Hinden, "Internet Protocol, Version
     6 (IPv6) Specification", RFC 1883, December 1995.

[18] Bradner, S. "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

Appendix A: Explicit Congestion Notification

ECN (Ramakrishnan, k., Floyd, S., "Explicit Congestion Notification",
RFC 2481, January 1999) describes a proposed extension to IP that
details a method to become aware of congestion outside of datagram
loss. This is an optional feature that an implementation MAY choose to
add to SCTP. This appendix details the minor differences an implementor implementers
will need to be aware of if they choose to implement this feature.
In general RFC 2481 should be followed with the following exceptions.

Negotiation:

RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages
of a TCP connection. The sender of the SYN sets two bits in the
TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning
behind this is to assure both sides are truly ECN capable. For SCTP
this is not necessary. To indicate that an endpoint is ECN capable
a
an endpoint MAY SHOULD add to the INIT and or INIT-ACK message INIT ACK chunk the TLV
reserved for ECN. This TLV contains no parameters, and thus has
the following format:

   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 = 0x000a 32768      |     Parameter Length = 0x0004 4      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stewart, et al                                               [Page  95]

ECN-Echo:

RFC 2481 details a specific bit for a receiver to send back in its
acknowledgments
TCP acknowledgements to notify the sender of the Congestion Experienced

(CE) bit having arrived from the network. For SCTP this same indication
is made by including the ECNE chunk. This chunk contains one data
element, i.e. the lowest TSN associated with the IP datagram marked
with the CE bit, and looks as follows:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ID=00001100 Chunk Type=12 | Flags=00000000|    Chunk Length=0008 Length = 8           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Lowest TSN Number                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Note: The ECNE is considered a Control chunk.

CWR:

RFC 2481 details a specific bit for a sender to send in the header of
its next outbound datagram TCP segment to indicate to its peer that it has
reduced its congestion window. This is termed the CWR bit. For
SCTP the same indication is made by including the CWR chunk.
This chunk contains one data element, i.e. the TSN number that
was sent in the ECN-Echo. This element represents the lowest
TSN number in the datagram that was originally marked with the
CE bit.

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ID=00001101 Chunk Type=13 | Flags=00000000|    Chunk Length=0008 Length = 8           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Lowest TSN Number                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Note: The CWR is considered a Control chunk.

      This Internet Draft expires

Appendix B Alder 32 bit checksum calculation

The Adler-32 checksum calculation given in 6 months this appendix is copied from April, 2000

Stewart, et al                                              [Page  96]
[RFC1950].

Adler-32 is composed of two sums accumulated per byte: s1 is the sum
of all bytes, s2 is the sum of all s1 values. Both sums are done
modulo 65521. s1 is initialized to 1, s2 to zero.  The Adler-32
checksum is stored as s2*65536 + s1 in network byte order.

The following C code computes the Adler-32 checksum of a data buffer.
It is written for clarity, not for speed.  The sample code is in the
ANSI C programming language. Non C users may find it easier to read
with these hints:

   &      Bitwise AND operator.
   >>     Bitwise right shift operator. When applied to an
          unsigned quantity, as here, right shift inserts zero bit(s)
          at the left.
   <<     Bitwise left shift operator. Left shift inserts zero
          bit(s) at the right.
   ++     "n++" increments the variable n.
   %      modulo operator: a % b is the remainder of a divided by b.
    #define BASE 65521 /* largest prime smaller than 65536 */
    /*
      Update a running Adler-32 checksum with the bytes buf[0..len-1]
      and return the updated checksum. The Adler-32 checksum should be
      initialized to 1.

       Usage example:

         unsigned long adler = 1L;

         while (read_buffer(buffer, length) != EOF) {
           adler = update_adler32(adler, buffer, length);
         }
         if (adler != original_adler) error();
      */
      unsigned long update_adler32(unsigned long adler,
         unsigned char *buf, int len)
      {
        unsigned long s1 = adler & 0xffff;
        unsigned long s2 = (adler >> 16) & 0xffff;
        int n;

        for (n = 0; n < len; n++) {
          s1 = (s1 + buf[n]) % BASE;
          s2 = (s2 + s1)     % BASE;
        }
        return (s2 << 16) + s1;
      }

      /* Return the adler32 of the bytes buf[0..len-1] */
      unsigned long adler32(unsigned char *buf, int len)
      {
        return update_adler32(1L, buf, len);
      }