tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4960

 Errata 
Proposed STD
Pages: 152
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TSVWG

Stream Control Transmission Protocol

Part 1 of 7, p. 1 to 15
None       Next RFC Part

Obsoletes:    2960    3309
Updated by:    6096    6335    7053


Top       ToC       Page 1 
Network Working Group                                    R. Stewart, Ed.
Request for Comments: 4960                                September 2007
Obsoletes: 2960, 3309
Category: Standards Track


                  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.

Abstract

   This document obsoletes RFC 2960 and RFC 3309.  It describes the
   Stream Control Transmission Protocol (SCTP).  SCTP is designed to
   transport Public Switched Telephone Network (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,

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

Top       Page 2 
Table of Contents

   1. Introduction ....................................................5
      1.1. Motivation .................................................5
      1.2. Architectural View of SCTP .................................6
      1.3. Key Terms ..................................................6
      1.4. Abbreviations .............................................10
      1.5. Functional View of SCTP ...................................10
           1.5.1. Association Startup and Takedown ...................11
           1.5.2. Sequenced Delivery within Streams ..................12
           1.5.3. User Data Fragmentation ............................12
           1.5.4. Acknowledgement and Congestion Avoidance ...........12
           1.5.5. Chunk Bundling .....................................13
           1.5.6. Packet Validation ..................................13
           1.5.7. Path Management ....................................13
      1.6. Serial Number Arithmetic ..................................14
      1.7. Changes from RFC 2960 .....................................15
   2. Conventions ....................................................15
   3. SCTP Packet Format .............................................15
      3.1. SCTP Common Header Field Descriptions .....................16
      3.2. Chunk Field Descriptions ..................................17
           3.2.1. Optional/Variable-Length Parameter Format ..........19
           3.2.2. Reporting of Unrecognized Parameters ...............21
      3.3. SCTP Chunk Definitions ....................................21
           3.3.1. Payload Data (DATA) (0) ............................22
           3.3.2. Initiation (INIT) (1) ..............................24
                  3.3.2.1. Optional/Variable-Length
                           Parameters in INIT ........................27
           3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30
                  3.3.3.1. Optional or Variable-Length Parameters ....33
           3.3.4. Selective Acknowledgement (SACK) (3) ...............34
           3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38
           3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39
           3.3.7. Abort Association (ABORT) (6) ......................40
           3.3.8. Shutdown Association (SHUTDOWN) (7) ................41
           3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41
           3.3.10. Operation Error (ERROR) (9) .......................42
                  3.3.10.1. Invalid Stream Identifier (1) ............44
                  3.3.10.2. Missing Mandatory Parameter (2) ..........44
                  3.3.10.3. Stale Cookie Error (3) ...................45
                  3.3.10.4. Out of Resource (4) ......................45
                  3.3.10.5. Unresolvable Address (5) .................46
                  3.3.10.6. Unrecognized Chunk Type (6) ..............46
                  3.3.10.7. Invalid Mandatory Parameter (7) ..........47
                  3.3.10.8. Unrecognized Parameters (8) ..............47
                  3.3.10.9. No User Data (9) .........................48
                  3.3.10.10. Cookie Received While Shutting
                             Down (10) ...............................48

Top      ToC       Page 3 
                  3.3.10.11. Restart of an Association with
                             New Addresses (11) ......................49
                  3.3.10.12. User-Initiated Abort (12) ...............49
                  3.3.10.13. Protocol Violation (13) .................50
           3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50
           3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51
           3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51
   4. SCTP Association State Diagram .................................52
   5. Association Initialization .....................................56
      5.1. Normal Establishment of an Association ....................56
           5.1.1. Handle Stream Parameters ...........................58
           5.1.2. Handle Address Parameters ..........................58
           5.1.3. Generating State Cookie ............................61
           5.1.4. State Cookie Processing ............................62
           5.1.5. State Cookie Authentication ........................62
           5.1.6. An Example of Normal Association Establishment .....64
      5.2. Handle Duplicate or Unexpected INIT, INIT ACK,
           COOKIE ECHO, and ..........................................65
           5.2.1. INIT Received in COOKIE-WAIT or
                  COOKIE-ECHOED State (Item B) .......................66
           5.2.2. Unexpected INIT in States Other than
                  CLOSED, COOKIE-ECHOED, .............................66
           5.2.3. Unexpected INIT ACK ................................67
           5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67
                  5.2.4.1. An Example of a Association Restart .......69
           5.2.5. Handle Duplicate COOKIE-ACK. .......................71
           5.2.6. Handle Stale COOKIE Error ..........................71
      5.3. Other Initialization Issues ...............................72
           5.3.1. Selection of Tag Value .............................72
      5.4. Path Verification .........................................72
   6. User Data Transfer .............................................73
      6.1. Transmission of DATA Chunks ...............................75
      6.2. Acknowledgement on Reception of DATA Chunks ...............78
           6.2.1. Processing a Received SACK .........................81
      6.3. Management of Retransmission Timer ........................83
           6.3.1. RTO Calculation ....................................83
           6.3.2. Retransmission Timer Rules .........................85
           6.3.3. Handle T3-rtx Expiration ...........................86
      6.4. Multi-Homed SCTP Endpoints ................................87
           6.4.1. Failover from an Inactive Destination Address ......88
      6.5. Stream Identifier and Stream Sequence Number ..............88
      6.6. Ordered and Unordered Delivery ............................88
      6.7. Report Gaps in Received DATA TSNs .........................89
      6.8. CRC32c Checksum Calculation ...............................90
      6.9. Fragmentation and Reassembly ..............................91
      6.10. Bundling .................................................92
   7. Congestion Control .............................................93
      7.1. SCTP Differences from TCP Congestion Control ..............94

Top      ToC       Page 4 
      7.2. SCTP Slow-Start and Congestion Avoidance ..................95
           7.2.1. Slow-Start .........................................96
           7.2.2. Congestion Avoidance ...............................97
           7.2.3. Congestion Control .................................98
           7.2.4. Fast Retransmit on Gap Reports .....................98
      7.3. Path MTU Discovery .......................................100
   8. Fault Management ..............................................100
      8.1. Endpoint Failure Detection ...............................100
      8.2. Path Failure Detection ...................................101
      8.3. Path Heartbeat ...........................................102
      8.4. Handle "Out of the Blue" Packets .........................104
      8.5. Verification Tag .........................................105
           8.5.1. Exceptions in Verification Tag Rules ..............105
   9. Termination of Association ....................................106
      9.1. Abort of an Association ..................................107
      9.2. Shutdown of an Association ...............................107
   10. Interface with Upper Layer ...................................110
      10.1. ULP-to-SCTP .............................................110
      10.2. SCTP-to-ULP .............................................120
   11. Security Considerations ......................................123
      11.1. Security Objectives .....................................123
      11.2. SCTP Responses to Potential Threats .....................124
           11.2.1. Countering Insider Attacks .......................124
           11.2.2. Protecting against Data Corruption in the
                   Network ..........................................124
           11.2.3. Protecting Confidentiality .......................124
           11.2.4. Protecting against Blind
                   Denial-of-Service Attacks ........................125
                  11.2.4.1. Flooding ................................125
                  11.2.4.2. Blind Masquerade ........................126
                  11.2.4.3. Improper Monopolization of Services .....127
      11.3. SCTP Interactions with Firewalls ........................127
      11.4. Protection of Non-SCTP-Capable Hosts ....................128
   12. Network Management Considerations ............................128
   13. Recommended Transmission Control Block (TCB) Parameters ......129
      13.1. Parameters Necessary for the SCTP Instance ..............129
      13.2. Parameters Necessary per Association (i.e., the TCB) ....129
      13.3. Per Transport Address Data ..............................131
      13.4. General Parameters Needed ...............................132
   14. IANA Considerations ..........................................132
      14.1. IETF-defined Chunk Extension ............................132
      14.2. IETF-Defined Chunk Parameter Extension ..................133
      14.3. IETF-Defined Additional Error Causes ....................133
      14.4. Payload Protocol Identifiers ............................134
      14.5. Port Numbers Registry ...................................134
   15. Suggested SCTP Protocol Parameter Values .....................136
   16. Acknowledgements .............................................137
   Appendix A. Explicit Congestion Notification .....................139

Top      ToC       Page 5 
   Appendix B. CRC32c Checksum Calculation ..........................140
   Appendix C. ICMP Handling ........................................142
   References .......................................................149
      Normative References ..........................................149
      Informative References ........................................150

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.

   This document obsoletes [RFC2960] and [RFC3309].

1.1.  Motivation

   TCP [RFC0793] 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
   [RFC0768].  The limitations that 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.

Top      ToC       Page 6 
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 that 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.3) to provide the other endpoint
   (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 that 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.  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 that a transmitting endpoint considers available for
      receiving user messages.

Top      ToC       Page 7 
   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.

   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 that 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 on
      which the message was sent.

   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.

Top      ToC       Page 8 
   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.

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

Top      ToC       Page 9 
   o  Slow-Start Threshold (ssthresh): An SCTP variable.  This is the
      threshold that 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 unidirectional 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.

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

   o  Tie-Tags: Two 32-bit random numbers that together make a 64-bit
      nonce.  These tags are used within a State Cookie and TCB so that
      a newly restarting association can be linked to the original
      association within the endpoint that did not restart and yet not
      reveal the true Verification Tags of an existing association.

   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
      a network-layer address, a transport-layer protocol, and a
      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) that 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.

Top      ToC       Page 10 
   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.  An 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.

1.4.  Abbreviations

   MAC    -  Message Authentication Code [RFC2104]

   RTO    -  Retransmission Timeout

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

Top      ToC       Page 11 
                           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.5.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 synchronization 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

Top      ToC       Page 12 
   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.5.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 8 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.5.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.5.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
   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.

Top      ToC       Page 13 
   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 Section 6
   and Section 7 for a detailed description of the protocol procedures
   associated with this function.

1.5.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 message 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.5.6.  Packet Validation

   A mandatory Verification Tag field and a 32-bit checksum field (see
   Appendix B for a description of the CRC32c 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 CRC32c 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 CRC32c checksum silently discards the
   packet.

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

Top      ToC       Page 14 
   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 startup, 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.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.
   All other arithmetic and comparisons in this document use normal
   arithmetic.

Top      ToC       Page 15 
1.7.  Changes from RFC 2960

   SCTP was originally defined in [RFC2960], which this document
   obsoletes.  Readers interested in the details of the various changes
   that this document incorporates are asked to consult [RFC4460].

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



(page 15 continued on part 2)

Next RFC Part