Mandatory attributes:
o association id - Local handle to the SCTP association.
Optional attributes:
o Upper Layer Abort Reason - Reason of the abort to be passed
to the peer.
None.
---------
Old text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The
status may indicate a failure OR a normal termination
event occurred in response to a shutdown or abort
request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve
unsent and unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
---------
New text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - Local handle to the SCTP association.
o status - This indicates what type of event has occurred; The
status may indicate that a failure OR a normal
termination event occurred in response to a shutdown
or abort request.
The following may be passed with the notification:
o data retrieval id - An identification used to retrieve unsent
and unacknowledged data.
o last-acked - The TSN last acked by that peer endpoint.
o last-sent - The TSN last sent to that peer endpoint.
o Upper Layer Abort Reason - The abort reason specified in
case of a user-initiated abort.
2.21.3. Solution Description
The above allows an upper layer to provide its peer with an
indication of why the association was aborted. Therefore, an
addition error cause was introduced.
2.22. Handling of Invalid Initiate Tag of INIT-ACK
2.22.1. Description of the Problem
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
Tag set to zero handles this as an error and sends back an ABORT.
But the sender of the INIT-ACK normally has no TCB, and thus the
ABORT is useless.
2.22.2. Text Changes to the Document
---------
Old text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the
Initiate Tag parameter. This value MUST be placed into
the Verification Tag field of every SCTP packet that the
INIT ACK receiver transmits within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
for more on the selection of the Initiate Tag value.
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 association by transmitting an ABORT.
---------
New text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the
Initiate Tag parameter. This value MUST be placed into
the Verification Tag field of every SCTP packet that the
INIT ACK receiver transmits within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
for more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK
chunk is found to be 0, the receiver MUST destroy the
association discarding its TCB. The receiver MAY send an
ABORT for debugging purpose.
2.22.3. Solution Description
The new text does not require that the receiver of the invalid INIT-
ACK send the ABORT. This behavior is in tune with the error case of
invalid stream numbers in the INIT-ACK. However, sending an ABORT
for debugging purposes is allowed.
2.23. Sending an ABORT in Response to an INIT
2.23.1. Description of the Problem
Whenever the receiver of an INIT chunk has to send an ABORT chunk in
response, for whatever reason, it is not stated clearly which
Verification Tag and value of the T-bit should be used.
2.23.2. Text Changes to the Document
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to ’0’, process it as described in Section 5.1.
Otherwise,
---------
New text: (Section 8.4)
---------
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 reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag
of the packet containing the ABORT chunk MUST be the
Initiate tag of the received INIT chunk, and the T-Bit of
the ABORT chunk has to be set to 0, indicating that
a TCB was destroyed. Otherwise,
2.23.3. Solution Description
The new text stated clearly which value of the Verification Tag and
T-bit have to be used.
2.24. Stream Sequence Number (SSN) Initialization
2.24.1. Description of the Problem
RFC 2960 does not describe the fact that the SSN has to be
initialized to 0, as required by RFC 2119.
2.24.2. Text Changes to the Document
---------
Old text: (Section 6.5)
---------
The stream sequence number in all the streams shall start from 0
when the association is established. Also, when the stream
sequence number reaches the value 65535 the next stream sequence
number shall be set to 0.
---------
New text: (Section 6.5)
---------
The stream sequence number in all the streams MUST start from 0
when the association is established. Also, when the stream
sequence number reaches the value 65535 the next stream sequence
number MUST be set to 0.
2.24.3. Solution Description
The ’shall’ in the text is replaced by a ’MUST’ to clearly state the
required behavior.
2.25. SACK Packet Format
2.25.1. Description of the Problem
It is not clear in RFC 2960 whether a SACK must contain the fields
Number of Gap Ack Blocks and Number of Duplicate TSNs.
2.25.2. Text Changes to the Document
---------
Old text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack and
Advertised Receiver Window Credit (a_rwnd) parameters.
---------
New text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack,
Advertised Receiver Window Credit (a_rwnd), Number
of Gap Ack Blocks, and Number of Duplicate TSNs fields.
2.25.3. Solution Description
The text has been modified. It is now clear that a SACK always
contains the fields Number of Gap Ack Blocks and Number of Duplicate
TSNs.
2.26. Protocol Violation Error Cause
2.26.1. Description of the Problem
There are many situations where an SCTP endpoint may detect that its
peer violates the protocol. The result of such detection often
results in the association being destroyed by the sending of an
ABORT. Currently, there are only some error causes that could be
used to indicate the reason for the abort, but these do not cover all
cases.
2.26.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.6 and 2.21 of this document.
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note: no old text; new error added in section 3.3.10)
---------
3.3.10.13. Protocol Violation (13)
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent
because an SCTP endpoint detects a protocol violation of the peer
that is not covered by the error causes described in 3.3.10.1 to
3.3.10.12. An implementation MAY provide additional information
specifying what kind of protocol violation has been detected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26.3. Solution Description
An additional error cause has been defined that can be used by an
endpoint to indicate a protocol violation of the peer.
2.27. Reporting of Unrecognized Parameters
2.27.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could
be reported in the INIT-ACK chunk or in a separate ERROR chunk, which
can get lost. Unrecognized parameters in an INIT-ACK chunk have to
be reported in an ERROR-chunk. This can be bundled with the COOKIE-
ERROR chunk or sent separately. If it is sent separately and
received before the COOKIE-ECHO, it will be handled as an OOTB
packet, resulting in sending out an ABORT chunk. Therefore, the
association would not be established.
2.27.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.2 of this document.
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an ’Unrecognized Parameter Type’ (in either an
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an ’Unrecognized Parameter Type’ (in
either an ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it; do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an ’Unrecognized Parameter Type’, as
described in 3.2.2.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an ’Unrecognized Parameter Type’, as
described in 3.2.2.
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it MUST put
the ’Unrecognized Parameter’ parameter(s) in the INIT-ACK chunk
sent in response to the INIT-chunk. Note that if the receiver
of the INIT chunk is NOT going to establish an association (e.g.,
due to lack of resources), then no report would be sent back.
If the receiver of an INIT-ACK chunk detects unrecognized
parameters and has to report them according to Section 3.2.1,
it SHOULD bundle the ERROR chunk containing the
’Unrecognized Parameter’ error cause with the COOKIE-ECHO
chunk sent in response to the INIT-ACK chunk. If the
receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately
but not before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
first chunk.
2.27.3. Solution Description
The procedure of reporting unrecognized parameters has been described
clearly.
2.28. Handling of IP Address Parameters
2.28.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that
supports either IPv4 addresses or IPv6 addresses should respond if
IPv4 and IPv6 addresses are presented by the peer in the INIT or
INIT-ACK chunk.
2.28.2. Text Changes to the Document
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a
re-initiation by using a ’Supported Address Types’ parameter in
the new INIT to indicate what types of address it prefers.
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a re-
initiation by using a ’Supported Address Types’ parameter in the
new INIT to indicate what types of address it prefers.
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
ACK chunk from its peer, it MUST use all the addresses belonging
to the supported address family. The other addresses MAY be
ignored. The endpoint SHOULD NOT respond with any kind of error
indication.
2.28.3. Solution Description
The procedure of handling IP address parameters has been described
clearly.
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
2.29.1. Description of the Problem
The description of the behavior in RFC 2960 [5] when a COOKIE ECHO
chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is
received, a TCB exists and the local tag and peer’s tag match, it is
stated that the endpoint should enter the ESTABLISHED state if it has
not already done so and send a COOKIE ACK. It was not clear that, in
the case the endpoint has already left the ESTABLISHED state again,
then it should not go back to established. In case D, the endpoint
can only enter state ESTABLISHED from COOKIE-ECHOED because in state
CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows
nothing about the peer’s tag, which is requested to match in this
case.
2.29.2. Text Changes to the Document
---------
Old text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should
always enter the ESTABLISHED state, if it has not already
done so. It should stop any init or cookie timers that may
be running and send a COOKIE ACK.
---------
New text: (Section 5.2.4)
---------
D) When both local and remote tags match, the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
state. It should stop any cookie timer that may
be running and send a COOKIE ACK.
2.29.3. Solution Description
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has
been described clearly.
2.30. The Initial Congestion Window Size
2.30.1. Description of the Problem
RFC 2960 was published with the intention of having the same
congestion control properties as TCP. Since the publication of RFC
2960, TCP’s initial congestion window size has been increased via RFC
3390. This same update will be needed for SCTP to keep SCTP’s
congestion control properties equivalent to that of TCP.
2.30.2. Text Changes to the Document
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a
sufficiently long idle period MUST be <= 2*MTU.
---------
New text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a
sufficiently long idle period MUST be set to
min(4*MTU, max (2*MTU, 4380 bytes)).
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted
to max(cwnd/2, 2*MTU) per RTO.
---------
New text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted
to max(cwnd/2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.3)
---------
7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform
slow start by
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform
slow start by:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
2.30.3. Solution Description
The change to SCTP’s initial congestion window will allow it to
continue to maintain the same congestion control properties as TCP.
2.31. Stream Sequence Numbers in Figures
2.31.1. Description of the Problem
In Section 2.24 of this document, it is clarified that the SSN are
initialized with 0. Two figures in RFC 2960 [5] illustrate that they
start with 1.
2.31.2. Text Changes to the Document
---------
Old text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,