7508 lines
291 KiB
Plaintext
7508 lines
291 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|