doc: Add RFC documents

1 files changed, 7507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2960.txt b/doc/rfc/rfc2960.txt
new file mode 100644
index 0000000..b9ad20c
--- /dev/null
+++ b/doc/rfc/rfc2960.txt
@@ -0,0 +1,7507 @@
+
+
+
+
+
+
+Network Working Group                                         R. Stewart
+Request for Comments: 2960                                        Q. Xie
+Category: Standards Track                                       Motorola
+                                                            K. Morneault
+                                                                C. Sharp
+                                                                   Cisco
+                                                         H. Schwarzbauer
+                                                                 Siemens
+                                                               T. Taylor
+                                                         Nortel Networks
+                                                               I. Rytina
+                                                                Ericsson
+                                                                M. Kalla
+                                                               Telcordia
+                                                                L. Zhang
+                                                                    UCLA
+                                                               V. Paxson
+                                                                   ACIRI
+                                                            October 2000
+
+
+                  Stream Control Transmission Protocol
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+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 transport protocol operating on top of 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 fragmentation to conform to discovered path MTU size,
+
+
+
+
+Stewart, et al.             Standards Track                     [Page 1]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      -- sequenced delivery of user messages within multiple streams,
+         with an option for order-of-arrival delivery of individual user
+         messages,
+      -- optional bundling of multiple user messages into a single SCTP
+         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.             Standards Track                     [Page 2]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+Table of Contents
+
+   1.  Introduction..................................................  5
+     1.1 Motivation..................................................  6
+     1.2 Architectural View of SCTP..................................  6
+     1.3 Functional View of SCTP.....................................  7
+       1.3.1 Association Startup and Takedown........................  8
+       1.3.2 Sequenced Delivery within Streams.......................  9
+       1.3.3 User Data Fragmentation.................................  9
+       1.3.4 Acknowledgement and Congestion Avoidance................  9
+       1.3.5 Chunk Bundling ......................................... 10
+       1.3.6 Packet Validation....................................... 10
+       1.3.7 Path Management......................................... 11
+     1.4 Key Terms................................................... 11
+     1.5 Abbreviations............................................... 15
+     1.6 Serial Number Arithmetic.................................... 15
+   2. Conventions.................................................... 16
+   3.  SCTP packet Format............................................ 16
+     3.1 SCTP Common Header Field Descriptions....................... 17
+     3.2 Chunk Field Descriptions.................................... 18
+       3.2.1 Optional/Variable-length Parameter Format............... 20
+     3.3 SCTP Chunk Definitions...................................... 21
+       3.3.1 Payload Data (DATA)..................................... 22
+       3.3.2 Initiation (INIT)....................................... 24
+         3.3.2.1 Optional or Variable Length Parameters.............. 26
+       3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
+         3.3.3.1 Optional or Variable Length Parameters.............. 33
+       3.3.4 Selective Acknowledgement (SACK)........................ 33
+       3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
+       3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
+       3.3.7 Abort Association (ABORT)............................... 39
+       3.3.8 Shutdown Association (SHUTDOWN)......................... 40
+       3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
+       3.3.10 Operation Error (ERROR)................................ 41
+         3.3.10.1 Invalid Stream Identifier.......................... 42
+         3.3.10.2 Missing Mandatory Parameter........................ 43
+         3.3.10.3 Stale Cookie Error................................. 43
+         3.3.10.4 Out of Resource.................................... 44
+         3.3.10.5 Unresolvable Address............................... 44
+         3.3.10.6 Unrecognized Chunk Type............................ 44
+         3.3.10.7 Invalid Mandatory Parameter........................ 45
+         3.3.10.8 Unrecognized Parameters............................ 45
+         3.3.10.9 No User Data....................................... 46
+         3.3.10.10 Cookie Received While Shutting Down............... 46
+       3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
+       3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
+       3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
+   4. SCTP Association State Diagram................................. 48
+
+
+
+Stewart, et al.             Standards Track                     [Page 3]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   5. Association Initialization..................................... 52
+     5.1 Normal Establishment of an Association...................... 52
+       5.1.1 Handle Stream Parameters................................ 54
+       5.1.2 Handle Address Parameters............................... 54
+       5.1.3 Generating State Cookie................................. 56
+       5.1.4 State Cookie Processing................................. 57
+       5.1.5 State Cookie Authentication............................. 57
+       5.1.6 An Example of Normal Association Establishment.......... 58
+     5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
+         and COOKIE ACK.............................................. 60
+       5.2.1 Handle Duplicate INIT in COOKIE-WAIT
+             or COOKIE-ECHOED States................................. 60
+       5.2.2 Unexpected INIT in States Other than CLOSED,
+             COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
+       5.2.3 Unexpected INIT ACK..................................... 61
+       5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
+         5.2.4.1 An Example of a Association Restart................. 64
+       5.2.5 Handle Duplicate COOKIE ACK............................. 66
+       5.2.6 Handle Stale COOKIE Error............................... 66
+     5.3 Other Initialization Issues................................. 67
+       5.3.1 Selection of Tag Value.................................. 67
+   6. User Data Transfer............................................. 67
+     6.1 Transmission of DATA Chunks................................. 69
+     6.2 Acknowledgement on Reception of DATA Chunks................. 70
+       6.2.1 Tracking Peer's Receive Buffer Space.................... 73
+     6.3 Management Retransmission Timer............................. 75
+       6.3.1 RTO Calculation......................................... 75
+       6.3.2 Retransmission Timer Rules.............................. 76
+       6.3.3 Handle T3-rtx Expiration................................ 77
+     6.4 Multi-homed SCTP Endpoints.................................. 78
+       6.4.1 Failover from Inactive Destination Address.............. 79
+     6.5 Stream Identifier and Stream Sequence Number................ 80
+     6.6 Ordered and Unordered Delivery.............................. 80
+     6.7 Report Gaps in Received DATA TSNs........................... 81
+     6.8 Adler-32 Checksum Calculation............................... 82
+     6.9 Fragmentation............................................... 83
+     6.10 Bundling .................................................. 84
+   7. Congestion Control   .......................................... 85
+     7.1 SCTP Differences from TCP Congestion Control................ 85
+     7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
+       7.2.1 Slow-Start.............................................. 87
+       7.2.2 Congestion Avoidance.................................... 89
+       7.2.3 Congestion Control...................................... 89
+       7.2.4 Fast Retransmit on Gap Reports.......................... 90
+     7.3 Path MTU Discovery.......................................... 91
+   8.  Fault Management.............................................. 92
+     8.1 Endpoint Failure Detection.................................. 92
+     8.2 Path Failure Detection...................................... 92
+
+
+
+Stewart, et al.             Standards Track                     [Page 4]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+     8.3 Path Heartbeat.............................................. 93
+     8.4 Handle "Out of the blue" Packets............................ 95
+     8.5 Verification Tag............................................ 96
+       8.5.1 Exceptions in Verification Tag Rules.................... 97
+   9. Termination of Association..................................... 98
+     9.1 Abort of an Association..................................... 98
+     9.2 Shutdown of an Association.................................. 98
+   10. Interface with Upper Layer....................................101
+     10.1 ULP-to-SCTP................................................101
+     10.2 SCTP-to-ULP................................................111
+   11. Security Considerations.......................................114
+     11.1 Security Objectives........................................114
+     11.2 SCTP Responses To Potential Threats........................115
+       11.2.1 Countering Insider Attacks.............................115
+       11.2.2 Protecting against Data Corruption in the Network......115
+       11.2.3 Protecting Confidentiality.............................115
+       11.2.4 Protecting against Blind Denial of Service Attacks.....116
+         11.2.4.1 Flooding...........................................116
+         11.2.4.2 Blind Masquerade...................................118
+         11.2.4.3 Improper Monopolization of Services................118
+     11.3 Protection against Fraud and Repudiation...................119
+   12. Recommended Transmission Control Block (TCB) Parameters.......120
+     12.1 Parameters necessary for the SCTP instance.................120
+     12.2 Parameters necessary per association (i.e. the TCB)........120
+     12.3 Per Transport Address Data.................................122
+     12.4 General Parameters Needed..................................123
+   13. IANA Considerations...........................................123
+     13.1 IETF-defined Chunk Extension...............................123
+     13.2 IETF-defined Chunk Parameter Extension.....................124
+     13.3 IETF-defined Additional Error Causes.......................124
+     13.4 Payload Protocol Identifiers...............................125
+   14. Suggested SCTP Protocol Parameter Values......................125
+   15. Acknowledgements..............................................126
+   16. Authors' Addresses............................................126
+   17. References....................................................128
+   18. Bibliography..................................................129
+   Appendix A .......................................................131
+   Appendix B .......................................................132
+   Full Copyright Statement .........................................134
+
+1. 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.
+
+
+
+
+
+Stewart, et al.             Standards Track                     [Page 5]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+1.1 Motivation
+
+   TCP [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
+   [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 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 within
+   the context of an association between two SCTP 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 endpoint
+
+
+
+Stewart, et al.             Standards Track                     [Page 6]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   (during association startup) with a list of transport addresses
+   (i.e., multiple IP addresses in combination with an SCTP port)
+   through which that endpoint can be reached and from which it will
+   originate SCTP packets.  The association spans transfers over all of
+   the possible source/destination combinations which may be generated
+   from each endpoint's lists.
+
+       _____________                                      _____________
+      |  SCTP User  |                                    |  SCTP User  |
+      | Application |                                    | Application |
+      |-------------|                                    |-------------|
+      |    SCTP     |                                    |    SCTP     |
+      |  Transport  |                                    |  Transport  |
+      |   Service   |                                    |   Service   |
+      |-------------|                                    |-------------|
+      |             |One or more    ----      One or more|             |
+      | IP Network  |IP address      \/        IP address| IP Network  |
+      |   Service   |appearances     /\       appearances|   Service   |
+      |_____________|               ----                 |_____________|
+
+        SCTP Node A |<-------- Network transport ------->| SCTP Node 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                     [Page 7]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+                           SCTP User Application
+
+         -----------------------------------------------------
+          _____________                  ____________________
+         |             |                | Sequenced delivery |
+         | Association |                |   within streams   |
+         |             |                |____________________|
+         |   startup   |
+         |             |         ____________________________
+         |     and     |        |    User Data Fragmentation |
+         |             |        |____________________________|
+         |   takedown  |
+         |             |         ____________________________
+         |             |        |     Acknowledgement        |
+         |             |        |          and               |
+         |             |        |    Congestion Avoidance    |
+         |             |        |____________________________|
+         |             |
+         |             |         ____________________________
+         |             |        |       Chunk Bundling       |
+         |             |        |____________________________|
+         |             |
+         |             |     ________________________________
+         |             |    |      Packet Validation         |
+         |             |    |________________________________|
+         |             |
+         |             |     ________________________________
+         |             |    |     Path Management            |
+         |_____________|    |________________________________|
+
+           Figure 2: Functional View of the SCTP Transport 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 Section 10).
+
+   A cookie mechanism, similar to one described by Karn and Simpson in
+   [RFC2522], is employed during the initialization to provide
+   protection against security attacks.  The cookie mechanism uses a
+   four-way handshake, the last two legs of which are allowed to carry
+   user data for fast setup.  The startup sequence is described in
+   Section 5 of this document.
+
+   SCTP provides for graceful close (i.e., shutdown) of an active
+   association on request from the SCTP user.  See the description of
+   the SHUTDOWN primitive in Section 10.  SCTP also allows ungraceful
+   close (i.e., abort), either on request from the user (ABORT
+
+
+
+Stewart, et al.             Standards Track                     [Page 8]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   primitive) or as a result of an error condition detected within the
+   SCTP layer.  Section 9 describes both the graceful and the ungraceful
+   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 that are to be delivered to the upper-layer protocol in
+   order with respect to other messages within the same stream.  This is
+   in contrast to its usage in TCP, where it refers to a sequence of
+   bytes (in this document a byte is assumed to be eight bits).
+
+   The SCTP user can specify at association startup time the number of
+   streams to be supported by the association.  This number is
+   negotiated with the remote end (see Section 5.1.1).  User messages
+   are associated with stream numbers (SEND, RECEIVE primitives, Section
+   10).  Internally, SCTP assigns a stream sequence number to each
+   message passed to it by the SCTP user.  On the receiving side, SCTP
+   ensures that messages are delivered to the SCTP user in sequence
+   within a given stream.  However, while one stream may be blocked
+   waiting for the next in-sequence user message, delivery from other
+   streams may proceed.
+
+   SCTP provides a mechanism for bypassing the sequenced delivery
+   service.  User messages sent using this mechanism are delivered to
+   the SCTP user as soon as they are received.
+
+1.3.3 User Data Fragmentation
+
+   When needed, SCTP fragments user messages to ensure that the SCTP
+   packet passed to the lower layer conforms to the path MTU.  On
+   receipt, fragments are reassembled into complete messages before
+   being passed to the SCTP user.
+
+1.3.4 Acknowledgement and Congestion Avoidance
+
+   SCTP assigns a Transmission Sequence Number (TSN) to each user data
+   fragment or unfragmented message.  The TSN is independent of any
+   stream sequence number assigned at the stream level.  The receiving
+
+
+
+
+
+
+Stewart, et al.             Standards Track                     [Page 9]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   end acknowledges all TSNs received, even if there are gaps in the
+   sequence.  In this way, reliable delivery is kept functionally
+   separate from sequenced stream delivery.
+
+   The acknowledgement and congestion avoidance function is responsible
+   for packet retransmission when timely acknowledgement has not been
+   received.  Packet retransmission is conditioned by congestion
+   avoidance procedures similar to those used for TCP.  See Sections 6
+   and 7 for a detailed description of the protocol procedures
+   associated with this function.
+
+1.3.5 Chunk Bundling
+
+   As described in Section 3, the SCTP packet as delivered to the lower
+   layer consists of a common header followed by one or more chunks.
+   Each chunk may contain either user data or SCTP control information.
+   The SCTP user has the option to request bundling of more than one
+   user messages into a single SCTP packet.  The chunk bundling function
+   of SCTP is responsible for assembly of the complete SCTP packet and
+   its disassembly at the receiving end.
+
+   During times of congestion an SCTP implementation MAY still perform
+   bundling even if the user has requested that SCTP not bundle.  The
+   user's disabling of bundling only affects SCTP implementations that
+   may delay a small period of time before transmission (to attempt to
+   encourage bundling).  When the user layer disables bundling, this
+   small delay is prohibited but not bundling that is performed during
+   congestion or retransmission.
+
+1.3.6 Packet Validation
+
+   A mandatory Verification Tag field and a 32 bit checksum field (see
+   Appendix B for a description of the Adler-32 checksum) are included
+   in the SCTP common header.  The Verification Tag value is chosen by
+   each end of the association during association startup.  Packets
+   received without the expected Verification Tag value are discarded,
+   as a protection against blind masquerade attacks and against stale
+   SCTP packets from a previous association.  The Adler-32 checksum
+   should be set by the sender of each SCTP packet to provide additional
+   protection against data corruption in the network.  The receiver of
+   an SCTP packet with an invalid Adler-32 checksum silently discards
+   the packet.
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 10]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+1.3.7 Path Management
+
+   The sending SCTP user is able to manipulate the set of transport
+   addresses used as destinations for SCTP packets through the
+   primitives described in Section 10.  The SCTP path management
+   function chooses the destination transport address for each outgoing
+   SCTP packet based on the SCTP user's instructions and the currently
+   perceived reachability status of the eligible destination set.  The
+   path management function monitors reachability through heartbeats
+   when other packet traffic is inadequate to provide this information
+   and advises the SCTP user when reachability of any far-end transport
+   address changes.  The path management function is also responsible
+   for reporting the eligible set of local transport addresses to the
+   far end during association startup, and for reporting the transport
+   addresses returned from the far end to the SCTP user.
+
+   At association start-up, a primary path is defined for each SCTP
+   endpoint, and is used for normal sending of SCTP packets.
+
+   On the receiving end, the path management is responsible for
+   verifying the existence of a valid SCTP association to which the
+   inbound SCTP packet belongs before passing it for further processing.
+
+   Note: Path Management and Packet Validation are done at the same
+   time, so although described separately above, in reality they cannot
+   be performed as separate items.
+
+1.4 Key Terms
+
+   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  Active destination transport address: A transport address on a
+      peer endpoint which a transmitting endpoint considers available
+      for receiving user messages.
+
+   o  Bundling: An optional multiplexing operation, whereby more than
+      one user message may be carried in the same SCTP packet.  Each
+      user message occupies its own DATA chunk.
+
+   o  Chunk: A unit of information within an SCTP packet, consisting of
+      a chunk header and chunk-specific content.
+
+   o  Congestion Window (cwnd): An SCTP variable that limits the data,
+      in number of bytes, a sender can send to a particular destination
+      transport address before receiving an acknowledgement.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 11]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  Cumulative TSN Ack Point: The TSN of the last DATA chunk
+      acknowledged via the Cumulative TSN Ack field of a SACK.
+
+   o  Idle destination address: An address that has not had user
+      messages sent to it within some length of time, normally the
+      HEARTBEAT interval or greater.
+
+   o  Inactive destination transport address: An address which is
+      considered inactive due to errors and unavailable to transport
+      user messages.
+
+   o  Message = user message:  Data submitted to SCTP by the Upper Layer
+      Protocol (ULP).
+
+   o  Message Authentication Code (MAC):  An integrity check mechanism
+      based on cryptographic hash functions using a secret key.
+      Typically, message authentication codes are used between two
+      parties that share a secret key in order to validate information
+      transmitted between these parties.  In SCTP it is used by an
+      endpoint to validate the State Cookie information that is returned
+      from the peer in the COOKIE ECHO chunk.  The term "MAC" has
+      different meanings in different contexts.  SCTP 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 message that is delivered in order with
+      respect to all previous user messages sent within the stream the
+      message was sent on.
+
+   o  Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
+      DATA chunk) that has been sent by the endpoint but for which it
+      has not yet received an acknowledgement.
+
+   o  Path: The route taken by the SCTP packets sent by one SCTP
+      endpoint to a specific destination transport address of its peer
+      SCTP endpoint.  Sending to different destination transport
+      addresses does not necessarily guarantee getting separate paths.
+
+   o  Primary Path: The primary path is the destination and source
+      address that will be put into a packet outbound to the peer
+      endpoint by default.  The definition includes the source address
+      since an implementation MAY wish to specify both destination and
+      source address to better control the return path taken by reply
+      chunks and on which interface the packet is transmitted when the
+      data sender is multi-homed.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 12]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  Receiver Window (rwnd): An SCTP variable a data sender uses to
+      store the most recently calculated receiver window of its peer, in
+      number of bytes.  This gives the sender an indication of the space
+      available in the receiver's inbound buffer.
+
+   o  SCTP association: A protocol relationship between SCTP endpoints,
+      composed of the two SCTP endpoints and protocol state information
+      including Verification Tags and the currently active set of
+      Transmission Sequence Numbers (TSNs), etc.  An association can be
+      uniquely identified by the 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 SCTP endpoint is represented to its peers as
+      a combination of a set of eligible destination 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.  A transport
+      address used by an SCTP endpoint must not be used by another SCTP
+      endpoint.  In other words, a transport address is unique to an
+      SCTP endpoint.
+
+   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 bytes.
+
+   o  Stream: A uni-directional logical channel established from one to
+      another associated SCTP endpoint, within which all user messages
+      are delivered in sequence except for those submitted to 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 these
+   correlations if they are so desired.
+
+
+
+Stewart, et al.             Standards Track                    [Page 13]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  Stream Sequence Number: A 16-bit sequence number used 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  Tie-Tags: Verification Tags from a previous association.  These
+      Tags are used within a State Cookie so that the newly restarting
+      association can be linked to the original association within the
+      endpoint that did not restart.
+
+   o  Transmission Control Block (TCB): An internal data structure
+      created by an SCTP endpoint for each of its existing SCTP
+      associations to other SCTP endpoints.  TCB contains all the status
+      and 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 containing
+      user data to permit the receiving SCTP 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 case of SCTP running over IP, a
+      transport address is defined by the combination of an IP address
+      and an SCTP port number (where SCTP is the Transport protocol).
+
+   o Unacknowledged TSN (at an SCTP 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 opposite case,
+      for a packet that has been sent but no acknowledgement has been
+      received.
+
+   o  Unordered Message: Unordered messages are "unordered" with respect
+      to any other message, this 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 same
+      stream.
+
+   o  User message: The unit of data delivery across the interface
+      between SCTP and its user.
+
+   o  Verification Tag: A 32 bit unsigned integer that is randomly
+      generated.  The Verification Tag provides a key that allows a
+      receiver to verify that the SCTP packet belongs to the current
+      association and is not an old or stale packet from a previous
+      association.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 14]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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 actual Transmission Sequence
+   Number space is finite, though very large.  This space ranges from 0
+   to 2**32 - 1. Since the space is finite, all arithmetic dealing with
+   Transmission Sequence Numbers must be performed modulo 2**32.  This
+   unsigned arithmetic preserves the relationship of sequence numbers as
+   they cycle from 2**32 - 1 to 0 again.  There are some subtleties to
+   computer modulo arithmetic, so great care should be taken in
+   programming the comparison of such values.  When referring to TSNs,
+   the symbol "=<" means "less than or equal"(modulo 2**32).
+
+   Comparisons and arithmetic on TSNs in this document SHOULD use Serial
+   Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
+
+   An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more
+   than 2**31 - 1 above the beginning TSN of its current send window.
+   Doing so will cause problems in comparing TSNs.
+
+   Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
+   That is, the next TSN a DATA chunk MUST use after transmitting TSN =
+   2*32 - 1 is TSN = 0.
+
+   Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
+   Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 15]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   All other arithmetic and comparisons in this document uses 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Common Header                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Chunk #1                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           ...                                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Chunk #n                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Multiple chunks can be bundled into one SCTP packet up to the MTU
+   size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks.
+   These chunks MUST NOT be bundled with any other chunk in a packet.
+   See Section 6.10 for more details on chunk bundling.
+
+   If a user data message doesn't fit into one SCTP packet it can be
+   fragmented into multiple chunks using the procedure defined in
+   Section 6.9.
+
+   All integer fields in an SCTP packet MUST be transmitted in network
+   byte order, unless otherwise stated.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 16]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.1 SCTP Common Header Field 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 (unsigned integer)
+
+      This is the SCTP sender's port number.  It can be used by the
+      receiver in combination with the source IP address, the SCTP
+      destination port and possibly the destination IP address to
+      identify the association to which this packet belongs.
+
+   Destination Port Number: 16 bits (unsigned integer)
+
+      This is the SCTP port number to which this packet is destined.
+      The receiving host will use this port number to de-multiplex the
+      SCTP packet to the correct receiving endpoint/application.
+
+   Verification Tag: 32 bits (unsigned integer)
+
+      The receiver of this packet uses the Verification Tag to validate
+      the sender of this SCTP packet.  On transmit, the value of this
+      Verification Tag MUST be set to the value of the Initiate Tag
+      received from the peer endpoint during the association
+      initialization, with the following exceptions:
+
+      -  A packet containing an INIT chunk MUST have a zero 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 8.4 and 8.5.
+
+   An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 17]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Checksum: 32 bits (unsigned integer)
+
+         This field contains the checksum of this SCTP packet.  Its
+         calculation is discussed in Section 6.8.  SCTP uses the Adler-
+         32 algorithm as described in Appendix B for calculating the
+         checksum
+
+3.2  Chunk Field Descriptions
+
+   The figure below illustrates the field format for the chunks to be
+   transmitted in the SCTP packet.  Each chunk is formatted with a 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Chunk Type  | Chunk  Flags  |        Chunk Length           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                          Chunk Value                          /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Chunk Type: 8 bits (unsigned integer)
+
+      This field identifies the type of information contained in the
+      Chunk Value field.  It takes a value from 0 to 254.  The value of
+      255 is reserved for future use as an extension field.
+
+   The values of 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)
+
+
+
+Stewart, et al.             Standards Track                    [Page 18]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   14         - Shutdown Complete (SHUTDOWN COMPLETE)
+   15 to 62   - reserved by IETF
+   63         - IETF-defined Chunk Extensions
+   64 to 126  - reserved by 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 highest-order two bits specify
+   the action that must be taken if the processing endpoint does not
+   recognize the Chunk Type.
+
+   00 - Stop processing this SCTP packet and discard it, do not process
+        any further chunks within it.
+
+   01 - Stop processing this SCTP packet and discard it, do not process
+        any further chunks within it, and report the unrecognized
+        parameter in an 'Unrecognized Parameter Type' (in either an
+        ERROR or in the INIT ACK).
+
+   10 - Skip this chunk and continue processing.
+
+   11 - Skip this chunk and continue processing, but report in an ERROR
+        Chunk using the 'Unrecognized Chunk Type' cause of error.
+
+   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.
+      Therefore, if the Chunk Value field is zero-length, the Length
+      field will be set to 4.  The Chunk Length field does not count any
+      padding.
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 19]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Chunk Value: 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 Chunk Type.
+
+   The total length of a chunk (including Type, Length and Value fields)
+   MUST be a multiple of 4 bytes.  If the length of the chunk is not a
+   multiple of 4 bytes, the sender MUST pad the chunk with all zero
+   bytes and this padding is not included in the chunk length field.
+   The sender should never pad with more than 3 bytes.  The receiver
+   MUST ignore the padding bytes.
+
+   SCTP defined chunks are described in detail in Section 3.3.  The
+   guidelines for IETF-defined chunk extensions can be found in Section
+   13.1 of this document.
+
+3.2.1  Optional/Variable-length Parameter Format
+
+   Chunk values of 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 chunk are
+   defined in a Type-Length-Value format as shown below.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Parameter Type       |       Parameter Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                       Parameter Value                         /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Chunk Parameter Type:  16 bits (unsigned integer)
+
+      The Type field is a 16 bit identifier of the type of parameter.
+      It takes a value of 0 to 65534.
+
+      The value of 65535 is reserved for IETF-defined extensions. Values
+      other than those defined in specific SCTP chunk description are
+      reserved for use by IETF.
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 20]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Chunk Parameter Length:  16 bits (unsigned integer)
+
+      The Parameter Length field contains the size of the parameter in
+      bytes, including the Parameter Type, Parameter Length, and
+      Parameter Value fields.  Thus, a parameter with a zero-length
+      Parameter Value field would have a Length field of 4.  The
+      Parameter Length does not include any padding bytes.
+
+   Chunk Parameter Value: variable-length.
+
+      The Parameter Value field contains the actual information to be
+      transferred in the parameter.
+
+   The total length of a parameter (including Type, Parameter Length and
+   Value fields) MUST be a multiple of 4 bytes.  If the length of the
+   parameter is not a multiple of 4 bytes, the sender pads the Parameter
+   at the end (i.e., after the Parameter Value field) with all zero
+   bytes.  The length of the padding is not included in the parameter
+   length field.  A sender SHOULD NOT pad with more than 3 bytes.  The
+   receiver MUST ignore the 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 an
+        ERROR or in the INIT ACK).
+
+   10 - Skip this parameter and continue processing.
+
+   11 - Skip this parameter and continue processing but report the
+        unrecognized parameter in an 'Unrecognized Parameter Type' (in
+        either an 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.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 21]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.1 Payload Data (DATA) (0)
+
+   The following format MUST be used for the DATA chunk:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 0    | Reserved|U|B|E|    Length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              TSN                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Stream Identifier S      |   Stream Sequence Number n    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Payload Protocol Identifier                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                 User Data (seq n of Stream S)                 /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Reserved: 5 bits
+
+      Should be set to all '0's and ignored by the receiver.
+
+   U bit: 1 bit
+
+      The (U)nordered bit, if set to '1', 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.
+
+      After re-assembly (if necessary), unordered DATA chunks MUST be
+      dispatched to the upper layer by the receiver without any attempt
+      to re-order.
+
+      If an unordered user message is fragmented, each fragment of the
+      message MUST have its U bit set to '1'.
+
+   B bit: 1 bit
+
+      The (B)eginning fragment bit, if set, indicates the first fragment
+      of a user message.
+
+   E bit:  1 bit
+
+      The (E)nding fragment bit, if set, indicates the last fragment of
+      a user message.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 22]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   An unfragmented user message shall have both the B and E bits set to
+   '1'.  Setting both B and E bits to '0' indicates a middle fragment of
+   a multi-fragment user message, as summarized in the following table:
+
+            B E                  Description
+         ============================================================
+         |  1 0 | First piece of a fragmented user message          |
+         +----------------------------------------------------------+
+         |  0 0 | Middle piece of a fragmented user message         |
+         +----------------------------------------------------------+
+         |  0 1 | Last piece of a fragmented user message           |
+         +----------------------------------------------------------+
+         |  1 1 | Unfragmented Message                              |
+         ============================================================
+         |             Table 1: Fragment Description Flags          |
+         ============================================================
+
+   When a user message is fragmented into multiple chunks, the TSNs are
+   used by the receiver to reassemble the message.  This means that the
+   TSNs for each fragment of a fragmented user message MUST be strictly
+   sequential.
+
+   Length:  16 bits (unsigned integer)
+
+      This field indicates the length of the DATA chunk in bytes from
+      the beginning of the type field to the end of the user data field
+      excluding any padding.  A DATA chunk with no user data field will
+      have Length set to 16 (indicating 16 bytes).
+
+   TSN : 32 bits (unsigned integer)
+
+      This value represents the TSN for this DATA chunk.  The valid
+      range of TSN is from 0 to 4294967295 (2**32 - 1).  TSN wraps back
+      to 0 after reaching 4294967295.
+
+   Stream Identifier S: 16 bits (unsigned integer)
+
+      Identifies the stream to which the following user data belongs.
+
+   Stream Sequence Number n: 16 bits (unsigned integer)
+
+      This value represents the stream sequence number of the following
+      user data within the stream S.  Valid range is 0 to 65535.
+
+      When a user message is fragmented by SCTP for transport, the same
+      stream sequence number MUST be carried in each of the fragments of
+      the message.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 23]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Payload Protocol Identifier: 32 bits (unsigned integer)
+
+      This value represents an application (or upper layer) 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
+      padding MUST NOT be included in the 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 1    |  Chunk Flags  |      Chunk Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Initiate Tag                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Advertised Receiver Window Credit (a_rwnd)          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Number of Outbound Streams   |  Number of Inbound Streams    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Initial TSN                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /              Optional/Variable-Length Parameters              /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The INIT chunk contains the following parameters.  Unless otherwise
+   noted, each parameter MUST only be included once in the INIT chunk.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 24]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+         Fixed Parameters                     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 Address (Note 1)               Optional    5
+         IPv6 Address (Note 1)               Optional    6
+         Cookie Preservative                 Optional    9
+         Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
+         Host Name Address (Note 3)          Optional    11
+         Supported Address Types (Note 4)    Optional    12
+
+   Note 1: The INIT chunks can contain multiple addresses that can 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 MUST NOT combine
+   any other address types with the Host Name address in the INIT.  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 type.
+
+   The Chunk Flags field in INIT is reserved and all bits in it should
+   be set to 0 by the sender and ignored by the receiver.  The sequence
+   of parameters within an INIT can be processed in any order.
+
+   Initiate Tag: 32 bits (unsigned integer)
+
+      The receiver of the INIT (the responding end) records the value of
+      the Initiate Tag parameter.  This value MUST be placed into the
+      Verification Tag field of every SCTP packet that the receiver of
+      the INIT transmits within this association.
+
+      The Initiate Tag is allowed to have any value except 0.  See
+      Section 5.3.1 for more on the selection of the tag value.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 25]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      If the value of the Initiate Tag in a received INIT chunk is found
+      to be 0, the receiver MUST treat it as an error and close the
+      association by transmitting an ABORT.
+
+   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
+      integer)
+
+      This value represents the dedicated buffer space, in number of
+      bytes, the sender of the INIT has reserved in association with
+      this window.  During the life of the 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.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 26]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   IPv4 Address Parameter (5)
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Type = 5               |      Length = 8               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        IPv4 Address                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   IPv4 Address: 32 bits (unsigned integer)
+
+      Contains an IPv4 address of the sending endpoint.  It is binary
+      encoded.
+
+   IPv6 Address Parameter (6)
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Type = 6           |          Length = 20          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                         IPv6 Address                          |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IPv6 Address: 128 bit (unsigned integer)
+
+      Contains an IPv6 address of the sending endpoint.  It is 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 Source Port Number in the SCTP common header,
+      the value passed in an IPv4 or IPv6 Address parameter indicates a
+      transport address the sender of the INIT will support for the
+      association being initiated.  That is, during the lifetime of this
+      association, this IP address can appear in the source address
+      field of an IP datagram sent from the sender of the INIT, and can
+      be used as a destination address of an IP datagram sent from the
+      receiver of the INIT.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 27]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      More than one IP Address parameter can be included in an INIT
+      chunk when the INIT sender is 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Type = 9             |          Length = 8           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Suggested Cookie Life-span Increment (msec.)          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Suggested Cookie Life-span Increment: 32 bits (unsigned integer)
+
+      This parameter indicates to the receiver how much increment in
+      milliseconds the sender wishes the receiver to add to its default
+      cookie life-span.
+
+      This optional parameter should be added to the INIT chunk by the
+      sender when it re-attempts establishing an association with a peer
+      to which its previous attempt of establishing the association failed
+      due to a stale cookie operation error.  The receiver MAY choose to
+      ignore the suggested cookie life-span increase for its own security
+      reasons.
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 28]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Host Name Address (11)
+
+      The sender of INIT uses this parameter to pass its Host Name (in
+      place of its IP addresses) to its peer.  The peer is responsible
+      for resolving the name.  Using this parameter might make it more
+      likely for the association to work across a 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 host name is
+      out of scope of SCTP.
+
+      Note: At least one null terminator is included in the Host Name
+      string and must be included in the length.
+
+   Supported Address Types (12)
+
+      The sender of INIT uses this parameter to list all the 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 Type #1        |        Address Type #2        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        ......
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Address Type: 16 bits (unsigned integer)
+
+      This is filled with the type value of the corresponding address
+      TLV (e.g., IPv4 = 5, IPv6 = 6, Hostname = 11).
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 29]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.3 Initiation Acknowledgement (INIT ACK) (2):
+
+   The INIT ACK chunk is used to acknowledge the initiation of an SCTP
+   association.
+
+   The parameter part of INIT ACK is formatted similarly to the INIT
+   chunk.  It uses two extra variable parameters: The State Cookie and
+   the Unrecognized Parameter:
+
+   The format of the INIT 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              /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Initiate Tag: 32 bits (unsigned integer)
+
+      The receiver of the INIT ACK records the value of the Initiate Tag
+      parameter.  This value MUST be placed into the Verification Tag
+      field of every SCTP packet that the INIT ACK receiver transmits
+      within this association.
+
+      The Initiate Tag MUST NOT take the value 0.  See Section 5.3.1 for
+      more on the selection of the Initiate Tag value.
+
+      If the value of the Initiate Tag in a received INIT ACK chunk is
+      found to be 0, the receiver MUST treat it as an error and close
+      the association by transmitting an ABORT.
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 30]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
+   integer)
+
+      This value represents the dedicated buffer space, in number of
+      bytes, the sender of the INIT ACK has reserved in association with
+      this window.  During the life of the association this buffer space
+      SHOULD not be lessened (i.e. dedicated buffers taken away from
+      this association).
+
+   Number of Outbound Streams (OS):  16 bits (unsigned integer)
+
+      Defines the number of outbound streams the sender of this INIT ACK
+      chunk wishes to create in this association.  The value of 0 MUST
+      NOT be used.
+
+      Note: A receiver of an INIT ACK  with the OS value set to 0 SHOULD
+      destroy the association discarding its TCB.
+
+   Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
+
+      Defines the maximum number of streams the sender of this INIT ACK
+      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 ACK  with the MIS value set to 0
+      SHOULD destroy the association discarding its TCB.
+
+   Initial TSN (I-TSN) : 32 bits (unsigned integer)
+
+      Defines the initial TSN that the INIT-ACK sender will use.  The
+      valid range is from 0 to 4294967295.  This field MAY be set to the
+      value of the Initiate Tag field.
+
+      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.             Standards Track                    [Page 31]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      Variable Parameters                  Status     Type Value
+      -------------------------------------------------------------
+      State Cookie                        Mandatory   7
+      IPv4 Address (Note 1)               Optional    5
+      IPv6 Address (Note 1)               Optional    6
+      Unrecognized Parameters             Optional    8
+      Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
+      Host Name Address (Note 3)          Optional    11
+
+   Note 1: The INIT ACK chunks can contain any number of IP address
+   parameters 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: The INIT ACK chunks MUST NOT contain more than one Host Name
+   address parameter.  Moreover, the sender of the INIT ACK MUST NOT
+   combine any other address types with the Host Name address in the
+   INIT ACK.  The receiver of the INIT ACK MUST ignore any other address
+   types if the 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
+   variable size of the state cookie AND the variable address list.  For
+   example if a responder to the INIT has 1000 IPv4 addresses it wishes
+   to send, it would need at least 8,000 bytes to encode this in the
+   INIT ACK.
+
+   In combination with the Source Port carried in the SCTP common
+   header, each IP Address parameter in the INIT ACK indicates to the
+   receiver of the INIT ACK a valid transport address supported by the
+   sender of the INIT ACK for the lifetime of the association being
+   initiated.
+
+   If the INIT ACK contains at least one IP Address parameter, then the
+   source address of the IP datagram containing the INIT ACK and any
+   additional address(es) provided within the INIT ACK may be used as
+   destinations by the receiver of the INIT-ACK.  If the INIT ACK does
+   not contain any IP Address parameters, the receiver of the INIT-ACK
+   MUST use the source address associated with the received IP datagram
+   as its sole destination address for the association.
+
+   The State Cookie and Unrecognized Parameters use the Type-Length-
+   Value format as defined in Section 3.2.1 and are described below.
+   The other fields are defined the same as their counterparts in the
+   INIT chunk.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 32]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.3.1 Optional or Variable Length Parameters
+
+   State Cookie
+
+      Parameter Type Value: 7
+
+      Parameter Length:  variable size, depending on Size of Cookie
+
+      Parameter Value:
+
+         This parameter value MUST contain all the necessary state and
+         parameter information required for the sender of this INIT ACK
+         to create the association, along with a Message Authentication
+         Code (MAC).  See Section 5.1.3 for details on State Cookie
+         definition.
+
+   Unrecognized Parameters:
+
+      Parameter Type Value: 8
+
+      Parameter Length:  Variable Size.
+
+      Parameter Value:
+
+         This parameter is returned to the originator of the INIT chunk
+         when the INIT contains an unrecognized parameter which has a
+         value that indicates that it should be reported to the sender.
+         This parameter value field will contain unrecognized parameters
+         copied from the INIT chunk complete with Parameter Type, Length
+         and Value fields.
+
+3.3.4 Selective Acknowledgement (SACK) (3):
+
+   This chunk is sent to the peer endpoint to acknowledge received DATA
+   chunks and to 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 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 its value.
+
+   The handling of a_rwnd by the receiver of the SACK is discussed in
+   detail in Section 6.2.1.
+
+
+
+Stewart, et al.             Standards Track                    [Page 33]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
+   Block acknowledges a 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 3    |Chunk  Flags   |      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        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      \                              ...                              \
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Gap Ack 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 TSN of the last DATA chunk received in
+      sequence before a gap.
+
+   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
+      integer)
+
+      This field indicates the updated receive buffer space in bytes of
+      the sender of this SACK, see Section 6.2.1 for details.
+
+
+
+Stewart, et al.             Standards Track                    [Page 34]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Number of Gap Ack Blocks: 16 bits (unsigned integer)
+
+      Indicates the number of Gap Ack Blocks included in this SACK.
+
+   Number of Duplicate TSNs: 16 bit
+
+      This field contains the number of duplicate TSNs the endpoint has
+      received.  Each duplicate TSN is listed following the Gap Ack
+      Block list.
+
+   Gap Ack Blocks:
+
+      These fields contain the Gap Ack Blocks.  They are repeated for
+      each Gap Ack Block up to the number of Gap Ack Blocks defined in
+      the Number of Gap Ack Blocks field.  All DATA chunks with TSNs
+      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
+      Start) and less than or equal to (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 Start offset TSN for this Gap Ack Block.  To
+      calculate the actual TSN number the Cumulative TSN Ack is added to
+      this offset number.  This calculated TSN identifies the first TSN
+      in this Gap Ack Block that has been received.
+
+   Gap Ack Block End:  16 bits (unsigned integer)
+
+      Indicates the End offset TSN for this Gap Ack Block.  To calculate
+      the actual TSN number the Cumulative TSN Ack is added to this
+      offset number.  This calculated TSN identifies the TSN of the last
+      DATA chunk received in 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,
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 35]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+                        ----------
+                        | 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 constructed as follows
+   (assuming the new a_rwnd is set to 4660 by the 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 number of times a TSN was received in duplicate
+      since the 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 after
+      sending each SACK.
+
+      For example, if a receiver were to get the TSN 19 three times it
+      would list 19 twice in the outbound SACK.  After sending the SACK
+      if it received yet one more TSN 19 it would list 19 as a duplicate
+      once in the next outgoing SACK.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 36]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.5 Heartbeat Request (HEARTBEAT) (4):
+
+   An endpoint should send this chunk to its peer endpoint to probe the
+   reachability of a particular destination transport address defined in
+   the present association.
+
+   The parameter field contains the 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 4    | Chunk  Flags  |      Heartbeat Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /            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 bytes, including the chunk header
+      and the Heartbeat Information field.
+
+   Heartbeat Information: variable length
+
+      Defined as a variable-length parameter using the format described
+      in Section 3.2.1, i.e.:
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Heartbeat Info Type=1      |         HB Info Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                  Sender-specific Heartbeat Info               /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 37]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      The Sender-specific Heartbeat Info field should normally include
+      information about the sender's 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 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 bits (unsigned integer)
+
+      Set to the size of the chunk in bytes, including the chunk header
+      and the Heartbeat Information field.
+
+   Heartbeat Information: variable length
+
+      This field MUST contain the Heartbeat Information parameter of
+      the Heartbeat Request to which this Heartbeat Acknowledgement is
+      responding.
+
+      Variable Parameters                  Status     Type Value
+      -------------------------------------------------------------
+      Heartbeat Info                       Mandatory   1
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 38]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.7 Abort Association (ABORT) (6):
+
+   The ABORT chunk is sent to the peer of an association to close the
+   association.  The ABORT chunk may contain Cause Parameters to inform
+   the receiver the reason of the abort.  DATA chunks MUST NOT be
+   bundled with ABORT.  Control chunks (except for INIT, INIT ACK and
+   SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be
+   placed before the ABORT in the SCTP packet, or they will be ignored
+   by the receiver.
+
+   If an 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 6    |Reserved     |T|           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                   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 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.
+
+   Length:  16 bits (unsigned integer)
+
+      Set to the size of the chunk in bytes, including the chunk header
+      and all the Error Cause fields present.
+
+   See Section 3.3.10 for Error Cause definitions.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 39]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.8 Shutdown Association (SHUTDOWN) (7):
+
+   An endpoint in an association MUST use this chunk to initiate a
+   graceful close of the association with its peer.  This chunk 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 7    | Chunk  Flags  |      Length = 8               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Cumulative TSN Ack                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Chunk Flags: 8 bits
+
+      Set to zero on transmit and ignored on receipt.
+
+   Length:  16 bits (unsigned integer)
+
+      Indicates the length of the parameter.  Set to 8.
+
+   Cumulative TSN Ack: 32 bits (unsigned integer)
+
+      This parameter contains the TSN of the last chunk received in
+      sequence before any gaps.
+
+      Note:  Since the SHUTDOWN message does not contain Gap Ack Blocks,
+      it cannot be used to acknowledge TSNs received out of order.  In a
+      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 be used to acknowledge the receipt of the SHUTDOWN
+   chunk at the completion of 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 8    |Chunk  Flags   |      Length = 4               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Stewart, et al.             Standards Track                    [Page 40]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Chunk Flags:  8 bits
+
+      Set to zero on transmit and ignored on receipt.
+
+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 with an ABORT chunk to report a fatal condition.  It has the
+   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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Type = 9    | Chunk  Flags  |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                    one or more Error Causes                   /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Chunk Flags:  8 bits
+
+      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 chunk header
+      and all the Error Cause fields present.
+
+   Error causes are defined as variable-length parameters using the
+   format described in 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Cause Code          |       Cause Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                    Cause-specific Information                 /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Cause Code: 16 bits (unsigned integer)
+
+      Defines the type of error conditions being reported.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 41]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      Cause Code
+      Value           Cause Code
+      ---------      ----------------
+       1              Invalid Stream 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
+      10              Cookie Received While Shutting Down
+
+   Cause Length: 16 bits (unsigned integer)
+
+      Set to the size of the parameter in bytes, including the Cause
+      Code, Cause Length, and Cause-Specific Information fields
+
+   Cause-specific Information: variable length
+
+      This field carries the details of the error condition.
+
+   Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
+   Guidelines for the IETF to define new error cause values are
+   discussed in 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 Stream Identifier of the DATA chunk received in
+      error.
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 42]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Reserved: 16 bits
+
+      This field is reserved.  It is set to all 0's on transmit and
+      Ignored on receipt.
+
+3.3.10.2 Missing Mandatory Parameter (2)
+
+   Cause of error
+   ---------------
+   Missing Mandatory Parameter:  Indicates that one or more mandatory
+   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       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Number of Missing params:  32 bits (unsigned integer)
+
+      This field contains the number of parameters contained in the
+      Cause-specific Information field.
+
+   Missing Param Type:  16 bits (unsigned integer)
+
+      Each field will contain the missing mandatory parameter number.
+
+3.3.10.3 Stale Cookie Error (3)
+
+   Cause of error
+   --------------
+   Stale Cookie Error:  Indicates the receipt of a valid State Cookie
+   that has expired.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Cause Code=3              |       Cause Length=8          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Measure of Staleness (usec.)                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Measure of Staleness:  32 bits (unsigned integer)
+
+      This field contains the difference, in microseconds, between the
+      current time and the time the State Cookie expired.
+
+
+
+Stewart, et al.             Standards Track                    [Page 43]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      The sender of this error cause MAY choose to report how long past
+      expiration the State Cookie is by including a non-zero value in
+      the Measure of Staleness field.  If the sender does not wish to
+      provide this information it should set the Measure of Staleness
+      field to the value of zero.
+
+3.3.10.4 Out of Resource (4)
+
+   Cause of error
+   ---------------
+   Out of Resource: Indicates that the sender is out of resource.  This
+   is usually sent in combination with or within an ABORT.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Cause Code=4              |      Cause Length=4           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.3.10.5 Unresolvable Address (5)
+
+   Cause of error
+   ---------------
+   Unresolvable Address: Indicates that the sender is not able to
+   resolve the specified address parameter (e.g., type of address is not
+   supported by the sender).  This is usually sent in combination with
+   or within an ABORT.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Cause Code=5              |      Cause Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                  Unresolvable Address                         /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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 bits of the 'Chunk Type' are set to 01 or 11.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 44]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Cause Code=6              |      Cause Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                  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              |      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             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                  Unrecognized Parameters                      /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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.
+
+
+
+Stewart, et al.             Standards Track                    [Page 45]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.10.9 No 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.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     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.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Cause Code=10              |      Cause Length=4          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+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.
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 46]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+       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.
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 47]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (14):
+
+   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 = 14   |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 endpoint's
+   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.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 48]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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  |
+                       +---------------+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 49]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+                      (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
+                          |                   |
+
+
+
+Stewart, et al.             Standards Track                    [Page 50]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+                          |                   | (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 in queue 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).
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 51]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 52]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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.
+
+   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.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 53]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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.
+
+
+
+Stewart, et al.             Standards Track                    [Page 54]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      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 user data
+      (piggy-backed or stand-alone) to its peer until the host name is
+      successfully resolved.
+
+      If the name resolution is not successful, the endpoint MUST
+      immediately send an ABORT with "Unresolvable Address" error cause
+      to its peer.  The ABORT shall be sent to the 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 shall derive and record all the
+      transport address(es) from the received 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.
+
+      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.
+
+
+
+Stewart, et al.             Standards Track                    [Page 55]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 of INIT (initiatee) MUST
+   either use one of the address types indicated in the Supported
+   Address Types parameter when responding to the INIT, or abort the
+   association with an "Unresolvable Address" error cause if it is
+   unwilling or incapable of using any of the address types indicated by
+   its peer.
+
+   IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
+   fails to resolve the address parameter due to an unsupported type, it
+   can abort the initiation process and then attempt a re-initiation by
+   using a 'Supported Address Types' parameter in the new INIT to
+   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 sender
+   of INIT ACK creates a State Cookie and sends it in the 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 lifespan of the State
+   Cookie, along with all the information necessary for it to establish
+   the association.
+
+   The following steps SHOULD be taken to generate the State Cookie:
+
+   1) Create an association TCB using information from both the received
+      INIT and the outgoing INIT ACK chunk,
+
+   2) In the TCB, set the creation time to the current time of day, and
+      the lifespan to the protocol parameter 'Valid.Cookie.Life',
+
+   3) From the TCB, identify and collect the minimal subset of
+      information needed to re-create the TCB, and generate a MAC using
+      this subset of information and a secret key (see [RFC2104] for an
+      example of generating a MAC), and
+
+   4) Generate the State Cookie by combining this subset of information
+      and the resultant MAC.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 56]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   After sending the INIT ACK with the State Cookie parameter, the
+   sender SHOULD delete the TCB and any other local resource related to
+   the new association, so as to prevent resource attacks.
+
+   The hashing method used to generate the MAC is strictly a private
+   matter for the receiver of the INIT chunk.  The use of a MAC is
+   mandatory to prevent denial of service attacks.  The secret key
+   SHOULD be random ([RFC1750] provides some information on randomness
+   guidelines); it SHOULD be changed reasonably frequently, and the
+   timestamp in the State Cookie MAY be used to 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 endpoint (in the COOKIE WAIT state) receives an INIT ACK
+   chunk with a State Cookie parameter, it MUST immediately send a
+   COOKIE ECHO chunk to its peer with the received State Cookie.  The
+   sender MAY also add any pending DATA chunks to the packet after the
+   COOKIE ECHO chunk.
+
+   The endpoint shall also start the T1-cookie timer after sending out
+   the COOKIE ECHO chunk.  If the 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 CLOSED
+   state).
+
+5.1.5 State Cookie Authentication
+
+   When an endpoint receives a COOKIE ECHO chunk from another endpoint
+   with which it has no association, it shall take the following
+   actions:
+
+   1) Compute a MAC using the TCB data carried in the State Cookie and
+      the secret key (note the timestamp in the State 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 as one that it previously generated
+      by comparing the computed MAC against the one carried in the State
+      Cookie.  If this comparison fails, the SCTP packet, including the
+      COOKIE ECHO and any DATA chunks, should be silently discarded,
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 57]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   3) Compare the creation timestamp in the State Cookie to the current
+      local time.  If the elapsed time is longer than the lifespan
+      carried in the State Cookie, then the packet, including the COOKIE
+      ECHO and any attached DATA chunks, SHOULD be discarded and the
+      endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error
+      cause to the peer endpoint,
+
+   4) If the State Cookie is valid, create an association to the sender
+      of the 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 to the peer acknowledging reception of the
+      COOKIE ECHO.  The COOKIE ACK MAY be bundled with an outbound DATA
+      chunk or SACK chunk; however, the COOKIE ACK MUST be the first
+      chunk in the SCTP packet.
+
+   6) Immediately acknowledge any DATA chunk bundled with the COOKIE
+      ECHO with a SACK (subsequent DATA chunk acknowledgement should
+      follow the rules defined in Section 6.2).  As mentioned in step
+      5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
+      MUST appear first in the SCTP packet.
+
+   If a COOKIE ECHO is received from an endpoint with which the receiver
+   of the COOKIE ECHO has an existing association, the procedures in
+   Section 5.2 should be followed.
+
+5.1.6 An Example of Normal Association Establishment
+
+   In the following example, "A" initiates the association and then
+   sends a user message to "Z", then "Z" sends two user messages to "A"
+   later (assuming no bundling or fragmentation occurs):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 58]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Endpoint A                                          Endpoint Z
+   {app sets association with Z}
+   (build TCB)
+   INIT [I-Tag=Tag_A
+         & other info]  --------\
+   (Start T1-init timer)         \
+   (Enter COOKIE-WAIT state)      \---> (compose temp TCB and Cookie_Z)
+
+                                   /--- INIT ACK [Veri Tag=Tag_A,
+                                  /              I-Tag=Tag_Z,
+   (Cancel T1-init timer) <------/               Cookie_Z, & other info]
+                                        (destroy temp TCB)
+   COOKIE ECHO [Cookie_Z] ------\
+   (Start T1-init timer)         \
+   (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
+                                         state)
+
+
+                                  /---- COOKIE-ACK
+                                 /
+   (Cancel T1-init timer, <-----/
+    Enter ESTABLISHED state)
+   {app sends 1st user data; strm 0}
+   DATA [TSN=initial TSN_A
+       Strm=0,Seq=1 & user data]--\
+    (Start T3-rtx timer)            \
+                                     \->
+                                 /----- SACK [TSN Ack=init
+                                             TSN_A,Block=0]
+   (Cancel T3-rtx timer) <------/
+
+                                        ...
+                                        {app sends 2 messages;strm 0}
+                                  /---- DATA
+                                 /        [TSN=init TSN_Z
+                             <--/          Strm=0,Seq=1 & user data 1]
+   SACK [TSN Ack=init TSN_Z,      /---- DATA
+         Block=0]     --------\  /        [TSN=init TSN_Z +1,
+                               \/          Strm=0,Seq=2 & user data 2]
+                        <------/\
+                                 \
+                                  \------>
+
+                     Figure 4: INITiation Example
+
+   If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
+   chunks are sent, the same INIT or COOKIE ECHO chunk with the same
+   Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
+
+
+
+Stewart, et al.             Standards Track                    [Page 59]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   the timer restarted.  This shall be repeated Max.Init.Retransmits
+   times before "A" considers "Z" unreachable and reports the failure to
+   its upper layer (and thus the association enters the CLOSED state).
+   When retransmitting the INIT, the endpoint MUST follow the rules
+   defined in 6.3 to determine the proper timer value.
+
+5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
+   COOKIE ACK
+
+   During the lifetime of an association (in one of the possible
+   states), an endpoint may receive from its peer endpoint one of the
+   setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK).  The
+   receiver shall treat such a setup chunk as a duplicate and process it
+   as described in this section.
+
+   Note:  An endpoint will not receive the chunk unless the chunk was
+   sent to a SCTP transport address and is from a SCTP transport address
+   associated with this 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) Both sides are trying to initialize the association at about the
+      same time,
+
+   C) The chunk is from a stale packet that was used to establish the
+      present association or a past association that is no longer in
+      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 COOKIE-ECHOED State (Item B)
+
+   This usually indicates an initialization collision, i.e., each
+   endpoint is attempting, at about the same time, to establish an
+   association with the other endpoint.
+
+   Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
+   endpoint MUST respond with an INIT ACK using the same parameters it
+
+
+
+Stewart, et al.             Standards Track                    [Page 60]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   sent in its original INIT chunk (including its Initiation Tag,
+   unchanged).  These original parameters are combined with those from
+   the newly received INIT chunk.  The endpoint shall also generate a
+   State Cookie with the INIT ACK.  The endpoint uses the parameters
+   sent in its INIT to calculate the State Cookie.
+
+   After that, the endpoint MUST NOT change its state, the T1-init timer
+   shall be left running and the corresponding TCB MUST NOT be
+   destroyed.  The normal procedures for handling State Cookies when a
+   TCB exists will resolve the duplicate INITs to a single association.
+
+   For an endpoint that is in the COOKIE-ECHOED state it MUST populate
+   its Tie-Tags with the Tag information of itself and its peer (see
+   section 5.2.2 for a description of the Tie-Tags).
+
+5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
+         COOKIE-WAIT and SHUTDOWN-ACK-SENT
+
+   Unless otherwise stated, upon reception of an unexpected INIT for
+   this association, the endpoint shall generate an INIT ACK with a
+   State Cookie.  In the outbound INIT ACK the endpoint MUST copy its
+   current Verification Tag and peer's Verification Tag into a reserved
+   place within the state cookie.  We shall refer to these locations as
+   the Peer's-Tie-Tag and the Local-Tie-Tag.  The outbound SCTP packet
+   containing this INIT ACK MUST carry a Verification Tag value equal to
+   the Initiation Tag found in the unexpected INIT.  And the INIT ACK
+   MUST contain a new Initiation Tag (randomly generated see Section
+   5.3.1).  Other parameters for the endpoint SHOULD be copied from the
+   existing parameters of the association (e.g. number of outbound
+   streams) into the INIT ACK and cookie.
+
+   After sending out the INIT ACK, the endpoint shall take no further
+   actions, i.e., the existing association, including its current state,
+   and the corresponding TCB MUST NOT be changed.
+
+   Note: Only when a TCB exists and the association is not in a COOKIE-
+   WAIT state are the Tie-Tags populated.  For a normal association INIT
+   (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
+   set to 0 (indicating that no previous TCB existed).  The INIT ACK and
+   State Cookie are populated as specified in section 5.2.1.
+
+5.2.3 Unexpected INIT ACK
+
+   If an INIT ACK is received by an endpoint in any state other than the
+   COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk.
+   An unexpected INIT ACK usually indicates the processing of an old or
+   duplicated INIT chunk.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 61]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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 CLOSED state) the following
+   rules shall be applied:
+
+   1) Compute a MAC as described in Step 1 of Section 5.1.5,
+
+   2) Authenticate the State Cookie as described in Step 2 of Section
+      5.1.5 (this is case C or D above).
+
+   3) Compare the timestamp in the State Cookie to the current time.  If
+      the State Cookie is older than the lifespan carried in the State
+      Cookie and the Verification Tags contained in the State Cookie do
+      not match the current association's Verification Tags, the packet,
+      including the COOKIE ECHO and any DATA chunks, should be
+      discarded.  The endpoint also MUST transmit an ERROR chunk with a
+      "Stale Cookie" error cause to the peer endpoint (this is case C or
+      D in section 5.2).
+
+      If both Verification Tags in the State Cookie match the
+      Verification Tags of the current association, consider the State
+      Cookie valid (this is case E of section 5.2) even if the lifespan
+      is exceeded.
+
+   4) If the State Cookie proves to be valid, unpack the TCB into a
+      temporary TCB.
+
+   5) Refer to Table 2 to determine the correct action to be taken.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 62]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
++------------+------------+---------------+--------------+-------------+
+|  Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag|   Action/   |
+|            |            |               |              | Description |
++------------+------------+---------------+--------------+-------------+
+|    X       |     X      |      M        |      M       |     (A)     |
++------------+------------+---------------+--------------+-------------+
+|    M       |     X      |      A        |      A       |     (B)     |
++------------+------------+---------------+--------------+-------------+
+|    M       |     0      |      A        |      A       |     (B)     |
++------------+------------+---------------+--------------+-------------+
+|    X       |     M      |      0        |      0       |     (C)     |
++------------+------------+---------------+--------------+-------------+
+|    M       |     M      |      A        |      A       |     (D)     |
++======================================================================+
+|       Table 2: Handling of a COOKIE ECHO when a TCB exists           |
++======================================================================+
+
+   Legend:
+
+      X - Tag does not match the existing TCB
+      M - Tag matches the existing TCB.
+      0 - No Tie-Tag in Cookie (unknown).
+      A - All cases, i.e. M, X or 0.
+
+   Note: For any case not shown in Table 2, the cookie should be
+   silently discarded.
+
+   Action
+
+   A) In this case, the peer may have restarted.  When the endpoint
+      recognizes this potential 'restart', the existing session is
+      treated the 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 an implementation
+         specific option).
+
+      -  A notification of RESTART SHOULD be sent to the ULP instead of
+         a "COMMUNICATION LOST" notification.
+
+      All the 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 endpoint shall enter the ESTABLISHED state.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 63]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
+      the peer has restarted (Action A), it MUST NOT setup a new
+      association but instead resend the SHUTDOWN ACK and send an ERROR
+      chunk with a "Cookie Received while Shutting Down" error cause to
+      its peer.
+
+   B) In this case, both sides may be attempting to start an association
+      at about the same time but the peer endpoint started its INIT
+      after responding to the local endpoint's INIT.  Thus it may have
+      picked a new Verification Tag not being aware of the previous Tag
+      it had sent this endpoint.  The endpoint should stay in or enter
+      the ESTABLISHED state but it MUST update its peer's Verification
+      Tag from the State Cookie, stop any init or cookie timers that may
+      running and send a COOKIE ACK.
+
+   C) In this case, the local endpoint's cookie has arrived late.
+      Before it arrived, the local endpoint sent an INIT and received an
+      INIT-ACK and finally sent a COOKIE ECHO with the peer's same tag
+      but a new tag of its own.  The cookie should be silently
+      discarded.  The endpoint SHOULD NOT change states and should leave
+      any timers running.
+
+   D) When both local and remote tags match the endpoint should always
+      enter the ESTABLISHED state, if it has not already done so. It
+      should stop any init or cookie timers that may be running and send
+      a COOKIE ACK.
+
+   Note: The "peer's Verification Tag" is the tag received in the
+   Initiate Tag field of the INIT or INIT ACK chunk.
+
+5.2.4.1 An Example of a Association Restart
+
+   In the following example, "A" initiates the association after a
+   restart has occurred.  Endpoint "Z" had no knowledge of the restart
+   until the exchange (i.e. Heartbeats had not yet detected the failure
+   of "A").  (assuming no bundling or fragmentation occurs):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 64]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+Endpoint A                                          Endpoint Z
+<-------------- Association is established---------------------->
+Tag=Tag_A                                             Tag=Tag_Z
+<--------------------------------------------------------------->
+{A crashes and restarts}
+{app sets up a association with Z}
+(build TCB)
+INIT [I-Tag=Tag_A'
+      & other info]  --------\
+(Start T1-init timer)         \
+(Enter COOKIE-WAIT state)      \---> (find a existing TCB
+                                      compose temp TCB and Cookie_Z
+                                      with Tie-Tags to previous
+                                      association)
+                                /--- INIT ACK [Veri Tag=Tag_A',
+                               /               I-Tag=Tag_Z',
+(Cancel T1-init timer) <------/                Cookie_Z[TieTags=
+                                               Tag_A,Tag_Z
+                                                & other info]
+                                     (destroy temp TCB,leave original
+                                      in place)
+COOKIE ECHO [Veri=Tag_Z',
+             Cookie_Z
+             Tie=Tag_A,
+             Tag_Z]----------\
+(Start T1-init timer)         \
+(Enter COOKIE-ECHOED state)    \---> (Find existing association,
+                                      Tie-Tags match old tags,
+                                      Tags do not match i.e.
+                                      case X X M M above,
+                                      Announce Restart to ULP
+                                      and reset association).
+                               /---- COOKIE-ACK
+                              /
+(Cancel T1-init timer, <-----/
+ Enter ESTABLISHED state)
+{app sends 1st user data; strm 0}
+DATA [TSN=initial TSN_A
+     Strm=0,Seq=1 & user data]--\
+(Start T3-rtx timer)            \
+                                 \->
+                              /----- SACK [TSN Ack=init TSN_A,Block=0]
+(Cancel T3-rtx timer) <------/
+
+                  Figure 5: A Restart Example
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 65]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+5.2.5 Handle Duplicate COOKIE-ACK.
+
+   At any state other than COOKIE-ECHOED, an endpoint should silently
+   discard a received COOKIE ACK chunk.
+
+5.2.6 Handle Stale COOKIE Error
+
+   Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates
+   one of a number of possible events:
+
+   A) That the association failed to completely setup before the State
+      Cookie issued by the sender was processed.
+
+   B) An old State Cookie was processed after setup completed.
+
+   C) An old State Cookie is received from someone that the receiver is
+      not interested in having an association with and the ABORT chunk
+      was lost.
+
+   When processing an ERROR chunk with a "Stale Cookie" error cause an
+   endpoint should first examine if an association is in the process of
+   being setup, i.e. the association is in the COOKIE-ECHOED state.  In
+   all cases if the association is not in the COOKIE-ECHOED state, the
+   ERROR chunk should be silently discarded.
+
+   If the association is in the COOKIE-ECHOED state, the endpoint may
+   elect one of the following three alternatives.
+
+   1) Send a new INIT chunk to the endpoint to generate a new State
+      Cookie and re-attempt the setup procedure.
+
+   2) Discard the TCB and report to the upper layer the inability to
+      setup the association.
+
+   3) Send a new INIT chunk to the endpoint, adding a Cookie
+      Preservative parameter requesting an extension to the lifetime of
+      the State Cookie.  When calculating the time extension, an
+      implementation SHOULD use the RTT information measured based on
+      the previous COOKIE ECHO / ERROR exchange, and should add no more
+      than 1 second beyond the measured RTT, due to long State Cookie
+      lifetimes making the endpoint more subject to a replay attack.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 66]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+5.3 Other Initialization Issues
+
+5.3.1 Selection of Tag Value
+
+   Initiate Tag values should be selected from the 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 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
+   association.
+
+   Moreover, the Verification Tag value used by either endpoint in a
+   given association MUST NOT change during the lifetime of an
+   association.  A new Verification Tag value MUST be used each time the
+   endpoint tears-down and then re-establishes an association to the
+   same peer.
+
+6. User Data Transfer
+
+   Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-
+   PENDING, and SHUTDOWN-RECEIVED states.  The only exception to this is
+   that DATA chunks are allowed to be bundled with an outbound COOKIE
+   ECHO chunk when in COOKIE-WAIT state.
+
+   DATA chunks MUST only be received according to the rules below in
+   ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT.  A DATA chunk received
+   in CLOSED is out of the blue and SHOULD be handled per 8.4.  A DATA
+   chunk received in any other state SHOULD be discarded.
+
+   A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and
+   SHUTDOWN-RECEIVED.  An incoming SACK MAY be processed in COOKIE-
+   ECHOED.  A SACK in the CLOSED state is out of the blue and SHOULD be
+   processed according to the rules in 8.4.  A SACK chunk received in
+   any other state SHOULD be discarded.
+
+
+   A SCTP receiver MUST be able to receive a minimum of 1500 bytes in
+   one SCTP packet.  This means that a SCTP endpoint MUST NOT indicate
+   less than 1500 bytes in its Initial a_rwnd sent in the INIT or INIT
+   ACK.
+
+   For transmission efficiency, SCTP defines mechanisms for bundling of
+   small user messages and fragmentation of large user messages.  The
+   following diagram depicts the flow of user messages through SCTP.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 67]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   In this section the term "data sender" refers to the endpoint that
+   transmits a DATA chunk and the term "data receiver" refers to the
+   endpoint that receives a DATA chunk.  A data receiver will transmit
+   SACK chunks.
+
+                 +--------------------------+
+                 |      User Messages       |
+                 +--------------------------+
+       SCTP user        ^  |
+      ==================|==|=======================================
+                        |  v (1)
+             +------------------+    +--------------------+
+             | SCTP DATA Chunks |    |SCTP Control Chunks |
+             +------------------+    +--------------------+
+                        ^  |             ^  |
+                        |  v (2)         |  v (2)
+                     +--------------------------+
+                     |      SCTP packets        |
+                     +--------------------------+
+       SCTP                      ^  |
+      ===========================|==|===========================
+                                 |  v
+             Connectionless Packet Transfer Service (e.g., IP)
+
+   Notes:
+
+      1) When converting user messages into DATA chunks, an endpoint
+         will fragment user messages larger than the current association
+         path MTU into multiple DATA chunks.  The data receiver will
+         normally reassemble the fragmented message from DATA chunks
+         before delivery to the user (see Section 6.9 for details).
+
+      2) Multiple DATA and control chunks may be bundled by the sender
+         into a single SCTP packet for transmission, as long as the
+         final size of the packet does not exceed the current path MTU.
+         The receiver will unbundle the packet back into the original
+         chunks.  Control chunks MUST come before DATA chunks in the
+         packet.
+
+                Figure 6: Illustration of User Data Transfer
+
+   The fragmentation and bundling mechanisms, as detailed in Sections
+   6.9 and 6.10, are OPTIONAL to implement by the data sender, but they
+   MUST be implemented by the data receiver, i.e., an endpoint MUST
+   properly receive and process bundled or fragmented data.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 68]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+6.1  Transmission of DATA Chunks
+
+   This document is specified as if there is a single retransmission
+   timer per destination transport address, but implementations MAY have
+   a retransmission timer for each DATA chunk.
+
+   The following general rules MUST be applied by the data sender for
+   transmission and/or retransmission of outbound DATA chunks:
+
+   A) At any given time, the data sender MUST NOT transmit new data to
+      any destination transport address if its peer's rwnd indicates
+      that the peer has no buffer space (i.e. rwnd is 0, see Section
+      6.2.1).  However, regardless of the value of rwnd (including if it
+      is 0), the data sender can always have one DATA chunk in flight to
+      the receiver if allowed by cwnd (see rule B below).  This rule
+      allows the sender to probe for a change in rwnd that the sender
+      missed due to the SACK having been lost in transit from the data
+      receiver to the data sender.
+
+   B) At any given time, the sender MUST NOT transmit new data to a
+      given transport address if it has cwnd or more bytes of data
+      outstanding to that transport address.
+
+   C) When the time comes for the sender to transmit, before sending new
+      DATA chunks, the sender MUST first transmit any outstanding DATA
+      chunks which are marked for retransmission (limited by the current
+      cwnd).
+
+   D) Then, the sender can send out as many new DATA chunks as Rule A
+      and Rule B above allow.
+
+   Multiple DATA chunks committed for transmission MAY be bundled in a
+   single packet.  Furthermore, DATA chunks being retransmitted MAY be
+   bundled with new DATA chunks, as long as the resulting packet size
+   does not exceed the 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 using to increase bundling efficiency.  It does
+   not in itself stop all bundling from occurring (i.e. in case of
+   congestion or retransmission).
+
+   Before an endpoint transmits a DATA chunk, if any received DATA
+   chunks have not been acknowledged (e.g., due to delayed ack), the
+   sender should create a SACK and bundle it with the outbound DATA
+   chunk, as long as the size of the final SCTP packet does not exceed
+   the current MTU.  See Section 6.2.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 69]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   IMPLEMENTATION NOTE: When the window is full (i.e., transmission is
+   disallowed by Rule A and/or Rule B), the sender MAY still accept send
+   requests from its upper layer, but MUST transmit no more DATA chunks
+   until some or all of the outstanding DATA chunks are acknowledged and
+   transmission is allowed by Rule A and Rule B again.
+
+   Whenever a transmission or retransmission is made to any address, if
+   the T3-rtx timer of that address is not currently running, the sender
+   MUST start that timer.  If the timer for that address is already
+   running, the sender MUST restart the timer if the earliest (i.e.,
+   lowest TSN) outstanding DATA chunk sent to that address is being
+   retransmitted.  Otherwise, the data sender MUST NOT restart the
+   timer.
+
+   When starting or restarting the T3-rtx timer, the timer value must be
+   adjusted according to the timer rules defined in Sections 6.3.2, and
+   6.3.3.
+
+   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
+   1 above the beginning TSN of the current send window.
+
+6.2  Acknowledgement on Reception of DATA Chunks
+
+   The SCTP endpoint MUST always acknowledge the 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 arrival of any unacknowledged DATA chunk.  In
+   some situations it may be beneficial for an SCTP transmitter to be
+   more conservative than the algorithms detailed in this document
+   allow. However, an SCTP transmitter MUST NOT be more aggressive than
+   the following algorithms allow.
+
+   A SCTP receiver MUST NOT generate more than one SACK for every
+   incoming packet, other than to update the offered window as the
+   receiving application consumes new data.
+
+   IMPLEMENTATION NOTE: The maximum delay for generating an
+   acknowledgement may be configured by the SCTP administrator, either
+   statically or dynamically, in order to meet the specific timing
+   requirement of the protocol being carried.
+
+   An implementation MUST NOT allow the maximum delay to be configured
+   to be more than 500 ms.  In other words an implementation MAY lower
+   this value below 500ms but MUST NOT raise it above 500ms.
+
+
+
+Stewart, et al.             Standards Track                    [Page 70]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Acknowledgements MUST be sent in SACK chunks unless shutdown was
+   requested by the ULP in which case an endpoint MAY send an
+   acknowledgement in the SHUTDOWN chunk.  A SACK chunk can acknowledge
+   the reception of multiple DATA chunks.  See Section 3.3.4 for SACK
+   chunk format.  In particular, the SCTP endpoint MUST fill in the
+   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 value in the Cumulative TSN Ack field SHOULD also be
+   reported in the Gap Ack Block fields.
+
+   Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
+   Therefore, the endpoint should use a SACK instead of the SHUTDOWN
+   chunk to acknowledge DATA chunks received out of order .
+
+   When a packet arrives with duplicate DATA chunk(s) and with no new
+   DATA chunk(s), the endpoint MUST immediately send a SACK with no
+   delay.  If a packet arrives with duplicate DATA chunk(s) bundled with
+   new DATA chunks, the endpoint MAY immediately send a SACK.  Normally
+   receipt of duplicate DATA chunks will occur when the original SACK
+   chunk was lost and the peer's RTO has expired.  The duplicate TSN
+   number(s) SHOULD be reported in the SACK as duplicate.
+
+   When an endpoint receives a SACK, it MAY use the 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 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.,
+   Operating System, memory management system, amount of memory, etc.).
+   However, the data sender strategy defined in Section 6.2.1 is based
+   on the assumption of receiver operation similar to the following:
+
+      A) At initialization of the association, the endpoint tells the
+         peer how much receive buffer space it has allocated to the
+         association in the INIT or INIT ACK.  The endpoint sets a_rwnd
+         to this value.
+
+      B) As DATA chunks are received and buffered, decrement a_rwnd by
+         the number of bytes received and buffered.  This is, in effect,
+         closing rwnd at the data sender and restricting the amount of
+         data it can transmit.
+
+      C) As DATA chunks are delivered to the ULP and released from the
+         receive buffers, increment a_rwnd by the number of bytes
+         delivered to the upper layer.  This is, in effect, opening up
+         rwnd on the data sender and allowing it to send more data.  The
+
+
+
+Stewart, et al.             Standards Track                    [Page 71]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+         data receiver SHOULD NOT increment a_rwnd unless it has
+         released bytes from its receive buffer.  For example, if the
+         receiver is holding fragmented DATA chunks in a reassembly
+         queue, it should not increment a_rwnd.
+
+      D) When sending a SACK, the data receiver SHOULD place the current
+         value of a_rwnd into the a_rwnd field.  The data receiver
+         SHOULD take into account that the data sender will not
+         retransmit DATA chunks that are acked via the Cumulative TSN
+         Ack (i.e., will drop from its retransmit queue).
+
+   Under certain circumstances, the 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 ULP).  These DATA chunks may have
+   been acked in Gap Ack Blocks.  For example, the data receiver may be
+   holding data in its receive buffers while reassembling a fragmented
+   user message 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 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 endpoint should
+   take into account the dropped data when calculating 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 data sender and thus
+   in suboptimal performance.
+
+   The following example illustrates the use of delayed
+   acknowledgements:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 72]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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] \
+                                  /         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 7:  Delayed Acknowledgment Example
+
+   If an endpoint receives a DATA chunk with no user data (i.e., the
+   Length field is set to 16) it MUST send an ABORT with error cause set
+   to "No User Data".
+
+   An endpoint SHOULD NOT send a 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 data receiver, at the time
+   of transmitting the SACK, has left of its total receive buffer space
+   (as specified in the INIT/INIT ACK).  Using a_rwnd, Cumulative TSN
+   Ack and Gap Ack Blocks, the data sender can develop a representation
+   of the peer's receive buffer space.
+
+   One of the problems the data sender must take into account when
+   processing a SACK is that a SACK can be received out of order.  That
+   is, a SACK sent by the data receiver can pass an earlier SACK and be
+   received first by the data sender.  If a SACK is received out of
+   order, the data sender can develop an incorrect view of the peer's
+   receive buffer space.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 73]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Since there is no explicit identifier that can be used to detect
+   out-of-order SACKs, the data sender must use heuristics to determine
+   if a SACK is new.
+
+   An endpoint SHOULD use the following rules to calculate the rwnd,
+   using the a_rwnd value, the Cumulative TSN Ack and Gap Ack Blocks in
+   a received SACK.
+
+   A) At the establishment of the association, the endpoint initializes
+      the rwnd to the Advertised Receiver Window Credit (a_rwnd) the
+      peer specified in the INIT or INIT ACK.
+
+   B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
+      the endpoint subtracts the data 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 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 Cumulative TSN Ack Point indicates an out-of-
+         order SACK.
+
+         ii) Set rwnd equal to the newly received a_rwnd minus the
+         number of bytes still outstanding after processing the
+         Cumulative TSN Ack and the Gap Ack Blocks.
+
+         iii) If the SACK is missing a TSN that was previously
+         acknowledged via a Gap Ack Block (e.g., the data receiver
+         reneged on the data), then mark the corresponding DATA chunk as
+         available for retransmit:  Mark it as missing for fast
+         retransmit as described in Section 7.2.4 and if no retransmit
+         timer is running for the destination address to which the DATA
+         chunk was originally transmitted, then T3-rtx is started for
+         that destination address.
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 74]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+6.3 Management of Retransmission Timer
+
+   An SCTP endpoint uses a retransmission timer T3-rtx to ensure data
+   delivery in the absence of any 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
+   separate RTO for each different destination transport address of 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
+   variation).
+
+6.3.1 RTO Calculation
+
+   The rules governing the computation of SRTT, RTTVAR, and RTO are as
+   follows:
+
+   C1) Until an RTT measurement has been made for a packet sent to the
+       given destination transport address, set RTO to the protocol
+       parameter 'RTO.Initial'.
+
+   C2) When the first RTT measurement R is made, set SRTT <- R, RTTVAR
+       <- R/2, 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: 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 is in flight and when allowed by rule C5 below, a new
+       RTT measurement MUST be made each round trip.  Furthermore, 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 [ALLMAN99]; second, if measurements are made more often,
+       then the values of RTO.Alpha and RTO.Beta in rule C3 above should
+       be adjusted so that SRTT and RTTVAR still adjust to changes at
+       roughly the same rate (in terms of how many round trips it takes
+
+
+
+Stewart, et al.             Standards Track                    [Page 75]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+       them to reflect new values) 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 of 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 ambiguous
+       whether the reply was for the first instance of the packet or a
+       later instance).
+
+   C6) Whenever RTO is computed, if it is less than RTO.Min seconds then
+       it is rounded up to RTO.Min seconds.  The reason for this rule is
+       that RTOs that 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 at least
+       RTO.max seconds.
+
+   There is no requirement for the clock granularity G used for
+   computing RTT measurements and the 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 retransmission timer are as follows:
+
+   R1) Every time a DATA chunk is sent to any address (including a
+       retransmission), if the T3-rtx timer of that address is not
+       running, start it running so that it will expire after the RTO of
+       that address.  The RTO used here is that obtained after any
+       doubling due to previous T3-rtx timer expirations on the
+       corresponding destination address as discussed in rule E2 below.
+
+   R2) Whenever all outstanding data sent to an address have been
+       acknowledged, turn off the T3-rtx timer of that address.
+
+   R3) Whenever a SACK is received that acknowledges the DATA chunk with
+       the earliest outstanding TSN for that address, restart T3-rtx
+       timer for that address with its current RTO (if there is still
+       outstanding data on that address).
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 76]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   R4) Whenever a SACK is received missing a TSN that was previously
+       acknowledged via a Gap Ack Block, start T3-rtx for the
+       destination address to which the DATA chunk was originally
+       transmitted if it is not already running.
+
+   The following example shows the use of various timer rules (assuming
+   the 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 [TSN Ack=7,Block=0]
+                                  \   /      DATA [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 [TSN Ack=8,Block=0]
+
+                 Figure 8 - Timer Rule Examples
+
+6.3.3 Handle T3-rtx Expiration
+
+   Whenever the retransmission timer T3-rtx expires for a destination
+   address, do the following:
+
+   E1) For the destination address for which the timer expires, adjust
+       its ssthresh with rules defined in Section 7.2.3 and set the cwnd
+       <- MTU.
+
+   E2) For the destination address for which the timer expires, set RTO
+       <- RTO * 2 ("back off the timer").  The 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 earliest (i.e., lowest TSN) outstanding
+       DATA chunks for the address for which the T3-rtx has expired will
+       fit into a single packet, subject to the MTU constraint for the
+       path corresponding to the destination transport address to which
+       the retransmission is being sent (this may be different from the
+
+
+
+Stewart, et al.             Standards Track                    [Page 77]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+       address for which the timer expires [see Section 6.4]).  Call
+       this value K.  Bundle and retransmit those K DATA chunks in a
+       single packet to the destination endpoint.
+
+   E4) Start the retransmission timer T3-rtx on the destination address
+       to which the retransmission is sent, if rule R1 above indicates
+       to do so.  The RTO to be used for starting T3-rtx should be the
+       one for the destination address to which the retransmission is
+       sent, which, when the receiver is multi-homed, may be different
+       from the 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 measurement made from a HEARTBEAT [see Section
+   8.3]), the computation in rule C3 is performed, including the
+   computation of RTO, which may result in "collapsing" RTO back down
+   after it has been subject to doubling (rule E2).
+
+   Note: Any DATA chunks that were sent to the 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).
+
+   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 different one, the current retransmission
+       timers are left running.  As soon as the endpoint transmits a
+       packet containing DATA chunk(s) to the new transport address,
+       start the timer on that transport address, using the RTO value of
+       the destination address to which the 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 multiple
+   destination addresses of a multi-homed peer endpoint as the primary
+   path (see Sections 5.1.2 and 10.1 for details).
+
+   By default, an endpoint SHOULD always transmit to the primary path,
+   unless the SCTP user explicitly specifies the destination transport
+   address (and possibly source transport address) to use.
+
+
+
+Stewart, et al.             Standards Track                    [Page 78]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
+   etc.) to the same destination transport address from which it
+   received the DATA or control chunk to which it is replying.  This
+   rule should also be followed if the endpoint is bundling DATA chunks
+   together with the reply chunk.
+
+   However, when acknowledging multiple DATA chunks received in packets
+   from different source addresses in a single SACK, the SACK chunk may
+   be transmitted to one of the destination transport addresses from
+   which the DATA or control chunks being acknowledged were received.
+
+   When a receiver of a duplicate DATA chunk sends a SACK to a multi-
+   homed endpoint it MAY be beneficial to vary the destination address
+   and not use the source address of the DATA chunk.  The reason being
+   that receiving a duplicate from a multi-homed endpoint might indicate
+   that the return path (as specified in the source address of the DATA
+   chunk) for the 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 which the DATA chunk
+   was sent.
+
+   Retransmissions do not affect the total outstanding data count.
+   However, if the DATA chunk is retransmitted onto a different
+   destination address, both the outstanding data counts on the new
+   destination address and the old destination address to which the data
+   chunk was last sent shall be adjusted accordingly.
+
+6.4.1 Failover from Inactive Destination Address
+
+   Some of the transport addresses of a multi-homed SCTP endpoint may
+   become inactive due to either the occurrence of certain error
+   conditions (see Section 8.2) or adjustments from SCTP user.
+
+   When there is outbound data to send and the primary path becomes
+   inactive (e.g., due to failures), or where the SCTP user explicitly
+   requests to send data to an inactive destination transport address,
+   before reporting an error to its ULP, the SCTP endpoint should try to
+   send the data to an alternate active destination transport address if
+   one exists.
+
+   When retransmitting data, if the endpoint is multi-homed, it should
+   consider each source-destination address pair in its retransmission
+   selection policy.  When retransmitting the endpoint should attempt to
+   pick the most divergent source-destination pair from the original
+   source-destination pair to which the packet was transmitted.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 79]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Note: Rules for picking the most divergent source-destination pair
+   are an implementation decision and is not specified within this
+   document.
+
+6.5 Stream Identifier and Stream Sequence Number
+
+   Every DATA chunk MUST carry a valid stream identifier.  If an
+   endpoint receives a DATA chunk with an invalid stream identifier, it
+   shall acknowledge the reception of the DATA chunk following the
+   normal procedure, immediately send an ERROR chunk with cause set to
+   "Invalid Stream Identifier" (see Section 3.3.10) and 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 SACK.
+
+   The stream sequence number in all the streams shall start from 0 when
+   the association is established.  Also, when the stream sequence
+   number reaches the value 65535 the next stream sequence number shall
+   be set to 0.
+
+6.6 Ordered and Unordered Delivery
+
+   Within a stream, an endpoint MUST deliver DATA chunks received with
+   the U flag set to 0 to the upper layer according to the order of
+   their stream sequence number.  If DATA chunks arrive out of order of
+   their stream sequence number, the endpoint MUST hold the received
+   DATA chunks from delivery to the ULP until they are re-ordered.
+
+   However, an SCTP endpoint can indicate that no ordered delivery is
+   required for a particular DATA chunk transmitted within the stream by
+   setting the U flag of the DATA chunk to 1.
+
+   When an endpoint receives a DATA chunk with the U flag set to 1, it
+   must bypass the ordering mechanism and immediately deliver the data
+   to the upper layer (after re-assembly if the user data is fragmented
+   by the data sender).
+
+   This provides an effective way of transmitting "out-of-band" data in
+   a given stream.  Also, a stream can be used as an "unordered" stream
+   by simply setting the U flag to 1 in all DATA chunks sent through
+   that stream.
+
+   IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an
+   implementation may choose to place the DATA chunk in an outbound
+   packet that is at the head of the outbound transmission queue if
+   possible.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 80]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   The 'Stream Sequence Number' field in a DATA chunk with U flag set to
+   1 has no significance.  The sender can fill it with arbitrary value,
+   but the receiver MUST ignore the field.
+
+   Note:  When transmitting ordered and unordered data, an endpoint does
+   not increment its Stream Sequence Number when transmitting a DATA
+   chunk with U flag set to 1.
+
+6.7 Report Gaps in Received DATA TSNs
+
+   Upon the reception of a new DATA chunk, an endpoint shall examine the
+   continuity of the TSNs received.  If the endpoint detects a gap in
+   the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack
+   Blocks immediately.  The data receiver continues sending a SACK after
+   receipt of each SCTP packet that 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 multi-homed, the SCTP endpoint SHOULD always try to
+   send the SACK to the same destination address 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 the DATA
+   chunks with TSNs not included in the Gap Ack Blocks reported by the
+   SACK as "missing".  The number of "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 SACK to report a gap.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 81]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      Endpoint A                                    Endpoint Z
+      {App sends 3 messages; strm 0}
+      DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
+      (Start T3-rtx timer)
+
+      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,Block=1,
+                                     /             Strt=2,End=2]
+                              <-----/
+      (remove 6 from out-queue,
+       and mark 7 as "1" missing report)
+
+                 Figure 9 - Reporting a Gap using SACK
+
+   The maximum number of Gap Ack Blocks that can be reported within a
+   single SACK 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 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 the packet, as described below.
+
+   After the packet is constructed (containing the SCTP common header
+   and one or more control or DATA chunks), the transmitter shall:
+
+   1) Fill in the proper Verification Tag in the SCTP common header and
+      initialize the checksum field to 0's.
+
+   2) Calculate the Adler-32 checksum of the whole packet, including the
+      SCTP common header and all the chunks.  Refer to appendix B for
+      details of the Adler-32 algorithm.  And,
+
+   3) Put the resultant value into the checksum field in the common
+      header, and leave the rest of the bits unchanged.
+
+   When an SCTP packet is received, the receiver MUST first check the
+   Adler-32 checksum:
+
+   1) Store the received Adler-32 checksum value aside,
+
+
+
+Stewart, et al.             Standards Track                    [Page 82]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   2) Replace the 32 bits of the checksum field in the received SCTP
+      packet with all '0's and calculate an Adler-32 checksum value of
+      the whole received packet.  And,
+
+   3) Verify that the calculated Adler-32 checksum is the same as the
+      received Adler-32 checksum.  If not, the receiver MUST treat the
+      packet as an invalid SCTP packet.
+
+   The default procedure for handling invalid SCTP packets is to
+   silently discard them.
+
+6.9 Fragmentation and 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 user message if the size
+   of the user message to be sent causes the outbound SCTP packet size
+   to exceed the current MTU.  If an implementation does not support
+   fragmentation of outbound user messages, the endpoint must return an
+   error to its upper layer and not attempt to send the user message.
+
+   IMPLEMENTATION NOTE:  In this error case, the Send primitive
+   discussed in Section 10.1 would need to return an error to the upper
+   layer.
+
+   If its peer is multi-homed, the endpoint shall choose a size no
+   larger than the association Path MTU.  The association Path MTU is
+   the smallest Path MTU of all destination addresses.
+
+   Note: Once a message is fragmented it cannot be re-fragmented.
+   Instead if the PMTU has been reduced, then IP fragmentation must be
+   used.  Please see Section 7.3 for details of PMTU discovery.
+
+   When determining when to fragment, the SCTP implementation MUST take
+   into account the SCTP packet header as well as the DATA chunk
+   header(s).  The implementation MUST also take into account the space
+   required for a SACK chunk if bundling a SACK chunk with the DATA
+   chunk.
+
+   Fragmentation takes the following steps:
+
+   1) The data sender MUST break the user message into a series of DATA
+      chunks such that each chunk plus SCTP overhead fits into an IP
+      datagram smaller than or equal to the association Path MTU.
+
+   2) The transmitter MUST then assign, in sequence, a separate TSN to
+      each of the DATA chunks in the series.  The transmitter assigns
+      the same SSN to each of the DATA chunks.  If the user indicates
+
+
+
+Stewart, et al.             Standards Track                    [Page 83]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+      that the user message is to be delivered using unordered delivery,
+      then the U flag of each DATA chunk of the user message MUST be set
+      to 1.
+
+   3) The transmitter MUST also set the B/E bits of the first DATA chunk
+      in the series to '10', the B/E bits of the last DATA chunk in the
+      series to '01', and the B/E bits of all other DATA chunks in the
+      series to '00'.
+
+   An endpoint MUST recognize fragmented DATA chunks by examining the
+   B/E bits in each of the received DATA chunks, and queue the
+   fragmented DATA chunks for re-assembly.  Once the user message is
+   reassembled, SCTP shall pass the re-assembled user message to the
+   specific stream for possible re-ordering and final dispatching.
+
+   Note: If the data receiver runs out of buffer space while still
+   waiting for more fragments to complete the re-assembly of the
+   message, it should dispatch part of its inbound message through a
+   partial delivery API (see Section 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 SCTP packet.  The total size of the resultant IP datagram,
+   including the SCTP packet and IP headers, MUST be less or equal to
+   the current Path MTU.
+
+   If its peer endpoint is multi-homed, the sending endpoint shall
+   choose a size no larger than the latest MTU of the current primary
+   path.
+
+   When bundling control chunks with DATA chunks, an endpoint MUST place
+   control chunks first in the outbound SCTP packet.  The transmitter
+   MUST transmit DATA chunks within a SCTP packet in increasing order of
+   TSN.
+
+   Note:  Since control chunks must be placed first in a packet and
+   since DATA 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 SCTP packet.
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 84]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   An endpoint MUST process received chunks in their order in the
+   packet. The receiver uses the chunk length field to determine the end
+   of a chunk and beginning of the next chunk taking account of the fact
+   that all chunks end on a 4 byte boundary.  If the receiver detects a
+   partial chunk, it MUST drop the chunk.
+
+   An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with
+   any other chunks.
+
+7. Congestion control
+
+   Congestion control is one of the basic functions in SCTP.  For some
+   applications, it may be likely that adequate resources will be
+   allocated to SCTP traffic to 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 to get data delivered as
+   soon as possible.  In the absence of network congestion, these
+   preventive congestion control algorithms should show no impact on the
+   protocol performance.
+
+   IMPLEMENTATION NOTE: As far as its specific performance requirements
+   are met, an implementation is always allowed to adopt a more
+   conservative congestion control algorithm than the one defined below.
+
+   The congestion control algorithms used by SCTP are based on
+   [RFC2581].  This section describes how the 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 same
+   terminology as in TCP congestion control whenever appropriate.
+
+   SCTP congestion control is always applied to the entire association,
+   and not to individual streams.
+
+7.1 SCTP Differences from TCP Congestion control
+
+   Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as
+   the TCP SACK.  TCP considers the information carried in the SACK as
+   advisory information only.  SCTP considers the information carried in
+   the Gap Ack Blocks in the SACK chunk as advisory.  In SCTP, any DATA
+   chunk that has been acknowledged by SACK, including DATA that arrived
+   at the receiving end out of order, are not considered fully delivered
+   until the Cumulative TSN Ack Point passes the TSN of the DATA chunk
+   (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack
+
+
+
+Stewart, et al.             Standards Track                    [Page 85]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   field in the SACK).  Consequently, the value of cwnd controls the
+   amount of outstanding data, rather than (as in the case of non-SACK
+   TCP) the upper bound between the highest acknowledged sequence number
+   and the latest DATA chunk that can be sent within the congestion
+   window.  SCTP SACK 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-
+   homing.  SCTP is designed to 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 two endpoints, thus ideally
+   one may need a separate set of congestion control parameters for each
+   of the paths.  The treatment here of congestion control for multi-
+   homed receivers is new with SCTP and may require refinement in the
+   future.  The current algorithms make the following assumptions:
+
+   o  The sender usually uses the same destination address until being
+      instructed by the upper layer otherwise; however, SCTP may change
+      to an alternate destination in the event an address is marked
+      inactive (see Section 8.2).  Also, SCTP may retransmit to a
+      different transport address than the original transmission.
+
+   o  The sender keeps a separate congestion control parameter set for
+      each of the destination addresses it can send to (not each
+      source-destination pair but for each destination).  The parameters
+      should decay if the address is not used for a long enough time
+      period.
+
+   o  For each of the destination addresses, an endpoint does slow-start
+      upon the first transmission to that address.
+
+   Note:  TCP guarantees in-sequence delivery of data to its upper-layer
+   protocol within a single TCP session.  This means that when TCP
+   notices a gap in the 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 missing data.  On the other hand,
+   SCTP can deliver data to its upper-layer protocol even if there is a
+   gap in TSN if the Stream Sequence Numbers are in sequence for a
+   particular stream (i.e., the missing DATA chunks are for a different
+   stream) or if unordered delivery is indicated.  Although this does
+   not affect cwnd, it might affect rwnd calculation.
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 86]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+7.2 SCTP Slow-Start and Congestion Avoidance
+
+   The slow start and congestion avoidance algorithms MUST be used by an
+   endpoint to control the amount of data being injected into the
+   network. The congestion control in SCTP is employed in regard to the
+   association, not to an individual stream.  In some situations it may
+   be beneficial for an SCTP sender to be more conservative than the
+   algorithms allow; however, an SCTP sender MUST NOT be more aggressive
+   than the following algorithms allow.
+
+   Like TCP, an SCTP endpoint uses the following three control variables
+   to regulate its transmission rate.
+
+   o  Receiver advertised window size (rwnd, in bytes), which is set by
+      the receiver based on its available buffer space for incoming
+      packets.
+
+      Note: This variable is kept on the entire association.
+
+   o  Congestion control window (cwnd, in bytes), which is adjusted by
+      the 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
+      sender to distinguish slow start and 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 facilitate cwnd adjustment.
+
+   Unlike TCP, an SCTP sender MUST keep a set of these control variables
+   cwnd, ssthresh and partial_bytes_acked for EACH destination address
+   of its peer (when its peer is multi-homed).  Only one rwnd is kept
+   for the whole association (no matter if the peer is multi-homed or
+   has a single address).
+
+7.2.1 Slow-Start
+
+   Beginning data transmission into a network with unknown conditions or
+   after a sufficiently long idle period requires SCTP to probe the
+   network to determine the available capacity.  The slow start
+   algorithm is used for this purpose at the beginning of a transfer, or
+   after repairing loss detected by the retransmission timer.
+
+
+
+Stewart, et al.             Standards Track                    [Page 87]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 of ssthresh MAY be arbitrarily high (for
+      example, implementations MAY use the size of the receiver
+      advertised window).
+
+   o  Whenever cwnd is greater than zero, the endpoint is allowed to
+      have cwnd bytes of data outstanding on that transport address.
+
+   o  When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
+      use the slow start algorithm to increase cwnd (assuming the
+      current congestion window is being fully utilized).  If an
+      incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
+      increased by at most the lesser of 1) the total size of the
+      previously outstanding DATA chunk(s) acknowledged, and 2) the
+      destination's path MTU. This protects against the ACK-Splitting
+      attack outlined in [SAVAGE99].
+
+   In instances where its peer endpoint is multi-homed, if an endpoint
+   receives a SACK that advances its Cumulative TSN Ack Point, then it
+   should update its cwnd (or cwnds) apportioned to the destination
+   addresses to which it transmitted the acknowledged data.  However if
+   the received SACK does not advance the Cumulative TSN Ack Point, the
+   endpoint MUST NOT adjust the cwnd of any of the destination
+   addresses.
+
+   Because an endpoint's cwnd is not tied to its Cumulative TSN Ack
+   Point, as duplicate SACKs come in, even though they may not advance
+   the Cumulative TSN Ack Point an endpoint 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
+   the current, unchanged value of cwnd now allows new data to be sent.
+   On the other hand, the increase of cwnd must be tied to the
+   Cumulative TSN Ack Point advancement as specified above.  Otherwise
+   the duplicate SACKs will not only clock out new data, but also will
+   adversely clock out more new data than what has just left the
+   network, during a time of possible congestion.
+
+   o  When the endpoint does not transmit data on a given transport
+      address, the cwnd of the transport address should be adjusted to
+      max(cwnd/2, 2*MTU) per RTO.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 88]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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 0.
+
+   o  Whenever cwnd is greater than ssthresh, upon each SACK arrival
+      that advances the Cumulative TSN Ack Point, increase
+      partial_bytes_acked by the total number of bytes of all new chunks
+      acknowledged in 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 arrival of the SACK the sender had cwnd or more bytes
+      of data outstanding (i.e., before arrival of the SACK, flightsize
+      was greater than or equal to cwnd), increase cwnd by MTU, and
+      reset partial_bytes_acked to (partial_bytes_acked - cwnd).
+
+   o  Same as in the slow start, when the sender does not transmit DATA
+      on a given transport address, the cwnd of the transport address
+      should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
+
+   o  When all of the data transmitted by the sender has been
+      acknowledged by the receiver, partial_bytes_acked is initialized
+      to 0.
+
+7.2.3 Congestion Control
+
+   Upon detection of packet losses from SACK  (see Section 7.2.4), An
+   endpoint should do the following:
+
+      ssthresh = max(cwnd/2, 2*MTU)
+      cwnd = ssthresh
+
+   Basically, a packet loss causes cwnd to be cut in half.
+
+   When the T3-rtx timer expires on an address, SCTP should perform slow
+   start by:
+
+      ssthresh = max(cwnd/2, 2*MTU)
+      cwnd = 1*MTU
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 89]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   and assure that no more than one SCTP packet will be in flight for
+   that address until the endpoint receives acknowledgement for
+   successful delivery of data to that address.
+
+7.2.4 Fast Retransmit on Gap Reports
+
+   In the absence of data loss, an endpoint performs delayed
+   acknowledgement.  However, whenever an endpoint notices a hole in the
+   arriving TSN sequence, it SHOULD start sending a SACK back every time
+   a packet arrives carrying data until the 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 same TSN(s) before taking action with
+   regard to Fast Retransmit.
+
+   When the TSN(s) is reported as missing in the fourth consecutive
+   SACK, the data sender shall:
+
+   1) Mark the missing DATA chunk(s) for retransmission,
+
+   2) Adjust the ssthresh and cwnd of the destination address(es) to
+      which the missing DATA chunks were last sent, according to the
+      formula described in Section 7.2.3.
+
+   3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
+      marked for retransmission will fit into a single packet, subject
+      to constraint of 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 a single packet.
+
+   4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
+      outstanding TSN number sent to that address, or the endpoint is
+      retransmitting the first outstanding DATA chunk sent to that
+      address.
+
+   Note: Before the above adjustments, if the received SACK also
+   acknowledges new DATA chunks and advances the Cumulative TSN Ack
+   Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
+   must be applied first.
+
+   A straightforward implementation of the above keeps a counter for
+   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 0.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 90]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Because cwnd in SCTP indirectly bounds the number of outstanding
+   TSN's, the effect of TCP fast-recovery is achieved automatically with
+   no adjustment to the congestion control window size.
+
+7.3 Path MTU Discovery
+
+   [RFC1191] specifies "Path MTU Discovery", whereby an endpoint
+   maintains an estimate of the 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 a
+   change in the Path MTU (PMTU).  RFC 1191 is thorough in its
+   discussion of the MTU discovery mechanism and strategies for
+   determining the current end-to-end MTU setting as well as detecting
+   changes in this value.  [RFC1981] specifies the same mechanisms for
+   IPv6.  An SCTP sender using IPv6 MUST use Path MTU Discovery unless
+   all packets are less than the minimum IPv6 MTU [RFC2460].
+
+   An endpoint SHOULD apply these techniques, and SHOULD do so on a
+   per-destination-address basis.
+
+   There are 4 ways in which SCTP differs from the 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 term "MTU" is discussed, it
+      refers to the MTU associated with the destination address
+      corresponding to the context of the 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 no larger than the 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 TSNs rather than bytes (as is the case for TCP), the discussion
+      in Section 6.5 of RFC 1191 applies: When retransmitting an IP
+      datagram to a remote address for which the IP datagram appears too
+      large for the path MTU to that address, the 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.
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 91]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   5) The sender should track an association PMTU which will be the
+      smallest PMTU discovered for all of the peer's destination
+      addresses.  When fragmenting messages into multiple parts this
+      association PMTU should be used to calculate the 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 MTU
+   discovery in RFCs 1191 and 1981 applies to SCTP on a per-
+   destination-address basis.
+
+   Note: For IPv6 destination addresses the DF bit does not exist,
+   instead the IP datagram must be fragmented as described in [RFC2460].
+
+8.  Fault Management
+
+8.1 Endpoint Failure Detection
+
+   An endpoint shall keep a counter on the total number of consecutive
+   retransmissions to its peer (including retransmissions to all the
+   destination transport addresses of the peer if it is multi-homed).
+   If the value of this counter exceeds the limit indicated in the
+   protocol parameter 'Association.Max.Retrans', the endpoint shall
+   consider the peer endpoint unreachable and shall stop transmitting
+   any more data to it (and thus the association enters the CLOSED
+   state).  In addition, the endpoint shall report the failure to the
+   upper layer, and optionally report back all outstanding user data
+   remaining in its outbound queue. The association is automatically
+   closed when the peer endpoint becomes unreachable.
+
+   The counter shall be reset each time a DATA chunk sent to that peer
+   endpoint is acknowledged (by the reception of a SACK), or a
+   HEARTBEAT-ACK is received from the peer endpoint.
+
+8.2 Path Failure Detection
+
+   When its peer endpoint is 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
+   HEARTBEAT sent to an idle address is not acknowledged within a RTO,
+   the error counter of that destination address will be incremented.
+   When the value in the error counter exceeds the protocol parameter
+   'Path.Max.Retrans' of that destination address, the endpoint should
+   mark the destination transport address as inactive, and a
+   notification SHOULD be sent to the upper layer.
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 92]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
+   address is acknowledged with a HEARTBEAT ACK, the endpoint shall
+   clear the error counter of the destination transport address to which
+   the DATA chunk was last sent (or HEARTBEAT was sent).  When the peer
+   endpoint is multi-homed and the last chunk sent to it was a
+   retransmission to an alternate address, there exists an ambiguity as
+   to whether or not the acknowledgement should be credited to the
+   address of the last chunk sent.  However, this ambiguity does not
+   seem to bear any significant consequence to SCTP behavior.  If this
+   ambiguity is undesirable, the transmitter may choose not to clear the
+   error counter if the last chunk sent was a retransmission.
+
+   Note: When configuring the SCTP endpoint, the user should avoid
+   having the value of 'Association.Max.Retrans' larger than the
+   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 SCTP chooses
+   to function is implementation specific.
+
+   When the primary path is marked inactive (due to excessive
+   retransmissions, for instance), the 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
+   primary path is marked inactive only ONE transport address SHOULD be
+   chosen and used as the new destination transport address.
+
+8.3 Path Heartbeat
+
+   By default, an SCTP endpoint shall monitor the reachability of the
+   idle destination transport address(es) of its peer by sending a
+   HEARTBEAT chunk periodically to the destination 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 current heartbeat period of
+   that address.  This applies to both active and inactive destination
+   addresses.
+
+   The upper layer can optionally initiate the following functions:
+
+   A) Disable heartbeat on a specific destination transport address of a
+      given association,
+
+   B) Change the HB.interval,
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 93]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   C) Re-enable heartbeat on a specific destination transport address of
+      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 transport address each time a HEARTBEAT is sent to that
+   address and not acknowledged within one RTO.
+
+   When the value of this counter reaches the protocol parameter '
+   Path.Max.Retrans', the endpoint should mark the corresponding
+   destination address as inactive if it is not so marked, and may also
+   optionally report to the upper layer the change of reachability of
+   this destination address.  After this, the endpoint should continue
+   HEARTBEAT on this destination address but should stop increasing the
+   counter.
+
+   The sender of the HEARTBEAT chunk should include in the Heartbeat
+   Information field of the 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 be used is to increment the error counter variable
+   every time a HEARTBEAT is sent to a destination.  Whenever a
+   HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of
+   the destination that the HEARTBEAT was sent to.  This in effect would
+   clear the previously stroked error (and any other error counts as
+   well).
+
+   The receiver of the HEARTBEAT should immediately respond with a
+   HEARTBEAT ACK that contains the Heartbeat Information field copied
+   from the received HEARTBEAT chunk.
+
+   Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
+   should clear the error counter of the destination transport address
+   to which the HEARTBEAT was sent, and mark 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 the reception of the latest
+   HEARTBEAT ACK.  The receiver of the HEARTBEAT ACK must also clear the
+   association overall error count as well (as defined in section 8.1).
+
+   The receiver of the HEARTBEAT ACK should also perform an RTT
+   measurement for that destination transport address using the time
+   value carried in the HEARTBEAT ACK chunk.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 94]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   On an idle destination address that is allowed to heartbeat, a
+   HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
+   destination address plus the protocol parameter 'HB.interval' , with
+   jittering of +/- 50%, and exponential back-off of the RTO if the
+   previous HEARTBEAT is unanswered.
+
+   A primitive is provided for the SCTP user to change the HB.interval
+   and turn on or off the heartbeat on a given destination address.  The
+   heartbeat interval set by the SCTP user is added to the RTO of that
+   destination (including any exponential backoff).  Only one heartbeat
+   should be sent each time the heartbeat timer expires (if multiple
+   destinations are idle).  It is a implementation decision on how to
+   choose which of the candidate idle destinations to heartbeat to (if
+   more than one destination is idle).
+
+   Note: When tuning the heartbeat interval, there is 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 well.  If a peer endpoint ABORTs the association for
+   any reason and the ABORT chunk is lost, the local endpoint will only
+   discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk
+   (thus causing the peer to send another ABORT).  This must be
+   considered when tuning the HEARTBEAT timer.  If the HEARTBEAT is
+   disabled only sending DATA to the association will discover a lost
+   ABORT from the peer.
+
+8.4 Handle "Out of the blue" Packets
+
+   An SCTP packet is called an "out of the blue" (OOTB) packet if it is
+   correctly formed, i.e., passed the receiver's Adler-32 check (see
+   Section 6.8), but the receiver is not able to identify the
+   association to which this packet belongs.
+
+   The receiver of an OOTB packet MUST do the following:
+
+   1) If the OOTB packet is to or from a non-unicast address, silently
+      discard the packet.  Otherwise,
+
+   2) If the OOTB packet contains an ABORT chunk, the receiver MUST
+      silently discard the OOTB packet and take no further action.
+      Otherwise,
+
+   3) If the packet contains an INIT chunk with a Verification Tag set
+      to '0', process it as described in Section 5.1.  Otherwise,
+
+   4) If the packet contains a COOKIE ECHO in the first chunk, process
+      it as described in Section 5.1.  Otherwise,
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 95]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
+      respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
+      When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
+      packet must fill in the Verification Tag field of the outbound
+      packet with the Verification Tag received in the SHUTDOWN ACK and
+      set the T-bit in the Chunk Flags to indicate that no TCB was
+      found. Otherwise,
+
+   6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
+      should silently discard the packet and take no further action.
+      Otherwise,
+
+   7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the
+      SCTP Packet should be silently discarded.  Otherwise,
+
+   8) The receiver should respond to the sender of the OOTB packet with
+      an ABORT.  When sending the ABORT, the receiver of the OOTB packet
+      MUST fill in the Verification Tag field of the outbound packet
+      with the value found in the Verification Tag field of the OOTB
+      packet and set the T-bit in the Chunk Flags to indicate that no
+      TCB was found.  After sending this ABORT, the receiver of the OOTB
+      packet shall discard the OOTB packet and take no further action.
+
+8.5 Verification Tag
+
+   The Verification Tag rules defined in this section apply when sending
+   or receiving SCTP packets which do not contain an INIT, SHUTDOWN
+   COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk.
+   The rules for sending and receiving SCTP packets containing one of
+   these chunk types are discussed separately in Section 8.5.1.
+
+   When sending an SCTP packet, the endpoint MUST fill in the
+   Verification Tag field of the outbound packet with the tag value in
+   the Initiate Tag parameter of the INIT or INIT ACK received from its
+   peer.
+
+   When receiving an SCTP packet, the endpoint MUST ensure that the
+   value in the Verification Tag field of the received SCTP packet
+   matches its own Tag.  If the received Verification Tag value does not
+   match the receiver's own tag value, the receiver shall silently
+   discard the packet and shall not process it any further except for
+   those cases listed in Section 8.5.1 below.
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 96]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+8.5.1 Exceptions in Verification Tag Rules
+
+   A) Rules for packet carrying INIT:
+
+      -  The sender MUST set the Verification Tag of the packet to 0.
+
+      -  When an endpoint receives an SCTP packet with the Verification
+         Tag set to 0, it should verify that the packet contains only an
+         INIT chunk.  Otherwise, the receiver MUST silently discard the
+         packet.
+
+   B) Rules for packet carrying ABORT:
+
+      -  The endpoint shall always fill in the Verification Tag field of
+         the outbound packet with the destination endpoint's tag value
+         if it is known.
+
+      -  If the ABORT is sent in response to an OOTB packet, the
+         endpoint MUST follow the procedure described in Section 8.4.
+
+      -  The receiver MUST accept the packet if the Verification Tag
+         matches either its own tag, OR the tag of its peer.  Otherwise,
+         the receiver MUST silently discard the packet and take no
+         further action.
+
+   C) Rules for packet carrying SHUTDOWN COMPLETE:
+
+      -  When sending a SHUTDOWN COMPLETE, if the receiver of the
+         SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
+         be used.  Only where no TCB exists should the sender use the
+         Verification Tag from the SHUTDOWN ACK.
+
+      -  The receiver of a SHUTDOWN COMPLETE shall accept the packet if
+         the Verification Tag field of the packet matches its own tag OR
+         it is set to its peer's tag and the T bit is set in the Chunk
+         Flags. Otherwise, the receiver MUST silently discard the packet
+         and take no further action.  An endpoint MUST ignore the
+         SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
+
+   D) Rules for packet carrying a COOKIE ECHO
+
+      -  When sending a COOKIE ECHO, the endpoint MUST use the value of
+         the Initial Tag received in the INIT ACK.
+
+      -  The receiver of a COOKIE ECHO follows the procedures in Section
+         5.
+
+
+
+
+
+Stewart, et al.             Standards Track                    [Page 97]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   E) Rules for packet carrying a SHUTDOWN ACK
+
+      -  If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the
+         procedures in section 8.4 SHOULD be followed, in other words it
+         should be treated as an Out Of The Blue packet.
+
+9. Termination of Association
+
+   An endpoint should terminate its association when it exits from
+   service.  An association can be terminated by either abort or
+   shutdown.  An abort of an association is abortive by definition in
+   that any data pending on either end of the association is discarded
+   and not delivered to the peer.  A shutdown of an association is
+   considered a graceful close where all data in queue by either
+   endpoint is delivered to the respective peers.  However, in the case
+   of a shutdown, 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 sending or receiving the SHUTDOWN chunk.
+
+9.1 Abort of an Association
+
+   When an endpoint decides to abort an existing association, it shall
+   send an ABORT chunk to its peer endpoint.  The sender MUST fill in
+   the peer's Verification Tag in the outbound packet and MUST NOT
+   bundle any DATA chunk with the ABORT.
+
+   An endpoint MUST NOT respond to any received packet that contains an
+   ABORT chunk (also see Section 8.4).
+
+   An endpoint receiving an ABORT shall apply the special Verification
+   Tag check rules described in Section 8.5.1.
+
+   After checking the Verification Tag, the receiving endpoint shall
+   remove the association from its record, and 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 of
+   an endpoint in an association can gracefully close the association.
+   This will allow all outstanding DATA chunks from the peer of the
+   shutdown initiator to be delivered before the association terminates.
+
+   Upon receipt of the SHUTDOWN primitive from its upper layer, the
+   endpoint enters SHUTDOWN-PENDING state and remains there until all
+   outstanding data has been acknowledged by its peer.  The endpoint
+
+
+
+Stewart, et al.             Standards Track                    [Page 98]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   accepts no new data from its upper layer, but retransmits data to the
+   far end if necessary to fill gaps.
+
+   Once all its outstanding data has been acknowledged, the endpoint
+   shall send a SHUTDOWN chunk to its peer including in the Cumulative
+   TSN Ack field the last sequential TSN it has received from the peer.
+   It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT
+   state.  If the timer expires, the endpoint must re-send the SHUTDOWN
+   with the updated last sequential TSN received from its peer.
+
+   The rules in Section 6.3 MUST be followed to determine the proper
+   timer value for T2-shutdown.  To indicate any gaps in TSN, the
+   endpoint may also bundle a SACK with the SHUTDOWN chunk in the same
+   SCTP packet.
+
+   An endpoint should limit the number of retransmissions of the
+   SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
+   If this threshold is exceeded the endpoint should destroy the TCB and
+   MUST report the peer endpoint unreachable to the upper layer (and
+   thus the 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 endpoint's retransmission count and restart
+   the T2-Shutdown timer,  giving its peer ample opportunity to transmit
+   all of its queued DATA chunks that have not yet been sent.
+
+   Upon the reception of the SHUTDOWN, the peer endpoint shall
+
+   -  enter the SHUTDOWN-RECEIVED state,
+
+   -  stop accepting new data from its SCTP user
+
+   -  verify, by checking the Cumulative TSN Ack field of the chunk,
+      that all its outstanding DATA chunks have been received by the
+      SHUTDOWN sender.
+
+   Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT
+   send a SHUTDOWN in response to a ULP request, and should discard
+   subsequent SHUTDOWN chunks.
+
+   If there are still outstanding DATA chunks left, the SHUTDOWN
+   receiver shall continue to follow normal data transmission procedures
+   defined in Section 6 until all outstanding DATA chunks are
+   acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
+   from its SCTP user.
+
+   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
+   respond to each received packet containing one or more DATA chunk(s)
+   with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
+
+
+
+Stewart, et al.             Standards Track                    [Page 99]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
+   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
+   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
+   endpoint must re-send the SHUTDOWN ACK.
+
+   The sender of the SHUTDOWN ACK should limit the number of
+   retransmissions of the SHUTDOWN ACK chunk to the protocol parameter '
+   Association.Max.Retrans'.  If this threshold is exceeded the endpoint
+   should destroy the TCB and may report the peer endpoint unreachable
+   to the upper layer (and thus the association enters the CLOSED
+   state).
+
+   Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
+   the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer,
+   and remove all record of the association.
+
+   Upon reception of the SHUTDOWN COMPLETE chunk the endpoint will
+   verify that it is in SHUTDOWN-ACK-SENT state, if it is not the chunk
+   should be discarded.  If the endpoint is in the SHUTDOWN-ACK-SENT
+   state the endpoint should stop the T2-shutdown timer and remove all
+   knowledge of the association (and thus the association enters the
+   CLOSED state).
+
+   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 SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or
+   SHUTDOWN-ACK-SENT state.
+
+   If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT
+   chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and
+   destination transport addresses (either in the IP addresses or in the
+   INIT chunk) that belong to this association, it should discard the
+   INIT chunk and retransmit the SHUTDOWN ACK chunk.
+
+   Note: Receipt of an INIT with the same source and destination IP
+   addresses as used in transport addresses assigned to an endpoint but
+   with a different port number indicates the initialization of a
+   separate association.
+
+   The sender of the INIT or COOKIE ECHO 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 same tag that was received in the SHUTDOWN ACK packet.  This is
+   considered an Out of the Blue packet as defined in Section 8.4.  The
+   sender of the INIT lets T1-init continue running and remains in the
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 100]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   COOKIE-WAIT or COOKIE-ECHOED state.  Normal T1-init timer expiration
+   will cause the INIT or COOKIE chunk to be retransmitted and thus
+   start a new association.
+
+   If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the
+   SHUTDOWN chunk SHOULD be silently discarded.
+
+   If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN
+   chunk from its peer, the 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 SHUTDOWN-ACK-SENT state and receives a
+   SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN
+   COMPLETE chunk to its peer, and remove all record of the 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 of
+   services to guarantee that all SCTP implementations can support 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 the basic functions the
+   SCTP must perform to support inter-process communication.  Individual
+   implementations must define their own exact format, and may provide
+   combinations or subsets of the basic functions in single calls.
+
+   A) Initialize
+
+   Format: INITIALIZE ([local port], [local eligible address list]) ->
+   local SCTP instance name
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 101]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   This primitive allows SCTP to initialize its internal data structures
+   and allocate necessary resources for setting up its operation
+   environment.  Once SCTP is initialized, ULP can communicate directly
+   with other endpoints without re-invoking this primitive.
+
+   SCTP will return a local SCTP instance name to the ULP.
+
+   Mandatory attributes:
+
+   None.
+
+   Optional attributes:
+
+   The following types of attributes may be passed along with the
+   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
+      included, all IP addresses assigned to the host should be used by
+      the local endpoint.
+
+   IMPLEMENTATION NOTE: If this optional attribute is supported by an
+   implementation, it will be the responsibility of the implementation
+   to enforce that the IP source address field of any SCTP packets sent
+   out by this endpoint contains one of the IP addresses indicated in
+   the local eligible address list.
+
+   B) Associate
+
+   Format: ASSOCIATE(local SCTP instance name, destination transport addr,
+           outbound stream count)
+   -> association id [,destination transport addr list] [,outbound stream
+      count]
+
+   This primitive allows the upper layer to initiate an association to a
+   specific peer endpoint.
+
+   The peer endpoint shall be specified by one of the transport
+   addresses which defines the endpoint (see Section 1.4).  If the local
+   SCTP instance has not been initialized, the ASSOCIATE is considered
+   an error.
+
+   An association id, which is a 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.
+
+
+
+Stewart, et al.             Standards Track                   [Page 102]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Other association parameters may be returned, including the complete
+   destination transport addresses of the peer as well as the outbound
+   stream count of the local endpoint.  One of the transport address
+   from the returned destination addresses will be selected by the local
+   endpoint as default primary path for sending SCTP packets to this
+   peer.  The returned "destination transport addr list" can be used by
+   the ULP to change the default primary path or to force sending a
+   packet to a specific transport address.
+
+   IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
+   blocking function call, the ASSOCIATE primitive can return
+   association parameters in addition to the association id upon
+   successful establishment.  If ASSOCIATE primitive is implemented as a
+   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 INITIALIZE operation.
+
+   o  destination transport addr - specified as one of the transport
+      addresses of the peer endpoint with which the association is to be
+      established.
+
+   o  outbound stream count - the number of outbound streams the 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 peer.  The association will be terminated only
+   after the peer acknowledges all the SCTP packets sent.  A success
+   code will be returned on successful termination of the association.
+   If attempting to terminate the association results in a failure, an
+   error code shall be returned.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 103]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Optional attributes:
+
+   None.
+
+   D) Abort
+
+   Format: ABORT(association id [, cause code])
+   -> result
+
+   Ungracefully closes an association.  Any locally queued user data
+   will be discarded and an ABORT chunk is sent to the peer.  A success
+   code will be returned on successful abortion of the association.  If
+   attempting to abort the association results in a failure, an error
+   code shall be returned.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   Optional attributes:
+
+   o  cause code - reason of the abort to be passed to the 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 main method to send user data via SCTP.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   o  buffer address - the location where the user message to be
+      transmitted is stored;
+
+   o  byte count - The size of the user data in number of bytes;
+
+   Optional attributes:
+
+   o  context - an optional 32 bit integer that will be carried in the
+      sending failure notification to the ULP if the transportation of
+      this User Message fails.
+
+
+
+Stewart, et al.             Standards Track                   [Page 104]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  stream id - to indicate which stream to send the data on.  If not
+      specified, stream 0 will be used.
+
+   o  life time - specifies the life time 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 if the 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 has attempted to transmit a chunk
+      before the life time expired.
+
+   IMPLEMENTATION NOTE: In order to better support the data lifetime
+   option, the transmitter may hold back the assigning of the TSN number
+   to an outbound DATA chunk to the last moment.  And, for
+   implementation simplicity, once a TSN number has been assigned the
+   sender should consider the send of this DATA chunk as committed,
+   overriding any lifetime option attached to the DATA chunk.
+
+   o  destination transport address - specified as one of the
+      destination transport addresses of the peer endpoint to which this
+      packet should be sent.  Whenever possible, SCTP should use this
+      destination transport address for sending the packets, instead of
+      the current primary path.
+
+   o  unorder flag - this flag, if present, indicates that the user
+      would like the data delivered in an unordered fashion to the peer
+      (i.e., the U flag is set to 1 on all DATA chunks carrying this
+      message).
+
+   o  no-bundle flag - instructs SCTP not to bundle this user data with
+      other outbound DATA chunks.  SCTP MAY still bundle even when this
+      flag is present, when faced with network congestion.
+
+   o  payload protocol-id - A 32 bit unsigned integer that is to be
+      passed to the peer indicating the type of payload protocol data
+      being transmitted.  This value is passed as opaque data by SCTP.
+
+   F) Set Primary
+
+   Format: SETPRIMARY(association id, destination transport address,
+                      [source transport address] )
+   -> result
+
+   Instructs the local SCTP to use the specified destination transport
+   address as primary path for sending packets.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 105]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   The result of attempting this operation shall be returned.  If the
+   specified 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 be returned.
+
+   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, which should be used as primary
+      address for sending packets.  This overrides the current primary
+      address information maintained by the local SCTP endpoint.
+
+   Optional attributes:
+
+   o  source transport address - optionally, some implementations may
+      allow you to set the default source address 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 one available.  The
+   size of the message read, in bytes, 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:
+
+   o  association id - local handle to the SCTP association
+
+   o  buffer address - the memory location indicated by the ULP to store
+      the received message.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 106]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  buffer size - the maximum size of data to be received, in bytes.
+
+   Optional attributes:
+
+   o  stream 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 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 32 bit 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.
+
+   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 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 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.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 107]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   I) Change Heartbeat
+
+   Format: CHANGEHEARTBEAT(association id, destination transport address,
+           new state [,interval])
+   -> result
+
+   Instructs the local endpoint to enable or disable heartbeat on the
+   specified destination transport address.
+
+   The result of attempting this operation shall be returned.
+
+   Note: Even when enabled, heartbeat 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 heartbeat for this destination
+      transport address (either enabled or disabled).
+
+   Optional attributes:
+
+   o  interval - if present, indicates the frequency of the heartbeat if
+      this is to enable heartbeat on a destination transport address.
+      This value is added to the RTO of the destination transport
+      address. This value, if present, effects all destinations.
+
+   J) Request HeartBeat
+
+   Format: REQUESTHEARTBEAT(association id, destination transport
+           address)
+   -> result
+
+   Instructs the local endpoint to perform a HeartBeat on the specified
+   destination transport address of the given association.  The returned
+   result should indicate whether the transmission of the HEARTBEAT
+   chunk to the destination address is successful.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   o  destination transport address - the transport address of the
+      association on which a heartbeat should be issued.
+
+
+
+Stewart, et al.             Standards Track                   [Page 108]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   K) Get SRTT Report
+
+   Format: GETSRTTREPORT(association id, destination transport address)
+   -> srtt result
+
+   Instructs the local SCTP to report the current SRTT measurement on
+   the specified destination transport address of the given association.
+   The returned result can be an integer containing the most recent SRTT
+   in milliseconds.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   o  destination transport address - the transport address of the
+      association on which the SRTT measurement is to be reported.
+
+   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 the specified
+   destination address.
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   o  destination transport address - the transport address of the
+      association on which the failure detection threshold is to be 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.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 109]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Mandatory attributes:
+
+   o  association id - local handle to the SCTP association
+
+   o  protocol parameter list - 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 address - some of the protocol parameters
+      may be set on a per destination transport address basis.
+
+   N) Receive unsent message
+
+   Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
+           [,stream id] [, stream sequence number] [,partial flag]
+           [,payload protocol-id])
+
+   o  data retrieval id - The identification passed to the 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 bytes.
+
+   Optional attributes:
+
+   o  stream id - this is a return value that is set to  indicate
+      which stream the data was sent to.
+
+   o  stream sequence number - this value is returned indicating
+      the stream sequence number that was associated with the 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 - The 32 bit unsigned integer that was sent to
+      be sent to the peer indicating the type of payload protocol of the
+      received data.
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 110]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   O)  Receive unacknowledged message
+
+   Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,
+           [,stream id] [, stream sequence number] [,partial flag]
+           [,payload protocol-id])
+
+   o  data retrieval id - The identification passed to the 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 bytes.
+
+   Optional attributes:
+
+   o  stream id - this is a return value that is set to  indicate which
+      stream the data was sent to.
+
+   o  stream sequence number - this value is returned indicating the
+      stream sequence number that was associated with the 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 - The 32 bit unsigned integer that was sent to
+      be sent to the peer indicating the type of payload protocol of the
+      received data.
+
+   P) Destroy SCTP instance
+
+   Format: DESTROY(local SCTP instance name)
+
+   o  local SCTP instance name - this is the value that was passed to
+      the application in the initialize primitive and it indicates which
+      SCTP instance to be 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.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 111]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   IMPLEMENTATION NOTE: In some cases this may be done through a
+   separate socket or error channel.
+
+   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 - 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 10.1).
+
+   C) NETWORK STATUS CHANGE notification
+
+   When a destination transport address is marked inactive (e.g., when
+   SCTP detects a failure), or marked 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.             Standards Track                   [Page 112]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 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
+      as 'outbound stream count').
+
+   E) COMMUNICATION LOST notification
+
+   When SCTP loses communication to an endpoint completely (e.g., via
+   Heartbeats) or detects that the endpoint has performed an abort
+   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 has occurred; The status
+              may indicate a failure OR a normal termination event
+              occurred in response to a shutdown or abort request.
+
+   The following may be passed with the notification:
+
+   o  data retrieval id - an identification used to retrieve unsent and
+      unacknowledged data.
+
+   o  last-acked - the TSN last acked by that peer endpoint;
+
+
+
+Stewart, et al.             Standards Track                   [Page 113]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   o  last-sent - the TSN last sent to that peer endpoint;
+
+   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.
+
+   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
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 114]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+11.2 SCTP Responses To Potential Threats
+
+   SCTP may potentially be used in a wide variety of risk situations.
+   It is important for operator(s) of systems running SCTP to analyze
+   their particular situations and decide on the appropriate counter-
+   measures.
+
+   Operators of systems running SCTP should consult [RFC2196] for
+   guidance in securing their site.
+
+11.2.1 Countering Insider Attacks
+
+   The principles of [RFC2196] should be applied to minimize the risk of
+   theft of information or sabotage by insiders.  Such procedures
+   include publication of security policies, control of access at the
+   physical, software, and network levels, and separation of services.
+
+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 integrity protection is required.  If this additional
+   protection were provided in the application-layer, the SCTP header
+   would remain vulnerable to deliberate integrity attacks.  While the
+   existing SCTP mechanisms for detection of packet replays are
+   considered sufficient for normal operation, stronger protections are
+   needed to protect SCTP when the operating environment contains
+   significant risk of deliberate attacks from a sophisticated
+   adversary.
+
+   In order to promote software code-reuse, to avoid re-inventing the
+   wheel, and to avoid gratuitous complexity to SCTP, the IP
+   Authentication Header [RFC2402] SHOULD be used when the 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
+   might be considered.  As with the supplementary checksum service,
+   user data encryption MAY be performed by the SCTP user application.
+
+
+
+Stewart, et al.             Standards Track                   [Page 115]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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
+   might include the masking of IP addresses and ports.  In this case
+   ESP SHOULD be used instead of application-level confidentiality.  If
+   ESP is used to protect confidentiality of SCTP traffic, an ESP
+   cryptographic transform that includes cryptographic integrity
+   protection MUST be used, because if there is a confidentiality threat
+   there will also be a strong integrity threat.
+
+   Whenever ESP is in use, application-level encryption is not generally
+   required.
+
+   Regardless of where confidentiality is provided, the ISAKMP [RFC2408]
+   and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key
+   management.
+
+   Operators should consult [RFC2401] for more information on the
+   security services available at and 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.  Blind denial of service attacks may take the form
+   of flooding, masquerade, or improper monopolization of services.
+
+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 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
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 116]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   -  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 to prevent
+   insertion of extraneous 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.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 117]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+11.2.4.2 Blind 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.
+
+   SCTP reduces the risk of blind masquerade attacks through IP spoofing
+   by use of the four-way startup handshake.  Man-in-the-middle
+   masquerade attacks are discussed in Section 11.3 below.  Because the
+   initial exchange is memoryless, no lockout mechanism is triggered by
+   blind 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 INIT ACK
+   containing the State Cookie.  SCTP protects against insertion of
+   extraneous packets into the flow of an established association by use
+   of the 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.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 118]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 packets
+   passing through a target SCTP association in real time.
+
+   The interception attack is countered by the confidentiality measures
+   discussed in 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
+   Verification Tag.  The 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 packets sent
+   and received in an association.  For example, the INIT ACK will have
+   sufficient information sent on the wire for an adversary in the
+   middle to hijack an existing SCTP 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
+   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 11.2.1.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 119]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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 or as an exhaustive list of all parameters inside an
+   SCTP TCB.  Each implementation may need its own additional parameters
+   for optimization.
+
+12.1 Parameters necessary for the SCTP instance
+
+   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:   A secret key used by this endpoint to compute the MAC.
+                 This SHOULD be a cryptographic quality random number
+                 with a sufficient length.  Discussion in [RFC1750] can
+                 be helpful in selection of the key.
+
+   Address 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 chunks.
+
+   SCTP Port:    The local SCTP port number the endpoint is bound to.
+
+12.2 Parameters necessary per association (i.e. the TCB)
+
+   Peer        : Tag value to be sent in every packet and is received
+   Verification: in the INIT or INIT ACK chunk.
+   Tag         :
+
+   My          : Tag expected in every inbound packet and sent in the
+   Verification: INIT or INIT ACK chunk.
+   Tag         :
+
+   State       : A state variable indicating what state the association
+               : is in, i.e. COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
+               : 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.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 120]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 and is used to associate an inbound 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
+   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    : The next TSN number to be assigned to a new DATA chunk.
+               : This is sent in the INIT or INIT ACK chunk to the peer
+               : and incremented each time a DATA chunk is assigned a
+               : TSN (normally just prior to transmit or during
+               : fragmentation).
+
+   Last Rcvd   : This is the last TSN received in sequence.  This value
+   TSN         : is set initially by taking the peer's Initial TSN,
+               : received in the INIT or 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
+               : Last Rcvd TSN).  If no gaps exist, i.e. no out of order
+               : 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.
+
+   Ack State   : This flag indicates if the next received packet
+               : is to be responded to with a SACK.  This is initialized
+               : to 0.  When a packet is received it is incremented.
+               : If this value reaches 2 or more, a SACK is sent and the
+               : value is reset to 0.  Note: This is used only when no
+               : DATA chunks are received out of order.  When DATA chunks
+               : are out of order, SACK's are not delayed (see Section
+               : 6).
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 121]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 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 6.2.2)
+
+   state       : The current state of this destination, i.e. DOWN, UP,
+               : ALLOW-HB, NO-HEARTBEAT, etc.
+
+   PMTU        : The current known path MTU.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 122]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Per         : A timer used by each destination.
+   Destination :
+   Timer       :
+
+   RTO-Pending : A flag used to track if one of the DATA chunks sent to
+                 this address is currently being used to compute a
+                 RTT.  If this flag is 0, the next 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 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 DATA chunks.
+
+   In Queue    : A queue of inbound DATA chunks.
+
+13. IANA Considerations
+
+   This protocol will require port reservation like TCP for the use of
+   "well known" servers within the Internet.  All current TCP ports
+   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
+       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 definition and use of new chunk types is an integral part of
+   SCTP.  Thus, new chunk types are assigned by IANA through an IETF
+   Consensus action as defined in [RFC2434].
+
+   The documentation for a new chunk code type must include the
+   following information:
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 123]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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 of the new chunk type
+      within the operation of the protocol.
+
+   The last chunk type (255) is reserved for future extension if
+   necessary.
+
+13.2 IETF-defined Chunk Parameter Extension
+
+   The assignment of new chunk parameter type codes is done through an
+   IETF Consensus action as defined in [RFC2434].  Documentation of the
+   chunk parameter MUST contain 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 11 to 65535
+   through a Specification Required action as defined in [RFC2434].
+   Provided documentation 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 ERROR (or ABORT) with this cause code.
+
+   c) Expected action by the SCTP endpoint which receives an ERROR (or
+      ABORT) chunk containing this cause code.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 124]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   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.10, i.e.:
+
+   -- first two bytes contain the cause code value
+   -- last two bytes contain length of the Cause Parameter.
+
+13.4 Payload Protocol Identifiers
+
+   Except for value 0 which is reserved by SCTP to indicate 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., 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        - 60  seconds
+   Association.Max.Retrans  - 10 attempts
+   Path.Max.Retrans         - 5  attempts (per destination address)
+   Max.Init.Retransmits     - 8  attempts
+   HB.interval              - 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.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 125]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+15. Acknowledgements
+
+   The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band,
+   Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R.
+   Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege,
+   Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David
+   Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, 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, La Monte Yarroll,
+   and many others for their invaluable comments.
+
+16.  Authors' Addresses
+
+   Randall R. Stewart
+   24 Burning Bush Trail.
+   Crystal Lake, IL 60012
+   USA
+
+   Phone: +1-815-477-2127
+   EMail: rrs@cisco.com
+
+
+   Qiaobing Xie
+   Motorola, Inc.
+   1501 W. Shure Drive, #2309
+   Arlington Heights, IL 60004
+   USA
+
+   Phone: +1-847-632-3028
+   EMail: qxie1@email.mot.com
+
+
+   Ken Morneault
+   Cisco Systems Inc.
+   13615 Dulles Technology Drive
+   Herndon, VA. 20171
+   USA
+
+   Phone: +1-703-484-3323
+   EMail: kmorneau@cisco.com
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 126]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Chip Sharp
+   Cisco Systems Inc.
+   7025 Kit Creek Road
+   Research Triangle Park, NC  27709
+   USA
+
+   Phone: +1-919-392-3121
+   EMail: chsharp@cisco.com
+
+
+   Hanns Juergen Schwarzbauer
+   SIEMENS AG
+   Hofmannstr. 51
+   81359 Munich
+   Germany
+
+   Phone: +49-89-722-24236
+   EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
+
+
+   Tom Taylor
+   Nortel Networks
+   1852 Lorraine Ave.
+   Ottawa, Ontario
+   Canada K1H 6Z8
+
+   Phone: +1-613-736-0961
+   EMail: taylor@nortelnetworks.com
+
+
+   Ian Rytina
+   Ericsson Australia
+   37/360 Elizabeth Street
+   Melbourne, Victoria 3000
+   Australia
+
+   Phone: +61-3-9301-6164
+   EMail: ian.rytina@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 127]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   Malleswar Kalla
+   Telcordia Technologies
+   3 Corporate Place
+   PYA-2J-341
+   Piscataway, NJ  08854
+   USA
+
+   Phone: +1-732-699-3728
+   EMail: mkalla@telcordia.com
+
+   Lixia Zhang
+   UCLA Computer Science Department
+   4531G Boelter Hall
+   Los Angeles, CA 90095-1596
+   USA
+
+   Phone: +1-310-825-2695
+   EMail: lixia@cs.ucla.edu
+
+   Vern Paxson
+   ACIRI
+   1947 Center St., Suite 600,
+   Berkeley, CA 94704-1198
+   USA
+
+   Phone: +1-510-666-2882
+   EMail: vern@aciri.org
+
+17. References
+
+   [RFC768]   Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC
+              768, August 1980.
+
+   [RFC793]   Postel, J. (ed.), "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC1123]  Braden, R., "Requirements for Internet hosts - application
+              and support", STD 3, RFC 1123, October 1989.
+
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+              November 1990.
+
+   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+              1700, October 1994.
+
+   [RFC1981]  McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, August 1996.
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 128]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, 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 R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401,  November 1998.
+
+   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+              2402, November 1998.
+
+   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, November 1998.
+
+   [RFC2408]  Maughan, D., Schertler, M., Schneider, M. and J. Turner,
+              "Internet Security Association and Key Management
+              Protocol", RFC 2408, November 1998.
+
+   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2581]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
+              Control", RFC 2581, April 1999.
+
+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.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 129]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   [RFC1950]  Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
+              Specification version 3.3", RFC 1950, May 1996.
+
+   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
+              Hashing for Message Authentication", RFC 2104, March 1997.
+
+   [RFC2196]  Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
+              September 1997.
+
+   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
+              Protocol", RFC 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 130]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+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
+   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
+   an endpoint SHOULD add to the INIT and or 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 = 32768      |     Parameter Length = 4      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   ECN-Echo:
+
+   RFC 2481 details a specific bit for a receiver to send back in its
+   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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Chunk Type=12 | Flags=00000000|    Chunk Length = 8           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Lowest TSN Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Note: The ECNE is considered a Control chunk.
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 131]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   CWR:
+
+   RFC 2481 details a specific bit for a sender to send in the header of
+   its next outbound 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 ECNE chunk.  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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Chunk Type=13 | Flags=00000000|    Chunk Length = 8           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Lowest TSN Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Note: The CWR is considered a Control chunk.
+
+Appendix B Alder 32 bit checksum calculation
+
+   The Adler-32 checksum calculation given in this appendix is copied from
+   [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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 132]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+   &      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);
+      }
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 133]
+
+RFC 2960          Stream Control Transmission Protocol      October 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.             Standards Track                   [Page 134]
+