draft-ietf-tsvwg-2960bis-00.txt   draft-ietf-tsvwg-2960bis-01.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems Inc. Internet-Draft Editor
Expires: August 20, 2006 February 16, 2006 Expires: November 10, 2006 May 9, 2006
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-00.txt draft-ietf-tsvwg-2960bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 20, 2006. This Internet-Draft will expire on November 10, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Stream Control Transmission Protocol This document describes the Stream Control Transmission Protocol
(SCTP). SCTP is designed to transport PSTN signaling messages over (SCTP). SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications. IP networks, but is capable of broader applications.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 11 1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 11
1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 11 1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 11
1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16
1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 16 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 16
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 17 3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 17
3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 18 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 18
3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 19 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 19
3.2.1. Optional/Variable-length Parameter Format . . . . . . 21 3.2.1. Optional/Variable-length Parameter Format . . . . . . 21
3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 23
3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 24
3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 24
3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 31 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 26
3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 35 3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 32
3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 38 3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 36
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 39 3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 40
3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 40 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 41
3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 41 3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 42 3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 42
3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 42 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 43
3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 44 3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 44
3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 45 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 45
3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 45 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 46
3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 46 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 46
3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 46 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 47
3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 47 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 47
3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 47 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 48
3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 47 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 48
3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 48 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 49
3.3.10.10. Cookie Received While Shutting Down (10) . . . . 48 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 49
3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 49 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 50
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 50 3.3.10.11. Restart of an Association with New Addresses
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 50 (11) . . . . . . . . . . . . . . . . . . . . . . 50
4. SCTP Association State Diagram . . . . . . . . . . . . . . . 51 3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 50
5. Association Initialization . . . . . . . . . . . . . . . . . 54 3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 51
5.1. Normal Establishment of an Association . . . . . . . . . 54 3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 51
5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 56 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 52
5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 57 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 53
5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 58 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 53
5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 59 5. Association Initialization . . . . . . . . . . . . . . . . . 57
5.1.5. State Cookie Authentication . . . . . . . . . . . . . 60 5.1. Normal Establishment of an Association . . . . . . . . . 57
5.1.6. An Example of Normal Association Establishment . . . 60 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 59
5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 59
5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 62
5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 63
5.1.5. State Cookie Authentication . . . . . . . . . . . . . 63
5.1.6. An Example of Normal Association Establishment . . . 64
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE
ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 62 ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 66
5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED 5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED
State (Item B) . . . . . . . . . . . . . . . . . . . 62 State (Item B) . . . . . . . . . . . . . . . . . . . 66
5.2.2. Unexpected INIT in States Other than CLOSED, 5.2.2. Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 63 COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 67
5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 63 5.2.3. Unexpected INIT ACK . . . . . . . . . . . . . . . . . 68
5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 64 5.2.4. Handle a COOKIE ECHO when a TCB exists . . . . . . . 68
5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 68 5.2.5. Handle Duplicate COOKIE-ACK. . . . . . . . . . . . . 72
5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 68 5.2.6. Handle Stale COOKIE Error . . . . . . . . . . . . . . 72
5.3. Other Initialization Issues . . . . . . . . . . . . . . . 68 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 72
5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 68 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 72
6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 69 5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 73
6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 70 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 74
6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 72 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 76
6.2.1. Processing a Received SACK . . . . . . . . . . . . . 75 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 78
6.3. Management of Retransmission Timer . . . . . . . . . . . 76 6.2.1. Processing a Received SACK . . . . . . . . . . . . . 81
6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 77 6.3. Management of Retransmission Timer . . . . . . . . . . . 83
6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 78 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 83
6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 79 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 84
6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 80 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 85
6.4.1. Failover from Inactive Destination Address . . . . . 81 6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86
6.5. Stream Identifier and Stream Sequence Number . . . . . . 82 6.4.1. Failover from Inactive Destination Address . . . . . 87
6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 82 6.5. Stream Identifier and Stream Sequence Number . . . . . . 88
6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 83 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 88
6.8. Adler-32 Checksum Calculation . . . . . . . . . . . . . . 84 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 89
6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 85 6.8. CRC-32c Checksum Calculation . . . . . . . . . . . . . . 90
6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 86 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 91
7. Congestion control . . . . . . . . . . . . . . . . . . . . . 87 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 92
7.1. SCTP Differences from TCP Congestion control . . . . . . 87 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 93
7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 88 7.1. SCTP Differences from TCP Congestion control . . . . . . 94
7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 89 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 95
7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 90 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 96
7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 91 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 97
7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 91 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97
7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 92 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 98
8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 94 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99
8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 94 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 101
8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 94 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 101
8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 95 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 101
8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 97 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 102
8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 98 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 104
8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 98 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 105
9. Termination of Association . . . . . . . . . . . . . . . . . 99 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 105
9.1. Abort of an Association . . . . . . . . . . . . . . . . . 100 9. Termination of Association . . . . . . . . . . . . . . . . . 106
9.2. Shutdown of an Association . . . . . . . . . . . . . . . 100 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 107
10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 103 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 107
10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 103 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 110
10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 114 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 110
11. Security Considerations . . . . . . . . . . . . . . . . . . . 116 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 121
11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124
11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 117 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 124
11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 117 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 124
11.2.2. Protecting against Data Corruption in the Network . . 117 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124
11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 118 11.2.2. Protecting against Data Corruption in the Network . . 125
11.2.4. Protecting against Blind Denial of Service Attacks . 118 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125
11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 118 11.2.4. Protecting against Blind Denial of Service Attacks . 126
11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 120 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126
11.2.4.3. Improper Monopolization of Services . . . . . . 120 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127
11.3. Protection against Fraud and Repudiation . . . . . . . . 121 11.2.4.3. Improper Monopolization of Services . . . . . . 128
12. Recommended Transmission Control Block (TCB) Parameters . . . 122 11.3. Protection against Fraud and Repudiation . . . . . . . . 128
12.1. Parameters necessary for the SCTP instance . . . . . . . 122 11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129
12.2. Parameters necessary per association (i.e. the TCB) . . . 122 11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129
12.3. Per Transport Address Data . . . . . . . . . . . . . . . 124 12. Recommended Transmission Control Block (TCB) Parameters . . . 130
12.4. General Parameters Needed . . . . . . . . . . . . . . . . 125 12.1. Parameters necessary for the SCTP instance . . . . . . . 131
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 12.2. Parameters necessary per association (i.e. the TCB) . . . 131
13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 126 12.3. Per Transport Address Data . . . . . . . . . . . . . . . 133
13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 126 12.4. General Parameters Needed . . . . . . . . . . . . . . . . 134
13.3. IETF-defined Additional Error Causes . . . . . . . . . . 127 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134
13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 127 13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 135
14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 128 13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 135
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 128 13.3. IETF-defined Additional Error Causes . . . . . . . . . . 136
Appendix A. Explicit Congestion Notification . . . . . . . . . . 128 13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 136
Appendix B. Alder 32 bit checksum calculation . . . . . . . . . 130 14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 136
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 131 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137
16.1. Normative references . . . . . . . . . . . . . . . . . . 131 Appendix A. Explicit Congestion Notification . . . . . . . . . . 137
16.2. Informational References . . . . . . . . . . . . . . . . 133 Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 134 Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 141
Intellectual Property and Copyright Statements . . . . . . . . . 135 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
16.1. Normative references . . . . . . . . . . . . . . . . . . 142
16.2. Informational References . . . . . . . . . . . . . . . . 143
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145
Intellectual Property and Copyright Statements . . . . . . . . . 146
1. Introduction 1. Introduction
EDITORS NOTE: Please read! EDITORS NOTE: Please read!
This document is the first version of the BIS for RFC2960. However This document is the first version of the BIS for RFC2960. However
it is a bit unusual in that it represents NO CHANGES from the it is a bit unusual in that it represents NO CHANGES from the
original document (other than these few paragraphs in the original document (other than these few paragraphs in the
introduction). Instead this document is a compilation of RFC2960 introduction). Instead this document is a compilation of RFC2960
converted to XML. In making such a large conversion of a text converted to XML. In making such a large conversion of a text
skipping to change at page 6, line 26 skipping to change at page 6, line 26
by the xml conversion itself. I have tried to assure that these are by the xml conversion itself. I have tried to assure that these are
minimized but they are present. Please inspect this document for minimized but they are present. Please inspect this document for
typos where I may have inadvertently removed text in the conversion typos where I may have inadvertently removed text in the conversion
process. process.
An undertaking represented by this update is not a small feat and An undertaking represented by this update is not a small feat and
represents the considerable effort of both the initial authors of represents the considerable effort of both the initial authors of
RFC2960: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor, RFC2960: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor,
I. Rytina, M. Kalla, L. Zhang, V. Paxson and the authors of the SCTP I. Rytina, M. Kalla, L. Zhang, V. Paxson and the authors of the SCTP
implementors guide: I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. implementors guide: I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen.
Add to this the efforts of all the subsequent eight SCTP inter- Add to this the efforts of all the subsequent seven SCTP inter-
operability tests and you have this document. My thanks cannot be operability tests and you have this document. My thanks cannot be
adequately expressed for all of you who have participated in the adequately expressed for all of you who have participated in the
coding, testing and updating process of this document all I can say coding, testing and updating process of this document all I can say
is Thank You! is Thank You!
Randall Stewart - Editor Randall Stewart - Editor
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
skipping to change at page 15, line 10 skipping to change at page 15, line 10
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 o Stream Sequence Number: A 16-bit sequence number used internally
by SCTP to assure sequenced delivery of the user messages within a by SCTP to assure 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: Verification Tags from a previous association. These o Tie-Tags: Two 32-bit random numbers that together make a 64- bit
Tags are used within a State Cookie so that the newly restarting nonce. These Tags are used within a State Cookie and TCB so that
association can be linked to the original association within the a newly restarting association can be linked to the original
endpoint that did not restart. association within the endpoint that did not restart and yet not
reveal the true Verification Tags of an existing association.
o Transmission Control Block (TCB): An internal data structure o Transmission Control Block (TCB): An internal data structure
created by an SCTP endpoint for each of its existing SCTP created by an SCTP endpoint for each of its existing SCTP
associations to other SCTP endpoints. TCB contains all the status associations to other SCTP endpoints. TCB contains all the status
and operational information for the endpoint to maintain and and operational information for the endpoint to maintain and
manage the corresponding association. manage the corresponding association.
o Transmission Sequence Number (TSN): A 32-bit sequence number used o 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
skipping to change at page 18, line 24 skipping to change at page 18, line 24
| 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. identify the association to which this packet belongs. The port
number 0 MUST NOT be used.
Destination Port Number: 16 bits (unsigned integer) Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined. This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application. SCTP packet to the correct receiving endpoint/application. The
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
skipping to change at page 20, line 40 skipping to change at page 20, line 40
Chunk Types are encoded such that the highest-order two bits Chunk Types are encoded such that the highest-order two 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 Chunk Type. does not 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 parameter in an 'Unrecognized Parameter Type' unrecognized chunk in an 'Unrecognized Chunk Type'.
(in either an ERROR or in the INIT ACK).
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). Explicit Congestion Notification (ECN).
Chunk Flags: 8 bits Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the The usage of these bits depends on the chunk type as given by the
Chunk Type. Unless otherwise specified, they are set to zero on Chunk Type. Unless otherwise specified, they are set to zero on
transmit and are ignored on receipt. transmit and are ignored on receipt.
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the This value represents the size of the chunk in bytes, including
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any field will be set to 4. The Chunk Length field does not count any
padding. chunk padding.
Chunks (including Type, Length, and Value fields) are padded out
by the sender with all zero bytes to be a multiple of 4 bytes
long. This padding MUST NOT be more than 3 bytes in total. The
Chunk Length value does not include terminating padding of the
chunk. However, it does include padding of any variable-length
parameter except the last parameter in the chunk. The receiver
MUST ignore the padding.
Note: A robust implementation should accept the Chunk whether or
not the final padding has been included in the Chunk Length.
Chunk Value: variable length Chunk Value: variable length
The Chunk Value field contains the actual information to be The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type. dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields) The total length of a chunk (including Type, Length, and Value
MUST be a multiple of 4 bytes. If the length of the chunk is not a fields) MUST be a multiple of 4 bytes. If the length of the chunk is
multiple of 4 bytes, the sender MUST pad the chunk with all zero not a multiple of 4 bytes, the sender MUST pad the chunk with all
bytes and this padding is not included in the chunk length field. zero bytes, and this padding is not included in the chunk length
The sender should never pad with more than 3 bytes. The receiver field. The sender should never pad with more than 3 bytes. The
MUST ignore the padding bytes. receiver 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 guidelines for IETF-defined chunk extensions can be found in
Section 13.1 of this document. Section 13.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
skipping to change at page 22, line 36 skipping to change at page 23, line 5
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 SHOULD NOT pad with more than 3 parameter length field. A sender SHOULD 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 two The Parameter Types are encoded such that the highest-order two
bits specify the action that must be taken if the processing bits specify the action that must be taken if the processing
endpoint does not recognize the Parameter Type. endpoint does not recognize the Parameter Type.
00 - Stop processing this SCTP packet and discard it, do not 00 - Stop processing this parameter; do not process any further
process any further chunks within it. parameters within this chunk.
01 - Stop processing this SCTP packet and discard it, do not 01 - Stop processing this parameter, do not process any further
process any further chunks within it, and report the parameters within this chunk, and report the unrecognized
unrecognized parameter in an 'Unrecognized Parameter Type' parameter in an 'Unrecognized Parameter', as described in
(in either an ERROR or in the INIT ACK). 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 Type' unrecognized parameter in an 'Unrecognized Parameter', as
(in either an ERROR or in the INIT ACK). described in Section 3.2.2.
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 after the unknown parameter is canceled, but no
processing already 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 13.2. defined in Section 13.2. Note that a parameter type MUST be
unique across all chunks. For example, the parameter type '5' is
used to represent an IPv4 address (see Section 3.2.2). The value
'5' then is reserved across all chunks to represent an IPv4
address and MUST NOT be reused with a different meaning in any
other chunk.
3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters and
has to report them according to Section 3.2.1, it MUST put the
'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in
response to the INIT-chunk. Note that if the receiver of the INIT
chunk is NOT going to establish an association (e.g., due to lack of
resources), an 'Unrecognized Parameter' would NOT be included with
any ABORT being sent to the sender of the INIT.
If the receiver of an INIT-ACK chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it SHOULD bundle
the ERROR chunk containing the 'Unrecognized Parameters' error cause
with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately but not
before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
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
skipping to change at page 25, line 20 skipping to change at page 26, line 16
When a user message is fragmented by SCTP for transport, the same When a user message is fragmented by SCTP for transport, the same
stream sequence number MUST be carried in each of the fragments of stream sequence number MUST be carried in each of the fragments of
the message. the message.
Payload Protocol Identifier: 32 bits (unsigned integer) Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by SCTP layer and sent to its peer. This identifier is not used by SCTP
but can be used by certain network entities as well as the peer but can be used by certain network entities, as well as by the
application to identify the type of information being carried in peer application, to identify the type of information being
this DATA chunk. This field must be sent even in fragmented DATA carried in this DATA chunk. This field must be sent even in
chunks (to make sure it is available for agents in the middle of fragmented DATA chunks (to make sure it is available for agents in
the network). the middle of the network). Note that this field is NOT touched
by an SCTP implementation, therefore its byte order is NOT
necessarily Big Endian. The upper layer is responsible for any
byte order conversions to this field.
The value 0 indicates no application identifier is specified by The value 0 indicates no application identifier is specified by
the upper layer for this payload data. the upper layer for this payload data.
User Data: variable length User Data: variable length
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.
skipping to change at page 27, line 9 skipping to change at page 28, line 9
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
receiver of INIT MUST ignore any other address types if the Host Name receiver of INIT MUST ignore any other address types if the Host Name
address parameter is present in the received INIT chunk. address paramete`r is present in the received INIT chunk.
Note 4: This parameter, when present, specifies all the address types Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address type. indicates that the sending endpoint can support any address type.
IMPLEMENTATION NOTE: If an INIT chunk is received with known
parameters that are not optional parameters of the INIT chunk then
the receiver SHOULD process the INIT chunk and send back an INIT-ACK.
The receiver of the INIT chunk MAY bundle an ERROR chunk with the
COOKIE-ACK chunk later. However, restrictive implementations MAY
send back an ABORT chunk in response to the INIT chunk.
The Chunk Flags field in INIT is reserved and all bits in it should The Chunk Flags field in INIT is reserved and all bits in it should
be set to 0 by the sender and ignored by the receiver. The sequence be set to 0 by the sender and ignored by the receiver. The sequence
of parameters within an INIT can be processed in any order. of parameters within an INIT can be processed in any order.
Initiate Tag: 32 bits (unsigned integer) Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT (the responding end) records the value of The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP packet that the receiver of Verification Tag field of every SCTP packet that the receiver of
the INIT transmits within this association. the INIT transmits within this association.
skipping to change at page 32, line 34 skipping to change at page 33, line 34
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.
If the value of the Initiate Tag in a received INIT ACK chunk is If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST treat it as an error and close found to be 0, the receiver MUST destroy the association
the association by transmitting an ABORT. discarding its TCB. The receiver MAY send an ABORT for debugging
purpose.
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer) integer)
This value represents the dedicated buffer space, in number of This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT ACK has reserved in association with bytes, the sender of the INIT ACK has reserved in association with
this window. During the life of the association this buffer space this window. During the life of the association this buffer space
SHOULD not be lessened (i.e. dedicated buffers taken away from SHOULD not be lessened (i.e. dedicated buffers taken away from
this association). this association).
Number of Outbound Streams (OS): 16 bits (unsigned integer) Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST chunk wishes to create in this association. The value of 0 MUST
NOT be used. NOT be used, and the value MUST NOT be greater than the MIS value
sent in the INIT chunk.
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB. destroy the association discarding its TCB.
Number of Inbound Streams (MIS) : 16 bits (unsigned integer) Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT ACK Defines the maximum number of streams the sender of this INIT ACK
chunk allows the peer end to create in this association. The chunk allows the peer end to create in this association. The
value 0 MUST NOT be used. value 0 MUST NOT be used.
skipping to change at page 33, line 40 skipping to change at page 34, line 40
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 Parameters 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
skipping to change at page 34, line 18 skipping to change at page 35, line 18
INIT ACK. The receiver of the INIT ACK MUST ignore any other address INIT ACK. The receiver of the INIT ACK MUST ignore any other address
types if the Host Name address parameter is present. types if the Host Name address parameter is present.
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a
INIT ACK that is quite large (more than 1500 bytes) due to the INIT ACK that is quite large (more than 1500 bytes) due to the
variable size of the state cookie AND the variable address list. For variable size of the state cookie AND the variable address list. For
example if a responder to the INIT has 1000 IPv4 addresses it wishes example if a responder to the INIT has 1000 IPv4 addresses it wishes
to send, it would need at least 8,000 bytes to encode this in the to send, it would need at least 8,000 bytes to encode this in the
INIT ACK. INIT ACK.
IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
parameters that are not optional parameters of the INIT-ACK chunk,
then the receiver SHOULD process the INIT-ACK chunk and send back a
COOKIE-ECHO. The receiver of the INIT-ACK chunk MAY bundle an ERROR
chunk with the COOKIE-ECHO chunk. However, restrictive
implementations MAY send back an ABORT chunk in response to the INIT-
ACK chunk.
In combination with the Source Port carried in the SCTP common In combination with the Source Port carried in the SCTP common
header, each IP Address parameter in the INIT ACK indicates to the header, each IP Address parameter in the INIT ACK indicates to the
receiver of the INIT ACK a valid transport address supported by the receiver of the INIT ACK a valid transport address supported by the
sender of the INIT ACK for the lifetime of the association being sender of the INIT ACK for the lifetime of the association being
initiated. initiated.
If the INIT ACK contains at least one IP Address parameter, then the If the INIT ACK contains at least one IP Address parameter, then the
source address of the IP datagram containing the INIT ACK and any source address of the IP datagram containing the INIT ACK and any
additional address(es) provided within the INIT ACK may be used as additional address(es) provided within the INIT ACK may be used as
destinations by the receiver of the INIT-ACK. If the INIT ACK does destinations by the receiver of the INIT-ACK. If the INIT ACK does
skipping to change at page 35, line 10 skipping to change at page 36, line 15
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 Parameters: 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 which has a value when the INIT contains an unrecognized parameter which has a value
that indicates that it should be reported to the sender. This that indicates that 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 Value from the INIT chunk complete with Parameter Type, Length and Value
fields. fields.
3.3.4. Selective Acknowledgement (SACK) (3): 3.3.4. Selective Acknowledgement (SACK) (3):
This chunk is sent to the peer endpoint to acknowledge received DATA This chunk is sent to the peer endpoint to acknowledge received DATA
chunks and to inform the peer endpoint of gaps in the received chunks and to inform the peer endpoint of gaps in the received
subsequences of DATA chunks as represented by their TSNs. subsequences of DATA chunks as represented by their TSNs.
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver
Window Credit (a_rwnd) parameters. Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of
Duplicate TSNs fields.
By definition, the value of the Cumulative TSN Ack parameter is the By definition, the value of the Cumulative TSN Ack parameter is the
last TSN received before a break in the sequence of received TSNs last TSN received before a break in the sequence of received TSNs
occurs; the next TSN value following this one has not yet been occurs; the next TSN value following this one has not yet been
received at the endpoint sending the SACK. This parameter therefore received at the endpoint sending the SACK. This parameter therefore
acknowledges receipt of all TSNs less than or equal to its value. acknowledges receipt of all TSNs less than or equal to its value.
The handling of a_rwnd by the receiver of the SACK is discussed in 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.
skipping to change at page 36, line 40 skipping to change at page 37, line 41
| Duplicate TSN X | | Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to all zeros on transmit and ignored on receipt. Set to all zeros 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. 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.
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.
Number of Gap Ack Blocks: 16 bits (unsigned integer) Number of Gap Ack Blocks: 16 bits (unsigned integer)
Indicates the number of Gap Ack Blocks included in this SACK. Indicates the number of Gap Ack Blocks included in this SACK.
Number of Duplicate TSNs: 16 bit Number of Duplicate TSNs: 16 bit
This field contains the number of duplicate TSNs the endpoint has This field contains the number of duplicate TSNs the endpoint has
received. Each duplicate TSN is listed following the Gap Ack received. Each duplicate TSN is listed following the Gap Ack
Block list. Block list.
Gap Ack Blocks: Gap Ack Blocks:
These fields contain the Gap Ack Blocks. They are repeated for These fields contain the Gap Ack Blocks. They are repeated for
each Gap Ack Block up to the number of Gap Ack Blocks defined in each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with TSNs the Number of Gap Ack Blocks field. All DATA chunks with TSNs
greater than or equal to (Cumulative TSN Ack + Gap Ack Block greater than or equal to (Cumulative TSN Ack + Gap Ack Block
skipping to change at page 40, line 47 skipping to change at page 42, line 10
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 the reason of the abort. DATA chunks MUST NOT be the receiver 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 placed before the ABORT in the SCTP packet, or they will be ignored
by the receiver. by the receiver.
If an endpoint receives an ABORT with a format error or for an If an endpoint receives an ABORT with a format error or no TCB is
association that doesn't exist, it MUST silently discard it. found, it MUST silently discard it. Moreover, under any
Moreover, under any circumstances, an endpoint that receives an ABORT circumstances, an endpoint that receives an ABORT MUST NOT respond to
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 had a TCB that it destroyed. The T bit is set to 0 if the sender filled in the Verification Tag
If the sender did not have a TCB it should set this bit to 1. expected by the peer. If the Verification Tag is reflected, the T
bit MUST be set to 1. Reflecting means that 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, please
see Section 8.5.1 for details. 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.
skipping to change at page 44, line 18 skipping to change at page 45, line 18
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
12 User Initiated Abort
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.10 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 13.3. discussed in Section 13.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
skipping to change at page 49, line 15 skipping to change at page 50, line 23
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 SHUTDOWN-ACK-SENT state. This error is usually the endpoint was in SHUTDOWN-ACK-SENT state. This error is usually
returned in an ERROR chunk bundled with the retransmitted SHUTDOWN returned in an ERROR chunk bundled with the retransmitted SHUTDOWN
ACK. 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)
Cause of error
--------------
Restart of an association with new addresses: An INIT was received on
an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
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).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Parameter length.
3.3.10.12. User-Initiated Abort (12)
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent
because of an upper layer request. The upper layer can specify an
Upper Layer Abort Reason that is transported by SCTP transparently
and MAY be delivered to the upper layer protocol at the peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.13. Protocol Violation (13)
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent
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
to Section 3.3.10.12. An implementation MAY provide additional
information specifying what kind of protocol violation has been
detected.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 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
skipping to change at page 50, line 5 skipping to change at page 52, line 31
the chunk header and the size of the Cookie. the chunk header and the size of the Cookie.
Cookie: variable size Cookie: variable size
This field must contain the exact cookie received in the State This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK. Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible to An implementation SHOULD make the cookie as small as possible to
insure interoperability. insure interoperability.
Note: A Cookie Echo does NOT contain a State Cookie Parameter;
instead, the data within the State Cookie's Parameter Value
becomes the data within the Cookie Echo's Chunk Value. This
allows an implementation to change only the first two bytes of the
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 in the same SCTP packet. chunk 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
skipping to change at page 50, line 45 skipping to change at page 53, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 had a TCB that it destroyed. The T bit is set to 0 if the sender filled in the Verification Tag
If the sender did not have a TCB it should set this bit to 1. expected by the peer. If the Verification Tag is reflected, the T
bit MUST be set to 1. Reflecting means that the sent Verification
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 lifetime of an SCTP association, the SCTP endpoint's During the lifetime of an SCTP association, the SCTP endpoint's
association progress from one state to another in response to various association progress from one state to another in response to various
events. The events that may potentially advance an association's events. The events that may potentially advance an association's
state include: state include:
skipping to change at page 56, line 14 skipping to change at page 58, line 51
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.
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter parameters in the received INIT or INIT ACK, invalid parameter
values, or lack of local resources, it MUST respond with an ABORT values, or lack of local resources, it SHOULD respond with an ABORT
chunk. It SHOULD also specify the cause of abort, such as the type chunk. It SHOULD also specify the cause of abort, such as the type
of the missing mandatory parameters, etc., by including the error of the missing mandatory parameters, etc., by including the error
cause parameters with the ABORT chunk. The Verification Tag field in cause parameters with the ABORT chunk. The Verification Tag field in
the common header of the outbound SCTP packet containing the ABORT the common header of the outbound SCTP packet containing the ABORT
chunk MUST be set to the Initiate Tag value of the peer. chunk MUST be set to the Initiate Tag value of the peer.
Note that a COOKIE ECHO chunk that does NOT pass the integrity check
is NOT considered an 'invalid parameter' and requires special
handling see Section 5.1
After the reception of the first DATA chunk in an association the After the reception of the first DATA chunk in an association the
endpoint MUST immediately respond with a SACK to acknowledge the DATA endpoint MUST immediately respond with a SACK to acknowledge the DATA
chunk. Subsequent acknowledgements should be done as described in chunk. Subsequent acknowledgements should be done as described in
Section 6.2. Section 6.2.
When the TCB is created, each endpoint MUST set its internal When the TCB is created, each endpoint MUST set its internal
Cumulative TSN Ack Point to the value of its transmitted Initial TSN Cumulative TSN Ack Point to the value of its transmitted Initial TSN
minus one. minus one.
IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally
used as the key to find the TCB within an SCTP instance. used as the key to find the TCB within an SCTP instance.
5.1.1. Handle Stream Parameters 5.1.1. Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall In the INIT and INIT ACK chunks, the sender of the chunk MUST
indicate the number of outbound streams (OS) it wishes to have in the indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint. accept from the other endpoint.
After receiving the stream configuration information from the other After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's side, each endpoint MUST perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST either use MIS outbound streams, or to configure, the endpoint MUST use MIS outbound streams and MAY
abort the association and report to its upper layer the resources report any shortage to the upper layer. The upper layer can then
shortage at its peer. choose to abort the association if the resource shortage is
unacceptable.
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.
skipping to change at page 58, line 7 skipping to change at page 61, line 6
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 INIT
or INIT ACK chunk, the receiver shall derive and record all the or INIT ACK chunk, the receiver MUST derive and record all the
transport address(es) from the received chunk AND the source IP transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es) 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 INIT
or INIT ACK chunk and the source IP address of the IP datagram. or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to destination transport addresses when sending subsequent packets to
its peer. its peer.
D) An INIT or INIT ACK chunk MUST be treated as belonging to an
already established association (or one in the process of being
established) if the use of any of the valid address parameters
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 58, line 44 skipping to change at page 61, line 47
association with an "Unresolvable Address" error cause if it is association with an "Unresolvable Address" error cause if it is
unwilling or incapable of using any of the address types indicated by unwilling or incapable of using any of the address types indicated by
its peer. its peer.
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type, it fails to resolve the address parameter due to an unsupported type, it
can abort the initiation process and then attempt a re-initiation by can abort the initiation process and then attempt a re-initiation by
using a 'Supported Address Types' parameter in the new INIT to using a 'Supported Address Types' parameter in the new INIT to
indicate what types of address it prefers. indicate what types of address it prefers.
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT- ACK
chunk from its peer, it MUST use all the addresses belonging to the
supported address family. The other addresses MAY be ignored. The
endpoint SHOULD NOT respond with any kind of error indication.
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
Address Types' parameter either IPv4 or IPv6, but uses the other
family for sending the packet containing the INIT chunk, or if it
also lists addresses of the other family in the INIT chunk, then the
address family that is not listed in the 'Supported Address Types'
parameter SHOULD also be considered as supported by the receiver of
the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond
with any kind of error indication.
5.1.3. Generating State Cookie 5.1.3. Generating State Cookie
When sending an INIT ACK as a response to an INIT chunk, the sender When sending an INIT ACK as a response to an INIT chunk, the sender
of INIT ACK creates a State Cookie and sends it in the State Cookie of INIT ACK creates a State Cookie and sends it in the State Cookie
parameter of the INIT ACK. Inside this State Cookie, the sender parameter of the INIT ACK. Inside this State Cookie, the sender
should include a MAC (see [RFC2104] for an example), a time stamp on should include a MAC (see [RFC2104] for an example), a time stamp on
when the State Cookie is created, and the lifespan of the State when the State Cookie is created, and the lifespan of the State
Cookie, along with all the information necessary for it to establish Cookie, along with all the information necessary for it to establish
the association. the association.
skipping to change at page 60, line 21 skipping to change at page 63, line 38
1) Compute a MAC using the TCB data carried in the State Cookie and 1) Compute a MAC using the TCB data carried in the State Cookie and
the secret key (note the timestamp in the State Cookie MAY be used the secret key (note the timestamp in the State Cookie MAY be used
to determine which secret key to use). Reference [RFC2104] can be to determine which secret key to use). Reference [RFC2104] can be
used as a guideline for generating the MAC, used as a guideline for generating the MAC,
2) Authenticate the State Cookie as one that it previously generated 2) Authenticate the State Cookie as one that it previously generated
by comparing the computed MAC against the one carried in the State by comparing the computed MAC against the one carried in the State
Cookie. If this comparison fails, the SCTP packet, including the Cookie. If this comparison fails, the SCTP packet, including the
COOKIE ECHO and any DATA chunks, should be silently discarded, COOKIE ECHO and any DATA chunks, should be silently discarded,
3) Compare the creation timestamp in the State Cookie to the current 3) Compare the port numbers and the Verification Tag contained within
the COOKIE ECHO chunk to the actual port numbers and the
Verification Tag within the SCTP common header of the received
packet. If these values do not match, the packet MUST be silently
discarded.
4) Compare the creation timestamp in the State Cookie to the current
local time. If the elapsed time is longer than the lifespan local time. If the elapsed time is longer than the lifespan
carried in the State Cookie, then the packet, including the COOKIE carried in the State Cookie, then the packet, including the COOKIE
ECHO and any attached DATA chunks, SHOULD be discarded and the ECHO and any attached DATA chunks, SHOULD be discarded, and the
endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error
cause to the peer endpoint, cause to the peer endpoint.
4) If the State Cookie is valid, create an association to the sender 5) If the State Cookie is valid, create an association to the sender
of the COOKIE ECHO chunk with the information in the TCB data of the COOKIE ECHO chunk with the information in the TCB data
carried in the COOKIE ECHO, and enter the ESTABLISHED state, carried in the COOKIE ECHO and enter the ESTABLISHED state.
5) Send a COOKIE ACK chunk to the peer acknowledging reception of the 6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the
COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA
chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk or SACK chunk; however, the COOKIE ACK MUST be the first
chunk in the SCTP packet. chunk in the SCTP packet.
6) Immediately acknowledge any DATA chunk bundled with the COOKIE 7) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step follow the rules defined in Section 6.2). As mentioned in step 5,
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST
MUST appear first in the SCTP packet. appear first in the SCTP packet.
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=1 & 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=1 & 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=2 & 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 6.3 to determine the proper timer value. defined in 6.3 to determine the proper timer value.
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
COOKIE ACK COOKIE ACK
During the lifetime of an association (in one of the possible During the lifetime of an association (in one of the possible
states), an endpoint may receive from its peer endpoint one of the states), an endpoint may receive from its peer endpoint one of the
setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The
receiver shall treat such a setup chunk as a duplicate and process it receiver shall treat such a setup chunk as a duplicate and process it
skipping to change at page 62, line 50 skipping to change at page 66, line 48
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.
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
endpoint MUST respond with an INIT ACK using the same parameters it respond with an INIT ACK using the same parameters it sent in its
sent in its original INIT chunk (including its Initiation Tag, original INIT chunk (including its Initiation Tag, unchanged). When
unchanged). These original parameters are combined with those from responding, the endpoint MUST send the INIT ACK back to the same
the newly received INIT chunk. The endpoint shall also generate a address that the original INIT (sent by this endpoint) was sent to.
State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie. Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged),
provided that no NEW address has been added to the forming
association. If the INIT message indicates that a new address has
been added to the association, then the entire INIT MUST be
discarded, and NO changes should be made to the existing association.
An ABORT SHOULD be sent in response that MAY include the error
'Restart of an association with new addresses'. The error SHOULD
list the addresses that were added to the restarting association.
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
an INIT ACK, the original parameters are combined with those from the
newly received INIT chunk. The endpoint shall also generate a State
Cookie with the INIT ACK. The endpoint uses the parameters sent in
its INIT to calculate the State Cookie.
After that, the endpoint MUST NOT change its state, the T1-init timer After that, the endpoint MUST NOT change its state, the T1-init timer
shall be left running and the corresponding TCB MUST NOT be shall be left running and the corresponding TCB MUST NOT be
destroyed. The normal procedures for handling State Cookies when a destroyed. The normal procedures for handling State Cookies when a
TCB exists will resolve the duplicate INITs to a single association. TCB exists will resolve the duplicate INITs to a single association.
For an endpoint that is in the COOKIE-ECHOED state it MUST populate For an endpoint that is in the COOKIE-ECHOED state it MUST populate
its Tie-Tags with the Tag information of itself and its peer (see its Tie-Tags within both the association TCB and inside the State
Section 5.2.2 for a description of the Tie-Tags). Cookie (see Section 5.2.2 for a description of the Tie-Tags).
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE- 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-
ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for Unless otherwise stated, upon receipt of an unexpected INIT for this
this association, the endpoint shall generate an INIT ACK with a association, the endpoint shall generate an INIT ACK with a State
State Cookie. In the outbound INIT ACK the endpoint MUST copy its Cookie. Before responding, the endpoint MUST check to see if the
current Verification Tag and peer's Verification Tag into a reserved unexpected INIT adds new addresses to the association. If new
place within the state cookie. We shall refer to these locations as addresses are added to the association, the endpoint MUST respond
the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet with an ABORT, copying the 'Initiation Tag' of the unexpected INIT
containing this INIT ACK MUST carry a Verification Tag value equal to into the 'Verification Tag' of the outbound packet carrying the
the Initiation Tag found in the unexpected INIT. And the INIT ACK ABORT. In the ABORT response, the cause of error MAY be set to
MUST contain a new Initiation Tag (randomly generated see 'restart of an association with new addresses'. The error SHOULD
list the addresses that were added to the restarting association. If
no new addresses are added, when responding to the INIT in the
outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a
reserved place within the State Cookie and the association's TCB. We
shall refer to these locations inside the cookie as the Peer's-Tie-
Tag and the Local-Tie-Tag. We will refer to the copy within an
association's TCB as the Local Tag and Peer's Tag. The outbound SCTP
packet containing this INIT ACK MUST carry a Verification Tag value
equal to the Initiation Tag found in the unexpected INIT. And the
INIT ACK MUST contain a new Initiation Tag (randomly generated; see
Section 5.3.1). Other parameters for the endpoint SHOULD be copied Section 5.3.1). Other parameters for the endpoint SHOULD be copied
from the existing parameters of the association (e.g. number of from the existing parameters of the association (e.g., number of
outbound streams) into the INIT ACK and cookie. outbound streams) into the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further After sending out the INIT ACK or ABORT, the endpoint shall take no
actions, i.e., the existing association, including its current state, further actions; i.e., the existing association, including its
and the corresponding TCB MUST NOT be changed. current state, and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE- Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT state are the Tie-Tags populated. For a normal association INIT WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a
(i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be value other than 0. For a normal association INIT (i.e., the
set to 0 (indicating that no previous TCB existed). The INIT ACK and endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
State Cookie are populated as specified in section 5.2.1. (indicating that no previous TCB existed).
5.2.3. Unexpected INIT ACK 5.2.3. Unexpected INIT ACK
If an INIT ACK is received by an endpoint in any state other than the If an INIT ACK is received by an endpoint in any state other than the
COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk. COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk.
An unexpected INIT ACK usually indicates the processing of an old or An unexpected INIT ACK usually indicates the processing of an old or
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
skipping to change at page 64, line 23 skipping to change at page 68, line 43
2) Authenticate the State Cookie as described in Step 2 of 2) Authenticate the State Cookie as described in Step 2 of
Section 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. If 3) Compare the timestamp in the State Cookie to the current time. If
the State Cookie is older than the lifespan carried in the State the State Cookie is older than the lifespan carried in the State
Cookie and the Verification Tags contained in the State Cookie do Cookie and the Verification Tags contained in the State Cookie do
not match the current association's Verification Tags, the packet, not match the current association's Verification Tags, the packet,
including the COOKIE ECHO and any DATA chunks, should be including the COOKIE ECHO and any DATA chunks, should be
discarded. The endpoint also MUST transmit an ERROR chunk with a discarded. The endpoint also MUST transmit an ERROR chunk with a
"Stale Cookie" error cause to the peer endpoint (this is case C or "Stale Cookie" error cause to the peer endpoint (this is case C or
D in section 5.2). 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 of section 5.2) even if the lifespan Cookie valid (this is case E of 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.
skipping to change at page 66, line 24 skipping to change at page 70, line 29
Tag from the State Cookie, stop any init or cookie timers that may Tag from the State Cookie, stop any init or cookie timers that may
running and send a COOKIE ACK. 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 an
INIT-ACK and finally sent a COOKIE ECHO with the peer's same tag INIT-ACK and finally sent a COOKIE ECHO with the peer's same tag
but a new tag of its own. The cookie should be silently 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 leave
any timers running. any timers running.
D) When both local and remote tags match the endpoint should always D) When both local and remote tags match, the endpoint should enter
enter the ESTABLISHED state, if it has not already done so. It the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It
should stop any init or cookie timers that may be running and send should stop any cookie timer that may be running and send a COOKIE
a COOKIE ACK. 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 67, line 33 skipping to change at page 71, line 33
& other info] & other info]
(destroy temp TCB,leave original (destroy temp TCB,leave original
in place) in place)
COOKIE ECHO [Veri=Tag_Z', COOKIE ECHO [Veri=Tag_Z',
Cookie_Z Cookie_Z
Tie=Tag_A, Tie=Tag_A,
Tag_Z]----------\ Tag_Z]----------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association, (Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags, Tie-Tags match old tags,
Tags do not match i.e. Tags do not match i.e.,
case X X M M above, case X X M M above,
Announce Restart to ULP Announce Restart to ULP
and reset association). and reset association).
/---- COOKIE-ACK /---- COOKIE-ACK
/ (Cancel T1-init timer, <------/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state) Enter ESTABLISHED state)
{app sends 1st user data; strm 0} {app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\ Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \ (Start T3-rtx timer) \
\-> \->
/----- SACK [TSN Ack=init TSN_A,Block=0] /--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/ (Cancel T3-rtx timer) <------/
Figure 5: A Restart Example Figure 5: A Restart Example
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
skipping to change at page 69, line 17 skipping to change at page 73, line 17
also necessary to prevent old duplicate packets from previous also necessary to prevent old duplicate packets from previous
associations being mistakenly processed as belonging to the current associations being mistakenly processed as belonging to the current
association. association.
Moreover, the Verification Tag value used by either endpoint in a Moreover, the Verification Tag value used by either endpoint in a
given association MUST NOT change during the lifetime of an given association MUST NOT change during the lifetime of an
association. A new Verification Tag value MUST be used each time the association. A new Verification Tag value MUST be used each time the
endpoint tears-down and then re-establishes an association to the endpoint tears-down and then re-establishes an association to the
same peer. same peer.
5.4. Path Verification
During association establishment, the two peers exchange a list of
addresses. In the predominant case, these lists accurately represent
the addresses owned by each peer. However, it is possible that a
misbehaving peer may supply addresses that it does not own. To
prevent this, the following rules are applied to all addresses of the
new association:
1) Any address passed to the sender of the INIT by its upper layer is
automatically considered to be CONFIRMED.
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
the one that the INIT-ACK was sent to.
3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send
HEARTBEATs including a 64-bit random nonce and a path indicator (to
identify the address that the HEARTBEAT is sent to) within the
HEARTBEAT parameter.
Upon receipt of the HEARTBEAT-ACK, a verification is made that the
nonce included in the HEARTBEAT parameter is the one sent to the
address indicated inside the HEARTBEAT parameter. When this match
occurs, the address that the original HEARTBEAT was sent to is now
considered CONFIRMED and available for normal data transfer.
These probing procedures are started when an association moves to the
ESTABLISHED state and are ended when all paths are confirmed.
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
the path becomes inactive, this rate is lowered to the normal
HEARTBEAT rate. At the expiration of the RTO timer, the error
counter of any path that was probed but not CONFIRMED is incremented
by one and subjected to path failure detection, as defined in
Section 8.2. When probing UNCONFIRMED addresses, however, the
association overall error count is NOT incremented.
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
to distribute HEARTBEATS to the peer's addresses for path
verification.
Whenever a path is confirmed, an indication MAY be given to the upper
layer.
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
the following exceptions:
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
address.
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
bundled with a HEARTBEAT including a nonce. An implementation
that does NOT support bundling MUST NOT send a COOKIE-ACK to an
UNCONFIRMED address.
- A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
bundled with a HEARTBEAT including a nonce, and the packet MUST
NOT exceed the path MTU. If the implementation does NOT support
bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
nonce) would exceed the path MTU, then the implementation MUST NOT
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
that DATA chunks are allowed to be bundled with an outbound COOKIE that DATA chunks are allowed to be bundled with an outbound COOKIE
ECHO chunk when in COOKIE-WAIT state. ECHO chunk when in COOKIE-WAIT state.
DATA chunks MUST only be received according to the rules below in DATA chunks MUST only be received according to the rules below in
ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received
in CLOSED is out of the blue and SHOULD be handled per 8.4. A DATA in CLOSED is out of the blue and SHOULD be handled per 8.4. A DATA
skipping to change at page 71, line 10 skipping to change at page 76, line 20
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 that the peer has no buffer space (i.e., rwnd is 0; see
Section 6.2.1). However, regardless of the value of rwnd Section 6.2.1). However, regardless of the value of rwnd
(including if it is 0), the data sender can always have one DATA (including if it is 0), the data sender can always have one DATA
chunk in flight to the receiver if allowed by cwnd (see rule B chunk in flight to the receiver if allowed by cwnd (see rule B,
below). This rule allows the sender to probe for a change in rwnd below). This rule allows the sender to probe for a change in rwnd
that the sender missed due to the SACK having been lost in transit that the sender missed due to the SACK's having been lost in
from the data 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
called a zero window probe. Note that a zero window probe SHOULD
only be sent when all outstanding DATA chunks have been
cumulatively acknowledged and no DATA chunks are in flight. Zero
window probing MUST be supported.
If the sender continues to receive new packets from the receiver
while doing zero window probing, the unacknowledged window probes
should not increment the error counter for the association or any
destination transport address.This is because the receiver MAY
keep its window closed for an indefinite time. Refer to
Section 6.2 on the receiver behavior when it advertises a zero
window. The sender SHOULD send the first zero window probe after
1 RTO when it detects that the receiver has closed its window and
SHOULD increase the probe interval exponentially afterwards. Also
note that the cwnd SHOULD be adjusted according to 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
to avoid silly window syndrome (SWS) as described in [RFC0813].
The algorithm can be similar to the one described in Section
4.2.3.4 of [RFC1122].
that the peer has no buffer space (i.e. rwnd is 0, see ).
However, regardless of the value of rwnd (including if it is 0),
the data sender can always have one DATA chunk in flight to the
receiver if allowed by cwnd (see rule B below). This rule allows
the sender to probe for a change in rwnd that the sender missed
due to the SACK having been lost in transit from the data receiver
to the data sender.
B) At any given time, the sender MUST NOT transmit new data to a 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 new
DATA chunks, the sender MUST first transmit any outstanding DATA DATA chunks, the sender MUST first transmit any outstanding DATA
chunks which are marked for retransmission (limited by the current chunks which are marked for retransmission (limited by the current
cwnd). cwnd).
skipping to change at page 72, line 20 skipping to change at page 78, line 15
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 Section 6.3.2, and adjusted according to the timer rules defined in Section 6.3.2, and
Section 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. DATA chunk when the DATA chunk received is inside its receive window.
When the receiver's advertised window is 0, the receiver MUST drop
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in [RFC0813]. The algorithm can be
similar to the one described in Section 4.2.3.3 of [RFC1122].
The guidelines on delayed acknowledgement algorithm specified in The guidelines on delayed acknowledgement algorithm specified in
Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an
acknowledgement SHOULD be generated for at least every second packet acknowledgement SHOULD be generated for at least every second packet
(not every second DATA chunk) received, and SHOULD be generated (not every second DATA chunk) received, and SHOULD be generated
within 200 ms of the arrival of any unacknowledged DATA chunk. In within 200 ms of the arrival of any unacknowledged DATA chunk. In
some situations it may be beneficial for an SCTP transmitter to be some situations it may be beneficial for an SCTP transmitter to be
more conservative than the algorithms detailed in this document more conservative than the algorithms detailed in this document
allow. However, an SCTP transmitter MUST NOT be more aggressive than allow. However, an SCTP transmitter MUST NOT be more aggressive than
the following algorithms allow. the following algorithms allow.
skipping to change at page 72, line 45 skipping to change at page 79, line 5
IMPLEMENTATION NOTE: The maximum delay for generating an IMPLEMENTATION NOTE: The maximum delay for generating an
acknowledgement may be configured by the SCTP administrator, either acknowledgement may be configured by the SCTP administrator, either
statically or dynamically, in order to meet the specific timing statically or dynamically, in order to meet the specific timing
requirement of the protocol being carried. requirement of the protocol being carried.
An implementation MUST NOT allow the maximum delay to be configured An implementation MUST NOT allow the maximum delay to be configured
to be more than 500 ms. In other words an implementation MAY lower to be more than 500 ms. In other words an implementation MAY lower
this value below 500ms but MUST NOT raise it above 500ms. this value below 500ms but MUST NOT raise it above 500ms.
Acknowledgements MUST be sent in SACK chunks unless shutdown was Acknowledegments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an requested by the ULP, in which case an endpoint MAY send an
acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be greater than the value in the Cumulative TSN Ack field are reported
reported in the Gap Ack Block fields. in the Gap Ack Block fields. The SCTP endpoint MUST report as many
Gap Ack Blocks as can fit in a single SACK chunk limited by the
current path MTU.
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN Therefore, the endpoint should use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order . chunk to acknowledge DATA chunks received out of order .
When a packet arrives with duplicate DATA chunk(s) and with no new When a packet arrives with duplicate DATA chunk(s) and with no new
DATA chunk(s), the endpoint MUST immediately send a SACK with no DATA chunk(s), the endpoint MUST immediately send a SACK with no
delay. If a packet arrives with duplicate DATA chunk(s) bundled with delay. If a packet arrives with duplicate DATA chunk(s) bundled with
new DATA chunks, the endpoint MAY immediately send a SACK. Normally new DATA chunks, the endpoint MAY immediately send a SACK. Normally
receipt of duplicate DATA chunks will occur when the original SACK receipt of duplicate DATA chunks will occur when the original SACK
skipping to change at page 76, line 43 skipping to change at page 82, line 43
monotonically increasing, a SACK whose Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of- less than the Cumulative TSN Ack Point indicates an out-of-
order SACK. 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 number
of bytes still outstanding after processing the Cumulative TSN of bytes still outstanding after processing the Cumulative TSN
Ack and the Gap Ack Blocks. 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 acknowledged
via a Gap Ack Block (e.g., the data receiver reneged on the via a Gap Ack Block (e.g., the data receiver reneged on the
data), then mark the corresponding DATA chunk as available for data), then consider the corresponding DATA that might be
retransmit: Mark it as missing for fast retransmit as described possibly missing: Count one miss indication towards fast
in Section 7.2.4 and if no retransmit timer is running for the retransmit as described in Section 7.2.4 , and if no retransmit
destination address to which the DATA chunk was originally timer is running for the destination address to which the DATA
transmitted, then T3-rtx is started for that destination chunk was originally transmitted, then T3-rtx is started for
address. that destination address.
iv) If the Cumulative TSN Ack matches or exceeds the Fast 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 78, line 9 skipping to change at page 84, line 15
then the values of RTO.Alpha and RTO.Beta in rule C3 above should then the values of RTO.Alpha and RTO.Beta in rule C3 above should
be adjusted so that SRTT and RTTVAR still adjust to changes at be adjusted so that SRTT and RTTVAR still adjust to changes at
roughly the same rate (in terms of how many round trips it takes roughly the same rate (in terms of how many round trips it takes
them to reflect new values) as they would if making only one them to reflect new values) as they would if making only one
measurement per round-trip and using RTO.Alpha and RTO.Beta as measurement per round-trip and using RTO.Alpha and RTO.Beta as
given in rule C3. However, the exact nature of these adjustments given in rule C3. However, the exact nature of these adjustments
remains a research issue. remains a research issue.
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets C5) Karn's algorithm: RTT measurements MUST NOT be made using packets
that were retransmitted (and thus for which it is ambiguous that were retransmitted (and thus for which it is ambiguous
whether the reply was for the first instance of the packet or a whether the reply was for the first instance of the the chunk or
later instance). for a later instance)
IMPLEMENTATION NOTE: RTT measurements should only be made using a
chunk with TSN r if no chunk with TSN less than or equal to r is
retransmitted since r is first sent.
C6) Whenever RTO is computed, if it is less than RTO.Min seconds then C6) Whenever RTO is computed, if it is less than RTO.Min seconds then
it is rounded up to RTO.Min seconds. The reason for this rule is it is rounded up to RTO.Min seconds. The reason for this rule is
that RTOs that do not have a high minimum value are susceptible that RTOs that do not have a high minimum value are susceptible
to unnecessary timeouts [ALLMAN99]. 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
skipping to change at page 81, line 24 skipping to change at page 87, line 34
which the DATA or control chunks being acknowledged were received. which the DATA or control chunks being acknowledged were received.
When a receiver of a duplicate DATA chunk sends a SACK to a multi- When a receiver of a duplicate DATA chunk sends a SACK to a multi-
homed endpoint it MAY be beneficial to vary the destination address homed endpoint it MAY be beneficial to vary the destination address
and not use the source address of the DATA chunk. The reason being and not use the source address of the DATA chunk. The reason being
that receiving a duplicate from a multi-homed endpoint might indicate that receiving a duplicate from a multi-homed endpoint might indicate
that the return path (as specified in the source address of the DATA that the return path (as specified in the source address of the DATA
chunk) for the SACK is broken. chunk) for the SACK is broken.
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk to an active destination transport address that is retransmit a chunk that timed out to an active destination transport
different from the last destination address to which the DATA chunk address that is different from the last destination address to which
was sent. the DATA chunk was sent.
Retransmissions do not affect the total outstanding data count. Retransmissions do not affect the total outstanding data count.
However, if the DATA chunk is retransmitted onto a different However, if the DATA chunk is retransmitted onto a different
destination address, both the outstanding data counts on the new destination address, both the outstanding data counts on the new
destination address and the old destination address to which the data destination address and the old destination address to which the data
chunk was last sent shall be adjusted accordingly. chunk was last sent shall be adjusted accordingly.
6.4.1. Failover from Inactive Destination Address 6.4.1. Failover from Inactive Destination Address
Some of the transport addresses of a multi-homed SCTP endpoint may Some of the transport addresses of a multi-homed SCTP endpoint may
become inactive due to either the occurrence of certain error become inactive due to either the occurrence of certain error
conditions (see Section 8.2) or adjustments from SCTP user. conditions (see Section 8.2) or adjustments from SCTP user.
When there is outbound data to send and the primary path becomes When there is outbound data to send and the primary path becomes
inactive (e.g., due to failures), or where the SCTP user explicitly inactive (e.g., due to failures), or where the SCTP user explicitly
requests to send data to an inactive destination transport address, requests to send data to an inactive destination transport address,
before reporting an error to its ULP, the SCTP endpoint should try to before reporting an error to its ULP, the SCTP endpoint should try to
send the data to an alternate active destination transport address if send the data to an alternate active destination transport address if
one exists. one exists.
When retransmitting data, if the endpoint is multi-homed, it should When retransmitting data that timed out, if the endpoint is multi-
consider each source-destination address pair in its retransmission homed, it should consider each source-destination address pair in its
selection policy. When retransmitting the endpoint should attempt to retransmission selection policy. When retransmitting timed out data,
pick the most divergent source-destination pair from the original the endpoint should attempt to pick the most divergent source-
source-destination pair to which the packet was transmitted. destination pair from the original source-destination pair to which
the packet was transmitted.
Note: Rules for picking the most divergent source-destination pair Note: Rules for picking the most divergent source-destination pair
are an implementation decision and is not specified within this are an implementation decision and is not specified within this
document. document.
6.5. Stream Identifier and Stream Sequence Number 6.5. Stream Identifier and Stream Sequence Number
Every DATA chunk MUST carry a valid stream identifier. If an Every DATA chunk MUST carry a valid stream identifier. If an
endpoint receives a DATA chunk with an invalid stream identifier, it endpoint receives a DATA chunk with an invalid stream identifier, it
shall acknowledge the reception of the DATA chunk following the shall acknowledge the reception of the DATA chunk following the
normal procedure, immediately send an ERROR chunk with cause set to normal procedure, immediately send an ERROR chunk with cause set to
"Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA
chunk. The endpoint may bundle the ERROR chunk in the same packet as chunk. The endpoint may bundle the ERROR chunk in the same packet as
the SACK as long as the ERROR follows the SACK. the SACK as long as the ERROR follows the SACK.
The stream sequence number in all the streams shall start from 0 when The stream sequence number in all the streams MUST start from 0 when
the association is established. Also, when the stream sequence the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall number reaches the value 65535 the next stream sequence number MUST
be set to 0. be set to 0.
6.6. Ordered and Unordered Delivery 6.6. Ordered and Unordered Delivery
Within a stream, an endpoint MUST deliver DATA chunks received with Within a stream, an endpoint MUST deliver DATA chunks received with
the U flag set to 0 to the upper layer according to the order of the U flag set to 0 to the upper layer according to the order of
their stream sequence number. If DATA chunks arrive out of order of their stream sequence number. If DATA chunks arrive out of order of
their stream sequence number, the endpoint MUST hold the received their stream sequence number, the endpoint MUST hold the received
DATA chunks from delivery to the ULP until they are re-ordered. DATA chunks from delivery to the ULP until they are re-ordered.
skipping to change at page 84, line 30 skipping to change at page 90, line 30
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 can not cover all the Gap Ack Blocks needed to be reported due SACK can not cover all the Gap Ack Blocks needed to be reported due
to the MTU limitation, the endpoint MUST send only one SACK, to the MTU limitation, the endpoint MUST send only one SACK,
reporting the Gap Ack Blocks from the lowest to highest TSNs, within reporting the Gap Ack Blocks from the lowest to highest TSNs, within
the size limit set by the MTU, and leave the remaining highest TSN the size limit set by the MTU, and leave the remaining highest TSN
numbers unacknowledged. numbers unacknowledged.
6.8. Adler-32 Checksum Calculation 6.8. CRC-32c Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum integrity of the transmission by including the CRC32c checksum value
value calculated on the packet, as described below. calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall: and one or more control or DATA chunks), the transmitter MUST
1) Fill in the proper Verification Tag in the SCTP common header and 1) fill in the proper Verification Tag in the SCTP common header and
initialize the checksum field to 0's. initialize the checksum field to '0's,
2) Calculate the Adler-32 checksum of the whole packet, including the 2) calculate the CRC32c checksum of the whole packet, including the
SCTP common header and all the chunks. Refer to appendix B for SCTP common header and all the chunks (refer to appendix B for
details of the Adler-32 algorithm. And, details of the CRC32c algorithm); and
3) Put the resultant value into the checksum field in the common 3) put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged. header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum: CRC32c checksum as follows:
1) Store the received Adler-32 checksum value aside, 1) Store the received CRC32c checksum value aside.
2) Replace the 32 bits of the checksum field in the received SCTP 2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value of packet with all '0's and calculate a CRC32c checksum value of the
the whole received packet. And, whole received packet.
3) Verify that the calculated Adler-32 checksum is the same as the 3) Verify that the calculated CRC32c checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat the received CRC32c checksum. If it is not, the receiver MUST treat
packet as an invalid SCTP packet. the packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to The default procedure for handling invalid SCTP packets is to
silently discard them. silently discard them.
Any hardware implementation SHOULD be done in a way that is
verifiable by the software.
6.9. Fragmentation and Reassembly 6.9. Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint it MUST support reassembly when receiving DATA chunks. If an
supports fragmentation, it MUST fragment a user message if the size endpoint supports fragmentation, it MUST fragment a user message if
of the user message to be sent causes the outbound SCTP packet size the size of the user message to be sent causes the outbound SCTP
to exceed the current MTU. If an implementation does not support packet size to exceed the current MTU. If an implementation does not
fragmentation of outbound user messages, the endpoint must return an support fragmentation of outbound user messages, the endpoint MUST
error to its upper layer and not attempt to send the user message. return an error to its upper layer and not attempt to send the user
message.
Note: If an implementation that supports fragmentation makes
available to its upper layer a mechanism to turn off fragmentation it
may do so. However, in so doing, it MUST react just like an
implementation that does NOT support fragmentation, i.e., it MUST
reject sends that exceed the current P-MTU.
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed IMPLEMENTATION NOTE: In this error case, the Send primitive discussed
in Section 10.1 would need to return an error to the upper layer. in Section 10.1 would need to return an error to the upper layer.
If its peer is multi-homed, the endpoint shall choose a size no If its peer is multi-homed, the endpoint shall choose a size no
larger than the association Path MTU. The association Path MTU is larger than the association Path MTU. The association Path MTU is
the smallest Path MTU of all destination addresses. the smallest Path MTU of all destination addresses.
Note: Once a message is fragmented it cannot be re-fragmented. Note: Once a message is fragmented it cannot be re-fragmented.
Instead if the PMTU has been reduced, then IP fragmentation must be Instead if the PMTU has been reduced, then IP fragmentation must be
skipping to change at page 86, line 50 skipping to change at page 93, line 10
When bundling control chunks with DATA chunks, an endpoint MUST place When bundling control chunks with DATA chunks, an endpoint MUST place
control chunks first in the outbound SCTP packet. The transmitter control chunks first in the outbound SCTP packet. The transmitter
MUST transmit DATA chunks within a SCTP packet in increasing order of MUST transmit DATA chunks within a SCTP packet in increasing order of
TSN. TSN.
Note: Since control chunks must be placed first in a packet and since Note: Since control chunks must be placed first in a packet and since
DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK
chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK
chunks. chunks.
Partial chunks MUST NOT be placed in an SCTP packet. Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk
is a chunk that is not completely contained in the SCTP packet; i.e.,
the SCTP packet is too short to contain all the bytes of the chunk as
indicated by the chunk length.
An endpoint MUST process received chunks in their order in the An endpoint MUST process received chunks in their order in the
packet. The receiver uses the chunk length field to determine the packet. The receiver uses the chunk length field to determine the
end of a chunk and beginning of the next chunk taking account of the end of a chunk and beginning of the next chunk taking account of the
fact that all chunks end on a 4 byte boundary. If the receiver fact that all chunks end on a 4 byte boundary. If the receiver
detects a partial chunk, it MUST drop the chunk. detects a partial chunk, it MUST drop the chunk.
An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with
any other chunks. any other chunks.
skipping to change at page 90, line 6 skipping to change at page 96, line 14
7.2.1. Slow-Start 7.2.1. Slow-Start
Beginning data transmission into a network with unknown conditions or Beginning data transmission into a network with unknown conditions or
after a sufficiently long idle period requires SCTP to probe the after a sufficiently long idle period requires SCTP to probe the
network to determine the available capacity. The slow start network to determine the available capacity. The slow start
algorithm is used for this purpose at the beginning of a transfer, or algorithm is used for this purpose at the beginning of a transfer, or
after repairing loss detected by the retransmission timer. after repairing loss detected by the retransmission timer.
o The initial cwnd before DATA transmission or after a sufficiently o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be <= 2*MTU. long idle period MUST be set to min(4*MTU, max (2*MTU, 4380
bytes)).
o The initial cwnd after a retransmission timeout MUST be no more o The initial cwnd after a retransmission timeout MUST be no more
than 1*MTU. than 1*MTU.
o The initial value of ssthresh MAY be arbitrarily high (for o The initial value of ssthresh MAY be arbitrarily high (for
example, implementations MAY use the size of the receiver example, implementations MAY use the size of the receiver
advertised window). advertised window).
o Whenever cwnd is greater than zero, the endpoint is allowed to o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address. have cwnd bytes of data outstanding on that transport address.
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the use the slow start algorithm to increase cwnd only if the current
current congestion window is being fully utilized). If an congestion window is being fully utilized, an incoming SACK
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be advances the Cumulative TSN Ack Point, and the data sender is not
increased by at most the lesser of 1) the total size of the in Fast Recovery. Only when these three conditions are met can
previously outstanding DATA chunk(s) acknowledged, and 2) the the cwnd be increased; otherwise, the cwnd MUST not be increased.
destination's path MTU. This protects against the ACK-Splitting If these conditions are met, then cwnd MUST be increased by, at
most, the lesser of 1) the total size of the previously
outstanding DATA chunk(s) acknowledged, and 2) the destination's
path MTU. This upper bound protects against the ACK-Splitting
attack outlined in [SAVAGE99]. attack outlined in [SAVAGE99].
In instances where its peer endpoint is multi-homed, if an endpoint In instances where its peer endpoint is multi-homed, if an endpoint
receives a SACK that advances its Cumulative TSN Ack Point, then it receives a SACK that advances its Cumulative TSN Ack Point, then it
should update its cwnd (or cwnds) apportioned to the destination should update its cwnd (or cwnds) apportioned to the destination
addresses to which it transmitted the acknowledged data. However if addresses to which it transmitted the acknowledged data. However if
the received SACK does not advance the Cumulative TSN Ack Point, the the received SACK does not advance the Cumulative TSN Ack Point, the
endpoint MUST NOT adjust the cwnd of any of the destination endpoint MUST NOT adjust the cwnd of any of the destination
addresses. addresses.
skipping to change at page 90, line 41 skipping to change at page 97, line 4
the received SACK does not advance the Cumulative TSN Ack Point, the the received SACK does not advance the Cumulative TSN Ack Point, the
endpoint MUST NOT adjust the cwnd of any of the destination endpoint MUST NOT adjust the cwnd of any of the destination
addresses. addresses.
Because an endpoint's cwnd is not tied to its Cumulative TSN Ack Because an endpoint's cwnd is not tied to its Cumulative TSN Ack
Point, as duplicate SACKs come in, even though they may not advance Point, as duplicate SACKs come in, even though they may not advance
the Cumulative TSN Ack Point an endpoint can still use them to clock the Cumulative TSN Ack Point an endpoint can still use them to clock
out new data. That is, the data newly acknowledged by the SACK out new data. That is, the data newly acknowledged by the SACK
diminishes the amount of data now in flight to less than cwnd; and so diminishes the amount of data now in flight to less than cwnd; and so
the current, unchanged value of cwnd now allows new data to be sent. the current, unchanged value of cwnd now allows new data to be sent.
On the other hand, the increase of cwnd must be tied to the On the other hand, the increase of cwnd must be tied to the
Cumulative TSN Ack Point advancement as specified above. Otherwise Cumulative TSN Ack Point advancement as specified above. Otherwise
the duplicate SACKs will not only clock out new data, but also will the duplicate SACKs will not only clock out new data, but also will
adversely clock out more new data than what has just left the adversely clock out more new data than what has just left the
network, during a time of possible congestion. network, during a time of possible congestion.
o When the endpoint does not transmit data on a given transport o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 2*MTU) per RTO. max(cwnd/2, 4*MTU) per RTO.
7.2.2. Congestion Avoidance 7.2.2. Congestion Avoidance
When cwnd is greater than ssthresh, cwnd should be incremented by When cwnd is greater than ssthresh, cwnd should be incremented by
1*MTU per RTT if the sender has cwnd or more bytes of data 1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding transport address. outstanding for the corresponding transport address.
In practice an implementation can achieve this goal in the following In practice an implementation can achieve this goal in the following
way: way:
skipping to change at page 91, line 30 skipping to change at page 97, line 40
Cumulative TSN Ack and by Gap Ack Blocks. Cumulative TSN Ack and by Gap Ack Blocks.
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), increase cwnd by MTU, and was greater than or equal to cwnd), increase cwnd by MTU, and
reset partial_bytes_acked to (partial_bytes_acked - cwnd). reset partial_bytes_acked to (partial_bytes_acked - cwnd).
o Same as in the slow start, when the sender does not transmit DATA o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 2*MTU) per RTO. should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
o When all of the data transmitted by the sender has been o When all of the data transmitted by the sender has been
acknowledged by the receiver, partial_bytes_acked is initialized acknowledged by the receiver, partial_bytes_acked is initialized
to 0. to 0.
7.2.3. Congestion Control 7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following: endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half. Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow When the T3-rtx timer expires on an address, SCTP should perform slow
start by: start by:
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU cwnd = 1*MTU
and assure that no more than one SCTP packet will be in flight for and assure that no more than one SCTP packet will be in flight for
that address until the endpoint receives acknowledgement for that address until the endpoint receives acknowledgement for
successful delivery of data to that address. successful delivery of data to that address.
7.2.4. Fast Retransmit on Gap Reports 7.2.4. Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in the acknowledgement. However, whenever an endpoint notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the hole is filled. a packet arrives carrying data until the hole is filled.
Whenever an endpoint receives a SACK that indicates some TSN(s) Whenever an endpoint receives a SACK that indicates that some TSNs
missing, it SHOULD wait for 3 further miss indications (via are missing, it SHOULD wait for 2 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with subsequent SACKs for a total of 3 missing reports) on the same TSNs
regard to Fast Retransmit. before taking action with regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive Miss indications SHOULD follow the HTNA (Highest TSN Newly
SACK, the data sender shall: Acknowledged) algorithm. For each incoming SACK, miss indications
are incremented only for missing TSNs prior to the highest TSN newly
acknowledged in the SACK. A newly acknowledged DATA chunk is one not
previously acknowledged in a SACK. If an endpoint is in Fast
Recovery and a SACK arrives that advances the Cumulative TSN Ack
Point, the miss indications are incremented for all TSNs reported
missing in the SACK.
1) Mark the missing DATA chunk(s) for retransmission, When the third consecutive miss indication is received for a TSN(s),
the data sender shall do the following:
2) Adjust the ssthresh and cwnd of the destination address(es) to 1) Mark the DATA chunk(s) with three miss indications for
which the missing DATA chunks were last sent, according to the retransmission.
formula described in Section 7.2.3.
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
destination address(es) to which the missing DATA chunks were last
sent, according to the formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. those K DATA chunks in a single packet. When a Fast Retransmit is
being performed, the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission for this single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that retransmitting the first outstanding DATA chunk sent to that
address. address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that did
not fit in the sent datagram carrying K other TSNs are also marked
as ineligible for a subsequent fast retransmit. However, as they
are marked for retransmission they will be retransmitted later on
as soon as cwnd allows.
6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
SHOULD NOT change for any destinations due to a subsequent Fast
Recovery event (i.e., one SHOULD NOT reduce the cwnd further 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 Point, the cwnd adjustment rules defined in Section 7.2.1 and
Section 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 4 and consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0. starting the fast retransmit procedure, the counter resets to 0.
skipping to change at page 94, line 16 skipping to change at page 101, line 10
discovery in [RFC1191] and [RFC1981] applies to SCTP on a per- discovery in [RFC1191] and [RFC1981] applies to SCTP on a per-
destination-address basis. destination-address basis.
Note: For IPv6 destination addresses the DF bit does not exist, Note: For IPv6 destination addresses the DF bit does not exist,
instead the IP datagram must be fragmented as described in [RFC2460]. instead the IP datagram must be fragmented as described in [RFC2460].
8. Fault Management 8. Fault Management
8.1. Endpoint Failure Detection 8.1. Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
8.2. Path Failure Detection 8.2. Path Failure Detection
When its peer endpoint is multi-homed, an endpoint should keep a When its peer endpoint is multi-homed, an endpoint should keep a
error counter for each of the destination transport addresses of the error counter for each of the destination transport addresses of the
peer endpoint. peer endpoint.
skipping to change at page 95, line 27 skipping to change at page 102, line 10
When the primary path is marked inactive (due to excessive When the primary path is marked inactive (due to excessive
retransmissions, for instance), the sender MAY automatically transmit retransmissions, for instance), the sender MAY automatically transmit
new packets to an alternate destination address if one exists and is new packets to an alternate destination address if one exists and is
active. If more than one alternate address is active when the active. If more than one alternate address is active when the
primary path is marked inactive only ONE transport address SHOULD be primary path is marked inactive only ONE transport address SHOULD be
chosen and used as the new destination transport address. chosen and used as the new destination transport address.
8.3. Path Heartbeat 8.3. Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint SHOULD monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
(INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
ACK-SENT state (SHUTDOWN receiver).
A destination transport address is considered "idle" if no new chunk A destination transport address is considered "idle" if no new chunk
which can be used for updating path RTT (usually including first which 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:
skipping to change at page 96, line 32 skipping to change at page 103, line 18
IMPLEMENTATION NOTE: An alternative implementation of the heartbeat IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
mechanism that can be used is to increment the error counter variable mechanism that can be used is to increment the error counter variable
every time a HEARTBEAT is sent to a destination. Whenever a every time a HEARTBEAT is sent to a destination. Whenever a
HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of
the destination that the HEARTBEAT was sent to. This in effect would the destination that the HEARTBEAT was sent to. This in effect would
clear the previously stroked error (and any other error counts as clear the previously stroked error (and any other error counts as
well). well).
The receiver of the HEARTBEAT should immediately respond with a The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied HEARTBEAT ACK that contains the Heartbeat Information TLV, together
from the received HEARTBEAT chunk. with any other received TLVs, copied unchanged from the received
HEARTBEAT chunk.
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
should clear the error counter of the destination transport address should clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint may address as active if it is not so marked. The endpoint may
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the
association overall error count as well (as defined in section 8.1). association overall error count as well (as defined in Section 8.1).
The receiver of the HEARTBEAT ACK should also perform an RTT The receiver of the HEARTBEAT ACK should also perform an RTT
measurement for that destination transport address using the time measurement for that destination transport address using the time
value carried in the HEARTBEAT ACK chunk. value carried in the HEARTBEAT ACK chunk.
On an idle destination address that is allowed to heartbeat, a On an idle destination address that is allowed to heartbeat, it is
HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that recommended that a HEARTBEAT chunk is sent once per RTO of that
destination address plus the protocol parameter 'HB.interval' , with destination address plus the protocol parameter 'HB.interval' , with
jittering of +/- 50%, and exponential back-off of the RTO if the jittering of +/- 50% of the RTO value, and exponential back-off of
previous HEARTBEAT is unanswered. the RTO if the previous HEARTBEAT is unanswered.
A primitive is provided for the SCTP user to change the HB.interval A primitive is provided for the SCTP user to change the HB.interval
and turn on or off the heartbeat on a given destination address. The and turn on or off the heartbeat on a given destination address. The
heartbeat interval set by the SCTP user is added to the RTO of that heartbeat interval set by the SCTP user is added to the RTO of that
destination (including any exponential backoff). Only one heartbeat destination (including any exponential backoff). Only one heartbeat
should be sent each time the heartbeat timer expires (if multiple should be sent each time the heartbeat timer expires (if multiple
destinations are idle). It is a implementation decision on how to destinations are idle). It is a implementation decision on how to
choose which of the candidate idle destinations to heartbeat to (if choose which of the candidate idle destinations to heartbeat to (if
more than one destination is idle). more than one destination is idle).
skipping to change at page 97, line 29 skipping to change at page 104, line 15
reason and the ABORT chunk is lost, the local endpoint will only reason and the ABORT chunk is lost, the local endpoint will only
discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk
(thus causing the peer to send another ABORT). This must be (thus causing the peer to send another ABORT). This must be
considered when tuning the HEARTBEAT timer. If the HEARTBEAT is considered when tuning the HEARTBEAT timer. If the HEARTBEAT is
disabled only sending DATA to the association will discover a lost disabled only sending DATA to the association will discover a lost
ABORT from the peer. ABORT from the peer.
8.4. Handle "Out of the blue" Packets 8.4. Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is An SCTP packet is called an "out of the blue" (OOTB) packet if it is
correctly formed, i.e., passed the receiver's Adler-32 check (see correctly formed (i.e., passed the receiver's CRC32c check; see
Section 6.8), but the receiver is not able to identify the Section 6.8), but the receiver is not able to identify the
association to which this packet belongs. association to which this packet belongs.
The receiver of an OOTB packet MUST do the following: The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, silently 1) If the OOTB packet is to or from a non-unicast address, a receiver
discard the packet. Otherwise, SHOULD silently discard the packet. Otherwise,
2) If the OOTB packet contains an ABORT chunk, the receiver MUST 2) If the OOTB packet contains an ABORT chunk, the receiver MUST
silently discard the OOTB packet and take no further action. silently discard the OOTB packet and take no further action.
Otherwise, Otherwise,
3) If the packet contains an INIT chunk with a Verification Tag set 3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. Otherwise, to '0', process it as described in Section 5.1. If, for whatever
reason, the INIT cannot be processed normally and an ABORT has to
be sent in response, the Verification Tag of the packet containing
the ABORT chunk MUST be the Initiate tag of the received INIT
chunk, and the T-Bit of the ABORT chunk has to be set to 0,
indicating that the Verification Tag is NOT reflected.
4) If the packet contains a COOKIE ECHO in the first chunk, process 4) If the packet contains a COOKIE ECHO in the first chunk, process
it as described in Section 5.1. Otherwise, it as described in Section 5.1. Otherwise,
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
packet must fill in the Verification Tag field of the outbound packet must fill in the Verification Tag field of the outbound
packet with the Verification Tag received in the SHUTDOWN ACK and packet with the Verification Tag received in the SHUTDOWN ACK and
set the T-bit in the Chunk Flags to indicate that no TCB was set the T-bit in the Chunk Flags to indicate that the Verification
found. Otherwise, Tag is reflected. Otherwise,
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver 6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
should silently discard the packet and take no further action. should silently discard the packet and take no further action.
Otherwise, Otherwise,
7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the 7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the
SCTP Packet should be silently discarded. Otherwise, SCTP Packet should be silently discarded. Otherwise,
8) The receiver should respond to the sender of the OOTB packet with 8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the Verification Tag field of the outbound packet MUST fill in the Verification Tag field of the outbound packet
with the value found in the Verification Tag field of the OOTB with the value found in the Verification Tag field of the OOTB
packet and set the T-bit in the Chunk Flags to indicate that no packet and set the T-bit in the Chunk Flags to indicate that the
TCB was found. After sending this ABORT, the receiver of the OOTB Verification Tag is reflected. After sending this ABORT, the
packet shall discard the OOTB packet and take no further action. receiver of the OOTB packet shall discard the OOTB packet and take
no further action.
8.5. Verification Tag 8.5. Verification Tag
The Verification Tag rules defined in this section apply when sending The Verification Tag rules defined in this section apply when sending
or receiving SCTP packets which do not contain an INIT, SHUTDOWN or receiving SCTP packets which do not contain an INIT, SHUTDOWN
COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk. COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk.
The rules for sending and receiving SCTP packets containing one of The rules for sending and receiving SCTP packets containing one of
these chunk types are discussed separately in Section 8.5.1. these chunk types are discussed separately in Section 8.5.1.
When sending an SCTP packet, the endpoint MUST fill in the When sending an SCTP packet, the endpoint MUST fill in the
skipping to change at page 99, line 14 skipping to change at page 106, line 5
- 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 shall 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, if
it is known. 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 endpoint
MUST follow the procedure described in Section 8.4. MUST follow the procedure described in Section 8.4
- The receiver MUST accept the packet if the Verification Tag - The receiver of an ABORT MUST accept the packet if the
matches either its own tag, OR the tag of its peer. Otherwise, Verification Tag field of the packet matches its own tag and the
the receiver MUST silently discard the packet and take no further T bit is not set OR if it is set to its peer's tag and the T bit
action. is set in the Chunk Flags. Otherwise, the receiver MUST 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 SHUTDOWN
ACK has a TCB then the destination endpoint's tag MUST be used. ACK has a TCB, then the destination endpoint's tag MUST be used,
Only where no TCB exists should the sender use the Verification and the T-bit MUST NOT be set. Only where no TCB exists should
Tag from the SHUTDOWN ACK. the sender use the Verification Tag from the 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 OR the Verification Tag field of the packet matches its own tag and
it is set to its peer's tag and the T bit is set in the Chunk the T bit is not set OR if it is set to its peer's tag and the T
Flags. Otherwise, the receiver MUST silently discard the packet bit is set in the Chunk Flags. Otherwise, the receiver MUST
and take no further action. An endpoint MUST ignore the SHUTDOWN silently discard the packet and take no further action. An
COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in 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 Initial Tag received in the INIT ACK. the Initial Tag received in the INIT ACK.
- The receiver of a COOKIE ECHO follows the procedures in - The receiver of a COOKIE ECHO follows the procedures in
Section 5. Section 5.
E) Rules for packet carrying a SHUTDOWN ACK E) Rules for packet carrying a SHUTDOWN ACK
skipping to change at page 100, line 4 skipping to change at page 106, line 43
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 Initial Tag received in the INIT ACK. the Initial Tag received in the INIT ACK.
- The receiver of a COOKIE ECHO follows the procedures in - The receiver of a COOKIE ECHO follows the procedures in
Section 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 it
should be treated as an Out Of The Blue packet. 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
of a shutdown, SCTP does not support a half-open state (like TCP) of a shutdown, SCTP does not support a half-open state (like TCP)
wherein one side may continue sending data while the other end is wherein one side may continue sending data while the other end is
closed. When either endpoint performs a shutdown, the association on closed. When either endpoint performs a shutdown, the association on
each peer will stop accepting new data from its user and only deliver each peer will stop accepting new data from its user and only deliver
data in queue at the time of sending or receiving the SHUTDOWN chunk. data in queue at the time of sending or receiving the SHUTDOWN chunk.
9.1. Abort of an Association 9.1. Abort of an Association
When an endpoint decides to abort an existing association, it shall When an endpoint decides to abort an existing association, it MUST
send an ABORT chunk to its peer endpoint. The sender MUST fill in send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. bundle any DATA chunk with the ABORT. If the association is aborted
on request of the upper layer, a User-Initiated Abort error cause
(see Section 3.3.10.12) SHOULD be present in the ABORT chunk.
An endpoint MUST NOT respond to any received packet that contains an An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4). ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification An endpoint receiving an ABORT MUST apply the special Verification
Tag check rules described in Section 8.5.1. Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall After checking the Verification Tag, the receiving endpoint MUST
remove the association from its record, and shall report the remove the association from its record and SHOULD report the
termination to its upper layer. termination to its upper layer. If a User-Initiated Abort error
cause is present in the ABORT chunk, the Upper Layer Abort Reason
SHOULD be made available to the upper layer.
9.2. Shutdown of an Association 9.2. Shutdown of an Association
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of Using the SHUTDOWN primitive (see Section 10.1), the upper layer of
an endpoint in an association can gracefully close the association. an endpoint in an association can gracefully close the association.
This will allow all outstanding DATA chunks from the peer of the This will allow all outstanding DATA chunks from the peer of the
shutdown initiator to be delivered before the association terminates. shutdown initiator to be delivered before the association terminates.
Upon receipt of the SHUTDOWN primitive from its upper layer, the Upon receipt of the SHUTDOWN primitive from its upper layer, the
endpoint enters SHUTDOWN-PENDING state and remains there until all endpoint enters SHUTDOWN-PENDING state and remains there until all
skipping to change at page 101, line 43 skipping to change at page 108, line 39
- verify, by checking the Cumulative TSN Ack field of the chunk, - 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 as reached the SHUTDOWN-RECEIVED state it MUST NOT Once an endpoint as 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 shall 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
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user. from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s) respond to each received packet containing one or more DATA chunks
with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
send a SHUTDOWN ACK and start a T2-shutdown timer of its own, chunks (i.e., there are TSNs that can be acknowledged that are larger
entering the SHUTDOWN-ACK-SENT state. If the timer expires, the than the cumulative TSN, and thus gaps exist in the TSN sequence), or
endpoint must re-send the SHUTDOWN ACK. if duplicate TSNs have been received, then a SACK chunk MUST also be
sent.
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-
shutdown-guard' to bound the overall time for shutdown sequence. At
the expiration of this timer, the sender SHOULD abort the association
by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used,
it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If
the timer expires, the endpoint must re-send the SHUTDOWN ACK.
The sender of the SHUTDOWN ACK should limit the number of 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 endpoint Association.Max.Retrans'. If this threshold is exceeded the endpoint
should destroy the TCB and may report the peer endpoint unreachable should destroy the TCB and may report the peer endpoint unreachable
to the upper layer (and thus the association enters the CLOSED to the upper layer (and thus the association enters the CLOSED
state). state).
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer,
skipping to change at page 106, line 4 skipping to change at page 113, line 9
Gracefully closes an association. Any locally queued user data will Gracefully closes an association. Any locally queued user data will
be delivered to the peer. The association will be terminated only be delivered to the peer. The association will be terminated only
after the peer acknowledges all the SCTP packets sent. A success after the peer acknowledges all the SCTP packets sent. A success
code will be returned on successful termination of the association. code will be returned on successful termination of the association.
If attempting to terminate the association results in a failure, an If attempting to terminate the association results in a failure, an
error code shall be returned. error code shall be returned.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
None. None.
D) Abort D) Abort
Format: ABORT(association id [, cause code]) Format: ABORT(association id [, Upper Layer Abort Reason])
-> result -> result
Ungracefully closes an association. Any locally queued user data Ungracefully closes an association. Any locally queued user data
will be discarded and an ABORT chunk is sent to the peer. A success will be discarded, and an ABORT chunk is sent to the peer. A success
code will be returned on successful abortion of the association. If code will be returned on successful abortion of the association. If
attempting to abort the association results in a failure, an error attempting to abort the association results in a failure, an error
code shall be returned. code shall be returned.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
o cause code - reason of the abort to be passed to the peer. o Upper Layer Abort Reason - Reason of the abort to be passed to the
peer.
None. None.
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address]
[,unorder flag] [,no-bundle flag] [,payload protocol-id] ) [,unorder flag] [,no-bundle flag] [,payload protocol-id] )
-> result -> result
skipping to change at page 116, line 8 skipping to change at page 123, line 25
When SCTP loses communication to an endpoint completely (e.g., via When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP. operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification: The following shall be passed with the notification:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The status o status - This indicates what type of event has occurred; The status
may indicate a failure OR a normal termination event may indicate that a failure OR a normal termination event
occurred in response to a shutdown or abort request. occurred in response to a shutdown or abort request.
The following may be passed with the notification: The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and o data retrieval id - an identification used to retrieve unsent and
unacknowledged data. unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint; o last-acked - the TSN last acked by that peer endpoint.
o last-sent - the TSN last sent to 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 F) COMMUNICATION ERROR notification
When SCTP receives an ERROR chunk from its peer and decides to notify When SCTP receives an ERROR chunk from its peer and decides to notify
its ULP, it can invoke this notification on the ULP. its ULP, it can invoke this notification on the ULP.
The following can be passed with the notification: The following can be passed with the notification:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o error info - this indicates the type of error and optionally some o error info - this indicates the type of error and optionally some
additional information received through the ERROR chunk. additional information received through the ERROR chunk.
G) RESTART notification G) RESTART notification
When SCTP detects that the peer has restarted, it may send this When SCTP detects that the peer has restarted, it may send this
notification to its ULP. notification to its ULP.
The following can be passed with the notification: The following can be passed with the notification:
skipping to change at page 122, line 7 skipping to change at page 129, line 35
repudiation is an issue, the use of the IPSEC AH service is repudiation is an issue, the use of the IPSEC AH service is
recommended to ensure both the integrity and the authenticity of the recommended to ensure both the integrity and the authenticity of the
SCTP packets passed. SCTP packets passed.
SCTP also provides no protection against attacks originating at or SCTP also provides no protection against attacks originating at or
beyond the SCTP node and taking place within the context of an beyond the SCTP node and taking place within the context of an
existing association. Prevention of such attacks should be covered existing association. Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in by appropriate security policies at the host site, as discussed in
Section 11.2.1. Section 11.2.1.
11.4. SCTP Interactions with Firewalls
It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements,
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
chunk MUST have a zero Verification Tag. Furthermore, we require that
the receiver of an INIT chunk MUST enforce these rules by silently
discarding an arriving packet with an INIT chunk that is bundled with
other chunks.
11.5. Protection of Non-SCTP Capable Hosts.
To provide a non-SCTP capable host with the same level of protection
against attacks as for SCTP-capable ones, all SCTP stacks MUST
implement the ICMP handling described in Appendix C.
When an SCTP stack receives a packet containing multiple control or
DATA chunks and the processing of the packet requires the sending of
multiple chunks in response, the sender of the response chunk(s) MUST
NOT send more than one packet. If bundling is supported, multiple
response chunks that fit into a single packet MAY be bundled together
into one single response packet. If bundling is not supported, then
the sender MUST NOT send more than one response chunk and MUST
discard all other responses. Note that this rule does NOT apply to a
SACK chunk, since a SACK chunk is, in itself, a response to DATA and
a SACK does not require a response of more DATA.
An SCTP implementation SHOULD abort the association if it receives a
SACK acknowledging a TSN that has not been sent.
An SCTP implementation that receives an INIT that would require a
large packet in response, due to the inclusion of multiple ERROR
parameters, MAY (at its discretion) elect to omit some or all of the
ERROR parameters to reduce the size of the INIT-ACK. Due to a
combination of the size of the COOKIE parameter and the number of
addresses a receiver of an INIT may be indicating to a peer, it is
always possible that the INIT-ACK will be larger than the original
INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
small as possible to reduce the possibility of byte amplification
attacks.
12. Recommended Transmission Control Block (TCB) Parameters 12. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should be This section details a recommended set of parameters that should be
contained within the TCB for an implementation. This section is for contained within the TCB for an implementation. This section is for
illustrative purposes and should not be deemed as requirements on an illustrative purposes and should not be deemed as requirements on an
implementation or as an exhaustive list of all parameters inside an implementation or as an exhaustive list of all parameters inside an
SCTP TCB. Each implementation may need its own additional parameters SCTP TCB. Each implementation may need its own additional parameters
for optimization. for optimization.
12.1. Parameters necessary for the SCTP instance 12.1. Parameters necessary for the SCTP instance
skipping to change at page 126, line 21 skipping to change at page 135, line 21
-- through definition of additional chunk types, -- through definition of additional chunk types,
-- through definition of additional parameter types, or -- through definition of additional parameter types, or
-- through definition of additional cause codes within ERROR chunks -- through definition of additional cause codes within ERROR chunks
In the case where a particular ULP using SCTP desires to have its own In the case where a particular ULP using SCTP desires to have its own
ports, the ULP should be responsible for registering with IANA for ports, the ULP should be responsible for registering with IANA for
getting its ports assigned. getting its ports assigned.
13.1. IETF-defined Chunk Extension 13.1. IETF-defined Chunk Extension
The definition and use of new chunk types is an integral part of The assignment of new chunk parameter type codes is done through an
SCTP. Thus, new chunk types are assigned by IANA through an IETF IETF Consensus action, as defined in [RFC2434]. Documentation of the
Consensus action as defined in [RFC2434]. chunk parameter MUST contain the following information:
The documentation for a new chunk code type must include 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 type
skipping to change at page 127, line 17 skipping to change at page 136, line 11
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 multiple
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
e) Each parameter type MUST be unique across all chunks.
13.3. IETF-defined Additional Error Causes 13.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
skipping to change at page 128, line 12 skipping to change at page 137, line 8
protocol identifier with IANA if it is so desired. The use of any protocol identifier with IANA if it is so desired. The use of any
specific payload protocol identifier is out of the scope of SCTP. specific payload protocol identifier is out of the scope of SCTP.
14. Suggested SCTP Protocol Parameter Values 14. 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
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
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.
15. Acknowledgements 15. Acknowledgements
The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band,
Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R.
skipping to change at page 130, line 15 skipping to change at page 139, line 15
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=13 | Flags=00000000| Chunk Length = 8 | | Chunk Type=13 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number | | Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The CWR is considered a Control chunk. Note: The CWR is considered a Control chunk.
Appendix B. Alder 32 bit checksum calculation Appendix B. CRC32c Checksum Calculation
The Adler-32 checksum calculation given in this appendix is copied
from [RFC1950].
Adler-32 is composed of two sums accumulated per byte: s1 is the sum
of all bytes, s2 is the sum of all s1 values. Both sums are done
modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32
checksum is stored as s2*65536 + s1 in network byte order.
The following C code computes the Adler-32 checksum of a data buffer. We define a 'reflected value' as one that is the opposite of the
It is written for clarity, not for speed. The sample code is in the normal bit order of the machine. The 32-bit CRC is calculated as
ANSI C programming language. Non C users may find it easier to read described for CRC-32c and uses the polynomial code 0x11EDC6F41
with these hints: (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+
x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a
procedure similar to ETHERNET CRC [ITU32], modified to reflect
transport level usage.
& Bitwise AND operator. CRC computation uses polynomial division. A message bit-string M is
transformed to a polynomial, M(X), and the CRC is calculated from
M(X) using polynomial arithmetic.
>> Bitwise right shift operator. When applied to an unsigned When CRCs are used at the link layer, the polynomial is derived from
quantity, as here, right shift inserts zero bit(s) at the left. on-the-wire bit ordering: the first bit 'on the wire' is the high-
order coefficient. Since SCTP is a transport-level protocol, it
cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use different
link-level bit orders.
<< Bitwise left shift operator. Left shift inserts zero bit(s) at A convention must therefore be established for mapping SCTP transport
the right. messages to polynomials for purposes of CRC computation. The bit-
ordering for mapping SCTP messages to polynomials is that bytes are
taken most-significant first; but within each byte, bits are taken
least-significant first. The first byte of the message provides the
eight highest coefficients. Within each byte, the least-significant
SCTP bit gives the most significant polynomial coefficient within
that byte, and the most-significant SCTP bit is the least significant
polynomial coefficient in that byte. (This bit ordering is sometimes
called 'mirrored' or 'reflected' [WILLIAMS93]) CRC polynomials are to
be transformed back into SCTP transport-level byte values, using a
consistent mapping.
++ "n++" increments the variable n. The SCTP transport-level CRC value should be calculated as follows:
% modulo operator: a % b is the remainder of a divided by b. - CRC input data are assigned to a byte stream, numbered from 0 to
N-1.
- The transport-level byte-stream is mapped to a polynomial value.
An N-byte PDU with j bytes numbered 0 to N-1 is considered as
coefficients of a polynomial M(x) of order 8N-1, with bit 0 of
byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being
coefficient x^(8(N-j)-1).
- The CRC remainder register is initialized with all 1s and the CRC
is computed with an algorithm that simultaneously multiplies by
x^32 and divides by the CRC polynomial.
- The polynomial is multiplied by x^32 and divided by G(x), the
generator polynomial, producing a remainder R(x) of degree less
than or equal to 31.
- The coefficients of R(x) are considered a 32-bit sequence.
- The bit sequence is complemented. The result is the CRC
polynomial.
- The CRC polynomial is mapped back into SCTP transport-level bytes.
The coefficient of x^31 gives the value of bit 7 of SCTP byte 0,
and the coefficient of x^24 gives the value of bit 0 of byte 0.
The coefficient of x^7 gives bit 7 of byte 3, and the coefficient
of x^0 gives bit 0 of byte 3. The resulting four-byte transport-
level sequence is the 32-bit SCTP checksum value.
#define BASE 65521 /* largest prime smaller than 65536 */ IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
/* literature on CRCs often follow an alternative formulation, in which
Update a running Adler-32 checksum with the bytes buf[0..len-1] the register used to hold the remainder of the long-division
and return the updated checksum. The Adler-32 checksum should be algorithm is initialized to zero rather than all-1s, and instead the
initialized to 1. first 32 bits of the message are complemented. The long-division
algorithm used in our formulation is specified such that the initial
multiplication by 2^32 and the long-division are combined into one
simultaneous operation. For such algorithms, and for messages longer
than 64 bits, the two specifications are precisely equivalent. That
equivalence is the intent of this document.
Usage example: Implementors of SCTP are warned that both specifications are to be
found in the literature, sometimes with no restriction on the long-
division algorithm. The choice of formulation in this document is to
permit non-SCTP usage, where the same CRC algorithm may be used to
protect messages shorter than 64 bits.
unsigned long adler = 1L; There may be a computational advantage in validating the Association
against the Verification Tag, prior to performing a checksum, as
invalid tags will result in the same action as a bad checksum in most
cases. The exceptions for this technique would be INIT and some
SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These
special case exchanges must represent small packets and will minimize
the effect of the checksum calculation.
while (read_buffer(buffer, length) != EOF) { Appendix C. ICMP Handling
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) { Whenever an ICMP message is received by an SCTP endpoint the
s1 = (s1 + buf[n]) % BASE; following procedures MUST be followed to ensure proper utilization of
s2 = (s2 + s1) % BASE; the information being provided by layer 3.
} ICMP1) An implementation MAY ignore all ICMPv4 messages where the
return (s2 << 16) + s1; type field is not set to "Destination Unreachable".
} ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable, "Parameter Problem" or
"Packet Too Big".
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or "Fragmentation
Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized next header
type encountered".
ICMP5) An implementation MUST use the payload of the ICMP message
(V4 or V6) to locate the association that sent the message that
ICMP is responding to. If the association cannot be found, an
implementation SHOULD ignore the ICMP message.
ICMP6) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the verification tag of the
peer. If the Verification Tag is not 0 and does NOT match,
discard the ICMP message. If it is 0 and the ICMP message
contains enough bytes to verify that the chunk type is an INIT
chunk and that the initiate tag matches the tag of the peer,
continue with ICMP7. If the ICMP message is too short or the
chunk type or the initiate tag does not match, silently discard
the packet.
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is a "Unrecognized next header type
encountered" or a "Protocol Unreachable", an implementation MUST
treat this message as an abort with the T bit set if it does not
contain an INIT chunk. If it does contain an INIT chunk and the
association is in COOKIE-WAIT state, handle the ICMP message like
an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable state
or alternatively increment the path error counter.
/* Return the adler32 of the bytes buf[0..len-1] */ Note that these procedures differ from [RFC1122] and from its
unsigned long adler32(unsigned char *buf, int len) requirements for processing of port-unreachable messages and the
{ requirements that an implementation MUST abort associations in
return update_adler32(1L, buf, len); response to a "protocol unreachable" message. Port unreachable
} messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP.
16. References 16. References
16.1. Normative references 16.1. Normative references
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures
for DCEs using asynchronous-to-synchronous conversion".",
ITU-T section 8.1.1.6.2.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP",
RFC 813, July 1982.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 133, line 20 skipping to change at page 143, line 49
[SAVAGE99] [SAVAGE99]
Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Commuinications Review 29(5), October 1999. Computer Commuinications Review 29(5), October 1999.
[ALLMAN99] [ALLMAN99]
Allman, M. and V. Paxson, "On Estimating End-to-End Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", SIGCOMM'99 , 1999. Network Path Properties", SIGCOMM'99 , 1999.
[WILLIAMS93]
Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
ALGORITHMS" - Internet publication http://
www.geocities.com/SiliconValley/Pines/8659/crc.htm.",
August 1993.
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 134, line 8 skipping to change at page 145, line 8
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, Congestion Notification (ECN) to IP", RFC 2481,
January 1999. January 1999.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
Author's Address Author's Address
Randall R. Stewart Randall R. Stewart
Cisco Systems Inc. Editor
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
US US
Email: rrs@cisco.com Email: rrs@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
 End of changes. 174 change blocks. 
426 lines changed or deleted 958 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/