draft-ietf-sigtran-sctp-07.txt   draft-ietf-sigtran-sctp-08.txt 
skipping to change at line 20 skipping to change at line 20
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 March 2,2000 expires in six months April 7,2000
Simple Control Transmission Protocol Stream Control Transmission Protocol
<draft-ietf-sigtran-sctp-07.txt> <draft-ietf-sigtran-sctp-08.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 RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. 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.
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] Stewart, et al [Page 1]
Abstract Abstract
This document describes the Simple Control Transmission Protocol This document describes the Stream Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signaling messages over (SCTP). SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications. IP networks, but is capable of broader applications.
SCTP is a reliable datagram transfer protocol operating on top of an SCTP is a reliable datagram transfer protocol operating on top of an
unreliable routed packet network such as IP. It offers the following unreliable routed packet network such as IP. It offers the following
services to its users: services to its users:
-- acknowledged error-free non-duplicated transfer of user data, -- acknowledged error-free non-duplicated transfer of user data,
-- data segmentation to conform to discovered path MTU size, -- data segmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, -- sequenced delivery of user messages within multiple streams,
skipping to change at line 75 skipping to change at line 75
1. Introduction..................................................5 1. Introduction..................................................5
1.1 Motivation..................................................5 1.1 Motivation..................................................5
1.2 Architectural View of SCTP..................................5 1.2 Architectural View of SCTP..................................5
1.3 Functional View of SCTP.....................................6 1.3 Functional View of SCTP.....................................6
1.3.1 Association Startup and Takedown........................7 1.3.1 Association Startup and Takedown........................7
1.3.2 Sequenced Delivery within Streams.......................7 1.3.2 Sequenced Delivery within Streams.......................7
1.3.3 User Data Segmentation..................................8 1.3.3 User Data Segmentation..................................8
1.3.4 Acknowledgment and Congestion Avoidance.................8 1.3.4 Acknowledgment and Congestion Avoidance.................8
1.3.5 Chunk Multiplex.........................................8 1.3.5 Chunk Multiplex.........................................8
1.3.6 Path Management.........................................8 1.3.6 Message Validation......................................8
1.3.7 Message Validation......................................9 1.3.7 Path Management.........................................9
1.4 Recapitulation of Key Terms.................................9 1.4 Recapitulation of Key Terms.................................9
1.5 Abbreviations...............................................11 1.5 Abbreviations...............................................11
2. SCTP Datagram Format..........................................11 2. SCTP Datagram Format..........................................11
2.1 SCTP Common Header Field Descriptions.......................12 2.1 SCTP Common Header Field Descriptions.......................12
2.2 Chunk Field Descriptions....................................13 2.2 Chunk Field Descriptions....................................13
2.2.1 Optional/Variable-length Parameter Format...............14 2.2.1 Optional/Variable-length Parameter Format...............14
2.2.2 Vendor-Specific Extension Parameter Format..............15 2.2.2 Vendor-Specific Extension Parameter Format..............15
2.3 SCTP Chunk Definitions......................................17 2.3 SCTP Chunk Definitions......................................17
2.3.1 Initiation (INIT).......................................17 2.3.1 Initiation (INIT).......................................17
2.3.1.1 Optional or Variable Length Parameters..............19 2.3.1.1 Optional or Variable Length Parameters..............19
skipping to change at line 189 skipping to change at line 189
13. Suggested SCTP Protocol Parameter Values......................92 13. Suggested SCTP Protocol Parameter Values......................92
14. Acknowledgments...............................................92 14. Acknowledgments...............................................92
15. Authors' Addresses............................................93 15. Authors' Addresses............................................93
16. References....................................................94 16. References....................................................94
Appendix A .......................................................95 Appendix A .......................................................95
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, Stream 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
TCP [8] has performed immense service as the primary means of reliable TCP [8] has performed immense service as the primary means of reliable
data transfer in IP networks. However, an increasing number of recent data transfer in IP networks. However, an increasing number of recent
applications have found TCP too limiting, and have incorporated their applications have found TCP too limiting, and have incorporated their
own reliable data transfer protocol on top of UDP [9]. The limitations own reliable data transfer protocol on top of UDP [9]. The limitations
which users have wished to bypass include the following: which users have wished to bypass include the following:
skipping to change at line 297 skipping to change at line 297
| | | Acknowledgment | | | | Acknowledgment |
| | | and | | | | and |
| | | Congestion Avoidance | | | | Congestion Avoidance |
..| | |____________________________| ..| | |____________________________|
| | | |
| | ____________________________ | | ____________________________
| | | Chunk Multiplex | | | | Chunk Multiplex |
| | |____________________________| | | |____________________________|
| | | |
| | ________________________________ | | ________________________________
| | | Message Validataion | | | | Message Validation |
| | |________________________________| | | |________________________________|
| | | |
| | ________________________________ | | ________________________________
| | | Path Management | | | | Path Management |
|______________ |________________________________| |______________ |________________________________|
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
skipping to change at line 382 skipping to change at line 381
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 messages into a single SCTP datagram. The chunk more than one user messages into a single SCTP datagram. The chunk
multiplex function of SCTP is responsible for assembly of the complete multiplex function of SCTP is responsible for assembly of the complete
SCTP datagram and its disassembly at the receiving end. SCTP datagram and its disassembly at the receiving end.
1.3.6 Path Management 1.3.6 Message Validation
A mandatory verification tag and an Adler-32 checksum [2] fields are
included in the SCTP common header. The verification tag value is
chosen by each end of the association during association startup.
Messages received without the verification tag value expected by the
receiver are discarded, as a protection against blind masquerade
attacks and against stale datagrams from a previous association.
Stewart, et al [Page 8]
The Adler-32 checksum should be set by the sender of each SCTP datagram,
to provide additional protection against data corruption in the
network beyond that provided by lower layers (e.g. the IP checksum).
1.3.7 Path Management
The sending SCTP user is able to manipulate the set of transport The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP datagrams, through the addresses used as destinations for SCTP datagrams, through the
primitives described in Chapter 9. The SCTP path management function primitives described in Chapter 9. The SCTP path management function
chooses the destination transport address for each outgoing SCTP chooses the destination transport address for each outgoing SCTP
datagram based on the SCTP user's instructions and the currently datagram based on the SCTP user's instructions and the currently
perceived reachability status of the eligible destination set. perceived reachability status of the eligible destination set.
Stewart, et al [Page 8]
The path management function monitors reachability through heartbeat The path management function monitors reachability through heartbeat
messages when other message traffic is inadequate to provide this messages when other message traffic is inadequate to provide this
information, and advises the SCTP user when reachability of any far- information, and advises the SCTP user when reachability of any far-
end transport address changes. The path management function is also end transport address changes. The path management function is also
responsible for reporting the eligible set of local transport responsible for reporting the eligible set of local transport
addresses to the far end during association startup, and for reporting addresses to the far end during association startup, and for reporting
the transport addresses returned from the far end to the SCTP user. the transport addresses returned from the far end to the SCTP user.
At association start-up, a primary destination transport address is At association start-up, a primary destination transport address is
defined for each SCTP endpoint, and is used for normal sending of SCTP defined for each SCTP endpoint, and is used for normal sending of SCTP
datagrams. datagrams.
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
A mandatory verification tag and an Adler-32 checksum [2] fields are
included in the SCTP common header. The verification tag value is
chosen by each end of the association during association startup.
Messages received without the verification tag value expected by the
receiver are discarded, as a protection against blind masquerade
attacks and against stale datagrams from a previous association.
The Adler-32 checksum should be set by the sender of each SCTP datagram,
to provide additional protection against data corruption in the
network beyond that provided by lower layers (e.g. the IP 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
sections. This section provides a consolidated list of the key terms sections. This section provides a consolidated list of the key terms
and their definitions. and their definitions.
o SCTP user application (SCTP user): The logical higher-layer o SCTP user application (SCTP user): The logical higher-layer
application entity which uses the services of SCTP, also called application entity which uses the services of SCTP, also called
the Upper-layer Protocol (ULP). the Upper-layer Protocol (ULP).
skipping to change at line 539 skipping to change at line 537
1.5. Abbreviations 1.5. Abbreviations
ICV - Integrity Check Value [4] ICV - Integrity Check Value [4]
RTO - Retransmission Time-out RTO - Retransmission Time-out
RTT - Round-trip Time RTT - Round-trip Time
RTTVAR - Round-trip Time Variation RTTVAR - Round-trip Time Variation
SCTP - Simple Control Transmission Protocol SCTP - Stream Control Transmission Protocol
SRTT - Smoothed RTT SRTT - Smoothed RTT
TCB - Transmission Control Block TCB - Transmission Control Block
TLV - Type-Length-Value Coding Format TLV - Type-Length-Value Coding Format
TSN - Transmission Sequence Number TSN - Transmission Sequence Number
ULP - Upper-layer Protocol ULP - Upper-layer Protocol
skipping to change at line 679 skipping to change at line 675
00000010 - Initiation Acknowledgment (INIT ACK) 00000010 - Initiation Acknowledgment (INIT ACK)
00000011 - Selective Acknowledgment (SACK) 00000011 - Selective Acknowledgment (SACK)
00000100 - Heartbeat Request (HEARTBEAT) 00000100 - Heartbeat Request (HEARTBEAT)
00000101 - Heartbeat Acknowledgment (HEARTBEAT ACK) 00000101 - Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110 - Abort (ABORT) 00000110 - Abort (ABORT)
00000111 - Shutdown (SHUTDOWN) 00000111 - Shutdown (SHUTDOWN)
00001000 - Shutdown Acknowledgment (SHUTDOWN ACK) 00001000 - Shutdown Acknowledgment (SHUTDOWN ACK)
00001001 - Operation Error (ERROR) 00001001 - Operation Error (ERROR)
00001010 - State Cookie (COOKIE) 00001010 - State Cookie (COOKIE)
00001011 - Cookie Acknowledgment (COOKIE ACK) 00001011 - Cookie Acknowledgment (COOKIE ACK)
00001100 - Reserved for Explict Congestion Notification Echo (ECNE) 00001100 - Reserved for Explicit Congestion Notification Echo (ECNE)
00001101 - Reserved for Congestion Window Reduced (CWR) 00001101 - Reserved for Congestion Window Reduced (CWR)
00001110 to 11111101 - reserved by IETF 00001110 to 11111101 - reserved by IETF
11111110 - Vendor-specific Chunk Extensions 11111110 - Vendor-specific Chunk Extensions
11111111 - IETF-defined Chunk Extensions 11111111 - IETF-defined Chunk Extensions
Note: The ENCE and CWR chunk types are reserved for future use of Explicit Note: The ECNE and CWR chunk types are reserved for future use of Explicit
Congestion Notification (ECN). Congestion Notification (ECN).
Chunk Flags: 8 bits Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the The usage of these bits depends on the chunk type as given by the
Chunk ID. Unless otherwise specified, they are set to zero on Chunk ID. Unless otherwise specified, they are set to zero on
transmit and are ignored on receipt. transmit and are ignored on receipt.
Chunk Length: 16 bits (u_int) Chunk Length: 16 bits (u_int)
skipping to change at line 892 skipping to change at line 888
Number of Inbound Streams Mandatory Number of Inbound Streams Mandatory
Initial TSN Mandatory Initial TSN Mandatory
Stewart, et al [Page 17] Stewart, et al [Page 17]
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
IPv4 Address (Note 1) Optional 0x0005 IPv4 Address (Note 1) Optional 0x0005
IPv6 Address (Note 1) Optional 0x0006 IPv6 Address (Note 1) Optional 0x0006
Cookie Preservative Optional 0x0009 Cookie Preservative Optional 0x0009
Reserved for ECN Capable Optional 0x000a Reserved for ECN Capable (Note 2) Optional 0x000a
Host Name Address (Note 3) Optional 0x000b
Supported Address Types (Note 4) Optional 0x000c
Note 1: The INIT chunks may contain multiple addresses that may be Note 1: The INIT chunks may contain multiple addresses that may be
IPv4 and/or IPv6 in any combination. IPv4 and/or IPv6 in any combination.
Note 2: The ECN capable field is reserved for future use of Explicit Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification. Congestion Notification.
Note 3: The INIT chunks may contain AT MOST one Host Name address
parameter. Moreover, the sender of the INIT SHALL not combine any other
address types with the Host Name address in the INIT while the receiver
of INIT MUST ignore any other address types if the Host Name address
parameter is present in the received INIT chunk.
Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address types.
Chunk Flags field in INIT is reserved, and all bits in it should be Chunk Flags field in INIT is reserved, and all bits in it should be
set to 0 by the sender and ignored by the receiver. The sequence of set to 0 by the sender and ignored by the receiver. The sequence of
parameters within an INIT may be processed in any order. parameters within an INIT may be processed in any order.
Initiate Tag: 32 bit u_int Initiate Tag: 32 bit u_int
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 Verification Tag field of every SCTP datagram that the responding
end transmits within this association. end transmits within this association.
skipping to change at line 934 skipping to change at line 942
association). association).
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. The valid range is Defines the initial TSN that the sender will use. The valid range is
from 0x0 to 0xffffffff. This field MAY be set to the value of the from 0x0 to 0xffffffff. This field MAY be set to the value of the
Initiate Tag field. Initiate Tag field.
Stewart, et al [Page 18] Stewart, et al [Page 18]
skipping to change at line 975 skipping to change at line 983
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bit IPv4 Address: 32 bit
Contains an IPv4 address of the sending endpoint. It is binary Contains an IPv4 address of the sending endpoint. It is binary
encoded. encoded.
IPv6 Address: IPv6 Address Parameter
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 0 0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
skipping to change at line 1004 skipping to change at line 1012
value passed in an IPv4 or IPv6 Address parameter indicates a value passed in an IPv4 or IPv6 Address parameter indicates a
transport address the sender of the INIT will support for the transport address the sender of the INIT will support for the
association being initiated. That is, during the lifetime of this association being initiated. That is, during the lifetime of this
association, this IP address may appear in the source address field association, this IP address may appear in the source address field
Stewart, et al [Page 19] Stewart, et al [Page 19]
of a datagram sent from the sender of the INIT, and may be used as a of a datagram sent from the sender of the INIT, and may be used as a
destination address of a datagram sent from the receiver of the destination address of a datagram sent from the receiver of the
INIT. INIT.
More than one IP Address parameters can be included in an INIT More than one IP Address parameter can be included in an INIT
chunk when the INIT sender is multi-homed. Moreover, a multi-homed chunk when the INIT sender is multi-homed. Moreover, a multi-homed
endpoint may have access to different types of network, thus more endpoint may have access to different types of network, thus more
than one address type may be present in one INIT chunk, i.e., IPv4 than one address type may be present in one INIT chunk, i.e., IPv4
and IPv6 transport addresses are allowed in the same INIT message. and IPv6 transport addresses are allowed in the same INIT message.
If the INIT contains at least one IP Address parameter, then only the If the INIT contains at least one IP Address parameter, then only the
transport address(es) provided within the INIT may be used as transport address(es) provided within the INIT may be used as
destinations by the responding end. If the INIT does not contain any destinations by the responding end. If the INIT does not contain any
IP Address parameters, the responding end MUST use the source IP Address parameters, the responding end MUST use the source
address associated with the received SCTP datagram as its sole address associated with the received SCTP datagram as its sole
skipping to change at line 1042 skipping to change at line 1050
This parameter indicates to the receiver how much increment the This parameter indicates to the receiver how much increment the
sender wishes the receiver to add to its default cookie life-span. sender wishes the receiver to add to its default cookie life-span.
This optional parameter should be added to the INIT message by the This optional parameter should be added to the INIT message by the
sender when it re-attempts establishing an association with a peer sender when it re-attempts establishing an association with a peer
to which its previous attempt of establishing the association failed to which its previous attempt of establishing the association failed
due to a Stale COOKIE error. Note, the receiver MAY choose to ignore due to a Stale COOKIE error. Note, the receiver MAY choose to ignore
the suggested cookie life-span increase for its own security the suggested cookie life-span increase for its own security
reasons. reasons.
Host Name Address
The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer. The peer is responsible for
resolving the name.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name: variable length
Defined as a zero terminated ASCII string with a variable
length. The syntax of the host name is out of scope of SCTP.
Supported Address Types
The sender of INIT uses this parameter to list all the address types
it can support.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type: 16 bit u_int
This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 0x0005, IPv6 = 0x0006).
2.3.2 Initiation Acknowledgment (INIT ACK) (00000010): 2.3.2 Initiation Acknowledgment (INIT ACK) (00000010):
The INIT ACK chunk is used to acknowledge the initiation of an SCTP The INIT ACK chunk is used to acknowledge the initiation of an SCTP
association. association.
The parameter part of INIT ACK is formatted similarly to the INIT The parameter part of INIT ACK is formatted similarly to the INIT
chunk. It uses two extra variable parameters: The State Cookie chunk. It uses two extra variable parameters: The State Cookie
and the Unrecognized Parameter: and the Unrecognized Parameter:
The format of the INIT ACK message is shown below: The format of the INIT ACK message is shown below:
skipping to change at line 1089 skipping to change at line 1137
Number of Outbound Streams Mandatory Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory Number of Inbound Streams Mandatory
Initial TSN Mandatory Initial TSN Mandatory
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
State Cookie Mandatory 0x0007 State Cookie Mandatory 0x0007
IPv4 Address (Note 1) Optional 0x0005 IPv4 Address (Note 1) Optional 0x0005
IPv6 Address (Note 1) Optional 0x0006 IPv6 Address (Note 1) Optional 0x0006
Unrecognized Parameters Optional 0x0008 Unrecognized Parameters Optional 0x0008
Reserved for ECN Capable Optional 0x000a Reserved for ECN Capable (Note 2) Optional 0x000a
Host Name Address (Note 3) Optional 0x000b
Note 1: The INIT ACK chunks may contain any number of IP address Note 1: The INIT ACK chunks may contain any number of IP address
parameters that may be IPv4 and/or IPv6 in any combination. parameters that may be IPv4 and/or IPv6 in any combination.
Note 2: The ECN capable field is reserved for future use of Explicit Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification. Congestion Notification.
Note 3: The INIT ACK chunks may contain AT MOST one Host Name address
parameter. Moreover, the sender of the INIT ACK SHALL not combine any
other address types with the Host Name address in the INIT ACK while
the receiver of the INIT ACK MUST ignore any other address types if
the Host Name address parameter is present.
Same as with INIT, in combination with the Source Port carried in the Same as with INIT, in combination with the Source Port carried in the
SCTP common header, each IP Address parameter in the INIT ACK indicates SCTP common header, each IP Address parameter in the INIT ACK indicates
to the receiver of the INIT ACK a valid transport address supported by to the receiver of the INIT ACK a valid transport address supported by
the sender of the INIT ACK for the lifetime of the association being the sender of the INIT ACK for the lifetime of the association being
initiated. initiated.
If the INIT ACK contains at least one IP Address parameter, then only If the INIT ACK contains at least one IP Address parameter, then only
the transport address(es) explicitly indicated in the INIT ACK may be the transport address(es) explicitly indicated in the INIT ACK may be
used as the destination(s) by the receiver of the INIT ACK. However, used as the destination(s) by the receiver of the INIT ACK. However,
if the INIT ACK contains no IP Address parameter, the receiver of the if the INIT ACK contains no IP Address parameter, the receiver of the
skipping to change at line 1563 skipping to change at line 1618
Cause of error Cause of error
--------------- ---------------
Out of Resource: indicating that the sender is out of resource. This Out of Resource: indicating that the sender is out of resource. This
is usually sent in combination with or within an ABORT. is usually sent in combination with or within an ABORT.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 | | Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
Unresolvable Address: indicating that the sender is not able to
resolve the specified address parameter (e.g., type of address is
not supported by the sender). This is sent within an ABORT.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ The Unresolvable Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameter field contains the complete TLV of the unresolvable
address.
Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the
originator of the INIT ACK message if the receiver does not
recognize one or more Optional TLV parameters in the INIT ACK chunk.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ The Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The error field will contain the unrecognized parameters copied
from the INIT ACK message complete with TLV. This error is normally
bundled with the Cookie chunk when responding to the INIT ACK, when
the sender of the Cookie wishes to report unrecognized parameters.
Guidelines for IETF-defined Error Cause extensions are discussed in Guidelines for IETF-defined Error Cause extensions are discussed in
Section 12.3 of this document. Section 12.3 of this document.
2.3.10 State Cookie (COOKIE) (00001010): 2.3.10 State Cookie (COOKIE) (00001010):
This chunk is used only during the initialization of an association. This chunk is used only during the initialization of an association.
It is sent by the initiator of an association to its peer to complete It is sent by the initiator of an association to its peer to complete
the initialization process. This chunk MUST precede any chunk the initialization process. This chunk MUST precede any chunk
sent within the association, but MAY be bundled with one or more DATA sent within the association, but MAY be bundled with one or more DATA
chunks in the same datagram. chunks in the same datagram.
skipping to change at line 1889 skipping to change at line 1978
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 back an ERROR chunk. In either 4.1.5), the receiver SHALL send back an ERROR chunk. In either
case, the receiver stays in the CLOSED state. case, the receiver stays 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.Retransmits' 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 T1-cookie timer expires, the endpoint SHALL retransmit
COOKIE and re-start the cookie timer without changing COOKIE and re-start the T1-cookie timer without changing
state. This SHALL be repeated up to 'Max.Init.Retransmits' 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.
skipping to change at line 1948 skipping to change at line 2037
Moreover, "Z" MUST generate and send along with the INIT ACK an Moreover, "Z" MUST generate and send along with the INIT ACK an
State Cookie. See Section 4.1.3 for State Cookie generation. State Cookie. See Section 4.1.3 for State Cookie generation.
Note: after sending out INIT ACK with the cookie, "Z" MUST not Note: after sending out INIT ACK with the cookie, "Z" MUST 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 stop the T1-init C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-init
timer and leave COOKIE-WAIT state. "A" shall then send the cookie timer and leave COOKIE-WAIT state. "A" shall then send the cookie
received in the INIT ACK message in a cookie chunk, restart the received in the INIT ACK message in a cookie chunk, start the
T1-init timer, and enter the COOKIE-SENT state. T1-cookie timer, and enter the COOKIE-SENT state.
Note, the cookie chunk can be bundled with any pending outbound Note, the cookie chunk can be bundled with any pending outbound
DATA chunks, but it MUST be the first chunk in the datagram AND DATA chunks, but it MUST be the first chunk in the datagram AND
until the COOKIE ACK is returned the sender MUST NOT send any until the COOKIE ACK is returned the sender MUST NOT send any
other datagrams to the peer. other datagrams to the peer.
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 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: an implementation may choose to send the IMPLEMENTATION NOTE: an implementation may choose to send the
Communication Up notification to the SCTP user upon reception Communication Up notification to the SCTP user upon reception
of a valid COOKIE. of a valid COOKIE.
Stewart, et al [Page 37] Stewart, et al [Page 37]
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 the T1-init COOKIE-SENT state to the ESTABLISHED state, stopping the T1-cookie
timer, and it may also notify its ULP about the successful timer, and it may also notify its ULP about the successful
establishment of the associate with a Communication Up notification establishment of the associate with a Communication Up notification
(see Section 9). (see Section 9).
Note: A DATA chunk MUST NOT be carried in the INIT or INIT ACK message. Note: A DATA chunk MUST NOT be carried in the INIT or INIT ACK message.
Note: T1-init timer shall follow the same rules given in Section 5.3. Note: T1-init timer and T1-cookie timer shall follow the same rules
given in Section 5.3.
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 missing mandatory decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter values, parameters in the received INIT or INIT ACK, invalid parameter values,
or, lack of local resources, it SHALL respond with an ABORT chunk. It or, lack of local resources, it SHALL respond with an ABORT chunk. It
SHOULD also specify the cause of abort, such as the type of the SHOULD also specify the cause of abort, such as the type of the
missing mandatory parameters, etc., by either including cause missing mandatory parameters, etc., by either including cause
parameters or bundling with the ABORT one or more Operational ERROR parameters or bundling with the ABORT one or more Operational ERROR
chunks. The Verification Tag field in the common header of the chunks. The Verification Tag field in the common header of the
outbound abort datagram MUST be set to equal the Initiate Tag value of outbound abort datagram MUST be set to equal the Initiate Tag value of
skipping to change at line 2036 skipping to change at line 2126
After the association is initialized, the valid outbound stream After the association is initialized, the valid outbound stream
identifier range for either endpoint shall be 0 to identifier range for either endpoint shall be 0 to
min(local OS, remote MIS)-1. min(local OS, remote MIS)-1.
4.1.2 Handle Address Parameters 4.1.2 Handle Address Parameters
During the association initialization, an endpoint shall use the During the association initialization, an endpoint shall use the
following rules to discover and collect the destination transport following rules to discover and collect the destination transport
address(es) of its peer. address(es) of its peer.
On reception of an INIT or INIT ACK message, the receiver shall record A) If there are no address parameters present in the received INIT
any transport addresses. The transport address(es) are derived by the or INIT ACK message, the receiver shall take the source IP address
combination of SCTP source port (from the common header) and the IP from which the message arrives and record it, in combination with
address parameter(s) carried in the INIT or INIT ACK message. The the SCTP source port number, as the only destination transport
receiver should use only these transport addresses as destination address for this peer.
transport addresses when sending subsequent datagrams to its peer. If
no IP address parameters are specified in the INIT or INIT ACK
message, then the source IP address from which the message arrives
should be combined with SCTP source port number and be considered as
the only destination transport address to use.
An initial primary destination transport address shall be selected B) If there is a Host Name parameter present in the received INIT or
for either endpoint, using the following rules: INIT ACK message, the receiver shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of this
peer by combining the resolved IP address(es) with the SCTP source
port.
For the initiator: any valid transport address obtained from the Note: the receiver MUST ignore any other IP address parameters if
INIT ACK message. If no transport address is specified in the INIT they are also present in the received INIT or INIT ACK message.
ACK message, use the source transport address from which the INIT
ACK message arrived.
For the responder: any valid transport address obtained from the Note: when the receiver of an INIT resolves the host name may have
INIT message. If no transport address is specified in the INIT potential security implications to SCTP. If the receiver of an INIT
message, use the source transport address from which the INIT resolves the host name upon the reception of the message, and the
message arrived. mechanism the receiver uses to resolve the host name involves
potential long delay (e.g. DNS query), the receiver may open itself
up to resource attacks for the period of time while it is waiting for
the name resolution results before it can build the cookie and
release local resource.
Therefore, in cases where the name translation involves potential
long delay, the receiver of the INIT SHOULD postpone the name
resolution till the reception of the COOKIE message from the
peer. In such a case, the receiver of the INIT SHOULD build the
cookie using the received Host Name (instead of destination
transport addresses) and send the INIT ACK to the source IP
address from where the INIT is received.
The receiver of an INIT ACK shall always immediately attempt to
resolve the name upon the reception of the message.
The receiver of the INIT or INIT ACK MUST NOT send user data
(piggy-backed or stand-alone) to its peer until the host name is
successfully resolved.
If the name resolution is not successful, the endpoint SHALL
immediately send an ABORT with Unresolvable Address error to its
peer. The ABORT shall be sent to the source IP address from where
the last peer message was received.
C) If there are only IPv4/IPv6 addresses present in the received
INIT or INIT ACK message, the receiver shall derive and record all
the transport address(es) from the received message. The transport
address(es) are derived by the combination of SCTP source port (from
the common header) and the IP address parameter(s) carried in the
INIT or INIT ACK message. The receiver should use only these
transport addresses as destination transport addresses when sending
subsequent datagrams to its peer.
After all transport addresses are derived from the INIT or INIT ACK
message using above rules, the endpoint shall select one of the
transport addresses as the initial primary destination transport
address.
Note: the sender of INIT may include a 'Supported Address Types'
parameter in the INIT to indicate what types of address are
acceptable. When this parameter is present, the receiver of INIT
(initiatee) SHALL either use one of the address types indicated in the
'Supported Address Types' parameter when responding to the INIT, or
abort the association with an Unresolvable Address error if it is
unwilling or incapable of using any of the address types indicated by
its peer.
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a re-initiation
by using a 'Supported Address Types' parameter in the new INIT to
indicate what types of address it prefers.
4.1.3 Generating State Cookie 4.1.3 Generating State Cookie
When sending an INIT ACK as a response to an INIT message, the sender When sending an INIT ACK as a response to an INIT message, the sender
of INIT ACK should create an State Cookie and send it as part of the of INIT ACK should create an State Cookie and send it as part of the
INIT ACK. Inside this State Cookie, the sender should include a ICV INIT ACK. Inside this State Cookie, the sender should include a ICV
security signature or MAC (message Authentication code) [4], a time security signature or MAC (message Authentication code) [4], a time
stamp on when the cookie is created, and the lifespan of the cookie, stamp on when the cookie is created, and the lifespan of the cookie,
along with all the information necessary for it to establish the along with all the information necessary for it to establish the
association. association.
skipping to change at line 2099 skipping to change at line 2238
The ICV and hashing method used to generate the MAC is strictly a The ICV and hashing method used to generate the MAC is strictly a
private matter for the receiver of the INIT message. The use of a MAC private matter for the receiver of the INIT message. The use of a MAC
is mandatory to prevent denial of service attacks. The Private Key is mandatory to prevent denial of service attacks. The Private Key
MUST be random per RFC1750 [1]; it SHOULD be changed reasonably MUST be random per RFC1750 [1]; it SHOULD be changed reasonably
frequently, and the timestamp in the cookie MAY be used to determine frequently, and the timestamp in the cookie MAY be used to determine
which key should be used to verify the MAC. which key should be used to verify the MAC.
4.1.4 Cookie Processing 4.1.4 Cookie Processing
When an endpoint receives an INIT ACK chunk in response to its INIT When an endpoint receives an INIT ACK chunk with a State Cookie
chunk, and the INIT ACK contains an State Cookie parameter, it parameter, it MUST immediately send a COOKIE chunk to its peer with
MUST immediately send a COOKIE chunk to its peer with the received the received cookie. The sender MAY also add any pending DATA chunks
cookie. The sender MAY also add any pending DATA chunks to the to the message.
message.
The sender shall also start the cookie timer after sending out The sender shall also start the T1-cookie timer after sending out
the COOKIE chunk. If the timer expires, the sender shall retransmit the COOKIE chunk. If the timer expires, the sender shall retransmit
the COOKIE chunk and restart the cookie timer. This is repeated until the COOKIE chunk and restart the T1-cookie timer. This is repeated until
either a COOKIE ACK is received or the endpoint is marked either a COOKIE ACK is received or 'Max.Init.Retransmits' is reached
unreachable (and thus the association enters the CLOSED state). causing the endpoint to be marked unreachable (and thus the association
enters the CLOSED state).
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 a MAC signature using the TCB data carried in the cookie 1) compute a MAC signature using the TCB data carried in the cookie
and the Private Key (note the timestamp in the cookie MAY be and the Private Key (note the timestamp in the cookie MAY be
used to determine which Private Key to use) reference [4] SHOULD used to determine which Private Key to use) reference [4] SHOULD
be used has a guideline for generating the MAC, be used has a guideline for generating the MAC,
skipping to change at line 2137 skipping to change at line 2276
time, if the elapsed time is longer than the lifespan carried in time, if the elapsed time is longer than the lifespan carried in
the cookie, then the datagram, including the COOKIE and the the cookie, then the datagram, including the COOKIE and the
attached user data, SHOULD be discarded and the endpoint MUST attached user data, SHOULD be discarded and the endpoint MUST
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) immediately acknowledge any DATA chunk in the datagram with a SACK 5) immediately acknowledge any DATA chunk in the datagram with a SACK
(subsequent datagram acknowledgement should following the rules (subsequent datagram acknowledgment should follow the rules defined
defined in Section 5.2), and, in Section 5.2), and,
Stewart, et al [Page 40] Stewart, et al [Page 40]
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 outbound the cookie. The COOKIE ACK MAY be piggy-backed with any outbound
DATA chunk or SACK chunk. DATA chunk or SACK chunk.
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 procedures in receiver of the COOKIE has an existing association, the procedures 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 message to "Z", then "Z" sends two user messages to "A" later a user message to "Z", then "Z" sends two user messages to "A" later
skipping to change at line 2293 skipping to change at line 2432
If an INIT ACK is received by an endpoint in any state If an INIT ACK is received by an endpoint in any state
other than the COOKIE-WAIT state, the endpoint should discard other than the COOKIE-WAIT state, the endpoint should discard
the INIT ACK message. A duplicate INIT ACK usually indicates the the INIT ACK message. A duplicate INIT ACK usually indicates the
processing of an old INIT or duplicated INIT message. processing of an old INIT or duplicated INIT message.
4.2.4 Handle Duplicate Cookie 4.2.4 Handle Duplicate Cookie
When a duplicated COOKIE chunk is received in any state for an When a duplicated COOKIE chunk is received in any state for an
existing association the following rules shall be applied: existing association the following rules shall be applied:
1) compute an MD5 signature using the TCB data carried in the cookie 1) compute a MAC 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,
Stewart, et al [Page 43] Stewart, et al [Page 43]
2) authenticate the cookie by comparing the computed MD5 signature 2) authenticate the cookie by comparing the computed MAC signature
against the one carried in the cookie. If this comparison fails, against the one carried in the cookie. If this comparison fails,
the datagram, including the COOKIE and the attached user data, the datagram, including the COOKIE and the attached user data,
should be silently discarded (this is case C or D above). should be silently discarded (this is case C or D above).
3) compare the timestamp in the cookie to the current time, if 3) compare the timestamp in the cookie to the current time, if
the cookie is older than the lifespan carried in the cookie, the cookie is older than the lifespan carried in the cookie,
the datagram, including the COOKIE and the attached user data, the datagram, including the COOKIE and the attached user data,
should be discarded and the endpoint MUST transmit a stale cookie should be discarded and the endpoint MUST transmit a stale cookie
error to the sending endpoint only if the Verification tags of the error to the sending endpoint only if the Verification tags of the
cookie's TCB does NOT match the current tag values in the association cookie's TCB does NOT match the current tag values in the association
skipping to change at line 2516 skipping to change at line 2655
already running, the sender SHALL restart the timer ONLY IF the already running, the sender SHALL restart the timer ONLY IF the
earliest (i.e., lowest TSN) outstanding DATA chunk sent to that earliest (i.e., lowest TSN) outstanding DATA chunk sent to that
address is being retransmitted. address is being retransmitted.
Stewart, et al [Page 47] Stewart, et al [Page 47]
When starting or restarting the T3-rxt timer, the timer value must be When starting or restarting the T3-rxt timer, the timer value must be
adjusted according to the timer rules defined in Sections 5.3.2, adjusted according to the timer rules defined in Sections 5.3.2,
and 5.3.3. and 5.3.3.
Note: The sender SHOULD not use a TSN that is more than 2**31 - 1
above the beginning TSN of the current send window.
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. Specifically, an Section 4.2 of RFC 2581 [3] SHOULD be followed. Specifically, an
acknowledgment SHOULD be generated for at least every second datagram acknowledgment 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.
skipping to change at line 2554 skipping to change at line 2696
Note: When a datagram arrives with duplicate DATA chunk(s) and no new Note: When a datagram arrives with duplicate DATA chunk(s) and no new
DATA chunk(s), the receiver MUST immediately send a SACK with no DATA chunk(s), the receiver MUST immediately send a SACK with no
delay. Normally this will occur when the original SACK was lost, and delay. Normally this will occur when the original SACK was lost, and
the peers RTO has expired. The duplicate TSN number(s) SHOULD be reported the peers RTO has expired. The duplicate TSN number(s) SHOULD be reported
in the SACK as duplicate. in the SACK as duplicate.
When a receiver prepares a SACK, any duplicate DATA chunks received When a receiver prepares a SACK, any duplicate DATA chunks received
SHOULD be reported in the SACK. SHOULD be reported in the SACK.
When a SACK is received the receiver MAY use the Duplicate TSN When a SACK is received the receiver MAY use the Duplicate TSN
information to determine if SACK loss is occuring. Further use information to determine if SACK loss is occurring. Further use
of this data is for future study. of this data is for future study.
Note: If a SACK is received that indicates a previously out of order
chunk has been discarded by the receiver (due to a buffer space
shortage), the sender should mark the chunk as having a first strike
for retransmit against the chunk and start a timer on the last
transmitted destination address (if one is not already running on that
destination address). The sender SHOULD not retransmit the chunk until
the fast retransmit algorithm indicates it should. This will allow the
receiver time to clear up the receive buffer problem that caused it to
discard the chunk.
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
{App sends 3 messages; strm 0} {App sends 3 messages; strm 0}
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)
Stewart, et al [Page 48] Stewart, et al [Page 48]
skipping to change at line 2587 skipping to change at line 2739
(bundle SACK with DATA) (bundle SACK with DATA)
/----- SACK [TSN Ack=9,Frag=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,Frag=0] -------------> (cancel T3-rxt timer) SACK [TSN ACK=6,Frag=0] -------------> (cancel T3-rxt timer)
Note: If a receiver receives a DATA chunk with 0 length (no user data
part) it MUST follow the normal procedures for handling TSN and stream
sequence number. However, it MAY choose not to deliver the NULL data to
the upper layer.
5.2.1 Tracking Peer's Receive Buffer Space 5.2.1 Tracking Peer's Receive Buffer Space
Whenever a SACK arrives, a new updated a_rwnd arrives with it. This Whenever a SACK arrives, a new updated a_rwnd arrives with it. This
value represents the amount of buffer space the sender of the SACK, at value represents the amount of buffer space the sender of the SACK, at
the time of transmitting the SACK, has left of its total receive the time of transmitting the SACK, has left of its total receive
buffer space (as specified in the INIT/INIT-ACK). After processing the buffer space (as specified in the INIT/INIT-ACK). After processing the
SACK, the receiver of the SACK must use the following rules to SACK, the receiver of the SACK SHOULD use the following rules to
re-calculate the rwnd, using the received a_rwnd value. re-calculate the rwnd, using the received a_rwnd value.
A) At the establishment of the association, the endpoint initializes A) At the establishment of the association, the endpoint initializes
the rwnd to the Advertised Receiver Window Credit (a_rwnd) the rwnd to the Advertised Receiver Window Credit (a_rwnd)
the peer specified in the INIT or INIT ACK. the peer specified in the INIT or INIT ACK.
B) Any time a DATA chunk is transmitted to a peer, the endpoint B) Any time a DATA chunk is transmitted to a peer, the endpoint
subtracts the data size of the chunk from the rwnd of that peer. subtracts the data size of the chunk from the rwnd of that peer.
C) Any time a SACK arrives, the endpoint performs the following: C) Any time a SACK arrives, the endpoint performs the following:
skipping to change at line 3097 skipping to change at line 3254
6.1 SCTP Differences from TCP Congestion control 6.1 SCTP Differences from TCP Congestion control
One difference between SCTP and TCP is that the Selective One difference between SCTP and TCP is that the Selective
Acknowledgment function (SACK) is designed into SCTP, rather than an Acknowledgment function (SACK) is designed into SCTP, rather than an
enhancement that is added to the protocol later as is the case for enhancement that is added to the protocol later as is the case for
TCP. SCTP SACK carries the same semantic meaning with that of TCP TCP. SCTP SACK carries the same semantic meaning with that of TCP
SACK. TCP and SCTP considers the information carried in the SACK as SACK. TCP and SCTP considers the information carried in the SACK as
advisory information only. In SCTP, any DATA chunk that has been advisory information only. In SCTP, any DATA chunk that has been
acknowledged by SACK, including DATA that arrived at the receiving end acknowledged by SACK, including DATA that arrived at the receiving end
out of order, are NOT considered fully delivered until the Cumulative out of order, are NOT considered fully delivered until the Cumulative
Acknowledgement point passes the acknowledged DATA chunk. Consequently, Acknowledgment point passes the acknowledged DATA chunk. Consequently,
the value of cwnd controls the amount of outstanding data, rather than the value of cwnd controls the amount of outstanding data, rather than
the upper bound between the highest acknowledged sequence number and the upper bound between the highest acknowledged sequence number and
the latest DATA chunk that can be sent within the congestion window, the latest DATA chunk that can be sent within the congestion window,
as is the case in non-SACK TCP. SCTP SACK leads to different as is the case in non-SACK TCP. SCTP SACK leads to different
implementations of fast-retransmit and fast-recovery from that of implementations of fast-retransmit and fast-recovery from that of
non-SACK TCP. As an example see [16]. non-SACK TCP. As an example see [16].
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
skipping to change at line 3136 skipping to change at line 3293
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 an SCTP sender to be more conservative than the may be beneficial for an SCTP sender to be more conservative than the
algorithms allow, however an SCTP sender MUST NOT be more aggressive algorithms allow, however an SCTP sender MUST NOT be more aggressive
than the following algorithms allow. than the following algorithms allow.
Like TCP, an SCTP sender uses the following three control variables on a Like TCP, an SCTP sender uses the following three control variables
per destination basis to regulate its transmission rate. to regulate its transmission rate.
Stewart, et al [Page 59] Stewart, et al [Page 59]
o Receiver advertised window size (rwnd, in octets), which is set by o Receiver advertised window size (rwnd, in octets), which is set by
the receiver based on its available buffer space for incoming packets. the receiver based on its available buffer space for incoming packets.
Note: This variable is kept on the entire association.
o Congestion control window (cwnd, in octets), which is adjusted by o Congestion control window (cwnd, in octets), which is adjusted by
the sender based on observed network conditions. the sender based on observed network conditions.
Note: This variable is maintained on a per-destination basis.
o Slow-start threshold (ssthresh, in octets), which is used by the o Slow-start threshold (ssthresh, in octets), which is used by the
sender to distinguish slow start and congestion avoidance phases. sender to distinguish slow start and congestion avoidance phases.
Note: This variable is maintained on a per-destination basis.
SCTP also requires one additional control variable, partial_bytes_acked, SCTP also requires one additional control variable, partial_bytes_acked,
which is used during congestion avoidance phase to facilitate cwnd which is used during congestion avoidance phase to facilitate cwnd
adjustment. adjustment.
Unlike TCP, an SCTP sender MUST keep a set of these control variables Unlike TCP, an SCTP sender MUST keep a set of these control variables
for EACH destination address of its peer (when its peer is multi-homed). for EACH destination address of its peer (when its peer is multi-homed).
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
skipping to change at line 3348 skipping to change at line 3511
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 Other than these differences, the discussion of TCP's use of MTU
discovery in RFCs 1191 and 1981 applies to SCTP, too, on a discovery in RFCs 1191 and 1981 applies to SCTP, too, on a
per-destination-address basis. per-destination-address basis.
Note: For IPv6 destination addresses the DF bit does not exist,
instead the datagram must be fragmented as described in RFC1883 [17].
Stewart, et al [Page 63] Stewart, et al [Page 63]
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).
skipping to change at line 3436 skipping to change at line 3602
A) disable heart beat on a specific destination transport address of a A) disable heart beat on a specific destination transport address of a
given association, given association,
B) re-enable heart beat on a specific destination transport address of B) re-enable heart beat on a specific destination transport address of
a given association, and, a given association, and,
C) request an on-demand heartbeat on a specific destination transport C) request an on-demand heartbeat on a specific destination transport
address of a given association. address of a given association.
The endpoint should increment the respective 'retrans.count' counter The endpoint should increment the respective 'retrans.count' counter
of the destination transport address each time a HEARTBEAT is sent to of the destination transport address each time a HEARTBEAT is sent to
that address. that address and not acknowledged.
When the value of this counter reaches the protocol parameter When the value of this counter reaches the protocol parameter
'Path.Max.Retrans', the endpoint should mark the corresponding 'Path.Max.Retrans', the endpoint should mark the corresponding
destination address as inactive if it is not so marked, and may also destination address as inactive if it is not so marked, and may also
optionally report to the upper layer the change of reachability of optionally report to the upper layer the change of reachability of
this destination address. After this, the endpoint should continue this destination address. After this, the endpoint should continue
heartbeat on this destination address but should stop increasing the heartbeat on this destination address but should stop increasing the
counter. counter.
The sender of the HEARTBEAT message should include in the Heartbeat The sender of the HEARTBEAT message should include in the Heartbeat
Information field of the message the current time when the message is Information field of the message the current time when the message is
sent out and the information on the destination address to which the sent out and the information on the destination address to which the
message is sent. message is sent.
IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
mechanism that can be used is to increment the 'retrans.count'
variable every time a HEARTBEAT is sent to a destination. Whenever
a HEARTBEAT-ACK arrives, the sender SHOULD be clearing the
'retrans.count' of the destination that the HEARTBEAT was
sent to. This in effect would clear the previously stroked
error (and any other error counts as well).
Stewart, et al [Page 65] Stewart, et al [Page 65]
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 Heartbeat Information field copied out HEARTBEAT ACK that contains the Heartbeat Information field copied out
from the 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 'retrans.count' counter of the destination transport should clear the 'retrans.count' counter 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
skipping to change at line 3825 skipping to change at line 3999
o cause code - reason of the abort to be passed to the peer. o cause code - reason of the abort to be passed to the peer.
None. None.
Stewart, et al [Page 72] Stewart, et al [Page 72]
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,un-order [,stream id] [,life time] [,destination transport address] [,un-order
flag] [,no-bundle flag]) flag] [,no-bundle flag] [,payload protocol-id] )
-> result -> result
This is the main method to send user data 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 user message to be o buffer address - the location where the user message to be
transmitted is stored; transmitted is stored;
skipping to change at line 3854 skipping to change at line 4028
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 user data. The user data o life time - specifies the life time of the user data. The user data
will not be sent by SCTP after the life time expires. This 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
user messages. SCTP notifies the ULP, if the data cannot be user messages. 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. However, the send primitive) within the life time variable. However, the
user data will be transmitted if a TSN has been assigned to the user data will be transmitted if a chunk has been attempted to
user data before the life time expired. be transmitted before the life time expired.
IMPLEMENTATION NOTE: in order to better support the data lifetime
option, the data sender MAY hold back the assigning of the TSN number
to an outbound data chunk to the last moment. And, for implementation
simplicity, once a TSN number has been assigned the sender MAY consider
the send of this data chunk as committed, overriding any lifetime option
attached to the data chunk.
o destination transport address - specified as one of the destination 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 peer. would like the data delivered in an un-ordered fashion to the 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.
o payload protocol-id - A 32 bit u_int that is to be passed to the
peer indicating the type of payload protocol data being
transmitted. This value is passed as opaque data by SCTP.
Stewart, et al [Page 73] Stewart, et al [Page 73]
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 3900 skipping to change at line 4085
addresses of the peer endpoint, which should be used as primary addresses of the peer endpoint, which should be used as primary
address for sending datagrams. This overrides the current primary address for sending datagrams. This overrides the current primary
address information maintained by the local SCTP endpoint. address information maintained by the local SCTP endpoint.
Stewart, et al [Page 74] Stewart, et al [Page 74]
G) Receive G) Receive
Format: RECEIVE(association id, buffer address, buffer size Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence number] -> byte count [,transport address] [,stream id] [,stream sequence number]
[,partial flag] [, delivery number] [,partial flag] [,delivery number] [,payload protocol-id]
This primitive shall read the first user message in the SCTP in-queue This primitive shall read the first user message in the SCTP in-queue
to ULP, if there is one available, into the specified buffer. The size to ULP, if there is one available, into the specified buffer. The size
of the message read, in octets, will be returned. It may, depending on of the message read, in octets, will be returned. It may, depending on
the specific implementation, also return other information such as the the specific implementation, also return other information such as the
sender's address, the stream id on which it is received, whether there sender's address, the stream id on which it is received, whether there
are more messages available for retrieval, etc. For ordered messages, are more messages available for retrieval, etc. For ordered messages,
their stream sequence number may also be returned. their stream sequence number may also be returned.
Depending upon the implementation, if this primitive is invoked when Depending upon the implementation, if this primitive is invoked when
skipping to change at line 3938 skipping to change at line 4123
o stream sequence number - the stream sequence number assigned by the o stream sequence number - the stream sequence number assigned by the
sending SCTP peer. sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When message is a partial delivery of the whole message. When
this flag is set, the stream id and stream sequence number MUST this flag is set, the stream id and stream sequence number MUST
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence that no more deliveries will be received for this stream sequence
number. number.
o payload protocol-id - A 32 bit u_int that is received from the
peer indicating the type of payload protocol of the received
data. This value is passed as opaque data by SCTP.
Stewart, et al [Page 75] Stewart, et al [Page 75]
H) Status H) Status
Format: STATUS(association id) Format: STATUS(association id)
-> status data -> status data
This primitive should return a data block containing the following This primitive should return a data block containing the following
information: information:
association connection state, association connection state,
skipping to change at line 4432 skipping to change at line 4621
existing association. Prevention of such attacks should be covered existing association. Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in by appropriate security policies at the host site, as discussed in
section 10.2.1. section 10.2.1.
11. Recommended Transmission Control Block (TCB) Parameters 11. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should This section details a recommended set of parameters that should
be contained within the TCB for an implementation. This section is be contained within the TCB for an implementation. This section is
for illustrative purposes and should not be deemed as requirements for illustrative purposes and should not be deemed as requirements
on an implementation NOR as an exhaustive list of all parameters on an implementation NOR as an exhaustive list of all parameters
inside an SCTP TCB. Each implemenation may need its own additional inside an SCTP TCB. Each implementation may need its own additional
parameters to optimize their implemenation. parameters to optimize their implementation.
11.1 Parameters necessary for the SCTP instance 11.1 Parameters necessary for the SCTP instance
Associations A list of current associations and mappings to the Associations A list of current associations and mappings to the
data consumers for each association. This may be in data consumers for each association. This may be in
the form of a hash table or other implementation dependent the form of a hash table or other implementation dependent
structure. The data consumers may be process identification structure. The data consumers may be process identification
information such as file descriptors, named pipe pointer, or information such as file descriptors, named pipe pointer, or
table pointers dependent on how SCTP is implemented. table pointers dependent on how SCTP is implemented.
skipping to change at line 4457 skipping to change at line 4646
helpful in selection of the key. helpful in selection of the key.
Address List The list of IP addresses that this instance has bound. This Address List The list of IP addresses that this instance has bound. This
information is passed to one's peer(s) in INIT and INIT-ACK information is passed to one's peer(s) in INIT and INIT-ACK
messages. messages.
SCTP Port The local SCTP port number the endpoint is bound to. SCTP Port The local SCTP port number the endpoint is bound to.
Stewart, et al [Page 86] Stewart, et al [Page 86]
11.2 Parameters necessary per association (i.e. the TCB)
Peer Tag value to be sent in every datagram and is received Peer Tag value to be sent in every datagram and is received
Verification in the INIT or INIT ACK message. Verification in the INIT or INIT ACK message.
Tag Tag
My Tag expected in every inbound datagram and sent in the My Tag expected in every inbound datagram and sent in the
Verification INIT or INIT ACK message. Verification INIT or INIT ACK message.
Tag Tag
11.2 Parameters necessary per association (i.e. the TCB)
State A state variable indicating what state the association is State A state variable indicating what state the association is
in, i.e . COOKIE_WAIT, COOKIE_SENT, ESTABLISHED, in, i.e . COOKIE_WAIT, COOKIE_SENT, ESTABLISHED,
SHUTDOWN_PENDING, SHUTDOWN_SENT, SHUTDOWN_RECEIVED. SHUTDOWN_PENDING, SHUTDOWN_SENT, SHUTDOWN_RECEIVED.
Note: No "CLOSED" state is illustrated since if a Note: No "CLOSED" state is illustrated since if a
association is "CLOSED" its TCB SHOULD be removed. association is "CLOSED" its TCB SHOULD be removed.
Peer Transport A list of SCTP transport addresses that the peer is Peer Transport A list of SCTP transport addresses that the peer is
Address List bound to. This information is derived from the INIT or Address List bound to. This information is derived from the INIT or
INIT-ACK and is used to associate an inbound datagram INIT-ACK and is used to associate an inbound datagram
with a given association. Normally this information is with a given association. Normally this information is
skipping to change at line 4546 skipping to change at line 4735
Error count The current error count for this destination. Error count The current error count for this destination.
Error Current error threshold for this destination i.e. Error Current error threshold for this destination i.e.
Threshold what value marks the destination down if Error count Threshold what value marks the destination down if Error count
reaches this value. reaches this value.
cwnd The current congestion window. cwnd The current congestion window.
ssthresh The current ssthresh value. ssthresh The current ssthresh value.
RTO The current retransmission timeout vaule. RTO The current retransmission timeout value.
SRTT The current smoothed round trip time. SRTT The current smoothed round trip time.
RTTVAR The current RTT variation. RTTVAR The current RTT variation.
partial bytes The tracking method for increase of cwnd when in partial bytes The tracking method for increase of cwnd when in
acked congestion avoidance mode (see section 6.2.2) acked congestion avoidance mode (see section 6.2.2)
state The current state of this destionation, i.e. DOWN, UP, state The current state of this destination, i.e. DOWN, UP,
ALLOW-HB, NO-HEARTBEAT, etc. ALLOW-HB, NO-HEARTBEAT, etc.
P-MTU The current known path MTU. P-MTU The current known path MTU.
Per A timer used by each destination. Per A timer used by each destination.
Destination Destination
Timer Timer
Stewart, et al [Page 88] Stewart, et al [Page 88]
RTO-Pending A flag used to track if one of the datagrams sent to this address RTO-Pending A flag used to track if one of the datagrams sent to this
is currently being used to compute a RTT. If this flag is 0, the address is currently being used to compute a RTT. If this
next datagram sent to this destination should be used to compute flag is 0, the next datagram sent to this destination
a RTT and this flag should be set. Every time the RTT calcualtion should be used to compute a RTT and this flag should be
set. Every time the RTT calculation
completes (i.e. the datagram is SACK'd) clear this flag. completes (i.e. the datagram is SACK'd) clear this flag.
last-time The time this destination was last sent to. This can be used last-time The time this destination was last sent to. This can be used
used to determine if a HEARTBEAT is needed. used to determine if a HEARTBEAT is needed.
11.4 General Parameters Needed 11.4 General Parameters Needed
Out Queue A queue of outbound datagrams. Out Queue A queue of outbound datagrams.
In Queue A queue of inbound datagrams. In Queue A queue of inbound datagrams.
skipping to change at line 4756 skipping to change at line 4946
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 9). customize some of these protocol parameters (see Section 9).
14. Acknowledgments 14. Acknowledgments
The authors wish to thank Mark Allman, Richard Band, Scott Bradner, The authors wish to thank Mark Allman, Richard Band, Scott Bradner,
Steve Bellovin, Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege, Steve Bellovin, Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege,
Henry Houh, Christian Huetima, Gary Lehecka, John Loughney, Daniel Henry Houh, Christian Huetima, Gary Lehecka, John Loughney, Daniel
Luan, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Luan, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno
Rajahalme, Ivan Raymond E. Reeves, Renee Revis, Arias Rodriguez, Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez,
A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their
invaluable comments. invaluable comments.
Stewart, et al [Page 92] Stewart, et al [Page 92]
15. Authors' Addresses 15. 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
skipping to change at line 4782 skipping to change at line 4972
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Chip Sharp Tel: +1-919-472-3121 Chip Sharp Tel: +1-919-392-3121
Cisco Systems Inc. EMail:chsharp@cisco.com Cisco Systems Inc. EMail:chsharp@cisco.com
7025 Kit Creek Road 7025 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Hanns Juergen Schwarzbauer Tel: +49-89-722-24236 Hanns Juergen Schwarzbauer Tel: +49-89-722-24236
SIEMENS AG SIEMENS AG
Hofmannstr. 51 Hofmannstr. 51
81359 Munich 81359 Munich
Germany Germany
skipping to change at line 4883 skipping to change at line 5073
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[15] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., [15] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999. Computer Communication Review, 29(5), October 1999.
[16] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, [16] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe,
Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3,
July 1996, pp. 5-21. July 1996, pp. 5-21.
[17] Deering, S., and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 1883, December 1995.
Appendix A: Explicit Congestion Notification Appendix A: Explicit Congestion Notification
ECN (Ramakrishnan, k., Floyd, S., "Explicit Congestion Notification", ECN (Ramakrishnan, k., Floyd, S., "Explicit Congestion Notification",
RFC 2481, January 1999) describes a proposed extension to IP that RFC 2481, January 1999) describes a proposed extension to IP that
details a method to become aware of congestion outside of datagram details a method to become aware of congestion outside of datagram
loss. This is an optional feature that an implemenation MAY choose to loss. This is an optional feature that an implementation MAY choose to
add to SCTP. This appendix details the minor differences an implemenator add to SCTP. This appendix details the minor differences an implementor
will need to be aware of if they choose to implement this feature. will need to be aware of if they choose to implement this feature.
In general RFC 2481 should be followed with the following exceptions. In general RFC 2481 should be followed with the following exceptions.
Negotiation: Negotiation:
RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages
of a TCP connection. The sender of the SYN sets two bits in the of a TCP connection. The sender of the SYN sets two bits in the
TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning
behind this is to assure both sides are truely ECN capable. For SCTP behind this is to assure both sides are truly ECN capable. For SCTP
this is not necessary. To indicate that an endpoint is ECN capable this is not necessary. To indicate that an endpoint is ECN capable
a endpoint MAY add to the INIT and or INIT-ACK message the TLV a endpoint MAY add to the INIT and or INIT-ACK message the TLV
reserved for ECN. This TLV contains no parameters and thus has reserved for ECN. This TLV contains no parameters, and thus 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000a | Parameter Length = 0x0004 | | Parameter Type = 0x000a | Parameter Length = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart, et al [Page 95] Stewart, et al [Page 95]
ECN-Echo: ECN-Echo:
RFC 2481 details a specific bit for a receiver to send back in its RFC 2481 details a specific bit for a receiver to send back in its
acknowledgments to notifiy the sender of the Congestion Experienced (CE) acknowledgments to notify the sender of the Congestion Experienced (CE)
bit having arrived from the network. For SCTP this same indication is bit having arrived from the network. For SCTP this same indication is
made by including the ECNE chunk. This chunk contains NO parameters made by including the ECNE chunk. This chunk contains one data
or data and looks as follows: element, i.e. the lowest TSN associated with the datagram marked
with the CE bit, and looks as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=00001100 | Flags=00000000| Chunk Length=0004 | | ID=00001100 | Flags=00000000| Chunk Length=0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk. Note: The ECNE is considered a Control chunk.
CWR: CWR:
RFC 2481 details a specific bit for a sender to send in its RFC 2481 details a specific bit for a sender to send in its
next outbound datagram to indicate to its peer that it has next outbound datagram to indicate to its peer that it has
reduced its congestion window. This is termed the CWR bit. For reduced its congestion window. This is termed the CWR bit. For
SCTP the same indication is made by including the CWR chunk. SCTP the same indication is made by including the CWR chunk.
This chunk contains NO parameters or data and looks as follows: This chunk contains one data element, i.e. the TSN number that
was sent in the ECN-Echo. This element represents the lowest
TSN number in the datagram that was originally marked with the
CE bit.
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=00001101 | Flags=00000000| Chunk Length=0004 | | ID=00001101 | Flags=00000000| Chunk Length=0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The CWR is considered a Control chunk. Note: The CWR is considered a Control chunk.
This Internet Draft expires in 6 months from March, 2000 This Internet Draft expires in 6 months from April, 2000
Stewart, et al [Page 96] Stewart, et al [Page 96]
 End of changes. 

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