draft-ietf-tsvwg-2960bis-02.txt   draft-ietf-tsvwg-2960bis-03.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Editor Internet-Draft Editor
Expires: December 10, 2006 June 8, 2006 Expires: June 15, 2007 December 12, 2006
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-02.txt draft-ietf-tsvwg-2960bis-03.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 December 10, 2006. This Internet-Draft will expire on June 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (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.
SCTP is a reliable transport protocol operating on top of a SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following connectionless packet network such as IP. It offers the following
services to its users: services to its users:
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.3.1. Association Startup and Takedown . . . . . . . . . . 8 1.3.1. Association Startup and Takedown . . . . . . . . . . 8
1.3.2. Sequenced Delivery within Streams . . . . . . . . . . 9 1.3.2. Sequenced Delivery within Streams . . . . . . . . . . 9
1.3.3. User Data Fragmentation . . . . . . . . . . . . . . . 9 1.3.3. User Data Fragmentation . . . . . . . . . . . . . . . 9
1.3.4. Acknowledgement and Congestion Avoidance . . . . . . 9 1.3.4. Acknowledgement and Congestion Avoidance . . . . . . 9
1.3.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 10 1.3.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 10
1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 10 1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 10
1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 10 1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 10
1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 15 1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15
1.7. Changes from RFC2960 . . . . . . . . . . . . . . . . . . 16
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 16 3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 16
3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 17 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 17
3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18
3.2.1. Optional/Variable-length Parameter Format . . . . . . 20 3.2.1. Optional/Variable-length Parameter Format . . . . . . 20
3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22
3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23
3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23
3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 25
3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 31 3.3.3. Initiation Acknowledgement (INIT ACK) (2): . . . . . 31
3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 35 3.3.4. Selective Acknowledgement (SACK) (3): . . . . . . . . 35
3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 39 3.3.5. Heartbeat Request (HEARTBEAT) (4): . . . . . . . . . 39
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 40 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): . . . 40
3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 40 3.3.7. Abort Association (ABORT) (6): . . . . . . . . . . . 41
3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 41 3.3.8. Shutdown Association (SHUTDOWN) (7): . . . . . . . . 42
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 42 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8): . . . . 42
3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 43 3.3.10. Operation Error (ERROR) (9): . . . . . . . . . . . . 43
3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 44 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 45
3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 45 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 45
3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 45 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 46
3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 46 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 46
3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 46 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 47
3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 47 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 47
3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 47 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 48
3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 48 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 48
3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 48 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 48
3.3.10.10. Cookie Received While Shutting Down (10) . . . . 49 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 49
3.3.10.11. Restart of an Association with New Addresses 3.3.10.11. Restart of an Association with New Addresses
(11) . . . . . . . . . . . . . . . . . . . . . . 49 (11) . . . . . . . . . . . . . . . . . . . . . . 49
3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 49 3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 50
3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 50 3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 50
3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 50 3.3.11. Cookie Echo (COOKIE ECHO) (10): . . . . . . . . . . . 51
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 51 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11): . . . . . . 52
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 52 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14): . . . . . 52
4. SCTP Association State Diagram . . . . . . . . . . . . . . . 52 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 53
5. Association Initialization . . . . . . . . . . . . . . . . . 56 5. Association Initialization . . . . . . . . . . . . . . . . . 56
5.1. Normal Establishment of an Association . . . . . . . . . 56 5.1. Normal Establishment of an Association . . . . . . . . . 57
5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 58 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 58
5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 58 5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 59
5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 61 5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 61
5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 62 5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 62
5.1.5. State Cookie Authentication . . . . . . . . . . . . . 62 5.1.5. State Cookie Authentication . . . . . . . . . . . . . 62
5.1.6. An Example of Normal Association Establishment . . . 63 5.1.6. An Example of Normal Association Establishment . . . 63
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE
ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 65 ECHO, and COOKIE ACK . . . . . . . . . . . . . . . . . . 65
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) . . . . . . . . . . . . . . . . . . . 65 State (Item B) . . . . . . . . . . . . . . . . . . . 65
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 . . . 66 COOKIE-ECHOED,COOKIE-WAIT and SHUTDOWN-ACK-SENT . . . 66
skipping to change at page 3, line 49 skipping to change at page 3, line 50
5.3. Other Initialization Issues . . . . . . . . . . . . . . . 71 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 71
5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 71 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 71
5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 72 5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 72
6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 73 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 73
6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 75 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 75
6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 77 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 77
6.2.1. Processing a Received SACK . . . . . . . . . . . . . 80 6.2.1. Processing a Received SACK . . . . . . . . . . . . . 80
6.3. Management of Retransmission Timer . . . . . . . . . . . 82 6.3. Management of Retransmission Timer . . . . . . . . . . . 82
6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 82 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 82
6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 83 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 83
6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 84 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 85
6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86 6.4. Multi-homed SCTP Endpoints . . . . . . . . . . . . . . . 86
6.4.1. Failover from Inactive Destination Address . . . . . 86 6.4.1. Failover from Inactive Destination Address . . . . . 87
6.5. Stream Identifier and Stream Sequence Number . . . . . . 87 6.5. Stream Identifier and Stream Sequence Number . . . . . . 87
6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 87 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 87
6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 88 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 88
6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 89 6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 89
6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 90 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 90
6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 91 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 91
7. Congestion control . . . . . . . . . . . . . . . . . . . . . 92 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 92
7.1. SCTP Differences from TCP Congestion control . . . . . . 93 7.1. SCTP Differences from TCP Congestion control . . . . . . 93
7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 94 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 94
7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 95 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 95
7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 96 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 96
7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 96 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97
7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 97 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 97
7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 98 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99
8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 100 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 100
8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 100 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 100
8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 100 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 100
8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 101 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 101
8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 103 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 103
8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 104 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 104
8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 104 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 105
9. Termination of Association . . . . . . . . . . . . . . . . . 105 9. Termination of Association . . . . . . . . . . . . . . . . . 106
9.1. Abort of an Association . . . . . . . . . . . . . . . . . 106 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 106
9.2. Shutdown of an Association . . . . . . . . . . . . . . . 106 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 107
10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 109 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 110
10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 109 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 110
10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 120 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 121
11. Security Considerations . . . . . . . . . . . . . . . . . . . 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124
11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 123 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 124
11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 123 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 124
11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 123 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124
11.2.2. Protecting against Data Corruption in the Network . . 124 11.2.2. Protecting against Data Corruption in the Network . . 124
11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 124 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125
11.2.4. Protecting against Blind Denial of Service Attacks . 125 11.2.4. Protecting against Blind Denial of Service Attacks . 125
11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 125 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126
11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 126 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127
11.2.4.3. Improper Monopolization of Services . . . . . . 127 11.2.4.3. Improper Monopolization of Services . . . . . . 128
11.3. Protection against Fraud and Repudiation . . . . . . . . 127 11.3. Protection against Fraud and Repudiation . . . . . . . . 128
11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 128 11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129
11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 128 11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129
12. Recommended Transmission Control Block (TCB) Parameters . . . 129 12. Network Managment Considerations . . . . . . . . . . . . . . 130
12.1. Parameters necessary for the SCTP instance . . . . . . . 130 13. Recommended Transmission Control Block (TCB) Parameters . . . 130
12.2. Parameters necessary per association (i.e. the TCB) . . . 130 13.1. Parameters necessary for the SCTP instance . . . . . . . 130
12.3. Per Transport Address Data . . . . . . . . . . . . . . . 132 13.2. Parameters necessary per association (i.e. the TCB) . . . 130
12.4. General Parameters Needed . . . . . . . . . . . . . . . . 133 13.3. Per Transport Address Data . . . . . . . . . . . . . . . 132
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 133 13.4. General Parameters Needed . . . . . . . . . . . . . . . . 133
13.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134
13.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134 14.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134
13.3. IETF-defined Additional Error Causes . . . . . . . . . . 135 14.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134
13.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135 14.3. IETF-defined Additional Error Causes . . . . . . . . . . 135
14. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 135 14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 136 15. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 136
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 136
Appendix A. Explicit Congestion Notification . . . . . . . . . . 137 Appendix A. Explicit Congestion Notification . . . . . . . . . . 137
Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139 Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139
Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 140 Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 141
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 147 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 147
16.1. Normative references . . . . . . . . . . . . . . . . . . 147 17.1. Normative references . . . . . . . . . . . . . . . . . . 147
16.2. Informative References . . . . . . . . . . . . . . . . . 148 17.2. Informative References . . . . . . . . . . . . . . . . . 148
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 149
Intellectual Property and Copyright Statements . . . . . . . . . 151 Intellectual Property and Copyright Statements . . . . . . . . . 150
1. Introduction 1. Introduction
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers, Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description and the basic concepts needed to understand the detailed description
of the protocol. of the protocol.
1.1. Motivation 1.1. Motivation
skipping to change at page 16, line 6 skipping to change at page 16, line 6
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
That is, the next TSN a DATA chunk MUST use after transmitting TSN = That is, the next TSN a DATA chunk MUST use after transmitting TSN =
2*32 - 1 is TSN = 0. 2*32 - 1 is TSN = 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document uses normal All other arithmetic and comparisons in this document uses normal
arithmetic. arithmetic.
1.7. Changes from RFC2960
SCTP was originally defined in [RFC2960] which this document
obsoletes. Readers interested in the details of the various changes
that this document incorporates are asked to consult [RFC4460].
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
3. SCTP packet Format 3. SCTP packet Format
An SCTP packet is composed of a common header and chunks. A chunk An SCTP packet is composed of a common header and chunks. A chunk
skipping to change at page 20, line 42 skipping to change at page 20, line 42
The total length of a chunk (including Type, Length, and Value The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, and this padding is not included in the chunk length zero bytes, and this padding is not included in the chunk length
field. The sender should never pad with more than 3 bytes. The field. The sender should never pad with more than 3 bytes. The
receiver 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 14.1 of this document.
3.2.1. Optional/Variable-length Parameter Format 3.2.1. Optional/Variable-length Parameter Format
Chunk values of SCTP control chunks consist of a chunk-type-specific Chunk values of SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters. The header of required fields, followed by zero or more parameters. The
optional and variable-length parameters contained in a chunk are optional and variable-length parameters contained in a chunk are
defined in a Type-Length-Value format as shown below. defined in a Type-Length-Value format as shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 22, line 25 skipping to change at page 22, line 22
11 - Skip this parameter and continue processing but report the 11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter', as unrecognized parameter in an 'Unrecognized Parameter', as
described in Section 3.2.2. described in Section 3.2.2.
Please note that in all four cases an INIT-ACK or COOKIE-ECHO 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 chunk is sent. In the 00 or 01 case the processing of the
parameters after the unknown parameter is canceled, but no parameters after the unknown parameter is canceled, but no
processing already done is rolled back. 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. Note that a parameter type MUST be defined in Section 14.2. Note that a parameter type MUST be
unique across all chunks. For example, the parameter type '5' is unique across all chunks. For example, the parameter type '5' is
used to represent an IPv4 address (see Section 3.2.2). The value used to represent an IPv4 address (see Section 3.2.2). The value
'5' then is reserved across all chunks to represent an IPv4 '5' then is reserved across all chunks to represent an IPv4
address and MUST NOT be reused with a different meaning in any address and MUST NOT be reused with a different meaning in any
other chunk. other chunk.
3.2.2. Reporting of Unrecognized Parameters 3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters and 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 has to report them according to Section 3.2.1, it MUST put the
skipping to change at page 24, line 36 skipping to change at page 24, line 36
When a user message is fragmented into multiple chunks, the TSNs are When a user message is fragmented into multiple chunks, the TSNs are
used by the receiver to reassemble the message. This means that the used by the receiver to reassemble the message. This means that the
TSNs for each fragment of a fragmented user message MUST be strictly TSNs for each fragment of a fragmented user message MUST be strictly
sequential. sequential.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the user data field the beginning of the type field to the end of the user data field
excluding any padding. A DATA chunk with no user data field will excluding any padding. A DATA chunk with one byte of user data
have Length set to 16 (indicating 16 bytes). will have Length set to 17 (indicating 17 bytes).
A DATA chunk with a user data field of length L will have the
length field set to (16 + L) (indicating 16+L bytes) where L MUST
be greater than 0.
TSN : 32 bits (unsigned integer) TSN : 32 bits (unsigned integer)
This value represents the TSN for this DATA chunk. The valid This value represents the TSN for this DATA chunk. The valid
range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back
to 0 after reaching 4294967295. to 0 after reaching 4294967295.
Stream Identifier S: 16 bits (unsigned integer) Stream Identifier S: 16 bits (unsigned integer)
Identifies the stream to which the following user data belongs. Identifies the stream to which the following user data belongs.
Stream Sequence Number n: 16 bits (unsigned integer) Stream Sequence Number n: 16 bits (unsigned integer)
This value represents the stream sequence number of the following This value represents the stream sequence number of the following
user data within the stream S. Valid range is 0 to 65535. user data within the stream S. Valid range is 0 to 65535.
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
skipping to change at page 44, line 33 skipping to change at page 44, line 46
Set to the size of the parameter in bytes, including the Cause Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields. Code, Cause Length, and Cause-Specific Information fields.
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 14.3.
3.3.10.1. Invalid Stream Identifier (1) 3.3.10.1. Invalid Stream Identifier (1)
Cause of error Cause of error
--------------- ---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk Invalid Stream Identifier: Indicates endpoint received a DATA chunk
sent to a nonexistent stream. sent to a nonexistent stream.
skipping to change at page 55, line 37 skipping to change at page 56, line 14
2) If the T1-init timer expires, the endpoint MUST retransmit INIT 2) If the T1-init timer expires, the endpoint MUST retransmit INIT
and re-start the T1-init timer without changing state. This MUST and re-start the T1-init timer without changing state. This MUST
be repeated up to 'Max.Init.Retransmits' times. After that, the be repeated up to 'Max.Init.Retransmits' times. After that, the
endpoint MUST abort the initialization process and report the endpoint MUST abort the initialization process and report the
error to SCTP user. error to SCTP user.
3) If the T1-cookie timer expires, the endpoint MUST retransmit 3) If the T1-cookie timer expires, the endpoint MUST retransmit
COOKIE ECHO and re-start the T1-cookie timer without changing COOKIE ECHO and re-start the T1-cookie timer without changing
state. This MUST be repeated up to 'Max.Init.Retransmits' times. state. This MUST be repeated up to 'Max.Init.Retransmits' times.
After that, the endpoint MUST abort the initialization process and After that, the endpoint MUST abort the initialization process
report the error to SCTP user. and report the error to SCTP user.
4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received 4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received
DATA chunks without delay. DATA chunks without delay.
5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new 5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new
send request from its SCTP user. send request from its SCTP user.
6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or 6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or
retransmit data and leave this state when all data in queue is retransmit data and leave this state when all data in queue is
transmitted. transmitted.
skipping to change at page 61, line 26 skipping to change at page 61, line 40
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.
The following steps SHOULD be taken to generate the State Cookie: The following steps SHOULD be taken to generate the State Cookie:
1) Create an association TCB using information from both the received 1) Create an association TCB using information from both the
INIT and the outgoing INIT ACK chunk, received INIT and the outgoing INIT ACK chunk,
2) In the TCB, set the creation time to the current time of day, and 2) In the TCB, set the creation time to the current time of day, and
the lifespan to the protocol parameter 'Valid.Cookie.Life', the lifespan to the protocol parameter 'Valid.Cookie.Life',
3) From the TCB, identify and collect the minimal subset of 3) From the TCB, identify and collect the minimal subset of
information needed to re-create the TCB, and generate a MAC using information needed to re-create the TCB, and generate a MAC using
this subset of information and a secret key (see [RFC2104] for an this subset of information and a secret key (see [RFC2104] for an
example of generating a MAC), and example of generating a MAC), and
4) Generate the State Cookie by combining this subset of information 4) Generate the State Cookie by combining this subset of information
and the resultant MAC. and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to sender SHOULD delete the TCB and any other local resource related to
the new association, so as to prevent resource attacks. the new association, so as to prevent resource attacks.
The hashing method used to generate the MAC is strictly a private The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk. The use of a MAC is matter for the receiver of the INIT chunk. The use of a MAC is
mandatory to prevent denial of service attacks. The secret key mandatory to prevent denial of service attacks. The secret key
skipping to change at page 62, line 29 skipping to change at page 62, line 45
marked unreachable (and thus the association enters the CLOSED marked unreachable (and thus the association enters the CLOSED
state). state).
5.1.5. State Cookie Authentication 5.1.5. State Cookie Authentication
When an endpoint receives a COOKIE ECHO chunk from another endpoint When an endpoint receives a COOKIE ECHO chunk from another endpoint
with which it has no association, it shall take the following with which it has no association, it shall take the following
actions: actions:
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
to determine which secret key to use). Reference [RFC2104] can be used to determine which secret key to use). Reference [RFC2104]
used as a guideline for generating the MAC, can be 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
Cookie. If this comparison fails, the SCTP packet, including the State Cookie. If this comparison fails, the SCTP packet,
COOKIE ECHO and any DATA chunks, should be silently discarded, including the COOKIE ECHO and any DATA chunks, should be silently
discarded,
3) Compare the port numbers and the Verification Tag contained within 3) Compare the port numbers and the Verification Tag contained
the COOKIE ECHO chunk to the actual port numbers and the within the COOKIE ECHO chunk to the actual port numbers and the
Verification Tag within the SCTP common header of the received Verification Tag within the SCTP common header of the received
packet. If these values do not match, the packet MUST be silently packet. If these values do not match, the packet MUST be
discarded. silently discarded.
4) Compare the creation timestamp in the State Cookie to the current 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
ECHO and any attached DATA chunks, SHOULD be discarded, and the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded,
endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error and the endpoint MUST transmit an ERROR chunk with a "Stale
cause to the peer endpoint. Cookie" error cause to the peer endpoint.
5) 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.
6) Send a COOKIE ACK chunk to the peer acknowledging receipt 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.
7) 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 5, follow the rules defined in Section 6.2). As mentioned in step
if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST 5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
appear first in the SCTP packet. MUST 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):
skipping to change at page 67, line 36 skipping to change at page 67, line 36
When a COOKIE ECHO chunk is received by an endpoint in any state for When a COOKIE ECHO chunk is received by an endpoint in any state for
an existing association (i.e., not in the CLOSED state) the following an existing association (i.e., not in the CLOSED state) the following
rules shall be applied: rules shall be applied:
1) Compute a MAC as described in Step 1 of Section 5.1.5, 1) Compute a MAC as described in Step 1 of Section 5.1.5,
2) Authenticate the State Cookie as described in Step 2 of 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.
the State Cookie is older than the lifespan carried in the State If the State Cookie is older than the lifespan carried in the
Cookie and the Verification Tags contained in the State Cookie do State Cookie and the Verification Tags contained in the State
not match the current association's Verification Tags, the packet, Cookie do not match the current association's Verification Tags,
including the COOKIE ECHO and any DATA chunks, should be the packet, including the COOKIE ECHO and any DATA chunks, should
discarded. The endpoint also MUST transmit an ERROR chunk with a be discarded. The endpoint also MUST transmit an ERROR chunk
"Stale Cookie" error cause to the peer endpoint (this is case C or with a "Stale Cookie" error cause to the peer endpoint (this is
D in Section 5.2). case C or D in Section 5.2).
If both Verification Tags in the State Cookie match the If both Verification Tags in the State Cookie match the
Verification Tags of the current association, consider the State Verification Tags of the current association, consider the State
Cookie valid (this is case E 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 72, line 25 skipping to change at page 72, line 25
same peer. same peer.
5.4. Path Verification 5.4. Path Verification
During association establishment, the two peers exchange a list of During association establishment, the two peers exchange a list of
addresses. In the predominant case, these lists accurately represent addresses. In the predominant case, these lists accurately represent
the addresses owned by each peer. However, it is possible that a the addresses owned by each peer. However, it is possible that a
misbehaving peer may supply addresses that it does not own. To misbehaving peer may supply addresses that it does not own. To
prevent this, the following rules are applied to all addresses of the prevent this, the following rules are applied to all addresses of the
new association: new association:
1) Any address passed to the sender of the INIT by its upper layer is 1) Any address passed to the sender of the INIT by its upper layer
automatically considered to be CONFIRMED. is automatically considered to be CONFIRMED.
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
the one that the INIT-ACK was sent to. the one that the INIT-ACK was sent to.
3) All other addresses not covered by rules 1 and 2 are considered 3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification. UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send To probe an address for verification, an endpoint will send
HEARTBEATs including a 64-bit random nonce and a path indicator (to HEARTBEATs including a 64-bit random nonce and a path indicator (to
identify the address that the HEARTBEAT is sent to) within the identify the address that the HEARTBEAT is sent to) within the
HEARTBEAT parameter. HEARTBEAT parameter.
skipping to change at page 76, line 21 skipping to change at page 76, line 21
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).
D) Then, the sender can send out as many new DATA chunks as Rule A D) When the time comes for the sender to transmit new DATA chunks,
and Rule B above allow. the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting
cwnd as follows:
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B allow.
Multiple DATA chunks committed for transmission MAY be bundled in a Multiple DATA chunks committed for transmission MAY be bundled in a
single packet. Furthermore, DATA chunks being retransmitted MAY be single packet. Furthermore, DATA chunks being retransmitted MAY be
bundled with new DATA chunks, as long as the resulting packet size bundled with new DATA chunks, as long as the resulting packet size
does not exceed the path MTU. A ULP may request that no bundling is does not exceed the path MTU. A ULP may request that no bundling is
performed but this should only turn off any delays that a SCTP performed but this should only turn off any delays that a SCTP
implementation may be using to increase bundling efficiency. It does implementation may be using to increase bundling efficiency. It does
not in itself stop all bundling from occurring (i.e. in case of not in itself stop all bundling from occurring (i.e. in case of
congestion or retransmission). congestion or retransmission).
skipping to change at page 78, line 5 skipping to change at page 78, line 18
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.
Acknowledegments MUST be sent in SACK chunks unless shutdown was Acknowledgments 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 are reported greater than the value in the Cumulative TSN Ack field are reported
in the Gap Ack Block fields. The SCTP endpoint MUST report as many 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 Gap Ack Blocks as can fit in a single SACK chunk limited by the
current path MTU. current path MTU.
skipping to change at page 81, line 29 skipping to change at page 81, line 29
that peer. that peer.
C) Any time a DATA chunk is marked for retransmission (via either T3- C) Any time a DATA chunk is marked for retransmission (via either T3-
rtx timer expiration (Section 6.3.3) or via fast retransmit rtx timer expiration (Section 6.3.3) or via fast retransmit
(Section 7.2.4), add the data size of those chunks to the rwnd. (Section 7.2.4), add the data size of those chunks to the rwnd.
Note: If the implementation is maintaining a timer on each DATA Note: If the implementation is maintaining a timer on each DATA
chunk then only DATA chunks whose timer expired would be marked chunk then only DATA chunks whose timer expired would be marked
for retransmission. for retransmission.
D) D) Any time a SACK arrives, the endpoint performs the following:
Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack 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
via a Gap Ack Block (e.g., the data receiver reneged on the acknowledged via a Gap Ack Block (e.g., the data receiver
data), then consider the corresponding DATA that might be reneged on the data), then consider the corresponding DATA that
possibly missing: Count one miss indication towards fast might be possibly missing: Count one miss indication towards
retransmit as described in Section 7.2.4 , and if no retransmit fast retransmit as described in Section 7.2.4 , and if no
timer is running for the destination address to which the DATA retransmit timer is running for the destination address to
chunk was originally transmitted, then T3-rtx is started for which the DATA chunk was originally transmitted, then T3-rtx is
that destination address. started for that destination address.
iv) If the Cumulative TSN Ack matches or exceeds the Fast
iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
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 82, line 49 skipping to change at page 82, line 46
RTO <- SRTT + 4 * RTTVAR. RTO <- SRTT + 4 * RTTVAR.
C3) When a new RTT measurement R' is made, set C3) When a new RTT measurement R' is made, set
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
and and
SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value Note: The value of SRTT used in the update to RTTVAR is its
before updating SRTT itself using the second assignment. value before updating SRTT itself using the second assignment.
After the computation, update RTO <- SRTT + 4 * RTTVAR. After the computation, update RTO <- SRTT + 4 * RTTVAR.
C4) When data is in flight and when allowed by rule C5 below, a new C4) When data is in flight and when allowed by rule C5 below, a new
RTT measurement MUST be made each round trip. Furthermore, new RTT measurement MUST be made each round trip. Furthermore, new
RTT measurements SHOULD be made no more than once per round-trip RTT measurements SHOULD be made no more than once per round-trip
for a given destination transport address. There are two reasons for a given destination transport address. There are two
for this recommendation: First, it appears that measuring more reasons for this recommendation: First, it appears that
frequently often does not in practice yield any significant measuring more frequently often does not in practice yield any
benefit [ALLMAN99]; second, if measurements are made more often, significant benefit [ALLMAN99]; second, if measurements are made
then the values of RTO.Alpha and RTO.Beta in rule C3 above should more often, then the values of RTO.Alpha and RTO.Beta in rule C3
be adjusted so that SRTT and RTTVAR still adjust to changes at above should be adjusted so that SRTT and RTTVAR still adjust to
roughly the same rate (in terms of how many round trips it takes changes at roughly the same rate (in terms of how many round
them to reflect new values) as they would if making only one trips it takes them to reflect new values) as they would if
measurement per round-trip and using RTO.Alpha and RTO.Beta as making only one measurement per round-trip and using RTO.Alpha
given in rule C3. However, the exact nature of these adjustments and RTO.Beta as given in rule C3. However, the exact nature of
remains a research issue. these adjustments 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
that were retransmitted (and thus for which it is ambiguous packets that were retransmitted (and thus for which it is
whether the reply was for the first instance of the the chunk or ambiguous whether the reply was for the first instance of the
for a later instance) the chunk or for a later instance)
IMPLEMENTATION NOTE: RTT measurements should only be made using a IMPLEMENTATION NOTE: RTT measurements should only be made using
chunk with TSN r if no chunk with TSN less than or equal to r is a chunk with TSN r if no chunk with TSN less than or equal to r
retransmitted since r is first sent. 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
it is rounded up to RTO.Min seconds. The reason for this rule is then it is rounded up to RTO.Min seconds. The reason for this
that RTOs that do not have a high minimum value are susceptible rule is that RTOs that do not have a high minimum value are
to unnecessary timeouts [ALLMAN99]. susceptible to unnecessary timeouts [ALLMAN99].
C7) A maximum value may be placed on RTO provided it is at least C7) A maximum value may be placed on RTO provided it is at least
RTO.max seconds. RTO.max seconds.
There is no requirement for the clock granularity G used for There is no requirement for the clock granularity G used for
computing RTT measurements and the different state variables, other computing RTT measurements and the different state variables, other
than: than:
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <-
G. G.
Experience [ALLMAN99] has shown that finer clock granularities (<= Experience [ALLMAN99] has shown that finer clock granularities (<=
100 msec) perform somewhat better than more coarse granularities. 100 msec) perform somewhat better than more coarse granularities.
6.3.2. Retransmission Timer Rules 6.3.2. Retransmission Timer Rules
The rules for managing the retransmission timer are as follows: The rules for managing the retransmission timer are as follows:
R1) Every time a DATA chunk is sent to any address (including a R1) Every time a DATA chunk is sent to any address (including a
retransmission), if the T3-rtx timer of that address is not retransmission), if the T3-rtx timer of that address is not
running, start it running so that it will expire after the RTO of running, start it running so that it will expire after the RTO
that address. The RTO used here is that obtained after any of that address. The RTO used here is that obtained after any
doubling due to previous T3-rtx timer expirations on the doubling due to previous T3-rtx timer expirations on the
corresponding destination address as discussed in rule E2 below. corresponding destination address as discussed in rule E2 below.
R2) Whenever all outstanding data sent to an address have been R2) Whenever all outstanding data sent to an address have been
acknowledged, turn off the T3-rtx timer of that address. acknowledged, turn off the T3-rtx timer of that address.
R3) Whenever a SACK is received that acknowledges the DATA chunk with R3) Whenever a SACK is received that acknowledges the DATA chunk
the earliest outstanding TSN for that address, restart T3-rtx with the earliest outstanding TSN for that address, restart T3-
timer for that address with its current RTO (if there is still rtx timer for that address with its current RTO (if there is
outstanding data on that address). still outstanding data on that address).
R4) Whenever a SACK is received missing a TSN that was previously R4) Whenever a SACK is received missing a TSN that was previously
acknowledged via a Gap Ack Block, start T3-rtx for the acknowledged via a Gap Ack Block, start T3-rtx for the
destination address to which the DATA chunk was originally destination address to which the DATA chunk was originally
transmitted if it is not already running. transmitted if it is not already running.
The following example shows the use of various timer rules (assuming The following example shows the use of various timer rules (assuming
the receiver uses delayed acks). the receiver uses delayed acks).
Endpoint A Endpoint Z Endpoint A Endpoint Z
skipping to change at page 85, line 6 skipping to change at page 85, line 11
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0] (Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Figure 8 - Timer Rule Examples Figure 8 - Timer Rule Examples
6.3.3. Handle T3-rtx Expiration 6.3.3. Handle T3-rtx Expiration
Whenever the retransmission timer T3-rtx expires for a destination Whenever the retransmission timer T3-rtx expires for a destination
address, do the following: address, do the following:
E1) For the destination address for which the timer expires, adjust E1) For the destination address for which the timer expires, adjust
its ssthresh with rules defined in Section 7.2.3 and set the cwnd its ssthresh with rules defined in Section 7.2.3 and set the
<- MTU. cwnd <- MTU.
E2) For the destination address for which the timer expires, set RTO E2) For the destination address for which the timer expires, set RTO
<- RTO * 2 ("back off the timer"). The maximum value discussed <- RTO * 2 ("back off the timer"). The maximum value discussed
in rule C7 above (RTO.max) may be used to provide an upper bound in rule C7 above (RTO.max) may be used to provide an upper bound
to this doubling operation. to this doubling operation.
E3) Determine how many of the earliest (i.e., lowest TSN) outstanding E3) Determine how many of the earliest (i.e., lowest TSN)
DATA chunks for the address for which the T3-rtx has expired will outstanding DATA chunks for the address for which the T3-rtx has
fit into a single packet, subject to the MTU constraint for the expired will fit into a single packet, subject to the MTU
path corresponding to the destination transport address to which constraint for the path corresponding to the destination
the retransmission is being sent (this may be different from the transport address to which the retransmission is being sent
address for which the timer expires [see Section 6.4]). Call (this may be different from the address for which the timer
this value K. Bundle and retransmit those K DATA chunks in a expires [see Section 6.4]). Call this value K. Bundle and
single packet to the destination endpoint. retransmit those K DATA chunks in a single packet to the
destination endpoint.
E4) Start the retransmission timer T3-rtx on the destination address E4) Start the retransmission timer T3-rtx on the destination address
to which the retransmission is sent, if rule R1 above indicates to which the retransmission is sent, if rule R1 above indicates
to do so. The RTO to be used for starting T3-rtx should be the to do so. The RTO to be used for starting T3-rtx should be the
one for the destination address to which the retransmission is one for the destination address to which the retransmission is
sent, which, when the receiver is multi-homed, may be different sent, which, when the receiver is multi-homed, may be different
from the destination address for which the timer expired (see from the destination address for which the timer expired (see
Section 6.4 below). Section 6.4 below).
After retransmitting, once a new RTT measurement is obtained (which After retransmitting, once a new RTT measurement is obtained (which
skipping to change at page 85, line 50 skipping to change at page 86, line 9
be marked for retransmission and sent as soon as cwnd allows be marked for retransmission and sent as soon as cwnd allows
(normally when a SACK arrives). (normally when a SACK arrives).
The final rule for managing the retransmission timer concerns The final rule for managing the retransmission timer concerns
failover (see Section 6.4.1): failover (see Section 6.4.1):
F1) Whenever an endpoint switches from the current destination F1) Whenever an endpoint switches from the current destination
transport address to a different one, the current retransmission transport address to a different one, the current retransmission
timers are left running. As soon as the endpoint transmits a timers are left running. As soon as the endpoint transmits a
packet containing DATA chunk(s) to the new transport address, packet containing DATA chunk(s) to the new transport address,
start the timer on that transport address, using the RTO value of start the timer on that transport address, using the RTO value
the destination address to which the data is being sent, if rule of the destination address to which the data is being sent, if
R1 indicates to do so. rule R1 indicates to do so.
6.4. Multi-homed SCTP Endpoints 6.4. Multi-homed SCTP Endpoints
An SCTP endpoint is considered multi-homed if there are more than one An SCTP endpoint is considered multi-homed if there are more than one
transport address that can be used as a destination address to reach transport address that can be used as a destination address to reach
that endpoint. that endpoint.
Moreover, the ULP of an endpoint shall select one of the multiple Moreover, the ULP of an endpoint shall select one of the multiple
destination addresses of a multi-homed peer endpoint as the primary destination addresses of a multi-homed peer endpoint as the primary
path (see Section 5.1.2 and Section 10.1 for details). path (see Section 5.1.2 and Section 10.1 for details).
skipping to change at page 91, line 15 skipping to change at page 91, line 28
Fragmentation takes the following steps: Fragmentation takes the following steps:
1) The data sender MUST break the user message into a series of DATA 1) The data sender MUST break the user message into a series of DATA
chunks such that each chunk plus SCTP overhead fits into an IP chunks such that each chunk plus SCTP overhead fits into an IP
datagram smaller than or equal to the association Path MTU. datagram smaller than or equal to the association Path MTU.
2) The transmitter MUST then assign, in sequence, a separate TSN to 2) The transmitter MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series. The transmitter assigns each of the DATA chunks in the series. The transmitter assigns
the same SSN to each of the DATA chunks. If the user indicates the same SSN to each of the DATA chunks. If the user indicates
that the user message is to be delivered using unordered delivery, that the user message is to be delivered using unordered
then the U flag of each DATA chunk of the user message MUST be set delivery, then the U flag of each DATA chunk of the user message
to 1. MUST be set to 1.
3) The transmitter MUST also set the B/E bits of the first DATA chunk 3) The transmitter MUST also set the B/E bits of the first DATA
in the series to '10', the B/E bits of the last DATA chunk in the chunk in the series to '10', the B/E bits of the last DATA chunk
series to '01', and the B/E bits of all other DATA chunks in the in the series to '01', and the B/E bits of all other DATA chunks
series to '00'. in the series to '00'.
An endpoint MUST recognize fragmented DATA chunks by examining the An endpoint MUST recognize fragmented DATA chunks by examining the
B/E bits in each of the received DATA chunks, and queue the B/E bits in each of the received DATA chunks, and queue the
fragmented DATA chunks for re-assembly. Once the user message is fragmented DATA chunks for re-assembly. Once the user message is
reassembled, SCTP shall pass the re-assembled user message to the reassembled, SCTP shall pass the re-assembled user message to the
specific stream for possible re-ordering and final dispatching. specific stream for possible re-ordering and final dispatching.
Note: If the data receiver runs out of buffer space while still Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the re-assembly of the waiting for more fragments to complete the re-assembly of the
message, it should dispatch part of its inbound message through a message, it should dispatch part of its inbound message through a
skipping to change at page 97, line 46 skipping to change at page 98, line 12
Point, the miss indications are incremented for all TSNs reported Point, the miss indications are incremented for all TSNs reported
missing in the SACK. missing in the SACK.
When the third consecutive miss indication is received for a TSN(s), When the third consecutive miss indication is received for a TSN(s),
the data sender shall do the following: the data sender shall do the following:
1) Mark the DATA chunk(s) with three miss indications for 1) Mark the DATA chunk(s) with three miss indications for
retransmission. retransmission.
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
destination address(es) to which the missing DATA chunks were last destination address(es) to which the missing DATA chunks were
sent, according to the formula described in Section 7.2.3. 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
to which the packet is being sent. Call this value K. Retransmit address to which the packet is being sent. Call this value K.
those K DATA chunks in a single packet. When a Fast Retransmit is Retransmit those K DATA chunks in a single packet. When a Fast
being performed, the sender SHOULD ignore the value of cwnd and Retransmit is being performed, the sender SHOULD ignore the value
SHOULD NOT delay retransmission for this single packet. 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
outstanding TSN number sent to that address, or the endpoint is lowest outstanding TSN number sent to that address, or the
retransmitting the first outstanding DATA chunk sent to that endpoint is retransmitting the first outstanding DATA chunk sent
address. to that address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus 5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that did for retransmission due to the Fast Retransmit algorithm that did
not fit in the sent datagram carrying K other TSNs are also marked not fit in the sent datagram carrying K other TSNs are also
as ineligible for a subsequent fast retransmit. However, as they marked as ineligible for a subsequent fast retransmit. However,
are marked for retransmission they will be retransmitted later on as they are marked for retransmission they will be retransmitted
as soon as cwnd allows. later on as soon as cwnd allows.
6) If not in Fast Recovery, enter Fast Recovery and mark the highest 6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd Recovery is exited. While in Fast Recovery, the ssthresh and
SHOULD NOT change for any destinations due to a subsequent Fast cwnd SHOULD NOT change for any destinations due to a subsequent
Recovery event (i.e., one SHOULD NOT reduce the cwnd further due Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further
to a subsequent fast retransmit). due to a subsequent fast retransmit).
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Section 7.2.1 and 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 3 and
starting the fast retransmit procedure, the counter resets to 0. starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
7.3. Path MTU Discovery 7.3. Path MTU Discovery
[RFC1191] specifies "Path MTU Discovery", whereby an endpoint [RFC1191] specifies "Path MTU Discovery", whereby an endpoint
maintains an estimate of the maximum transmission unit (MTU) along a maintains an estimate of the maximum transmission unit (MTU) along a
skipping to change at page 99, line 26 skipping to change at page 99, line 37
[RFC1191] of applying MTU discovery to TCP: [RFC1191] of applying MTU discovery to TCP:
1) SCTP associations can span multiple addresses. An endpoint MUST 1) SCTP associations can span multiple addresses. An endpoint MUST
maintain separate MTU estimates for each destination address of maintain separate MTU estimates for each destination address of
its peer. its peer.
2) Elsewhere in this document, when the term "MTU" is discussed, it 2) Elsewhere in this document, when the term "MTU" is discussed, it
refers to the MTU associated with the destination address refers to the MTU associated with the destination address
corresponding to the context of the discussion. corresponding to the context of the discussion.
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment Size". 3) Unlike TCP, SCTP does not have a notion of "Maximum Segment
Accordingly, the MTU for each destination address SHOULD be Size". Accordingly, the MTU for each destination address SHOULD
initialized to a value no larger than the link MTU for the local be initialized to a value no larger than the link MTU for the
interface to which packets for that remote destination address local interface to which packets for that remote destination
will be routed. address will be routed.
4) Since data transmission in SCTP is naturally structured in terms 4) Since data transmission in SCTP is naturally structured in terms
of TSNs rather than bytes (as is the case for TCP), the discussion of TSNs rather than bytes (as is the case for TCP), the
in Section 6.5 of [RFC1191] applies: When retransmitting an IP discussion in Section 6.5 of [RFC1191] applies: When
datagram to a remote address for which the IP datagram appears too retransmitting an IP datagram to a remote address for which the
large for the path MTU to that address, the IP datagram SHOULD be IP datagram appears too large for the path MTU to that address,
retransmitted without the DF bit set, allowing it to possibly be the IP datagram SHOULD be retransmitted without the DF bit set,
fragmented. Transmissions of new IP datagrams MUST have DF set. allowing it to possibly be fragmented. Transmissions of new IP
datagrams MUST have DF set.
5) The sender should track an association PMTU which will be the 5) The sender should track an association PMTU which will be the
smallest PMTU discovered for all of the peer's destination smallest PMTU discovered for all of the peer's destination
addresses. When fragmenting messages into multiple parts this addresses. When fragmenting messages into multiple parts this
association PMTU should be used to calculate the size of each association PMTU should be used to calculate the size of each
fragment. This will allow retransmissions to be seamlessly sent fragment. This will allow retransmissions to be seamlessly sent
to an alternate address without encountering IP fragmentation. to an alternate address without encountering IP fragmentation.
Other than these differences, the discussion of TCP's use of MTU Other than these differences, the discussion of TCP's use of MTU
discovery in [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 (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT Chunks. 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 MAY 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 103, line 21 skipping to change at page 103, line 46
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 CRC32c 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, a receiver 1) If the OOTB packet is to or from a non-unicast address, a
SHOULD silently discard the packet. Otherwise, receiver 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. If, for whatever 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 reason, the INIT cannot be processed normally and an ABORT has to
be sent in response, the Verification Tag of the packet containing be sent in response, the Verification Tag of the packet
the ABORT chunk MUST be the Initiate tag of the received INIT containing the ABORT chunk MUST be the Initiate tag of the
chunk, and the T-Bit of the ABORT chunk has to be set to 0, received INIT chunk, and the T-Bit of the ABORT chunk has to be
indicating that the Verification Tag is NOT reflected. 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
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of
packet must fill in the Verification Tag field of the outbound the OOTB packet must fill in the Verification Tag field of the
packet with the Verification Tag received in the SHUTDOWN ACK and outbound packet with the Verification Tag received in the
set the T-bit in the Chunk Flags to indicate that the Verification SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate
Tag is reflected. Otherwise, that the Verification 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
MUST fill in the Verification Tag field of the outbound packet packet MUST fill in the Verification Tag field of the outbound
with the value found in the Verification Tag field of the OOTB packet with the value found in the Verification Tag field of the
packet and set the T-bit in the Chunk Flags to indicate that the OOTB packet and set the T-bit in the Chunk Flags to indicate that
Verification Tag is reflected. After sending this ABORT, the the Verification Tag is reflected. After sending this ABORT, the
receiver of the OOTB packet shall discard the OOTB packet and take receiver of the OOTB packet shall discard the OOTB packet and
no further action. 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 118, line 23 skipping to change at page 119, line 4
association on which the failure detection threshold is to be set. association on which the failure detection threshold is to be set.
o failure threshold - the new value of 'Path.Max.Retrans' for the o failure threshold - the new value of 'Path.Max.Retrans' for the
destination address. destination address.
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport Format: SETPROTOCOLPARAMETERS(association id, [,destination transport
address,] protocol parameter list) address,] protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o protocol parameter list - The specific names and values of the o protocol parameter list - The specific names and values of the
protocol parameters (e.g., Association.Max.Retrans [see Section 14 protocol parameters (e.g., Association.Max.Retrans [see Section 15
) that the SCTP user wishes to customize. ) that the SCTP user wishes to customize.
Optional attributes: Optional attributes:
o destination transport address - some of the protocol parameters o destination transport address - some of the protocol parameters
may be set on a per destination transport address basis. may be set on a per destination transport address basis.
N) Receive unsent message N) Receive unsent message
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
[,stream id] [, stream sequence number] [,partial flag] [,stream id] [, stream sequence number] [,partial flag]
[,payload protocol-id]) [,payload protocol-id])
o data retrieval id - The identification passed to the ULP in the o data retrieval id - The identification passed to the ULP in the
skipping to change at page 122, line 4 skipping to change at page 122, line 30
blocking function call, the association parameters are returned as a blocking function call, the association parameters are returned as a
result of the ASSOCIATE primitive itself. In that case, result of the ASSOCIATE primitive itself. In that case,
COMMUNICATION UP notification is optional at the association COMMUNICATION UP notification is optional at the association
initiator's side. initiator's side.
The following shall be passed with the notification: The following shall be passed with the notification:
o 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 o status - This indicates what type of event has occurred
o destination transport address list - the complete set of transport o destination transport address list - the complete set of transport
addresses of the peer addresses of the peer
o outbound stream count - the maximum number of streams allowed to be o outbound stream count - the maximum number of streams allowed to
used in this association by the ULP be used in this association by the ULP
o inbound stream count - the number of streams the peer endpoint has o inbound stream count - the number of streams the peer endpoint has
requested with this association (this may not be the same number requested with this association (this may not be the same number
as 'outbound stream count'). as 'outbound stream count').
E) COMMUNICATION LOST notification E) COMMUNICATION LOST notification
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
may indicate that a failure OR a normal termination event status may indicate that a failure OR a normal termination
occurred in response to a shutdown or abort request. event 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 o Upper Layer Abort Reason - The abort reason specified in case of a
user-initiated abort. 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:
skipping to change at page 129, line 25 skipping to change at page 130, line 9
large packet in response, due to the inclusion of multiple ERROR large packet in response, due to the inclusion of multiple ERROR
parameters, MAY (at its discretion) elect to omit some or all of the 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 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 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 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 always possible that the INIT-ACK will be larger than the original
INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
small as possible to reduce the possibility of byte amplification small as possible to reduce the possibility of byte amplification
attacks. attacks.
12. Recommended Transmission Control Block (TCB) Parameters 12. Network Managment Considerations
A MIB for SCTP is defined in [RFC3873].
13. 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 13.1. Parameters necessary for the SCTP instance
Associations: A list of current associations and mappings to the data Associations: A list of current associations and mappings to the data
consumers for each association. This may be in the consumers for each association. This may be in the
form of a hash table or other implementation dependent form of a hash table or other implementation dependent
structure. The data consumers may be process structure. The data consumers may be process
identification information such as file descriptors, identification information such as file descriptors,
named pipe pointer, or table pointers dependent on how named pipe pointer, or table pointers dependent on how
SCTP is implemented. SCTP is implemented.
Secret Key: A secret key used by this endpoint to compute the MAC. Secret Key: A secret key used by this endpoint to compute the MAC.
This SHOULD be a cryptographic quality random number This SHOULD be a cryptographic quality random number
with a sufficient length. Discussion in RFC4086 can with a sufficient length. Discussion in RFC4086 can
be helpful in selection of the key. be helpful in selection of the key.
Address List: The list of IP addresses that this instance has bound. Address List: The list of IP addresses that this instance has bound.
This information is passed to one's peer(s) in INIT and This information is passed to one's peer(s) in INIT and
INIT ACK chunks. INIT ACK chunks.
SCTP Port: The local SCTP port number the endpoint is bound to. SCTP Port: The local SCTP port number the endpoint is bound to.
12.2. Parameters necessary per association (i.e. the TCB) 13.2. Parameters necessary per association (i.e. the TCB)
Peer : Tag value to be sent in every packet and is received Peer : Tag value to be sent in every packet and is received
Verification: in the INIT or INIT ACK chunk. Verification: in the INIT or INIT ACK chunk.
Tag : Tag :
My : Tag expected in every inbound packet and sent in the My : Tag expected in every inbound packet and sent in the
Verification: INIT or INIT ACK chunk. Verification: INIT or INIT ACK chunk.
Tag : Tag :
State : A state variable indicating what state the association State : A state variable indicating what state the association
skipping to change at page 132, line 4 skipping to change at page 132, line 26
: and possibly the stream number. : and possibly the stream number.
Outbound : An array of structures to track the outbound streams. Outbound : An array of structures to track the outbound streams.
Streams : Normally including the next sequence number to Streams : Normally including the next sequence number to
: be sent on the stream. : be sent on the stream.
Reasm Queue : A re-assembly queue. Reasm Queue : A re-assembly queue.
Local : The list of local IP addresses bound in to this Local : The list of local IP addresses bound in to this
Transport : association. Transport : association.
Address : Address :
List : List :
Association : The smallest PMTU discovered for all of the Association : The smallest PMTU discovered for all of the
PMTU : peer's transport addresses. PMTU : peer's transport addresses.
12.3. Per Transport Address Data 13.3. Per Transport Address Data
For each destination transport address in the peer's address list For each destination transport address in the peer's address list
derived from the INIT or INIT ACK chunk, a number of data elements derived from the INIT or INIT ACK chunk, a number of data elements
needs to be maintained including: needs to be maintained including:
Error count : The current error count for this destination. Error count : The current error count for this destination.
Error : Current error threshold for this destination i.e. Error : Current error threshold for this destination i.e.
Threshold : what value marks the destination down if Error count Threshold : what value marks the destination down if Error count
: reaches this value. : reaches this value.
skipping to change at page 133, line 44 skipping to change at page 133, line 44
this address is currently being used to compute a this address is currently being used to compute a
RTT. If this flag is 0, the next DATA chunk sent to this RTT. If this flag is 0, the next DATA chunk sent to this
destination should be used to compute a RTT and this destination should be used to compute a RTT and this
flag should be set. Every time the RTT calculation flag should be set. Every time the RTT calculation
completes (i.e. the DATA chunk is SACK'd) clear this completes (i.e. the DATA chunk is SACK'd) clear this
flag. flag.
last-time : The time this destination was last sent to. This can be last-time : The time this destination was last sent to. This can be
used : used to determine if a HEARTBEAT is needed. used : used to determine if a HEARTBEAT is needed.
12.4. General Parameters Needed 13.4. General Parameters Needed
Out Queue : A queue of outbound DATA chunks. Out Queue : A queue of outbound DATA chunks.
In Queue : A queue of inbound DATA chunks. In Queue : A queue of inbound DATA chunks.
13. IANA Considerations 14. IANA Considerations
This protocol will require port reservation like TCP for the use of This protocol will require port reservation like TCP for the use of
"well known" servers within the Internet. All current TCP ports "well known" servers within the Internet. All current TCP ports
shall be automatically reserved in the SCTP port address space. New shall be automatically reserved in the SCTP port address space. New
requests should follow IANA's current mechanisms for TCP. requests should follow IANA's current mechanisms for TCP.
This protocol may also be extended through IANA in three ways: This protocol may also be extended through IANA in three ways:
-- through definition of additional chunk types, -- through definition of additional chunk types,
-- through definition of additional parameter types, or -- through definition of additional parameter types, or
-- through definition of additional cause codes within 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 14.1. IETF-defined Chunk Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) A long and short name for the new chunk type; a) A long and short name for the new chunk type;
b) A detailed description of the structure of the chunk, which MUST b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2; conform to the basic structure defined in Section 3.2;
c) A detailed definition and description of intended use of each c) A detailed definition and description of intended use of each
field within the chunk, including the chunk flags if any; field within the chunk, including the chunk flags if any;
d) A detailed procedural description of the use of the new chunk type d) A detailed procedural description of the use of the new chunk type
within the operation of the protocol. within the operation of the protocol.
The last chunk type (255) is reserved for future extension if The last chunk type (255) is reserved for future extension if
necessary. necessary.
13.2. IETF-defined Chunk Parameter Extension 14.2. IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) Name of the parameter type. a) Name of the parameter type.
b) Detailed description of the structure of the parameter field. b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value This structure MUST conform to the general type-length-value
format described in Section 3.2.1. format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value. c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type, d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances 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. e) Each parameter type MUST be unique across all chunks.
13.3. IETF-defined Additional Error Causes 14.3. IETF-defined Additional Error Causes
Additional cause codes may be allocated in the range 11 to 65535 Additional cause codes may be allocated in the range 11 to 65535
through a Specification Required action as defined in [RFC2434]. through a Specification Required action as defined in [RFC2434].
Provided documentation must include the following information: Provided documentation must include the following information:
a) Name of the error condition. a) Name of the error condition.
b) Detailed description of the conditions under which an SCTP b) Detailed description of the conditions under which an SCTP
endpoint should issue an ERROR (or ABORT) with this cause code. endpoint should issue an ERROR (or ABORT) with this cause code.
skipping to change at page 135, line 36 skipping to change at page 135, line 40
d) Detailed description of the structure and content of data fields d) Detailed description of the structure and content of data fields
which accompany this cause code. which accompany this cause code.
The initial word (32 bits) of a cause code parameter MUST conform to The initial word (32 bits) of a cause code parameter MUST conform to
the format shown in Section 3.3.10, i.e.: the format shown in Section 3.3.10, i.e.:
-- first two bytes contain the cause code value -- first two bytes contain the cause code value
-- last two bytes contain length of the Cause Parameter. -- last two bytes contain length of the Cause Parameter.
13.4. Payload Protocol Identifiers 14.4. Payload Protocol Identifiers
Except for value 0 which is reserved by SCTP to indicate an Except for value 0 which is reserved by SCTP to indicate an
unspecified payload protocol identifier in a DATA chunk, SCTP will unspecified payload protocol identifier in a DATA chunk, SCTP will
not be responsible for standardizing or verifying any payload not be responsible for standardizing or verifying any payload
protocol identifiers; SCTP simply receives the identifier from the protocol identifiers; SCTP simply receives the identifier from the
upper layer and carries it with the corresponding payload data. upper layer and carries it with the corresponding payload data.
The upper layer, i.e., the SCTP user, SHOULD standardize any specific The upper layer, i.e., the SCTP user, SHOULD standardize any specific
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 15. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
Max.Burst - 4 Max.Burst - 4
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
skipping to change at page 136, line 23 skipping to change at page 136, line 27
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds HB.interval - 30 seconds
HB.Max.Burst - 1 HB.Max.Burst - 1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10). customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above. Note: RTO.Min SHOULD be set as recommended above.
15. Acknowledgements 16. Acknowledgements
An undertaking represented by this updated document is not a small An undertaking represented by this updated document is not a small
feat and represents the summation of the initial authors of RFC2960, feat and represents the summation of the initial authors of RFC2960,
Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor, I. Rytina, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer T. Taylor, I. Rytina,
M. Kalla, L. Zhang, V. Paxson , M. Kalla, L. Zhang, V. Paxson ,
add to that the comments from every one that contributed to the add to that the comments from every one that contributed to the
original RFC: original RFC:
skipping to change at page 137, line 23 skipping to change at page 137, line 27
Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar. Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
A special thanks to Mark Allman, who should actually be a co-author A special thanks to Mark Allman, who should actually be a co-author
for his work on the max-burst, but managed to wiggle out due to a for his work on the max-burst, but managed to wiggle out due to a
technicality. Also, we would like to acknowledge Lyndon Ong and Phil technicality. Also, we would like to acknowledge Lyndon Ong and Phil
Conrad for their valuable input and many contributions. Conrad for their valuable input and many contributions.
And finally you have this document. My thanks cannot be adequately And finally you have this document, and those that have commented
expressed for all of you who have participated in the coding, testing upon that including, Alfred Hines and Ronnie Sellars.
and updating process of this document all I can say is Thank You!
My thanks cannot be adequately expressed for all of you who have
participated in the coding, testing and updating process of this
document all I can say is Thank You!
Randall Stewart - Editor Randall Stewart - Editor
Appendix A. Explicit Congestion Notification Appendix A. Explicit Congestion Notification
ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification",
[RFC3168], January 1999) describes a proposed extension to IP that [RFC3168], January 1999) describes a proposed extension to IP that
details a method to become aware of congestion outside of datagram details a method to become aware of congestion outside of datagram
loss. This is an optional feature that an implementation MAY choose loss. This is an optional feature that an implementation MAY choose
to add to SCTP. This appendix details the minor differences to add to SCTP. This appendix details the minor differences
skipping to change at page 146, line 46 skipping to change at page 147, line 4
return 1; return 1;
} }
int int
validate_crc32(unsigned char *buffer, unsigned int length) validate_crc32(unsigned char *buffer, unsigned int length)
{ {
SCTP_message *message; SCTP_message *message;
unsigned int i; unsigned int i;
unsigned long original_crc32; unsigned long original_crc32;
unsigned long crc32 = ~0L; unsigned long crc32 = ~0L;
/* save and zero checksum */ /* save and zero checksum */
message = (SCTP_message *) buffer; message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum); original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L; message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length); crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1); return ((original_crc32 == crc32)? 1 : -1);
} }
16. References 17. References
16.1. Normative references 17.1. Normative references
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures [ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures
for DCEs using asynchronous-to-synchronous conversion".", for DCEs using asynchronous-to-synchronous conversion".",
ITU-T section 8.1.1.6.2. 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.
skipping to change at page 148, line 15 skipping to change at page 148, line 21
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission
Protocol (SCTP) Management Information Base (MIB)",
RFC 3873, September 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
16.2. Informative References 17.2. Informative References
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of [FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21, Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21,
July 1996. July 1996.
[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.
skipping to change at page 149, line 12 skipping to change at page 149, line 22
[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.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
September 1997. September 1997.
[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.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, April 2006.
Author's Address Author's Address
Randall R. Stewart Randall R. Stewart
Editor 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 Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 151, line 29 skipping to change at page 150, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 103 change blocks. 
255 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/