draft-ietf-sigtran-sctp-10.txt   draft-ietf-sigtran-sctp-11.txt 
skipping to change at page 1, line 21 skipping to change at page 1, line 22
Nortel Networks Nortel Networks
I. Rytina I. Rytina
Ericsson Ericsson
M. Kalla M. Kalla
Telcordia Telcordia
L. Zhang L. Zhang
UCLA UCLA
V. Paxson V. Paxson
ACIRI ACIRI
expires in six months June 16,2000 expires in six months July 3,2000
Stream Control Transmission Protocol Stream Control Transmission Protocol
<draft-ietf-sigtran-sctp-10.txt> <draft-ietf-sigtran-sctp-11.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 2, line 30 skipping to change at page 2, line 30
-- optional bundling of multiple user messages into a single SCTP -- optional bundling of multiple user messages into a single SCTP
packet, and packet, and
-- network-level fault tolerance through supporting of multi-homing -- network-level fault tolerance through supporting of multi-homing
at either or both ends of an association. at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks. and resistance to flooding and masquerade attacks.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.................................................. 5 1. Introduction.................................................. 4
1.1 Motivation.................................................. 5 1.1 Motivation.................................................. 5
1.2 Architectural View of SCTP.................................. 6 1.2 Architectural View of SCTP.................................. 5
1.3 Functional View of SCTP..................................... 6 1.3 Functional View of SCTP..................................... 6
1.3.1 Association Startup and Takedown........................ 7 1.3.1 Association Startup and Takedown........................ 7
1.3.2 Sequenced Delivery within Streams....................... 8 1.3.2 Sequenced Delivery within Streams....................... 8
1.3.3 User Data Fragmentation................................. 8 1.3.3 User Data Fragmentation................................. 8
1.3.4 Acknowledgement and Congestion Avoidance................ 8 1.3.4 Acknowledgement and Congestion Avoidance................ 8
1.3.5 Chunk Bundling ......................................... 8 1.3.5 Chunk Bundling ......................................... 8
1.3.6 Packet Validation....................................... 9 1.3.6 Packet Validation....................................... 8
1.3.7 Path Management......................................... 9 1.3.7 Path Management......................................... 9
1.4 Key Terms................................................... 10 1.4 Key Terms................................................... 9
1.5 Abbreviations............................................... 12 1.5 Abbreviations............................................... 12
1.6 Serial Number Arithmetic.................................... 13 1.6 Serial Number Arithmetic.................................... 12
2. Conventions.................................................... 13 2. Conventions.................................................... 13
3. SCTP packet Format............................................ 13 3. SCTP packet Format............................................ 13
3.1 SCTP Common Header Field Descriptions....................... 14 3.1 SCTP Common Header Field Descriptions....................... 14
3.2 Chunk Field Descriptions.................................... 15 3.2 Chunk Field Descriptions.................................... 15
3.2.1 Optional/Variable-length Parameter Format............... 17 3.2.1 Optional/Variable-length Parameter Format............... 17
3.3 SCTP Chunk Definitions...................................... 18 3.3 SCTP Chunk Definitions...................................... 18
3.3.1 Payload Data (DATA)..................................... 18 3.3.1 Payload Data (DATA)..................................... 18
3.3.2 Initiation (INIT)....................................... 20 3.3.2 Initiation (INIT)....................................... 20
3.3.2.1 Optional or Variable Length Parameters.............. 23 3.3.2.1 Optional or Variable Length Parameters.............. 22
3.3.3 Initiation Acknowledgement (INIT ACK)................... 25 3.3.3 Initiation Acknowledgement (INIT ACK)................... 25
3.3.3.1 Optional or Variable Length Parameters.............. 28 3.3.3.1 Optional or Variable Length Parameters.............. 28
3.3.4 Selective Acknowledgement (SACK)........................ 28 3.3.4 Selective Acknowledgement (SACK)........................ 28
3.3.5 Heartbeat Request (HEARTBEAT)........................... 31 3.3.5 Heartbeat Request (HEARTBEAT)........................... 31
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 32 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 32
3.3.7 Abort Association (ABORT)............................... 33 3.3.7 Abort Association (ABORT)............................... 33
3.3.8 Shutdown Association (SHUTDOWN)......................... 34 3.3.8 Shutdown Association (SHUTDOWN)......................... 33
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 34 3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 34
3.3.10 Operation Error (ERROR)................................ 35 3.3.10 Operation Error (ERROR)................................ 34
3.3.10.1 Invalid Stream Identifier.......................... 36 3.3.10.1 Invalid Stream Identifier.......................... 36
3.3.10.2 Missing Mandatory Parameter........................ 36 3.3.10.2 Missing Mandatory Parameter........................ 36
3.3.10.3 Stale Cookie Error................................. 37 3.3.10.3 Stale Cookie Error................................. 37
3.3.10.4 Out of Resource.................................... 37 3.3.10.4 Out of Resource.................................... 37
3.3.10.5 Unresolvable Address............................... 38 3.3.10.5 Unresolvable Address............................... 37
3.3.10.6 Unrecognized Chunk Type............................ 38 3.3.10.6 Unrecognized Chunk Type............................ 38
3.3.10.7 Invalid Mandatory Parameter........................ 38 3.3.10.7 Invalid Mandatory Parameter........................ 38
3.3.10.8 Unrecognized Parameters............................ 39 3.3.10.8 Unrecognized Parameters............................ 38
3.3.10.9 No User Data....................................... 39 3.3.10.9 No User Data....................................... 39
3.3.10.10 Cookie Received While Shutting Down............... 39 3.3.10.10 Cookie Received While Shutting Down............... 39
3.3.11 Cookie Echo (COOKIE ECHO).............................. 40 3.3.11 Cookie Echo (COOKIE ECHO).............................. 39
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 40 3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 40
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 41 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 40
4. SCTP Association State Diagram................................. 41 4. SCTP Association State Diagram................................. 41
5. Association Initialization..................................... 44 5. Association Initialization..................................... 44
5.1 Normal Establishment of an Association...................... 45 5.1 Normal Establishment of an Association...................... 44
5.1.1 Handle Stream Parameters................................ 46 5.1.1 Handle Stream Parameters................................ 46
5.1.2 Handle Address Parameters............................... 47 5.1.2 Handle Address Parameters............................... 46
5.1.3 Generating State Cookie................................. 48 5.1.3 Generating State Cookie................................. 48
5.1.4 State Cookie Processing................................. 49 5.1.4 State Cookie Processing................................. 48
5.1.5 State Cookie Authentication............................. 49 5.1.5 State Cookie Authentication............................. 49
5.1.6 An Example of Normal Association Establishment.......... 50 5.1.6 An Example of Normal Association Establishment.......... 50
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO, 5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK.............................................. 51 and COOKIE ACK.............................................. 51
5.2.1 Handle Duplicate INIT in COOKIE-WAIT 5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or COOKIE-ECHOED States................................. 52 or COOKIE-ECHOED States................................. 52
5.2.2 Unexpected INIT in States Other than CLOSED, 5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED and COOKIE-WAIT........................... 52 COOKIE-ECHOED and COOKIE-WAIT........................... 52
5.2.3 Unexpected INIT ACK..................................... 53 5.2.3 Unexpected INIT ACK..................................... 52
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 53 5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 52
5.2.5 Handle Duplicate COOKIE ACK............................. 55 5.2.5 Handle Duplicate COOKIE ACK............................. 54
5.2.6 Handle Stale COOKIE Error............................... 55 5.2.6 Handle Stale COOKIE Error............................... 55
5.3 Other Initialization Issues................................. 56 5.3 Other Initialization Issues................................. 55
5.3.1 Selection of Tag Value.................................. 56 5.3.1 Selection of Tag Value.................................. 55
6. User Data Transfer............................................. 56 6. User Data Transfer............................................. 56
6.1 Transmission of DATA Chunks................................. 57 6.1 Transmission of DATA Chunks................................. 57
6.2 Acknowledgement on Reception of DATA Chunks................. 59 6.2 Acknowledgement on Reception of DATA Chunks................. 58
6.2.1 Tracking Peer's Receive Buffer Space.................... 61 6.2.1 Tracking Peer's Receive Buffer Space.................... 61
6.3 Management Retransmission Timer............................. 62 6.3 Management Retransmission Timer............................. 62
6.3.1 RTO Calculation......................................... 63 6.3.1 RTO Calculation......................................... 62
6.3.2 Retransmission Timer Rules.............................. 64 6.3.2 Retransmission Timer Rules.............................. 63
6.3.3 Handle T3-rtx Expiration................................ 65 6.3.3 Handle T3-rtx Expiration................................ 64
6.4 Multi-homed SCTP Endpoints.................................. 66 6.4 Multi-homed SCTP Endpoints.................................. 65
6.4.1 Failover from Inactive Destination Address.............. 66 6.4.1 Failover from Inactive Destination Address.............. 66
6.5 Stream Identifier and Stream Sequence Number................ 67 6.5 Stream Identifier and Stream Sequence Number................ 67
6.6 Ordered and Unordered Delivery.............................. 67 6.6 Ordered and Unordered Delivery.............................. 67
6.7 Report Gaps in Received DATA TSNs........................... 68 6.7 Report Gaps in Received DATA TSNs........................... 68
6.8 Adler-32 Checksum Calculation............................... 69 6.8 Adler-32 Checksum Calculation............................... 69
6.9 Fragmentation............................................... 70 6.9 Fragmentation............................................... 69
6.10 Bundling .................................................. 71 6.10 Bundling .................................................. 70
7. Congestion Control .......................................... 71 7. Congestion Control .......................................... 71
7.1 SCTP Differences from TCP Congestion Control................ 72 7.1 SCTP Differences from TCP Congestion Control................ 71
7.2 SCTP Slow-Start and Congestion Avoidance.................... 73 7.2 SCTP Slow-Start and Congestion Avoidance.................... 72
7.2.1 Slow-Start.............................................. 73 7.2.1 Slow-Start.............................................. 73
7.2.2 Congestion Avoidance.................................... 74 7.2.2 Congestion Avoidance.................................... 74
7.2.3 Congestion Control...................................... 75 7.2.3 Congestion Control...................................... 75
7.2.4 Fast Retransmit on Gap Reports.......................... 75 7.2.4 Fast Retransmit on Gap Reports.......................... 75
7.3 Path MTU Discovery.......................................... 76 7.3 Path MTU Discovery.......................................... 76
8. Fault Management.............................................. 77 8. Fault Management.............................................. 77
8.1 Endpoint Failure Detection.................................. 77 8.1 Endpoint Failure Detection.................................. 77
8.2 Path Failure Detection...................................... 78 8.2 Path Failure Detection...................................... 77
8.3 Path Heartbeat.............................................. 78 8.3 Path Heartbeat.............................................. 78
8.4 Handle "Out of the blue" Packets............................ 80 8.4 Handle "Out of the blue" Packets............................ 80
8.5 Verification Tag............................................ 81 8.5 Verification Tag............................................ 81
8.5.1 Exceptions in Verification Tag Rules.................... 81 8.5.1 Exceptions in Verification Tag Rules.................... 81
9. Termination of Association..................................... 82 9. Termination of Association..................................... 82
9.1 Abort of an Association..................................... 82 9.1 Abort of an Association..................................... 82
9.2 Shutdown of an Association.................................. 83 9.2 Shutdown of an Association.................................. 83
10. Interface with Upper Layer.................................... 85 10. Interface with Upper Layer.................................... 85
10.1 ULP-to-SCTP................................................ 85 10.1 ULP-to-SCTP................................................ 85
10.2 SCTP-to-ULP................................................ 94 10.2 SCTP-to-ULP................................................ 94
11. Security Considerations....................................... 97 11. Security Considerations....................................... 96
11.1 Security Objectives........................................ 97 11.1 Security Objectives........................................ 96
11.2 SCTP Responses To Potential Threats........................ 97 11.2 SCTP Responses To Potential Threats........................ 97
11.2.1 Countering Insider Attacks............................. 97 11.2.1 Countering Insider Attacks............................. 97
11.2.2 Protecting against Data Corruption in the Network...... 97 11.2.2 Protecting against Data Corruption in the Network...... 97
11.2.3 Protecting Confidentiality............................. 98 11.2.3 Protecting Confidentiality............................. 97
11.2.4 Protecting against Blind Denial of Service Attacks..... 98 11.2.4 Protecting against Blind Denial of Service Attacks..... 98
11.2.4.1 Flooding........................................... 98 11.2.4.1 Flooding........................................... 98
11.2.4.2 Masquerade......................................... 99 11.2.4.2 Masquerade......................................... 99
11.2.4.3 Improper Monopolization of Services................100 11.2.4.3 Improper Monopolization of Services................100
11.3 Protection against Fraud and Repudiation...................100 11.3 Protection against Fraud and Repudiation...................100
12. Recommended Transmission Control Block (TCB) Parameters.......101 12. Recommended Transmission Control Block (TCB) Parameters.......101
12.1 Parameters necessary for the SCTP instance.................101 12.1 Parameters necessary for the SCTP instance.................101
12.2 Parameters necessary per association (i.e. the TCB)........101 12.2 Parameters necessary per association (i.e. the TCB)........101
12.3 Per Transport Address Data.................................103 12.3 Per Transport Address Data.................................102
12.4 General Parameters Needed..................................104 12.4 General Parameters Needed..................................104
13. IANA Consideration............................................104 13. IANA Consideration............................................104
13.1 IETF-defined Chunk Extension...............................104 13.1 IETF-defined Chunk Extension...............................104
13.2 IETF-defined Additional Error Causes.......................105 13.2 IETF-defined Additional Error Causes.......................104
13.3 Payload Protocol Identifiers...............................105 13.3 Payload Protocol Identifiers...............................105
14. Suggested SCTP Protocol Parameter Values......................106 14. Suggested SCTP Protocol Parameter Values......................105
15. Acknowledgements..............................................106 15. Acknowledgements..............................................106
16. Authors' Addresses............................................106 16. Authors' Addresses............................................106
17. References....................................................107 17. References....................................................107
18. Bibliography..................................................108 18. Bibliography..................................................108
Appendix A .......................................................109 Appendix A .......................................................109
Appendix B .......................................................110 Appendix B .......................................................110
1. Introduction 1. Introduction
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
skipping to change at page 11, line 38 skipping to change at page 11, line 17
uniquely identified by the transport addresses used by the endpoints uniquely identified by the transport addresses used by the endpoints
in the association. Two SCTP endpoints MUST NOT have more than one in the association. Two SCTP endpoints MUST NOT have more than one
SCTP association between them at any given time. SCTP association between them at any given time.
o SCTP endpoint: The logical sender/receiver of SCTP packets. On a o SCTP endpoint: The logical sender/receiver of SCTP packets. On a
multi-homed host, an SCTP endpoint is represented to its peers as a multi-homed host, an SCTP endpoint is represented to its peers as a
combination of a set of eligible destination transport addresses to combination of a set of eligible destination transport addresses to
which SCTP packets can be sent and a set of eligible source which SCTP packets can be sent and a set of eligible source
transport addresses from which SCTP packets can be received. transport addresses from which SCTP packets can be received.
All transport addresses used by an SCTP endpoint must use the All transport addresses used by an SCTP endpoint must use the
same port number, but can use multiple IP addresses. same port number, but can use multiple IP addresses. A transport
address used by an SCTP endpoint must not be used by another
SCTP endpoint. In other words, a transport address is unique
to an SCTP endpoint.
o SCTP packet (or packet): The unit of data delivery across the o SCTP packet (or packet): The unit of data delivery across the
interface between SCTP and the connectionless packet network (e.g., interface between SCTP and the connectionless packet network (e.g.,
IP). An SCTP packet includes the common SCTP header, possible SCTP IP). An SCTP packet includes the common SCTP header, possible SCTP
control chunks, and user data encapsulated within SCTP DATA chunks. control chunks, and user data encapsulated within SCTP DATA chunks.
o SCTP user application (SCTP user): The logical higher-layer o SCTP user application (SCTP user): The logical higher-layer
application entity which uses the services of SCTP, also called application entity which uses the services of SCTP, also called
the Upper-layer Protocol (ULP). the Upper-layer Protocol (ULP).
skipping to change at page 14, line 47 skipping to change at page 14, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number | | Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag | | Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer) Source Port Number: 16 bits (unsigned integer)
This is the SCTP senders port number. It can be used by the This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the receiver in combination with the source IP address, the
SCTP destination port and possibly the destination IP address SCTP destination port and possibly the destination IP address
to identify the association to which this packet belongs. to identify the association to which this packet belongs.
Destination Port Number: 16 bits (unsigned integer) Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined. The This is the SCTP port number to which this packet is destined. The
receiving host will use this port number to de-multiplex the receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application. SCTP packet to the correct receiving endpoint/application.
skipping to change at page 16, line 19 skipping to change at page 15, line 53
5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT) 6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN) 7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK) 8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR) 9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO) 10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK) 11 - Cookie Acknowledgement (COOKIE ACK)
12 - Reserved for Explicit Congestion Notification Echo (ECNE) 12 - Reserved for Explicit Congestion Notification Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR) 13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE) 14 - Shutdown Complete (SHUTDOWN COMPLETE)
15 to 63 - reserved by IETF 15 to 62 - reserved by IETF
63 - IETF-defined Chunk Extensions 63 - IETF-defined Chunk Extensions
64 to 126 - reserved by IETF 64 to 126 - reserved by IETF
127 - IETF-defined Chunk Extensions 127 - IETF-defined Chunk Extensions
128 to 190 - reserved by IETF 128 to 190 - reserved by IETF
191 - IETF-defined Chunk Extensions 191 - IETF-defined Chunk Extensions
192 to 254 - reserved by IETF 192 to 254 - reserved by IETF
255 - IETF-defined Chunk Extensions 255 - IETF-defined Chunk Extensions
Chunk Types are encoded such that the highest-order two bits Chunk Types are encoded such that the highest-order two bits
specify the action that must be taken if the processing specify the action that must be taken if the processing
skipping to change at page 22, line 44 skipping to change at page 22, line 25
not be lessened (i.e. dedicated buffers taken away from this not be lessened (i.e. dedicated buffers taken away from this
association); however, an endpoint MAY change the value of a_rwnd association); however, an endpoint MAY change the value of a_rwnd
it sends in SACK chunks. it sends in SACK chunks.
Number of Outbound Streams (OS): 16 bits (unsigned integer) Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT chunk Defines the number of outbound streams the sender of this INIT chunk
wishes to create in this association. The value of 0 MUST NOT be wishes to create in this association. The value of 0 MUST NOT be
used. used.
Note: A receiver of an INIT with the OS value set to 0 SHOULD ABORT Note: A receiver of an INIT with the OS value set to 0 SHOULD abort
the association. the association.
Number of Inbound Streams (MIS) : 16 bits (unsigned integer) Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT chunk Defines the maximum number of streams the sender of this INIT chunk
allows the peer end to create in this association. The value 0 MUST allows the peer end to create in this association. The value 0 MUST
NOT be used. NOT be used.
Note: There is no negotiation of the actual number of streams Note: There is no negotiation of the actual number of streams
but instead the two endpoints will use the min(requested, but instead the two endpoints will use the min(requested,
offered). See Section 5.1.1 for details. offered). See Section 5.1.1 for details.
Note: A receiver of an INIT with the MIS value of 0 SHOULD ABORT Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
the association. the association.
Initial TSN (I-TSN) : 32 bits (unsigned integer) Initial TSN (I-TSN) : 32 bits (unsigned integer)
Defines the initial TSN that the sender will use. The valid range is Defines the initial TSN that the sender will use. The valid range is
from 0 to 4294967295. This field MAY be set to the value of the from 0 to 4294967295. This field MAY be set to the value of the
Initiate Tag field. Initiate Tag field.
3.3.2.1 Optional/Variable Length Parameters in INIT 3.3.2.1 Optional/Variable Length Parameters in INIT
skipping to change at page 26, line 25 skipping to change at page 26, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN | | Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Optional/Variable-Length Parameters / / Optional/Variable-Length Parameters /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag: 32 bits (unsigned integer) Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK (the responding end) records the value The receiver of the INIT ACK records the value of the Initiate Tag
of the Initiate Tag parameter. This value MUST be placed into the parameter. This value MUST be placed into the Verification Tag
Verification Tag field of every SCTP packet that the INIT ACK field of every SCTP packet that the INIT ACK receiver transmits
receiver transmits within this association. within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value. more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK chunk is If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST treat it as an error and close the found to be 0, the receiver MUST treat it as an error and close the
association by transmitting an ABORT. association by transmitting an ABORT.
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
skipping to change at page 28, line 34 skipping to change at page 28, line 18
3.3.3.1 Optional or Variable Length Parameters 3.3.3.1 Optional or Variable Length Parameters
State Cookie State Cookie
Parameter Type Value: 7 Parameter Type Value: 7
Parameter Length: variable size, depending on Size of Cookie Parameter Length: variable size, depending on Size of Cookie
Parameter Value: Parameter Value:
This parameter value MUST contain all the necessary state and This parameter value MUST contain all the necessary state and
parameter information required for the sender of this INIT ACK to parameter information required for the sender of this INIT ACK to
create the association, along with Message Authentication Code create the association, along with a Message Authentication Code
(MAC). See Section 5.1.3 for details on State Cookie definition. (MAC). See Section 5.1.3 for details on State Cookie definition.
Unrecognized Parameters: Unrecognized Parameters:
Parameter Type Value: 8 Parameter Type Value: 8
Parameter Length: Variable Size. Parameter Length: Variable Size.
Parameter Value: Parameter Value:
This parameter is returned to the originator of the INIT chunk This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter which has a value when the INIT contains an unrecognized parameter which has a value
skipping to change at page 32, line 30 skipping to change at page 32, line 14
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length | | Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info / / Sender-specific Heartbeat Info /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-specific Heartbeat Info field should normally include The Sender-specific Heartbeat Info field should normally include
information about the senders current time when this HEARTBEAT information about the sender's current time when this HEARTBEAT
chunk is sent and the destination transport address to which this chunk is sent and the destination transport address to which this
HEARTBEAT is sent (see Section 8.3). HEARTBEAT is sent (see Section 8.3).
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5): 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):
An endpoint should send this chunk to its peer endpoint as a response An endpoint should send this chunk to its peer endpoint as a response
to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always
sent to the source IP address of the IP datagram containing the sent to the source IP address of the IP datagram containing the
HEARTBEAT chunk to which this ack is responding. HEARTBEAT chunk to which this ack is responding.
skipping to change at page 37, line 22 skipping to change at page 37, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N | | Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Missing params: 32 bits (unsigned integer) Number of Missing params: 32 bits (unsigned integer)
This field contains the number of parameters contained in the This field contains the number of parameters contained in the
Cause-specific Information field. Cause-specific Information field.
Missing Param Type: 16 bits (unsigned integer) Missing Param Type: 16 bits (unsigned integer)
Each field will contain the missing mandatory parameter number.
This field contains a mandatory parameter that was missing in the
INIT or INIT ACK message. This field contains the complete
Parameter, including Type, Length and Value fields.
3.3.10.3 Stale Cookie Error (3) 3.3.10.3 Stale Cookie Error (3)
Cause of error Cause of error
-------------- --------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired. that has expired.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 | | Cause Code=3 | Cause Length=8 |
skipping to change at page 40, line 26 skipping to change at page 40, line 7
It is sent by the initiator of an association to its peer to complete It is sent by the initiator of an association to its peer to complete
the initialization process. This chunk MUST precede any DATA chunk the initialization process. This chunk MUST precede any DATA chunk
sent within the association, but MAY be bundled with one or more DATA sent within the association, but MAY be bundled with one or more DATA
chunks in the same packet. chunks in the same packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length | | Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie | / Cookie /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bit Chunk Flags: 8 bit
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the 4 bytes of Set to the size of the chunk in bytes, including the 4 bytes of
the chunk header and the size of the Cookie. the chunk header and the size of the Cookie.
skipping to change at page 41, line 15 skipping to change at page 40, line 46
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 | | Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Set to zero on transmit and ignored on receipt. Set to zero on transmit and ignored on receipt.
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (12): 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (14):
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK
chunk at the completion of the shutdown process, see Section 9.2 for chunk at the completion of the shutdown process, see Section 9.2 for
details. details.
The SHUTDOWN COMPLETE chunk has no parameters. The SHUTDOWN COMPLETE chunk has no parameters.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 |Reserved |T| Length = 4 | | Type = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits Chunk Flags: 8 bits
Reserved: 7 bits Reserved: 7 bits
Set to 0 on transmit and ignored on receipt. Set to 0 on transmit and ignored on receipt.
T bit: 1 bit T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it destroyed. If The T bit is set to 0 if the sender had a TCB that it destroyed. If
the sender did NOT have a TCB it should set this bit to 1. the sender did NOT have a TCB it should set this bit to 1.
Note: Special rules apply to this chunk for verification, please Note: Special rules apply to this chunk for verification, please
see Section 8.5.1 for details. see Section 8.5.1 for details.
4. SCTP Association State Diagram 4. SCTP Association State Diagram
During the lifetime of an SCTP association, the SCTP endpoints association During the lifetime of an SCTP association, the SCTP endpoint's association
progress from one state to another in response to various events. The progress from one state to another in response to various events. The
events that may potentially advance an association's state include: events that may potentially advance an association's state include:
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT], o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc. control o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc. control
chunks, or chunks, or
o Some timeout events. o Some timeout events.
skipping to change at page 44, line 32 skipping to change at page 44, line 12
(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 retransmit (6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit
data and leave this state when all data inqueue is transmitted. data and leave this state when all data inqueue is transmitted.
(7 In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new (7) In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new
send request from its SCTP user. send request from its SCTP user.
The CLOSED state is used to indicate that an association is not The CLOSED state is used to indicate that an association is not
created (i.e., doesn't exist). created (i.e., doesn't exist).
5. Association Initialization 5. Association Initialization
Before the first data transmission can take place from one SCTP Before the first data transmission can take place from one SCTP
endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must
complete an initialization process in order to set up an SCTP complete an initialization process in order to set up an SCTP
skipping to change at page 46, line 8 skipping to change at page 45, line 43
COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie
timer. It may also notify its ULP about the successful timer. It may also notify its ULP about the successful
establishment of the association with a Communication Up establishment of the association with a Communication Up
notification (see Section 10). notification (see Section 10).
An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.
They MUST be the only chunks present in the SCTP packets that carry They MUST be the only chunks present in the SCTP packets that carry
them. them.
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
doesn't control the source IP address that is used for transmitting),
an endpoint might need to include in its INIT or INIT ACK all possible
IP addresses from which packets to the peer could be transmitted.
An endpoint MUST send the INIT ACK to the IP address from which it An endpoint MUST send the INIT ACK to the IP address from which it
received the INIT. received the INIT.
Note: T1-init timer and T1-cookie timer shall follow the same rules Note: T1-init timer and T1-cookie timer shall follow the same rules
given in Section 6.3. given in Section 6.3.
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter values, parameters in the received INIT or INIT ACK, invalid parameter values,
or lack of local resources, it MUST respond with an ABORT chunk. It or lack of local resources, it MUST respond with an ABORT chunk. It
skipping to change at page 48, line 14 skipping to change at page 47, line 42
INIT or INIT ACK chunk, the receiver shall derive and record all INIT or INIT ACK chunk, the receiver shall derive and record all
the transport address(es) from the received chunk AND the the transport address(es) from the received chunk AND the
source IP address that sent the INIT or INIT ACK. The transport source IP address that sent the INIT or INIT ACK. The transport
address(es) are derived by the combination of SCTP source port (from address(es) are derived by the combination of SCTP source port (from
the common header) and the IP address parameter(s) carried in the the common header) and the IP address parameter(s) carried in the
INIT or INIT ACK chunk and the source IP address of the IP datagram. INIT or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets destination transport addresses when sending subsequent packets
to its peer. to its peer.
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
doesn't control the source IP address that is used for transmitting),
an endpoint might need to include in its INIT or INIT ACK all possible
IP addresses from which packets to the peer could be transmitted.
After all transport addresses are derived from the INIT or INIT ACK After all transport addresses are derived from the INIT or INIT ACK
chunk using the above rules, the endpoint shall select one of the chunk using the above rules, the endpoint shall select one of the
transport addresses as the initial primary path. transport addresses as the initial primary path.
Note: The INIT-ACK MUST be sent to the source address of the INIT. Note: The INIT-ACK MUST be sent to the source address of the INIT.
The sender of INIT may include a 'Supported Address Types' The sender of INIT may include a 'Supported Address Types'
parameter in the INIT to indicate what types of address are parameter in the INIT to indicate what types of address are
acceptable. When this parameter is present, the receiver of INIT acceptable. When this parameter is present, the receiver of INIT
(initiatee) MUST either use one of the address types indicated in the (initiatee) MUST either use one of the address types indicated in the
skipping to change at page 48, line 52 skipping to change at page 48, line 32
with all the information necessary for it to establish the association. with all the information necessary for it to establish 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 received
INIT and the outgoing INIT ACK chunk, 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) Generate a MAC using the TCB and a secret key (see [RFC2104] for an 3) From the TCB, identify and collect the minimal subset of
information needed to re-create the TCB, and generate a MAC using
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 the smallest amount of 4) Generate the State Cookie by combining this subset of information
information needed to generate a TCB and the resultant MAC. and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the sender After sending the INIT ACK with the State Cookie parameter, the sender
SHOULD delete the TCB and any other local resource related to the new SHOULD delete the TCB and any other local resource related to the new
association, so as to prevent resource attacks. association, so as to prevent resource attacks.
The hashing method used to generate the MAC is strictly a 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 private matter for the receiver of the INIT chunk. The use of a MAC
is mandatory to prevent denial of service attacks. The secret key is mandatory to prevent denial of service attacks. The secret key
SHOULD be random ([RFC1750] provides some information on randomness SHOULD be random ([RFC1750] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the guidelines); it SHOULD be changed reasonably frequently, and the
skipping to change at page 50, line 29 skipping to change at page 50, line 12
receiver of the COOKIE ECHO has an existing association, the procedures receiver of the COOKIE ECHO has an existing association, the procedures
in Section 5.2 should be followed. in 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 sends In the following example, "A" initiates the association and then sends
a user message to "Z", then "Z" sends two user messages to "A" later a user message to "Z", then "Z" sends two user messages to "A" later
(assuming no bundling or fragmentation occurs): (assuming no bundling or fragmentation occurs):
Endpoint A Endpoint Z Endpoint A Endpoint Z
x
{app sets association with Z} {app sets association with Z}
(build TCB) (build TCB)
INIT [I-Tag=Tag_A INIT [I-Tag=Tag_A
& other info] --------\ & other info] --------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A, /--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z, / I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info] (Cancel T1-init timer) <------/ Cookie_Z, & other info]
skipping to change at page 52, line 24 skipping to change at page 52, line 4
This usually indicates an initialization collision, i.e., each This usually indicates an initialization collision, i.e., each
endpoint is attempting, at about the same time, to establish an endpoint is attempting, at about the same time, to establish an
association with the other endpoint. association with the other endpoint.
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Verification Tag, sent in its original INIT chunk (including its Verification Tag,
unchanged). These original parameters are combined with those from the unchanged). These original parameters are combined with those from the
newly received INIT chunk. The endpoint shall also generate a State newly received INIT chunk. The endpoint shall also generate a State
Cookie with the INIT ACK. The endpoint uses the parameters sent in its Cookie with the INIT ACK. The endpoint uses the parameters sent in its
INIT to calculate the State Cookie. INIT to calculate the State Cookie.
After that, the endpoint MUST not change its state, the T1-init After that, the endpoint MUST NOT change its state, the T1-init
timer shall be left running and the corresponding TCB MUST NOT be timer shall be left running and the corresponding TCB MUST NOT be
destroyed. The normal procedures for handling State Cookies when destroyed. The normal procedures for handling State Cookies when
a TCB exists will resolve the duplicate INITs to a single association. a TCB exists will resolve the duplicate INITs to a single association.
For an endpoint that is in the COOKIE-ECHOED state it MUST populate
its Tie-Tags with the Tag information of itself and its peer (see
section 5.2.2 for a description of the Tie-Tags).
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED and 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED and
COOKIE-WAIT COOKIE-WAIT
Unless otherwise stated, upon reception of an unexpected INIT for this Unless otherwise stated, upon reception of an unexpected INIT for this
association, the endpoint shall generate an INIT ACK with a State association, the endpoint shall generate an INIT ACK with a State
Cookie. In the outbound INIT ACK the endpoint MUST copy its current Cookie. In the outbound INIT ACK the endpoint MUST copy its current
Verification Tag and Peers Verification tag into a reserved place Verification Tag and Peers Verification tag into a reserved place
within the state cookie. We shall refer to these locations as the within the state cookie. We shall refer to these locations as the
Peers-Tie-Tag and the Local-Tie-Tag. The INIT ACK MUST contain a new Peers-Tie-Tag and the Local-Tie-Tag. The INIT ACK MUST contain a new
Verification Tag (randomly generated see Section 5.3.1). Other Verification Tag (randomly generated see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g. number of outbound streams) into parameters of the association (e.g. number of outbound streams) into
the INIT ACK and cookie. the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further After sending out the INIT ACK, the endpoint shall take no further
actions, i.e., the existing association, including its current state, actions, i.e., the existing association, including its current state,
and the corresponding TCB MUST NOT be changed. and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is NOT in a Note: Only when a TCB exists and the association is NOT in a
COOKIE-ECHOED or COOKIE-WAIT state are the Tie-Tags populated. For a COOKIE-WAIT state are the Tie-Tags populated. For a normal association
normal association INIT (i.e. the endpoint ARE in a COOKIE-ECHOED or INIT (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST
COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no be set to 0 (indicating that no previous TCB existed). The INIT ACK
previous TCB existed). The INIT ACK and State Cookie are populated and State Cookie are populated as specified in section 5.2.1.
as specified in section 5.2.1.
5.2.3 Unexpected INIT ACK 5.2.3 Unexpected INIT ACK
If an INIT ACK is received by an endpoint in any state If an INIT ACK is received by an endpoint in any state
other than the COOKIE-WAIT state, the endpoint should discard other than the COOKIE-WAIT state, the endpoint should discard
the INIT ACK chunk. An unexpected INIT ACK usually indicates the the INIT ACK chunk. An unexpected INIT ACK usually indicates the
processing of an old or duplicated INIT chunk. processing of an old or duplicated INIT chunk.
5.2.4 Handle a COOKIE ECHO when a TCB exists 5.2.4 Handle a COOKIE ECHO when a TCB exists
skipping to change at page 53, line 57 skipping to change at page 53, line 39
6) If either of the Verification Tags do NOT match, refer to the following 6) If either of the Verification Tags do NOT match, refer to the following
table to determine the correct action to be taken. table to determine the correct action to be taken.
+------------+------------+---------------+--------------+-------------+ +------------+------------+---------------+--------------+-------------+
| Local Tag | Peers Tag | Local-Tie-Tag | Peers-Tie-Tag| Action/ | | Local Tag | Peers Tag | Local-Tie-Tag | Peers-Tie-Tag| Action/ |
| | | | | Description | | | | | | Description |
+------------+------------+---------------+--------------+-------------+ +------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) | | X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+ +------------+------------+---------------+--------------+-------------+
| X | M | M | M | (B) | | M | A | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | M | X | (C) |
+------------+------------+---------------+--------------+-------------+
| M | X | X | M | (D) |
+------------+------------+---------------+--------------+-------------+ +------------+------------+---------------+--------------+-------------+
| M | X | M | M | (E) | | X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+ +------------+------------+---------------+--------------+-------------+
| X | X | X | X | (F) | | M | M | A | A | (D) |
+======================================================================+ +======================================================================+
| Table 2: Handling of a Cookie when a TCB exists | | Table 2: Handling of a Cookie when a TCB exists |
+======================================================================+ +======================================================================+
Legend: Legend:
X - Tag does not match the existing TCB X - Tag does not match the existing TCB
M - Tag matches the existing TCB. M - Tag matches the existing TCB.
0 - No Tie-Tag in Cookie.
A - All cases match, no-match or unknown i.e. 0.
Actions Note: For any case not shown in Table 2, the cookie should be
silently discarded.
Action
(A)In this case, the peer may have restarted. When the endpoint (A)In this case, the peer may have restarted. When the endpoint
recognizes this potential 'restart', the existing session is recognizes this potential 'restart', the existing session is
treated the same as if it received an ABORT followed by a new treated the same as if it received an ABORT followed by a new
Cookie Echo with the following exceptions: Cookie Echo with the following exceptions:
- Any SCTP Data Chunks MAY be retained (this is an implementation - Any SCTP Data Chunks MAY be retained (this is an implementation
specific option). specific option).
- A notification of RESTART SHOULD be sent to the ULP instead - A notification of RESTART SHOULD be sent to the ULP instead
skipping to change at page 54, line 46 skipping to change at page 54, line 29
After this the endpoint shall enter the ESTABLISHED state. After this the endpoint shall enter the ESTABLISHED state.
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
the peer has restarted (Action A), it MUST NOT setup a new the peer has restarted (Action A), it MUST NOT setup a new
association but instead resend the SHUTDOWN ACK and send an ERROR association but instead resend the SHUTDOWN ACK and send an ERROR
chunk with a "Cookie Received while Shutting Down" error cause to chunk with a "Cookie Received while Shutting Down" error cause to
its peer. its peer.
(B)In this case, both sides may be attempting to start an (B)In this case, both sides may be attempting to start an
association at about the same time but the INIT-Ack of one side
was lost, and the other side completed the INIT sequence.
In this case, the endpoint MUST update the Local Verification
Tag from the Cookie, stay in or move to the Established State,
stop any init or cookie timers that may be running and
send a Cookie Ack.
(C)In this case, a software error may have occurred in the peer. The
peer changed its Verification Tag while it was in the Cookie Sent
state. The endpoint MAY stay in or move to the Established state,
but it must stop any init or cookie timers that may be running,
update its Verification Tag from the Cookie and send a
Cookie Ack.
(D)In this case, a software error may have occurred in the local
endpoint. The Verification Tag has been changed when in
the COOKIE-ECHOED state. The endpoint MAY stay in or enter the
Established state but it MUST update its peers Verification
Tag from the Cookie, stop any init or cookie timers that may
be running and send a Cookie Ack.
(E)In this case, both sides may be attempting to start an
association at about the same time but the peer endpoint association at about the same time but the peer endpoint
started its INIT after responding to the local endpoints started its INIT after responding to the local endpoints
INIT. Thus it picked a new Verification Tag not being aware INIT. Thus it may have picked a new Verification Tag not being aware
of the previous Tag it had sent this endpoint. The endpoint of the previous Tag it had sent this endpoint. The endpoint
should stay in or enter the Established state but it MUST update should stay in or enter the Established state but it MUST update
its peers Verification Tag from the Cookie, stop any init its peers Verification Tag from the Cookie, stop any init
or cookie timers that may running and send a Cookie Ack. or cookie timers that may running and send a Cookie Ack.
(F)In this case, an invalid cookie has been sent. The Cookie (C)In this case, the local endpoints cookie has arrived
MUST be silently discarded. late. Before it arrived the local endpoint, sent
a INIT and received a INIT-ACK and finally sent a
Cookie with the peers same tag but a new tag of
its own. The cookie should be silently discarded.
The endpoint should NOT change states and should
leave any timers running.
(D)When both local and remote tags match the endpoint should
always enter the Established state. It should stop any init
or cookie timers that may running and send a Cookie Ack.
Note: The "peer's Verification Tag" is the tag received in the Note: The "peer's Verification Tag" is the tag received in the
Initiate Tag field of the INIT or INIT ACK chunk. Initiate Tag field of the INIT or INIT ACK chunk.
5.2.5 Handle Duplicate COOKIE-ACK. 5.2.5 Handle Duplicate COOKIE-ACK.
At any state other than COOKIE-ECHOED, an endpoint should silently At any state other than COOKIE-ECHOED, an endpoint should silently
discard a received COOKIE ACK chunk. discard a received COOKIE ACK chunk.
5.2.6 Handle Stale COOKIE Error 5.2.6 Handle Stale COOKIE Error
skipping to change at page 56, line 38 skipping to change at page 56, line 7
association. association.
Moreover, the Verification Tag value used by either endpoint in a given Moreover, the Verification Tag value used by either endpoint in a given
association MUST NOT change during the lifetime of an association MUST NOT change during the lifetime of an
association. A new Verification Tag value MUST be used each association. A new Verification Tag value MUST be used each
time the endpoint tears-down and then re-establishes an association to time the endpoint tears-down and then re-establishes an association to
the same peer. the same peer.
6. User Data Transfer 6. User Data Transfer
Data transfer MUST only happen in the ESTABLISHED, SHUTDOWN-PENDING, Data transmission MUST only happen in the ESTABLISHED,
and SHUTDOWN-RECEIVED states. The only exception to this is that DATA SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED states. The only
chunks are allowed to be bundled with an outbound COOKIE ECHO chunk exception to this is that DATA chunks are allowed to be
when in COOKIE-WAIT state. bundled with an outbound COOKIE ECHO chunk when in COOKIE-WAIT
state.
DATA chunks MUST only be received according to the rules below
in ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk
received in CLOSED is out of the blue and SHOULD be handled
per 8.4. A DATA chunk received in any other state SHOULD be
discarded.
A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and
SHUTDOWN-RECEIVED. An incoming SACK MAY be processed in
COOKIE-ECHOED. A SACK in the CLOSED state is out of the blue
and SHOULD be processed according to the rules in 8.4. A SACK
chunk received in any other state SHOULD be discarded.
A SCTP receiver MUST be able to receive a minimum of 1500 bytes A SCTP receiver MUST be able to receive a minimum of 1500 bytes
in one SCTP packet. This means that a SCTP endpoint MUST NOT in one SCTP packet. This means that a SCTP endpoint MUST NOT
indicate less than 1500 bytes in its Initial a_rwnd sent in the indicate less than 1500 bytes in its Initial a_rwnd sent in the
INIT or INIT ACK. INIT or INIT ACK.
For transmission efficiency, SCTP defines mechanisms for bundling of For transmission efficiency, SCTP defines mechanisms for bundling of
small user messages and fragmentation of large user messages. small user messages and fragmentation of large user messages.
The following diagram depicts the flow of user messages through SCTP. The following diagram depicts the flow of user messages through SCTP.
skipping to change at page 81, line 18 skipping to change at page 80, line 54
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet
must fill in the Verification Tag field of the outbound packet with must fill in the Verification Tag field of the outbound packet with
the Verification Tag received in the SHUTDOWN ACK and set the the Verification Tag received in the SHUTDOWN ACK and set the
T-bit in the Chunk Flags to indicate that no TCB was found. T-bit in the Chunk Flags to indicate that no TCB was found.
Otherwise, 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) The receiver should respond to the sender of the OOTB packet with 7) If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the procedures
in section 5 SHOULD be followed. Otherwise,
8) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK
the SCTP Packet should be silently discarded. Otherwise,
9) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the Verification Tag field of the outbound packet MUST fill in the Verification Tag field of the outbound packet
with the value found in the Verification Tag field of the OOTB with the value found in the Verification Tag field of the OOTB
packet and set the T-bit in the Chunk Flags to indicate that no packet and set the T-bit in the Chunk Flags to indicate that no
TCB was found. After sending this ABORT, the receiver of the TCB was found. After sending this ABORT, the receiver of the
OOTB packet shall discard the OOTB packet and take no further OOTB packet shall discard the OOTB packet and take no further
action. action.
8.5 Verification Tag 8.5 Verification Tag
skipping to change at page 82, line 42 skipping to change at page 82, line 26
- When sending a COOKIE ECHO, the endpoint MUST use the value of the - When sending a COOKIE ECHO, the endpoint MUST use the value of the
Initial Tag received in the INIT ACK. Initial Tag received in the INIT ACK.
- The receiver of a COOKIE ECHO follows the procedures in Section 5. - The receiver of a COOKIE ECHO follows the procedures in Section 5.
9. Termination of Association 9. Termination of Association
An endpoint should terminate its association when it exits from An endpoint should terminate its association when it exits from
service. An association can be terminated by either abort or service. An association can be terminated by either abort or
shutdown. A abort of an association is abortive by definition in that shutdown. An abort of an association is abortive by definition in that
any data pending on either end of the association is discarded and NOT any data pending on either end of the association is discarded and NOT
delivered to the peer. A shutdown of an association is considered a delivered to the peer. A shutdown of an association is considered a
graceful close where all data in queue by either endpoint is delivered graceful close where all data in queue by either endpoint is delivered
to the respective peers. However, in the case of a shutdown, SCTP does to the respective peers. However, in the case of a shutdown, SCTP does
not support a half-open state (like TCP) wherein one side may continue not support a half-open state (like TCP) wherein one side may continue
sending data while the other end is closed. When either endpoint sending data while the other end is closed. When either endpoint
performs a shutdown, the association on each peer will stop accepting performs a shutdown, the association on each peer will stop accepting
new data from its user and only deliver data in queue at the time of new data from its user and only deliver data in queue at the time of
sending or receiving the SHUTDOWN chunk. sending or receiving the SHUTDOWN chunk.
9.1 Abort of an Association 9.1 Abort of an Association
When an endpoint decides to abort down an existing association, it When an endpoint decides to abort an existing association, it
shall send an ABORT chunk to its peer endpoint. The sender MUST fill shall send an ABORT chunk to its peer endpoint. The sender MUST fill
in the peer's Verification Tag in the outbound packet and MUST NOT in the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. bundle any DATA chunk with the ABORT.
An endpoint MUST NOT respond to any received packet that contains an An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4). ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification Tag An endpoint receiving an ABORT shall apply the special Verification Tag
check rules described in Section 8.5.1. check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall After checking the Verification Tag, the receiving endpoint shall
remove the association from its record, and shall report the remove the association from its record, and shall report the
skipping to change at page 83, line 27 skipping to change at page 83, line 15
9.2 Shutdown of an Association 9.2 Shutdown of an Association
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an
endpoint in an association can gracefully close the association. endpoint in an association can gracefully close the association.
This will allow all outstanding DATA chunks from the peer of This will allow all outstanding DATA chunks from the peer of
the shutdown initiator to be delivered before the association the shutdown initiator to be delivered before the association
terminates. terminates.
Upon receipt of the SHUTDOWN primitive from its upper layer, the Upon receipt of the SHUTDOWN primitive from its upper layer, the
endpoint enters SHUTDOWN-PENDING state and remains there until all endpoint enters SHUTDOWN-PENDING state and remains there until all
outstanding TSNs have been acknowledged by its peer. The endpoint outstanding data has been acknowledged by its peer. The endpoint
accepts no new data from its upper layer, but retransmits data to the accepts no new data from its upper layer, but retransmits data to the
far end if necessary to fill gaps. far end if necessary to fill gaps.
Once all its outstanding TSNs have been acknowledged, the endpoint Once all its outstanding data has been acknowledged, the endpoint
shall send a SHUTDOWN chunk to its peer including in the Cumulative shall send a SHUTDOWN chunk to its peer including in the Cumulative
TSN Ack field the last sequential TSN it has received from the peer. TSN Ack field the last sequential TSN it has received from the peer.
It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT
state. If the timer expires, the endpoint must re-send the SHUTDOWN state. If the timer expires, the endpoint must re-send the SHUTDOWN
with the updated last sequential TSN received from its peer. with the updated last sequential TSN received from its peer.
The rules in Section 6.3 MUST be followed to determine the proper timer The rules in Section 6.3 MUST be followed to determine the proper timer
value for T2-shutdown. To indicate any gaps in TSN, the endpoint may value for T2-shutdown. To indicate any gaps in TSN, the endpoint may
also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet. also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet.
skipping to change at page 84, line 7 skipping to change at page 83, line 49
Upon the reception of the SHUTDOWN, the peer endpoint shall Upon the reception of the SHUTDOWN, the peer endpoint shall
- enter the SHUTDOWN-RECEIVED state, - enter the SHUTDOWN-RECEIVED state,
- stop accepting new data from its SCTP user - stop accepting new data from its SCTP user
- verify, by checking the Cumulative TSN Ack field of the chunk, that - verify, by checking the Cumulative TSN Ack field of the chunk, that
all its outstanding DATA chunks have been received by the SHUTDOWN all its outstanding DATA chunks have been received by the SHUTDOWN
sender. sender.
Once a endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT
send a SHUTDOWN in response to a ULP request. send a SHUTDOWN in response to a ULP request. And should discard
subsequent SHUTDOWN chunks.
If there are still outstanding DATA chunks left, the SHUTDOWN receiver If there are still outstanding DATA chunks left, the SHUTDOWN receiver
shall continue to follow normal data transmission procedures defined in shall continue to follow normal data transmission procedures defined in
Section 6 until all outstanding DATA chunks are acknowledged; however, Section 6 until all outstanding DATA chunks are acknowledged; however,
the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender shall immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received DATA chunk with a SACK and restart the respond to each received packet containing one or more DATA chunk(s)
T2-shutdown timer. with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer.
If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering
the SHUTDOWN-ACK-SENT state. the SHUTDOWN-ACK-SENT state.
The sender of the SHUTDOWN ACK should limit the number of The sender of the SHUTDOWN ACK should limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
'Association.Max.Retrans'. If this threshold is exceeded the endpoint 'Association.Max.Retrans'. If this threshold is exceeded the endpoint
should destroy the TCB and may report the peer endpoint unreachable to should destroy the TCB and may report the peer endpoint unreachable to
the upper layer (and thus the association enters the CLOSED state). the upper layer (and thus the association enters the CLOSED state).
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its
peer, and remove all record of the association. peer, and remove all record of the association.
Upon reception of the SHUTDOWN COMPLETE chunk the endpoint will verify
that it is in SHUTDOWN-ACK-SENT state, if it is not the chunk should be
discarded. If the endpoint is in the SHUTDOWN-ACK-SENT state the endpoint
should stop the T2-shutdown timer and remove all knowledge of the
association (and thus the association enters the CLOSED state).
An endpoint SHOULD assure that all its outstanding DATA chunks have An endpoint SHOULD assure that all its outstanding DATA chunks have
been acknowledged before initiating the shutdown procedure. been acknowledged before initiating the shutdown procedure.
An endpoint should reject any new data request from its upper An endpoint should reject any new data request from its upper
layer if it is in SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or layer if it is in SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
SHUTDOWN-ACK-SENT state. or SHUTDOWN-ACK-SENT state.
If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT chunk If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT chunk
(e.g., if the SHUTDOWN COMPLETE was lost) with source and destination (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination
transport addresses (either in the IP addresses or in the INIT chunk) transport addresses (either in the IP addresses or in the INIT chunk)
that belong to this association, it should discard the INIT chunk and that belong to this association, it should discard the INIT chunk and
retransmit the SHUTDOWN ACK chunk. retransmit the SHUTDOWN ACK chunk.
Note: Receipt of an INIT with the same source and destination IP Note: Receipt of an INIT with the same source and destination IP
addresses as used in transport addresses assigned to an endpoint but addresses as used in transport addresses assigned to an endpoint but
with a different port number indicates the initialization of a with a different port number indicates the initialization of a
separate association. separate association.
The sender of the INIT should respond to the receipt of a SHUTDOWN-ACK The sender of the INIT or COOKIE should respond to the receipt of a
with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the SHUTDOWN-ACK with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the
Verification Tag field of its common header set to the same tag that Verification Tag field of its common header set to the same tag that
was received in the SHUTDOWN ACK packet. This is considered an Out of was received in the SHUTDOWN ACK packet. This is considered an Out of
the Blue packet as defined in Section 8.4. The sender of the INIT lets the Blue packet as defined in Section 8.4. The sender of the INIT lets
T1-init continue running and remains in the COOKIE-WAIT state. Normal T1-init continue running and remains in the COOKIE-WAIT or COOKIE-ECHOED state.
T1-init timer expiration will cause the INIT chunk to be retransmitted Normal T1-init timer expiration will cause the INIT or COOKIE chunk to be
and thus start a new association. retransmitted and thus start a new association.
If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the
SHUTDOWN chunk SHOULD be silently discarded.
If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN chunk If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN chunk
from its peer, the endpoint shall respond immediately with a SHUTDOWN from its peer, the endpoint shall respond immediately with a SHUTDOWN
ACK to its peer, and move into a SHUTDOWN-ACK-SENT state restarting its ACK to its peer, and move into a SHUTDOWN-ACK-SENT state restarting its
T2-shutdown timer. T2-shutdown timer.
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a
SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a
SHUTDOWN COMPLETE chunk to its peer, and remove all record of the SHUTDOWN COMPLETE chunk to its peer, and remove all record of the
association. association.
skipping to change at page 89, line 53 skipping to change at page 89, line 45
Format: RECEIVE(association id, buffer address, buffer size Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence -> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id] number] [,partial flag] [,delivery number] [,payload protocol-id]
This primitive shall read the first user message in the SCTP in-queue This primitive shall read the first user message in the SCTP in-queue
into the buffer specified by ULP, if there is one available. The size into the buffer specified by ULP, if there is one available. The size
of the message read, in bytes, will be returned. It may, depending on of the message read, in bytes, will be returned. It may, depending on
the specific implementation, also return other information such as the the specific implementation, also return other information such as the
senders address, the stream id on which it is received, whether there sender's address, the stream id on which it is received, whether there
are more messages available for retrieval, etc. For ordered messages, are more messages available for retrieval, etc. For ordered messages,
their stream sequence number may also be returned. their stream sequence number may also be returned.
Depending upon the implementation, if this primitive is invoked when Depending upon the implementation, if this primitive is invoked when
no message is available the implementation should return an indication no message is available the implementation should return an indication
of this condition or should block the invoking process until data does of this condition or should block the invoking process until data does
become available. become available.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o buffer address - the memory location indicated by the ULP to store o buffer address - the memory location indicated by the ULP to store
the received message. the received message.
skipping to change at page 95, line 57 skipping to change at page 95, line 48
o outbound stream count - the maximum number of streams allowed to be o outbound stream count - the maximum number of streams allowed to be
used in this association by the ULP used in this association by the ULP
o inbound stream count - the number of streams the peer endpoint o inbound stream count - the number of streams the peer endpoint
has requested with this association (this may not be the same has requested with this association (this may not be the same
number as 'outbound stream count'). number as 'outbound stream count').
E) COMMUNICATION LOST notification E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (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; o status - This indicates what type of event has occurred;
The status may indicate a failure OR a normal The status may indicate a failure OR a normal
termination event occurred in response to a termination event occurred in response to a
skipping to change at page 106, line 29 skipping to change at page 106, line 19
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10). customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above. Note: RTO.Min SHOULD be set as recommended above.
15. Acknowledgements 15. Acknowledgements
The authors wish to thank Mark Allman, R.J.Atkinson, Richard Band, The authors wish to thank Mark Allman, R.J.Atkinson, Richard Band,
Scott Bradner, Steve Bellovin, Ram Dantu, R. Ezhirpavai, Mike Fisk, Scott Bradner, Steve Bellovin, Ram Dantu, R. Ezhirpavai, Mike Fisk,
Sally Floyd, Matt Holdrege, Henry Houh, Christian Huitema, Gary Sally Floyd, Atsushi Fukumoto ,Matt Holdrege, Henry Houh, Christian
Lehecka, John Loughney, Daniel Luan, Thomas Narten, Erik Nordmark, Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Daniel Luan, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad,
Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves,
A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian
invaluable comments. Wyld, La Monte Yarroll, and many others for their invaluable comments.
16. Authors' Addresses 16. Authors' Addresses
Randall R. Stewart Tel: +1-815-479-8536 Randall R. Stewart Tel: +1-815-479-8536
Motorola, Inc. EMail: rstewart@flashcom.net 24 Burning Bush Trail. EMail: rstewart@flashcom.net
1501 W. Shure Drive, #2315 Crystal Lake, IL 60012
Arlington Heights, IL 60004
USA USA
Qiaobing Xie Tel: +1-847-632-3028 Qiaobing Xie Tel: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
 End of changes. 

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