draft-ietf-sigtran-sctp-03.txt   draft-ietf-sigtran-sctp-04.txt 
skipping to change at line 20 skipping to change at page 10, line ?
Nortel Networks Nortel Networks
I. Rytina I. Rytina
Ericsson Ericsson
M. Kalla M. Kalla
Telcordia Telcordia
L. Zhang L. Zhang
UCLA UCLA
V. Paxson V. Paxson
ACIRI ACIRI
expires in six months October 20,1999 expires in six months November 24,1999
Simple Control Transmission Protocol Simple Control Transmission Protocol
<draft-ietf-sigtran-sctp-03.txt> <draft-ietf-sigtran-sctp-04.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Stewart, et al [Page 1]
Abstract Abstract
This document describes the Simple Control Transmission Protocol This document describes the Simple Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signalling messages over (SCTP). SCTP is designed to transport PSTN signalling messages over
IP networks, but is capable of broader application. IP networks, but is capable of broader application.
SCTP is an application-level datagram transfer protocol operating on SCTP is an application-level datagram transfer protocol operating on
top of an unreliable datagram service such as UDP. It offers the top of an unreliable datagram service such as UDP. It offers the
following services to its users: following services to its users:
skipping to change at line 62 skipping to change at page 10, line ?
with an option for order-of-arrival delivery of individual with an option for order-of-arrival delivery of individual
datagrams datagrams
-- optional multiplexing of user datagrams into SCTP datagrams, -- optional multiplexing of user datagrams into SCTP datagrams,
subject to MTU size restrictions subject to MTU size restrictions
-- enhanced reliability through support of multi-homing at either or -- enhanced reliability through support of multi-homing at either or
both ends of the association. both ends of the association.
The design of SCTP includes appropriate congestion avoidance behaviour The design of SCTP includes appropriate congestion avoidance behaviour
and resistance to flooding and masquerade attacks. and resistance to flooding and masquerade attacks.
Stewart, et al [Page 1] Stewart, et al [Page 2]
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction 1. Introduction.................................................. 5
1.1 Motivation 1.1 Motivation.................................................. 5
1.2 Architectural View of SCTP 1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP 1.3 Functional View of SCTP..................................... 6
1.3.1 Association Startup and Takedown 1.3.1 Association Startup and Takedown........................ 7
1.3.2 Sequenced Delivery within Streams 1.3.2 Sequenced Delivery within Streams....................... 8
1.3.3 User Data Segmentation 1.3.3 User Data Segmentation.................................. 8
1.3.4 Acknowledgement and Congestion Avoidance 1.3.4 Acknowledgement and Congestion Avoidance................ 8
1.3.5 Chunk Multiplex 1.3.5 Chunk Multiplex......................................... 9
1.3.6 Path Management 1.3.6 Path Management......................................... 9
1.3.7 Message Validation 1.3.7 Message Validation...................................... 9
1.4 Recapitulation of Key Terms 1.4 Recapitulation of Key Terms.................................10
1.5. Abbreviations 1.5. Abbreviations..............................................12
2. SCTP Datagram Format 2. SCTP Datagram Format..........................................12
2.1 SCTP Common Header Field Descriptions 2.1 SCTP Common Header Field Descriptions.......................13
2.2 Chunk Field Descriptions 2.2 Chunk Field Descriptions....................................14
2.2.1 Optional/Variable-length Parameter Format 2.2.1 Optional/Variable-length Parameter Format..............16
2.2.2 Vendor-Specific Extension Parameter Format 2.2.2 Vendor-Specific Extension Parameter Format..............16
2.3 SCTP Chunk Definitions 2.3 SCTP Chunk Definitions......................................18
2.3.1 Initiation (INIT) 2.3.1 Initiation (INIT).......................................18
2.3.1.1 Optional or Variable Length Parameters 2.3.1.1 Optional or Variable Length Parameters..............20
2.3.2 Initiation Acknowledgement (INIT ACK) 2.3.2 Initiation Acknowledgement (INIT ACK)...................23
2.3.2.1 Optional or Variable Length Parameters 2.3.2.1 Optional or Variable Length Parameters..............24
2.3.3 Selective Acknowledgement (SACK) 2.3.3 Selective Acknowledgement (SACK)........................25
2.3.4 Heartbeat Request (HEARTBEAT) 2.3.4 Heartbeat Request (HEARTBEAT)...........................27
2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK) 2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK)................28
2.3.6 Abort Association (ABORT) 2.3.6 Abort Association (ABORT)...............................29
2.3.7 Shutdown Association (SHUTDOWN) 2.3.7 Shutdown Association (SHUTDOWN).........................30
2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK) 2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK)..................30
2.3.9 Operation Error (ERROR) 2.3.9 Operation Error (ERROR).................................31
2.3.10 Encryption Cookie (COOKIE) 2.3.10 Encryption Cookie (COOKIE).............................33
2.3.11 Cookie Acknowledgment (COOKIE ACK) 2.3.11 Cookie Acknowledgment (COOKIE ACK).....................33
2.3.12 Payload Data (DATA) 2.3.12 Payload Data (DATA)....................................34
2.4 Vendor-Specific Chunk Extensions 2.4 Vendor-Specific Chunk Extensions............................35
3. SCTP Association State Diagram 3. SCTP Association State Diagram.................................37
4. Association Initialization 4. Association Initialization.....................................39
4.1 Normal Establishment of an Association 4.1 Normal Establishment of an Association......................39
4.1.1 Handle Stream Parameters 4.1.1 Handle Stream Parameters................................41
4.1.2 Handle Address Parameters 4.1.2 Handle Address Parameters...............................41
4.1.3 Generating Responder Cookie 4.1.3 Generating Responder Cookie.............................41
4.1.4 Cookie Processing 4.1.4 Cookie Processing.......................................42
4.1.5 Cookie Authentication 4.1.5 Cookie Authentication...................................42
4.1.6 An Example of Normal Association Establishment 4.1.6 An Example of Normal Association Establishment..........43
4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK 4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK.....44
4.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-SENT State 4.2.1 Handle Duplicate INIT in COOKIE-WAIT
4.2.2 Handle Duplicate INIT in Other States or COOKIE-SENT States...................................45
4.2.3 Handle Duplicate INIT ACK 4.2.2 Handle Duplicate INIT in Other States...................45
4.2.4 Handle Duplicate COOKIE 4.2.3 Handle Duplicate INIT ACK...............................46
4.2.5 Handle Duplicate COOKIE-ACK 4.2.4 Handle Duplicate COOKIE.................................46
4.2.6 Handle Stale COOKIE Error 4.2.5 Handle Duplicate COOKIE-ACK.............................47
4.3 Other Initialization Issues
4.3.1 Selection of Tag Value Stewart, et al [Page 3]
4.3.2 Initiation from behind a NAT 4.2.6 Handle Stale COOKIE Error...............................47
5. User Data Transfer 4.3 Other Initialization Issues.................................48
5.1 Transmission of DATA Chunks 4.3.1 Selection of Tag Value..................................48
5.2 Acknowledgment of Reception of DATA Chunks 4.3.2 Initiation from behind a NAT............................48
5.3 Management Retransmission Timer 5. User Data Transfer.............................................48
5.3.1 RTO Calculation 5.1 Transmission of DATA Chunks.................................49
5.3.2 Retransmission Timer Rules 5.2 Acknowledgment of Reception of DATA Chunks..................51
5.3.3 Handle T3-rxt Expiration 5.3 Management Retransmission Timer.............................51
5.4 Multi-homed SCTP Endpoints 5.3.1 RTO Calculation.........................................52
5.5 Stream Identifier and Sequence Number 5.3.2 Retransmission Timer Rules..............................53
5.6 Ordered and Un-ordered Delivery 5.3.3 Handle T3-rxt Expiration................................54
5.7 Report Gaps in Received DATA TSNs 5.4 Multi-homed SCTP Endpoints..................................55
5.8 CRC-16 Utilization 5.4.1 Failover from Inactive Destination Address..............56
5.9 Segmentation 5.5 Stream Identifier and Sequence Number.......................56
5.10 Bundling and Multiplexing 5.6 Ordered and Un-ordered Delivery.............................56
6. Congestion Control 5.7 Report Gaps in Received DATA TSNs...........................57
6.1 SCTP Differences from TCP Congestion Control 5.8 CRC-16 Utilization..........................................58
6.2 SCTP Slow-Start and Congestion Avoidance 5.9 Segmentation................................................59
6.2.1 Slow-Start 5.10 Bundling and Multiplexing..................................60
6.2.2 Congestion Avoidance 6. Congestion Control ..........................................60
6.2.3 Congestion Control 6.1 SCTP Differences from TCP Congestion Control................61
6.2.4 Fast Retransmit on Gap Reports 6.2 SCTP Slow-Start and Congestion Avoidance....................62
6.3 Path MTU Discovery 6.2.1 Slow-Start..............................................62
7. Fault Management 6.2.2 Congestion Avoidance....................................63
7.1 Endpoint Failure Detection 6.2.3 Congestion Control......................................63
7.2 Path Failure Detection 6.2.4 Fast Retransmit on Gap Reports..........................64
7.3 Path Heartbeat 6.3 Path MTU Discovery..........................................64
7.4 Verification Tag 7. Fault Management..............................................65
8. Termination of Association 7.1 Endpoint Failure Detection..................................65
8.1 Close of an Association 7.2 Path Failure Detection......................................66
8.2 Shutdown of an Association 7.3 Path Heartbeat..............................................66
9. Interface with Upper Layer 7.4 Verification Tag............................................67
9.1 ULP-to-SCTP 8. Termination of Association.....................................68
9.2 SCTP-to-ULP 8.1 Close of an Association.....................................68
9.3 Interfaces to Layer Management 8.2 Shutdown of an Association..................................68
9.3.1 LM-to-SCTP 9. Interface with Upper Layer.....................................69
9.3.2 SCTP-to-LM 9.1 ULP-to-SCTP.................................................70
10. Security Considerations 9.2 SCTP-to-ULP.................................................77
10.1 Security Objectives 10. Security Considerations.......................................80
10.2 SCTP Responses To Potential Threats 10.1 Security Objectives........................................80
10.2.1 Countering Insider Attacks 10.2 SCTP Responses To Potential Threats........................80
10.2.2 Protecting against Data Corruption in the Network 10.2.1 Countering Insider Attacks.............................80
10.2.3 Protecting Confidentiality 10.2.2 Protecting against Data Corruption in the Network......80
10.2.4 Protecting against Blind Denial of Service Attacks 10.2.3 Protecting Confidentiality.............................81
10.2.4.1 Flooding 10.2.4 Protecting against Blind Denial of Service Attacks.....81
10.2.4.2 Masquerade 10.2.4.1 Flooding...........................................81
10.2.4.3 Improper Monopolization of Services 10.2.4.2 Masquerade.........................................82
10.3 Protection against Fraud and Repudiation 10.2.4.3 Improper Monopolization of Services................83
11. IANA Consideration 10.3 Protection against Fraud and Repudiation...................83
11.1 IETF-defined Chunk Extension 11. IANA Consideration............................................84
11.2 IETF-defined Chunk Parameter Extension 11.1 IETF-defined Chunk Extension...............................84
11.3 IETF-defined Additional Error Causes
12. Suggested SCTP Timer and Protocol Parameter Values Stewart, et al [Page 4]
13. Acknowledgments 11.2 IETF-defined Chunk Parameter Extension.....................85
14. Authors' Addresses 11.3 IETF-defined Additional Error Causes.......................85
15. References 12. Suggested SCTP Protocol Parameter Values......................86
13. Acknowledgments...............................................87
14. Authors' Addresses............................................87
15. References....................................................88
1. Introduction 1. Introduction
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
Simple Control Transmission Protocol (SCTP), the services it offers, Simple Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description and the basic concepts needed to understand the detailed description
of the protocol. of the protocol.
1.1 Motivation 1.1 Motivation
skipping to change at line 215 skipping to change at page 10, line ?
reasonable time. reasonable time.
-- The limited scope of TCP sockets complicates the task of -- The limited scope of TCP sockets complicates the task of
providing highly-available data transfer capability using providing highly-available data transfer capability using
multi-homed hosts. multi-homed hosts.
Limitations due to implementation: Limitations due to implementation:
-- TCP is generally implemented at the operating system level. -- TCP is generally implemented at the operating system level.
Kernel limitations may constrain the maximum allowable number Kernel limitations may constrain the maximum allowable number
Stewart, et al [Page 5]
of simultaneous TCP connections to a number far below that of simultaneous TCP connections to a number far below that
required for certain applications. required for certain applications.
-- TCP implementations do not generally allow the application -- TCP implementations do not generally allow the application
to control the timers which determine how quickly a connection to control the timers which determine how quickly a connection
failure is discovered. Some applications are more critically failure is discovered. Some applications are more critically
dependent than others on timely initiation of recovery from dependent than others on timely initiation of recovery from
such failures. such failures.
Transport of PSTN signalling across the IP network is an application Transport of PSTN signalling across the IP network is an application
skipping to change at line 265 skipping to change at page 10, line ?
|-------------| |-------------| |-------------| |-------------|
| Unreliable |One or more ---- One or more| Unreliable | | Unreliable |One or more ---- One or more| Unreliable |
| Datagram |port/address \/ port/address| Datagram | | Datagram |port/address \/ port/address| Datagram |
| Service |appearances /\ appearances| Service | | Service |appearances /\ appearances| Service |
|_____________| ---- |_____________| |_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association Figure 1: An SCTP Association
Stewart, et al [Page 6]
1.3 Functional View of SCTP 1.3 Functional View of SCTP
The SCTP transport service can be decomposed into a number of The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the functions. These are depicted in Figure 2 and explained in the
remainder of this section. remainder of this section.
SCTP User Application SCTP User Application
..----------------------------------------------------- ..-----------------------------------------------------
.. _____________ ____________________ .. _____________ ____________________
skipping to change at line 306 skipping to change at page 10, line ?
| | | |
| | ________________________________ | | ________________________________
| | | Message Validation | | | | Message Validation |
|______________ |________________________________| |______________ |________________________________|
Figure 2: Functional View of the SCTP Transport Service Figure 2: Functional View of the SCTP Transport Service
1.3.1 Association Startup and Takedown 1.3.1 Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE primitive in Chapter 9). The startup description of the ASSOCIATE primitive in Chapter 9).
sequence is described in chapter 4 of this document. It is designed to
be resistant to flooding and masquerade attacks. A cookie mechanism, taken from that devised by Karn and Simpson in RFC
2522 [6], is employed during the initialization to provide protection
against security attacks. The cookie mechanism uses a four-way
handshaking, but the last two legs of which are allowed to carry user
Stewart, et al [Page 7]
data for fast setup. The startup sequence is described in chapter 4 of
this document.
SCTP provides for graceful takedown of an active association on SCTP provides for graceful takedown of an active association on
request from the SCTP user. See the description of the TERMINATE request from the SCTP user. See the description of the TERMINATE
primitive in chapter 9. SCTP also allows ungraceful takedown, either primitive in chapter 9. SCTP also allows ungraceful takedown, either
on request from the user (ABORT primitive) or as a result of an error on request from the user (ABORT primitive) or as a result of an error
condition detected within the SCTP layer. Chapter 8 describes both the condition detected within the SCTP layer. Chapter 8 describes both the
graceful and the ungraceful takedown procedures. graceful and the ungraceful takedown procedures.
1.3.2 Sequenced Delivery within Streams 1.3.2 Sequenced Delivery within Streams
skipping to change at line 355 skipping to change at page 10, line ?
SCTP assigns a Transmission Sequence Number (TSN) to each user data SCTP assigns a Transmission Sequence Number (TSN) to each user data
segment or unsegmented datagram. The TSN is independent of any segment or unsegmented datagram. The TSN is independent of any
sequence number assigned at the stream level. The receiving end sequence number assigned at the stream level. The receiving end
acknowledges all TSNs received, even if there are gaps in the acknowledges all TSNs received, even if there are gaps in the
sequence. In this way, reliable delivery is kept functionally separate sequence. In this way, reliable delivery is kept functionally separate
from sequenced delivery. from sequenced delivery.
The Acknowledgement and Congestion Avoidance function is responsible The Acknowledgement and Congestion Avoidance function is responsible
for message retransmission when timely acknowledgement has not been for message retransmission when timely acknowledgement has not been
Stewart, et al [Page 8]
received. Message retransmission is conditioned by congestion received. Message retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. avoidance procedures similar to those used for TCP.
See Chapters 5 and 6 for a detailed description of the protocol See Chapters 5 and 6 for a detailed description of the protocol
procedures associated with this function. procedures associated with this function.
1.3.5 Chunk Multiplex 1.3.5 Chunk Multiplex
As described in Chapter 2, the SCTP datagram as delivered to the lower As described in Chapter 2, the SCTP datagram as delivered to the lower
layer consists of a common header followed by one or more chunks. Each layer consists of a common header followed by one or more chunks. Each
chunk may contain either user data or SCTP control information. The chunk may contain either user data or SCTP control information. The
SCTP user has the option to request "bundling", or multiplexing of SCTP user has the option to request "bundling", or multiplexing of
more than one user datagram into a single SCTP datagram. The chunk more than one user datagram into a single SCTP datagram. The chunk
skipping to change at line 402 skipping to change at page 10, line ?
On the receiving end, the path management is responsible for verifying On the receiving end, the path management is responsible for verifying
the existence of a valid SCTP association to which the inbound SCTP the existence of a valid SCTP association to which the inbound SCTP
datagram belongs before passing it for further processing. datagram belongs before passing it for further processing.
1.3.7 Message Validation 1.3.7 Message Validation
The common SCTP header includes a validation tag and an optional CRC The common SCTP header includes a validation tag and an optional CRC
field. A validation tag value is chosen by each end of the association field. A validation tag value is chosen by each end of the association
during association startup. Messages received without the validation during association startup. Messages received without the validation
tag value expected by the receiver are discarded, as a protection tag value expected by the receiver are discarded, as a protection
Stewart, et al [Page 9]
against blind masquerade attacks and against stale datagrams from a against blind masquerade attacks and against stale datagrams from a
previous association. previous association.
The CRC may optionally be set by the sender, to provide additional The CRC may optionally be set by the sender, to provide additional
protection against data corruption in the network beyond that provided protection against data corruption in the network beyond that provided
by lower layers (e.g. the UDP checksum). by lower layers (e.g. the UDP checksum).
1.4 Recapitulation of Key Terms 1.4 Recapitulation of Key Terms
The language used to describe SCTP has been introduced in the previous The language used to describe SCTP has been introduced in the previous
skipping to change at line 435 skipping to change at page 10, line ?
between SCTP and the unreliable datagram service (e.g. UDP) which between SCTP and the unreliable datagram service (e.g. UDP) which
it is using. An SCTP datagram includes the common SCTP header, it is using. An SCTP datagram includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated within possible SCTP control chunks, and user data encapsulated within
SCTP DATA chunks. SCTP DATA chunks.
o Transport address: an address which serves as a source or o Transport address: an address which serves as a source or
destination for the unreliable datagram transport service used by destination for the unreliable datagram transport service used by
SCTP. In IP networks, a transport address is defined by the SCTP. In IP networks, a transport address is defined by the
combination of an IP address and a UDP port number. combination of an IP address and a UDP port number.
o SCTP endpoint: a logical entity, comprising a set of eligible o SCTP endpoint: the logical sender/receiver of SCTP datagrams. On a
transport addresses at a host, which SCTP datagrams will be multi-homed host, an SCTP endpoint is represented to its peers as a
sent to and received from. Note, a transport address can only be combination of a set of eligible destination transport addresses to
which SCTP datagrams can be sent and a set of eligible source
transport addresses from which SCTP datagrams can be received.
Note, a source or destination transport address can only be
included in one unique SCTP endpoint, i.e., it is NOT allowed to included in one unique SCTP endpoint, i.e., it is NOT allowed to
have the same SCTP transport address appear in more than one have the same SCTP source or destination transport address appear
endpoints. in more than one SCTP endpoint.
o SCTP association: a protocol relationship between SCTP endpoints, o SCTP association: a protocol relationship between SCTP endpoints,
comprising the two SCTP endpoints and protocol state information comprising the two SCTP endpoints and protocol state information
including verification tags and the currently active set of including verification tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. Transmission Sequence Numbers (TSNs), etc.
o Chunk: a unit of information within an SCTP datagram, consisting of o Chunk: a unit of information within an SCTP datagram, consisting of
a chunk header and chunk-specific content. a chunk header and chunk-specific content.
o Transmission Sequence Number (TSN): a 32-bit sequence number used o Transmission Sequence Number (TSN): a 32-bit sequence number used
skipping to change at line 546 skipping to change at page 13, line 4
| Common Header | | Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 | | Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n | | Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple chunks can be multiplexed into one UDP SCTP datagram up to Multiple chunks can be multiplexed into one UDP SCTP datagram up to
the MTU size except for the INIT, INIT ACK, and SHUTDOWN ACK the MTU size except for the INIT, INIT ACK, and SHUTDOWN ACK
chunks. These chunks MUST not be multiplexed with any other chunk in a chunks. These chunks MUST not be multiplexed with any other chunk in a
datagram. See Section 5.10 for more details on chunk multiplexing. datagram. See Section 5.10 for more details on chunk multiplexing.
If an user data message doesn't fit into one SCTP datagram it can be If an user data message doesn't fit into one SCTP datagram it can be
segmented into multiple chunks using the procedure defined in Section segmented into multiple chunks using the procedure defined in
5.9. Section 5.9.
All integer fields in SCTP datagrams MUST be transmitted in the
network byte order, unless otherwise stated.
2.1 SCTP Common Header Field Descriptions 2.1 SCTP Common Header Field Descriptions
SCTP Common Header Format SCTP Common Header Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Reserved |C| CRC-16 | | Vers | Reserved |C| CRC-16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 822 skipping to change at page 18, line 41
VS-Value: Variable Length VS-Value: Variable Length
This field contains the parameter identified by the VS-Type field. This field contains the parameter identified by the VS-Type field.
It's meaning is identified by the vendor. It's meaning is identified by the vendor.
2.3 SCTP Chunk Definitions 2.3 SCTP Chunk Definitions
This section defines the format of the different chunk types. This section defines the format of the different chunk types.
Note: integers in the chunk MUST be transmitted in network octet-order.
2.3.1 Initiation (INIT) (00000001) 2.3.1 Initiation (INIT) (00000001)
This chunk is used to initiate a SCTP association between This chunk is used to initiate a SCTP association between
two endpoints. The format of the INIT message is shown below: two endpoints. The format of the INIT message is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|Chunk Flags | Chunk Length | |0 0 0 0 0 0 0 1|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag | | Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Window Credit | | Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Inbound Streams | (Reserved) | | Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN | | Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Optional/Variable-Length Parameters / / Optional/Variable-Length Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless otherwise The INIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only be included once in the INIT chunk. noted, each parameter MUST only be included once in the INIT chunk.
skipping to change at line 890 skipping to change at page 20, line 13
The receiver of the INIT (the responding end) records the value of The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP datagram that the responding end Verification Tag field of every SCTP datagram that the responding end
transmits within this association. transmits within this association.
The valid range for Initiate Tag is from 0x1 to 0xffffffff. See The valid range for Initiate Tag is from 0x1 to 0xffffffff. See
Section 4.3.1 for more on selection of the tag value. Section 4.3.1 for more on selection of the tag value.
If the value of the Initiate Tag in a received INIT chunk is found If the value of the Initiate Tag in a received INIT chunk is found
to be 0x0, the receiver MUST treat it as an error and silently to be 0x0, the receiver MUST treat it as an error and silently
discard the datagram (or send Abort with tag=0??!). discard the datagram.
Receive Window Credit (rwnd): 32 bit u_int Receiver Window Credit (rwnd): 32 bit u_int
This field defines the maximum number of octets of outbound data the This field defines the maximum number of octets of outbound data the
receiver of the INIT is allowed to have outstanding (i.e. sent and receiver of the INIT is allowed to have outstanding (i.e. sent and
not acknowledged). not acknowledged).
Number of Outbound Streams (OS): 16 bit u_int Number of Outbound Streams (OS): 16 bit u_int
Defines the number of outbound streams the sender of this INIT chunk 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 wishes to create in this association. The value of 0 MUST NOT be
used. used.
Number of Inbound Streams (MIS) : 16 bit u_int Number of Inbound Streams (MIS) : 16 bit u_int
Defines the maximum number of streams the sender of this INIT chunk 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 allows the peer end to create in this association. The value 0 MUST
NOT be used. NOT be used.
Initial TSN (I-TSN) : 32 bit u_int Initial TSN (I-TSN) : 32 bit u_int
Defines the initial TSN that the sender will use. This field MAY be Defines the initial TSN that the sender will use. The valid range is
set to the value of the Initiate Tag field. from 0x0 to 0xffffffff. This field MAY be set to the value of the
Initiate Tag field.
The Reserved fields must be set to all 0 by the sender and ignored by The Reserved fields must be set to all 0 by the sender and ignored by
the receiver. the receiver.
2.3.1.1 Optional or Variable Length Parameters 2.3.1.1 Optional or Variable Length Parameters
The following parameters follow the Type-Length-Value format as The following parameters follow the Type-Length-Value format as
defined in Section 2.2.1. The IP address fields MUST come after the defined in Section 2.2.1. The IP address fields MUST come after the
fixed-length fields. fixed-length fields.
skipping to change at line 1049 skipping to change at page 23, line 25
The format of the INIT ACK message is shown below: The format of the INIT ACK message is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|Chunk Flags | Chunk Length | |0 0 0 0 0 0 1 0|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag | | Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Window Credit | | Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Inbound Streams | (Reserved) | | Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN | | Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Optional/Variable-Length Parameters / / Optional/Variable-Length Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT ACK contains the following parameters. Unless otherwise The INIT ACK contains the following parameters. Unless otherwise
noted, each parameter MUST only be included once in the INIT ACK chunk. noted, each parameter MUST only be included once in the INIT ACK chunk.
skipping to change at line 1129 skipping to change at page 25, line 11
appended to the end of the INIT ACK chunk. In case the receiver of appended to the end of the INIT ACK chunk. In case the receiver of
the INIT ACK does not support the vendor-specific parameters received, the INIT ACK does not support the vendor-specific parameters received,
it MUST ignore those fields. it MUST ignore those fields.
2.3.3 Selective Acknowledgement (SACK) (00000011): 2.3.3 Selective Acknowledgement (SACK) (00000011):
This chunk is sent to the remote endpoint to acknowledge received DATA This chunk is sent to the remote endpoint to acknowledge received DATA
chunks and to inform the remote endpoint of gaps in the received chunks and to inform the remote endpoint of gaps in the received
subsequences of DATA chunks as represented by their TSNs. subsequences of DATA chunks as represented by their TSNs.
The SACK MUST contain the Highest Consecutive TSN ACK and Rcv Window The SACK MUST contain the Cumulative TSN ACK and Receiver Window
Credit (rwnd) parameters. By definition, the value of the Highest Credit (rwnd) parameters. By definition, the value of the Cumulative
Consecutive TSN ACK parameter is the last TSN received at the time the TSN ACK parameter is the last TSN received at the time the Selective
Selective ACK is sent, before a break in the sequence of received TSNs ACK is sent, before a break in the sequence of received TSNs occurs;
occurs; the next TSN value following this one has not yet been the next TSN value following this one has not yet been received at the
received at the reporting end. This parameter therefore acknowledges reporting end. This parameter therefore acknowledges receipt of all
receipt of all TSNs up to and including the value given. TSNs up to and including the value given.
The Selective ACK also contains zero or more fragment reports. Each The Selective ACK also contains zero or more fragment reports. Each
fragment report acknowledges a subsequence of TSNs received following fragment report acknowledges a subsequence of TSNs received following
a break in the sequence of received TSNs. By definition, all TSNs a break in the sequence of received TSNs. By definition, all TSNs
acknowledged by fragment reports are higher than the value of the acknowledged by fragment reports are higher than the value of the
Highest Consecutive TSN ACK. Cumulative TSN ACK.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|Chunk Flags | Chunk Length | |0 0 0 0 0 0 1 1|Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest Consecutive TSN ACK | | Cumulative TSN ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcv Window Credit (rwnd) | | Receiver Window Credit (rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Fragments = N | (Reserved) | | Number of Fragments = N | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment #1 Start | Fragment #1 End | | Fragment #1 Start | Fragment #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ ... \ \ ... \
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment #N Start | Fragment #N End | | Fragment #N Start | Fragment #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to all zeros on transmit and ignored on receipt. Set to all zeros on transmit and ignored on receipt.
Highest Consecutive TSN ACK: 32 bit u_int Cumulative TSN ACK: 32 bit u_int
This parameter contains the TSN of the last DATA chunk received in This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. sequence before a gap.
Receive Window Credit (rwnd): 32 bit u_int Receiver Window Credit (rwnd): 32 bit u_int
This field defines the new maximum number of octets of outbound data This field defines the new maximum number of octets of outbound data
the receiver of this SACK is allowed to have outstanding (i.e. sent the receiver of this SACK is allowed to have outstanding (i.e. sent
and not acknowledged). and not acknowledged).
Number of Fragments: 16 bit u_int Number of Fragments: 16 bit u_int
Indicates the number of TSN fragments included in this Selective Indicates the number of TSN fragments included in this Selective
ACK. ACK.
Reserved: 16 bit Reserved: 16 bit
Must be set to all 0 by the sender and ignored by the receiver. Must be set to all 0 by the sender and ignored by the receiver.
Fragments: Fragments:
These fields contain the ack fragments. They are repeated for each These fields contain the ack fragments. They are repeated for each
fragment up to the number of fragments defined in the Number of fragment up to the number of fragments defined in the Number of
Fragments field. All DATA chunks with TSNs between the (Highest Fragments field. All DATA chunks with TSNs between the (Cumulative
Consecutive TSN + Fragment Start) and (Highest Consecutive TSN + TSN ACK + Fragment Start) and (Cumulative TSN ACK + Fragment End) of
Fragment End) of each fragment are assumed to have been received each fragment are assumed to have been received correctly.
correctly.
Fragment Start: 16 bit u_int Fragment Start: 16 bit u_int
Indicates the Start offset TSN for this fragment. To calculate the Indicates the Start offset TSN for this fragment. To calculate the
actual TSN number the Highest Consecutive TSN is added to this actual TSN number the Cumulative TSN ACK is added to this
offset number to yield the TSN. This calculated TSN identifies offset number to yield the TSN. This calculated TSN identifies
the first TSN in this fragment that has been received. the first TSN in this fragment that has been received.
Fragment End: 16 bit u_int Fragment End: 16 bit u_int
Indicates the End offset TSN for this fragment. To calculate the Indicates the End offset TSN for this fragment. To calculate the
actual TSN number the Highest Consecutive TSN is added to this actual TSN number the Cumulative TSN ACK is added to this
offset number to yield the TSN. This calculated TSN identifies offset number to yield the TSN. This calculated TSN identifies
the TSN of the last DATA chunk received in this fragment. the TSN of the last DATA chunk received in this fragment.
For example, assume the receiver has the following datagrams newly For example, assume the receiver has the following datagrams newly
arrived at the time when it decides to send a Selective ACK, arrived at the time when it decides to send a Selective ACK,
---------- ----------
| TSN=17 | | TSN=17 |
---------- ----------
| | <- still missing | | <- still missing
---------- ----------
| TSN=15 | | TSN=15 |
---------- ----------
| TSN=14 | | TSN=14 |
---------- ----------
| | <- still missing | | <- still missing
skipping to change at line 1235 skipping to change at page 27, line 26
---------- ----------
| TSN=11 | | TSN=11 |
---------- ----------
| TSN=10 | | TSN=10 |
---------- ----------
then, the parameter part of the Selective ACK MUST be constructed as then, the parameter part of the Selective ACK MUST be constructed as
follows (assuming the new rwnd is set to 0x1234 by the sender): follows (assuming the new rwnd is set to 0x1234 by the sender):
+---------------+--------------+ +---------------+--------------+
| Highest Consecutive TSN = 12 | | Cumulative TSN ACK = 12 |
----------------+--------------- ----------------+---------------
| rwnd = 0x1234 | | rwnd = 0x1234 |
----------------+--------------- ----------------+---------------
| num of frag=2 | (rev = 0) | | num of frag=2 | (rev = 0) |
----------------+--------------- ----------------+---------------
|frag #1 strt=2 |frag #1 end=3 | |frag #1 strt=2 |frag #1 end=3 |
----------------+--------------- ----------------+---------------
|frag #2 strt=5 |frag #2 end=5 | |frag #2 strt=5 |frag #2 end=5 |
-------------------------------- --------------------------------
2.3.4 Heartbeat Request (HEARTBEAT) (00000100): 2.3.4 Heartbeat Request (HEARTBEAT) (00000100):
An endpoint should send this chunk to its peer endpoint of the current An endpoint should send this chunk to its peer endpoint of the current
association to probe the reachability of a particular destination association to probe the reachability of a particular destination
transport address defined in the present association. transport address defined in the present association.
The parameter fields MUST contain the time values. The parameter field contains the Heartbeat Information which is a
variable length opeque data structure understood only by the sender.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0| |0 0 0 0 0 1 0 0| Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 1 (e.g., sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 2 (e.g., usec) | \ \
/ Heartbeat Information (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
Time Value 1: 32 bit u_int Heartbeat Length:
Time Value 2: 32 bit u_int
The Time Values contain a time value meaningful only to the Set to the size of the chunk in octets, including the chunk header
sender. For example, Time Value 1 may be in units of seconds and and the Heartbeat Information field.
Time Value 2 in units of microseconds. Their value should be set to
the current time at which this Heartbeat Request is sent.
IMPLEMENTATION NOTE: For most systems the value is normally set by Heartbeat Information:
doing a system call to get the current time.
defined as a variable-length parameter using the format described in
Section 2.2.1, i.e.:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-specific Heartbeat Info field should normally include
information about the sender's current time when this HEARTBEAT
message is sent and the destination transport address to which this
HEARTBEAT is sent (see Section 7.3).
2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK) (00000101): 2.3.5 Heartbeat Acknowledgment (HEARTBEAT ACK) (00000101):
An endpoint should send this chunk to its peer endpoint as a response An endpoint should send this chunk to its peer endpoint as a response
to a Heartbeat Request (see Section 7.3). to a Heartbeat Request (see Section 7.3).
The parameter field MUST contain the time values. The parameter field contains a variable length opeque data structure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0| |0 0 0 0 0 1 0 1| Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 1 (e.g., sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value 2 (e.g., usec) | \ \
/ Heartbeat Information (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
Time Value 1: 32 bit u_int Heartbeat Ack Length:
Time Value 2: 32 bit u_int
The values of these two field SHALL be copied from the time values Set to the size of the chunk in octets, including the chunk header
contained in the Heartbeat Request to which this Heartbeat and the Heartbeat Information field.
acknowledgement is responding.
Heartbeat Information:
The values of this field SHALL be copied from the Heartbeat
Information field found in the Heartbeat Request to which this
Heartbeat Acknowledgement is responding.
2.3.6 Abort Association (ABORT) (00000110): 2.3.6 Abort Association (ABORT) (00000110):
The ABORT chunk is sent to the peer of an association to terminate the The ABORT chunk is sent to the peer of an association to terminate the
association. The Abort chunk has no parameters. association. The Abort chunk has no parameters.
If an endpoint receives an INIT or INIT ACK missing a mandatory If an endpoint receives an INIT or INIT ACK missing a mandatory
parameter, it MUST send an ABORT message to its peer. It SHOULD parameter, it MUST send an ABORT message to its peer. It SHOULD
include a Operational Error chunk with the Abort chunk to specify include a Operational Error chunk with the Abort chunk to specify
the reason. the reason.
skipping to change at line 1341 skipping to change at page 30, line 16
An endpoint in an association MUST use this chunk to initiate a An endpoint in an association MUST use this chunk to initiate a
graceful termination of the association with its peer. This chunk has graceful termination of the association with its peer. This chunk has
the following format. the following format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| |0 0 0 0 0 1 1 1|Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest Consecutive TSN ACK | | Cumulative TSN ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
Highest Consecutive TSN ACK: 32 bit u_int Cumulative TSN ACK: 32 bit u_int
This parameter contains the TSN of the last chunk received in This parameter contains the TSN of the last chunk received in
sequence before any gaps. sequence before any gaps.
2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK) (00001000): 2.3.8 Shutdown Acknowledgment (SHUTDOWN ACK) (00001000):
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
chunk at the completion of the shutdown process, see Section 8.2 for chunk at the completion of the shutdown process, see Section 8.2 for
details. details.
skipping to change at line 1541 skipping to change at page 34, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN | | TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Sequence Number n | | Stream Identifier S | Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream S) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: the TSN, stream identifier, and sequence number MUST be
transmitted in network byte order.
Reserved: 5 bits Reserved: 5 bits
should be set to all '0's and ignored by the receiver. should be set to all '0's and ignored by the receiver.
U bit: 1 bit U bit: 1 bit
The (U)nordered bit, if set, indicates that this is an unordered The (U)nordered bit, if set, indicates that this is an unordered
data chunk, and there is NO Sequence Number assigned to this DATA data chunk, and there is NO Sequence Number assigned to this DATA
chunk. Therefore, the receiver MUST ignore the Sequence Number chunk. Therefore, the receiver MUST ignore the Sequence Number
field. field.
After reassembly (if necessary), unordered data chunks MUST be After reassembly (if necessary), unordered data chunks MUST be
skipping to change at line 1593 skipping to change at page 35, line 25
Length: 16 bits (16 bit u_int) Length: 16 bits (16 bit u_int)
This field indicates the length of the DATA chunk in octets. It This field indicates the length of the DATA chunk in octets. It
includes the Type field, the Reserved field, the U and B/E bits, the includes the Type field, the Reserved field, the U and B/E bits, the
Length field, TSN, the Stream Identifier, the Stream Sequence Length field, TSN, the Stream Identifier, the Stream Sequence
Number, and the User Data fields. It does not include any padding. Number, and the User Data fields. It does not include any padding.
TSN : 32 bits (32 bit u_int) TSN : 32 bits (32 bit u_int)
This value represents the TSN for this DATA chunk. This value represents the TSN for this DATA chunk. The valid range
of TSN is from 0x0 to 0xffffffff.
Stream Identifier S: 16 bit u_int Stream Identifier S: 16 bit u_int
Identifies the stream to which the following user data belongs. Identifies the stream to which the following user data belongs.
Sequence Number n: 16 bit u_int Sequence Number n: 16 bit u_int
This value presents the sequence number of the following user This value presents the sequence number of the following user
data within the stream S. Valid range is 0x0 to 0xFFFF. data within the stream S. Valid range is 0x0 to 0xFFFF.
skipping to change at line 1737 skipping to change at page 38, line 22
(from any state except CLOSED) (from any state except CLOSED)
| |
| |
/--------+--------\ /--------+--------\
[shutdown] / \ [shutdown] / \
----------------- | | ----------------- | |
check outstanding | | check outstanding | |
data chunks | | data chunks | |
v | v |
+---------+ | +---------+ |
(4) |SHUTDOWN | | rcv SHUTDOWN |SHUTDOWN | | rcv SHUTDOWN
|PENDING | | ---------------- |PENDING | | ----------------
+---------+ | x +---------+ | x
| | | |
No more outstanding | | No more outstanding | |
------------------- | | ------------------- | |
snd SHUTDOWN | | snd SHUTDOWN | |
strt shutdown timer | | strt shutdown timer | |
v v v v
+---------+ +-----------+ +---------+ +-----------+
(5) |SHUTDOWN | | SHUTDOWN | (5) (4) |SHUTDOWN | | SHUTDOWN | (5)
|SENT | | RECEIVED | |SENT | | RECEIVED |
+---------+ +-----------+ +---------+ +-----------+
| | | |
rcv SHUTDOWN.ACK | | x rcv SHUTDOWN.ACK | | x
------------------- | |----------------- ------------------- | |-----------------
stop shutdown timer | | retransmit missing DATA stop shutdown timer | | retransmit missing DATA
delete TCB | | send SHUTDOWN.ACK delete TCB | | send SHUTDOWN.ACK
| | delete TCB | | delete TCB
| | | |
\ +---------+ / \ +---------+ /
skipping to change at line 1771 skipping to change at page 39, line 7
Note: Note:
(1) If the received COOKIE is invalid (i.e., failed to pass the (1) If the received COOKIE is invalid (i.e., failed to pass the
authentication check), the receiver MUST silently discard the authentication check), the receiver MUST silently discard the
datagram. Or, if the received COOKIE is expired (see Section datagram. Or, if the received COOKIE is expired (see Section
4.1.5), the receiver SHALL send an ERROR chunk back. In 4.1.5), the receiver SHALL send an ERROR chunk back. In
either case, the receiver SHALL stay in the closed state. either case, the receiver SHALL stay in the closed state.
(2) If the init timer expires, the endpoint SHALL retransmit INIT (2) If the init timer expires, the endpoint SHALL retransmit INIT
and re-start the init timer without changing state. This SHALL be and re-start the init timer without changing state. This SHALL be
repeated up to 'Max.Init.Retransmit' times. After that, the repeated up to 'Max.Init.Retransmits' times. After that, the
endpoint SHALL abort the initialization process and report the endpoint SHALL abort the initialization process and report the
error to SCTP user. error to SCTP user.
(3) If the cookie timer expires, the endpoint SHALL retransmit (3) If the cookie timer expires, the endpoint SHALL retransmit
COOKIE and re-start the cookie timer without changing COOKIE and re-start the cookie timer without changing
state. This SHALL be repeated up to 'Max.Init.Retransmit' state. This SHALL be repeated up to 'Max.Init.Retransmits'
times. After that, the endpoint SHALL abort the initialization times. After that, the endpoint SHALL abort the initialization
process and report the error to SCTP user. process and report the error to SCTP user.
(4) In SHUTDOWN-SENT state the endpoint SHALL acknowledge any received (4) In SHUTDOWN-SENT state the endpoint SHALL acknowledge any received
DATA chunks without delay DATA chunks without delay
(5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new (5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new
send request from its SCTP user. send request from its SCTP user.
4. Association Initialization 4. Association Initialization
Before the first data transmission can take place from one SCTP Before the first data transmission can take place from one SCTP
endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must
complete an initialization process in order to set up an SCTP complete an initialization process in order to set up an SCTP
association between them. association between them.
The SCTP user at an endpoint SHOULD use the ASSOCIATE primitive to The SCTP user at an endpoint SHOULD use the ASSOCIATE primitive to
initialize an SCTP association to another SCTP endpoint. initialize an SCTP association to another SCTP endpoint.
IMPLEMENTATION NOTE: From an SCTP-user's point of view, an IMPLEMENTATION NOTE: From an SCTP-user's point of view, an
association may be implicitly opened, without an Associate primitive association may be implicitly opened, without an ASSOCIATE primitive
(see 9.1 B) being invoked, by the initiating endpoint's sending of (see 9.1 B) being invoked, by the initiating endpoint's sending of
the first user data to the destination endpoint. The initiating SCTP the first user data to the destination endpoint. The initiating SCTP
will assume default values for all mandatory and optional parameters will assume default values for all mandatory and optional parameters
for the INIT/INIT ACK. for the INIT/INIT ACK.
Once the association is established, unidirectional streams will be Once the association is established, unidirectional streams will be
open for data transfer on both ends (see Section 4.1.1). open for data transfer on both ends (see Section 4.1.1).
A cookie mechanism is employed during the initialization to provide
protection against security attacks. The cookie mechanism uses a
four-way handshaking, but the last two legs of which are allowed to
carry user data for fast setup.
4.1 Normal Establishment of an Association 4.1 Normal Establishment of an Association
The initialization process consists of the following steps (assuming The initialization process consists of the following steps (assuming
that SCTP endpoint "A" tries to set up an association with SCTP that SCTP endpoint "A" tries to set up an association with SCTP
endpoint "Z" and "Z" accepts the new association): endpoint "Z" and "Z" accepts the new association):
A) "A" shall first send an INIT message to "Z". In the INIT, "A" must A) "A" shall first send an INIT message to "Z". In the INIT, "A" must
provide its security tag "Tag_A" in the Initiate Tag field. Tag_A provide its security tag "Tag_A" in the Initiate Tag field. Tag_A
shall be a random number in the range of 0x1 to 0xffffffff (see shall be a random number in the range of 0x1 to 0xffffffff (see
4.3.1 for Tag value selection). After sending the INIT, "A" enters 4.3.1 for Tag value selection). After sending the INIT, "A" starts
the COOKIE-WAIT state. the T1-init timer and enters the COOKIE-WAIT state.
B) "Z" shall respond immediately with an INIT ACK message. In the B) "Z" shall respond immediately with an INIT ACK message. In the
message, besides filling in other parameters, "Z" must set the message, besides filling in other parameters, "Z" must set the
Verification Tag field to Tag_A, and also provide its own security Verification Tag field to Tag_A, and also provide its own security
tag "Tag_Z" in the Initiate Tag field. tag "Tag_Z" in the Initiate Tag field.
Moreover, "Z" shall generate and send along with the INIT ACK a Moreover, "Z" shall generate and send along with the INIT ACK a
responder cookie. See Section 4.1.3 for responder cookie responder cookie. See Section 4.1.3 for responder cookie
generation. generation.
Note: after sending out INIT ACK with the cookie, "Z" should not Note: after sending out INIT ACK with the cookie, "Z" should not
allocate any resources, nor keep any states for the new allocate any resources, nor keep any states for the new
association. Otherwise, "Z" will be vulnerable to resource attacks. association. Otherwise, "Z" will be vulnerable to resource attacks.
C) Upon reception of the INIT ACK from "Z", "A" shall leave COOKIE-WAIT C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-init
state and enter the COOKIE-SENT state. "A" now sends the cookie timer and leave COOKIE-WAIT state. "A" shall then send the cookie
received in the INIT ACK message in a cookie chunk. The cookie received in the INIT ACK message in a cookie chunk, restart the
chunk can be bundled with any pending DATA chunks, but it MUST T1-init timer, and enter the COOKIE-SENT state.
be the first chunk in the datagram.
Note, the cookie chunk can be bundled with any pending outbound
DATA chunks, but it MUST be the first chunk in the datagram.
D) Upon reception of the COOKIE chunk, Endpoint "Z" will reply with D) Upon reception of the COOKIE chunk, Endpoint "Z" will reply with
a COOKIE-ACK chunk after building a TCB and marking itself to a COOKIE ACK chunk after building a TCB and marking itself to
the established state. A COOKIE-ACK chunk may also be combined with the ESTABLISHED state. A COOKIE ACK chunk may be combined with
any pending DATA chunks (and/or SACK chunks), but the COOKIE-ACK any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK
chunk must be the first chunk in the datagram. chunk must be the first chunk in the datagram.
IMPLEMENTATION NOTE: a implementation may choose to send the IMPLEMENTATION NOTE: an implementation may choose to send the
communication up primitive to the SCTP user upon reception Communication Up notification to the SCTP user upon reception
of a valid cookie. of a valid COOKIE.
E) Upon reception of the COOKIE ACK, endpoint "A" will move from the E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
COOKIE-SENT state to the ESTABLISHED state, stopping its INIT COOKIE-SENT state to the ESTABLISHED state, stopping the T1-init
timer. timer, and it may also notify its ULP about the successful
establishment of the associate with a Communication Up notification
IMPLEMENTATION NOTE: a implementation may choose to send the (see Section 9).
communication up primitive to the SCTP user upon reception
of a the COOKIE ACK.
Note: no DATA chunk shall be carried in the INIT or INIT ACK message. Note: no DATA chunk shall be carried in the INIT or INIT ACK message.
Note: if an endpoint receives an INIT, INIT ACK, or COOKIE chunk but Note: if an endpoint receives an INIT, INIT ACK, or COOKIE chunk but
decides not to establish the new association due to lack of resources, decides not to establish the new association due to lack of resources,
etc., it shall respond to the chunk with an ABORT chunk. The etc., it shall respond with an ABORT chunk. The Verification Tag field
Verification Tag field of the common header must be set to equal the of the common header must be set to equal the Initiate Tag value of
Initiate Tag value of the peer. the peer.
Note: After the reception of the first data chunk in an association Note: After the reception of the first data chunk in an association
the receiver MUST immediately respond with a SACK to acknowledge the receiver MUST immediately respond with a SACK to acknowledge
the data chunk, subsequent acknowledgements should be done as the data chunk, subsequent acknowledgements should be done as
described in section 5.2. described in section 5.2.
Note: When a SCTP endpoint sends an INIT or INIT ACK it MUST include Note: When a SCTP endpoint sends an INIT or INIT ACK it MUST include
all of its transport addresses in the parameter section. This is all of its transport addresses in the parameter section. This is
because it may NOT be possible to control the "sending" address that because it may NOT be possible to control the "sending" address that
a receiver of a SCTP datagram sees. A receiver thus MUST know every a receiver of a SCTP datagram sees. A receiver thus MUST know every
address that may be a source address for a peer SCTP endpoint, this address that may be a source address for a peer SCTP endpoint, this
assures that the inbound SCTP datagram can be matched to the proper assures that the inbound SCTP datagram can be matched to the proper
association. association.
skipping to change at line 1944 skipping to change at page 42, line 31
MD5), and MD5), and
4) generate the responder cookie by combining the TCB and the 4) generate the responder cookie by combining the TCB and the
resultant MD5 signature. resultant MD5 signature.
After sending the INIT ACK with the cookie, the sender SHOULD delete After sending the INIT ACK with the cookie, the sender SHOULD delete
the TCB and any other local resource related to the new association, the TCB and any other local resource related to the new association,
so as to prevent resource attacks. so as to prevent resource attacks.
The private key should be a cryptographic quality random number with The private key should be a cryptographic quality random number with
a sufficient length. Discussion in RFC-1750 [1] can be helpful in a sufficient length. Discussion in RFC 1750 [1] can be helpful in
selection of the key. selection of the key.
4.1.4 Cookie Processing 4.1.4 Cookie Processing
When a cookie is received from its peer in an INIT ACK message, the When a cookie is received from its peer in an INIT ACK message, the
receiver of the INIT ACK MUST immediately send a COOKIE chunk to its receiver of the INIT ACK MUST immediately send a COOKIE chunk to its
peer and MAY piggy-back any pending DATA chunks on the outbound peer and MAY piggy-back any pending DATA chunks on the outbound COOKIE
cookie chunk. The sender should also start a timer, and retransmit chunk. The sender shall also start the T1-init timer after sending out
the cookie chunk until a COOKIE ACK is received or the endpoint the COOKIE chunk. If the timer expires, the sender shall retransmit
is marked unreachable. the COOKIE chunk and restart the T1-init timer. This is repeated until
either a COOKIE ACK is received or the endpoint is marked unreachable.
4.1.5 Cookie Authentication 4.1.5 Cookie Authentication
When an endpoint receives a COOKIE chunk from another endpoint with When an endpoint receives a COOKIE chunk from another endpoint with
which it has no association, it shall take the following actions: which it has no association, it shall take the following actions:
1) compute an MD5 signature using the TCB data carried in the cookie 1) compute an MD5 signature using the TCB data carried in the cookie
along with the receiver's private security key, along with the receiver's private security key,
2) authenticate the cookie by comparing the computed MD5 signature 2) authenticate the cookie by comparing the computed MD5 signature
skipping to change at line 1983 skipping to change at page 43, line 22
transmit a stale cookie operational error to the sending endpoint, transmit a stale cookie operational error to the sending endpoint,
4) if the cookie is valid, create an association to the sender of the 4) if the cookie is valid, create an association to the sender of the
COOKIE message with the information in the TCB data carried in the COOKIE message with the information in the TCB data carried in the
COOKIE, and enter the ESTABLISHED state, COOKIE, and enter the ESTABLISHED state,
5) acknowledge any DATA chunk in the datagram following the rules 5) acknowledge any DATA chunk in the datagram following the rules
defined in Section 5.2, and, defined in Section 5.2, and,
6) send a COOKIE ACK chunk to the sender acknowledging reception of 6) send a COOKIE ACK chunk to the sender acknowledging reception of
the cookie. The COOKIE ACK MAY be piggybacked with any DATA chunk or the cookie. The COOKIE ACK MAY be piggybacked with any outbound
SACK chunk (if a DATA chunk is present in the received datagram a DATA chunk or SACK chunk.
SACK MUST be sent in the acknowledgement).
Note that if a COOKIE is received from an endpoint with which the Note that if a COOKIE is received from an endpoint with which the
receiver of the COOKIE has an existing association, the proceedures in receiver of the COOKIE has an existing association, the proceedures in
section 4.2 should be followed. section 4.2 should be followed.
4.1.6 An Example of Normal Association Establishment 4.1.6 An Example of Normal Association Establishment
In the following example, "A" initiates the association and then sends In the following example, "A" initiates the association and then sends
a user datagram to "Z", then "Z" sends two user datagrams to "A" a user datagram to "Z", then "Z" sends two user datagrams to "A"
later: later:
Endpoint A Endpoint Z Endpoint A Endpoint Z
{app sets association with Z} {app sets association with Z}
(build TCB)
INIT [INIT Tag=Tag_A INIT [INIT Tag=Tag_A
& other info] --------\ & other info] --------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A, /--- INIT ACK [Veri Tag=Tag_A,
/ INIT Tag=Tag_Z, / INIT Tag=Tag_Z,
(Cancel T1-init timer, <------/ Cookie_Z, & other info] (Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB) (destroy temp TCB)
COOKIE[ Cookie_Z] -----------\ COOKIE[ Cookie_Z] -----------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-SENT state) \---> (build TCB enter established state) (Enter COOKIE-SENT state) \---> (build TCB enter ESTABLISHED state)
/---- COOKIE-ACK /---- COOKIE-ACK
/ /
(Cancel T1-init timer, <-----/ (Cancel T1-init timer, <-----/
Enter established state) Enter established state)
... ...
{app sends 1st user data; strm 0} {app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\ Strm=0,Seq=1 & user data]--\
(Start T3-rxt timer) \ (Start T3-rxt timer) \
\-> \->
skipping to change at line 2042 skipping to change at page 44, line 33
SACK [TSN ACK=init TSN_Z, /---- DATA SACK [TSN ACK=init TSN_Z, /---- DATA
Frag=0] --------\ / [TSN=init TSN_Z +1, Frag=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2] \/ Strm=0,Seq=2 & user data 2]
<------/\ <------/\
\ \
\------> \------>
Note that If T1-init timer expires at "A" after the INIT or COOKIE Note that If T1-init timer expires at "A" after the INIT or COOKIE
chunks are sent, the same INIT or cookie chunk with the same Initiate chunks are sent, the same INIT or cookie chunk with the same Initiate
Tag (i.e., Tag_A) or cookie shall be retransmitted and the timer Tag (i.e., Tag_A) or cookie shall be retransmitted and the timer
restarted. This shall be repeated Max.Init.Retransmit times before "A" restarted. This shall be repeated Max.Init.Retransmits times before "A"
considers "Z" unreachable and reports the failure to its upper layer. considers "Z" unreachable and reports the failure to its upper layer.
When retransmitting the INIT, the endpoint SHALL following the rules When retransmitting the INIT, the endpoint SHALL following the rules
defined in 5.3 to determine the proper timer value. defined in 5.3 to determine the proper timer value.
4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK 4.2 Handle Duplicate INIT, INIT ACK, COOKIE, and COOKIE ACK
At any time during the life of an association (in one of the possible At any time during the life of an association (in one of the possible
states) between an endpoint and its peer, one of the setup chunks states) between an endpoint and its peer, one of the setup chunks
may be received from the peer, the receiver shall process such may be received from the peer, the receiver shall process such
a duplicate has described in this section. a duplicate has described in this section.
skipping to change at line 2078 skipping to change at page 45, line 21
In case A), the endpoint shall reset the present association and set a In case A), the endpoint shall reset the present association and set a
new association with its peer. Case B) is unique and is discussed in new association with its peer. Case B) is unique and is discussed in
Section 4.2.1. However, in cases C) and D), the endpoint must retain Section 4.2.1. However, in cases C) and D), the endpoint must retain
the present association. the present association.
The rules in the following sections shall be applied in order to The rules in the following sections shall be applied in order to
identify and correctly handle these cases. identify and correctly handle these cases.
4.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-SENT State 4.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-SENT State
This usually indicates an initialization collision. This usually indicates an initialization collision, i.e., both
endpoints are attempting at about the same time to establish an
association with the other endpoint.
In such a case, each of the two side shall respond to the other side In such a case, each of the two side shall respond to the other side
with an INIT ACK, with the Verification Tag field of the common header with an INIT ACK, with the Verification Tag field of the common header
set to the tag value received from the INIT message, and the Initiate set to the tag value received from the INIT message, and the Initiate
Tag field set to its own tag value (the same tag used in the INIT Tag field set to its own tag value (the same tag used in the INIT
message sent out by itself). Each responder shall also generate a message sent out by itself). Each responder shall also generate a
cookie with the INIT ACK. cookie with the INIT ACK.
After that, no other actions shall be taken by either side, i.e., the After that, no other actions shall be taken by either side, i.e., the
endpoint shall not change its state, and the T1-init timer shall be endpoint shall not change its state, and the T1-init timer shall be
skipping to change at line 2149 skipping to change at page 46, line 49
endpoint but NO update should be made to the existing endpoint but NO update should be made to the existing
TCB. TCB.
6) If the the local Verification Tag in the temporary TCB 6) If the the local Verification Tag in the temporary TCB
does not match the local Verification Tag in the existing does not match the local Verification Tag in the existing
TCB, then the cookie is a old stale cookie and does TCB, then the cookie is a old stale cookie and does
not correspond to the existing association (case C above). not correspond to the existing association (case C above).
The datagram should be silently discarded. The datagram should be silently discarded.
7) If the Peers Verification Tag in the temporary TCB does not 7) If the Peers Verification Tag in the temporary TCB does not
match the Peers Verification Tag in the existing TCB match the Peer's Verification Tag in the existing TCB
then a restart of the peer has occurred (case A above) and the then a restart of the peer has occurred (case A above).
endpoint should report the restart and respond with a COOKIE-ACK In such a case, the endpoint should report the restart to its ULP
message; Updating the Verification Tag, starting sequence and respond the peer with a COOKIE ACK message. It shall also
number, and network information of its peer from the temporary update the Verification Tag, initial TSN, and the destination
TCB to the existing TCB. After which the temporary TCB may be address list of the existing TCB with the information from the
discarded. temporary TCB. After that the temporary TCB can be discarded.
Furthermore, all the congestion control parameters (e.g., cwnd,
ssthresh) related to this peer shall be reset to their initial
values (see Section 6.2.1).
IMPLEMENTATION NOTE: It is an implementation decision on how IMPLEMENTATION NOTE: It is an implementation decision on how
to handle any pending datagrams. The implementation may elect to handle any pending datagrams. The implementation may elect
to either A) send all messages up to its upper layer with the to either A) send all messages back to its upper layer with the
restart report, or B) automatically requeue any datagrams restart report, or B) automatically re-queue any datagrams
pending, marking all to the unsent state and assigning pending by marking all of them as never-sent and assigning
new TSN's at the time of initial transmit based upon the new TSN's at the time of their initial transmissions based upon
updated starting sequence number (as defined in section 5.5). the updated starting TSN (as defined in section 5.5).
4.2.5 Handle Duplicate COOKIE-ACK. 4.2.5 Handle Duplicate COOKIE-ACK.
At any state other than COOKIE-Sent a endpoint may receive a At any state other than COOKIE-SENT, an endpoint may receive a
duplicated COOKIE-ACK chunk. If so, the chunk should be silently duplicated COOKIE ACK chunk. If so, the chunk should be silently
discarded. discarded.
4.2.6 Handle Stale COOKIE Error 4.2.6 Handle Stale COOKIE Error
A stale cookie error indicates one of a number of possible events: A stale cookie error indicates one of a number of possible events:
A) that the association failed to completely setup before the A) that the association failed to completely setup before the
cookie issued by the sender was processed. cookie issued by the sender was processed.
B) an old cookie was processed after setup completed. B) an old cookie was processed after setup completed.
C) an old cookie is received from someone that the receiver is C) an old cookie is received from someone that the receiver is
not interested in having a association with and the ABORT not interested in having a association with and the ABORT
message was lost. message was lost.
When processing a stale cookie a endpoint should first examine When processing a stale cookie an endpoint should first examine
if an association is in the process of being setup, i.e. the if an association is in the process of being setup, i.e. the
association is in the COOKIE-SENT state. In all cases if association is in the COOKIE-SENT state. In all cases if
the association is NOT in the COOKIE-SENT state, the stale the association is NOT in the COOKIE-SENT state, the stale
cookie message should be silently discarded. cookie message should be silently discarded.
If the association is in the COOKIE-SENT state, the endpoint If the association is in the COOKIE-SENT state, the endpoint may elect
may elect one of three alternatives. one of the following three alternatives.
1) Send a new INIT message to the endpoint, to generate 1) Send a new INIT message to the endpoint, to generate a new cookie
a new cookie and re-attempt the setup procedure. and re-attempt the setup procedure.
2) Discard the TCB and report to the upper layer the 2) Discard the TCB and report to the upper layer the inability of
inability to setup the association. setting-up the association.
3) Send a new INIT message to the endpoint, adding a cookie 3) Send a new INIT message to the endpoint, adding a cookie
preservative requesting a time extentsion on the life of the preservative parameter requesting an extentsion on the life time of
cookie. When calculating the time extension, an implementation the cookie. When calculating the time extension, an implementation
SHOULD use Round Trip Time (RTT) information generated from SHOULD use the RTT information measured based on the previous
the original COOKIE <-> Stale COOKIE timing and should add no more COOKIE / Stale COOKIE message exchange, and should add no more
than 1,000,000 microseconds beyond the RTT. Long cookie lives will than 1 second beyond the measured RTT, due to a long cookie life
make a endpoint more subject to a replay attack. time makes the endpoint more subject to a replay attack.
4.3 Other Initialization Issues 4.3 Other Initialization Issues
4.3.1 Selection of Tag Value 4.3.1 Selection of Tag Value
Initiate Tag values should be selected from the range of 0x1 to Initiate Tag values should be selected from the range of 0x1 to
0xffffffff. It is very important that the Tag value be randomized to 0xffffffff. It is very important that the Tag value be randomized to
help protect against "man in the middle" and "sequence number" attacks. help protect against "man in the middle" and "sequence number" attacks.
It is suggested that RFC 1750 [1] be used for the Tag randomization. It is suggested that RFC 1750 [1] be used for the Tag randomization.
skipping to change at line 2278 skipping to change at page 49, line 37
(1) When converting user messages into Data chunks, SCTP sender (1) When converting user messages into Data chunks, SCTP sender
will segment user messages larger than the current path MTU will segment user messages larger than the current path MTU
into multiple data chunks. The segmented message will be into multiple data chunks. The segmented message will be
reassembled from data chunks before delivery by the SCTP reassembled from data chunks before delivery by the SCTP
receiver. receiver.
(2) Multiple data and control chunks may be multiplexed by the (2) Multiple data and control chunks may be multiplexed by the
sender into a single SCTP datagram for transmission, as long as sender into a single SCTP datagram for transmission, as long as
the final size of the datagram does not exceed the current path the final size of the datagram does not exceed the current path
MTU. The receiver will de-multiplex the datagram back into MTU. The receiver will de-multiplex the datagram back into
chunks. the original chunks.
The bundling and segmentation mechanisms, as detailed in Sections 5.9 The bundling and segmentation mechanisms, as detailed in Sections 5.9
and 5.10, are optional to implement by the data sender, but they MUST and 5.10, are optional to implement by the data sender, but they MUST
be implemented by the data receiver, i.e., a SCTP receiver MUST be be implemented by the data receiver, i.e., a SCTP receiver MUST be
prepared to receive and process bundled or segmented data. prepared to receive and process bundled or segmented data.
5.1 Transmission of DATA Chunks 5.1 Transmission of DATA Chunks
The following general rules SHALL be applied by the sender for The following general rules SHALL be applied by the sender for
transmission and/or retransmission of outbound DATA chunks: transmission and/or retransmission of outbound DATA chunks:
A) At any given time, the sender MUST NOT transmit new data onto any A) At any given time, the sender MUST NOT transmit new data onto any
destination transport address if it has rwnd or more octets of data destination transport address if it has rwnd or more octets of data
outstanding. The outstanding data size is defined as the total size outstanding. The outstanding data size is defined as the total size
of ALL data chunks outstanding. of ALL data chunks outstanding.
However, regardless of the value of rwnd (including if it is 0),
the sender can always have ONE data packet in flight to the
receiver. This rule allows the sender to probe for a change in rwnd
that the sender missed due to the update having been lost in
transmission from the receiver to the sender.
B) At any given time, the sender MUST NOT transmit new data onto a B) At any given time, the sender MUST NOT transmit new data onto a
given transport address if it has cwnd or more octets of data given transport address if it has cwnd or more octets of data
outstanding on that transport address. outstanding on that transport address.
C) When the time comes for the sender to transmit, before sending C) When the time comes for the sender to transmit, before sending
new DATA chunks, the sender MUST first transmit any outstanding new DATA chunks, the sender MUST first transmit any outstanding
DATA chunks which are marked for retransmission. 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 D) Then, the sender can send out as many new DATA chunks as Rule A and
Rule B above allow. Rule B above allow.
Note: multiple DATA chunks committed for transmission MAY be Note: multiple DATA chunks committed for transmission MAY be
bundled in a single packet, unless bundling is explicitly disallowed bundled in a single packet, unless bundling is explicitly disallowed
by ULP of the data sender. Also, it is implementation specific by ULP of the data sender. Furthermore, DATA chunks being
whether to allow the bundling of retransmission DATA chunks with retransmitted MAY be bundled with new DATA chunks, as long as the
new DATA chunks. resulting packet size does not exceed the path MTU.
Note: if there are any unacknowledged DATA chunks (e.g., due to Note: before a sender transmits a data packet, if any received DATA
delayed ack), the sender should create a SACK and bundle it with chunks have not been acknowledged (e.g., due to delayed ack), the
the outbound DATA chunk, as long as the size of the final SCTP sender should create a SACK and bundle it with the outbound DATA
datagram does not exceed the current MTU. See Section 5.2. chunk, as long as the size of the final SCTP datagram does not exceed
the current MTU. See Section 5.2.
IMPLEMENTATION Note: if the window is full (i.e., transmission is IMPLEMENTATION Note: when the window is full (i.e., transmission is
disallowed by Rule A and/or Rule B), the sender MAY still accept disallowed by Rule A and/or Rule B), the sender MAY still accept
send requests from its upper layer, but SHALL transmit no more DATA send requests from its upper layer, but SHALL transmit no more DATA
chunks until some or all of the outstanding DATA chunks are chunks until some or all of the outstanding DATA chunks are
acknowledged and transmission is allowed by Rule A and Rule B acknowledged and transmission is allowed by Rule A and Rule B
again. again.
In all cases, if a transmission or retransmission of a DATA chunk is Whenever a transmission or retransmission is made, if T3-rxt timer is
made, the sender shall start the retransmission timer (T3-rxt) if it not currently running, the sender MUST start the timer. However, if
is not currently running. The T3-rxt timer value must be adjusted the timer is already running, the sender SHALL restart the timer ONLY
according to the timer rules defined in Sections 5.3.2, and 5.3.3. IF the earliest (i.e., lowest TSN) outstanding DATA chunk is being
retransmitted.
Note: If rwnd is set to 0, and all outstanding DATA chunks are When starting or restarting the T3-rxt timer, the timer value must be
acknowledged, a sender is allowed to send ONE new DATA chunk up to the adjusted according to the timer rules defined in Sections 5.3.2,
size of current path MTU, to probe the receiver for changes to rwnd. and 5.3.3.
5.2 Acknowledgment on Reception of DATA Chunks 5.2 Acknowledgment on Reception of DATA Chunks
The SCTP receiver MUST always acknowledge the SCTP sender about the The SCTP receiver MUST always acknowledge the SCTP sender about the
reception of each DATA chunk. reception of each DATA chunk.
The guidelines on delayed acknowledgment algorithm specified in The guidelines on delayed acknowledgment algorithm specified in
Section 4.2 of RFC 2581 [3] SHOULD be followed. In particular, a SCTP Section 4.2 of RFC 2581 [3] SHOULD be followed. Specifically, an
receiver MUST NOT excessively delay acknowledgments. Specifically, an
acknowledgement SHOULD be generated for at least every second datagram acknowledgement SHOULD be generated for at least every second datagram
received, and SHOULD be generated within 200 ms of the arrival of any received, and SHOULD be generated within 200 ms of the arrival of any
unacknowledged datagram. unacknowledged datagram.
IMPLEMENTATION NOTE: the maximal delay for generating an IMPLEMENTATION NOTE: the maximal delay for generating an
acknowledgement may need to be configurable by the SCTP user, acknowledgement may be configured by the SCTP user, either
either statically or dynamically, in order to meet the specific statically or dynamically, in order to meet the specific
timing requirement of the signaling protocol being carried. timing requirement of the signaling protocol being carried.
Acknowledgments MUST be sent in SACK control chunks. A SACK chunk can Acknowledgments MUST be sent in SACK control chunks. A SACK chunk can
acknowledge the reception of multiple DATA chunks. See Section 2.3.3 acknowledge the reception of multiple DATA chunks. See Section 2.3.3
for SACK chunk format. In particular, the SCTP receiver MUST fill the for SACK chunk format. In particular, the SCTP receiver MUST fill in
Highest Consecutive TSN ACK field to indicate the highest consecutive the Cumulative TSN ACK field to indicate the latest cumulative TSN
TSN number it has received, and any received segments beyond the number it has received, and any received segments beyond the
highest consecutive TSN SHALL also be reported. Cumulative TSN SHALL also be reported.
Upon reception of the SACK, the data sender MUST adjust its total Upon reception of the SACK, the data sender MUST adjust its total
outstanding data count and the outstanding data count on those outstanding data count and the outstanding data count on those
destination addresses for which one or more data chunks is destination addresses for which one or more data chunks is
acknowledged by the SACK. acknowledged by the SACK.
The following example illustrates the use of delayed acknowledgments: The following example illustrates the use of delayed acknowledgments:
Endpoint A Endpoint Z Endpoint A Endpoint Z
skipping to change at line 2381 skipping to change at page 51, line 52
/------- SACK [TSN ACK=8,Frag=0] /------- SACK [TSN ACK=8,Frag=0]
(cancel T3-rxt timer) <-----/ (cancel T3-rxt timer) <-----/
... ...
... ...
DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed) DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rxt timer) (Start T3-rxt timer)
... ...
{App sends 1 message; strm 1} {App sends 1 message; strm 1}
(bundle SACK with DATA) (bundle SACK with DATA)
/----- SACK [TSN Ack=9,Seg=0] \ /----- SACK [TSN Ack=9,Frag=0] \
/ DATA [TSN=6,Strm=1,Seq=2] / DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rxt timer) <------/ (Start T3-rxt timer) (cancel T3-rxt timer) <------/ (Start T3-rxt timer)
(ack delayed) (ack delayed)
... ...
(send ack) (send ack)
SACK [TSN ACK=6,Seg=0] --------------> (cancel T3-rxt timer) SACK [TSN ACK=6,Frag=0] -------------> (cancel T3-rxt timer)
5.3 Management of Retransmission Timer 5.3 Management of Retransmission Timer
SCTP uses a retransmission timer T3-rxt to ensure data delivery in the SCTP uses a retransmission timer T3-rxt to ensure data delivery in the
absence of any feedback from the remote data receiver. The duration of absence of any feedback from the remote data receiver. The duration of
this timer is referred to as RTO (retransmission timeout). this timer is referred to as RTO (retransmission timeout).
When the receiver endpoint is multi-homed, the data sender endpoint
will calculate a separate RTO for each different destination transport
addresses of the receiver endpoint.
The computation and management of RTO in SCTP follows closely with how The computation and management of RTO in SCTP follows closely with how
TCP manages its retransmission timer. To compute the current RTO, an TCP manages its retransmission timer. To compute the current RTO, an
SCTP sender maintains two state variables per destination transport SCTP sender maintains two state variables per destination transport
address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time
variation). variation).
5.3.1 RTO Calculation 5.3.1 RTO Calculation
The rules governing the computation of SRTT, RTTVAR, and RTO are The rules governing the computation of SRTT, RTTVAR, and RTO are
as follows: as follows:
C1) Until an RTT measurement has been made for a packet sent C1) Until an RTT measurement has been made for a packet sent
to the given destination transport address, set RTO to the to the given destination transport address, set RTO to the
protocol parameter 'RTO.Initial'. protocol parameter 'RTO.Initial'.
C2) When the first RTT measurement R is made, set SRTT <- R, C2) When the first RTT measurement R is made, set SRTT <- R,
RTTVAR <- R/2, and RTO <- SRTT + K * RTTVAR, where K = 4. RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR.
C3) When a new RTT measurement R' is made, set C3) When a new RTT measurement R' is made, set
RTTVAR <- beta * RTTVAR + (1 - beta) * |SRTT - R'| RTTVAR <- beta * RTTVAR + (1 - beta) * |SRTT - R'|
SRTT <- alpha * SRTT + (1 - alpha) * R' SRTT <- alpha * SRTT + (1 - alpha) * R'
(The value of SRTT used in the update to RTTVAR is its value (The value of SRTT used in the update to RTTVAR is its value
*before* updating SRTT itself using the second assignment.) *before* updating SRTT itself using the second assignment.)
The above are computed using alpha=1/8 and beta=1/4. The above are computed using alpha=1/8 and beta=1/4.
After the computation, update RTO <- SRTT + 4 * RTTVAR. After the computation, update RTO <- SRTT + 4 * RTTVAR.
C4) It is RECOMMENDED that new RTT measurements should be made C4) When data is in flight and when allowed by rule C5 below, a new
no more than once per round-trip for a given destination RTT measurement MUST be made each round trip. Furthermore,
transport address. There are two reasons for this recommendation: it is RECOMMENDED that new RTT measurements should be made no
first, it appears that measuring more often does not in practice more than once per round-trip for a given destination transport
yield any significant benefit [5]; second, if measurements address. There are two reasons for this recommendation: first,
are made more often, then the values of alpha and beta in it appears that measuring more frequently often does not in
rule C3 above must be adjusted so that SRTT and RTTVAR still practice yield any significant benefit [5]; second, if
adjust to changes at roughly the same rate (in terms of measurements are made more often, then the values of alpha and
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 them to reflect new value) as how many round trips it takes them to reflect new value) as
they would if making only one measurement per round-trip they would if making only one measurement per round-trip and
and using alpha and beta as given in rule C3. using alpha and 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 C5) Karn's algorithm: RTT measurements MUST NOT be made using
packets that were retransmitted (and thus for which it is packets that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of the ambiguous whether the reply was for the first instance of the
packet or a later instance). packet or a later instance).
C6) Whenever RTO is computed, if it is less than 1 second then C6) Whenever RTO is computed, if it is less than 1 second then
it is rounded up to 1 second. The reason for this rule is it is rounded up to 1 second. The reason for this rule is
that RTOs that do not have a high minimum value are susceptible that RTOs that do not have a high minimum value are susceptible
to unnecessary timeouts [5]. to unnecessary timeouts [5].
skipping to change at line 2467 skipping to change at page 53, line 46
perform somewhat better than more coarse granularities. perform somewhat better than more coarse granularities.
5.3.2 Retransmission Timer Rules 5.3.2 Retransmission Timer Rules
The rules for managing the retransmission timer are as follows: The rules for managing the retransmission timer are as follows:
R1) Every time a packet containing data is sent (including a R1) Every time a packet containing data is sent (including a
retransmission), if the T3-rxt timer is not running, start it retransmission), if the T3-rxt timer is not running, start it
running so that it will expire after RTO seconds. The RTO running so that it will expire after RTO seconds. The RTO
used here is that obtained after any doubling due to used here is that obtained after any doubling due to
retransmission as discussed in rule E3 below. previous T3-rxt timer expirations on the coresponding destination
address as discussed in rule E2 below.
R2) Whenever all outstanding data has been acknowledged, turn R2) Whenever all outstanding data has been acknowledged, turn off the
off the retransmission timer. T3-rxt timer.
R3) Whenever a SACK is received that acknowledges new data chunks R3) Whenever a SACK is received that acknowledges new data chunks
including the one with the earliest outstanding TSN (i.e., moving including the one with the earliest outstanding TSN (i.e., moving
the cumulative ACK point forward), the cumulative ACK point forward), restart T3-rxt timer with the
restart T3-rxt retransmission timer so that it will expire current RTO.
after RTO seconds (for the current value of RTO).
The following example shows the use of various timer rules (assuming The following example shows the use of various timer rules (assuming
the receiver uses delayed acks). the receiver uses delayed acks).
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 2 messages; strm 0} {App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rxt timer) (Start T3-rxt timer)
{App sends 1 message; strm 1} {App sends 1 message; strm 1}
(bundle ack with data) (bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN ACK=7,Frag=0] \ DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN ACK=7,Frag=0] \
\ / DATA [TSN=6,Strm=1,Seq=2] \ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rxt timer) \ / (Start T3-rxt timer)
\ \
/ \ / \
(Re-start T3-rxt timer) <------/ \--> (ack delayed) (Re-start T3-rxt timer) <------/ \--> (ack delayed)
(ack delayed) (ack delayed)
... ...
{send ack} {send ack}
SACK [TSN ACK=6,Frag=0] --------------> (Cancel T3-rxt timer) SACK [TSN ACK=6,Frag=0] --------------> (Cancel T3-rxt timer)
.. ..
(send ack) (send ack)
(Cancel T3-rxt timer) <-------------- SACK [TSN ACK=8,Frag=0] (Cancel T3-rxt timer) <-------------- SACK [TSN ACK=8,Frag=0]
5.3.3 Handle T3-rxt Expiration 5.3.3 Handle T3-rxt Expiration
Whenever the retransmission timer T3-rxt expires, do the following: Whenever the retransmission timer T3-rxt expires on a destination
address, do the following:
E1) Adjust ssthresh with rules defined in Section 6.2.3.
E2) Determine how many of the earliest (i.e., lowest TSN) E1) On the destination address where the timer expires, adjust its
outstanding Data chunks will fit into a single packet, ssthresh with rules defined in Section 6.2.3 and set the
subject to the MTU constraints for the path corresponding to
the destination transport address. Call this value K.
Retransmit those K data chunks in a single packet, and set
cwnd <- MTU. cwnd <- MTU.
E3) Set RTO <- RTO * 2 ("back off the timer"). The maximum value E2) On the destination address where the timer expires, set
discussed in rule C7 above may be used to provide an upper bound RTO <- RTO * 2 ("back off the timer"). The maximum value discussed
to this doubling operation. in rule C7 above may be used to provide an upper bound to this
doubling operation.
E4) Start the retransmission timer, per rule R1 above. E3) Determine how many of the earliest (i.e., lowest TSN) outstanding
Data chunks will fit into a single packet, subject to the MTU
constraint for the path corresponding to the destination transport
address where the retransmission is being sent to (this may be
different from the address where the timer expires [see Section
5.4]). Call this value K. Retransmit those K data chunks in a
single packet to the address.
Note, the data sender MAY use a value smaller than the RTO when E4) Start the retransmission timer on the destination address to where
start the retransmission timer IF the sender has fewer than the retransmission is sent, if rule R1 above indicates to do so.
cwnd octets of outstanding data on the transport address to which
the retransmission is being sent.
Note that after retransmitting, once a new RTT measurement is obtained Note that after retransmitting, once a new RTT measurement is obtained
(which can only happen when new data has been sent and acknowledged, (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 per rule C5, or for a measurement made from a Heartbeat [see Section
7.3]), the computation in rule C3 is performed, including the 7.3]), the computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down computation of RTO, which may result in "collapsing" RTO back down
after it has been subject to doubling (rule E3). after it has been subject to doubling (rule E2).
The final rule for managing the retransmission timer concerns failover: The final rule for managing the retransmission timer concerns failover
(see Section 5.4.1):
F1) Whenever SCTP switches from the current destination transport F1) Whenever SCTP switches from the current destination transport
address to a different one (per section 5.4), the current address to a different one, the current retransmission timer is
retransmission timer is left running. As soon as SCTP transmits left running. As soon as SCTP transmits a packet containing data
a packet containing data to the new transport address, restart the to the new transport address, restart the timer, using the RTO
timer, using the RTO value for the path to the new address. value for the path to the new address, if rule R1 indicates to
do so.
5.4 Multi-homed SCTP Endpoints 5.4 Multi-homed SCTP Endpoints
An SCTP endpoint is considered multi-homed if there are more than one An SCTP endpoint is considered multi-homed if there are more than one
transport addresses that can be used as a destination address to reach transport addresses that can be used as a destination address to reach
that endpoint. that endpoint.
Moreover, at the sender side, one of the multiple destination Moreover, at the sender side, one of the multiple destination
addresses of the multi-homed receiver endpoint shall be selected as addresses of the multi-homed receiver endpoint shall be selected as
the primary destination transport address by the UPL (see Section 9 the primary destination transport address by the UPL (see Section 9
for details). for details).
At association initiation, the initial primary destination transport At association initiation, the initial primary destination transport
addresses are: addresses are:
- for the sender of the INIT message, the transport address that the - for the sender of the INIT message, the transport address that the
INIT is sent on. This may be changed upon reception of the INIT is sent to.
destination transport address list in the INIT ACK message from the
peer.
- for the sender of the INTI ACK message, any valid transport address - for the sender of the INTI ACK message, any valid transport address
obtained from the INIT message. obtained from the INIT message.
When the SCTP sender is transmitting to the multi-homed receiver, by When the SCTP sender is transmitting to the multi-homed receiver, by
default the transmission SHOULD always take place on the primary default the transmission SHOULD always take place on the primary
transport address, unless the SCTP user explicitly specifies the transport address, unless the SCTP user explicitly specifies the
destination transport address to use. destination transport address to use.
If possible, acknowledgements SHOULD be transmitted to the same The acknowledgement SHOULD be transmitted to the same destination
destination transport address from which the acknowledged DATA or transport address from which the DATA or control chunk being
control chunks were received (Note: when acknowledging multiple DATA acknowledged were received.
chunks in a single SACK, this may not be possible).
Some of the destination transport addresses may become inactive due to However, when acknowledging multiple DATA chunks in a single SACK, the
either the occurrance of certain error conditions or adjustments from SACK message may be transmitted to one of the destination transport
SCTP user. addresses from which the DATA or control chunks being acknowledged
were received.
In the case where the primary destination transport address becomes Furthermore, when the receiver is multi-homed, the SCTP data sender
inactive, or the SCTP user tries to explicitly send to an inactive SHOULD try to retransmit a chunk to an active destination transport
destination transport address, the SCTP sender should either send the address that is different from the last destination address where the
chunk to an alternate active destination transport address, or to data chunk was sent to.
report an error. This is implementation specific.
Also, when the SCTP receiver is multi-homed, an SCTP sender SHOULD Note, retransmissions do not affect the total outstanding data
always try to retransmit a chunk to an active destination transport count. However, if the data chunk is retransmitted onto a different
address that is different from the original destination address used destination address, both the outstanding data counts on the new
to transmit that chunk. Retransmissions do not affect the total destination address and the old destination address where the data
outstanding data count. However, if the data chunk is retransmitted chunk was last sent to shall be adjusted accordingly.
onto a different destination address, the outstanding data counts on
the new destination address and the old destination address where the 5.4.1 Failover from Inactive Destination Address
data chunk was originally sent to shall be adjusted accordingly.
Some of the destination transport addresses of a multi-homed SCTP data
receiver may become inactive due to either the occurrance of certain
error conditions (see Section 7.2) or adjustments from SCTP user.
When there is outbound data to send and the primary destination
transport address 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 sender should try to send the data to an alternate active
destination transport address if one exists.
5.5 Stream Identifier and Sequence Number 5.5 Stream Identifier and Sequence Number
Every DATA chunk MUST carry a valid stream identifier. If a DATA chunk Every DATA chunk MUST carry a valid stream identifier. If a DATA chunk
with an invalid stream identifier is received, the receiver shall with an invalid stream identifier is received, the receiver shall
respond immediately with an ERROR message with cause set to Invalid respond immediately with an ERROR message with cause set to Invalid
Stream Identifier (see Section 2.3.9) and discard the DATA chunk. Stream Identifier (see Section 2.3.9) and discard the DATA chunk.
The stream sequence number in all the streams shall start from 0x0 The stream sequence number in all the streams shall start from 0x0
when the association is established. Also, when the stream sequence when the association is established. Also, when the stream sequence
number reaches the value 0xffff the next sequence number shall be set number reaches the value 0xffff the next sequence number shall be set
to 0x0. to 0x0.
5.6 Ordered and Un-ordered Delivery 5.6 Ordered and Un-ordered Delivery
Normally, the SCTP receiver shall ensure the DATA chunks within any By default the SCTP receiver shall ensure the DATA chunks within any
given stream be delivered to the upper layer according to the order of given stream be delivered to the upper layer according to the order of
their stream sequence number. If there are DATA chunks arriving out of their stream sequence number. If there are DATA chunks arriving out of
order of their stream sequence number, the receiver MUST hold the order of their stream sequence number, the receiver MUST hold the
received DATA chunks from delivery until they are re-ordered. received DATA chunks from delivery until they are re-ordered.
However, an SCTP sender can indicate that no ordered delivery is However, an SCTP sender can indicate that no ordered delivery is
required on a particular DATA chunk within the stream by setting the U required on a particular DATA chunk within the stream by setting the U
flag of the DATA chunk to 1. flag of the DATA chunk to 1.
In this case, the receiver must ignore the sequence number field of In this case, the receiver must bypass the ordering mechanism and
the data chunk, bypass the ordering mechanism and immediately delivery immediately delivery the data to the upper layer (after re-assembly if
the data to the upper layer (after re-assembly if the user data is the user data is segmented by the sender).
segmented by the sender).
This provides an effective way of transmitting "out-of-band" data in a 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 given stream. Also, a stream can be used as an "unordered" stream by
simply setting the U flag to 1 in each outbound DATA chunk from that simply setting the U flag to 1 in all outbound DATA chunks sent
stream. through that stream.
IMPLEMENTATION NOTE: An implementation, when sending an unordered IMPLEMENTATION NOTE: when sending an unordered DATA chunk, an
DATA chunk, may choose to place the DATA chunk in an outbound implementation may choose to place the DATA chunk in an outbound
datagram at the head of the outbound transmission queue if datagram that is at the head of the outbound transmission queue if
possible. possible.
Note that the 'Sequence Number' field in an un-ordered data chunk has
no significance; the sender can fill it with arbitrary value, but the
receiver MUST ignore the field.
5.7 Report Gaps in Received DATA TSNs 5.7 Report Gaps in Received DATA TSNs
Upon the reception of a new DATA chunk, an SCTP receiver shall examine Upon the reception of a new DATA chunk, an SCTP receiver shall examine
the continuity of the TSNs received. If the receiver detects that gaps the continuity of the TSNs received. If the receiver detects that gaps
exist in the received DATA chunk sequence, an SACK with fragment exist in the received DATA chunk sequence, an SACK with fragment
reports shall be sent back immediately. reports shall be sent back immediately.
Based on the segment reports from the SACK, the data sender can Based on the segment reports from the SACK, the data sender can
calculate the missing DATA chunks and make decisions on whether to calculate the missing DATA chunks and make decisions on whether to
retransmit them (see Section 5.3 for details). retransmit them (see Section 5.3 for details).
skipping to change at line 2731 skipping to change at page 59, line 31
invalid SCTP datagram. invalid SCTP datagram.
If the C Bit is not set, the receiver MUST NOT perform the above If the C Bit is not set, the receiver MUST NOT perform the above
CRC-16 check. CRC-16 check.
The default procedure of handling invalid SCTP datagrams is to The default procedure of handling invalid SCTP datagrams is to
silently discard them. silently discard them.
5.9 Segmentation 5.9 Segmentation
Segmentation SHALL be performed by the data sender if the user message Segmentation MUST be performed by the data sender if the user message
to be sent has a large size that causes the outbound SCTP datagram to be sent has a large size that causes the outbound SCTP datagram
size exceeding the current MTU. size exceeding the current MTU.
Note, if the data receiver is multi-homed, the sender shall choose a
size no larger than the latest MTU of the current primary destination
address.
When determining when to segment, the SCTP implementation MUST take When determining when to segment, the SCTP implementation MUST take
into account the SCTP datagram header as well as the DATA chunk into account the SCTP datagram header as well as the DATA chunk
header. The implementation MAY also take account of the space required header. The implementation MAY also take account of the space required
for a SACK chunk. for a SACK chunk.
IMPLEMENTATION NOTE: if the data receiver is multi-homed, the
latest MTU of the current primary destination address shall be
used.
IMPLEMENTATION NOTE: if segmentation is not support by the sender, IMPLEMENTATION NOTE: if segmentation is not support by the sender,
an error should be reported to the sender's SCTP user if the data to be an error should be reported to the sender's SCTP user if the data to be
sent has a size exceeding the current MTU. In such cases the Send sent has a size exceeding the current MTU. In such cases the Send
primitive discussed in Section 9.1 would need to return an error primitive discussed in Section 9.1 would need to return an error
to the upper layer. to the upper layer.
Segmentation takes the following steps: Segmentation takes the following steps:
1) the data sender SHALL break the large user message into a series of 1) the data sender SHALL break the large user message into a series of
DATA chunks, such that each of the chunks can be fit into an IP DATA chunks, such that each of the chunks can be fit into an IP
datagram smaller than the current MTU, datagram smaller than or equal to the current MTU,
2) the data sender MUST then assign, in sequence, a separate TSN to 2) the data sender MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series, each of the DATA chunks in the series,
3) the data sender MUST also set the B/E bits of the first DATA chunk 3) the data sender 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 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 '01', and the B/E bits of all other DATA chunks in the
series to '00'. series to '00'.
The data receiver MUST recognize the segmented DATA chunks, by The data receiver MUST recognize the segmented DATA chunks, by
examining the B/E bits in each of the received DATA chunks, and queue examining the B/E bits in each of the received DATA chunks, and queue
the segmented DATA chunks for re-assembly. Then, it shall pass the the segmented DATA chunks for re-assembly. Then, it shall pass the
re-assembled user message to the specific stream for re-ordering and re-assembled user message to the specific stream for re-ordering and
final dispatching. final dispatching.
5.10 Bundling and Multiplexing 5.10 Bundling and Multiplexing
An SCTP sender achieves data bundling by simply including multiple An SCTP sender achieves data bundling by simply including multiple
DATA chunks in one outbound SCTP datagram. Note that the total size of DATA chunks in one outbound SCTP datagram. Note that the total size of
the resultant SCTP datagram, including the SCTP common header, MUST be the resultant IP datagram, including the SCTP datagram, and the UDP
less or equal to the current MTU. and IP headers, MUST be less or equal to the current MTU.
IMPLEMENTATION NOTE: if the data receiver is multi-homed, the Note, if the data receiver is multi-homed, the sender shall choose a
latest MTU of the current primary destination address shall be size no larger than the latest MTU of the current primary destination
used. address.
When multiplexing control chunks with DATA chunks, control chunks have When multiplexing control chunks with DATA chunks, control chunks have
the priority and MUST be placed first in the outbound SCTP datagram the priority and MUST be placed first in the outbound SCTP datagram
and be transmitted first. The transmitter MUST transmit DATA chunks and be transmitted first. The transmitter MUST transmit DATA chunks
within a SCTP datagram in increasing order of TSN. within a SCTP datagram in increasing order of TSN.
Partial chunks MUST NOT be placed in a SCTP datagram. Partial chunks MUST NOT be placed in a SCTP datagram.
The receiver MUST process the chunks in order in the datagram. The The receiver MUST process the chunks in order in the datagram. The
receiver uses the chunk length field to determine the end of a chunk 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 and beginning of the next chunk taking account of the fact that all
chunks end on a thirty-two-bit word boundary. If the receiver detects chunks end on a thirty-two-bit word boundary. If the receiver detects
a partial chunk, it MUST drop the chunk. a partial chunk, it MUST drop the chunk.
6. Congestion control 6. Congestion control
Congestion control is one of the basic functions in the SCTP protocol. Congestion control is one of the basic functions in the SCTP protocol.
It is likely that adequate resources will be allocated to SCTP traffic For some applications, it may be likely that adequate resources will
to assure prompt delivery of time-critical SCTP data, thus it would be be allocated to SCTP traffic to assure prompt delivery of
unlikely, during normal operations, that SCTP transmissions encounter time-critical SCTP data - thus it would appear to be unlikely, during
severe congestion condition. However SCTP must prepare itself for normal operations, that SCTP transmissions encounter severe congestion
adverse operational conditions, which can develop upon partial network
failures or unexpected traffic surge. In such situations SCTP must condition. However SCTP must prepare itself for adverse operational
follow correct congestion control steps to recover from congestion conditions, which can develop upon partial network failures or
quickly in order to get data delivered as soon as possible. In the unexpected traffic surge. In such situations SCTP must follow correct
absence of network congestion, these preventive congestion control congestion control steps to recover from congestion quickly in order
algorithms will show no impact on the protocol performance. 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.
The congestion control algorithms used by SCTP are based on RFC 2581 The congestion control algorithms used by SCTP are based on RFC 2581
[3], "TCP Congestion Control". This section describes how the [3], "TCP Congestion Control". This section describes how the
algorithms defined in RFC 2581 are adopted for use in SCTP. We first algorithms defined in RFC 2581 are adopted for use in SCTP. We first
list differences in protocol designs between TCP and SCTP, and then list differences in protocol designs between TCP and SCTP, and then
describe SCTP's congestion control scheme. The description will use describe SCTP's congestion control scheme. The description will use
the same terminology as in TCP congestion control whenever the same terminology as in TCP congestion control whenever
appropriate. appropriate.
6.1 SCTP Differences from TCP Congestion control 6.1 SCTP Differences from TCP Congestion control
One difference from TCP is that Selective Acknowledgment function One difference from TCP is that Selective Acknowledgment function
(SACK) is designed into SCTP, rather than an enhancement that is added (SACK) is designed into SCTP, rather than an enhancement that is added
to the protocol later as the case for TCP. SCTP SACK carries to the protocol later as is the case for TCP. SCTP SACK carries
different semantic meanings from that of TCP SACK. TCP considers the different semantic meanings from that of TCP SACK. TCP considers the
information carried in the SACK as advisory information only. In information carried in the SACK as advisory information only. In
SCTP, any DATA chunk that has been acknowledged by SACK, including SCTP, any DATA chunk that has been acknowledged by SACK, including
DATA that arrived at the receiving end out of order, are considered DATA that arrived at the receiving end out of order, are considered
having been delivered to the destination application, and the sender having been delivered to the destination application, and the sender
is free to discard the local copy. Thus the value of cwnd controls is free to discard the local copy. Consequently, the value of cwnd
the number of outstanding data; it is not the upper bound between the controls the amount of outstanding data, rather than the upper bound
highest acknowledged sequence number and the latest DATA chunk that between the highest acknowledged sequence number and the latest DATA
can be sent within the congestion window, as the case in TCP. SCTP chunk that can be sent within the congestion window, as is the case in
SACK leads to different implementations of fast-retransmit and TCP. SCTP SACK leads to different implementations of fast-retransmit
fast-recovery from that of TCP. and fast-recovery from that of TCP.
The biggest difference between SCTP and TCP, however, is multi-homing. The biggest difference between SCTP and TCP, however, is multi-homing.
SCTP is designed to establish robust communication associations SCTP is designed to establish robust communication associations
between two end points each of which may be reachable by more than one between two end points each of which may be reachable by more than one
transport address. Potentially different addresses may lead to transport address. Potentially different addresses may lead to
distinguished data paths between the two points, thus ideally one may distinguished data paths between the two points, thus ideally one may
need a separate set of congestion control parameters for each of the need a separate set of congestion control parameters for each of the
paths. Given SCTP is the first transport protocol whose design paths. The treatment here of congestion control for multihomed
specifically takes multihoming issue into consideration, however, receivers is new with SCTP and may require refinement in the
there is no experience at this point regarding the use of multiple future. The current algorithms make the following assumptions:
addresses, or the likelyhood of each address pair representing a
separate path. To proceed with caution, we make the following
assumptions:
o the sender does not change the use of source address often, if at o The sender does not change the use of source address often,
all. if at all.
o the sender always uses the same destination address until being
o The sender always uses the same destination address until being
instructed by the upper layer otherwise. instructed by the upper layer otherwise.
o the sender keeps a separate congestion control parameter set for each
o The sender keeps a separate congestion control parameter set for each
of the destination addresses. The parameters should decay if the of the destination addresses. The parameters should decay if the
address is not used for a long enough time period. address is not used for a long enough time period.
o For each of the destination addresses, do slow-start upon the first o For each of the destination addresses, do slow-start upon the first
transmission to that address. transmission to that address.
6.2 SCTP Slow-Start and Congestion Avoidance 6.2 SCTP Slow-Start and Congestion Avoidance
The slow start and congestion avoidance algorithms MUST be used by a The slow start and congestion avoidance algorithms MUST be used by a
SCTP sender to control the amount of outstanding data being injected SCTP sender to control the amount of outstanding data being injected
into the network. The congestion control in SCTP is employed in regard into the network. The congestion control in SCTP is employed in regard
to the association, not to an individual stream. In some situations it to the association, not to an individual stream. In some situations it
may be beneficial for a SCTP sender to be more conservative than the may be beneficial for a SCTP sender to be more conservative than the
skipping to change at line 2869 skipping to change at page 62, line 25
SCTP sender to control the amount of outstanding data being injected SCTP sender to control the amount of outstanding data being injected
into the network. The congestion control in SCTP is employed in regard into the network. The congestion control in SCTP is employed in regard
to the association, not to an individual stream. In some situations it to the association, not to an individual stream. In some situations it
may be beneficial for a SCTP sender to be more conservative than the may be beneficial for a SCTP sender to be more conservative than the
algorithms allow, however a SCTP sender MUST NOT be more aggressive than algorithms allow, however a SCTP sender MUST NOT be more aggressive than
the following algorithms allow. the following algorithms allow.
Like TCP, an SCTP sender uses the following three control variables to Like TCP, an SCTP sender uses the following three control variables to
regulate its transmission rate. regulate its transmission rate.
o Receiver advertised window size (rwnd), which is set by the o Receiver advertised window size (rwnd, in octets), which is set by
receiver based on its available buffer space for incoming packets. the receiver based on its available buffer space for incoming packets.
o Congestion control window (cwnd), which is adjusted by the sender
based on observed network conditions.
o Slow-start threshold (ssthresh), which is also used by the sender to
distinguish congestion control and congestion avoidance phases.
SCTP also requires one additional control variable, cwnd2, which is used o Congestion control window (cwnd, in octets), which is adjusted by
during congestion avoidance phase to facilitate cwnd adjustment. the sender based on observed network conditions.
o Slow-start threshold (ssthresh, in octets), which is also used by
the sender to distinguish congestion control and congestion
avoidance phases.
SCTP also requires one additional control variable, partial_bytes_acked,
which is used during congestion avoidance phase to facilitate cwnd
adjustment.
6.2.1 Slow-Start 6.2.1 Slow-Start
Beginning data transmission into a network with unknown conditions Beginning data transmission into a network with unknown conditions
requires SCTP to probe the network to determine the available capacity. 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 The slow start algorithm is used for this purpose at the beginning of a
transfer, or after repairing loss detected by the retransmission timer. transfer, or after repairing loss detected by the retransmission timer.
o The initial value of cwnd MUST be less than or equal to 2*MTU octets. o The initial value of cwnd MUST be less than or equal to 2*MTU octets.
o The initial value of ssthresh MAY be arbitrarily high (for example, o The initial value of ssthresh MAY be arbitrarily high (for example,
some implementations use the size of the receiver advertised window). some implementations use the size of the receiver advertised window).
o Whenever cwnd is greater than zero, the sender is allowed to have cwnd o Whenever cwnd is greater than zero, the sender is allowed to have cwnd
octets of data outstanding on that transport address. octets of data outstanding on that transport address.
o When cwnd is less than or equal to ssthresh AND the sender has cwnd or more
data outstanding on the transport address, cwnd is incremented by
the total number of octets of all new data chunks acknowledged in each
SACK received (piggy-backed or stand-alone SACKs).
o 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 RTT.
Note: a piggy-backed SACK is one that is bundled with a DATA chunk. o When cwnd is less than or equal to ssthresh AND the sender has cwnd
or more data outstanding on the transport address, cwnd is
incremented by MTU for each SACK received which advances the
cumulative TSN of the transport address.
o 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.
6.2.2 Congestion Avoidance 6.2.2 Congestion Avoidance
Whenever cwnd is increased to be equal or greater than ssthresh, cwnd Whenever cwnd is increased to be greater than ssthresh, cwnd should be
should be incremented by MTU per RTT if at time the sender has cwnd or incremented by MTU per RTT if at time the sender has cwnd or more
more octets of data outstanding on that transport address. octets of data outstanding on that transport address.
In practice an implementation can achieve this goal in the In practice an implementation can achieve this goal in the
following way: following way:
o cwnd2 is initialized to 0. o partial_bytes_acked is initialized to 0.
o Whenever cwnd is equal or greater than ssthresh, upon each SACK
arrival, increase cwnd2 by the total number of octets of all new o Whenever cwnd is greater than ssthresh, upon each SACK arrival,
chunks acknowledged in that SACK. increase partial_bytes_acked by the total number of octets of all
o When cwnd2 is equal or greater than cwnd and before the arrival of the new chunks acknowledged in that SACK.
SACK the sender has cwnd or more octets of data outstanding,
increase cwnd by MTU, and reset cwnd2 to (cwnd2 - cwnd). o When partial_bytes_acked is equal or greater than cwnd and before
the arrival of the SACK the sender has cwnd or more octets of data
outstanding, increase cwnd by MTU, and reset partial_bytes_acked to
(partial_bytes_acked - cwnd).
o Same as in the slow start, when the sender does not transmit data on 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 a given transport address, the cwnd of the transport address should
be adjusted to max(cwnd / 2, 2*MTU) per RTT. be adjusted to max(cwnd / 2, 2*MTU) per RTO.
6.2.3 Congestion Control 6.2.3 Congestion Control
Upon detection of packet losses from SACK, the sender should do the Upon detection of packet losses from SACK, the sender should do the
following: following:
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh/2 cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half(or 1/4??). Basically, a packet loss causes cwnd to be cut in half.
When the T3-rxt timer expires, SCTP should perform slow start by When the T3-rxt timer expires, SCTP should perform slow start by
setting cwnd = MTU, and assure that no more than one DATA chunk will setting cwnd = MTU, and assuring that no more than one data packet
be in flight until the sender receives acknowledgment for successful will be in flight until the sender receives acknowledgment for
delivery. successful delivery.
6.2.4 Fast Retransmit on Gap Reports 6.2.4 Fast Retransmit on Gap Reports
In the absence of data losses, a SCTP receiver performs delayed In the absence of data losses, a SCTP receiver performs delayed
acknowledgment. However whenever a receiver notices a hole in the acknowledgment. However whenever a receiver notices a hole in the
arriving TSN sequence, it should start sending a SACK for every arriving TSN sequence, it should start sending a SACK for every
packet arrival. packet arrival.
At the sender end, whenever the sender notices a hole in a SACK, it At the sender end, whenever the sender notices a hole in a SACK, it
should wait for 3 further SACKs before taking action. If the 3 should wait for 3 further SACKs before taking action. If the 3
subsequent SACKs report the same TSN(s) missing, the sender shall: subsequent SACKs report the same TSN(s) missing, the sender shall:
1) mark the DATA chunk(s) for retransmission, 1) Mark the missing DATA chunk(s) for retransmission,
2) adjust its ssthresh and cwnd according to the formula described in
Section 6.2.3. 2) Adjust the ssthresh and cwnd of the destination address(es) where
3) Restart T3-rxt timer if it is running, and the missing data chunks were last sent, according to the formula
4) start retransmission procedure, as described in Section 5.3.3. described in Section 6.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) missing Data
chunks 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-rxt timer ONLY IF the last SACK advanced the cumulative
TSN point, or we are retransmitting the first outstanding Data
chunk.
Note, before the above adjustments, if the received SACK also
acknowledges new data chunks and advances the cumulative TSN point,
the cwnd adjustment rules defined in Sections 6.2.1 and 6.2.2 must
be applied first.
A straightforward implementation of the above requires that the sender A straightforward implementation of the above requires that the sender
keeps a counter for each TSN hole first reported by a SACK; the keeps a counter for each TSN hole first reported by a SACK; the
counter keeps track of whether 3 subsequent SACKs have reported the counter keeps track of whether 3 subsequent SACKs have reported the
same hole. same hole.
Because cwnd in SCTP bounds the number of outstanding TSN's, Because cwnd in SCTP indirectly bounds the number of outstanding
the effect of TCP fast-recovery is achieved automatically with no TSN's, the effect of TCP fast-recovery is achieved automatically with
adjustment to the control window size. no adjustment to the congestion control window size.
6.3 Path MTU Discovery 6.3 Path MTU Discovery
RFC 1191 discusses "Path MTU Discovery", whereby a sender maintains an IMPLEMENTATION NOTE: in some operating systems, protocols sitting on
estimate of the maximum transmission unit (MTU) along a given Internet path top of UDP may not have access to the IP "Don't Fragment bit", nor
and refrains from sending datagrams along that path which exceed the MTU, do they have easy access to the ICMP messages. This can make the path
other than occasional attempts to probe for a change in the path MTU. MTU discovery difficult to realize. It is RECOMMENDED that in such a
RFC 1191 is thorough in its discussion of the MTU discovery mechanism and case a fixed MTU of at most 512 octets should be used by the SCTP
strategies for determining the current end-to-end MTU setting as well as data sender.
detecting changes in this value. RFC 1981 discusses applying the same
mechanisms for IPv6.
An SCTP sender MUST apply these techniques, and MUST do so on a RFC 1191 [11] discusses "Path MTU Discovery", whereby a sender
maintains an estimate of the maximum transmission unit (MTU) along a
given Internet path and refrains from sending datagrams along that
path which exceed the MTU, other than occasional attempts to probe for
a change in the path MTU. 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.
RFC 1981 discusses applying the same mechanisms for IPv6.
An SCTP sender SHOULD apply these techniques, and SHOULD do so on a
per-destination-address basis. per-destination-address basis.
There are 4 ways in which SCTP differs from the description in RFC 1191 of There are 4 ways in which SCTP differs from the description in RFC 1191
applying MTU discovery to TCP: of applying MTU discovery to TCP:
1) SCTP associations can span multiple set of addresses. 1) SCTP associations can span multiple set of addresses.
Per the above comment, an SCTP sender MUST maintain separate Per the above comment, an SCTP sender MUST maintain separate
MTU estimates for each destination address of its peer. MTU estimates for each destination address of its peer.
2) Elsewhere in this document, when the term "MTU" is discussed, 2) Elsewhere in this document, when the term "MTU" is discussed,
it refers to the MTU associated with the destination address it refers to the MTU associated with the destination address
corresponding to the context of the discussion. If this corresponding to the context of the discussion.
address is ambiguous, it indicates a bug in this document.
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment 3) Unlike TCP, SCTP does not have a notion of "Maximum Segment
Size". Accordingly, the MTU for each destination address Size". Accordingly, the MTU for each destination address
SHOULD be initialized to a value no larger than the link MTU SHOULD be initialized to a value no larger than the link MTU
for the local interface to which datagrams for that remote for the local interface to which datagrams for that remote
destination address will be routed. destination address will be routed.
4) Since data transmission in SCTP is naturally structured in 4) Since data transmission in SCTP is naturally structured in
terms of TSNs rather than bytes (as is the case for TCP), the terms of TSNs rather than bytes (as is the case for TCP), the
discussion in section 6.5 of RFC 1191 applies: when retransmitting discussion in section 6.5 of RFC 1191 applies: when retransmitting
a datagram to a remote address for which the datagram appears a datagram to a remote address for which the datagram appears
too large for the path MTU to that address, the datagram SHOULD too large for the path MTU to that address, the datagram SHOULD
be retransmitted without the DF bit set, allowing it to possibly be retransmitted without the DF bit set, allowing it to possibly
be fragmented. Transmissions of new datagrams MUST have DF set. be fragmented. Transmissions of new datagrams MUST have DF set.
Other than these differences, the discussion of TCP's use of MTU discovery Other than these differences, the discussion of TCP's use of MTU
in RFCs 1191 and 1981 applies to SCTP, too, on a per-destination-address discovery in RFCs 1191 and 1981 applies to SCTP, too, on a
basis. per-destination-address basis.
7. Fault Management 7. Fault Management
7.1 Endpoint Failure Detection 7.1 Endpoint Failure Detection
The data sender shall keep a counter on the total number of The data sender shall keep a counter on the total number of
consecutive retransmissions to its peer (including retransmissions to consecutive retransmissions to its peer (including retransmissions to
ALL the destination transport addresses of the peer if it is ALL the destination transport addresses of the peer if it is
multi-homed). multi-homed).
If the value of this counter exceeds the limit defined in the protocol If the value of this counter exceeds the limit indicated in the
parameter 'Max.Retransmits', the data sender shall consider the peer protocol parameter 'Association.Max.Retrans', the data sender shall
endpoint unreachable and shall stop transmitting any more data to consider the peer endpoint unreachable and shall stop transmitting any
it. In addition, the data sender shall report the failure to the upper more data to it. In addition, the data sender shall report the failure
layer, and optionally report back all outstanding datagrams remaining to the upper layer, and optionally report back all outstanding
in its outbound queue. datagrams remaining in its outbound queue.
The counter shall be reset each time a datagram is received from the The counter shall be reset each time a datagram sent to that
peer endpoint. destination address is acknowledged by the peer endpoint.
7.2 Path Failure Detection 7.2 Path Failure Detection
When the remote endpoint is multi-homed, the data sender should keep a When the remote endpoint is multi-homed, the data sender should keep a
'retrans.count' counter for each of the destination transport addresses of 'retrans.count' counter for each of the destination transport
the remote endpoint. addresses of the remote endpoint.
This count should be incremented each time the data sender retransmits
an outstanding datagram which was originally sent to the destination
transport address.
When the value in 'retrans.count' exceeds half of the value of the Each time the data sender retransmits an outstanding datagram, the
protocol parameter 'Max.Retransmits', the data sender should mark the 'retrans.count' counter of the destination address, to which the
corresponding destination transport address as inactive, and a notification datagram was previously sent, will be incremented. When the value in
may optionally be sent to the upper layer. 'retrans.count' exceeds the protocol parameter 'Path.Max.Retrans' of
that destination address, the data sender should mark the destination
transport address as inactive, and a notification SHOULD be
sent to the upper layer.
When an outstanding datagram is acknowledged, the data sender should When an outstanding datagram is acknowledged, the data sender shall
clear the 'retrans.count' counter of the destination transport address to clear the 'retrans.count' counter of the destination transport address
which the datagram was sent. In the case of a retransmitted datagram to which the datagram was last sent.
(due to time-out or SACK) the destination transport address last
sent to should be used to determine which 'retrans.count' to clear.
7.3 Path Heartbeat 7.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending idle destination transport address(es) of its peer by sending
HEARTBEAT messages periodically to the destination transport HEARTBEAT messages periodically to the destination transport
address(es). address(es).
A destination transport address should be considered idle if no A destination transport address is considered "idle" if no user data
datagram has been sent to it for a certain period of time, no matter and no heartbeat has been sent to it within the current heartbeat
if it is marked active and inactive. period of that address. This applies to both active and inactive
destination addresses.
IMPLEMENTATION NOTE: When multiple idle destination transport
addresses exist, it is recommended that the endpoint sends heartbeat
messages on a Round-Robin basis, with priority given to active idle
destination transport addresses.
The upper layer can optionally initiate the following functions: The upper layer can optionally initiate the following functions:
A) disable heartbeat on a given association, A) disable heart beat on a specific destination transport address of a
B) re-enable heart beat on a given association, and, given association,
C) request an on-demand heartbeat on a given association. B) re-enable heart beat on a specific destination transport address of
a given association, and,
C) request an on-demand heartbeat on a specific destination transport
address of a given association.
The endpoint should keep a 'heartbeat.sent.count' counter for each The endpoint should keep a 'heartbeat.sent.count' counter for each
destination transport address to record the number of HEARTBEAT destination transport address to record the number of HEARTBEAT
messages sent to that destination transport address yet not messages sent to that destination transport address yet not
acknowledged upon. acknowledged upon.
When the value of this counter reaches the protocol parameter When the value of this counter reaches the protocol parameter
'Max.HeartBeat.Misses', the endpoint should also mark that destination 'Path.Max.Retrans', the endpoint should mark the corresponding
address as inactive if it is not so marked. The endpoint may also destination address as inactive if it is not so marked, and may also
optionally report to the upper layer the un-reachablility of the optionally report to the upper layer the change of reachability of
transport address. this destination address.
The sender of the HEARTBEAT message should include in the message the The sender of the HEARTBEAT message should include in the Heartbeat
current time when the message is sent out. Information field of the message the current time when the message is
sent out and the information on the destination address to which the
message is sent.
The receiver of the HEARTBEAT should immediately respond with a The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the time value copied out from the HEARTBEAT ACK that contains the Heartbeat Information field copied out
received HEARTBEAT message. from the received HEARTBEAT message.
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
should clear the 'heartbeat.sent.count' of the destination transport should clear the 'heartbeat.sent.count' of the destination transport
address to which the HEARTBEAT was sent, and mark the destination address to which the HEARTBEAT was sent, and mark the destination
transport address as active if it is not so marked. The endpoint may transport address as active if it is not so marked. The endpoint may
also optionally report to the upper layer the reachablility of the optionally report to the upper layer when an inactive destination
transport address. It also should perform an RTT measurement for that address is marked as active due to the reception of the latest
destination transport address using the time value carried in the HEARTBEAT ACK.
HEARTBEAT ACK message.
The suggested interval for heart beat interval is 4000 ms, and may be The receiver of the HEARTBEAT ACK should also perform an RTT
dynamically adjusted by adding the current RTT measurement if it is measurement for that destination transport address using the time
available. value carried in the HEARTBEAT ACK message.
On an idle destination address that is allowed to heartbeat, HEARTBEAT
messages is RECOMMENDED to be sent once per RTO of that destination
address, with jittering of +/- 50%, and exponential back-off if the
previous HEARTBEAT is unanswered.
A primitive should been provided for the SCTP user to change the heart
beat interval and turn on or off the heart beat on a given destination
address. Note, the heartbeat interval set by the SCTP user on any of
the idle destination addresses SHOULD be no smaller than the RTO of
that distination address. Separate timers may be used to control the
heartbeat transmission for different idle destination addresses.
7.4 Verification Tag 7.4 Verification Tag
Except for INIT, the sender of any SCTP datagram MUST include the Except for INIT, the sender of any SCTP datagram MUST include the
destination endpoint's Tag in the Verification Tag field of the destination endpoint's Tag in the Verification Tag field of the
message. In the case of INIT, the sender should set the Verification message. In the case of INIT, the sender should set the Verification
Tag to 0. Tag to 0.
When sending a SHUTDOWN ACK message, the sender is allowed to either When sending a SHUTDOWN ACK message, the sender is allowed to either
to use the destination endpoint's Tag or fill the Verification Tag to use the destination endpoint's Tag or fill the Verification Tag
field with 0. field with 0.
When receiving an SCTP datagram (except for INIT and SHUTDOWN ACK), When receiving an SCTP datagram (except for INIT and SHUTDOWN ACK),
the receiver MUST ensure that the value in the Verification Tag field the receiver MUST ensure that the value in the Verification Tag field
of the received message matches its own Tag. If the values do not of the received message matches its own Tag. If the values do not
match, the receiver shall silently discard the datagram and shall NOT match, the receiver shall silently discard the datagram and shall NOT
skipping to change at line 3144 skipping to change at page 68, line 45
report the termination to its upper layer. report the termination to its upper layer.
8.2 Shutdown of an Association 8.2 Shutdown of an Association
An endpoint in an association may decide to gracefully shutdown the An endpoint in an association may decide to gracefully shutdown the
association. This will guarantee that all outstanding datagrams from association. This will guarantee that all outstanding datagrams from
the peer of the shutdown initiator be delivered before the association the peer of the shutdown initiator be delivered before the association
terminates. terminates.
The initiator shall send a SHUTDOWN message to the peer of the The initiator shall send a SHUTDOWN message to the peer of the
association, and shall include the last highest consecutive TSN it has association, and shall include the last cumulative TSN it has
received from the peer in the 'Highest Consecutive TSN ACK' field. It received from the peer in the 'Cumulative TSN ACK' field. It
shall then start the T2-shutdown timer and enter the Shutdown-SENT shall then start the T2-shutdown timer and enter the Shutdown-SENT
state. If the timer expires, the initiator must re-send the SHUTDOWN state. If the timer expires, the initiator must re-send the SHUTDOWN
with the updated last TSN received from its peer. When retransmitting with the updated last TSN received from its peer. When retransmitting
the SHUTDOWN, the rules in 5.3 SHALL be followed to determine the the SHUTDOWN, the rules in 5.3 SHALL be followed to determine the
proper timer value. The sender of the SHUTDOWN message may also proper timer value. The sender of the SHUTDOWN message may also
optionally include a SACK to indicate any gaps by bundling both the optionally include a SACK to indicate any gaps by bundling both the
SACK and SHUTDOWN message together. SACK and SHUTDOWN message together.
Note the sender of a shutdown should limit the number of Note the sender of a shutdown should limit the number of
retransmissions of the shutdown message to the protocol parameter retransmissions of the shutdown message to the protocol parameter
'Max.Retransmits'. If Max.Retransmits is exceeded the endpoint should 'Association.Max.Retrans'. If this threshold is exceeded the endpoint
destroy the TCB and may report the endpoint has unreachable to the should destroy the TCB and may report the endpoint unreachable to the
upper layer. upper layer.
Upon the reception of the SHUTDOWN, the peer shall enter the Upon the reception of the SHUTDOWN, the peer shall enter the
Shutdown-received state, and shall verify, by checking the TSN ACK Shutdown-received state, and shall verify, by checking the TSN ACK
field of the message, that all its outstanding datagrams have been field of the message, that all its outstanding datagrams have been
received by the initiator. received by the initiator.
If there are still outstanding datagrams left, the peer shall mark If there are still outstanding datagrams left, the peer shall mark
them for retransmission and start the retransmit procedure as defined them for retransmission and start the retransmit procedure as defined
in Section 5.3. in Section 5.3.
skipping to change at line 3210 skipping to change at page 70, line 14
The primitives and notifications described in this section should be The primitives and notifications described in this section should be
used as a guideline for implementing SCTP. The following functional used as a guideline for implementing SCTP. The following functional
description of ULP interface primitives is, at best, fictional. We description of ULP interface primitives is, at best, fictional. We
must warn readers that different SCTP implementations may have must warn readers that different SCTP implementations may have
different ULP interfaces. However, all SCTPs must provide a certain different ULP interfaces. However, all SCTPs must provide a certain
minimum set of services to guarantee that all SCTP implementations can minimum set of services to guarantee that all SCTP implementations can
support the same protocol hierarchy. This section specifies the support the same protocol hierarchy. This section specifies the
functional interfaces required of all SCTP implementations. functional interfaces required of all SCTP implementations.
Sections 9.1 and 9.2 model interface between SCTP and the Upper Layer
Protocols. Section 9.3 models interfaces to a Layer Management entity.
The Layer Management functions could be implemented as part of the
upper layer itself or as a separate entity.
9.1 ULP-to-SCTP 9.1 ULP-to-SCTP
The following sections functionally characterize a ULP/SCTP interface. The following sections functionally characterize a ULP/SCTP interface.
The notation used is similar to most procedure or function calls in The notation used is similar to most procedure or function calls in
high level languages. high level languages.
The ULP primitives described below specify the basic functions the The ULP primitives described below specify the basic functions the
SCTP must perform to support inter-process communication. Individual SCTP must perform to support inter-process communication. Individual
implementations must define their own exact format, and may provide implementations must define their own exact format, and may provide
combinations or subsets of the basic functions in single calls. combinations or subsets of the basic functions in single calls.
A) Initialize A) Initialize
Format: INITIALIZE ([local port], [local eligible transport Format: INITIALIZE ([local port], [local eligible address list])
address list])
-> local SCTP instance name -> local SCTP instance name
This primitive allows SCTP to initialize its internal data structures This primitive allows SCTP to initialize its internal data structures
and allocate necessary resources for setting up its operation and allocate necessary resources for setting up its operation
environment. Note that once SCTP is initialized, ULP can communicate environment. Note that once SCTP is initialized, ULP can communicate
directly with other endpoints without re-invoking this primitive. directly with other endpoints without re-invoking this primitive.
A local SCTP instance name will be returned to the ULP by the SCTP. A local SCTP instance name will be returned to the ULP by the SCTP.
Mandatory attributes: Mandatory attributes:
None. None.
Optional attributes: Optional attributes:
The following types of attributes may be passed along with The following types of attributes may be passed along with the
the primitive: primitive:
o local port - UDP port number, if ULP wants it to be specified; o local port - UDP port number, if ULP wants it to be specified;
o local eliglible transport address list - A list of eliglible o local eliglible address list - A list of eliglible IP addresses
transport addresses that the local SCTP endpoint should bind. By that the local SCTP endpoint should bind. By default all transport
default all transport interface cards should be used by the local interface cards should be used by the local endpoint if no list is
host if no list is given. given.
IMPLEMENTAION 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 datagrams
sent out by this endpoint MUST contain one of the IP addresses
indicated on the local eligible address list. This enforcement may
be difficult on ceitein operating systems.
B) Associate B) Associate
Format: ASSOCIATE(local SCTP instance name, destination addr info, Format: ASSOCIATE(local SCTP instance name, destination transport
stream count [,eligible transport address list] [,timer info]) addr, outbound stream count [,destination eligible transport addr
-> association id [,destination net list] [,outbound stream count] list])
-> association id [,destination transport addr list] [,outbound stream
count]
This primitive allows the upper layer to initiate an association to a This primitive allows the upper layer to initiate an association to a
specific peer endpoint. The peer endpoint shall be specified by one of specific peer endpoint.
the transport addresses which define the endpoint (see section 1.1).
If the local SCTP instance has not been initialized, the ASSOCIATE is The peer endpoint shall be specified by one of the transport addresses
considered an error. The set of transport addresses specified in the which defines the endpoint (see section 1.1). If the local SCTP
"eligible transport address list" shall be used has valid destinations instance has not been initialized, the ASSOCIATE is considered an
when sending to the peer endpoint. If this parameter is not specified, error.
the associate command will consider all of the transport addresses
returned by the INIT ACK message has valid. The set of transport addresses specified in the "destination eligible
transport addr list" shall be used as valid destinations by the
initiating endpoint when sending to the peer endpoint. If this
parameter is not specified, the initiating endpoint will consider ALL
of the transport addresses returned by the INIT ACK message from the
peer endpoint as valid ones. Note, when specified, the "destination
eligible transport addr list" MUST be the same as, or a sub-set of,
the transport addresses returned in the INIT ACK message from the peer
endpoint. Otherwise, it shall be considered as a configuration error.
An association id, which is a local handle to the SCTP association, An association id, which is a local handle to the SCTP association,
will be returned on successful establishment of the association. If will be returned on successful establishment of the association. If
SCTP is not able to open an SCTP association with the peer endpoint, SCTP is not able to open an SCTP association with the peer endpoint,
an error is returned. an error is returned.
Implementor's Note: If ASSOCIATE primitive is implemented as a Other association parameters may be returned, including the complete
blocking function call, the ASSOCIATE primitive can return association destination transport addresses of the peer as well as the outbound
parameters in addition to the association id upon successful stream count of the local endpoint. One of the transport address from
establishment. If ASSOCIATE primitive is implemented as a non-blocking the returned destination addresses (or the "destination eligible
call, only the association id shall be returned and association transport addr list" if provided) will be selected by the local
parameters shall be passed using the COMMUNICATION UP notification. endpoint as default primary destination address for sending SCTP
datagrams to this peer. The returned "destination transport addr
list" can be used by the ULP to change the default primary destination
address or to force sending a datagram to a specific transport address.
The association parameters shall include the destination addresses of IMPLEMENTION NOTE: If ASSOCIATE primitive is implemented as a
the peer as well as the outbound stream count. One of the transport blocking function call, the ASSOCIATE primitive can return
address from the set of destination addresses will be used as default association parameters in addition to the association id upon
primary destination address for sending datagrams to this peer. The successful establishment. If ASSOCIATE primitive is implemented as a
returned "destination net list" can be used by the ULP to override the non-blocking call, only the association id shall be returned and
default primary destination transport address or to force sending a association parameters shall be passed using the COMMUNICATION UP
datagram on a specific network. notification.
Mandatory attributes: Mandatory attributes:
o local SCTP instance name - obtained from the initialize operation. o local SCTP instance name - obtained from the INITIALIZE operation.
o destination addr info - specified as one of the transport addresses o destination transport addr - specified as one of the transport
of the peer endpoint with which the association is to be established. addresses of the peer endpoint with which the association is to be
established.
o stream count - the number of streams the ULP would like to open at the o outbound stream count - the number of outbound streams the ULP
beginning of the association. would like to open towards this peer endpoint.
Optional attributes: Optional attributes:
o eligible transport address list - a list of transport addresses o destination eligible transport addr list - a list of transport
that the endpoint is allowed to use for sending datagrams to the addresses that the local endpoint is allowed to use for sending
peer. By default, all transport addresses of the peer are datagrams to this peer. By default, all transport addresses
available. indicated by the peer in its INIT ACK message can be used.
o timer info - Timer selection and its operation syntax -- to indicate
to SCTP an alternative timer the SCTP should use for its operation.
C) Terminate C) Terminate
Format: TERMINATE(association id) Format: TERMINATE(association id)
-> result -> result
Gracefully terminates an association. Any locally queued datagrams Gracefully terminates an association. Any locally queued datagrams
will be delivered to the peer. The association will be terminated only will be delivered to the peer. The association will be terminated only
after the peer acknowledges all the messages sent. A success code after the peer acknowledges all the messages sent. A success code
will be returned on successful termination of the association. If will be returned on successful termination of the association. If
skipping to change at line 3352 skipping to change at page 73, line 19
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
None. None.
E) Send E) Send
Format: SEND(association id, buffer address, byte count Format: SEND(association id, buffer address, byte count [,context]
[,context] [,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address] [,un-order
[,un-order flag] [,no-bundle flag] ) flag] [,no-bundle flag])
-> result
This is the main method to send datagrams via SCTP. This is the main method to send user data via SCTP.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o buffer address - the location where the payload to be transmitted is o buffer address - the location where the user data to be transmitted
stored; is stored;
o byte count - The size of the payload in number of octets; o byte count - The size of the user data in number of octets;
Optional attributes: Optional attributes:
o context - optional information that will be carried in the o context - optional information that will be carried in the
sending failure notification to the ULP if the transportation of sending failure notification to the ULP if the transportation of
this datagram fails. this datagram fails.
o stream id - to indicate which stream to send the data on. If not o stream id - to indicate which stream to send the data on. If not
specified, stream 0 will be used. specified, stream 0 will be used.
o life time - specifies the life time of the message. The message o life time - specifies the life time of the user date. The user data
will not be sent by SCTP after the life time expires. This will not be sent by SCTP after the life time expires. This
parameter can be used to avoid efforts to transmit stale parameter can be used to avoid efforts to transmit stale
datagrams. SCTP notifies the ULP, if the datagram cannot be datagrams. SCTP notifies the ULP, if the data cannot be
initiated to transport (i.e. sent to the destination via SCTP's initiated to transport (i.e. sent to the destination via SCTP's
send primitive) within the life time variable. How ever, the send primitive) within the life time variable. How ever, the
message will be transmitted if a TSN has been assigned to the user data will be transmitted if a TSN has been assigned to the
message before the life time expired. user data before the life time expired.
o destination transport address - specified as one of the destination o destination transport address - specified as one of the destination
transport addresses of the peer endpoint to which this message transport addresses of the peer endpoint to which this message
should be sent. Whenever possible, SCTP should use this destination should be sent. Whenever possible, SCTP should use this destination
transport address for sending the datagram, instead of the current transport address for sending the datagram, instead of the current
primary destination transport address. primary destination transport address.
o un-order flag - this flag, if present, indicates that the user o un-order flag - this flag, if present, indicates that the user
would like the data delivered in an un-ordered fashion to the would like the data delivered in an un-ordered fashion to the peer.
remote peer.
o no-bundle flag - Instructs SCTP not to bundle the user data with o no-bundle flag - instructs SCTP not to bundle the user data with
other outbound DATA chunks. Note: SCTP may still bundle even when other outbound DATA chunks. Note: SCTP may still bundle even when
this flag is present, when faced with network congestion. this flag is present, when faced with network congestion.
F) Set Primary F) Set Primary
Format: SETPRIMARY(association id, destination transport address) Format: SETPRIMARY(association id, destination transport address)
-> result -> result
Instructs the local SCTP to use the specified destination transport Instructs the local SCTP to use the specified destination transport
address as primary destination address for sending datagrams. address as primary destination address for sending datagrams.
skipping to change at line 3454 skipping to change at page 75, line 20
the received datagram. the received datagram.
o buffer size - the maximum size of data to be received, in octets. o buffer size - the maximum size of data to be received, in octets.
Optional attributes: Optional attributes:
o stream id - to indicate which stream to receive the data on. o stream id - to indicate which stream to receive the data on.
H) Status H) Status
Format: STATUS(association id) -> status data Format: STATUS(association id)
-> status data
&gt; status data This primitive should return a data block containing the following
This primitive shall return a data block containing the following
information: information:
receive window size, association connection state,
send window size, destination transport address list,
connection state, destination transport address reachability state,
number of buffers awaiting acknowledgement, current receiver window size,
number of buffers pending receipt, current congestion window sizes,
primary destination address, number of DATA chunks awaiting acknowledgement,
round trip time on primary destination address, number of DATA chunks pending receipt,
retransmission time out value on primary destination address, primary destination transport address,
other destination addresses, SRTT on primary destination address,
round trip times on other destination addresses. RTO on primary destination address,
SRTT and RTO on other destination addresses, etc.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
None. None.
I) Change Heartbeat I) Change Heartbeat
Format: CHANGEHEARTBEAT(association id, new state) Format: CHANGEHEARTBEAT(association id, destination transport address,
new state [,interval])
-> result -> result
Instructs the local SCTP to enable or disable heart beat on the Instructs the local endpoint to enable or disable heart beat on the
specified association. specified destination transport address.
The result of attempting this operation shall be returned. The result of attempting this operation shall be returned.
Note, even when enabled, heart beat will not take place if the
destination transport address is not idle.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o new state - the new state of heart beat for this association (either o destination transport address - specified as one of the transport
enabled or disabled). addresses of the peer endpoint.
o new state - the new state of heart beat for this destination
transport address (either enabled or disabled).
Optional attributes:
o interval - if present, indicates the frequence of the heart beat if
this is to enable heart beat on a destination transport
address. Default interval is the RTO of the destination address.
J) Request HeartBeat J) Request HeartBeat
Format: REQUESTHEARTBEAT(association id, transport address) Format: REQUESTHEARTBEAT(association id, destination transport address)
-> result
Instructs the local SCTP to perform a HeartBeat on the specified Instructs the local endpoint to perform a HeartBeat on the specified
transport address of the given association. The results of the destination transport address of the given association. The returned
HeartBeat should update the RTT information. result should indicate whether the transmission of the HEARTBEAT
message to the destination address is successful.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o transport address - the transport address of the association o destination transport address - the transport address of the
on which a heartbeat should be issued. association on which a heartbeat should be issued.
K) Get RTT Report K) Get SRTT Report
Format: GETRTTREPORT(association id, transport address) Format: GETSRTTREPORT(association id, destination transport address)
-> rtt result -> srtt result
&gt; <span class="insert">srtt</span> result Instructs the local SCTP to report the current SRTT measurement on the
Instructs the local SCTP to report the current RTT measurement on the specified destination transport address of the given association. The
specified transport address of the given association. The returned returned result can be an intager containing the most recent SRTT in
result can be an intager containing the most recent RTT in
milliseconds. milliseconds.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o destinatoin transport address - the transport address of the
association on which the SRTT measurement is to be reported.
o transport address - the transport address of the association L) Set Failure Threshould
on which the RTT measurement is to be reported.
L) Set Protocol Parameters Format: SETFAILURETHRESHOLD(association id, destination transport
address, failure threshold)
-> result
Format: SETPROTOCOLPARAMETERS(association id, protocol parameter list) 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 -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o protocol parameter list - The specific values of the protocol o protocol parameter list - The specific names and values of the
parameters (e.g., RTO.Initial, Max.Retransmits, [see Section 12]) protocol parameters (e.g., RTO.Initial, Association.Max.Retrans
that the SCTP user wishes to customized. [see Section 12]) that the SCTP user wishes to customized.
Optional attributes:
o destination transport address - some of the protocol parameters may
be set on a per destination transport address basis.
9.2 SCTP-to-ULP 9.2 SCTP-to-ULP
It is assumed that the operating system or application environment It is assumed that the operating system or application environment
provides a means for the SCTP to asynchronously signal the ULP provides a means for the SCTP to asynchronously signal the ULP
process. When SCTP does signal an ULP process, certain information is process. When SCTP does signal an ULP process, certain information is
passed to the ULP. passed to the ULP.
A) DATA ARRIVE notification A) DATA ARRIVE notification
SCTP shall invoke this notification on the ULP when a datagram is SCTP shall invoke this notification on the ULP when a datagram is
successfully received and ready for retrieval. successfully received and ready for retrieval.
The following may be optionally be passed with the notification: The following may be optionally be passed with the notification:
skipping to change at line 3567 skipping to change at page 78, line 26
o stream id - to indicate which stream the data is received on. o stream id - to indicate which stream the data is received on.
B) SEND FAILURE notification B) SEND FAILURE notification
If a datagram can not be delivered SCTP shall invoke this notification If a datagram can not be delivered SCTP shall invoke this notification
on the ULP. on the ULP.
The following may be optionally be passed with the notification: The following may be optionally be passed with the notification:
o association id - local handle to the SCTP association
o data - the location ULP can find the un-delivered datagram. o data - the location ULP can find the un-delivered datagram.
o context - optional information associated with this datagram (see o context - optional information associated with this datagram (see
D in section 9.1). D in section 9.1).
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
C) NETWORK STATUS CHANGE notification C) NETWORK STATUS CHANGE notification
When a destination transport address is marked down (e.g., when SCTP When a destination transport address is marked down (e.g., when SCTP
detects a failure), or marked up (e.g., when SCTP detects a recovery), detects a failure), or marked up (e.g., when SCTP detects a recovery),
SCTP shall invoke this notification on the ULP. SCTP shall invoke this notification on the ULP.
The following shall be passed with the notification: 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 o destination transport address - This indicates the destination
transport address of the peer endpoint affected by the change; transport address of the peer endpoint affected by the change;
o new-status - This indicates the new status. o new-status - This indicates the new status.
D) COMMUNICATION UP notification D) COMMUNICATION UP notification
This notification is used when SCTP becomes ready to send or receive This notification is used when SCTP becomes ready to send or receive
datagrams, or when a lost communication to an endpoint is restored. datagrams, or when a lost communication to an endpoint is restored.
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
blocking function call, the association parameters are returned as a blocking function call, the association parameters are returned as a
result of the ASSOCIATE primitive itself. In that case, result of the ASSOCIATE primitive itself. In that case,
COMMUNICATION UP notification is optional at the association COMMUNICATION UP notification is optional at the association
initiator's side. initiator's side.
The following shall be passed with the notification: The following shall be passed with the notification:
o status - This indicates what type of event that has occurred;
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o destination transport address list - the set of transport addresses o status - This indicates what type of event that has occurred
of the peer
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 o outbound stream count - the maximum number of streams allowed to be
used in this association by the ULP used in this association by the ULP
E) COMMUNICATION LOST notification E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely or detects When SCTP loses communication to an endpoint completely or detects
that the endpoint has performed an abort or graceful shutdown that the endpoint has performed an abort or graceful shutdown
operation, it shall invoke this notification on the ULP. operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification: The following shall be passed with the notification:
o status - This indicates what type of event that has occurred;
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o status - This indicates what type of event that has occurred;
The following may be optionally passed with the notification: The following may be optionally passed with the notification:
o unsent-datagrams - The number and location of un-sent datagrams o unsent-datagrams - The number and location of un-sent datagrams
still in hold by SCTP; still in hold by SCTP;
o unacknowledged-datagrams - The number and location of datagrams o unacknowledged-datagrams - The number and location of datagrams
that were attempted to be transported to the destination, but were that were attempted to be transported to the destination, but were
not acknowledged when the loss of communication was detected. not acknowledged when the loss of communication was detected.
o last-acked - the sequence number last acked by that peer endpoint; o last-acked - the sequence number last acked by that peer endpoint;
o last-sent - the sequence number last sent to that peer endpoint; o last-sent - the sequence number last sent to that peer endpoint;
o received-but-not-delivered - datagrams that were received by SCTP o received-but-not-delivered - datagrams that were received by SCTP
but not yet delivered to the ULP. but not yet delivered to the ULP.
Note: the un-send data report may not be accurate for those user Note: the un-send data report may not be accurate for those user
messages which are segmented by SCTP during transmission. messages which are segmented by SCTP during transmission.
9.3 Interfaces to Layer Management
This section models interfaces to a Layer Management (LM) entity,
which manages resources that have transport layer-wide impact. Layer
Management consists of primitives related to the management of SCTP
performed as a subset of systems management.
9.3.1 LM-to-SCTP
The following ULP-to-SCTP primitives from section 9.1 could be
implemented as part of the LM entity.
INITIALIZE
SETPRIMARY
ABORT
STATUS
9.3.2 SCTP-to-LM
The following SCTP-to-ULP primitives from section 9.2 could be implemented
as part of the LM entity.
SEND FAILURE notification
NETWORK STATUS CHANGE notification
COMMUNICATION UP notification
COMMUNICATION LOST notification
10. Security Considerations 10. Security Considerations
10.1 Security Objectives 10.1 Security Objectives
As a common transport protocol designed to reliably carry time- As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signalling messages for sensitive user messages, such as billing or signalling messages for
telephony services, between two networked endpoints, SCTP has the telephony services, between two networked endpoints, SCTP has the
following security objectives. following security objectives.
- availability of reliable and timely data transport services - availability of reliable and timely data transport services
- integrity of the user-to-user information carried by SCTP - integrity of the user-to-user information carried by SCTP
skipping to change at line 3701 skipping to change at page 80, line 38
consulted for guidance. consulted for guidance.
The case is more difficult where the SCTP system is operated by a The case is more difficult where the SCTP system is operated by a
private user. The service provider with whom that user has a private user. The service provider with whom that user has a
contractual arrangement SHOULD provide help to ensure that the contractual arrangement SHOULD provide help to ensure that the
user's site is secure, ranging from advice on configuration through user's site is secure, ranging from advice on configuration through
downloaded scripts and security software. downloaded scripts and security software.
10.2.1 Countering Insider Attacks 10.2.1 Countering Insider Attacks
The principles of the Site Security Handbook [ ] should be applied The principles of the Site Security Handbook [13] should be applied
to minimize the risk of theft of information or sabotage by to minimize the risk of theft of information or sabotage by
insiders. These include publication of security policies, control insiders. These include publication of security policies, control
of access at the physical, software, and network levels, and of access at the physical, software, and network levels, and
separation of services. separation of services.
10.2.2 Protecting against Data Corruption in the Network 10.2.2 Protecting against Data Corruption in the Network
Where the risk of undetected errors in datagrams delivered by the Where the risk of undetected errors in datagrams delivered by the
lower layer transport services is considered to be too great, lower layer transport services is considered to be too great,
additional checksum protection may be required. The question is additional checksum protection may be required. The question is
skipping to change at line 3884 skipping to change at page 84, line 30
section 10.2.1. section 10.2.1.
11. IANA Consideration 11. IANA Consideration
This protocol may be extended through IANA in three ways: This protocol may be extended through IANA in three ways:
-- through definition of additional chunk types, -- through definition of additional chunk types,
-- through definition of additional parameter types, or -- through definition of additional parameter types, or
-- through definition of additional cause codes within Operation -- through definition of additional cause codes within Operation
Error chunks 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.
11.1 IETF-defined Chunk Extension 11.1 IETF-defined Chunk Extension
The appropriate use of specific chunk types is an integral part of the The appropriate use of specific chunk types is an integral part of the
SCTP protocol. In consequence, the intention is that new IETF-defined SCTP protocol. In consequence, the intention is that new IETF-defined
chunk types MUST be supported by standards-track RFC documentation. chunk types MUST be supported by standards-track RFC documentation.
As a transitional step, a new chunk type MAY be introduced in an As a transitional step, a new chunk type MAY be introduced in an
Experimental RFC. Chunk type codes MUST remain permanently associated Experimental RFC. Chunk type codes MUST remain permanently associated
with the original documentation on the basis of which they were with the original documentation on the basis of which they were
allocated. Thus if the RFC supporting a given chunk type is allocated. Thus if the RFC supporting a given chunk type is
deprecated in favour of a new document, the corresponding chunk type deprecated in favour of a new document, the corresponding chunk type
skipping to change at line 4003 skipping to change at page 87, line 7
the format shown in section 2.3.9, i.e.: the format shown in section 2.3.9, i.e.:
-- first two octets contain the cause code value -- first two octets contain the cause code value
-- last two octets contain length of the cause parameter. -- last two octets contain length of the cause parameter.
12. Suggested SCTP Protocol Parameter Values 12. Suggested SCTP Protocol Parameter Values
The following protocol parameters are recommended: The following protocol parameters are recommended:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
Valid.Cookie.Life - 5 seconds Valid.Cookie.Life - 5 seconds
Max.Retransmits - 10 attempts Association.Max.Retrans - 10 attempts
Max.Init.Retransmit - 8 attempts Path.Max.Retrans - 5 attempts (per destination address)
Max.HeartBeat.Misses - 3 attempts Max.Init.Retransmits - 8 attempts
IMPLEMENTATION NOTE: The SCTP implementation SHOULD allow ULP to IMPLEMENTATION NOTE: The SCTP implementation SHOULD allow ULP to
customize these protocol parameters. customize these protocol parameters.
Miscellaneous protocol variables/counters: Miscellaneous protocol variables/counters:
'retrans.count' - per association counter 'retrans.count' - per destination transport address counter
'heartbeat.sent.count' - per destination transport address counter 'heartbeat.sent.count' - per destination transport address counter
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Mark Allman, Richard Band, Scott Bradner, The authors wish to thank Mark Allman, Richard Band, Scott Bradner,
Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege, Henry Houh, Gary Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege, Henry Houh,
Lehecka, Lyndon Ong, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Christian Huetima, Gary Lehecka, Lyndon Ong, Kelvin Porter, Heinz
A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their Prantner, Jarno Rajahalme, A. Sankar, Greg Sidebottom, Brian Wyld, and
invaluable comments. many others for their invaluable comments.
14. Authors' Addresses 14. Authors' Addresses
Randall R. Stewart Tel: +1-847-632-7438 Randall R. Stewart Tel: +1-847-632-7438
Motorola, Inc. EMail: rstewar1@email.mot.com Motorola, Inc. EMail: rstewar1@email.mot.com
1501 W. Shure Drive, #2315 1501 W. Shure Drive, #2315
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Qiaobing Xie Tel: +1-847-632-3028 Qiaobing Xie Tel: +1-847-632-3028
skipping to change at line 4102 skipping to change at page 89, line 8
RFC 1750, December 1994. RFC 1750, December 1994.
[2] ITU-T Recommendation Q.703 "Q.703 - Signaling link", July 1996. [2] ITU-T Recommendation Q.703 "Q.703 - Signaling link", July 1996.
[3] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion [3] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
August 1999. August 1999.
[5] M. Allman and V. Paxson, "On Estimating End-to-End Network Path [5] Allman, M., and Paxson, V., "On Estimating End-to-End Network Path
Properties", Proc. SIGCOMM '99, 1999. Properties", Proc. SIGCOMM '99, 1999.
This Internet Draft expires in 6 months from October 1999. [6] Karn, P., and Simpson, W., "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[7] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[8] Postel, J. (ed.), "Transmission Control Protocol", RFC 793,
September 1981.
[9] Postel, J. (ed.), "User Datagram Protocol", RFC 768, August 1980.
[10] Reynolds, J., and Postel, J. (ed.), "Assigned Numbers", RFC 1700,
October 1994.
[11] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191,
November 1990.
[12] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[13] Fraser, B. (ed.), "Site Security Handbook", RFC 2196, September
1997.
[14] Kent, S., and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
This Internet Draft expires in 6 months from November 1999.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/