draft-ietf-tsvwg-rfc4960-bis-00.txt   draft-ietf-tsvwg-rfc4960-bis-01.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Obsoletes: 4960 (if approved) M. Tuexen Obsoletes: 4960 (if approved) M. Tuexen
Intended status: Standards Track Muenster Univ. of Appl. Sciences Intended status: Standards Track Muenster Univ. of Appl. Sciences
Expires: May 27, 2019 K. Nielsen Expires: September 12, 2019 K. Nielsen
Kamstrup A/S Kamstrup A/S
November 23, 2018 March 11, 2019
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-rfc4960-bis-00 draft-ietf-tsvwg-rfc4960-bis-01
Abstract Abstract
This document obsoletes RFC 4960, if approved. It describes the This document obsoletes RFC 4960, if approved. It describes the
Stream Control Transmission Protocol (SCTP). SCTP is designed to Stream Control Transmission Protocol (SCTP). SCTP is designed to
transport Public Switched Telephone Network (PSTN) signaling messages transport Public Switched Telephone Network (PSTN) signaling messages
over IP networks, but is capable of broader applications. over IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following connectionless 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, o acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size, o data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with o sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user an option for order-of-arrival delivery of individual user
messages, messages,
-- optional bundling of multiple user messages into a single SCTP o optional bundling of multiple user messages into a single SCTP
packet, and packet, and
-- network-level fault tolerance through supporting of multi-homing o network-level fault tolerance through supporting of multi-homing
at either or both ends of an association. at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks. and resistance to flooding and masquerade attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 43
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction ....................................................6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation .................................................6 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Architectural View of SCTP .................................7 1.2. Architectural View of SCTP . . . . . . . . . . . . . . . 6
1.3. Key Terms ..................................................7 1.3. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Abbreviations .............................................11 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Functional View of SCTP ...................................11 1.5. Functional View of SCTP . . . . . . . . . . . . . . . . . 11
1.5.1. Association Startup and Takedown ...................12 1.5.1. Association Startup and Takedown . . . . . . . . . . 12
1.5.2. Sequenced Delivery within Streams ..................13 1.5.2. Sequenced Delivery within Streams . . . . . . . . . . 13
1.5.3. User Data Fragmentation ............................13 1.5.3. User Data Fragmentation . . . . . . . . . . . . . . . 13
1.5.4. Acknowledgement and Congestion Avoidance ...........13 1.5.4. Acknowledgement and Congestion Avoidance . . . . . . 13
1.5.5. Chunk Bundling .....................................14 1.5.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 14
1.5.6. Packet Validation ..................................14 1.5.6. Packet Validation . . . . . . . . . . . . . . . . . . 14
1.5.7. Path Management ....................................14 1.5.7. Path Management . . . . . . . . . . . . . . . . . . . 14
1.6. Serial Number Arithmetic ..................................15 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15
1.7. Changes from RFC 4960 .....................................16 1.7. Changes from RFC 4960 . . . . . . . . . . . . . . . . . . 16
2. Conventions ....................................................16 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. SCTP Packet Format .............................................16 3. SCTP Packet Format . . . . . . . . . . . . . . . . . . . . . 16
3.1. SCTP Common Header Field Descriptions .....................17 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 16
3.2. Chunk Field Descriptions ..................................18 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18
3.2.1. Optional/Variable-Length Parameter Format ..........20 3.2.1. Optional/Variable-Length Parameter Format . . . . . . 20
3.2.2. Reporting of Unrecognized Parameters ...............22 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22
3.3. SCTP Chunk Definitions ....................................22 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 22
3.3.1. Payload Data (DATA) (0) ............................23 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 22
3.3.2. Initiation (INIT) (1) ..............................25 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25
3.3.2.1. Optional/Variable-Length 3.3.2.1. Optional/Variable-Length Parameters in INIT . . . 28
Parameters in INIT ........................28 3.3.3. Initiation Acknowledgement (INIT ACK) (2) . . . . . . 31
3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........31 3.3.3.1. Optional or Variable-Length Parameters . . . . . 34
3.3.3.1. Optional or Variable-Length Parameters ....34 3.3.4. Selective Acknowledgement (SACK) (3) . . . . . . . . 34
3.3.4. Selective Acknowledgement (SACK) (3) ...............35 3.3.5. Heartbeat Request (HEARTBEAT) (4) . . . . . . . . . . 38
3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................39 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) . . . . 39
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......40 3.3.7. Abort Association (ABORT) (6) . . . . . . . . . . . . 40
3.3.7. Abort Association (ABORT) (6) ......................41 3.3.8. Shutdown Association (SHUTDOWN) (7) . . . . . . . . . 41
3.3.8. Shutdown Association (SHUTDOWN) (7) ................42 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) . . . . . 41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........42 3.3.10. Operation Error (ERROR) (9) . . . . . . . . . . . . . 42
3.3.10. Operation Error (ERROR) (9) .......................43 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 43
3.3.10.1. Invalid Stream Identifier (1) ............45 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 44
3.3.10.2. Missing Mandatory Parameter (2) ..........45 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 44
3.3.10.3. Stale Cookie Error (3) ...................46 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 45
3.3.10.4. Out of Resource (4) ......................46 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 45
3.3.10.5. Unresolvable Address (5) .................47 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 45
3.3.10.6. Unrecognized Chunk Type (6) ..............47 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 46
3.3.10.7. Invalid Mandatory Parameter (7) ..........48 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 46
3.3.10.8. Unrecognized Parameters (8) ..............48 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 47
3.3.10.9. No User Data (9) .........................49 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 47
3.3.10.10. Cookie Received While Shutting 3.3.10.11. Restart of an Association with New Addresses
Down (10) ...............................49 (11) . . . . . . . . . . . . . . . . . . . . . . 48
3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 48
3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 48
3.3.11. Cookie Echo (COOKIE ECHO) (10) . . . . . . . . . . . 49
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) . . . . . . 50
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) . . . . . 50
4. SCTP Association State Diagram . . . . . . . . . . . . . . . 51
5. Association Initialization . . . . . . . . . . . . . . . . . 54
5.1. Normal Establishment of an Association . . . . . . . . . 54
5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 56
5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 57
5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 59
5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 60
5.1.5. State Cookie Authentication . . . . . . . . . . . . . 60
5.1.6. An Example of Normal Association Establishment . . . 61
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE
ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 63
5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State
(Item B) . . . . . . . . . . . . . . . . . . . . . . 63
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-
ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT . . . . . 64
5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 65
5.2.4. Handle a COOKIE ECHO when a TCB Exists . . . . . . . 65
5.2.4.1. An Example of a Association Restart . . . . . . . 67
5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 69
5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 69
5.3. Other Initialization Issues . . . . . . . . . . . . . . . 69
5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 69
5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 70
6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 71
6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 73
6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 75
6.2.1. Processing a Received SACK . . . . . . . . . . . . . 78
6.3. Management of Retransmission Timer . . . . . . . . . . . 80
6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 80
6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 81
6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 82
6.4. Multi-Homed SCTP Endpoints . . . . . . . . . . . . . . . 84
6.4.1. Failover from an Inactive Destination Address . . . . 84
6.5. Stream Identifier and Stream Sequence Number . . . . . . 85
6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 85
6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 86
6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 87
6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 88
6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 89
7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 90
7.1. SCTP Differences from TCP Congestion Control . . . . . . 91
7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 92
7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 92
7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 94
7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 94
7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 95
7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 96
8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 97
8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 97
8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 97
8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 98
8.4. Handle "Out of the Blue" Packets . . . . . . . . . . . . 100
8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 101
8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 101
3.3.10.11. Restart of an Association with 9. Termination of Association . . . . . . . . . . . . . . . . . 103
New Addresses (11) ......................50 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 103
3.3.10.12. User-Initiated Abort (12) ...............50 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 103
3.3.10.13. Protocol Violation (13) .................51 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 106
3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................51 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . 106
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........52 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . 115
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........52 11. Security Considerations . . . . . . . . . . . . . . . . . . . 117
4. SCTP Association State Diagram .................................53 11.1. Security Objectives . . . . . . . . . . . . . . . . . . 117
5. Association Initialization .....................................57 11.2. SCTP Responses to Potential Threats . . . . . . . . . . 118
5.1. Normal Establishment of an Association ....................57 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 118
5.1.1. Handle Stream Parameters ...........................59 11.2.2. Protecting against Data Corruption in the Network . 118
5.1.2. Handle Address Parameters ..........................59 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 118
5.1.3. Generating State Cookie ............................62 11.2.4. Protecting against Blind Denial-of-Service Attacks . 119
5.1.4. State Cookie Processing ............................63 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 119
5.1.5. State Cookie Authentication ........................63 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 120
5.1.6. An Example of Normal Association Establishment .....65 11.2.4.3. Improper Monopolization of Services . . . . . . 121
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, 11.3. SCTP Interactions with Firewalls . . . . . . . . . . . . 121
COOKIE ECHO, and ..........................................66 11.4. Protection of Non-SCTP-Capable Hosts . . . . . . . . . . 122
5.2.1. INIT Received in COOKIE-WAIT or 12. Network Management Considerations . . . . . . . . . . . . . . 122
COOKIE-ECHOED State (Item B) .......................67 13. Recommended Transmission Control Block (TCB) Parameters . . . 122
5.2.2. Unexpected INIT in States Other than 13.1. Parameters Necessary for the SCTP Instance . . . . . . . 123
CLOSED, COOKIE-ECHOED, .............................67 13.2. Parameters Necessary per Association (i.e., the TCB) . . 123
5.2.3. Unexpected INIT ACK ................................68 13.3. Per Transport Address Data . . . . . . . . . . . . . . . 124
5.2.4. Handle a COOKIE ECHO when a TCB Exists .............68 13.4. General Parameters Needed . . . . . . . . . . . . . . . 125
5.2.4.1. An Example of a Association Restart .......70 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
5.2.5. Handle Duplicate COOKIE-ACK. .......................72 14.1. IETF-Defined Chunk Extension . . . . . . . . . . . . . . 125
5.2.6. Handle Stale COOKIE Error ..........................72 14.2. IETF-Defined Chunk Parameter Extension . . . . . . . . . 126
5.3. Other Initialization Issues ...............................73 14.3. IETF-Defined Additional Error Causes . . . . . . . . . . 126
5.3.1. Selection of Tag Value .............................73 14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 127
5.4. Path Verification .........................................73 14.5. Port Numbers Registry . . . . . . . . . . . . . . . . . 127
6. User Data Transfer .............................................74 15. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 130
6.1. Transmission of DATA Chunks ...............................76 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 130
6.2. Acknowledgement on Reception of DATA Chunks ...............79 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.2.1. Processing a Received SACK .........................82 17.1. Normative References . . . . . . . . . . . . . . . . . . 131
6.3. Management of Retransmission Timer ........................84 17.2. Informative References . . . . . . . . . . . . . . . . . 133
6.3.1. RTO Calculation ....................................84 Appendix A. Explicit Congestion Notification . . . . . . . . . . 134
6.3.2. Retransmission Timer Rules .........................86 Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 136
6.3.3. Handle T3-rtx Expiration ...........................87 Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 138
6.4. Multi-Homed SCTP Endpoints ................................88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 144
6.4.1. Failover from an Inactive Destination Address ......89
6.5. Stream Identifier and Stream Sequence Number ..............89
6.6. Ordered and Unordered Delivery ............................89
6.7. Report Gaps in Received DATA TSNs .........................90
6.8. CRC32c Checksum Calculation ...............................91
6.9. Fragmentation and Reassembly ..............................92
6.10. Bundling .................................................93
7. Congestion Control .............................................94
7.1. SCTP Differences from TCP Congestion Control ..............95
7.2. SCTP Slow-Start and Congestion Avoidance ..................96
7.2.1. Slow-Start .........................................97
7.2.2. Congestion Avoidance ...............................98
7.2.3. Congestion Control .................................99
7.2.4. Fast Retransmit on Gap Reports .....................99
7.3. Path MTU Discovery .......................................101
8. Fault Management ..............................................101
8.1. Endpoint Failure Detection ...............................101
8.2. Path Failure Detection ...................................102
8.3. Path Heartbeat ...........................................103
8.4. Handle "Out of the Blue" Packets .........................105
8.5. Verification Tag .........................................106
8.5.1. Exceptions in Verification Tag Rules ..............106
9. Termination of Association ....................................107
9.1. Abort of an Association ..................................108
9.2. Shutdown of an Association ...............................108
10. Interface with Upper Layer ...................................111
10.1. ULP-to-SCTP .............................................111
10.2. SCTP-to-ULP .............................................121
11. Security Considerations ......................................124
11.1. Security Objectives .....................................124
11.2. SCTP Responses to Potential Threats .....................125
11.2.1. Countering Insider Attacks .......................125
11.2.2. Protecting against Data Corruption in the
Network ..........................................125
11.2.3. Protecting Confidentiality .......................125
11.2.4. Protecting against Blind
Denial-of-Service Attacks ........................126
11.2.4.1. Flooding ................................126
11.2.4.2. Blind Masquerade ........................127
11.2.4.3. Improper Monopolization of Services .....128
11.3. SCTP Interactions with Firewalls ........................128
11.4. Protection of Non-SCTP-Capable Hosts ....................129
12. Network Management Considerations ............................129
13. Recommended Transmission Control Block (TCB) Parameters ......130
13.1. Parameters Necessary for the SCTP Instance ..............130
13.2. Parameters Necessary per Association (i.e., the TCB) ....130
13.3. Per Transport Address Data ..............................132
13.4. General Parameters Needed ...............................133
14. IANA Considerations ..........................................133
14.1. IETF-defined Chunk Extension ............................133
14.2. IETF-Defined Chunk Parameter Extension ..................134
14.3. IETF-Defined Additional Error Causes ....................134
14.4. Payload Protocol Identifiers ............................135
14.5. Port Numbers Registry ...................................135
15. Suggested SCTP Protocol Parameter Values .....................137
16. Acknowledgements .............................................138
Appendix A. Explicit Congestion Notification .....................140
Appendix B. CRC32c Checksum Calculation ..........................141
Appendix C. ICMP Handling ........................................143
References .......................................................150
Normative References ..........................................150
Informative References ........................................151
1. Introduction 1. Introduction
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
Stream 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.
This document obsoletes [RFC4960], if approved. This document obsoletes [RFC4960], if approved.
1.1. Motivation 1.1. Motivation
TCP [RFC0793] has performed immense service as the primary means of TCP [RFC0793] has performed immense service as the primary means of
reliable data transfer in IP networks. However, an increasing number reliable data transfer in IP networks. However, an increasing number
of recent applications have found TCP too limiting, and have of recent applications have found TCP too limiting, and have
incorporated their own reliable data transfer protocol on top of UDP incorporated their own reliable data transfer protocol on top of UDP
[RFC0768]. The limitations that users have wished to bypass include [RFC0768]. The limitations that users have wished to bypass include
the following: the following:
-- TCP provides both reliable data transfer and strict order-of- o TCP provides both reliable data transfer and strict order-of-
transmission delivery of data. Some applications need reliable transmission delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these satisfied with partial ordering of the data. In both of these
cases, the head-of-line blocking offered by TCP causes unnecessary cases, the head-of-line blocking offered by TCP causes unnecessary
delay. delay.
-- The stream-oriented nature of TCP is often an inconvenience. o The stream-oriented nature of TCP is often an inconvenience.
Applications must add their own record marking to delineate their Applications must add their own record marking to delineate their
messages, and must make explicit use of the push facility to messages, and must make explicit use of the push facility to
ensure that a complete message is transferred in a reasonable ensure that a complete message is transferred in a reasonable
time. time.
-- The limited scope of TCP sockets complicates the task of providing o The limited scope of TCP sockets complicates the task of providing
highly-available data transfer capability using multi-homed hosts. highly-available data transfer capability using multi-homed hosts.
-- TCP is relatively vulnerable to denial-of-service attacks, such as o TCP is relatively vulnerable to denial-of-service attacks, such as
SYN attacks. SYN attacks.
Transport of PSTN signaling across the IP network is an application Transport of PSTN signaling across the IP network is an application
for which all of these limitations of TCP are relevant. While this for which all of these limitations of TCP are relevant. While this
application directly motivated the development of SCTP, other application directly motivated the development of SCTP, other
applications may find SCTP a good match to their requirements. applications may find SCTP a good match to their requirements.
1.2. Architectural View of SCTP 1.2. Architectural View of SCTP
SCTP is viewed as a layer between the SCTP user application ("SCTP SCTP is viewed as a layer between the SCTP user application ("SCTP
skipping to change at page 7, line 26 skipping to change at page 7, line 10
SCTP is connection-oriented in nature, but the SCTP association is a SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint (Section 1.3) to provide the other endpoint each SCTP endpoint (Section 1.3) to provide the other endpoint
(during association startup) with a list of transport addresses (during association startup) with a list of transport addresses
(i.e., multiple IP addresses in combination with an SCTP port) (i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will through which that endpoint can be reached and from which it will
originate SCTP packets. The association spans transfers over all of originate SCTP packets. The association spans transfers over all of
the possible source/destination combinations that may be generated the possible source/destination combinations that may be generated
from each endpoint's lists. from each endpoint's lists.
_____________ _____________ _____________ _____________
| SCTP User | | SCTP User | | SCTP User | | SCTP User |
| Application | | Application | | Application | | Application |
|-------------| |-------------| |-------------| |-------------|
| SCTP | | SCTP | | SCTP | | SCTP |
| Transport | | Transport | | Transport | | Transport |
| Service | | Service | | Service | | Service |
|-------------| |-------------| |-------------| |-------------|
| |One or more ---- One or more| | | |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network | | IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service | | Service |appearances /\ appearances| Service |
|_____________| ---- |_____________| |_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association Figure 1: An SCTP Association
1.3. Key Terms 1.3. Key Terms
Some of the language used to describe SCTP has been introduced in the Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the previous sections. This section provides a consolidated list of the
key terms and their definitions. key terms and their definitions.
o Active destination transport address: A transport address on a Active destination transport address: A transport address on a peer
peer endpoint that a transmitting endpoint considers available for endpoint that a transmitting endpoint considers available for
receiving user messages. receiving user messages.
o Bundling: An optional multiplexing operation, whereby more than Bundling: An optional multiplexing operation, whereby more than one
one user message may be carried in the same SCTP packet. Each user message may be carried in the same SCTP packet. Each user
user message occupies its own DATA chunk. message occupies its own DATA chunk.
o Chunk: A unit of information within an SCTP packet, consisting of Chunk: A unit of information within an SCTP packet, consisting of a
a chunk header and chunk-specific content. chunk header and chunk-specific content.
o Congestion window (cwnd): An SCTP variable that limits the data, Congestion window (cwnd): An SCTP variable that limits the data, in
in number of bytes, a sender can send to a particular destination number of bytes, a sender can send to a particular destination
transport address before receiving an acknowledgement. transport address before receiving an acknowledgement.
o Cumulative TSN Ack Point: The TSN of the last DATA chunk Cumulative TSN Ack Point: The TSN of the last DATA chunk
acknowledged via the Cumulative TSN Ack field of a SACK. acknowledged via the Cumulative TSN Ack field of a SACK.
o Idle destination address: An address that has not had user Idle destination address: An address that has not had user messages
messages sent to it within some length of time, normally the sent to it within some length of time, normally the HEARTBEAT
HEARTBEAT interval or greater. interval or greater.
o Inactive destination transport address: An address that is Inactive destination transport address: An address that is
considered inactive due to errors and unavailable to transport considered inactive due to errors and unavailable to transport
user messages. user messages.
o Message = user message: Data submitted to SCTP by the Upper Layer Message = user message: Data submitted to SCTP by the Upper Layer
Protocol (ULP). Protocol (ULP).
o Message Authentication Code (MAC): An integrity check mechanism Message Authentication Code (MAC): An integrity check mechanism
based on cryptographic hash functions using a secret key. based on cryptographic hash functions using a secret key.
Typically, message authentication codes are used between two Typically, message authentication codes are used between two
parties that share a secret key in order to validate information parties that share a secret key in order to validate information
transmitted between these parties. In SCTP, it is used by an transmitted between these parties. In SCTP, it is used by an
endpoint to validate the State Cookie information that is returned endpoint to validate the State Cookie information that is returned
from the peer in the COOKIE ECHO chunk. The term "MAC" has from the peer in the COOKIE ECHO chunk. The term "MAC" has
different meanings in different contexts. SCTP uses this term different meanings in different contexts. SCTP uses this term
with the same meaning as in [RFC2104]. with the same meaning as in [RFC2104].
o Network Byte Order: Most significant byte first, a.k.a., big Network Byte Order: Most significant byte first, a.k.a., big endian.
endian.
o Ordered Message: A user message that is delivered in order with Ordered Message: A user message that is delivered in order with
respect to all previous user messages sent within the stream on respect to all previous user messages sent within the stream on
which the message was sent. which the message was sent.
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
DATA chunk) that has been sent by the endpoint but for which it DATA chunk) that has been sent by the endpoint but for which it
has not yet received an acknowledgement. has not yet received an acknowledgement.
o Path: The route taken by the SCTP packets sent by one SCTP Path: The route taken by the SCTP packets sent by one SCTP endpoint
endpoint to a specific destination transport address of its peer to a specific destination transport address of its peer SCTP
SCTP endpoint. Sending to different destination transport endpoint. Sending to different destination transport addresses
addresses does not necessarily guarantee getting separate paths. does not necessarily guarantee getting separate paths.
o Primary Path: The primary path is the destination and source Primary Path: The primary path is the destination and source address
address that will be put into a packet outbound to the peer that will be put into a packet outbound to the peer endpoint by
endpoint by default. The definition includes the source address default. The definition includes the source address since an
since an implementation MAY wish to specify both destination and implementation MAY wish to specify both destination and source
source address to better control the return path taken by reply address to better control the return path taken by reply chunks
chunks and on which interface the packet is transmitted when the and on which interface the packet is transmitted when the data
data sender is multi-homed. sender is multi-homed.
o Receiver Window (rwnd): An SCTP variable a data sender uses to Receiver Window (rwnd): An SCTP variable a data sender uses to store
store the most recently calculated receiver window of its peer, in the most recently calculated receiver window of its peer, in
number of bytes. This gives the sender an indication of the space number of bytes. This gives the sender an indication of the space
available in the receiver's inbound buffer. available in the receiver's inbound buffer.
o SCTP association: A protocol relationship between SCTP endpoints, SCTP association: A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information composed of the two SCTP endpoints and protocol state information
including Verification Tags and the currently active set of including Verification Tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. An association can be Transmission Sequence Numbers (TSNs), etc. An association can be
uniquely identified by the transport addresses used by the uniquely identified by the transport addresses used by the
endpoints in the association. Two SCTP endpoints MUST NOT have endpoints in the association. Two SCTP endpoints MUST NOT have
more than one SCTP association between them at any given time. more than one SCTP association between them at any given time.
o SCTP endpoint: The logical sender/receiver of SCTP packets. On a SCTP endpoint: The logical sender/receiver of SCTP packets. On a
multi-homed host, an SCTP endpoint is represented to its peers as multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a set of eligible destination transport addresses a combination of a set of eligible destination transport addresses
to which SCTP packets can be sent and a set of eligible source to which SCTP packets can be sent and a set of eligible source
transport addresses from which SCTP packets can be received. All transport addresses from which SCTP packets can be received. All
transport addresses used by an SCTP endpoint must use the same transport addresses used by an SCTP endpoint must use the same
port number, but can use multiple IP addresses. A transport port number, but can use multiple IP addresses. A transport
address used by an SCTP endpoint must not be used by another SCTP address used by an SCTP endpoint must not be used by another SCTP
endpoint. In other words, a transport address is unique to an endpoint. In other words, a transport address is unique to an
SCTP endpoint. SCTP endpoint.
o SCTP packet (or packet): The unit of data delivery across the SCTP packet (or packet): The unit of data delivery across the
interface between SCTP and the connectionless packet network interface between SCTP and the connectionless packet network
(e.g., IP). An SCTP packet includes the common SCTP header, (e.g., IP). An SCTP packet includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated within possible SCTP control chunks, and user data encapsulated within
SCTP DATA chunks. SCTP DATA chunks.
o SCTP user application (SCTP user): The logical higher-layer 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).
o Slow-Start Threshold (ssthresh): An SCTP variable. This is the Slow-Start Threshold (ssthresh): An SCTP variable. This is the
threshold that the endpoint will use to determine whether to threshold that the endpoint will use to determine whether to
perform slow start or congestion avoidance on a particular perform slow start or congestion avoidance on a particular
destination transport address. Ssthresh is in number of bytes. destination transport address. Ssthresh is in number of bytes.
o Stream: A unidirectional logical channel established from one to Stream: A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the are delivered in sequence except for those submitted to the
unordered delivery service. unordered delivery service.
Note: The relationship between stream numbers in opposite directions Note: The relationship between stream numbers in opposite directions
is strictly a matter of how the applications use them. It is the is strictly a matter of how the applications use them. It is the
responsibility of the SCTP user to create and manage these responsibility of the SCTP user to create and manage these
correlations if they are so desired. correlations if they are so desired.
o Stream Sequence Number: A 16-bit sequence number used internally Stream Sequence Number: A 16-bit sequence number used internally by
by SCTP to ensure sequenced delivery of the user messages within a SCTP to ensure sequenced delivery of the user messages within a
given stream. One Stream Sequence Number is attached to each user given stream. One Stream Sequence Number is attached to each user
message. message.
o Tie-Tags: Two 32-bit random numbers that together make a 64-bit Tie-Tags: Two 32-bit random numbers that together make a 64-bit
nonce. These tags are used within a State Cookie and TCB so that nonce. These tags are used within a State Cookie and TCB so that
a newly restarting association can be linked to the original a newly restarting association can be linked to the original
association within the endpoint that did not restart and yet not association within the endpoint that did not restart and yet not
reveal the true Verification Tags of an existing association. reveal the true Verification Tags of an existing association.
o Transmission Control Block (TCB): An internal data structure Transmission Control Block (TCB): An internal data structure created
created by an SCTP endpoint for each of its existing SCTP by an SCTP endpoint for each of its existing SCTP associations to
associations to other SCTP endpoints. TCB contains all the status other SCTP endpoints. TCB contains all the status and operational
and operational information for the endpoint to maintain and information for the endpoint to maintain and manage the
manage the corresponding association. corresponding association.
o Transmission Sequence Number (TSN): A 32-bit sequence number used Transmission Sequence Number (TSN): A 32-bit sequence number used
internally by SCTP. One TSN is attached to each chunk containing internally by SCTP. One TSN is attached to each chunk containing
user data to permit the receiving SCTP endpoint to acknowledge its user data to permit the receiving SCTP endpoint to acknowledge its
receipt and detect duplicate deliveries. receipt and detect duplicate deliveries.
o Transport address: A transport address is traditionally defined by Transport address: A transport address is traditionally defined by a
a network-layer address, a transport-layer protocol, and a network-layer address, a transport-layer protocol, and a
transport-layer port number. In the case of SCTP running over IP, transport-layer port number. In the case of SCTP running over IP,
a transport address is defined by the combination of an IP address a transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the transport protocol). and an SCTP port number (where SCTP is the transport protocol).
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated
associated DATA chunk) that has been received by the endpoint but DATA chunk) that has been received by the endpoint but for which
for which an acknowledgement has not yet been sent. Or in the an acknowledgement has not yet been sent. Or in the opposite
opposite case, for a packet that has been sent but no case, for a packet that has been sent but no acknowledgement has
acknowledgement has been received. been received.
o Unordered Message: Unordered messages are "unordered" with respect Unordered Message: Unordered messages are "unordered" with respect
to any other message; this includes both other unordered messages to any other message; this includes both other unordered messages
as well as other ordered messages. An unordered message might be as well as other ordered messages. An unordered message might be
delivered prior to or later than ordered messages sent on the same delivered prior to or later than ordered messages sent on the same
stream. stream.
o User message: The unit of data delivery across the interface User message: The unit of data delivery across the interface between
between SCTP and its user. SCTP and its user.
o Verification Tag: A 32-bit unsigned integer that is randomly Verification Tag: A 32-bit unsigned integer that is randomly
generated. The Verification Tag provides a key that allows a generated. The Verification Tag provides a key that allows a
receiver to verify that the SCTP packet belongs to the current receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous association and is not an old or stale packet from a previous
association. association.
1.4. Abbreviations 1.4. Abbreviations
MAC - Message Authentication Code [RFC2104] MAC Message Authentication Code [RFC2104]
RTO Retransmission Timeout
RTO - Retransmission Timeout RTT Round-Trip Time
RTTVAR Round-Trip Time Variation
RTT - Round-Trip Time SCTP Stream Control Transmission Protocol
SRTT Smoothed RTT
RTTVAR - Round-Trip Time Variation TCB Transmission Control Block
TLV Type-Length-Value coding format
SCTP - Stream Control Transmission Protocol TSN Transmission Sequence Number
ULP Upper-Layer Protocol
SRTT - Smoothed RTT
TCB - Transmission Control Block
TLV - Type-Length-Value coding format
TSN - Transmission Sequence Number
ULP - Upper-Layer Protocol
1.5. Functional View of SCTP 1.5. Functional View of SCTP
The SCTP transport service can be decomposed into a number of The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the functions. These are depicted in Figure 2 and explained in the
remainder of this section. remainder of this section.
SCTP User Application SCTP User Application
----------------------------------------------------- -----------------------------------------------------
_____________ ____________________ _____________ ____________________
| | | Sequenced Delivery | | | | Sequenced Delivery |
| Association | | within Streams | | Association | | within Streams |
| | |____________________| | | |____________________|
| Startup | | Startup |
| | ____________________________ | | ____________________________
| and | | User Data Fragmentation | | and | | User Data Fragmentation |
| | |____________________________| | | |____________________________|
| Takedown | | Takedown |
| | ____________________________ | | ____________________________
| | | Acknowledgement | | | | Acknowledgement |
| | | and | | | | and |
| | | Congestion Avoidance | | | | Congestion Avoidance |
| | |____________________________| | | |____________________________|
| | | |
| | ____________________________ | | ____________________________
| | | Chunk Bundling | | | | Chunk Bundling |
| | |____________________________| | | |____________________________|
| | | |
| | ________________________________ | | ________________________________
| | | Packet Validation | | | | Packet Validation |
| | |________________________________| | | |________________________________|
| | | |
| | ________________________________ | | ________________________________
| | | Path Management | | | | Path Management |
|_____________| |________________________________| |_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service Figure 2: Functional View of the SCTP Transport Service
1.5.1. Association Startup and Takedown 1.5.1. Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 10). description of the ASSOCIATE (or SEND) primitive in Section 10).
A cookie mechanism, similar to one described by Karn and Simpson in A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522], is employed during the initialization to provide [RFC2522], is employed during the initialization to provide
protection against synchronization attacks. The cookie mechanism protection against synchronization attacks. The cookie mechanism
uses a four-way handshake, the last two legs of which are allowed to uses a four-way handshake, the last two legs of which are allowed to
skipping to change at page 13, line 25 skipping to change at page 13, line 26
The term "stream" is used in SCTP to refer to a sequence of user The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document, a byte is assumed to be 8 bits). bytes (in this document, a byte is assumed to be 8 bits).
The SCTP user can specify at association startup time the number of The SCTP user can specify at association startup time the number of
streams to be supported by the association. This number is streams to be supported by the association. This number is
negotiated with the remote end (see Section 5.1.1). User messages negotiated with the remote end (see Section 5.1.1). User messages
are associated with stream numbers (SEND, RECEIVE primitives, Section are associated with stream numbers (SEND, RECEIVE primitives,
10). Internally, SCTP assigns a Stream Sequence Number to each Section 10). Internally, SCTP assigns a Stream Sequence Number to
message passed to it by the SCTP user. On the receiving side, SCTP each message passed to it by the SCTP user. On the receiving side,
ensures that messages are delivered to the SCTP user in sequence SCTP ensures that messages are delivered to the SCTP user in sequence
within a given stream. However, while one stream may be blocked within a given stream. However, while one stream may be blocked
waiting for the next in-sequence user message, delivery from other waiting for the next in-sequence user message, delivery from other
streams may proceed. streams may proceed.
SCTP provides a mechanism for bypassing the sequenced delivery SCTP provides a mechanism for bypassing the sequenced delivery
service. User messages sent using this mechanism are delivered to service. User messages sent using this mechanism are delivered to
the SCTP user as soon as they are received. the SCTP user as soon as they are received.
1.5.3. User Data Fragmentation 1.5.3. User Data Fragmentation
skipping to change at page 16, line 8 skipping to change at page 16, line 8
2*32 - 1 is TSN = 0. 2*32 - 1 is TSN = 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document use normal All other arithmetic and comparisons in this document use normal
arithmetic. arithmetic.
1.7. Changes from RFC 4960 1.7. Changes from RFC 4960
SCTP was originally defined in [RFC4960], which this document SCTP was originally defined in [RFC4960], which this document
obsoletes, if approved. In this current revision no changes other obsoletes, if approved. In this current revision no changes other
than formatting changes are present. than formatting changes are present.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. SCTP Packet Format 3. SCTP Packet Format
An SCTP packet is composed of a common header and chunks. A chunk An SCTP packet is composed of a common header and chunks. A chunk
contains either control information or user data. contains either control information or user data.
The SCTP packet format is shown below: The SCTP packet format is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header | | Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 | | Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n | | Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple chunks can be bundled into one SCTP packet up to the MTU Multiple chunks can be bundled into one SCTP packet up to the MTU
size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks.
These chunks MUST NOT be bundled with any other chunk in a packet. These chunks MUST NOT be bundled with any other chunk in a packet.
See Section 6.10 for more details on chunk bundling. See Section 6.10 for more details on chunk bundling.
If a user data message doesn't fit into one SCTP packet it can be If a user data message doesn't fit into one SCTP packet it can be
fragmented into multiple chunks using the procedure defined in fragmented into multiple chunks using the procedure defined in
Section 6.9. Section 6.9.
All integer fields in an SCTP packet MUST be transmitted in network All integer fields in an SCTP packet MUST be transmitted in network
byte order, unless otherwise stated. byte order, unless otherwise stated.
3.1. SCTP Common Header Field Descriptions 3.1. SCTP Common Header Field Descriptions
SCTP Common Header Format
SCTP Common Header Format 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number | | Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag | | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer) Source Port Number: 16 bits (unsigned integer)
This is the SCTP sender's port number. It can be used by the This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP receiver in combination with the source IP address, the SCTP
destination port, and possibly the destination IP address to destination port, and possibly the destination IP address to
identify the association to which this packet belongs. The port identify the association to which this packet belongs. The port
number 0 MUST NOT be used. number 0 MUST NOT be used.
Destination Port Number: 16 bits (unsigned integer) Destination Port Number: 16 bits (unsigned integer)
skipping to change at page 17, line 42 skipping to change at page 17, line 39
port number 0 MUST NOT be used. port number 0 MUST NOT be used.
Verification Tag: 32 bits (unsigned integer) Verification Tag: 32 bits (unsigned integer)
The receiver of this packet uses the Verification Tag to validate The receiver of this packet uses the Verification Tag to validate
the sender of this SCTP packet. On transmit, the value of this the sender of this SCTP packet. On transmit, the value of this
Verification Tag MUST be set to the value of the Initiate Tag Verification Tag MUST be set to the value of the Initiate Tag
received from the peer endpoint during the association received from the peer endpoint during the association
initialization, with the following exceptions: initialization, with the following exceptions:
- A packet containing an INIT chunk MUST have a zero Verification * A packet containing an INIT chunk MUST have a zero Verification
Tag. Tag.
- A packet containing a SHUTDOWN COMPLETE chunk with the T bit * A packet containing a SHUTDOWN COMPLETE chunk with the T bit
set MUST have the Verification Tag copied from the packet with set MUST have the Verification Tag copied from the packet with
the SHUTDOWN ACK chunk. the SHUTDOWN ACK chunk.
- A packet containing an ABORT chunk may have the verification * A packet containing an ABORT chunk may have the verification
tag copied from the packet that caused the ABORT to be sent. tag copied from the packet that caused the ABORT to be sent.
For details see Section 8.4 and Section 8.5. For details see Section 8.4 and Section 8.5.
An INIT chunk MUST be the only chunk in the SCTP packet carrying it. An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
Checksum: 32 bits (unsigned integer) Checksum: 32 bits (unsigned integer)
This field contains the checksum of this SCTP packet. Its This field contains the checksum of this SCTP packet. Its
calculation is discussed in Section 6.8. SCTP uses the CRC32c calculation is discussed in Section 6.8. SCTP uses the CRC32c
algorithm as described in Appendix B for calculating the checksum. algorithm as described in Appendix B for calculating the checksum.
3.2. Chunk Field Descriptions 3.2. Chunk Field Descriptions
The figure below illustrates the field format for the chunks to be The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet. Each chunk is formatted with a Chunk transmitted in the SCTP packet. Each chunk is formatted with a Chunk
Type field, a chunk-specific Flag field, a Chunk Length field, and a Type field, a chunk-specific Flag field, a Chunk Length field, and a
Value field. Value field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length | | Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Chunk Value / / Chunk Value /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer) Chunk Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the This field identifies the type of information contained in the
Chunk Value field. It takes a value from 0 to 254. The value of Chunk Value field. It takes a value from 0 to 254. The value of
255 is reserved for future use as an extension field. 255 is reserved for future use as an extension field.
The values of Chunk Types are defined as follows: The values of Chunk Types are defined as follows:
ID Value Chunk Type ID Value Chunk Type
----- ---------- ----- ----------
0 - Payload Data (DATA) 0 - Payload Data (DATA)
1 - Initiation (INIT) 1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK) 2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK) 3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT) 4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT) 6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN) 7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK) 8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR) 9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO) 10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK) 11 - Cookie Acknowledgement (COOKIE ACK)
12 - Reserved for Explicit Congestion Notification Echo 12 - Reserved for Explicit Congestion Notification Echo
(ECNE) (ECNE)
13 - Reserved for Congestion Window Reduced (CWR) 13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE) 14 - Shutdown Complete (SHUTDOWN COMPLETE)
15 to 62 - available 15 to 62 - available
63 - reserved for IETF-defined Chunk Extensions 63 - reserved for IETF-defined Chunk Extensions
64 to 126 - available 64 to 126 - available
127 - reserved for IETF-defined Chunk Extensions 127 - reserved for IETF-defined Chunk Extensions
128 to 190 - available 128 to 190 - available
191 - reserved for IETF-defined Chunk Extensions 191 - reserved for IETF-defined Chunk Extensions
192 to 254 - available 192 to 254 - available
255 - reserved for IETF-defined Chunk Extensions 255 - reserved for IETF-defined Chunk Extensions
Chunk Types are encoded such that the highest-order 2 bits specify Chunk Types are encoded such that the highest-order 2 bits specify
the action that must be taken if the processing endpoint does not the action that must be taken if the processing endpoint does not
recognize the Chunk Type. recognize the Chunk Type.
00 - Stop processing this SCTP packet and discard it, do not 00 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it. process any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not 01 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it, and report the process any further chunks within it, and report the
unrecognized chunk in an 'Unrecognized Chunk Type'. unrecognized chunk in an 'Unrecognized Chunk Type'.
10 - Skip this chunk and continue processing. 10 - Skip this chunk and continue processing.
11 - Skip this chunk and continue processing, but report in an 11 - Skip this chunk and continue processing, but report in an
ERROR chunk using the 'Unrecognized Chunk Type' cause of ERROR chunk using the 'Unrecognized Chunk Type' cause of
error. error.
Note: The ECNE and CWR chunk types are reserved for future use of Note: The ECNE and CWR chunk types are reserved for future use of
Explicit Congestion Notification (ECN); see Appendix A. Explicit Congestion Notification (ECN); see Appendix A.
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 Type field. Unless otherwise specified, they are set to 0 Chunk Type field. Unless otherwise specified, they are set to 0
on transmit and are ignored on receipt. on transmit and are ignored on receipt.
skipping to change at page 20, line 30 skipping to change at page 20, line 25
dependent on the Chunk Type. dependent on the Chunk Type.
The total length of a chunk (including Type, Length, and Value The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, and this padding is not included in the Chunk Length zero bytes, and this padding is not included in the Chunk Length
field. The sender MUST NOT pad with more than 3 bytes. The receiver field. The sender MUST NOT pad with more than 3 bytes. The receiver
MUST ignore the padding bytes. MUST ignore the padding bytes.
SCTP-defined chunks are described in detail in Section 3.3. The SCTP-defined chunks are described in detail in Section 3.3. The
guidelines for IETF-defined chunk extensions can be found in Section guidelines for IETF-defined chunk extensions can be found in
14.1 of this document. Section 14.1 of this document.
3.2.1. Optional/Variable-Length Parameter Format 3.2.1. Optional/Variable-Length Parameter Format
Chunk values of SCTP control chunks consist of a chunk-type-specific Chunk values of SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters. The header of required fields, followed by zero or more parameters. The
optional and variable-length parameters contained in a chunk are optional and variable-length parameters contained in a chunk are
defined in a Type-Length-Value format as shown below. defined in a Type-Length-Value format as shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length | | Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Parameter Value / / Parameter Value /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Parameter Type: 16 bits (unsigned integer) Chunk Parameter Type: 16 bits (unsigned integer)
The Type field is a 16-bit identifier of the type of parameter. The Type field is a 16-bit identifier of the type of parameter.
It takes a value of 0 to 65534. It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions. The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific SCTP chunk Values other than those defined in specific SCTP chunk
descriptions are reserved for use by IETF. descriptions are reserved for use by IETF.
skipping to change at page 21, line 39 skipping to change at page 21, line 34
the parameter is not a multiple of 4 bytes, the sender pads the the parameter is not a multiple of 4 bytes, the sender pads the
parameter at the end (i.e., after the Parameter Value field) with parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is not included in the all zero bytes. The length of the padding is not included in the
Parameter Length field. A sender MUST NOT pad with more than 3 Parameter Length field. A sender MUST NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes. bytes. The receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order 2 bits The Parameter Types are encoded such that the highest-order 2 bits
specify the action that must be taken if the processing endpoint specify the action that must be taken if the processing endpoint
does not recognize the Parameter Type. does not recognize the Parameter Type.
00 - Stop processing this parameter; do not process any further 00 - Stop processing this parameter; do not process any further
parameters within this chunk. parameters within this chunk.
01 - Stop processing this parameter, do not process any further 01 - Stop processing this parameter, do not process any further
parameters within this chunk, and report the unrecognized parameters within this chunk, and report the unrecognized
parameter in an 'Unrecognized Parameter', as described in parameter in an 'Unrecognized Parameter', as described in
Section 3.2.2. Section 3.2.2.
10 - Skip this parameter and continue processing. 10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the 11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter', as unrecognized parameter in an 'Unrecognized Parameter', as
described in Section 3.2.2. described in Section 3.2.2.
Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk
is sent. In the 00 or 01 case, the processing of the parameters is sent. In the 00 or 01 case, the processing of the parameters
after the unknown parameter is canceled, but no processing already after the unknown parameter is canceled, but no processing already
done is rolled back. done is rolled back.
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
defined in Section 14.2. Note that a parameter type MUST be unique defined in Section 14.2. Note that a parameter type MUST be unique
across all chunks. For example, the parameter type '5' is used to across all chunks. For example, the parameter type '5' is used to
skipping to change at page 23, line 9 skipping to change at page 23, line 5
first chunk. first chunk.
3.3. SCTP Chunk Definitions 3.3. SCTP Chunk Definitions
This section defines the format of the different SCTP chunk types. This section defines the format of the different SCTP chunk types.
3.3.1. Payload Data (DATA) (0) 3.3.1. Payload Data (DATA) (0)
The following format MUST be used for the DATA chunk: The following format MUST be used for the DATA chunk:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length | | Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN | | TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n | | Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier | | Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream S) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits Reserved: 5 bits
Should be set to all '0's and ignored by the receiver. Should be set to all '0's and ignored by the receiver.
U bit: 1 bit U bit: 1 bit
The (U)nordered bit, if set to '1', indicates that this is an The (U)nordered bit, if set to '1', indicates that this is an
unordered DATA chunk, and there is no Stream Sequence Number unordered DATA chunk, and there is no Stream Sequence Number
assigned to this DATA chunk. Therefore, the receiver MUST ignore assigned to this DATA chunk. Therefore, the receiver MUST ignore
skipping to change at page 24, line 9 skipping to change at page 24, line 5
E bit: 1 bit E bit: 1 bit
The (E)nding fragment bit, if set, indicates the last fragment of The (E)nding fragment bit, if set, indicates the last fragment of
a user message. a user message.
An unfragmented user message shall have both the B and E bits set to An unfragmented user message shall have both the B and E bits set to
'1'. Setting both B and E bits to '0' indicates a middle fragment of '1'. Setting both B and E bits to '0' indicates a middle fragment of
a multi-fragment user message, as summarized in the following table: a multi-fragment user message, as summarized in the following table:
B E Description +---+---+-------------------------------------------+
============================================================ | B | E | Description |
| 1 0 | First piece of a fragmented user message | +---+---+-------------------------------------------+
+----------------------------------------------------------+ | 1 | 0 | First piece of a fragmented user message |
| 0 0 | Middle piece of a fragmented user message | +---+---+-------------------------------------------+
+----------------------------------------------------------+ | 0 | 0 | Middle piece of a fragmented user message |
| 0 1 | Last piece of a fragmented user message | +---+---+-------------------------------------------+
+----------------------------------------------------------+ | 0 | 1 | Last piece of a fragmented user message |
| 1 1 | Unfragmented message | +---+---+-------------------------------------------+
============================================================ | 1 | 1 | Unfragmented message |
| Table 1: Fragment Description Flags | +---+---+-------------------------------------------+
============================================================
Table 1: Fragment Description Flags
When a user message is fragmented into multiple chunks, the TSNs are When a user message is fragmented into multiple chunks, the TSNs are
used by the receiver to reassemble the message. This means that the used by the receiver to reassemble the message. This means that the
TSNs for each fragment of a fragmented user message MUST be strictly TSNs for each fragment of a fragmented user message MUST be strictly
sequential. sequential.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the User Data field the beginning of the type field to the end of the User Data field
skipping to change at page 26, line 5 skipping to change at page 25, line 34
This is the payload user data. The implementation MUST pad the This is the payload user data. The implementation MUST pad the
end of the data to a 4-byte boundary with all-zero bytes. Any end of the data to a 4-byte boundary with all-zero bytes. Any
padding MUST NOT be included in the Length field. A sender MUST padding MUST NOT be included in the Length field. A sender MUST
never add more than 3 bytes of padding. never add more than 3 bytes of padding.
3.3.2. Initiation (INIT) (1) 3.3.2. Initiation (INIT) (1)
This chunk is used to initiate an SCTP association between two This chunk is used to initiate an SCTP association between two
endpoints. The format of the INIT chunk is shown below: endpoints. The format of the INIT chunk is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Chunk Flags | Chunk Length | | Type = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag | | Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) | | Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams | | Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN | | Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Optional/Variable-Length Parameters / / Optional/Variable-Length Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless otherwise The INIT chunk contains the following parameters. Unless otherwise
noted, each parameter MUST only be included once in the INIT chunk. noted, each parameter MUST only be included once in the INIT chunk.
Fixed Parameters Status Fixed Parameters Status
---------------------------------------------- ----------------------------------------------
Initiate Tag Mandatory Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory Advertised Receiver Window Credit Mandatory
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
------------------------------------------------------------- -------------------------------------------------------------
IPv4 Address (Note 1) Optional 5 IPv6 Address IPv4 Address (Note 1) Optional 5 IPv6 Address
(Note 1) Optional 6 Cookie Preservative (Note 1) Optional 6 Cookie Preservative
Optional 9 Reserved for ECN Capable (Note 2) Optional Optional 9 Reserved for ECN Capable (Note 2) Optional
32768 (0x8000) Host Name Address (Note 3) Optional 32768 (0x8000) Host Name Address (Note 3) Optional
11 Supported Address Types (Note 4) Optional 12 11 Supported Address Types (Note 4) Optional 12
Note 1: The INIT chunks can contain multiple addresses that can be Note 1: The INIT chunks can contain multiple addresses that can 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: An INIT chunk MUST NOT contain more than one Host Name Note 3: An INIT chunk MUST NOT contain more than one Host Name
Address parameter. Moreover, the sender of the INIT MUST NOT combine Address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name Address in the INIT. The any other address types with the Host Name Address in the INIT. The
skipping to change at page 28, line 32 skipping to change at page 28, line 16
the Initiate Tag field. the Initiate Tag field.
3.3.2.1. Optional/Variable-Length Parameters in INIT 3.3.2.1. Optional/Variable-Length Parameters in INIT
The following parameters follow the Type-Length-Value format as The following parameters follow the Type-Length-Value format as
defined in Section 3.2.1. Any Type-Length-Value fields MUST come defined in Section 3.2.1. Any Type-Length-Value fields MUST come
after the fixed-length fields defined in the previous section. after the fixed-length fields defined in the previous section.
IPv4 Address Parameter (5) IPv4 Address Parameter (5)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 8 | | Type = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer) IPv4 Address: 32 bits (unsigned integer)
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 Parameter (6) IPv6 Address Parameter (6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 | | Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bits (unsigned integer) IPv6 Address: 128 bits (unsigned integer)
Contains an IPv6 [RFC2460] address of the sending endpoint. It is Contains an IPv6 [RFC2460] address of the sending endpoint. It is
binary encoded. binary encoded.
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291],
but should instead use an IPv4 Address parameter for an IPv4 but should instead use an IPv4 Address parameter for an IPv4
address. address.
skipping to change at page 30, line 10 skipping to change at page 29, line 37
Note that not using any IP Address parameters in the INIT and INIT Note that not using any IP Address parameters in the INIT and INIT
ACK is an alternative to make an association more likely to work ACK is an alternative to make an association more likely to work
across a NAT box. across a NAT box.
Cookie Preservative (9) Cookie Preservative (9)
The sender of the INIT shall use this parameter to suggest to the The sender of the INIT shall use this parameter to suggest to the
receiver of the INIT for a longer life-span of the State Cookie. receiver of the INIT for a longer life-span of the State Cookie.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 8 | | Type = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-Span Increment (msec.) | | Suggested Cookie Life-Span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-Span Increment: 32 bits (unsigned integer) Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)
This parameter indicates to the receiver how much increment in This parameter indicates to the receiver how much increment in
milliseconds the sender wishes the receiver to add to its default milliseconds the sender wishes the receiver to add to its default
cookie life-span. cookie life-span.
This optional parameter should be added to the INIT chunk by the This optional parameter should be added to the INIT chunk by the
sender when it reattempts establishing an association with a peer sender when it reattempts establishing an association with a peer
to which its previous attempt of establishing the association to which its previous attempt of establishing the association
skipping to change at page 30, line 38 skipping to change at page 30, line 16
choose to ignore the suggested cookie life-span increase for its choose to ignore the suggested cookie life-span increase for its
own security reasons. own security reasons.
Host Name Address (11) Host Name Address (11)
The sender of INIT uses this parameter to pass its Host Name (in 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 place of its IP addresses) to its peer. The peer is responsible for
resolving the name. Using this parameter might make it more likely resolving the name. Using this parameter might make it more likely
for the association to work across a NAT box. for the association to work across a NAT box.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length | | Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name / / Host Name /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name: variable length Host Name: variable length
This field contains a host name in "host name syntax" per RFC 1123 This field contains a host name in "host name syntax" per RFC 1123
Section 2.1 [RFC1123]. The method for resolving the host name is Section 2.1 [RFC1123]. The method for resolving the host name is
out of scope of SCTP. out of scope of SCTP.
Note: At least one null terminator is included in the Host Name Note: At least one null terminator is included in the Host Name
string and must be included in the length. string and must be included in the length.
Supported Address Types (12) Supported Address Types (12)
The sender of INIT uses this parameter to list all the address types The sender of INIT uses this parameter to list all the address types
it can support. it can support.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | | Type = 12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 | | Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... | | ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Address Type: 16 bits (unsigned integer) Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
3.3.3. Initiation Acknowledgement (INIT ACK) (2) 3.3.3. Initiation Acknowledgement (INIT ACK) (2)
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 and chunk. It uses two extra variable parameters: The State Cookie and
skipping to change at page 32, line 7 skipping to change at page 31, line 18
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 and chunk. It uses two extra variable parameters: The State Cookie and
the Unrecognized Parameter: the Unrecognized Parameter:
The format of the INIT ACK chunk is shown below: The format of the INIT ACK chunk is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Chunk Flags | Chunk Length | | Type = 2 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag | | Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit | | Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams | | Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN | | Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Optional/Variable-Length Parameters / / Optional/Variable-Length Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag: 32 bits (unsigned integer) Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the Initiate Tag The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits field of every SCTP packet that the INIT ACK receiver transmits
within this association. within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value. more on the selection of the Initiate Tag value.
skipping to change at page 33, line 29 skipping to change at page 32, line 43
Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD
destroy the association discarding its TCB. destroy the association discarding its TCB.
Initial TSN (I-TSN): 32 bits (unsigned integer) Initial TSN (I-TSN): 32 bits (unsigned integer)
Defines the initial TSN that the INIT ACK sender will use. The Defines the initial TSN that the INIT ACK sender will use. The
valid range is from 0 to 4294967295. This field MAY be set to the valid range is from 0 to 4294967295. This field MAY be set to the
value of the Initiate Tag field. value of the Initiate Tag field.
Fixed Parameters Status Fixed Parameters Status
---------------------------------------------- ----------------------------------------------
Initiate Tag Mandatory Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory Advertised Receiver Window Credit Mandatory
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 7 State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5 IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6 IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8 Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11 Host Name Address (Note 3) Optional 11
Note 1: The INIT ACK chunks can contain any number of IP address Note 1: The INIT ACK chunks can contain any number of IP address
parameters that can be IPv4 and/or IPv6 in any combination. parameters that can 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 MUST NOT contain more than one Host Name Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
Address parameter. Moreover, the sender of the INIT ACK MUST NOT Address parameter. Moreover, the sender of the INIT ACK MUST NOT
combine any other address types with the Host Name Address in the combine any other address types with the Host Name Address in the
skipping to change at page 34, line 49 skipping to change at page 34, line 16
The State Cookie and Unrecognized Parameters use the Type-Length- The State Cookie and Unrecognized Parameters use the Type-Length-
Value format as defined in Section 3.2.1 and are described below. Value format as defined in Section 3.2.1 and are described below.
The other fields are defined the same as their counterparts in the The other fields are defined the same as their counterparts in the
INIT chunk. INIT chunk.
3.3.3.1. Optional or Variable-Length Parameters 3.3.3.1. Optional or Variable-Length Parameters
State Cookie State Cookie
Parameter Type Value: 7 Parameter Type Value: 7
Parameter Length: Variable size, depending on size of Cookie. Parameter Length: Variable size, depending on size of Cookie.
Parameter Value: Parameter Value:
This parameter value MUST contain all the necessary state and This parameter value MUST contain all the necessary state and
parameter information required for the sender of this INIT ACK to parameter information required for the sender of this INIT ACK to
create the association, along with a Message Authentication Code create the association, along with a Message Authentication Code
(MAC). See Section 5.1.3 for details on State Cookie definition. (MAC). See Section 5.1.3 for details on State Cookie definition.
Unrecognized Parameter: Unrecognized Parameter:
Parameter Type Value: 8 Parameter Type Value: 8
Parameter Length: Variable size. Parameter Length: Variable size.
Parameter Value: Parameter Value:
This parameter is returned to the originator of the INIT chunk This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter that has a value when the INIT contains an unrecognized parameter that has a value
that indicates it should be reported to the sender. This that indicates it should be reported to the sender. This
parameter value field will contain unrecognized parameters copied parameter value field will contain unrecognized parameters copied
from the INIT chunk complete with Parameter Type, Length, and from the INIT chunk complete with Parameter Type, Length, and
Value fields. Value fields.
skipping to change at page 36, line 5 skipping to change at page 35, line 20
The handling of a_rwnd by the receiver of the SACK is discussed in The handling of a_rwnd by the receiver of the SACK is discussed in
detail in Section 6.2.1. detail in Section 6.2.1.
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. By definition, all TSNs in the sequence of received TSNs. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack. Cumulative TSN Ack.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |Chunk Flags | Chunk Length | | Type = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack | | Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) | | Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End | | Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ ... \ \ ... \
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End | | Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 | | Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ ... \ \ ... \
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X | | Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to all '0's on transmit and ignored on receipt. Set to all '0's on transmit and ignored on receipt.
Cumulative TSN Ack: 32 bits (unsigned integer) Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. In the case where no DATA chunk has been sequence before a gap. In the case where no DATA chunk has been
received, this value is set to the peer's Initial TSN minus one. received, this value is set to the peer's Initial TSN minus one.
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer) integer)
This field indicates the updated receive buffer space in bytes of This field indicates the updated receive buffer space in bytes of
the sender of this SACK; see Section 6.2.1 for details. the sender of this SACK; see Section 6.2.1 for details.
skipping to change at page 38, line 5 skipping to change at page 36, line 48
this offset number. This calculated TSN identifies the first TSN this offset number. This calculated TSN identifies the first TSN
in this Gap Ack Block that has been received. in this Gap Ack Block that has been received.
Gap Ack Block End: 16 bits (unsigned integer) Gap Ack Block End: 16 bits (unsigned integer)
Indicates the End offset TSN for this Gap Ack Block. To calculate Indicates the End offset TSN for this Gap Ack Block. To calculate
the actual TSN number, the Cumulative TSN Ack is added to this the actual TSN number, the Cumulative TSN Ack is added to this
offset number. This calculated TSN identifies the TSN of the last offset number. This calculated TSN identifies the TSN of the last
DATA chunk received in this Gap Ack Block. DATA chunk received in this Gap Ack Block.
For example, assume that the receiver has the following DATA chunks For example, assume that the receiver has the following DATA
newly arrived at the time when it decides to send a Selective ACK, chunks newly arrived at the time when it decides to send a
Selective ACK,
---------- ----------
| TSN=17 | | TSN=17 |
---------- ----------
| | <- still missing | | <- still missing
---------- ----------
| TSN=15 | | TSN=15 |
---------- ----------
| TSN=14 | | TSN=14 |
---------- ----------
| | <- still missing | | <- still missing
---------- ----------
| TSN=12 | | TSN=12 |
---------- ----------
| TSN=11 | | TSN=11 |
---------- ----------
| TSN=10 | | TSN=10 |
---------- ----------
then the parameter part of the SACK MUST be constructed as follows then the parameter part of the SACK MUST be constructed as follows
(assuming the new a_rwnd is set to 4660 by the sender): (assuming the new a_rwnd is set to 4660 by the sender):
+--------------------------------+ +--------------------------------+
| Cumulative TSN Ack = 12 | | Cumulative TSN Ack = 12 |
+--------------------------------+ +--------------------------------+
| a_rwnd = 4660 | | a_rwnd = 4660 |
+----------------+---------------+ +----------------+---------------+
| num of block=2 | num of dup=0 | | num of block=2 | num of dup=0 |
+----------------+---------------+ +----------------+---------------+
|block #1 strt=2 |block #1 end=3 | |block #1 strt=2 |block #1 end=3 |
+----------------+---------------+ +----------------+---------------+
|block #2 strt=5 |block #2 end=5 | |block #2 strt=5 |block #2 end=5 |
+----------------+---------------+ +----------------+---------------+
Duplicate TSN: 32 bits (unsigned integer) Duplicate TSN: 32 bits (unsigned integer)
Indicates the number of times a TSN was received in duplicate Indicates the number of times a TSN was received in duplicate
since the last SACK was sent. Every time a receiver gets a since the last SACK was sent. Every time a receiver gets a
duplicate TSN (before sending the SACK), it adds it to the list of duplicate TSN (before sending the SACK), it adds it to the list of
duplicates. The duplicate count is reinitialized to zero after duplicates. The duplicate count is reinitialized to zero after
sending each SACK. sending each SACK.
For example, if a receiver were to get the TSN 19 three times it For example, if a receiver were to get the TSN 19 three times it
skipping to change at page 39, line 14 skipping to change at page 38, line 14
3.3.5. Heartbeat Request (HEARTBEAT) (4) 3.3.5. Heartbeat Request (HEARTBEAT) (4)
An endpoint should send this chunk to its peer endpoint to probe the An endpoint should send this chunk to its peer endpoint to probe the
reachability of a particular destination transport address defined in reachability of a particular destination transport address defined in
the present association. the present association.
The parameter field contains the Heartbeat Information, which is a The parameter field contains the Heartbeat Information, which is a
variable-length opaque data structure understood only by the sender. variable-length opaque data structure understood only by the sender.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Chunk Flags | Heartbeat Length | | Type = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Heartbeat Information TLV (Variable-Length) / / Heartbeat Information TLV (Variable-Length) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
Heartbeat Length: 16 bits (unsigned integer) Heartbeat Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field. and the Heartbeat Information field.
Heartbeat Information: variable length Heartbeat Information: variable length
Defined as a variable-length parameter using the format described Defined as a variable-length parameter using the format described
in Section 3.2.1, i.e.: in Section 3.2.1, i.e.:
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Heartbeat Info Mandatory 1 Heartbeat Info Mandatory 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length | | Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-Specific Heartbeat Info / / Sender-Specific Heartbeat Info /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-Specific Heartbeat Info field should normally include The Sender-Specific Heartbeat Info field should normally include
information about the sender's current time when this HEARTBEAT information about the sender's current time when this HEARTBEAT
chunk is sent and the destination transport address to which this chunk is sent and the destination transport address to which this
HEARTBEAT is sent (see Section 8.3). This information is simply HEARTBEAT is sent (see Section 8.3). This information is simply
reflected back by the receiver in the HEARTBEAT ACK message (see reflected back by the receiver in the HEARTBEAT ACK message (see
Section 3.3.6). Note also that the HEARTBEAT message is both for Section 3.3.6). Note also that the HEARTBEAT message is both for
reachability checking and for path verification (see Section 5.4). reachability checking and for path verification (see Section 5.4).
When a HEARTBEAT chunk is being used for path verification When a HEARTBEAT chunk is being used for path verification
purposes, it MUST hold a 64-bit random nonce. purposes, it MUST hold a 64-bit random nonce.
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)
An endpoint should send this chunk to its peer endpoint as a response An endpoint should send this chunk to its peer endpoint as a response
to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always
sent to the source IP address of the IP datagram containing the sent to the source IP address of the IP datagram containing the
HEARTBEAT chunk to which this ack is responding. HEARTBEAT chunk to which this ack is responding.
The parameter field contains a variable-length opaque data structure. The parameter field contains a variable-length opaque data structure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Chunk Flags | Heartbeat Ack Length | | Type = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Heartbeat Information TLV (Variable-Length) / / Heartbeat Information TLV (Variable-Length) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
Heartbeat Ack Length: 16 bits (unsigned integer) Heartbeat Ack Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field. and the Heartbeat Information field.
Heartbeat Information: variable length Heartbeat Information: variable length
This field MUST contain the Heartbeat Information parameter of the This field MUST contain the Heartbeat Information parameter of the
Heartbeat Request to which this Heartbeat Acknowledgement is Heartbeat Request to which this Heartbeat Acknowledgement is
responding. responding.
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Heartbeat Info Mandatory 1 Heartbeat Info Mandatory 1
3.3.7. Abort Association (ABORT) (6) 3.3.7. Abort Association (ABORT) (6)
The ABORT chunk is sent to the peer of an association to close the The ABORT chunk is sent to the peer of an association to close the
association. The ABORT chunk may contain Cause Parameters to inform association. The ABORT chunk may contain Cause Parameters to inform
the receiver about the reason of the abort. DATA chunks MUST NOT be the receiver about the reason of the abort. DATA chunks MUST NOT be
bundled with ABORT. Control chunks (except for INIT, INIT ACK, and bundled with ABORT. Control chunks (except for INIT, INIT ACK, and
SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be
placed before the ABORT in the SCTP packet or they will be ignored by placed before the ABORT in the SCTP packet or they will be ignored by
the receiver. the receiver.
If an endpoint receives an ABORT with a format error or no TCB is If an endpoint receives an ABORT with a format error or no TCB is
found, it MUST silently discard it. Moreover, under any found, it MUST silently discard it. Moreover, under any
circumstances, an endpoint that receives an ABORT MUST NOT respond to circumstances, an endpoint that receives an ABORT MUST NOT respond to
that ABORT by sending an ABORT of its own. that ABORT by sending an ABORT of its own.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 |Reserved |T| Length | | Type = 6 |Reserved |T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ zero or more Error Causes / / zero or more Error Causes /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Reserved: 7 bits Reserved: 7 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
T bit: 1 bit T bit: 1 bit
The T bit is set to 0 if the sender filled in the Verification Tag The T bit is set to 0 if the sender filled in the Verification
expected by the peer. If the Verification Tag is reflected, the T Tag expected by the peer. If the Verification Tag is
bit MUST be set to 1. Reflecting means that the sent Verification reflected, the T bit MUST be set to 1. Reflecting means that
Tag is the same as the received one. the sent Verification Tag is the same as the received one.
Note: Special rules apply to this chunk for verification; please Note: Special rules apply to this chunk for verification;
see Section 8.5.1 for details. please see Section 8.5.1 for details.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present. and all the Error Cause fields present.
See Section 3.3.10 for Error Cause definitions. See Section 3.3.10 for Error Cause definitions.
3.3.8. Shutdown Association (SHUTDOWN) (7) 3.3.8. Shutdown Association (SHUTDOWN) (7)
An endpoint in an association MUST use this chunk to initiate a An endpoint in an association MUST use this chunk to initiate a
graceful close of the association with its peer. This chunk has the graceful close of the association with its peer. This chunk has the
following format. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Chunk Flags | Length = 8 | | Type = 7 | Chunk Flags | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack | | Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
Indicates the length of the parameter. Set to 8. Indicates the length of the parameter. Set to 8.
Cumulative TSN Ack: 32 bits (unsigned integer) Cumulative TSN Ack: 32 bits (unsigned integer)
skipping to change at page 43, line 5 skipping to change at page 41, line 48
Block as a renege. (See Section 6.2 for information on reneging.) Block as a renege. (See Section 6.2 for information on reneging.)
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8)
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
chunk at the completion of the shutdown process; see Section 9.2 for chunk at the completion of the shutdown process; see Section 9.2 for
details. details.
The SHUTDOWN ACK chunk has no parameters. The SHUTDOWN ACK chunk has no parameters.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Chunk Flags | Length = 4 | | Type = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
3.3.10. Operation Error (ERROR) (9) 3.3.10. Operation Error (ERROR) (9)
An endpoint sends this chunk to its peer endpoint to notify it of An endpoint sends this chunk to its peer endpoint to notify it of
certain error conditions. It contains one or more error causes. An certain error conditions. It contains one or more error causes. An
Operation Error is not considered fatal in and of itself, but may be Operation Error is not considered fatal in and of itself, but may be
used with an ABORT chunk to report a fatal condition. It has the used with an ABORT chunk to report a fatal condition. It has the
following parameters: following parameters:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Chunk Flags | Length | | Type = 9 | Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ one or more Error Causes / / one or more Error Causes /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present. and all the Error Cause fields present.
Error causes are defined as variable-length parameters using the Error causes are defined as variable-length parameters using the
format described in Section 3.2.1, that is: format described in Section 3.2.1, that is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length | | Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-Specific Information / / Cause-Specific Information /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code: 16 bits (unsigned integer) Cause Code: 16 bits (unsigned integer)
Defines the type of error conditions being reported. Defines the type of error conditions being reported.
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
1 Invalid Stream Identifier 1 Invalid Stream Identifier
2 Missing Mandatory Parameter 2 Missing Mandatory Parameter
3 Stale Cookie Error 3 Stale Cookie Error
4 Out of Resource 4 Out of Resource
5 Unresolvable Address 5 Unresolvable Address
6 Unrecognized Chunk Type 6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter 7 Invalid Mandatory Parameter
8 Unrecognized Parameters 8 Unrecognized Parameters
9 No User Data 9 No User Data
10 Cookie Received While Shutting Down 10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses 11 Restart of an Association with New Addresses
12 User Initiated Abort 12 User Initiated Abort
13 Protocol Violation 13 Protocol Violation
Cause Length: 16 bits (unsigned integer) Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields. Code, Cause Length, and Cause-Specific Information fields.
Cause-Specific Information: variable length Cause-Specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 14.3. discussed in Section 14.3.
3.3.10.1. Invalid Stream Identifier (1) 3.3.10.1. Invalid Stream Identifier (1)
skipping to change at page 45, line 13 skipping to change at page 43, line 39
discussed in Section 14.3. discussed in Section 14.3.
3.3.10.1. Invalid Stream Identifier (1) 3.3.10.1. Invalid Stream Identifier (1)
Cause of error Cause of error
--------------- ---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk Invalid Stream Identifier: Indicates endpoint received a DATA chunk
sent to a nonexistent stream. sent to a nonexistent stream.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 | | Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | (Reserved) | | Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream Identifier: 16 bits (unsigned integer) Stream Identifier: 16 bits (unsigned integer)
Contains the Stream Identifier of the DATA chunk received in Contains the Stream Identifier of the DATA chunk received in
error. error.
Reserved: 16 bits Reserved: 16 bits
This field is reserved. It is set to all 0's on transmit and This field is reserved. It is set to all 0's on transmit and
ignored on receipt. ignored on receipt.
3.3.10.2. Missing Mandatory Parameter (2) 3.3.10.2. Missing Mandatory Parameter (2)
Cause of error Cause of error
--------------- ---------------
Missing Mandatory Parameter: Indicates that one or more mandatory TLV Missing Mandatory Parameter: Indicates that one or more mandatory TLV
parameters are missing in a received INIT or INIT ACK. parameters are missing in a received INIT or INIT ACK.
skipping to change at page 45, line 37 skipping to change at page 44, line 15
ignored on receipt. ignored on receipt.
3.3.10.2. Missing Mandatory Parameter (2) 3.3.10.2. Missing Mandatory Parameter (2)
Cause of error Cause of error
--------------- ---------------
Missing Mandatory Parameter: Indicates that one or more mandatory TLV Missing Mandatory Parameter: Indicates that one or more mandatory TLV
parameters are missing in a received INIT or INIT ACK. parameters are missing in a received INIT or INIT ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 | | Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N | | Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 | | Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N | | Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Missing params: 32 bits (unsigned integer) Number of Missing params: 32 bits (unsigned integer)
This field contains the number of parameters contained in the This field contains the number of parameters contained in the
Cause-Specific Information field. Cause-Specific Information field.
Missing Param Type: 16 bits (unsigned integer) Missing Param Type: 16 bits (unsigned integer)
Each field will contain the missing mandatory parameter number. Each field will contain the missing mandatory parameter number.
3.3.10.3. Stale Cookie Error (3) 3.3.10.3. Stale Cookie Error (3)
Cause of error Cause of error
-------------- --------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired. that has expired.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 | | Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) | | Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness: 32 bits (unsigned integer) Measure of Staleness: 32 bits (unsigned integer)
This field contains the difference, in microseconds, between the This field contains the difference, in microseconds, between the
current time and the time the State Cookie expired. current time and the time the State Cookie expired.
The sender of this error cause MAY choose to report how long past The sender of this error cause MAY choose to report how long past
expiration the State Cookie is by including a non-zero value in expiration the State Cookie is by including a non-zero value in
the Measure of Staleness field. If the sender does not wish to the Measure of Staleness field. If the sender does not wish to
provide this information, it should set the Measure of Staleness provide this information, it should set the Measure of Staleness
field to the value of zero. field to the value of zero.
3.3.10.4. Out of Resource (4) 3.3.10.4. Out of Resource (4)
Cause of error Cause of error
--------------- ---------------
Out of Resource: Indicates that the sender is out of resource. This Out of Resource: Indicates 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.5. Unresolvable Address (5) 3.3.10.5. Unresolvable Address (5)
Cause of error Cause of error
--------------- ---------------
Unresolvable Address: Indicates that the sender is not able to Unresolvable Address: Indicates that the sender is not able to
resolve the specified address parameter (e.g., type of address is not resolve the specified address parameter (e.g., type of address is not
supported by the sender). This is usually sent in combination with supported by the sender). This is usually sent in combination with
or within an ABORT. or within an ABORT.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length | | Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unresolvable Address / / Unresolvable Address /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unresolvable Address: variable length Unresolvable Address: variable length
The Unresolvable Address field contains the complete Type, Length, The Unresolvable Address field contains the complete Type, Length,
and Value of the address parameter (or Host Name parameter) that and Value of the address parameter (or Host Name parameter) that
contains the unresolvable address or host name. contains the unresolvable address or host name.
3.3.10.6. Unrecognized Chunk Type (6) 3.3.10.6. Unrecognized Chunk Type (6)
Cause of error Cause of error
skipping to change at page 47, line 32 skipping to change at page 46, line 4
Unresolvable Address: variable length Unresolvable Address: variable length
The Unresolvable Address field contains the complete Type, Length, The Unresolvable Address field contains the complete Type, Length,
and Value of the address parameter (or Host Name parameter) that and Value of the address parameter (or Host Name parameter) that
contains the unresolvable address or host name. contains the unresolvable address or host name.
3.3.10.6. Unrecognized Chunk Type (6) 3.3.10.6. Unrecognized Chunk Type (6)
Cause of error Cause of error
--------------- ---------------
Unrecognized Chunk Type: This error cause is returned to the Unrecognized Chunk Type: This error cause is returned to the
originator of the chunk if the receiver does not understand the chunk originator of the chunk if the receiver does not understand the chunk
and the upper bits of the 'Chunk Type' are set to 01 or 11. and the upper bits of the 'Chunk Type' are set to 01 or 11.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length | | Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk / / Unrecognized Chunk /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk: variable length Unrecognized Chunk: variable length
The Unrecognized Chunk field contains the unrecognized chunk from The Unrecognized Chunk field contains the unrecognized chunk from
the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk
Length. Length.
3.3.10.7. Invalid Mandatory Parameter (7) 3.3.10.7. Invalid Mandatory Parameter (7)
Cause of error Cause of error
--------------- ---------------
Invalid Mandatory Parameter: This error cause is returned to the Invalid Mandatory Parameter: This error cause is returned to the
originator of an INIT or INIT ACK chunk when one of the mandatory originator of an INIT or INIT ACK chunk when one of the mandatory
parameters is set to an invalid value. parameters is set to an invalid value.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 | | Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.8. Unrecognized Parameters (8) 3.3.10.8. Unrecognized Parameters (8)
Cause of error Cause of error
--------------- ---------------
Unrecognized Parameters: This error cause is returned to the Unrecognized Parameters: This error cause is returned to the
originator of the INIT ACK chunk if the receiver does not recognize originator of the INIT ACK chunk if the receiver does not recognize
one or more Optional TLV parameters in the INIT ACK chunk. one or more Optional TLV parameters in the INIT ACK chunk.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length | | Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters / / Unrecognized Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Parameters: variable length Unrecognized Parameters: variable length
The Unrecognized Parameters field contains the unrecognized The Unrecognized Parameters field contains the unrecognized
parameters copied from the INIT ACK chunk complete with TLV. This parameters copied from the INIT ACK chunk complete with TLV. This
error cause is normally contained in an ERROR chunk bundled with error cause is normally contained in an ERROR chunk bundled with
the COOKIE ECHO chunk when responding to the INIT ACK, when the the COOKIE ECHO chunk when responding to the INIT ACK, when the
sender of the COOKIE ECHO chunk wishes to report unrecognized sender of the COOKIE ECHO chunk wishes to report unrecognized
parameters. parameters.
3.3.10.9. No User Data (9) 3.3.10.9. No User Data (9)
Cause of error Cause of error
skipping to change at page 49, line 11 skipping to change at page 47, line 17
the COOKIE ECHO chunk when responding to the INIT ACK, when the the COOKIE ECHO chunk when responding to the INIT ACK, when the
sender of the COOKIE ECHO chunk wishes to report unrecognized sender of the COOKIE ECHO chunk wishes to report unrecognized
parameters. parameters.
3.3.10.9. No User Data (9) 3.3.10.9. No User Data (9)
Cause of error Cause of error
--------------- ---------------
No User Data: This error cause is returned to the originator of a No User Data: This error cause is returned to the originator of a
DATA chunk if a received DATA chunk has no user data. DATA chunk if a received DATA chunk has no user data.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 | | Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value / / TSN value /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSN value: 32 bits (unsigned integer) TSN value: 32 bits (unsigned integer)
The TSN value field contains the TSN of the DATA chunk received The TSN value field contains the TSN of the DATA chunk received
with no user data field. with no user data field.
This cause code is normally returned in an ABORT chunk (see This cause code is normally returned in an ABORT chunk (see
Section 6.2). Section 6.2).
3.3.10.10. Cookie Received While Shutting Down (10) 3.3.10.10. Cookie Received While Shutting Down (10)
Cause of error Cause of error
--------------- ---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received while Cookie Received While Shutting Down: A COOKIE ECHO was received while
the endpoint was in the SHUTDOWN-ACK-SENT state. This error is the endpoint was in the SHUTDOWN-ACK-SENT state. This error is
usually returned in an ERROR chunk bundled with the retransmitted usually returned in an ERROR chunk bundled with the retransmitted
SHUTDOWN ACK. SHUTDOWN ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 | | Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.11. Restart of an Association with New Addresses (11) 3.3.10.11. Restart of an Association with New Addresses (11)
Cause of error Cause of error
-------------- --------------
Restart of an association with new addresses: An INIT was received on Restart of an association with new addresses: An INIT was received on
an existing association. But the INIT added addresses to the an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The association that were previously NOT part of the association. The
new addresses are listed in the error code. This ERROR is normally new addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see Section 5.2). sent as part of an ABORT refusing the INIT (see Section 5.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable | | Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs / / New Address TLVs /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV that was found Note: Each New Address TLV is an exact copy of the TLV that was found
in the INIT chunk that was new, including the Parameter Type and the in the INIT chunk that was new, including the Parameter Type and the
Parameter Length. Parameter Length.
3.3.10.12. User-Initiated Abort (12) 3.3.10.12. User-Initiated Abort (12)
Cause of error Cause of error
-------------- --------------
This error cause MAY be included in ABORT chunks that are sent This error cause MAY be included in ABORT chunks that are sent
because of an upper-layer request. The upper layer can specify an because of an upper-layer request. The upper layer can specify an
Upper Layer Abort Reason that is transported by SCTP transparently Upper Layer Abort Reason that is transported by SCTP transparently
and MAY be delivered to the upper-layer protocol at the peer. and MAY be delivered to the upper-layer protocol at the peer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable | | Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason / / Upper Layer Abort Reason /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.13. Protocol Violation (13) 3.3.10.13. Protocol Violation (13)
Cause of error Cause of error
-------------- --------------
This error cause MAY be included in ABORT chunks that are sent This error cause MAY be included in ABORT chunks that are sent
because an SCTP endpoint detects a protocol violation of the peer because an SCTP endpoint detects a protocol violation of the peer
that is not covered by the error causes described in Section 3.3.10.1 that is not covered by the error causes described in Section 3.3.10.1
to Section 3.3.10.12. An implementation MAY provide additional to Section 3.3.10.12. An implementation MAY provide additional
information specifying what kind of protocol violation has been information specifying what kind of protocol violation has been
detected. detected.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable | | Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information / / Additional Information /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.11. Cookie Echo (COOKIE ECHO) (10) 3.3.11. Cookie Echo (COOKIE ECHO) (10)
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 DATA chunk the initialization process. This chunk MUST precede any DATA 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 packet. chunks in the same packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length | | Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cookie / / Cookie /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bit Chunk Flags: 8 bit
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the 4 bytes of Set to the size of the chunk in bytes, including the 4 bytes of
the chunk header and the size of the cookie. the chunk header and the size of the cookie.
skipping to change at page 52, line 27 skipping to change at page 50, line 22
State Cookie parameter to become a COOKIE ECHO chunk. State Cookie parameter to become a COOKIE ECHO chunk.
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
This chunk is used only during the initialization of an association. This chunk is used only during the initialization of an association.
It is used to acknowledge the receipt of a COOKIE ECHO chunk. This It is used to acknowledge the receipt of a COOKIE ECHO chunk. This
chunk MUST precede any DATA or SACK chunk sent within the chunk MUST precede any DATA or SACK chunk sent within the
association, but MAY be bundled with one or more DATA chunks or SACK association, but MAY be bundled with one or more DATA chunks or SACK
chunk's in the same SCTP packet. chunk's in the same SCTP packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 | | Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14)
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
ACK chunk at the completion of the shutdown process; see Section 9.2 ACK chunk at the completion of the shutdown process; see Section 9.2
for details. for details.
The SHUTDOWN COMPLETE chunk has no parameters. The SHUTDOWN COMPLETE chunk has no parameters.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 |Reserved |T| Length = 4 | | Type = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Reserved: 7 bits Reserved: 7 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
T bit: 1 bit T bit: 1 bit
The T bit is set to 0 if the sender filled in the Verification
The T bit is set to 0 if the sender filled in the Verification Tag Tag expected by the peer. If the Verification Tag is
expected by the peer. If the Verification Tag is reflected, the T reflected, the T bit MUST be set to 1. Reflecting means that
bit MUST be set to 1. Reflecting means that the sent Verification the sent Verification Tag is the same as the received one.
Tag is the same as the received one.
Note: Special rules apply to this chunk for verification, please see Note: Special rules apply to this chunk for verification, please see
Section 8.5.1 for details. Section 8.5.1 for details.
4. SCTP Association State Diagram 4. SCTP Association State Diagram
During the life time of an SCTP association, the SCTP endpoint's During the life time of an SCTP association, the SCTP endpoint's
association progresses from one state to another in response to association progresses from one state to another in response to
various events. The events that may potentially advance an various events. The events that may potentially advance an
association's state include: association's state include:
skipping to change at page 55, line 4 skipping to change at page 52, line 22
| | COOKIE-ECHOED| (3) | | COOKIE-ECHOED| (3)
| +--------------+ | +--------------+
| | | |
| | rcv COOKIE ACK | | rcv COOKIE ACK
| | ----------------- | | -----------------
| | stop cookie timer | | stop cookie timer
v v v v
+---------------+ +---------------+
| ESTABLISHED | | ESTABLISHED |
+---------------+ +---------------+
|
(from the ESTABLISHED state only) |
| /----+------------\
| [SHUTDOWN] / \
/--------+--------\ -------------------| |
[SHUTDOWN] / \ check outstanding | |
-------------------| | DATA chunks | |
check outstanding | | v |
DATA chunks | | +---------+ |
v | |SHUTDOWN-| | rcv SHUTDOWN
+---------+ | |PENDING | |------------------
|SHUTDOWN-| | rcv SHUTDOWN +---------+ | check outstanding
|PENDING | |------------------ | | DATA chunks
+---------+ | check outstanding No more outstanding | |
| | DATA chunks ---------------------| |
No more outstanding | | snd SHUTDOWN | |
---------------------| | strt shutdown timer | |
snd SHUTDOWN | | v v
strt shutdown timer | | +---------+ +-----------+
v v (4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
+---------+ +-----------+ |SENT | | RECEIVED |
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6) +---------+ +-----------+
|SENT | | RECEIVED | | \ |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ | (A) rcv SHUTDOWN ACK | \ |
----------------------| \ | ----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN | stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) | send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ | delete TCB | \ |
| \ | No more outstanding | \ | No more outstanding
| \ |----------------- | \ |-----------------
| \ | send SHUTDOWN ACK | \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer (B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ | ----------------------| \ |
skipping to change at page 57, line 31 skipping to change at page 54, line 44
Once the association is established, unidirectional streams are open Once the association is established, unidirectional streams are open
for data transfer on both ends (see Section 5.1.1). for data transfer on both ends (see Section 5.1.1).
5.1. Normal Establishment of an Association 5.1. Normal Establishment of an Association
The initialization process consists of the following steps (assuming The initialization process consists of the following steps (assuming
that SCTP endpoint "A" tries to set up an association with SCTP that SCTP endpoint "A" tries to set up an association with SCTP
endpoint "Z" and "Z" accepts the new association): endpoint "Z" and "Z" accepts the new association):
A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must
provide its Verification Tag (Tag_A) in the Initiate Tag field. provide its Verification Tag (Tag_A) in the Initiate Tag field.
Tag_A SHOULD be a random number in the range of 1 to 4294967295 Tag_A SHOULD be a random number in the range of 1 to 4294967295
(see Section 5.3.1 for Tag value selection). After sending the (see Section 5.3.1 for Tag value selection). After sending the
INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT
state. state.
B) "Z" shall respond immediately with an INIT ACK chunk. The B) "Z" shall respond immediately with an INIT ACK chunk. The
destination IP address of the INIT ACK MUST be set to the source destination IP address of the INIT ACK MUST be set to the source
IP address of the INIT to which this INIT ACK is responding. In IP address of the INIT to which this INIT ACK is responding. In
the response, besides filling in other parameters, "Z" must set the response, besides filling in other parameters, "Z" must set
the Verification Tag field to Tag_A, and also provide its own the Verification Tag field to Tag_A, and also provide its own
Verification Tag (Tag_Z) in the Initiate Tag field. Verification Tag (Tag_Z) in the Initiate Tag field.
Moreover, "Z" MUST generate and send along with the INIT ACK a Moreover, "Z" MUST generate and send along with the INIT ACK a
State Cookie. See Section 5.1.3 for State Cookie generation. State Cookie. See Section 5.1.3 for State Cookie generation.
Note: After sending out INIT ACK with the State Cookie parameter, Note: After sending out INIT ACK with the State Cookie parameter,
"Z" MUST NOT allocate any resources or keep any states for the new "Z" MUST NOT allocate any resources or keep any states for the
association. Otherwise, "Z" will be vulnerable to resource new association. Otherwise, "Z" will be vulnerable to resource
attacks. attacks.
C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1- C) Upon reception of the INIT ACK from "Z", "A" shall stop the
init timer and leave the COOKIE-WAIT state. "A" shall then send T1-init timer and leave the COOKIE-WAIT state. "A" shall then
the State Cookie received in the INIT ACK chunk in a COOKIE ECHO send the State Cookie received in the INIT ACK chunk in a COOKIE
chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED ECHO chunk, start the T1-cookie timer, and enter the COOKIE-
state. ECHOED state.
Note: The COOKIE ECHO chunk can be bundled with any pending Note: The COOKIE ECHO chunk can be bundled with any pending
outbound DATA chunks, but it MUST be the first chunk in the packet outbound DATA chunks, but it MUST be the first chunk in the
and until the COOKIE ACK is returned the sender MUST NOT send any packet and until the COOKIE ACK is returned the sender MUST NOT
other packets to the peer. send any other packets to the peer.
D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply
with a COOKIE ACK chunk after building a TCB and moving to the with a COOKIE ACK chunk after building a TCB and moving to the
ESTABLISHED state. A COOKIE ACK chunk may be bundled with any ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk pending DATA chunks (and/or SACK chunks), but the COOKIE ACK
MUST be the first chunk in the packet. chunk MUST be the first chunk in the packet.
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 of a Communication Up notification to the SCTP user upon reception of
valid COOKIE ECHO chunk. a valid COOKIE ECHO chunk.
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-ECHOED state to the ESTABLISHED state, stopping the T1- COOKIE-ECHOED state to the ESTABLISHED state, stopping the
cookie timer. It may also notify its ULP about the successful T1-cookie timer. It may also notify its ULP about the successful
establishment of the association with a Communication Up establishment of the association with a Communication Up
notification (see Section 10). notification (see Section 10).
An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.
They MUST be the only chunks present in the SCTP packets that carry They MUST be the only chunks present in the SCTP packets that carry
them. them.
An endpoint MUST send the INIT ACK to the IP address from which it An endpoint MUST send the INIT ACK to the IP address from which it
received the INIT. received the INIT.
Note: T1-init timer and T1-cookie timer shall follow the same rules Note: T1-init timer and T1-cookie timer shall follow the same rules
given in Section 6.3. given in Section 6.3.
skipping to change at page 59, line 47 skipping to change at page 57, line 11
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 min(local OS, identifier range for either endpoint shall be 0 to min(local OS,
remote MIS)-1. remote MIS)-1.
5.1.2. Handle Address Parameters 5.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.
A) If there are no address parameters present in the received INIT or A) If there are no address parameters present in the received INIT
INIT ACK chunk, the endpoint shall take the source IP address from or INIT ACK chunk, the endpoint shall take the source IP address
which the chunk arrives and record it, in combination with the from which the chunk arrives and record it, in combination with
SCTP source port number, as the only destination transport address the SCTP source port number, as the only destination transport
for this peer. address for this peer.
B) If there is a Host Name parameter present in the received INIT or B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP this peer by combining the resolved IP address(es) with the SCTP
source port. source port.
The endpoint MUST ignore any other IP Address parameters if they The endpoint MUST ignore any other IP Address parameters if they
are also present in the received INIT or INIT ACK chunk. are also present in the received INIT or INIT ACK chunk.
The time at which the receiver of an INIT resolves the host name The time at which the receiver of an INIT resolves the host name
has potential security implications to SCTP. If the receiver of has potential security implications to SCTP. If the receiver of
an INIT resolves the host name upon the reception of the chunk, an INIT resolves the host name upon the reception of the chunk,
and the mechanism the receiver uses to resolve the host name and the mechanism the receiver uses to resolve the host name
involves potential long delay (e.g., DNS query), the receiver may involves potential long delay (e.g., DNS query), the receiver may
open itself up to resource attacks for the period of time while it open itself up to resource attacks for the period of time while
is waiting for the name resolution results before it can build the it is waiting for the name resolution results before it can build
State Cookie and release local resources. the State Cookie and release local resources.
Therefore, in cases where the name translation involves potential Therefore, in cases where the name translation involves potential
long delay, the receiver of the INIT MUST postpone the name long delay, the receiver of the INIT MUST postpone the name
resolution till the reception of the COOKIE ECHO chunk from the resolution till the reception of the COOKIE ECHO chunk from the
peer. In such a case, the receiver of the INIT SHOULD build the peer. In such a case, the receiver of the INIT SHOULD build the
State Cookie using the received Host Name (instead of destination State Cookie using the received Host Name (instead of destination
transport addresses) and send the INIT ACK to the source IP transport addresses) and send the INIT ACK to the source IP
address from which the INIT was received. address from which the INIT was received.
The receiver of an INIT ACK shall always immediately attempt to The receiver of an INIT ACK shall always immediately attempt to
resolve the name upon the reception of the chunk. resolve the name upon the reception of the chunk.
The receiver of the INIT or INIT ACK MUST NOT send user data 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 (piggy-backed or stand-alone) to its peer until the host name is
successfully resolved. successfully resolved.
If the name resolution is not successful, the endpoint MUST If the name resolution is not successful, the endpoint MUST
immediately send an ABORT with "Unresolvable Address" error cause immediately send an ABORT with "Unresolvable Address" error cause
to its peer. The ABORT shall be sent to the source IP address to its peer. The ABORT shall be sent to the source IP address
from which the last peer packet was received. from which the last peer packet was received.
C) If there are only IPv4/IPv6 addresses present in the received INIT C) If there are only IPv4/IPv6 addresses present in the received
or INIT ACK chunk, the receiver MUST derive and record all the INIT or INIT ACK chunk, the receiver MUST derive and record all
transport addresses from the received chunk AND the source IP the transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport addresses address that sent the INIT or INIT ACK. The transport addresses
are derived by the combination of SCTP source port (from the are derived by the combination of SCTP source port (from the
common header) and the IP Address parameter(s) carried in the INIT common header) and the IP Address parameter(s) carried in the
or INIT ACK chunk and the source IP address of the IP datagram. INIT or INIT ACK chunk and the source IP address of the IP
The receiver should use only these transport addresses as datagram. The receiver should use only these transport addresses
destination transport addresses when sending subsequent packets to as destination transport addresses when sending subsequent
its peer. packets to its peer.
D) An INIT or INIT ACK chunk MUST be treated as belonging to an D) An INIT or INIT ACK chunk MUST be treated as belonging to an
already established association (or one in the process of being already established association (or one in the process of being
established) if the use of any of the valid address parameters established) if the use of any of the valid address parameters
contained within the chunk would identify an existing TCB. contained within the chunk would identify an existing TCB.
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
doesn't control the source IP address that is used for transmitting), doesn't control the source IP address that is used for transmitting),
an endpoint might need to include in its INIT or INIT ACK all an endpoint might need to include in its INIT or INIT ACK all
possible IP addresses from which packets to the peer could be possible IP addresses from which packets to the peer could be
transmitted. transmitted.
After all transport addresses are derived from the INIT or INIT ACK After all transport addresses are derived from the INIT or INIT ACK
chunk using the above rules, the endpoint shall select one of the chunk using the above rules, the endpoint shall select one of the
transport addresses as the initial primary path. transport addresses as the initial primary path.
skipping to change at page 65, line 11 skipping to change at page 62, line 5
If a COOKIE ECHO is received from an endpoint with which the receiver If a COOKIE ECHO is received from an endpoint with which the receiver
of the COOKIE ECHO has an existing association, the procedures in of the COOKIE ECHO has an existing association, the procedures in
Section 5.2 should be followed. Section 5.2 should be followed.
5.1.6. An Example of Normal Association Establishment 5.1.6. An Example of Normal Association Establishment
In the following example, "A" initiates the association and then In the following example, "A" initiates the association and then
sends a user message to "Z", then "Z" sends two user messages to "A" sends a user message to "Z", then "Z" sends two user messages to "A"
later (assuming no bundling or fragmentation occurs): later (assuming no bundling or fragmentation occurs):
Endpoint A Endpoint Z Endpoint A Endpoint Z
{app sets association with Z} {app sets association with Z}
(build TCB) (build TCB)
INIT [I-Tag=Tag_A INIT [I-Tag=Tag_A
& other info] ------\ & other info] ------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A, /-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z, / I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info] (Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB) (destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\ COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state) state)
/---- COOKIE-ACK /---- COOKIE-ACK
/ /
(Cancel T1-init timer, <-----/ (Cancel T1-init timer, <-----/
Enter ESTABLISHED state) Enter ESTABLISHED state)
{app sends 1st user data; strm 0} {app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\ Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \ (Start T3-rtx timer) \
\-> \->
/----- SACK [TSN Ack=init /----- SACK [TSN Ack=init
/ TSN_A,Block=0] / TSN_A,Block=0]
(Cancel T3-rtx timer) <------/ (Cancel T3-rtx timer) <------/
... ...
{app sends 2 messages;strm 0} {app sends 2 messages;strm 0}
/---- DATA /---- DATA
/ [TSN=init TSN_Z / [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1] <--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1, Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2] \/ Strm=0,Seq=1 & user data 2]
<------/\ <------/\
\ \
\------> \------>
Figure 4: INITIATION Example Figure 4: INITIATION Example
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
chunks are sent, the same INIT or COOKIE ECHO chunk with the same chunks are sent, the same INIT or COOKIE ECHO chunk with the same
Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
the timer restarted. This shall be repeated Max.Init.Retransmits the timer restarted. This shall be repeated Max.Init.Retransmits
times before "A" considers "Z" unreachable and reports the failure to times before "A" considers "Z" unreachable and reports the failure to
its upper layer (and thus the association enters the CLOSED state). its upper layer (and thus the association enters the CLOSED state).
When retransmitting the INIT, the endpoint MUST follow the rules When retransmitting the INIT, the endpoint MUST follow the rules
defined in Section 6.3 to determine the proper timer value. defined in Section 6.3 to determine the proper timer value.
skipping to change at page 66, line 31 skipping to change at page 63, line 24
receiver shall treat such a setup chunk as a duplicate and process it receiver shall treat such a setup chunk as a duplicate and process it
as described in this section. as described in this section.
Note: An endpoint will not receive the chunk unless the chunk was Note: An endpoint will not receive the chunk unless the chunk was
sent to an SCTP transport address and is from an SCTP transport sent to an SCTP transport address and is from an SCTP transport
address associated with this endpoint. Therefore, the endpoint address associated with this endpoint. Therefore, the endpoint
processes such a chunk as part of its current association. processes such a chunk as part of its current association.
The following scenarios can cause duplicated or unexpected chunks: The following scenarios can cause duplicated or unexpected chunks:
A) The peer has crashed without being detected, restarted itself, and A) The peer has crashed without being detected, restarted itself,
sent out a new INIT chunk trying to restore the association, and sent out a new INIT chunk trying to restore the association,
B) Both sides are trying to initialize the association at about the B) Both sides are trying to initialize the association at about the
same time, same time,
C) The chunk is from a stale packet that was used to establish the C) The chunk is from a stale packet that was used to establish the
present association or a past association that is no longer in present association or a past association that is no longer in
existence, existence,
D) The chunk is a false packet generated by an attacker, or D) The chunk is a false packet generated by an attacker, or
E) The peer never received the COOKIE ACK and is retransmitting its E) The peer never received the COOKIE ACK and is retransmitting its
COOKIE ECHO. COOKIE ECHO.
The rules in the following sections shall be applied in order to The rules in the following sections shall be applied in order to
identify and correctly handle these cases. identify and correctly handle these cases.
5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)
This usually indicates an initialization collision, i.e., each This usually indicates an initialization collision, i.e., each
endpoint is attempting, at about the same time, to establish an endpoint is attempting, at about the same time, to establish an
association with the other endpoint. association with the other endpoint.
skipping to change at page 68, line 45 skipping to change at page 65, line 33
duplicated INIT chunk. duplicated INIT chunk.
5.2.4. Handle a COOKIE ECHO when a TCB Exists 5.2.4. Handle a COOKIE ECHO when a TCB Exists
When a COOKIE ECHO chunk is received by an endpoint in any state for When a COOKIE ECHO chunk is received by an endpoint in any state for
an existing association (i.e., not in the CLOSED state) the following an existing association (i.e., not in the CLOSED state) the following
rules shall be applied: rules shall be applied:
1) Compute a MAC as described in step 1 of Section 5.1.5, 1) Compute a MAC as described in step 1 of Section 5.1.5,
2) Authenticate the State Cookie as described in step 2 of Section 2) Authenticate the State Cookie as described in step 2 of
5.1.5 (this is case C or D above). Section 5.1.5 (this is case C or D above).
3) Compare the timestamp in the State Cookie to the current time. 3) Compare the timestamp in the State Cookie to the current time.
If the State Cookie is older than the lifespan carried in the If the State Cookie is older than the lifespan carried in the
State Cookie and the Verification Tags contained in the State State Cookie and the Verification Tags contained in the State
Cookie do not match the current association's Verification Tags, Cookie do not match the current association's Verification Tags,
the packet, including the COOKIE ECHO and any DATA chunks, should the packet, including the COOKIE ECHO and any DATA chunks, should
be discarded. The endpoint also MUST transmit an ERROR chunk be discarded. The endpoint also MUST transmit an ERROR chunk
with a "Stale Cookie" error cause to the peer endpoint (this is with a "Stale Cookie" error cause to the peer endpoint (this is
case C or D in Section 5.2). case C or D in Section 5.2).
If both Verification Tags in the State Cookie match the If both Verification Tags in the State Cookie match the
Verification Tags of the current association, consider the State Verification Tags of the current association, consider the State
Cookie valid (this is case E in Section 5.2) even if the lifespan Cookie valid (this is case E in Section 5.2) even if the lifespan
is exceeded. is exceeded.
4) If the State Cookie proves to be valid, unpack the TCB into a 4) If the State Cookie proves to be valid, unpack the TCB into a
temporary TCB. temporary TCB.
5) Refer to Table 2 to determine the correct action to be taken. 5) Refer to Table 2 to determine the correct action to be taken.
+------------+------------+---------------+--------------+-------------+ +-----------+------------+---------------+----------------+--------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ | | Local Tag | Peer's Tag | Local-Tie-Tag | Peer's-Tie-Tag | Action |
| | | | | Description | +-----------+------------+---------------+----------------+--------+
+------------+------------+---------------+--------------+-------------+ | X | X | M | M | (A) |
| X | X | M | M | (A) | +-----------+------------+---------------+----------------+--------+
+------------+------------+---------------+--------------+-------------+ | M | X | A | A | (B) |
| M | X | A | A | (B) | +-----------+------------+---------------+----------------+--------+
+------------+------------+---------------+--------------+-------------+ | M | 0 | A | A | (B) |
| M | 0 | A | A | (B) | +-----------+------------+---------------+----------------+--------+
+------------+------------+---------------+--------------+-------------+ | X | M | 0 | 0 | (C) |
| X | M | 0 | 0 | (C) | +-----------+------------+---------------+----------------+--------+
+------------+------------+---------------+--------------+-------------+ | M | M | A | A | (D) |
| M | M | A | A | (D) | +-----------+------------+---------------+----------------+--------+
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB Exists | Table 2: Handling of a COOKIE ECHO when a TCB Exists
+======================================================================+
Legend: Legend:
X - Tag does not match the existing TCB. X - Tag does not match the existing TCB.
M - Tag matches the existing TCB. M - Tag matches the existing TCB.
0 - No Tie-Tag in cookie (unknown). 0 - No Tie-Tag in cookie (unknown).
A - All cases, i.e., M, X, or 0. A - All cases, i.e., M, X, or 0.
Note: For any case not shown in Table 2, the cookie should be Note: For any case not shown in Table 2, the cookie should be
silently discarded. silently discarded.
Action Action
A) In this case, the peer may have restarted. When the endpoint A) In this case, the peer may have restarted. When the endpoint
recognizes this potential 'restart', the existing session is recognizes this potential 'restart', the existing session is
treated the same as if it received an ABORT followed by a new treated the same as if it received an ABORT followed by a new
COOKIE ECHO with the following exceptions: COOKIE ECHO with the following exceptions:
- Any SCTP DATA chunks MAY be retained (this is an * Any SCTP DATA chunks MAY be retained (this is an
implementation-specific option). implementation-specific option).
- A notification of RESTART SHOULD be sent to the ULP instead of * A notification of RESTART SHOULD be sent to the ULP instead of
a "COMMUNICATION LOST" notification. a "COMMUNICATION LOST" notification.
All the congestion control parameters (e.g., cwnd, ssthresh) All the congestion control parameters (e.g., cwnd, ssthresh)
related to this peer MUST be reset to their initial values (see related to this peer MUST be reset to their initial values (see
Section 6.2.1). Section 6.2.1).
After this, the endpoint shall enter the ESTABLISHED state. After this, the endpoint shall enter the ESTABLISHED state.
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
that the peer has restarted (Action A), it MUST NOT set up a new that the peer has restarted (Action A), it MUST NOT set up a new
association but instead resend the SHUTDOWN ACK and send an ERROR association but instead resend the SHUTDOWN ACK and send an ERROR
chunk with a "Cookie Received While Shutting Down" error cause to chunk with a "Cookie Received While Shutting Down" error cause to
its peer. its peer.
B) In this case, both sides may be attempting to start an association B) In this case, both sides may be attempting to start an
at about the same time, but the peer endpoint started its INIT association at about the same time, but the peer endpoint started
after responding to the local endpoint's INIT. Thus, it may have its INIT after responding to the local endpoint's INIT. Thus, it
picked a new Verification Tag, not being aware of the previous tag may have picked a new Verification Tag, not being aware of the
it had sent this endpoint. The endpoint should stay in or enter previous tag it had sent this endpoint. The endpoint should stay
the ESTABLISHED state, but it MUST update its peer's Verification in or enter the ESTABLISHED state, but it MUST update its peer's
Tag from the State Cookie, stop any init or cookie timers that may Verification Tag from the State Cookie, stop any init or cookie
be running, and send a COOKIE ACK. timers that may be running, and send a COOKIE ACK.
C) In this case, the local endpoint's cookie has arrived late. C) In this case, the local endpoint's cookie has arrived late.
Before it arrived, the local endpoint sent an INIT and received an Before it arrived, the local endpoint sent an INIT and received
INIT ACK and finally sent a COOKIE ECHO with the peer's same tag an INIT ACK and finally sent a COOKIE ECHO with the peer's same
but a new tag of its own. The cookie should be silently tag but a new tag of its own. The cookie should be silently
discarded. The endpoint SHOULD NOT change states and should leave discarded. The endpoint SHOULD NOT change states and should
any timers running. leave any timers running.
D) When both local and remote tags match, the endpoint should enter D) When both local and remote tags match, the endpoint should enter
the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It
should stop any cookie timer that may be running and send a COOKIE should stop any cookie timer that may be running and send a
ACK. COOKIE ACK.
Note: The "peer's Verification Tag" is the tag received in the Note: The "peer's Verification Tag" is the tag received in the
Initiate Tag field of the INIT or INIT ACK chunk. Initiate Tag field of the INIT or INIT ACK chunk.
5.2.4.1. An Example of a Association Restart 5.2.4.1. An Example of a Association Restart
In the following example, "A" initiates the association after a In the following example, "A" initiates the association after a
restart has occurred. Endpoint "Z" had no knowledge of the restart restart has occurred. Endpoint "Z" had no knowledge of the restart
until the exchange (i.e., Heartbeats had not yet detected the failure until the exchange (i.e., Heartbeats had not yet detected the failure
of "A") (assuming no bundling or fragmentation occurs): of "A") (assuming no bundling or fragmentation occurs):
skipping to change at page 72, line 15 skipping to change at page 69, line 15
5.2.5. Handle Duplicate COOKIE-ACK. 5.2.5. Handle Duplicate COOKIE-ACK.
At any state other than COOKIE-ECHOED, an endpoint should silently At any state other than COOKIE-ECHOED, an endpoint should silently
discard a received COOKIE ACK chunk. discard a received COOKIE ACK chunk.
5.2.6. Handle Stale COOKIE Error 5.2.6. Handle Stale COOKIE Error
Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates
one of a number of possible events: one of a number of possible events:
A) The association failed to completely setup before the State Cookie A) The association failed to completely setup before the State
issued by the sender was processed. Cookie issued by the sender was processed.
B) An old State Cookie was processed after setup completed. B) An old State Cookie was processed after setup completed.
C) An old State Cookie is received from someone that the receiver is C) An old State Cookie is received from someone that the receiver is
not interested in having an association with and the ABORT chunk not interested in having an association with and the ABORT chunk
was lost. was lost.
When processing an ERROR chunk with a "Stale Cookie" error cause an When processing an ERROR chunk with a "Stale Cookie" error cause an
endpoint should first examine if an association is in the process of endpoint should first examine if an association is in the process of
being set up, i.e., the association is in the COOKIE-ECHOED state. being set up, i.e., the association is in the COOKIE-ECHOED state.
In all cases, if the association is not in the COOKIE-ECHOED state, In all cases, if the association is not in the COOKIE-ECHOED state,
the ERROR chunk should be silently discarded. the ERROR chunk should be silently discarded.
If the association is in the COOKIE-ECHOED state, the endpoint may If the association is in the COOKIE-ECHOED state, the endpoint may
elect one of the following three alternatives. elect one of the following three alternatives.
skipping to change at page 73, line 34 skipping to change at page 70, line 25
5.4. Path Verification 5.4. Path Verification
During association establishment, the two peers exchange a list of During association establishment, the two peers exchange a list of
addresses. In the predominant case, these lists accurately represent addresses. In the predominant case, these lists accurately represent
the addresses owned by each peer. However, it is possible that a the addresses owned by each peer. However, it is possible that a
misbehaving peer may supply addresses that it does not own. To misbehaving peer may supply addresses that it does not own. To
prevent this, the following rules are applied to all addresses of the prevent this, the following rules are applied to all addresses of the
new association: new association:
1) Any address passed to the sender of the INIT by its upper layer 1) Any address passed to the sender of the INIT by its upper layer
is automatically considered to be CONFIRMED. is automatically considered to be CONFIRMED.
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT-ACK was sent. is the one to which the INIT-ACK was sent.
3) All other addresses not covered by rules 1 and 2 are considered 3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification. UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send To probe an address for verification, an endpoint will send
HEARTBEATs including a 64-bit random nonce and a path indicator (to HEARTBEATs including a 64-bit random nonce and a path indicator (to
identify the address that the HEARTBEAT is sent to) within the identify the address that the HEARTBEAT is sent to) within the
HEARTBEAT parameter. HEARTBEAT parameter.
Upon receipt of the HEARTBEAT ACK, a verification is made that the Upon receipt of the HEARTBEAT ACK, a verification is made that the
nonce included in the HEARTBEAT parameter is the one sent to the nonce included in the HEARTBEAT parameter is the one sent to the
address indicated inside the HEARTBEAT parameter. When this match address indicated inside the HEARTBEAT parameter. When this match
occurs, the address that the original HEARTBEAT was sent to is now occurs, the address that the original HEARTBEAT was sent to is now
considered CONFIRMED and available for normal data transfer. considered CONFIRMED and available for normal data transfer.
These probing procedures are started when an association moves to the These probing procedures are started when an association moves to the
ESTABLISHED state and are ended when all paths are confirmed. ESTABLISHED state and are ended when all paths are confirmed.
In each RTO, a probe may be sent on an active UNCONFIRMED path in an In each RTO, a probe may be sent on an active UNCONFIRMED path in an
attempt to move it to the CONFIRMED state. If during this probing attempt to move it to the CONFIRMED state. If during this probing
the path becomes inactive, this rate is lowered to the normal the path becomes inactive, this rate is lowered to the normal
HEARTBEAT rate. At the expiration of the RTO timer, the error HEARTBEAT rate. At the expiration of the RTO timer, the error
counter of any path that was probed but not CONFIRMED is incremented counter of any path that was probed but not CONFIRMED is incremented
by one and subjected to path failure detection, as defined in Section by one and subjected to path failure detection, as defined in
8.2. When probing UNCONFIRMED addresses, however, the association Section 8.2. When probing UNCONFIRMED addresses, however, the
overall error count is NOT incremented. association overall error count is NOT incremented.
The number of HEARTBEATS sent at each RTO SHOULD be limited by the The number of HEARTBEATS sent at each RTO SHOULD be limited by the
HB.Max.Burst parameter. It is an implementation decision as to how HB.Max.Burst parameter. It is an implementation decision as to how
to distribute HEARTBEATS to the peer's addresses for path to distribute HEARTBEATS to the peer's addresses for path
verification. verification.
Whenever a path is confirmed, an indication MAY be given to the upper Whenever a path is confirmed, an indication MAY be given to the upper
layer. layer.
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
the following exceptions: the following exceptions:
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED o A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
address. address.
- A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address. o A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address.
- A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be o A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be
bundled with a HEARTBEAT including a nonce. An implementation bundled with a HEARTBEAT including a nonce. An implementation
that does NOT support bundling MUST NOT send a COOKIE ACK to an that does NOT support bundling MUST NOT send a COOKIE ACK to an
UNCONFIRMED address. UNCONFIRMED address.
- A COOKIE ECHO MAY be sent to an UNCONFIRMED address, but it MUST o A COOKIE ECHO MAY be sent to an UNCONFIRMED address, but it MUST
be bundled with a HEARTBEAT including a nonce, and the packet MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST
NOT exceed the path MTU. If the implementation does NOT support NOT exceed the path MTU. If the implementation does NOT support
bundling or if the bundled COOKIE ECHO plus HEARTBEAT (including bundling or if the bundled COOKIE ECHO plus HEARTBEAT (including
nonce) would exceed the path MTU, then the implementation MUST NOT nonce) would exceed the path MTU, then the implementation MUST NOT
send a COOKIE ECHO to an UNCONFIRMED address. send a COOKIE ECHO to an UNCONFIRMED address.
6. User Data Transfer 6. User Data Transfer
Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN- Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-
PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is
skipping to change at page 76, line 5 skipping to change at page 72, line 21
For transmission efficiency, SCTP defines mechanisms for bundling of For transmission efficiency, SCTP defines mechanisms for bundling of
small user messages and fragmentation of large user messages. The small user messages and fragmentation of large user messages. The
following diagram depicts the flow of user messages through SCTP. following diagram depicts the flow of user messages through SCTP.
In this section, the term "data sender" refers to the endpoint that In this section, the term "data sender" refers to the endpoint that
transmits a DATA chunk and the term "data receiver" refers to the transmits a DATA chunk and the term "data receiver" refers to the
endpoint that receives a DATA chunk. A data receiver will transmit endpoint that receives a DATA chunk. A data receiver will transmit
SACK chunks. SACK chunks.
+--------------------------+ +--------------------------+
| User Messages | | User Messages |
+--------------------------+ +--------------------------+
SCTP user ^ | SCTP user ^ |
==================|==|======================================= ==================|==|=======================================
| v (1) | v (1)
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCTP DATA Chunks | |SCTP Control Chunks | | SCTP DATA Chunks | |SCTP Control Chunks |
+------------------+ +--------------------+ +------------------+ +--------------------+
^ | ^ | ^ | ^ |
| v (2) | v (2) | v (2) | v (2)
+--------------------------+ +--------------------------+
| SCTP packets | | SCTP packets |
+--------------------------+ +--------------------------+
SCTP ^ | SCTP ^ |
===========================|==|=========================== ===========================|==|===========================
| v | v
Connectionless Packet Transfer Service (e.g., IP) Connectionless Packet Transfer Service (e.g., IP)
Notes: Figure 6: Illustration of User Data Transfer
1) When converting user messages into DATA chunks, an endpoint Notes:
will fragment user messages larger than the current association
path MTU into multiple DATA chunks. The data receiver will
normally reassemble the fragmented message from DATA chunks
before delivery to the user (see Section 6.9 for details).
2) Multiple DATA and control chunks may be bundled by the sender 1) When converting user messages into DATA chunks, an endpoint will
into a single SCTP packet for transmission, as long as the fragment user messages larger than the current association path
final size of the packet does not exceed the current path MTU. MTU into multiple DATA chunks. The data receiver will normally
The receiver will unbundle the packet back into the original reassemble the fragmented message from DATA chunks before
chunks. Control chunks MUST come before DATA chunks in the delivery to the user (see Section 6.9 for details).
packet.
Figure 6: Illustration of User Data Transfer 2) Multiple DATA and control chunks may be bundled by the sender
into a single SCTP packet for transmission, as long as the final
size of the packet does not exceed the current path MTU. The
receiver will unbundle the packet back into the original chunks.
Control chunks MUST come before DATA chunks in the packet.
The fragmentation and bundling mechanisms, as detailed in Section 6.9 The fragmentation and bundling mechanisms, as detailed in Section 6.9
and Section 6.10, are OPTIONAL to implement by the data sender, but and Section 6.10, are OPTIONAL to implement by the data sender, but
they MUST be implemented by the data receiver, i.e., an endpoint MUST they MUST be implemented by the data receiver, i.e., an endpoint MUST
properly receive and process bundled or fragmented data. properly receive and process bundled or fragmented data.
6.1. Transmission of DATA Chunks 6.1. Transmission of DATA Chunks
This document is specified as if there is a single retransmission This document is specified as if there is a single retransmission
timer per destination transport address, but implementations MAY have timer per destination transport address, but implementations MAY have
a retransmission timer for each DATA chunk. a retransmission timer for each DATA chunk.
The following general rules MUST be applied by the data sender for The following general rules MUST be applied by the data sender for
transmission and/or retransmission of outbound DATA chunks: transmission and/or retransmission of outbound DATA chunks:
A) At any given time, the data sender MUST NOT transmit new data to A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e., rwnd is 0; see Section that the peer has no buffer space (i.e., rwnd is 0; see
6.2.1). However, regardless of the value of rwnd (including if it Section 6.2.1). However, regardless of the value of rwnd
is 0), the data sender can always have one DATA chunk in flight to (including if it is 0), the data sender can always have one DATA
the receiver if allowed by cwnd (see rule B, below). This rule chunk in flight to the receiver if allowed by cwnd (see rule B,
allows the sender to probe for a change in rwnd that the sender below). This rule allows the sender to probe for a change in
missed due to the SACK's having been lost in transit from the data rwnd that the sender missed due to the SACK's having been lost in
receiver to the data sender. transit from the data receiver to the data sender.
When the receiver's advertised window is zero, this probe is When the receiver's advertised window is zero, this probe is
called a zero window probe. Note that a zero window probe SHOULD called a zero window probe. Note that a zero window probe SHOULD
only be sent when all outstanding DATA chunks have been only be sent when all outstanding DATA chunks have been
cumulatively acknowledged and no DATA chunks are in flight. Zero cumulatively acknowledged and no DATA chunks are in flight. Zero
window probing MUST be supported. window probing MUST be supported.
If the sender continues to receive new packets from the receiver If the sender continues to receive new packets from the receiver
while doing zero window probing, the unacknowledged window probes while doing zero window probing, the unacknowledged window probes
should not increment the error counter for the association or any should not increment the error counter for the association or any
destination transport address. This is because the receiver MAY destination transport address. This is because the receiver MAY
keep its window closed for an indefinite time. Refer to Section keep its window closed for an indefinite time. Refer to
6.2 on the receiver behavior when it advertises a zero window. Section 6.2 on the receiver behavior when it advertises a zero
The sender SHOULD send the first zero window probe after 1 RTO window. The sender SHOULD send the first zero window probe after
when it detects that the receiver has closed its window and SHOULD 1 RTO when it detects that the receiver has closed its window and
increase the probe interval exponentially afterwards. Also note SHOULD increase the probe interval exponentially afterwards.
that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero Also note that the cwnd SHOULD be adjusted according to
window probing does not affect the calculation of cwnd. Section 7.2.1. Zero window probing does not affect the
calculation of cwnd.
The sender MUST also have an algorithm for sending new DATA chunks The sender MUST also have an algorithm for sending new DATA
to avoid silly window syndrome (SWS) as described in [RFC0813]. chunks to avoid silly window syndrome (SWS) as described in
The algorithm can be similar to the one described in Section [RFC0813]. The algorithm can be similar to the one described in
4.2.3.4 of [RFC1122]. Section 4.2.3.4 of [RFC1122].
However, regardless of the value of rwnd (including if it is 0), However, regardless of the value of rwnd (including if it is 0),
the data sender can always have one DATA chunk in flight to the the data sender can always have one DATA chunk in flight to the
receiver if allowed by cwnd (see rule B below). This rule allows receiver if allowed by cwnd (see rule B below). This rule allows
the sender to probe for a change in rwnd that the sender missed the sender to probe for a change in rwnd that the sender missed
due to the SACK having been lost in transit from the data receiver due to the SACK having been lost in transit from the data
to the data sender. receiver to the data sender.
B) At any given time, the sender MUST NOT transmit new data to a B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data given transport address if it has cwnd or more bytes of data
outstanding to that transport address. outstanding to that transport address.
C) When the time comes for the sender to transmit, before sending new C) When the time comes for the sender to transmit, before sending
DATA chunks, the sender MUST first transmit any outstanding DATA new DATA chunks, the sender MUST first transmit any outstanding
chunks that are marked for retransmission (limited by the current DATA chunks that are marked for retransmission (limited by the
cwnd). current cwnd).
D) When the time comes for the sender to transmit new DATA chunks, D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting number of packets sent. The limit MAY be applied by adjusting
cwnd as follows: cwnd as follows:
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine. emitted by the output routine.
E) Then, the sender can send out as many new DATA chunks as rule A E) Then, the sender can send out as many new DATA chunks as rule A
and rule B allow. and rule B allow.
Multiple DATA chunks committed for transmission MAY be bundled in a Multiple DATA chunks committed for transmission MAY be bundled in a
single packet. Furthermore, DATA chunks being retransmitted MAY be single packet. Furthermore, DATA chunks being retransmitted MAY be
bundled with new DATA chunks, as long as the resulting packet size bundled with new DATA chunks, as long as the resulting packet size
does not exceed the path MTU. A ULP may request that no bundling is does not exceed the path MTU. A ULP may request that no bundling is
performed, but this should only turn off any delays that an SCTP performed, but this should only turn off any delays that an SCTP
implementation may be using to increase bundling efficiency. It does implementation may be using to increase bundling efficiency. It does
not in itself stop all bundling from occurring (i.e., in case of not in itself stop all bundling from occurring (i.e., in case of
congestion or retransmission). congestion or retransmission).
skipping to change at page 79, line 6 skipping to change at page 75, line 22
Whenever a transmission or retransmission is made to any address, if Whenever a transmission or retransmission is made to any address, if
the T3-rtx timer of that address is not currently running, the sender the T3-rtx timer of that address is not currently running, the sender
MUST start that timer. If the timer for that address is already MUST start that timer. If the timer for that address is already
running, the sender MUST restart the timer if the earliest (i.e., running, the sender MUST restart the timer if the earliest (i.e.,
lowest TSN) outstanding DATA chunk sent to that address is being lowest TSN) outstanding DATA chunk sent to that address is being
retransmitted. Otherwise, the data sender MUST NOT restart the retransmitted. Otherwise, the data sender MUST NOT restart the
timer. timer.
When starting or restarting the T3-rtx timer, the timer value must be When starting or restarting the T3-rtx timer, the timer value must be
adjusted according to the timer rules defined in Sections 6.3.2 and adjusted according to the timer rules defined in Section 6.3.2 and
6.3.3. Section 6.3.3.
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window. 1 above the beginning TSN of the current send window.
6.2. Acknowledgement on Reception of DATA Chunks 6.2. Acknowledgement on Reception of DATA Chunks
The SCTP endpoint MUST always acknowledge the reception of each valid The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk when the DATA chunk received is inside its receive window. DATA chunk when the DATA chunk received is inside its receive window.
When the receiver's advertised window is 0, the receiver MUST drop When the receiver's advertised window is 0, the receiver MUST drop
skipping to change at page 80, line 41 skipping to change at page 77, line 10
this data is for future study. this data is for future study.
The data receiver is responsible for maintaining its receive buffers. The data receiver is responsible for maintaining its receive buffers.
The data receiver SHOULD notify the data sender in a timely manner of The data receiver SHOULD notify the data sender in a timely manner of
changes in its ability to receive data. How an implementation changes in its ability to receive data. How an implementation
manages its receive buffers is dependent on many factors (e.g., manages its receive buffers is dependent on many factors (e.g.,
operating system, memory management system, amount of memory, etc.). operating system, memory management system, amount of memory, etc.).
However, the data sender strategy defined in Section 6.2.1 is based However, the data sender strategy defined in Section 6.2.1 is based
on the assumption of receiver operation similar to the following: on the assumption of receiver operation similar to the following:
A) At initialization of the association, the endpoint tells the peer A) At initialization of the association, the endpoint tells the peer
how much receive buffer space it has allocated to the association how much receive buffer space it has allocated to the association
in the INIT or INIT ACK. The endpoint sets a_rwnd to this value. in the INIT or INIT ACK. The endpoint sets a_rwnd to this value.
B) As DATA chunks are received and buffered, decrement a_rwnd by the B) As DATA chunks are received and buffered, decrement a_rwnd by the
number of bytes received and buffered. This is, in effect, number of bytes received and buffered. This is, in effect,
closing rwnd at the data sender and restricting the amount of data closing rwnd at the data sender and restricting the amount of
it can transmit. data it can transmit.
C) As DATA chunks are delivered to the ULP and released from the C) As DATA chunks are delivered to the ULP and released from the
receive buffers, increment a_rwnd by the number of bytes delivered receive buffers, increment a_rwnd by the number of bytes
to the upper layer. This is, in effect, opening up rwnd on the delivered to the upper layer. This is, in effect, opening up
data sender and allowing it to send more data. The data receiver rwnd on the data sender and allowing it to send more data. The
SHOULD NOT increment a_rwnd unless it has released bytes from its data receiver SHOULD NOT increment a_rwnd unless it has released
receive buffer. For example, if the receiver is holding bytes from its receive buffer. For example, if the receiver is
fragmented DATA chunks in a reassembly queue, it should not holding fragmented DATA chunks in a reassembly queue, it should
increment a_rwnd. not increment a_rwnd.
D) When sending a SACK, the data receiver SHOULD place the current D) When sending a SACK, the data receiver SHOULD place the current
value of a_rwnd into the a_rwnd field. The data receiver SHOULD value of a_rwnd into the a_rwnd field. The data receiver SHOULD
take into account that the data sender will not retransmit DATA take into account that the data sender will not retransmit DATA
chunks that are acked via the Cumulative TSN Ack (i.e., will drop chunks that are acked via the Cumulative TSN Ack (i.e., will drop
from its retransmit queue). from its retransmit queue).
Under certain circumstances, the data receiver may need to drop DATA Under certain circumstances, the data receiver may need to drop DATA
chunks that it has received but hasn't released from its receive chunks that it has received but hasn't released from its receive
buffers (i.e., delivered to the ULP). These DATA chunks may have buffers (i.e., delivered to the ULP). These DATA chunks may have
been acked in Gap Ack Blocks. For example, the data receiver may be been acked in Gap Ack Blocks. For example, the data receiver may be
holding data in its receive buffers while reassembling a fragmented holding data in its receive buffers while reassembling a fragmented
user message from its peer when it runs out of receive buffer space. user message from its peer when it runs out of receive buffer space.
It may drop these DATA chunks even though it has acknowledged them in It may drop these DATA chunks even though it has acknowledged them in
Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT
include them in Gap Ack Blocks in subsequent SACKs until they are include them in Gap Ack Blocks in subsequent SACKs until they are
skipping to change at page 82, line 8 skipping to change at page 78, line 8
An endpoint SHOULD NOT revoke a SACK and discard data. Only in An endpoint SHOULD NOT revoke a SACK and discard data. Only in
extreme circumstances should an endpoint use this procedure (such as extreme circumstances should an endpoint use this procedure (such as
out of buffer space). The data receiver should take into account out of buffer space). The data receiver should take into account
that dropping data that has been acked in Gap Ack Blocks can result that dropping data that has been acked in Gap Ack Blocks can result
in suboptimal retransmission strategies in the data sender and thus in suboptimal retransmission strategies in the data sender and thus
in suboptimal performance. in suboptimal performance.
The following example illustrates the use of delayed The following example illustrates the use of delayed
acknowledgements: acknowledgements:
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-rtx timer) (Start T3-rtx timer)
DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack) DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
/------- SACK [TSN Ack=8,block=0] /------- SACK [TSN Ack=8,block=0]
(cancel T3-rtx timer) <-----/ (cancel T3-rtx timer) <-----/
DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed) DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rtx timer) (Start T3-rtx timer)
... ...
{App sends 1 message; strm 1} {App sends 1 message; strm 1}
(bundle SACK with DATA) (bundle SACK with DATA)
/----- SACK [TSN Ack=9,block=0] \ /----- SACK [TSN Ack=9,block=0] \
/ DATA [TSN=6,Strm=1,Seq=2] / DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rtx timer) <------/ (Start T3-rtx timer) (cancel T3-rtx timer) <------/ (Start T3-rtx timer)
(ack delayed) (ack delayed)
(send ack) (send ack)
SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer) SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)
Figure 7: Delayed Acknowledgement Example Figure 7: Delayed Acknowledgement Example
If an endpoint receives a DATA chunk with no user data (i.e., the If an endpoint receives a DATA chunk with no user data (i.e., the
Length field is set to 16), it MUST send an ABORT with error cause Length field is set to 16), it MUST send an ABORT with error cause
set to "No User Data". set to "No User Data".
An endpoint SHOULD NOT send a DATA chunk with no user data part. An endpoint SHOULD NOT send a DATA chunk with no user data part.
6.2.1. Processing a Received SACK 6.2.1. Processing a Received SACK
Each SACK an endpoint receives contains an a_rwnd value. This value Each SACK an endpoint receives contains an a_rwnd value. This value
skipping to change at page 83, line 7 skipping to change at page 79, line 8
Ack, and Gap Ack Blocks, the data sender can develop a representation Ack, and Gap Ack Blocks, the data sender can develop a representation
of the peer's receive buffer space. of the peer's receive buffer space.
One of the problems the data sender must take into account when One of the problems the data sender must take into account when
processing a SACK is that a SACK can be received out of order. That processing a SACK is that a SACK can be received out of order. That
is, a SACK sent by the data receiver can pass an earlier SACK and be is, a SACK sent by the data receiver can pass an earlier SACK and be
received first by the data sender. If a SACK is received out of received first by the data sender. If a SACK is received out of
order, the data sender can develop an incorrect view of the peer's order, the data sender can develop an incorrect view of the peer's
receive buffer space. receive buffer space.
Since there is no explicit identifier that can be used to detect Since there is no explicit identifier that can be used to detect out-
out-of-order SACKs, the data sender must use heuristics to determine of-order SACKs, the data sender must use heuristics to determine if a
if a SACK is new. SACK is new.
An endpoint SHOULD use the following rules to calculate the rwnd, An endpoint SHOULD use the following rules to calculate the rwnd,
using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in
a received SACK. a received SACK.
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 the rwnd to the Advertised Receiver Window Credit (a_rwnd) the
peer specified in the INIT or INIT ACK. peer specified in the INIT or INIT ACK.
B) Any time a DATA chunk is transmitted (or retransmitted) to a peer, B) Any time a DATA chunk is transmitted (or retransmitted) to a
the endpoint subtracts the data size of the chunk from the rwnd of peer, the endpoint subtracts the data size of the chunk from the
that peer. rwnd of that peer.
C) Any time a DATA chunk is marked for retransmission, either via C) Any time a DATA chunk is marked for retransmission, either via
T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit
(Section 7.2.4), add the data size of those chunks to the rwnd. (Section 7.2.4), add the data size of those chunks to the rwnd.
Note: If the implementation is maintaining a timer on each DATA Note: If the implementation is maintaining a timer on each DATA
chunk, then only DATA chunks whose timer expired would be marked chunk, then only DATA chunks whose timer expired would be marked
for retransmission. for retransmission.
D) Any time a SACK arrives, the endpoint performs the following: D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack
less than the Cumulative TSN Ack Point indicates an out-of- is less than the Cumulative TSN Ack Point indicates an out-
order SACK. of-order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the number ii) Set rwnd equal to the newly received a_rwnd minus the
of bytes still outstanding after processing the Cumulative number of bytes still outstanding after processing the
TSN Ack and the Gap Ack Blocks. Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously acknowledged iii) If the SACK is missing a TSN that was previously
via a Gap Ack Block (e.g., the data receiver reneged on the acknowledged via a Gap Ack Block (e.g., the data receiver
data), then consider the corresponding DATA that might be reneged on the data), then consider the corresponding DATA
possibly missing: Count one miss indication towards Fast that might be possibly missing: Count one miss indication
Retransmit as described in Section 7.2.4, and if no towards Fast Retransmit as described in Section 7.2.4, and
retransmit timer is running for the destination address to if no retransmit timer is running for the destination
which the DATA chunk was originally transmitted, then T3-rtx address to which the DATA chunk was originally transmitted,
is started for that destination address. then T3-rtx is started for that destination address.
iv) If the Cumulative TSN Ack matches or exceeds the Fast iv) If the Cumulative TSN Ack matches or exceeds the Fast
Recovery exitpoint (Section 7.2.4), Fast Recovery is exited. Recovery exitpoint (Section 7.2.4), Fast Recovery is
exited.
6.3. Management of Retransmission Timer 6.3. Management of Retransmission Timer
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data An SCTP endpoint uses a retransmission timer T3-rtx to ensure data
delivery in the absence of any feedback from its peer. The duration delivery in the absence of any feedback from its peer. The duration
of this timer is referred to as RTO (retransmission timeout). of this timer is referred to as RTO (retransmission timeout).
When an endpoint's peer is multi-homed, the endpoint will calculate a When an endpoint's peer is multi-homed, the endpoint will calculate a
separate RTO for each different destination transport address of its separate RTO for each different destination transport address of its
peer endpoint. peer endpoint.
skipping to change at page 85, line 41 skipping to change at page 81, line 41
rule is that RTOs that do not have a high minimum value are rule is that RTOs that do not have a high minimum value are
susceptible to unnecessary timeouts [ALLMAN99]. susceptible to unnecessary timeouts [ALLMAN99].
C7) A maximum value may be placed on RTO provided it is at least C7) A maximum value may be placed on RTO provided it is at least
RTO.max seconds. RTO.max seconds.
There is no requirement for the clock granularity G used for There is no requirement for the clock granularity G used for
computing RTT measurements and the different state variables, other computing RTT measurements and the different state variables, other
than: than:
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR
G. <- G.
Experience [ALLMAN99] has shown that finer clock granularities (<= Experience [ALLMAN99] has shown that finer clock granularities (<=
100 msec) perform somewhat better than more coarse granularities. 100 msec) perform somewhat better than more coarse granularities.
6.3.2. Retransmission Timer Rules 6.3.2. Retransmission Timer Rules
The rules for managing the retransmission timer are as follows: The rules for managing the retransmission timer are as follows:
R1) Every time a DATA chunk is sent to any address (including a R1) Every time a DATA chunk is sent to any address (including a
retransmission), if the T3-rtx timer of that address is not retransmission), if the T3-rtx timer of that address is not
skipping to change at page 87, line 39 skipping to change at page 83, line 31
E4) Start the retransmission timer T3-rtx on the destination address E4) Start the retransmission timer T3-rtx on the destination address
to which the retransmission is sent, if rule R1 above indicates to which the retransmission is sent, if rule R1 above indicates
to do so. The RTO to be used for starting T3-rtx should be the to do so. The RTO to be used for starting T3-rtx should be the
one for the destination address to which the retransmission is one for the destination address to which the retransmission is
sent, which, when the receiver is multi-homed, may be different sent, which, when the receiver is multi-homed, may be different
from the destination address for which the timer expired (see from the destination address for which the timer expired (see
Section 6.4 below). Section 6.4 below).
After retransmitting, once a new RTT measurement is obtained (which After retransmitting, once a new RTT measurement is obtained (which
can happen only when new data has been sent and acknowledged, per can happen only when new data has been sent and acknowledged, per
rule C5, or for a measurement made from a HEARTBEAT; see Section rule C5, or for a measurement made from a HEARTBEAT; see
8.3), the computation in rule C3 is performed, including the Section 8.3), the computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down computation of RTO, which may result in "collapsing" RTO back down
after it has been subject to doubling (rule E2). after it has been subject to doubling (rule E2).
Note: Any DATA chunks that were sent to the address for which the Note: Any DATA chunks that were sent to the address for which the
T3-rtx timer expired but did not fit in one MTU (rule E3 above) T3-rtx timer expired but did not fit in one MTU (rule E3 above)
should be marked for retransmission and sent as soon as cwnd allows should be marked for retransmission and sent as soon as cwnd allows
(normally, when a SACK arrives). (normally, when a SACK arrives).
The final rule for managing the retransmission timer concerns The final rule for managing the retransmission timer concerns
failover (see Section 6.4.1): failover (see Section 6.4.1):
skipping to change at page 91, line 15 skipping to change at page 87, line 5
Upon the reception of a SACK, the endpoint MUST remove all DATA Upon the reception of a SACK, the endpoint MUST remove all DATA
chunks that have been acknowledged by the SACK's Cumulative TSN Ack chunks that have been acknowledged by the SACK's Cumulative TSN Ack
from its transmit queue. The endpoint MUST also treat all the DATA from its transmit queue. The endpoint MUST also treat all the DATA
chunks with TSNs not included in the Gap Ack Blocks reported by the chunks with TSNs not included in the Gap Ack Blocks reported by the
SACK as "missing". The number of "missing" reports for each SACK as "missing". The number of "missing" reports for each
outstanding DATA chunk MUST be recorded by the data sender in order outstanding DATA chunk MUST be recorded by the data sender in order
to make retransmission decisions. See Section 7.2.4 for details. to make retransmission decisions. See Section 7.2.4 for details.
The following example shows the use of SACK to report a gap. The following example shows the use of SACK to report a gap.
Endpoint A Endpoint Z {App Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer) -----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack) immediately send ack)
/----- SACK [TSN Ack=6,Block=1, /----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2] / Start=2,End=2]
<-----/ (remove 6 from out-queue, <-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report) and mark 7 as "1" missing report)
Figure 9: Reporting a Gap using SACK Figure 9: Reporting a Gap using SACK
The maximum number of Gap Ack Blocks that can be reported within a The maximum number of Gap Ack Blocks that can be reported within a
single SACK chunk is limited by the current path MTU. When a single single SACK chunk is limited by the current path MTU. When a single
SACK cannot cover all the Gap Ack Blocks needed to be reported due to SACK cannot cover all the Gap Ack Blocks needed to be reported due to
the MTU limitation, the endpoint MUST send only one SACK, reporting the MTU limitation, the endpoint MUST send only one SACK, reporting
the Gap Ack Blocks from the lowest to highest TSNs, within the size the Gap Ack Blocks from the lowest to highest TSNs, within the size
limit set by the MTU, and leave the remaining highest TSN numbers limit set by the MTU, and leave the remaining highest TSN numbers
unacknowledged. unacknowledged.
6.8. CRC32c Checksum Calculation 6.8. CRC32c Checksum Calculation
skipping to change at page 93, line 33 skipping to change at page 89, line 21
the same SSN to each of the DATA chunks. If the user indicates the same SSN to each of the DATA chunks. If the user indicates
that the user message is to be delivered using unordered that the user message is to be delivered using unordered
delivery, then the U flag of each DATA chunk of the user message delivery, then the U flag of each DATA chunk of the user message
MUST be set to 1. MUST be set to 1.
3) The transmitter MUST also set the B/E bits of the first DATA 3) The transmitter MUST also set the B/E bits of the first DATA
chunk in the series to '10', the B/E bits of the last DATA chunk chunk in the series to '10', the B/E bits of the last DATA chunk
in the series to '01', and the B/E bits of all other DATA chunks in the series to '01', and the B/E bits of all other DATA chunks
in the series to '00'. in the series to '00'.
An endpoint MUST recognize fragmented DATA chunks by examining the An endpoint MUST recognize fragmented DATA chunks by examining the B/
B/E bits in each of the received DATA chunks, and queue the E bits in each of the received DATA chunks, and queue the fragmented
fragmented DATA chunks for reassembly. Once the user message is DATA chunks for reassembly. Once the user message is reassembled,
reassembled, SCTP shall pass the reassembled user message to the SCTP shall pass the reassembled user message to the specific stream
specific stream for possible reordering and final dispatching. for possible reordering and final dispatching.
Note: If the data receiver runs out of buffer space while still Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the reassembly of the message, waiting for more fragments to complete the reassembly of the message,
it should dispatch part of its inbound message through a partial it should dispatch part of its inbound message through a partial
delivery API (see Section 10), freeing some of its receive buffer delivery API (see Section 10), freeing some of its receive buffer
space so that the rest of the message may be received. space so that the rest of the message may be received.
6.10. Bundling 6.10. Bundling
An endpoint bundles chunks by simply including multiple chunks in one An endpoint bundles chunks by simply including multiple chunks in one
skipping to change at page 95, line 50 skipping to change at page 91, line 40
homed receivers is new with SCTP and may require refinement in the homed receivers is new with SCTP and may require refinement in the
future. The current algorithms make the following assumptions: future. The current algorithms make the following assumptions:
o The sender usually uses the same destination address until being o The sender usually uses the same destination address until being
instructed by the upper layer to do otherwise; however, SCTP may instructed by the upper layer to do otherwise; however, SCTP may
change to an alternate destination in the event an address is change to an alternate destination in the event an address is
marked inactive (see Section 8.2). Also, SCTP may retransmit to a marked inactive (see Section 8.2). Also, SCTP may retransmit to a
different transport address than the original transmission. different transport address than the original transmission.
o The sender keeps a separate congestion control parameter set for o The sender keeps a separate congestion control parameter set for
each of the destination addresses it can send to (not each each of the destination addresses it can send to (not each source-
source-destination pair but for each destination). The parameters destination pair but for each destination). The parameters should
should decay if the address is not used for a long enough time decay if the address is not used for a long enough time period.
period.
o For each of the destination addresses, an endpoint does slow start o For each of the destination addresses, an endpoint does slow start
upon the first transmission to that address. upon the first transmission to that address.
Note: TCP guarantees in-sequence delivery of data to its upper-layer Note: TCP guarantees in-sequence delivery of data to its upper-layer
protocol within a single TCP session. This means that when TCP protocol within a single TCP session. This means that when TCP
notices a gap in the received sequence number, it waits until the gap notices a gap in the received sequence number, it waits until the gap
is filled before delivering the data that was received with sequence is filled before delivering the data that was received with sequence
numbers higher than that of the missing data. On the other hand, numbers higher than that of the missing data. On the other hand,
SCTP can deliver data to its upper-layer protocol even if there is a SCTP can deliver data to its upper-layer protocol even if there is a
skipping to change at page 100, line 44 skipping to change at page 96, line 15
6) If not in Fast Recovery, enter Fast Recovery and mark the highest 6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and Recovery is exited. While in Fast Recovery, the ssthresh and
cwnd SHOULD NOT change for any destinations due to a subsequent cwnd SHOULD NOT change for any destinations due to a subsequent
Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further
due to a subsequent Fast Retransmit). due to a subsequent Fast Retransmit).
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Section 7.2.1 and Section Point, the cwnd adjustment rules defined in Section 7.2.1 and
7.2.2 must be applied first. Section 7.2.2 must be applied first.
A straightforward implementation of the above keeps a counter for A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 3 and consecutive SACK reporting the TSN hole. After reaching 3 and
starting the Fast-Retransmit procedure, the counter resets to 0. starting the Fast-Retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP Fast Recovery is achieved automatically with TSN's, the effect of TCP Fast Recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
skipping to change at page 101, line 20 skipping to change at page 96, line 38
[RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path [RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path
MTU Discovery", whereby an endpoint maintains an estimate of the MTU Discovery", whereby an endpoint maintains an estimate of the
maximum transmission unit (MTU) along a given Internet path and maximum transmission unit (MTU) along a given Internet path and
refrains from sending packets along that path that exceed the MTU, refrains from sending packets along that path that exceed the MTU,
other than occasional attempts to probe for a change in the Path MTU other than occasional attempts to probe for a change in the Path MTU
(PMTU). [RFC4821] is thorough in its discussion of the MTU discovery (PMTU). [RFC4821] is thorough in its discussion of the MTU discovery
mechanism and strategies for determining the current end-to-end MTU mechanism and strategies for determining the current end-to-end MTU
setting as well as detecting changes in this value. setting as well as detecting changes in this value.
An endpoint SHOULD apply these techniques, and SHOULD do so on a An endpoint SHOULD apply these techniques, and SHOULD do so on a per-
per-destination-address basis. destination-address basis.
There are two important SCTP-specific points regarding Path MTU There are two important SCTP-specific points regarding Path MTU
discovery: discovery:
1) SCTP associations can span multiple addresses. An endpoint MUST 1) SCTP associations can span multiple addresses. An endpoint MUST
maintain separate MTU estimates for each destination address of maintain separate MTU estimates for each destination address of
its peer. its peer.
2) The sender should track an association PMTU that will be the 2) The sender should track an association PMTU that will be the
smallest PMTU discovered for all of the peer's destination smallest PMTU discovered for all of the peer's destination
skipping to change at page 103, line 27 skipping to change at page 98, line 44
A destination transport address is considered "idle" if no new chunk A destination transport address is considered "idle" if no new chunk
that can be used for updating path RTT (usually including first that can be used for updating path RTT (usually including first
transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no
HEARTBEAT has been sent to it within the current heartbeat period of HEARTBEAT has been sent to it within the current heartbeat period of
that address. This applies to both active and inactive destination that address. This applies to both active and inactive destination
addresses. addresses.
The upper layer can optionally initiate the following functions: The upper layer can optionally initiate the following functions:
A) Disable heartbeat on a specific destination transport address of a A) Disable heartbeat on a specific destination transport address of
given association, a given association,
B) Change the HB.interval, B) Change the HB.interval,
C) Re-enable heartbeat on a specific destination transport address of C) Re-enable heartbeat on a specific destination transport address
a given association, and of a given association, and
D) Request an on-demand HEARTBEAT on a specific destination transport D) Request an on-demand HEARTBEAT on a specific destination
address of a given association. transport address of a given association.
The endpoint should increment the respective error counter of the The endpoint should increment the respective error counter of the
destination transport address each time a HEARTBEAT is sent to that destination transport address each time a HEARTBEAT is sent to that
address and not acknowledged within one RTO. address and not acknowledged within one RTO.
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
skipping to change at page 106, line 38 skipping to change at page 101, line 47
value in the Verification Tag field of the received SCTP packet value in the Verification Tag field of the received SCTP packet
matches its own tag. If the received Verification Tag value does not matches its own tag. If the received Verification Tag value does not
match the receiver's own tag value, the receiver shall silently match the receiver's own tag value, the receiver shall silently
discard the packet and shall not process it any further except for discard the packet and shall not process it any further except for
those cases listed in Section 8.5.1 below. those cases listed in Section 8.5.1 below.
8.5.1. Exceptions in Verification Tag Rules 8.5.1. Exceptions in Verification Tag Rules
A) Rules for packet carrying INIT: A) Rules for packet carrying INIT:
- The sender MUST set the Verification Tag of the packet to 0. * The sender MUST set the Verification Tag of the packet to 0.
- When an endpoint receives an SCTP packet with the Verification * When an endpoint receives an SCTP packet with the Verification
Tag set to 0, it should verify that the packet contains only an Tag set to 0, it should verify that the packet contains only an
INIT chunk. Otherwise, the receiver MUST silently discard the INIT chunk. Otherwise, the receiver MUST silently discard the
packet. packet.
B) Rules for packet carrying ABORT: B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag field of * The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value, if the outbound packet with the destination endpoint's tag value,
it is known. if it is known.
- If the ABORT is sent in response to an OOTB packet, the endpoint * If the ABORT is sent in response to an OOTB packet, the
MUST follow the procedure described in Section 8.4. endpoint MUST follow the procedure described in Section 8.4.
- The receiver of an ABORT MUST accept the packet if the * The receiver of an ABORT MUST accept the packet if the
Verification Tag field of the packet matches its own tag and the Verification Tag field of the packet matches its own tag and
T bit is not set OR if it is set to its peer's tag and the T bit the T bit is not set OR if it is set to its peer's tag and the
is set in the Chunk Flags. Otherwise, the receiver MUST silently T bit is set in the Chunk Flags. Otherwise, the receiver MUST
discard the packet and take no further action. silently discard the packet and take no further action.
C) Rules for packet carrying SHUTDOWN COMPLETE: C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN * When sending a SHUTDOWN COMPLETE, if the receiver of the
ACK has a TCB, then the destination endpoint's tag MUST be used, SHUTDOWN ACK has a TCB, then the destination endpoint's tag
and the T bit MUST NOT be set. Only where no TCB exists should MUST be used, and the T bit MUST NOT be set. Only where no TCB
the sender use the Verification Tag from the SHUTDOWN ACK, and exists should the sender use the Verification Tag from the
MUST set the T bit. SHUTDOWN ACK, and MUST set the T bit.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if * The receiver of a SHUTDOWN COMPLETE shall accept the packet if
the Verification Tag field of the packet matches its own tag and the Verification Tag field of the packet matches its own tag
the T bit is not set OR if it is set to its peer's tag and the T and the T bit is not set OR if it is set to its peer's tag and
bit is set in the Chunk Flags. Otherwise, the receiver MUST the T bit is set in the Chunk Flags. Otherwise, the receiver
silently discard the packet and take no further action. An MUST silently discard the packet and take no further action.
endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in
SHUTDOWN-ACK-SENT state. the SHUTDOWN-ACK-SENT state.
D) Rules for packet carrying a COOKIE ECHO D) Rules for packet carrying a COOKIE ECHO
- When sending a COOKIE ECHO, the endpoint MUST use the value of * When sending a COOKIE ECHO, the endpoint MUST use the value of
the Initiate Tag received in the INIT ACK. the Initiate Tag received in the INIT ACK.
- The receiver of a COOKIE ECHO follows the procedures in Section * The receiver of a COOKIE ECHO follows the procedures in
5. Section 5.
E) Rules for packet carrying a SHUTDOWN ACK E) Rules for packet carrying a SHUTDOWN ACK
- If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the * If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the
procedures in Section 8.4 SHOULD be followed; in other words, it procedures in Section 8.4 SHOULD be followed; in other words,
should be treated as an Out Of The Blue packet. it should be treated as an Out Of The Blue packet.
9. Termination of Association 9. Termination of Association
An endpoint should terminate its association when it exits from An endpoint should terminate its association when it exits from
service. An association can be terminated by either abort or service. An association can be terminated by either abort or
shutdown. An abort of an association is abortive by definition in shutdown. An abort of an association is abortive by definition in
that any data pending on either end of the association is discarded that any data pending on either end of the association is discarded
and not delivered to the peer. A shutdown of an association is and not delivered to the peer. A shutdown of an association is
considered a graceful close where all data in queue by either considered a graceful close where all data in queue by either
endpoint is delivered to the respective peers. However, in the case endpoint is delivered to the respective peers. However, in the case
skipping to change at page 109, line 17 skipping to change at page 104, line 29
If this threshold is exceeded, the endpoint should destroy the TCB If this threshold is exceeded, the endpoint should destroy the TCB
and MUST report the peer endpoint unreachable to the upper layer (and and MUST report the peer endpoint unreachable to the upper layer (and
thus the association enters the CLOSED state). The reception of any thus the association enters the CLOSED state). The reception of any
packet from its peer (i.e., as the peer sends all of its queued DATA packet from its peer (i.e., as the peer sends all of its queued DATA
chunks) should clear the endpoint's retransmission count and restart chunks) should clear the endpoint's retransmission count and restart
the T2-shutdown timer, giving its peer ample opportunity to transmit the T2-shutdown timer, giving its peer ample opportunity to transmit
all of its queued DATA chunks that have not yet been sent. all of its queued DATA chunks that have not yet been sent.
Upon reception of the SHUTDOWN, the peer endpoint shall Upon reception of the SHUTDOWN, the peer endpoint shall
- enter the SHUTDOWN-RECEIVED state, o enter the SHUTDOWN-RECEIVED state,
- stop accepting new data from its SCTP user, and o stop accepting new data from its SCTP user, and
- verify, by checking the Cumulative TSN Ack field of the chunk, o verify, by checking the Cumulative TSN Ack field of the chunk,
that all its outstanding DATA chunks have been received by the that all its outstanding DATA chunks have been received by the
SHUTDOWN sender. SHUTDOWN sender.
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
send a SHUTDOWN in response to a ULP request, and should discard send a SHUTDOWN in response to a ULP request, and should discard
subsequent SHUTDOWN chunks. subsequent SHUTDOWN chunks.
If there are still outstanding DATA chunks left, the SHUTDOWN If there are still outstanding DATA chunks left, the SHUTDOWN
receiver MUST continue to follow normal data transmission procedures receiver MUST continue to follow normal data transmission procedures
defined in Section 6, until all outstanding DATA chunks are defined in Section 6, until all outstanding DATA chunks are
skipping to change at page 109, line 44 skipping to change at page 105, line 7
While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST
immediately respond to each received packet containing one or more immediately respond to each received packet containing one or more
DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer.
If a SHUTDOWN chunk by itself cannot acknowledge all of the received If a SHUTDOWN chunk by itself cannot acknowledge all of the received
DATA chunks (i.e., there are TSNs that can be acknowledged that are DATA chunks (i.e., there are TSNs that can be acknowledged that are
larger than the cumulative TSN, and thus gaps exist in the TSN larger than the cumulative TSN, and thus gaps exist in the TSN
sequence), or if duplicate TSNs have been received, then a SACK chunk sequence), or if duplicate TSNs have been received, then a SACK chunk
MUST also be sent. MUST also be sent.
The sender of the SHUTDOWN MAY also start an overall guard timer The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-
'T5-shutdown-guard' to bound the overall time for the shutdown shutdown-guard' to bound the overall time for the shutdown sequence.
sequence. At the expiration of this timer, the sender SHOULD abort At the expiration of this timer, the sender SHOULD abort the
the association by sending an ABORT chunk. If the 'T5-shutdown- association by sending an ABORT chunk. If the 'T5-shutdown- guard'
guard' timer is used, it SHOULD be set to the recommended value of 5 timer is used, it SHOULD be set to the recommended value of 5 times
times 'RTO.Max'. 'RTO.Max'.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2- the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If
the timer expires, the endpoint must resend the SHUTDOWN ACK. the timer expires, the endpoint must resend the SHUTDOWN ACK.
The sender of the SHUTDOWN ACK should limit the number of The sender of the SHUTDOWN ACK should limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
'Association.Max.Retrans'. If this threshold is exceeded, the 'Association.Max.Retrans'. If this threshold is exceeded, the
endpoint should destroy the TCB and may report the peer endpoint endpoint should destroy the TCB and may report the peer endpoint
skipping to change at page 111, line 42 skipping to change at page 107, line 7
The following sections functionally characterize a ULP/SCTP The following sections functionally characterize a ULP/SCTP
interface. The notation used is similar to most procedure or interface. The notation used is similar to most procedure or
function calls in high-level languages. function calls in high-level languages.
The ULP primitives described below specify the basic functions that The ULP primitives described below specify the basic functions that
SCTP must perform to support inter-process communication. Individual SCTP must perform to support inter-process communication. Individual
implementations must define their own exact format, and may provide implementations must define their own exact format, and may provide
combinations or subsets of the basic functions in single calls. combinations or subsets of the basic functions in single calls.
A) Initialize A) Initialize
Format: INITIALIZE ([local port],[local eligible address list])->
local SCTP instance name
This primitive allows SCTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Once SCTP is initialized, ULP can communicate directly
with other endpoints without re-invoking this primitive.
SCTP will return a local SCTP instance name to the ULP.
Mandatory attributes:
None.
Optional attributes:
The following types of attributes may be passed along with the
primitive:
o local port - SCTP port number, if ULP wants it to be specified.
o local eligible address list - an address list that the local SCTP
endpoint should bind. By default, if an address list is not
included, all IP addresses assigned to the host should be used by
the local endpoint.
IMPLEMENTATION NOTE: If this optional attribute is supported by an
implementation, it will be the responsibility of the implementation
to enforce that the IP source address field of any SCTP packets sent
out by this endpoint contains one of the IP addresses indicated in
the local eligible address list.
B) Associate
Format: ASSOCIATE(local SCTP instance name,
destination transport addr, outbound stream count)
-> association id [,destination transport addr list]
[,outbound stream count]
This primitive allows the upper layer to initiate an association to a
specific peer endpoint.
The peer endpoint shall be specified by one of the transport
addresses that defines the endpoint (see Section 1.3). If the local
SCTP instance has not been initialized, the ASSOCIATE is considered
an error.
An association id, which is a local handle to the SCTP association,
will be returned on successful establishment of the association. If
SCTP is not able to open an SCTP association with the peer endpoint,
an error is returned.
Other association parameters may be returned, including the complete
destination transport addresses of the peer as well as the outbound
stream count of the local endpoint. One of the transport addresses
from the returned destination addresses will be selected by the local
endpoint as default primary path for sending SCTP packets to this
peer. The returned "destination transport addr list" can be used by
the ULP to change the default primary path or to force sending a
packet to a specific transport address.
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
blocking function call, the ASSOCIATE primitive can return
association parameters in addition to the association id upon
successful establishment. If ASSOCIATE primitive is implemented as a
non-blocking call, only the association id shall be returned and
association parameters shall be passed using the COMMUNICATION UP
notification.
Mandatory attributes:
o local SCTP instance name - obtained from the INITIALIZE operation.
o destination transport addr - specified as one of the transport
addresses of the peer endpoint with which the association is to be
established.
o outbound stream count - the number of outbound streams the ULP
would like to open towards this peer endpoint.
Optional attributes:
None.
C) Shutdown
Format: SHUTDOWN(association id)
-> result
Gracefully closes an association. Any locally queued user data will
be delivered to the peer. The association will be terminated only
after the peer acknowledges all the SCTP packets sent. A success
code will be returned on successful termination of the association.
If attempting to terminate the association results in a failure, an
error code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association.
Optional attributes:
None.
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Ungracefully closes an association. Any locally queued user data
will be discarded, and an ABORT chunk is sent to the peer. A success
code will be returned on successful abort of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association.
Optional attributes:
o Upper Layer Abort Reason - reason of the abort to be passed to the
peer.
None.
E) Send
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result
This is the main method to send user data via SCTP.
Mandatory attributes:
o association id - local handle to the SCTP association.
o buffer address - the location where the user message to be
transmitted is stored.
o byte count - the size of the user data in number of bytes.
Optional attributes:
o context - an optional 32-bit integer that will be carried in the
sending failure notification to the ULP if the transportation of
this user message fails.
o stream id - to indicate which stream to send the data on. If not
specified, stream 0 will be used.
o life time - specifies the life time of the user data. The user
data will not be sent by SCTP after the life time expires. This
parameter can be used to avoid efforts to transmit stale user
messages. SCTP notifies the ULP if the data cannot be initiated
to transport (i.e., sent to the destination via SCTP's send
primitive) within the life time variable. However, the user data
will be transmitted if SCTP has attempted to transmit a chunk
before the life time expired.
IMPLEMENTATION NOTE: In order to better support the data life time
option, the transmitter may hold back the assigning of the TSN number
to an outbound DATA chunk to the last moment. And, for
implementation simplicity, once a TSN number has been assigned the
sender should consider the send of this DATA chunk as committed,
overriding any life time option attached to the DATA chunk.
o destination transport address - specified as one of the
destination transport addresses of the peer endpoint to which this
packet should be sent. Whenever possible, SCTP should use this
destination transport address for sending the packets, instead of
the current primary path.
o unordered flag - this flag, if present, indicates that the user
would like the data delivered in an unordered fashion to the peer
(i.e., the U flag is set to 1 on all DATA chunks carrying this
message).
o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion.
o payload protocol-id - a 32-bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol data
being transmitted. This value is passed as opaque data by SCTP.
F) Set Primary
Format: SETPRIMARY(association id, destination transport address,
[source transport address] )
-> result
Instructs the local SCTP to use the specified destination transport
address as the primary path for sending packets.
The result of attempting this operation shall be returned. If the
specified destination transport address is not present in the
"destination transport address list" returned earlier in an associate
command or communication up notification, an error shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association.
o destination transport address - specified as one of the transport
addresses of the peer endpoint, which should be used as the
primary address for sending packets. This overrides the current
primary address information maintained by the local SCTP endpoint.
Optional attributes:
o source transport address - optionally, some implementations may
allow you to set the default source address placed in all outgoing
IP datagrams.
G) Receive
Format: RECEIVE(association id, buffer address, buffer size
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id]
This primitive shall read the first user message in the SCTP in-queue
into the buffer specified by ULP, if there is one available. The
size of the message read, in bytes, will be returned. It may,
depending on the specific implementation, also return other
information such as the sender's address, the stream id on which it
is received, whether there are more messages available for retrieval,
etc. For ordered messages, their Stream Sequence Number may also be
returned.
Depending upon the implementation, if this primitive is invoked when
no message is available the implementation should return an
indication of this condition or should block the invoking process
until data does become available.
Mandatory attributes:
o association id - local handle to the SCTP association
o buffer address - the memory location indicated by the ULP to store
the received message.
o buffer size - the maximum size of data to be received, in bytes.
Optional attributes:
o stream id - to indicate which stream to receive the data on.
o Stream Sequence Number - the Stream Sequence Number assigned by
the sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this
Receive contains a partial delivery of the whole message. When
this flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
o payload protocol-id - a 32-bit unsigned integer that is received Format: INITIALIZE ([local port],[local eligible address list])
from the peer indicating the type of payload protocol of the -> local SCTP instance name
received data. This value is passed as opaque data by SCTP.
H) Status This primitive allows SCTP to initialize its internal data
structures and allocate necessary resources for setting up its
operation environment. Once SCTP is initialized, ULP can
communicate directly with other endpoints without re-invoking
this primitive.
SCTP will return a local SCTP instance name to the ULP.
Mandatory attributes:
Format: STATUS(association id) * None.
-> status data
This primitive should return a data block containing the following Optional attributes:
information: The following types of attributes may be passed along with the
primitive:
association connection state, * local port - SCTP port number, if ULP wants it to be
destination transport address list, specified.
destination transport address reachability states, * local eligible address list - an address list that the local
current receiver window size, SCTP endpoint should bind. By default, if an address list is
current congestion window sizes, not included, all IP addresses assigned to the host should be
number of unacknowledged DATA chunks, used by the local endpoint.
number of DATA chunks pending receipt,
primary path,
most recent SRTT on primary path,
RTO on primary path,
SRTT and RTO on other destination addresses, etc.
Mandatory attributes: IMPLEMENTATION NOTE: If this optional attribute is supported by
an implementation, it will be the responsibility of the
implementation to enforce that the IP source address field of any
SCTP packets sent out by this endpoint contains one of the IP
addresses indicated in the local eligible address list.
B) Associate
o association id - local handle to the SCTP association. Format: ASSOCIATE(local SCTP instance name, destination transport
addr, outbound stream count) -> association id
[,destination transport addr list] [,outbound stream
count]
Optional attributes: This primitive allows the upper layer to initiate an association
to a specific peer endpoint.
The peer endpoint shall be specified by one of the transport
addresses that defines the endpoint (see Section 1.3). If the
local SCTP instance has not been initialized, the ASSOCIATE is
considered an error.
None. An association id, which is a local handle to the SCTP
association, will be returned on successful establishment of the
association. If SCTP is not able to open an SCTP association
with the peer endpoint, an error is returned.
Other association parameters may be returned, including the
complete destination transport addresses of the peer as well as
the outbound stream count of the local endpoint. One of the
transport addresses from the returned destination addresses will
be selected by the local endpoint as default primary path for
sending SCTP packets to this peer. The returned "destination
transport addr list" can be used by the ULP to change the default
primary path or to force sending a packet to a specific transport
address.
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
blocking function call, the ASSOCIATE primitive can return
association parameters in addition to the association id upon
successful establishment. If ASSOCIATE primitive is implemented
as a non-blocking call, only the association id shall be returned
and association parameters shall be passed using the
COMMUNICATION UP notification.
Mandatory attributes:
I) Change Heartbeat * local SCTP instance name - obtained from the INITIALIZE
operation.
* destination transport addr - specified as one of the transport
addresses of the peer endpoint with which the association is
to be established.
* outbound stream count - the number of outbound streams the ULP
would like to open towards this peer endpoint.
Format: CHANGE HEARTBEAT(association id, Optional attributes:
destination transport address, new state [,interval])
-> result
Instructs the local endpoint to enable or disable heartbeat on the * None.
specified destination transport address. C) Shutdown
The result of attempting this operation shall be returned. Format: SHUTDOWN(association id) -> result
Note: Even when enabled, heartbeat will not take place if the Gracefully closes an association. Any locally queued user data
destination transport address is not idle. will be delivered to the peer. The association will be
terminated only after the peer acknowledges all the SCTP packets
sent. A success code will be returned on successful termination
of the association. If attempting to terminate the association
results in a failure, an error code shall be returned.
Mandatory attributes:
Mandatory attributes: * association id - local handle to the SCTP association.
o association id - local handle to the SCTP association. Optional attributes:
o destination transport address - specified as one of the transport * None.
addresses of the peer endpoint. D) Abort
o new state - the new state of heartbeat for this destination Format: ABORT(association id [, Upper Layer Abort Reason]) ->
transport address (either enabled or disabled). result
Optional attributes: Ungracefully closes an association. Any locally queued user data
will be discarded, and an ABORT chunk is sent to the peer. A
success code will be returned on successful abort of the
association. If attempting to abort the association results in a
failure, an error code shall be returned.
Mandatory attributes:
o interval - if present, indicates the frequency of the heartbeat if * association id - local handle to the SCTP association.
this is to enable heartbeat on a destination transport address.
This value is added to the RTO of the destination transport
address. This value, if present, affects all destinations.
J) Request HeartBeat Optional attributes:
Format: REQUESTHEARTBEAT(association id, destination transport * Upper Layer Abort Reason - reason of the abort to be passed to
address) the peer.
-> result * None.
E) Send
Instructs the local endpoint to perform a HeartBeat on the specified Format: SEND(association id, buffer address, byte count
destination transport address of the given association. The returned [,context] [,stream id] [,life time] [,destination
result should indicate whether the transmission of the HEARTBEAT transport address] [,unordered flag] [,no-bundle flag]
chunk to the destination address is successful. [,payload protocol-id] ) -> result
Mandatory attributes: This is the main method to send user data via SCTP.
Mandatory attributes:
o association id - local handle to the SCTP association. * association id - local handle to the SCTP association.
* buffer address - the location where the user message to be
transmitted is stored.
* byte count - the size of the user data in number of bytes.
o destination transport address - the transport address of the Optional attributes:
association on which a heartbeat should be issued.
K) Get SRTT Report * context - an optional 32-bit integer that will be carried in
the sending failure notification to the ULP if the
transportation of this user message fails.
* stream id - to indicate which stream to send the data on. If
not specified, stream 0 will be used.
* life time - specifies the life time of the user data. The
user data will not be sent by SCTP after the life time
expires. This parameter can be used to avoid efforts to
transmit stale user messages. SCTP notifies the ULP if the
data cannot be initiated to transport (i.e., sent to the
destination via SCTP's send primitive) within the life time
variable. However, the user data will be transmitted if SCTP
has attempted to transmit a chunk before the life time
expired.
IMPLEMENTATION NOTE: In order to better support the data life
time option, the transmitter may hold back the assigning of
the TSN number to an outbound DATA chunk to the last moment.
And, for implementation simplicity, once a TSN number has been
assigned the sender should consider the send of this DATA
chunk as committed, overriding any life time option attached
to the DATA chunk.
* destination transport address - specified as one of the
destination transport addresses of the peer endpoint to which
this packet should be sent. Whenever possible, SCTP should
use this destination transport address for sending the
packets, instead of the current primary path.
* unordered flag - this flag, if present, indicates that the
user would like the data delivered in an unordered fashion to
the peer (i.e., the U flag is set to 1 on all DATA chunks
carrying this message).
* no-bundle flag - instructs SCTP not to bundle this user data
with other outbound DATA chunks. SCTP MAY still bundle even
when this flag is present, when faced with network congestion.
* payload protocol-id - a 32-bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol
data being transmitted. This value is passed as opaque data
by SCTP.
F) Set Primary
Format: GETSRTTREPORT(association id, Format: SETPRIMARY(association id, destination transport address,
destination transport address) [source transport address]) -> result
-> srtt result
Instructs the local SCTP to report the current SRTT measurement on Instructs the local SCTP to use the specified destination
the specified destination transport address of the given association. transport address as the primary path for sending packets.
The returned result can be an integer containing the most recent SRTT The result of attempting this operation shall be returned. If
in milliseconds. the specified destination transport address is not present in the
"destination transport address list" returned earlier in an
associate command or communication up notification, an error
shall be returned.
Mandatory attributes:
Mandatory attributes: * association id - local handle to the SCTP association.
* destination transport address - specified as one of the
transport addresses of the peer endpoint, which should be used
as the primary address for sending packets. This overrides
the current primary address information maintained by the
local SCTP endpoint.
o association id - local handle to the SCTP association. Optional attributes:
o destination transport address - the transport address of the * source transport address - optionally, some implementations
association on which the SRTT measurement is to be reported. may allow you to set the default source address placed in all
outgoing IP datagrams.
G) Receive
L) Set Failure Threshold Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) -> byte count [,transport address] [,stream
id] [,stream sequence number] [,partial flag] [,delivery
number] [,payload protocol-id]
Format: SETFAILURETHRESHOLD(association id, destination transport This primitive shall read the first user message in the SCTP in-
address, failure threshold) queue into the buffer specified by ULP, if there is one
available. The size of the message read, in bytes, will be
returned. It may, depending on the specific implementation, also
return other information such as the sender's address, the stream
id on which it is received, whether there are more messages
available for retrieval, etc. For ordered messages, their Stream
Sequence Number may also be returned.
Depending upon the implementation, if this primitive is invoked
when no message is available the implementation should return an
indication of this condition or should block the invoking process
until data does become available.
Mandatory attributes:
-> result * association id - local handle to the SCTP association
* buffer address - the memory location indicated by the ULP to
store the received message.
* buffer size - the maximum size of data to be received, in
bytes.
This primitive allows the local SCTP to customize the reachability Optional attributes:
failure detection threshold 'Path.Max.Retrans' for the specified
destination address.
Mandatory attributes: * stream id - to indicate which stream to receive the data on.
* Stream Sequence Number - the Stream Sequence Number assigned
by the sending SCTP peer.
* partial flag - if this returned flag is set to 1, then this
Receive contains a partial delivery of the whole message.
When this flag is set, the stream id and Stream Sequence
Number MUST accompany this receive. When this flag is set to
0, it indicates that no more deliveries will be received for
this Stream Sequence Number.
* payload protocol-id - a 32-bit unsigned integer that is
received from the peer indicating the type of payload protocol
of the received data. This value is passed as opaque data by
SCTP.
H) Status
o association id - local handle to the SCTP association. Format: STATUS(association id) -> status data
This primitive should return a data block containing the
following information:
o destination transport address - the transport address of the association connection state,
association on which the failure detection threshold is to be set. destination transport address list,
destination transport address reachability states,
current receiver window size,
current congestion window sizes,
number of unacknowledged DATA chunks,
number of DATA chunks pending receipt,
primary path,
most recent SRTT on primary path,
RTO on primary path,
SRTT and RTO on other destination addresses, etc.
o failure threshold - the new value of 'Path.Max.Retrans' for the Mandatory attributes:
destination address.
M) Set Protocol Parameters * association id - local handle to the SCTP association.
Format: SETPROTOCOLPARAMETERS(association id, Optional attributes:
[,destination transport address,]
protocol parameter list)
-> result
This primitive allows the local SCTP to customize the protocol * None.
parameters. I) Change Heartbeat
Mandatory attributes: Format: CHANGE HEARTBEAT(association id, destination transport
address, new state [,interval]) -> result
o association id - local handle to the SCTP association. Instructs the local endpoint to enable or disable heartbeat on
the specified destination transport address.
The result of attempting this operation shall be returned.
Note: Even when enabled, heartbeat will not take place if the
destination transport address is not idle.
Mandatory attributes:
o protocol parameter list - the specific names and values of the * association id - local handle to the SCTP association.
protocol parameters (e.g., Association.Max.Retrans; see Section * destination transport address - specified as one of the
15) that the SCTP user wishes to customize. transport addresses of the peer endpoint.
* new state - the new state of heartbeat for this destination
transport address (either enabled or disabled).
Optional attributes: Optional attributes:
o destination transport address - some of the protocol parameters * interval - if present, indicates the frequency of the
may be set on a per destination transport address basis. heartbeat if this is to enable heartbeat on a destination
transport address. This value is added to the RTO of the
destination transport address. This value, if present,
affects all destinations.
J) Request HeartBeat
Format: REQUESTHEARTBEAT(association id, destination transport
address) -> result
N) Receive Unsent Message Instructs the local endpoint to perform a HeartBeat on the
specified destination transport address of the given association.
The returned result should indicate whether the transmission of
the HEARTBEAT chunk to the destination address is successful.
Mandatory attributes:
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer * association id - local handle to the SCTP association.
size [,stream id] [, stream sequence number] [,partial * destination transport address - the transport address of the
flag] [,payload protocol-id]) association on which a heartbeat should be issued.
K) Get SRTT Report
o data retrieval id - the identification passed to the ULP in the Format: GETSRTTREPORT(association id, destination transport
failure notification. address) -> srtt result
o buffer address - the memory location indicated by the ULP to store Instructs the local SCTP to report the current SRTT measurement
the received message. on the specified destination transport address of the given
association. The returned result can be an integer containing
the most recent SRTT in milliseconds.
Mandatory attributes:
o buffer size - the maximum size of data to be received, in bytes. * association id - local handle to the SCTP association.
* destination transport address - the transport address of the
association on which the SRTT measurement is to be reported.
L) Set Failure Threshold
Optional attributes: Format: SETFAILURETHRESHOLD(association id, destination transport
address, failure threshold) -> result
o stream id - this is a return value that is set to indicate which This primitive allows the local SCTP to customize the
stream the data was sent to. reachability failure detection threshold 'Path.Max.Retrans' for
the specified destination address.
Mandatory attributes:
o Stream Sequence Number - this value is returned indicating the * association id - local handle to the SCTP association.
Stream Sequence Number that was associated with the message. * destination transport address - the transport address of the
association on which the failure detection threshold is to be
set.
* failure threshold - the new value of 'Path.Max.Retrans' for
the destination address.
M) Set Protocol Parameters
o partial flag - if this returned flag is set to 1, then this Format: SETPROTOCOLPARAMETERS(association id, [,destination
message is a partial delivery of the whole message. When this transport address,] protocol parameter list) -> result
flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
o payload protocol-id - The 32 bit unsigned integer that was sent to This primitive allows the local SCTP to customize the protocol
be sent to the peer indicating the type of payload protocol of the parameters.
received data. Mandatory attributes:
o Receive Unacknowledged Message * association id - local handle to the SCTP association.
* protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see
Section 15) that the SCTP user wishes to customize.
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer Optional attributes:
size, [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
o data retrieval id - the identification passed to the ULP in the * destination transport address - some of the protocol
failure notification. parameters may be set on a per destination transport address
basis.
N) Receive Unsent Message
o buffer address - the memory location indicated by the ULP to store Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer
the received message. size [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
o buffer size - the maximum size of data to be received, in bytes. * data retrieval id - the identification passed to the ULP in
the failure notification.
* buffer address - the memory location indicated by the ULP to
store the received message.
* buffer size - the maximum size of data to be received, in
bytes.
Optional attributes: Optional attributes:
o stream id - this is a return value that is set to indicate which * stream id - this is a return value that is set to indicate
stream the data was sent to. which stream the data was sent to.
* Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message.
* partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it
indicates that no more deliveries will be received for this
Stream Sequence Number.
* payload protocol-id - The 32 bit unsigned integer that was
sent to be sent to the peer indicating the type of payload
protocol of the received data.
O) Receive Unacknowledged Message
o Stream Sequence Number - this value is returned indicating the Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
Stream Sequence Number that was associated with the message. size, [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
o partial flag - if this returned flag is set to 1, then this * data retrieval id - the identification passed to the ULP in
message is a partial delivery of the whole message. When this the failure notification.
flag is set, the stream id and Stream Sequence Number MUST * buffer address - the memory location indicated by the ULP to
accompany this receive. When this flag is set to 0, it indicates store the received message.
that no more deliveries will be received for this Stream Sequence * buffer size - the maximum size of data to be received, in
Number. bytes.
o payload protocol-id - the 32-bit unsigned integer that was sent to Optional attributes:
the peer indicating the type of payload protocol of the received
data.
P) Destroy SCTP Instance * stream id - this is a return value that is set to indicate
which stream the data was sent to.
* Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message.
* partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it
indicates that no more deliveries will be received for this
Stream Sequence Number.
* payload protocol-id - the 32-bit unsigned integer that was
sent to the peer indicating the type of payload protocol of
the received data.
P) Destroy SCTP Instance
Format: DESTROY(local SCTP instance name) Format: DESTROY(local SCTP instance name)
o local SCTP instance name - this is the value that was passed to * local SCTP instance name - this is the value that was passed
the application in the initialize primitive and it indicates which to the application in the initialize primitive and it
SCTP instance is to be destroyed. indicates which SCTP instance is to be destroyed.
10.2. SCTP-to-ULP 10.2. SCTP-to-ULP
It is assumed that the operating system or application environment It is assumed that the operating system or application environment
provides a means for the SCTP to asynchronously signal the ULP provides a means for the SCTP to asynchronously signal the ULP
process. When SCTP does signal a ULP process, certain information is process. When SCTP does signal a ULP process, certain information is
passed to the ULP. passed to the ULP.
IMPLEMENTATION NOTE: In some cases, this may be done through a IMPLEMENTATION NOTE: In some cases, this may be done through a
separate socket or error channel. separate socket or error channel.
A) DATA ARRIVE notification A) DATA ARRIVE notification
SCTP shall invoke this notification on the ULP when a user
SCTP shall invoke this notification on the ULP when a user message is message is successfully received and ready for retrieval.
successfully received and ready for retrieval. The following may optionally be passed with the notification:
The following may optionally be passed with the notification:
o association id - local handle to the SCTP association.
o stream id - to indicate which stream the data is received on.
B) SEND FAILURE notification
If a message cannot be delivered, SCTP shall invoke this notification
on the ULP.
The following may optionally be passed with the notification:
o association id - local handle to the SCTP association.
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o cause code - indicating the reason of the failure, e.g., size too
large, message life time expiration, etc.
o context - optional information associated with this message (see D
in Section 10.1).
C) NETWORK STATUS CHANGE notification
When a destination transport address is marked inactive (e.g., when
SCTP detects a failure) or marked active (e.g., when SCTP detects a
recovery), SCTP shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association.
o destination transport address - this indicates the destination
transport address of the peer endpoint affected by the change.
o new-status - this indicates the new status.
D) COMMUNICATION UP notification
This notification is used when SCTP becomes ready to send or receive
user messages, or when a lost communication to an endpoint is
restored.
IMPLEMENTATION NOTE: If the ASSOCIATE primitive is implemented as a
blocking function call, the association parameters are returned as a
result of the ASSOCIATE primitive itself. In that case,
COMMUNICATION UP notification is optional at the association
initiator's side.
The following shall be passed with the notification:
o association id - local handle to the SCTP association.
o status - This indicates what type of event has occurred.
o destination transport address list - the complete set of
transport addresses of the peer.
o outbound stream count - the maximum number of streams allowed to
be used in this association by the ULP.
o inbound stream count - the number of streams the peer endpoint
has requested with this association (this may not be the same
number as 'outbound stream count').
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association.
o status - this indicates what type of event has occurred; the
status may indicate that a failure OR a normal
termination event occurred in response to a shutdown or
abort request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint.
o last-sent - the TSN last sent to that peer endpoint.
o Upper Layer Abort Reason - the abort reason specified in case of
a user-initiated abort.
F) COMMUNICATION ERROR notification
When SCTP receives an ERROR chunk from its peer and decides to notify
its ULP, it can invoke this notification on the ULP.
The following can be passed with the notification:
o association id - local handle to the SCTP association. * association id - local handle to the SCTP association.
* stream id - to indicate which stream the data is received on.
B) SEND FAILURE notification
If a message cannot be delivered, SCTP shall invoke this
notification on the ULP.
The following may optionally be passed with the notification:
o error info - this indicates the type of error and optionally some * association id - local handle to the SCTP association.
additional information received through the ERROR chunk. * data retrieval id - an identification used to retrieve unsent
and unacknowledged data.
* cause code - indicating the reason of the failure, e.g., size
too large, message life time expiration, etc.
* context - optional information associated with this message
(see D in Section 10.1).
C) NETWORK STATUS CHANGE notification
When a destination transport address is marked inactive (e.g.,
when SCTP detects a failure) or marked active (e.g., when SCTP
detects a recovery), SCTP shall invoke this notification on the
ULP.
The following shall be passed with the notification:
G) RESTART notification * association id - local handle to the SCTP association.
* destination transport address - this indicates the destination
transport address of the peer endpoint affected by the change.
* new-status - this indicates the new status.
D) COMMUNICATION UP notification
This notification is used when SCTP becomes ready to send or
receive user messages, or when a lost communication to an
endpoint is restored.
IMPLEMENTATION NOTE: If the ASSOCIATE primitive is implemented as
a blocking function call, the association parameters are returned
as a result of the ASSOCIATE primitive itself. In that case,
COMMUNICATION UP notification is optional at the association
initiator's side.
The following shall be passed with the notification:
When SCTP detects that the peer has restarted, it may send this * association id - local handle to the SCTP association.
notification to its ULP. * status - This indicates what type of event has occurred.
* destination transport address list - the complete set of
transport addresses of the peer.
* outbound stream count - the maximum number of streams allowed
to be used in this association by the ULP.
* inbound stream count - the number of streams the peer endpoint
has requested with this association (this may not be the same
number as 'outbound stream count').
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g.,
via Heartbeats) or detects that the endpoint has performed an
abort operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
The following can be passed with the notification: * association id - local handle to the SCTP association.
* status - this indicates what type of event has occurred; the
status may indicate that a failure OR a normal termination
event occurred in response to a shutdown or abort request.
o association id - local handle to the SCTP association. The following may be passed with the notification:
H) SHUTDOWN COMPLETE notification * data retrieval id - an identification used to retrieve unsent
and unacknowledged data.
* last-acked - the TSN last acked by that peer endpoint.
* last-sent - the TSN last sent to that peer endpoint.
* Upper Layer Abort Reason - the abort reason specified in case
of a user-initiated abort.
F) COMMUNICATION ERROR notification
When SCTP receives an ERROR chunk from its peer and decides to
notify its ULP, it can invoke this notification on the ULP.
The following can be passed with the notification:
When SCTP completes the shutdown procedures (Section 9.2), this * association id - local handle to the SCTP association.
notification is passed to the upper layer. * error info - this indicates the type of error and optionally
some additional information received through the ERROR chunk.
G) RESTART notification
When SCTP detects that the peer has restarted, it may send this
notification to its ULP.
The following can be passed with the notification:
The following can be passed with the notification: * association id - local handle to the SCTP association.
H) SHUTDOWN COMPLETE notification
When SCTP completes the shutdown procedures (Section 9.2), this
notification is passed to the upper layer.
The following can be passed with the notification:
o association id - local handle to the SCTP association. * association id - local handle to the SCTP association.
11. Security Considerations 11. Security Considerations
11.1. Security Objectives 11.1. Security Objectives
As a common transport protocol designed to reliably carry time- As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signaling messages for sensitive user messages, such as billing or signaling messages for
telephony services, between two networked endpoints, SCTP has the telephony services, between two networked endpoints, SCTP has the
following security objectives. following security objectives.
- availability of reliable and timely data transport services o availability of reliable and timely data transport services
- integrity of the user-to-user information carried by SCTP o integrity of the user-to-user information carried by SCTP
11.2. SCTP Responses to Potential Threats 11.2. SCTP Responses to Potential Threats
SCTP may potentially be used in a wide variety of risk situations. SCTP may potentially be used in a wide variety of risk situations.
It is important for operators of systems running SCTP to analyze It is important for operators of systems running SCTP to analyze
their particular situations and decide on the appropriate counter- their particular situations and decide on the appropriate counter-
measures. measures.
Operators of systems running SCTP should consult [RFC2196] for Operators of systems running SCTP should consult [RFC2196] for
guidance in securing their site. guidance in securing their site.
skipping to change at page 126, line 45 skipping to change at page 119, line 41
with legitimate transactions, and exploitation of buffer-related with legitimate transactions, and exploitation of buffer-related
software bugs. Flooding may be directed either at the SCTP node or software bugs. Flooding may be directed either at the SCTP node or
at resources in the intervening IP Access Links or the Internet. at resources in the intervening IP Access Links or the Internet.
Where the latter entities are the target, flooding will manifest Where the latter entities are the target, flooding will manifest
itself as loss of network services, including potentially the breach itself as loss of network services, including potentially the breach
of any firewalls in place. of any firewalls in place.
In general, protection against flooding begins at the equipment In general, protection against flooding begins at the equipment
design level, where it includes measures such as: design level, where it includes measures such as:
- avoiding commitment of limited resources before determining that o avoiding commitment of limited resources before determining that
the request for service is legitimate. the request for service is legitimate.
- giving priority to completion of processing in progress over the o giving priority to completion of processing in progress over the
acceptance of new work. acceptance of new work.
- identification and removal of duplicate or stale queued requests o identification and removal of duplicate or stale queued requests
for service. for service.
- not responding to unexpected packets sent to non-unicast o not responding to unexpected packets sent to non-unicast
addresses. addresses.
Network equipment should be capable of generating an alarm and log if Network equipment should be capable of generating an alarm and log if
a suspicious increase in traffic occurs. The log should provide a suspicious increase in traffic occurs. The log should provide
information such as the identity of the incoming link and source information such as the identity of the incoming link and source
address(es) used, which will help the network or SCTP system operator address(es) used, which will help the network or SCTP system operator
to take protective measures. Procedures should be in place for the to take protective measures. Procedures should be in place for the
operator to act on such alarms if a clear pattern of abuse emerges. operator to act on such alarms if a clear pattern of abuse emerges.
The design of SCTP is resistant to flooding attacks, particularly in The design of SCTP is resistant to flooding attacks, particularly in
skipping to change at page 127, line 45 skipping to change at page 120, line 42
this type of attack is to verify that the IP addresses received from this type of attack is to verify that the IP addresses received from
DNS include the source IP address of the original INIT. If the list DNS include the source IP address of the original INIT. If the list
of IP addresses received from DNS does not include the source IP of IP addresses received from DNS does not include the source IP
address of the INIT, the endpoint MAY silently discard the INIT. address of the INIT, the endpoint MAY silently discard the INIT.
This last option will not protect against the attack against the DNS. This last option will not protect against the attack against the DNS.
11.2.4.2. Blind Masquerade 11.2.4.2. Blind Masquerade
Masquerade can be used to deny service in several ways: Masquerade can be used to deny service in several ways:
- by tying up resources at the target SCTP node to which the o by tying up resources at the target SCTP node to which the
impersonated node has limited access. For example, the target impersonated node has limited access. For example, the target
node may by policy permit a maximum of one SCTP association with node may by policy permit a maximum of one SCTP association with
the impersonated SCTP node. The masquerading attacker may attempt the impersonated SCTP node. The masquerading attacker may attempt
to establish an association purporting to come from the to establish an association purporting to come from the
impersonated node so that the latter cannot do so when it requires impersonated node so that the latter cannot do so when it requires
it. it.
- by deliberately allowing the impersonation to be detected, thereby o by deliberately allowing the impersonation to be detected, thereby
provoking counter-measures that cause the impersonated node to be provoking counter-measures that cause the impersonated node to be
locked out of the target SCTP node. locked out of the target SCTP node.
- by interfering with an established association by inserting o by interfering with an established association by inserting
extraneous content such as a SHUTDOWN request. extraneous content such as a SHUTDOWN request.
SCTP reduces the risk of blind masquerade attacks through IP spoofing SCTP reduces the risk of blind masquerade attacks through IP spoofing
by use of the four-way startup handshake. Because the initial by use of the four-way startup handshake. Because the initial
exchange is memory-less, no lockout mechanism is triggered by blind exchange is memory-less, no lockout mechanism is triggered by blind
masquerade attacks. In addition, the INIT ACK containing the State masquerade attacks. In addition, the INIT ACK containing the State
Cookie is transmitted back to the IP address from which it received Cookie is transmitted back to the IP address from which it received
the INIT. Thus, the attacker would not receive the INIT ACK the INIT. Thus, the attacker would not receive the INIT ACK
containing the State Cookie. SCTP protects against insertion of containing the State Cookie. SCTP protects against insertion of
extraneous packets into the flow of an established association by use extraneous packets into the flow of an established association by use
skipping to change at page 129, line 7 skipping to change at page 121, line 52
11.3. SCTP Interactions with Firewalls 11.3. SCTP Interactions with Firewalls
It is helpful for some firewalls if they can inspect just the first It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements, please refer to [RFC1858]). Accordingly, we stress the requirements,
stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
with any other chunk in a packet, and (2) a packet containing an INIT with any other chunk in a packet, and (2) a packet containing an INIT
chunk MUST have a zero Verification Tag. Furthermore, we require chunk MUST have a zero Verification Tag. Furthermore, we require
that the receiver of an INIT chunk MUST enforce these rules by that the receiver of an INIT chunk MUST enforce these rules by
silently discarding an arriving packet with an INIT chunk that is silently discarding an arriving packet with an INIT chunk that is
bundled with other chunks or has a non-zero verification tag and bundled with other chunks or has a non-zero verification tag and
contains an INIT-chunk. contains an INIT-chunk.
11.4. Protection of Non-SCTP-Capable Hosts 11.4. Protection of Non-SCTP-Capable Hosts
To provide a non-SCTP-capable host with the same level of protection To provide a non-SCTP-capable host with the same level of protection
against attacks as for SCTP-capable ones, all SCTP stacks MUST against attacks as for SCTP-capable ones, all SCTP stacks MUST
implement the ICMP handling described in Appendix C. implement the ICMP handling described in Appendix C.
When an SCTP stack receives a packet containing multiple control or When an SCTP stack receives a packet containing multiple control or
skipping to change at page 130, line 23 skipping to change at page 123, line 14
13.1. Parameters Necessary for the SCTP Instance 13.1. Parameters Necessary for the SCTP Instance
Associations: A list of current associations and mappings to the data Associations: A list of current associations and mappings to the data
consumers for each association. This may be in the consumers for each association. This may be in the
form of a hash table or other implementation-dependent form of a hash table or other implementation-dependent
structure. The data consumers may be process structure. The data consumers may be process
identification information such as file descriptors, identification information such as file descriptors,
named pipe pointer, or table pointers dependent on how named pipe pointer, or table pointers dependent on how
SCTP is implemented. SCTP is implemented.
Secret Key: A secret key used by this endpoint to compute the MAC. Secret Key: A secret key used by this endpoint to compute the MAC.
This SHOULD be a cryptographic quality random number This SHOULD be a cryptographic quality random number
with a sufficient length. Discussion in RFC 4086 can with a sufficient length. Discussion in [RFC4086] can
be helpful in selection of the key. be helpful in selection of the key.
Address List: The list of IP addresses that this instance has bound. Address List: The list of IP addresses that this instance has bound.
This information is passed to one's peer(s) in INIT and This information is passed to one's peer(s) in INIT and
INIT ACK chunks. INIT ACK chunks.
SCTP Port: The local SCTP port number to which the endpoint is SCTP Port: The local SCTP port number to which the endpoint is
bound. bound.
13.2. Parameters Necessary per Association (i.e., the TCB) 13.2. Parameters Necessary per Association (i.e., the TCB)
Peer : Tag value to be sent in every packet and is received Peer Verification Tag: Tag value to be sent in every packet and is
Verification: in the INIT or INIT ACK chunk. received in the INIT or INIT ACK chunk.
Tag : My Verification Tag: Tag expected in every inbound packet and sent
in the INIT or INIT ACK chunk.
My : Tag expected in every inbound packet and sent in the State: A state variable indicating what state the association
Verification: INIT or INIT ACK chunk. is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
Tag : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
SHUTDOWN-ACK-SENT.
State : A state variable indicating what state the association
: is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
: SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
: SHUTDOWN-ACK-SENT.
Note: No "CLOSED" state is illustrated since if a 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 Address List: A list of SCTP transport addresses to
Peer : A list of SCTP transport addresses to which the peer which the peer is bound. This information is derived
Transport : is bound. This information is derived from the INIT or from the INIT or INIT ACK and is used to associate an
Address : INIT ACK and is used to associate an inbound packet inbound packet with a given association. Normally,
List : with a given association. Normally, this information this information is hashed or keyed for quick lookup
: is hashed or keyed for quick lookup and access of the and access of the TCB.
: TCB. Primary Path: This is the current primary destination transport
address of the peer endpoint. It may also specify a
Primary : This is the current primary destination transport source transport address on this endpoint.
Path : address of the peer endpoint. It may also specify a Overall Error Count: The overall association error count.
: source transport address on this endpoint. Overall Error Threshold: The threshold for this association that if
the Overall Error Count reaches will cause this
Overall : The overall association error count. association to be torn down.
Error Count : Peer Rwnd: Current calculated value of the peer's rwnd.
Next TSN: The next TSN number to be assigned to a new DATA chunk.
Overall : The threshold for this association that if the Overall This is sent in the INIT or INIT ACK chunk to the peer
Error : Error Count reaches will cause this association to be and incremented each time a DATA chunk is assigned a
Threshold : torn down. TSN (normally just prior to transmit or during
fragmentation).
Peer Rwnd : Current calculated value of the peer's rwnd. Last Rcvd TSN: This is the last TSN received in sequence. This
value is set initially by taking the peer's initial
Next TSN : The next TSN number to be assigned to a new DATA chunk. TSN, received in the INIT or INIT ACK chunk, and
: This is sent in the INIT or INIT ACK chunk to the peer subtracting one from it.
: and incremented each time a DATA chunk is assigned a Mapping Array: An array of bits or bytes indicating which out-of-
: TSN (normally just prior to transmit or during order TSNs have been received (relative to the Last
: fragmentation). Rcvd TSN). If no gaps exist, i.e., no out-of- order
packets have been received, this array will be set to
Last Rcvd : This is the last TSN received in sequence. This value all zero. This structure may be in the form of a
TSN : is set initially by taking the peer's initial TSN, circular buffer or bit array.
: received in the INIT or INIT ACK chunk, and Ack State: This flag indicates if the next received packet is to
: subtracting one from it. be responded to with a SACK. This is initialized to 0.
When a packet is received it is incremented. If this
Mapping : An array of bits or bytes indicating which out-of- value reaches 2 or more, a SACK is sent and the value
Array : order TSNs have been received (relative to the is reset to 0. Note: This is used only when no DATA
: Last Rcvd TSN). If no gaps exist, i.e., no out-of- chunks are received out of order. When DATA chunks are
: order packets have been received, this array will out of order, SACKs are not delayed (see Section 6).
: be set to all zero. This structure may be in the Inbound Streams: An array of structures to track the inbound
: form of a circular buffer or bit array. streams, normally including the next sequence number
expected and possibly the stream number.
Ack State : This flag indicates if the next received packet Outbound Streams: An array of structures to track the outbound
: is to be responded to with a SACK. This is initialized streams, normally including the next sequence number to
: to 0. When a packet is received it is incremented. be sent on the stream.
: If this value reaches 2 or more, a SACK is sent and the Reasm Queue: A reassembly queue.
: value is reset to 0. Note: This is used only when no Local Transport Address List: The list of local IP addresses bound
: DATA chunks are received out of order. When DATA in to this association.
: chunks are out of order, SACKs are not delayed (see Association PMTU: The smallest PMTU discovered for all of the peer's
: Section 6). transport addresses.
Inbound : An array of structures to track the inbound streams,
Streams : normally including the next sequence number expected
: and possibly the stream number.
Outbound : An array of structures to track the outbound streams,
Streams : normally including the next sequence number to
: be sent on the stream.
Reasm Queue : A reassembly queue.
Local : The list of local IP addresses bound in to this
Transport : association.
Address :
List :
Association : The smallest PMTU discovered for all of the
PMTU : peer's transport addresses.
13.3. Per Transport Address Data 13.3. Per Transport Address Data
For each destination transport address in the peer's address list For each destination transport address in the peer's address list
derived from the INIT or INIT ACK chunk, a number of data elements derived from the INIT or INIT ACK chunk, a number of data elements
need to be maintained including: need to be maintained including:
Error Count : The current error count for this destination. Error Count: The current error count for this destination.
Error Threshold: Current error threshold for this destination, i.e.,
Error : Current error threshold for this destination, i.e., 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.
ssthresh: The current ssthresh value.
cwnd : The current congestion window. RTO: The current retransmission timeout value.
SRTT: The current smoothed round-trip time.
ssthresh : The current ssthresh value. RTTVAR: The current RTT variation.
partial bytes acked: The tracking method for increase of cwnd when
RTO : The current retransmission timeout value. in congestion avoidance mode (see Section 7.2.2).
SRTT : The current smoothed round-trip time.
RTTVAR : The current RTT variation.
partial : The tracking method for increase of cwnd when in
bytes acked : congestion avoidance mode (see Section 7.2.2).
state : The current state of this destination, i.e., DOWN, UP,
: ALLOW-HB, NO-HEARTBEAT, etc.
PMTU : The current known path MTU.
Per : A timer used by each destination.
Destination :
Timer :
RTO-Pending : A flag used to track if one of the DATA chunks sent to
: this address is currently being used to compute an
: RTT. If this flag is 0, the next DATA chunk sent to
: this destination should be used to compute an RTT and
: this flag should be set. Every time the RTT
: calculation completes (i.e., the DATA chunk is SACK'd),
: clear this flag.
last-time : The time to which this destination was last sent. state: The current state of this destination, i.e., DOWN, UP,
: This can be to determine if a HEARTBEAT is needed. ALLOW-HB, NO-HEARTBEAT, etc.
PMTU: The current known path MTU.
Per Destination Timer: A timer used by each destination.
RTO-Pending: A flag used to track if one of the DATA chunks sent to
this address is currently being used to compute an RTT.
If this flag is 0, the next DATA chunk sent to this
destination should be used to compute an RTT and this
flag should be set. Every time the RTT calculation
completes (i.e., the DATA chunk is SACK'd), clear this
flag.
last-time: The time to which this destination was last sent. This
can be to determine if a HEARTBEAT is needed.
13.4. General Parameters Needed 13.4. General Parameters Needed
Out Queue : A queue of outbound DATA chunks. Out Queue: A queue of outbound DATA chunks.
In Queue: A queue of inbound DATA chunks.
In Queue : A queue of inbound DATA chunks.
14. IANA Considerations 14. IANA Considerations
SCTP defines three registries that IANA maintains: SCTP defines three registries that IANA maintains:
- through definition of additional chunk types, o through definition of additional chunk types,
- through definition of additional parameter types, or o through definition of additional parameter types, or
- through definition of additional cause codes within ERROR chunks. o through definition of additional cause codes within ERROR chunks.
SCTP requires that the IANA Port Numbers registry be opened for SCTP SCTP requires that the IANA Port Numbers registry be opened for SCTP
port registrations, Section 14.5 describes how. An IESG-appointed port registrations, Section 14.5 describes how. An IESG-appointed
Expert Reviewer supports IANA in evaluating SCTP port allocation Expert Reviewer supports IANA in evaluating SCTP port allocation
requests. requests.
14.1. IETF-Defined Chunk Extension 14.1. IETF-Defined Chunk Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) A long and short name for the new chunk type. a) A long and short name for the new chunk type.
b) A detailed description of the structure of the chunk, which MUST b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2. conform to the basic structure defined in Section 3.2.
c) A detailed definition and description of intended use of each c) A detailed definition and description of intended use of each
field within the chunk, including the chunk flags if any. field within the chunk, including the chunk flags if any.
d) A detailed procedural description of the use of the new chunk type d) A detailed procedural description of the use of the new chunk
within the operation of the protocol. type within the operation of the protocol.
The last chunk type (255) is reserved for future extension if The last chunk type (255) is reserved for future extension if
necessary. necessary.
14.2. IETF-Defined Chunk Parameter Extension 14.2. IETF-Defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) Name of the parameter type. a) Name of the parameter type.
b) Detailed description of the structure of the parameter field. b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general Type-Length-Value This structure MUST conform to the general Type-Length-Value
format described in Section 3.2.1. format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value. c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type, d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances
instances of this parameter type may be found within the same multiple instances of this parameter type may be found within the
chunk. same chunk.
e) Each parameter type MUST be unique across all chunks. e) Each parameter type MUST be unique across all chunks.
14.3. IETF-Defined Additional Error Causes 14.3. IETF-Defined Additional Error Causes
Additional cause codes may be allocated in the range 11 to 65535 Additional cause codes may be allocated in the range 11 to 65535
through a Specification Required action as defined in [RFC2434]. through a Specification Required action as defined in [RFC2434].
Provided documentation must include the following information: Provided documentation must include the following information:
a) Name of the error condition. a) Name of the error condition.
b) Detailed description of the conditions under which an SCTP b) Detailed description of the conditions under which an SCTP
endpoint should issue an ERROR (or ABORT) with this cause code. endpoint should issue an ERROR (or ABORT) with this cause code.
c) Expected action by the SCTP endpoint that receives an ERROR (or c) Expected action by the SCTP endpoint that receives an ERROR (or
ABORT) chunk containing this cause code. ABORT) chunk containing this cause code.
d) Detailed description of the structure and content of data fields d) Detailed description of the structure and content of data fields
that accompany this cause code. that accompany this cause code.
The initial word (32 bits) of a cause code parameter MUST conform to The initial word (32 bits) of a cause code parameter MUST conform to
the format shown in Section 3.3.10, i.e.: the format shown in Section 3.3.10, i.e.:
- first 2 bytes contain the cause code value o first 2 bytes contain the cause code value
- last 2 bytes contain the length of the cause parameter. o last 2 bytes contain the length of the cause parameter.
14.4. Payload Protocol Identifiers 14.4. Payload Protocol Identifiers
Except for value 0, which is reserved by SCTP to indicate an Except for value 0, which is reserved by SCTP to indicate an
unspecified payload protocol identifier in a DATA chunk, SCTP will unspecified payload protocol identifier in a DATA chunk, SCTP will
not be responsible for standardizing or verifying any payload not be responsible for standardizing or verifying any payload
protocol identifiers; SCTP simply receives the identifier from the protocol identifiers; SCTP simply receives the identifier from the
upper layer and carries it with the corresponding payload data. upper layer and carries it with the corresponding payload data.
The upper layer, i.e., the SCTP user, SHOULD standardize any specific The upper layer, i.e., the SCTP user, SHOULD standardize any specific
skipping to change at page 136, line 37 skipping to change at page 128, line 30
number. number.
o A port name registered for TCP MAY be registered for SCTP as well. o A port name registered for TCP MAY be registered for SCTP as well.
Any such registration SHOULD use the same port number as the Any such registration SHOULD use the same port number as the
existing TCP registration. existing TCP registration.
o Concrete intent to use a port SHOULD precede port registration. o Concrete intent to use a port SHOULD precede port registration.
For example, existing TCP ports SHOULD NOT be registered in For example, existing TCP ports SHOULD NOT be registered in
advance of any intent to use those ports for SCTP. advance of any intent to use those ports for SCTP.
This document registers the following ports. (These registrations This document registers the following ports. (These registrations
should be considered models to follow for future allocation should be considered models to follow for future allocation
requests.) requests.)
discard 9/sctp Discard # IETF TSVWG
discard 9/sctp Discard # IETF TSVWG # Randall Stewart <rrs@cisco.com>
# Randall Stewart <rrs@cisco.com> # [RFC4960]
# [RFC4960]
The discard service, which accepts SCTP connections on port The discard service, which accepts SCTP connections on port
9, discards all incoming application data and sends no data 9, discards all incoming application data and sends no data
in response. Thus, SCTP's discard port is analogous to in response. Thus, SCTP's discard port is analogous to
TCP's discard port, and might be used to check the health TCP's discard port, and might be used to check the health
of an SCTP stack. of an SCTP stack.
ftp-data 20/sctp FTP # IETF TSVWG ftp-data 20/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
ftp 21/sctp FTP # IETF TSVWG ftp 21/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
File Transfer Protocol (FTP) data (20) and control ports File Transfer Protocol (FTP) data (20) and control ports
(21). (21).
ssh 22/sctp SSH # IETF TSVWG ssh 22/sctp SSH # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
The Secure Shell (SSH) remote login service, which allows The Secure Shell (SSH) remote login service, which allows
secure shell logins to a host. secure shell logins to a host.
http 80/sctp HTTP # IETF TSVWG http 80/sctp HTTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
World Wide Web HTTP over SCTP. World Wide Web HTTP over SCTP.
bgp 179/sctp BGP # IETF TSVWG bgp 179/sctp BGP # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
Border Gateway Protocol over SCTP. Border Gateway Protocol over SCTP.
https 443/sctp HTTPS # IETF TSVWG https 443/sctp HTTPS # IETF TSVWG
# Randall Stewart <rrs@cisco.com> # Randall Stewart <rrs@cisco.com>
# [RFC4960] # [RFC4960]
World Wide Web HTTP over TLS/SSL over SCTP. World Wide Web HTTP over TLS/SSL over SCTP.
15. Suggested SCTP Protocol Parameter Values 15. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
Max.Burst - 4 Max.Burst - 4
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds HB.interval - 30 seconds
HB.Max.Burst - 1 HB.Max.Burst - 1
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 10). customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above. Note: RTO.Min SHOULD be set as recommended above.
16. Acknowledgements 16. Acknowledgements
An undertaking represented by this updated document is not a small An undertaking represented by this updated document is not a small
feat and represents the summation of the initial authors of RFC 2960: feat and represents the summation of the initial authors of RFC 2960:
Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor,
Rytina, M. Kalla, L. Zhang, and V. Paxson. I. Rytina, M. Kalla, L. Zhang, and V. Paxson.
Add to that, the comments from everyone who contributed to the Add to that, the comments from everyone who contributed to the
original RFC: original RFC:
Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve
Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally
Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian
Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon
Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme,
skipping to change at page 140, line 5 skipping to change at page 131, line 34
And finally, you have this document, and those who have commented And finally, you have this document, and those who have commented
upon that including Alfred Hoenes and Ronnie Sellars. upon that including Alfred Hoenes and Ronnie Sellars.
My thanks cannot be adequately expressed to all of you who have My thanks cannot be adequately expressed to all of you who have
participated in the coding, testing, and updating process of this participated in the coding, testing, and updating process of this
document. All I can say is, Thank You! document. All I can say is, Thank You!
Randall Stewart - Editor Randall Stewart - Editor
17. References
17.1. Normative References
[ITU.V42.1994]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
DOI 10.17487/RFC2434, October 1998,
<https://www.rfc-editor.org/info/rfc2434>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
<https://www.rfc-editor.org/info/rfc2581>.
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission
Protocol (SCTP) Management Information Base (MIB)",
RFC 3873, DOI 10.17487/RFC3873, September 2004,
<https://www.rfc-editor.org/info/rfc3873>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<https://www.rfc-editor.org/info/rfc4306>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
17.2. Informative References
[ALLMAN99]
Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", SIGCOM 99, 1999.
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP", SIGCOM 99, V. 26, N. 3,
pp 5-21, July 1996.
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP",
RFC 813, DOI 10.17487/RFC0813, July 1982,
<https://www.rfc-editor.org/info/rfc813>.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
DOI 10.17487/RFC1858, October 1995,
<https://www.rfc-editor.org/info/rfc1858>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
DOI 10.17487/RFC2196, September 1997,
<https://www.rfc-editor.org/info/rfc2196>.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999,
<https://www.rfc-editor.org/info/rfc2522>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<https://www.rfc-editor.org/info/rfc2960>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
DOI 10.17487/RFC3309, September 2002,
<https://www.rfc-editor.org/info/rfc3309>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[SAVAGE99]
Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communications Review 29(5), October 1999.
[WILLIAMS93]
Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
ALGORITHMS", SIGCOM 99, August 1993,
<http://www.geocities.com/SiliconValley/Pines/8659/
crc.htm>.
Appendix A. Explicit Congestion Notification Appendix A. Explicit Congestion Notification
ECN [RFC3168] describes a proposed extension to IP that details a ECN [RFC3168] describes a proposed extension to IP that details a
method to become aware of congestion outside of datagram loss. This method to become aware of congestion outside of datagram loss. This
is an optional feature that an implementation MAY choose to add to is an optional feature that an implementation MAY choose to add to
SCTP. This appendix details the minor differences implementers will SCTP. This appendix details the minor differences implementers will
need to be aware of if they choose to implement this feature. In need to be aware of if they choose to implement this feature. In
general, [RFC3168] should be followed with the following exceptions. general, [RFC3168] should be followed with the following exceptions.
Negotiation: Negotiation:
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection. The sender of the SYN sets 2 bits in the stages of a TCP connection. The sender of the SYN sets 2 bits in the
TCP flags, and the sender of the SYN-ACK sets only 1 bit. The TCP flags, and the sender of the SYN-ACK sets only 1 bit. The
reasoning behind this is to ensure that both sides are truly ECN reasoning behind this is to ensure that both sides are truly ECN
capable. For SCTP, this is not necessary. To indicate that an capable. For SCTP, this is not necessary. To indicate that an
endpoint is ECN capable, an endpoint SHOULD add to the INIT and or endpoint is ECN capable, an endpoint SHOULD add to the INIT and or
INIT ACK chunk the TLV reserved for ECN. This TLV contains no INIT ACK chunk the TLV reserved for ECN. This TLV contains no
parameters, and thus has the following format: parameters, and thus has 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 = 32768 | Parameter Length = 4 | | Parameter Type = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo: ECN-Echo:
[RFC3168] details a specific bit for a receiver to send back in its [RFC3168] details a specific bit for a receiver to send back in its
TCP acknowledgements to notify the sender of the Congestion TCP acknowledgements to notify the sender of the Congestion
Experienced (CE) bit having arrived from the network. For SCTP, this Experienced (CE) bit having arrived from the network. For SCTP, this
same indication is made by including the ECNE chunk. This chunk same indication is made by including the ECNE chunk. This chunk
contains one data element, i.e., the lowest TSN associated with the contains one data element, i.e., the lowest TSN associated with the
IP datagram marked with the CE bit, and looks as follows: IP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 | | Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number | | Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk. Note: The ECNE is considered a Control chunk.
CWR: CWR:
[RFC3168] details a specific bit for a sender to send in the header [RFC3168] details a specific bit for a sender to send in the header
of its next outbound TCP segment to indicate to its peer that it has of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window. This is termed the CWR bit. For reduced its congestion window. This is termed the CWR bit. For
SCTP, the same indication is made by including the CWR chunk. This SCTP