destination addresses of a multi-homed peer endpoint as the primary
path (see Sections 5.1.2 and 10.1 for details).
By default, an endpoint SHOULD always transmit to the primary path,
unless the SCTP user explicitly specifies the destination transport
address (and possibly source transport address) to use.
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the same destination transport address from which it
received the DATA or control chunk to which it is replying. This
rule should also be followed if the endpoint is bundling DATA chunks
together with the reply chunk.
However, when acknowledging multiple DATA chunks received in packets
from different source addresses in a single SACK, the SACK chunk may
be transmitted to one of the destination transport addresses from
which the DATA or control chunks being acknowledged were received.
When a receiver of a duplicate DATA chunk sends a SACK to a multi-
homed endpoint it MAY be beneficial to vary the destination address
and not use the source address of the DATA chunk. The reason being
that receiving a duplicate from a multi-homed endpoint might indicate
that the return path (as specified in the source address of the DATA
chunk) for the SACK is broken.
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk to an active destination transport address that is
different from the last destination address to which the DATA chunk
was sent.
Retransmissions do not affect the total outstanding data count.
However, if the DATA chunk is retransmitted onto a different
destination address, both the outstanding data counts on the new
destination address and the old destination address to which the data
chunk was last sent shall be adjusted accordingly.
6.4.1 Failover from Inactive Destination Address
Some of the transport addresses of a multi-homed SCTP endpoint may
become inactive due to either the occurrence of certain error
conditions (see Section 8.2) or adjustments from SCTP user.
When there is outbound data to send and the primary path becomes
inactive (e.g., due to failures), or where the SCTP user explicitly
requests to send data to an inactive destination transport address,
before reporting an error to its ULP, the SCTP endpoint should try to
send the data to an alternate active destination transport address if
one exists.
When retransmitting data, if the endpoint is multi-homed, it should
consider each source-destination address pair in its retransmission
selection policy. When retransmitting the endpoint should attempt to
pick the most divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination pair
are an implementation decision and is not specified within this
document.
6.5 Stream Identifier and Stream Sequence Number
Every DATA chunk MUST carry a valid stream identifier. If an
endpoint receives a DATA chunk with an invalid stream identifier, it
shall acknowledge the reception of the DATA chunk following the
normal procedure, immediately send an ERROR chunk with cause set to
"Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA
chunk. The endpoint may bundle the ERROR chunk in the same packet as
the SACK as long as the ERROR follows the SACK.
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.
6.6 Ordered and Unordered Delivery
Within a stream, an endpoint MUST deliver DATA chunks received with
the U flag set to 0 to the upper layer according to the order of
their stream sequence number. If DATA chunks arrive out of order of
their stream sequence number, the endpoint MUST hold the received
DATA chunks from delivery to the ULP until they are re-ordered.
However, an SCTP endpoint can indicate that no ordered delivery is
required for a particular DATA chunk transmitted within the stream by
setting the U flag of the DATA chunk to 1.
When an endpoint receives a DATA chunk with the U flag set to 1, it
must bypass the ordering mechanism and immediately deliver the data
to the upper layer (after re-assembly if the user data is fragmented
by the data sender).
This provides an effective way of transmitting "out-of-band" data in
a given stream. Also, a stream can be used as an "unordered" stream
by simply setting the U flag to 1 in all DATA chunks sent through
that stream.
IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an
implementation may choose to place the DATA chunk in an outbound
packet that is at the head of the outbound transmission queue if
possible.
The 'Stream Sequence Number' field in a DATA chunk with U flag set to
1 has no significance. The sender can fill it with arbitrary value,
but the receiver MUST ignore the field.
Note: When transmitting ordered and unordered data, an endpoint does
not increment its Stream Sequence Number when transmitting a DATA
chunk with U flag set to 1.
6.7 Report Gaps in Received DATA TSNs
Upon the reception of a new DATA chunk, an endpoint shall examine the
continuity of the TSNs received. If the endpoint detects a gap in
the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack
Blocks immediately. The data receiver continues sending a SACK after
receipt of each SCTP packet that doesn't fill the gap.
Based on the Gap Ack Block from the received SACK, the endpoint can
calculate the missing DATA chunks and make decisions on whether to
retransmit them (see Section 6.2.1 for details).
Multiple gaps can be reported in one single SACK (see Section 3.3.4).
When its peer is multi-homed, the SCTP endpoint SHOULD always try to
send the SACK to the same destination address from which the last
DATA chunk was received.
Upon the reception of a SACK, the endpoint MUST remove all DATA
chunks which have been acknowledged by the SACK's Cumulative TSN Ack
from its transmit queue. The endpoint MUST also treat all the DATA
chunks with TSNs not included in the Gap Ack Blocks reported by the
SACK as "missing". The number of "missing" reports for each
outstanding DATA chunk MUST be recorded by the data sender in order
to make retransmission decisions. See Section 7.2.4 for details.
The following example shows the use of SACK to report a gap.
Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Strt=2,End=2]
<-----/
(remove 6 from out-queue,
and mark 7 as "1" missing report)
Figure 9 - Reporting a Gap using SACK
The maximum number of Gap Ack Blocks that can be reported within a
single SACK chunk is limited by the current path MTU. When a single
SACK can not cover all the Gap Ack Blocks needed to be reported due
to the MTU limitation, the endpoint MUST send only one SACK,
reporting the Gap Ack Blocks from the lowest to highest TSNs, within
the size limit set by the MTU, and leave the remaining highest TSN
numbers unacknowledged.
6.8 Adler-32 Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall:
1) Fill in the proper Verification Tag in the SCTP common header and
initialize the checksum field to 0's.
2) Calculate the Adler-32 checksum of the whole packet, including the
SCTP common header and all the chunks. Refer to appendix B for
details of the Adler-32 algorithm. And,
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:
1) Store the received Adler-32 checksum value aside,
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value of
the whole received packet. And,
3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat the
packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
6.9 Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint
supports fragmentation, it MUST fragment a user message if the size
of the user message to be sent causes the outbound SCTP packet size
to exceed the current MTU. If an implementation does not support
fragmentation of outbound user messages, the endpoint must return an
error to its upper layer and not attempt to send the user message.
IMPLEMENTATION NOTE: In this error case, the Send primitive
discussed in Section 10.1 would need to return an error to the upper
layer.
If its peer is multi-homed, the endpoint shall choose a size no
larger than the association Path MTU. The association Path MTU is
the smallest Path MTU of all destination addresses.
Note: Once a message is fragmented it cannot be re-fragmented.
Instead if the PMTU has been reduced, then IP fragmentation must be
used. Please see Section 7.3 for details of PMTU discovery.
When determining when to fragment, the SCTP implementation MUST take
into account the SCTP packet header as well as the DATA chunk
header(s). The implementation MUST also take into account the space
required for a SACK chunk if bundling a SACK chunk with the DATA
chunk.
Fragmentation takes the following steps:
1) The data sender MUST break the user message into a series of DATA
chunks such that each chunk plus SCTP overhead fits into an IP
datagram smaller than or equal to the association Path MTU.
2) The transmitter MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series. The transmitter assigns
the same SSN to each of the DATA chunks. If the user indicates
that the user message is to be delivered using unordered delivery,
then the U flag of each DATA chunk of the user message MUST be set
to 1.
3) The transmitter MUST also set the B/E bits of the first DATA chunk
in the series to '10', the B/E bits of the last DATA chunk in the
series to '01', and the B/E bits of all other DATA chunks in the
series to '00'.
An endpoint MUST recognize fragmented DATA chunks by examining the
B/E bits in each of the received DATA chunks, and queue the
fragmented DATA chunks for re-assembly. Once the user message is
reassembled, SCTP shall pass the re-assembled user message to the
specific stream for possible re-ordering and final dispatching.
Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the re-assembly of the
message, it should dispatch part of its inbound message through a
partial delivery API (see Section 10), freeing some of its receive
buffer space so that the rest of the message may be received.
6.10 Bundling
An endpoint bundles chunks by simply including multiple chunks in one
outbound SCTP packet. The total size of the resultant IP datagram,
including the SCTP packet and IP headers, MUST be less or equal to
the current Path MTU.
If its peer endpoint is multi-homed, the sending endpoint shall
choose a size no larger than the latest MTU of the current primary
path.
When bundling control chunks with DATA chunks, an endpoint MUST place
control chunks first in the outbound SCTP packet. The transmitter
MUST transmit DATA chunks within a SCTP packet in increasing order of
TSN.
Note: Since control chunks must be placed first in a packet and
since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK
chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK
chunks.
Partial chunks MUST NOT be placed in an SCTP packet.
An endpoint MUST process received chunks in their order in the
packet. The receiver uses the chunk length field to determine the end
of a chunk and beginning of the next chunk taking account of the fact
that all chunks end on a 4 byte boundary. If the receiver detects a
partial chunk, it MUST drop the chunk.
An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with
any other chunks.
7. Congestion control
Congestion control is one of the basic functions in SCTP. For some
applications, it may be likely that adequate resources will be
allocated to SCTP traffic to assure prompt delivery of time-critical
data - thus it would appear to be unlikely, during normal operations,
that transmissions encounter severe congestion conditions. However
SCTP must operate under adverse operational conditions, which can
develop upon partial network failures or unexpected traffic surges.
In such situations SCTP must follow correct congestion control steps
to recover from congestion quickly in order to get data delivered as
soon as possible. In the absence of network congestion, these
preventive congestion control algorithms should show no impact on the
protocol performance.
IMPLEMENTATION NOTE: As far as its specific performance requirements
are met, an implementation is always allowed to adopt a more
conservative congestion control algorithm than the one defined below.
The congestion control algorithms used by SCTP are based on
[RFC2581]. This section describes how the algorithms defined in
RFC2581 are adapted for use in SCTP. We first list differences in
protocol designs between TCP and SCTP, and then describe SCTP's
congestion control scheme. The description will use the same
terminology as in TCP congestion control whenever appropriate.
SCTP congestion control is always applied to the entire association,
and not to individual streams.
7.1 SCTP Differences from TCP Congestion control
Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as
the TCP SACK. TCP considers the information carried in the SACK as
advisory information only. SCTP considers the information carried in
the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any DATA
chunk that has been acknowledged by SACK, including DATA that arrived
at the receiving end out of order, are not considered fully delivered
until the Cumulative TSN Ack Point passes the TSN of the DATA chunk
(i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack
field in the SACK). Consequently, the value of cwnd controls the
amount of outstanding data, rather than (as in the case of non-SACK
TCP) the upper bound between the highest acknowledged sequence number
and the latest DATA chunk that can be sent within the congestion
window. SCTP SACK leads to different implementations of fast-
retransmit and fast-recovery than non-SACK TCP. As an example see
[FALL96].
The biggest difference between SCTP and TCP, however, is multi-
homing. SCTP is designed to establish robust communication
associations between two endpoints each of which may be reachable by
more than one transport address. Potentially different addresses may
lead to different data paths between the two endpoints, thus ideally
one may need a separate set of congestion control parameters for each
of the paths. The treatment here of congestion control for multi-
homed receivers is new with SCTP and may require refinement in the
future. The current algorithms make the following assumptions:
o The sender usually uses the same destination address until being
instructed by the upper layer otherwise; however, SCTP may change
to an alternate destination in the event an address is marked
inactive (see Section 8.2). Also, SCTP may retransmit to a
different transport address than the original transmission.
o The sender keeps a separate congestion control parameter set for
each of the destination addresses it can send to (not each
source-destination pair but for each destination). The parameters
should decay if the address is not used for a long enough time
period.
o For each of the destination addresses, an endpoint does slow-start
upon the first transmission to that address.
Note: TCP guarantees in-sequence delivery of data to its upper-layer
protocol within a single TCP session. This means that when TCP
notices a gap in the received sequence number, it waits until the gap
is filled before delivering the data that was received with sequence
numbers higher than that of the missing data. On the other hand,
SCTP can deliver data to its upper-layer protocol even if there is a
gap in TSN if the Stream Sequence Numbers are in sequence for a
particular stream (i.e., the missing DATA chunks are for a different
stream) or if unordered delivery is indicated. Although this does
not affect cwnd, it might affect rwnd calculation.
7.2 SCTP Slow-Start and Congestion Avoidance
The slow start and congestion avoidance algorithms MUST be used by an
endpoint to control the amount of data being injected into the
network. The congestion control in SCTP is employed in regard to the
association, not to an individual stream. In some situations it may
be beneficial for an SCTP sender to be more conservative than the
algorithms allow; however, an SCTP sender MUST NOT be more aggressive
than the following algorithms allow.
Like TCP, an SCTP endpoint uses the following three control variables
to regulate its transmission rate.
o Receiver advertised window size (rwnd, in bytes), which is set by
the receiver based on its available buffer space for incoming
packets.
Note: This variable is kept on the entire association.
o Congestion control window (cwnd, in bytes), which is adjusted by
the sender based on observed network conditions.
Note: This variable is maintained on a per-destination address
basis.
o Slow-start threshold (ssthresh, in bytes), which is used by the
sender to distinguish slow start and congestion avoidance phases.
Note: This variable is maintained on a per-destination address
basis.
SCTP also requires one additional control variable,
partial_bytes_acked, which is used during congestion avoidance phase
to facilitate cwnd adjustment.
Unlike TCP, an SCTP sender MUST keep a set of these control variables
cwnd, ssthresh and partial_bytes_acked for EACH destination address
of its peer (when its peer is multi-homed). Only one rwnd is kept
for the whole association (no matter if the peer is multi-homed or
has a single address).
7.2.1 Slow-Start
Beginning data transmission into a network with unknown conditions or
after a sufficiently long idle period requires SCTP to probe the
network to determine the available capacity. The slow start
algorithm is used for this purpose at the beginning of a transfer, or
after repairing loss detected by the retransmission timer.
o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be <= 2*MTU.
o The initial cwnd after a retransmission timeout MUST be no more
than 1*MTU.
o The initial value of ssthresh MAY be arbitrarily high (for
example, implementations MAY use the size of the receiver
advertised window).
o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address.
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the
destination's path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99].
In instances where its peer endpoint is multi-homed, if an endpoint
receives a SACK that advances its Cumulative TSN Ack Point, then it
should update its cwnd (or cwnds) apportioned to the destination
addresses to which it transmitted the acknowledged data. However if
the received SACK does not advance the Cumulative TSN Ack Point, the
endpoint MUST NOT adjust the cwnd of any of the destination
addresses.
Because an endpoint's cwnd is not tied to its Cumulative TSN Ack
Point, as duplicate SACKs come in, even though they may not advance
the Cumulative TSN Ack Point an endpoint can still use them to clock
out new data. That is, the data newly acknowledged by the SACK
diminishes the amount of data now in flight to less than cwnd; and so
the current, unchanged value of cwnd now allows new data to be sent.
On the other hand, the increase of cwnd must be tied to the
Cumulative TSN Ack Point advancement as specified above. Otherwise
the duplicate SACKs will not only clock out new data, but also will
adversely clock out more new data than what has just left the
network, during a time of possible congestion.
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.
7.2.2 Congestion Avoidance
When cwnd is greater than ssthresh, cwnd should be incremented by
1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding transport address.
In practice an implementation can achieve this goal in the following
way:
o partial_bytes_acked is initialized to 0.
o Whenever cwnd is greater than ssthresh, upon each SACK arrival
that advances the Cumulative TSN Ack Point, increase
partial_bytes_acked by the total number of bytes of all new chunks
acknowledged in that SACK including chunks acknowledged by the new
Cumulative TSN Ack and by Gap Ack Blocks.
o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), increase cwnd by MTU, and
reset partial_bytes_acked to (partial_bytes_acked - cwnd).
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.
o When all of the data transmitted by the sender has been
acknowledged by the receiver, partial_bytes_acked is initialized
to 0.
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
and assure that no more than one SCTP packet will be in flight for
that address until the endpoint receives acknowledgement for
successful delivery of data to that address.
7.2.4 Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the hole is filled.
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall:
1) Mark the missing DATA chunk(s) for retransmission,
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
7.3 Path MTU Discovery
[RFC1191] specifies "Path MTU Discovery", whereby an endpoint
maintains an estimate of the maximum transmission unit (MTU) along a
given Internet path and refrains from sending packets along that path
which exceed the MTU, other than occasional attempts to probe for a
change in the Path MTU (PMTU). RFC1191 is thorough in its
discussion of the MTU discovery mechanism and strategies for
determining the current end-to-end MTU setting as well as detecting
changes in this value. [RFC1981] specifies the same mechanisms for
IPv6. An SCTP sender using IPv6 MUST use Path MTU Discovery unless
all packets are less than the minimum IPv6 MTU [RFC2460].
An endpoint SHOULD apply these techniques, and SHOULD do so on a
per-destination-address basis.
There are 4 ways in which SCTP differs from the description in RFC
1191 of applying MTU discovery to TCP:
1) SCTP associations can span multiple addresses. An endpoint MUST
maintain separate MTU estimates for each destination address of
its peer.
2) Elsewhere in this document, when the term "MTU" is discussed, it
refers to the MTU associated with the destination address
corresponding to the context of the discussion.
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment Size".
Accordingly, the MTU for each destination address SHOULD be
initialized to a value no larger than the link MTU for the local
interface to which packets for that remote destination address
will be routed.
4) Since data transmission in SCTP is naturally structured in terms
of TSNs rather than bytes (as is the case for TCP), the discussion
in Section 6.5 of RFC1191 applies: When retransmitting an IP
datagram to a remote address for which the IP datagram appears too
large for the path MTU to that address, the IP datagram SHOULD be
retransmitted without the DF bit set, allowing it to possibly be
fragmented. Transmissions of new IP datagrams MUST have DF set.
5) The sender should track an association PMTU which will be the
smallest PMTU discovered for all of the peer's destination
addresses. When fragmenting messages into multiple parts this
association PMTU should be used to calculate the size of each
fragment. This will allow retransmissions to be seamlessly sent
to an alternate address without encountering IP fragmentation.
Other than these differences, the discussion of TCP's use of MTU
discovery in RFCs 1191 and 1981 applies to SCTP on a per-
destination-address basis.
Note: For IPv6 destination addresses the DF bit does not exist,
instead the IP datagram must be fragmented as described in [RFC2460].
8. Fault Management
8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
8.2 Path Failure Detection
When its peer endpoint is multi-homed, an endpoint should keep a
error counter for each of the destination transport addresses of the
peer endpoint.
Each time the T3-rtx timer expires on any address, or when a
HEARTBEAT sent to an idle address is not acknowledged within a RTO,
the error counter of that destination address will be incremented.
When the value in the error counter exceeds the protocol parameter
'Path.Max.Retrans' of that destination address, the endpoint should
mark the destination transport address as inactive, and a
notification SHOULD be sent to the upper layer.
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
address is acknowledged with a HEARTBEAT ACK, the endpoint shall
clear the error counter of the destination transport address to which
the DATA chunk was last sent (or HEARTBEAT was sent). When the peer
endpoint is multi-homed and the last chunk sent to it was a
retransmission to an alternate address, there exists an ambiguity as
to whether or not the acknowledgement should be credited to the
address of the last chunk sent. However, this ambiguity does not
seem to bear any significant consequence to SCTP behavior. If this
ambiguity is undesirable, the transmitter may choose not to clear the
error counter if the last chunk sent was a retransmission.
Note: When configuring the SCTP endpoint, the user should avoid
having the value of 'Association.Max.Retrans' larger than the
summation of the 'Path.Max.Retrans' of all the destination addresses
for the remote endpoint. Otherwise, all the destination addresses
may become inactive while the endpoint still considers the peer
endpoint reachable. When this condition occurs, how the SCTP chooses
to function is implementation specific.
When the primary path is marked inactive (due to excessive
retransmissions, for instance), the sender MAY automatically transmit
new packets to an alternate destination address if one exists and is
active. If more than one alternate address is active when the
primary path is marked inactive only ONE transport address SHOULD be
chosen and used as the new destination transport address.
8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es).
A destination transport address is considered "idle" if no new chunk
which can be used for updating path RTT (usually including first
transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no
HEARTBEAT has been sent to it within the current heartbeat period of
that address. This applies to both active and inactive destination
addresses.
The upper layer can optionally initiate the following functions:
A) Disable heartbeat on a specific destination transport address of a
given association,
B) Change the HB.interval,
C) Re-enable heartbeat on a specific destination transport address of
a given association, and,
D) Request an on-demand HEARTBEAT on a specific destination transport
address of a given association.
The endpoint should increment the respective error counter of the
destination transport address each time a HEARTBEAT is sent to that
address and not acknowledged within one RTO.
When the value of this counter reaches the protocol parameter '
Path.Max.Retrans', the endpoint should mark the corresponding
destination address as inactive if it is not so marked, and may also
optionally report to the upper layer the change of reachability of
this destination address. After this, the endpoint should continue
HEARTBEAT on this destination address but should stop increasing the
counter.
The sender of the HEARTBEAT chunk should include in the Heartbeat
Information field of the chunk the current time when the packet is
sent out and the destination address to which the packet is sent.
IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
mechanism that can be used is to increment the error counter variable
every time a HEARTBEAT is sent to a destination. Whenever a
HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of
the destination that the HEARTBEAT was sent to. This in effect would
clear the previously stroked error (and any other error counts as
well).
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk.
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
should clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint may
optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the
association overall error count as well (as defined in section 8.1).
The receiver of the HEARTBEAT ACK should also perform an RTT
measurement for that destination transport address using the time
value carried in the HEARTBEAT ACK chunk.
On an idle destination address that is allowed to heartbeat, a
HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
destination address plus the protocol parameter 'HB.interval' , with
jittering of +/- 50%, and exponential back-off of the RTO if the
previous HEARTBEAT is unanswered.
A primitive is provided for the SCTP user to change the HB.interval
and turn on or off the heartbeat on a given destination address. The
heartbeat interval set by the SCTP user is added to the RTO of that
destination (including any exponential backoff). Only one heartbeat
should be sent each time the heartbeat timer expires (if multiple
destinations are idle). It is a implementation decision on how to
choose which of the candidate idle destinations to heartbeat to (if
more than one destination is idle).
Note: When tuning the heartbeat interval, there is a side effect that
SHOULD be taken into account. When this value is increased, i.e.
the HEARTBEAT takes longer, the detection of lost ABORT messages
takes longer as well. If a peer endpoint ABORTs the association for
any reason and the ABORT chunk is lost, the local endpoint will only
discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk
(thus causing the peer to send another ABORT). This must be
considered when tuning the HEARTBEAT timer. If the HEARTBEAT is
disabled only sending DATA to the association will discover a lost
ABORT from the peer.
8.4 Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is
correctly formed, i.e., passed the receiver's Adler-32 check (see
Section 6.8), but the receiver is not able to identify the
association to which this packet belongs.
The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, silently
discard the packet. Otherwise,
2) If the OOTB packet contains an ABORT chunk, the receiver MUST
silently discard the OOTB packet and take no further action.
Otherwise,
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. Otherwise,
4) If the packet contains a COOKIE ECHO in the first chunk, process
it as described in Section 5.1. Otherwise,
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
packet must fill in the Verification Tag field of the outbound
packet with the Verification Tag received in the SHUTDOWN ACK and
set the T-bit in the Chunk Flags to indicate that no TCB was
found. Otherwise,
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
should silently discard the packet and take no further action.
Otherwise,
7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the
SCTP Packet should be silently discarded. Otherwise,
8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB packet
MUST fill in the Verification Tag field of the outbound packet
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
TCB was found. After sending this ABORT, the receiver of the OOTB
packet shall discard the OOTB packet and take no further action.
8.5 Verification Tag
The Verification Tag rules defined in this section apply when sending
or receiving SCTP packets which do not contain an INIT, SHUTDOWN
COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk.
The rules for sending and receiving SCTP packets containing one of
these chunk types are discussed separately in Section 8.5.1.
When sending an SCTP packet, the endpoint MUST fill in the
Verification Tag field of the outbound packet with the tag value in
the Initiate Tag parameter of the INIT or INIT ACK received from its
peer.
When receiving an SCTP packet, the endpoint MUST ensure that the
value in the Verification Tag field of the received SCTP packet
matches its own Tag. If the received Verification Tag value does not
match the receiver's own tag value, the receiver shall silently
discard the packet and shall not process it any further except for
those cases listed in Section 8.5.1 below.
8.5.1 Exceptions in Verification Tag Rules
A) Rules for packet carrying INIT:
- The sender MUST set the Verification Tag of the packet to 0.
- When an endpoint receives an SCTP packet with the Verification
Tag set to 0, it should verify that the packet contains only an
INIT chunk. Otherwise, the receiver MUST silently discard the
packet.
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no
further action.
C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
be used. Only where no TCB exists should the sender use the
Verification Tag from the SHUTDOWN ACK.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if
the Verification Tag field of the packet matches its own tag OR
it is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
D) Rules for packet carrying a COOKIE ECHO
- When sending a COOKIE ECHO, the endpoint MUST use the value of
the Initial Tag received in the INIT ACK.
- The receiver of a COOKIE ECHO follows the procedures in Section
5.
E) Rules for packet carrying a SHUTDOWN ACK
- If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the
procedures in section 8.4 SHOULD be followed, in other words it
should be treated as an Out Of The Blue packet.
9. Termination of Association
An endpoint should terminate its association when it exits from
service. An association can be terminated by either abort or
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 delivered to the peer. A shutdown of an association is
considered a 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 not support a half-open state (like TCP)
wherein one side may continue sending data while the other end is
closed. When either endpoint 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 sending or receiving the SHUTDOWN chunk.
9.1 Abort of an Association
When an endpoint decides to abort an existing association, it 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
bundle any DATA chunk with the ABORT.
An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall
remove the association from its record, and shall report the
termination to its upper layer.
9.2 Shutdown of an Association
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of
an endpoint in an association can gracefully close the association.
This will allow all outstanding DATA chunks from the peer of the
shutdown initiator to be delivered before the association terminates.
Upon receipt of the SHUTDOWN primitive from its upper layer, the
endpoint enters SHUTDOWN-PENDING state and remains there until all
outstanding data has been acknowledged by its peer. The endpoint
accepts no new data from its upper layer, but retransmits data to the
far end if necessary to fill gaps.
Once all its outstanding data has been acknowledged, the endpoint
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.
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
with the updated last sequential TSN received from its peer.
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 also bundle a SACK with the SHUTDOWN chunk in the same
SCTP packet.
An endpoint should limit the number of retransmissions of the
SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
If this threshold is exceeded the endpoint should destroy the TCB and
MUST report the peer endpoint unreachable to the upper layer (and
thus the association enters the CLOSED state). The reception of any
packet from its peer (i.e. as the peer sends all of its queued DATA
chunks) should clear the endpoint's retransmission count and restart
the T2-Shutdown timer, giving its peer ample opportunity to transmit
all of its queued DATA chunks that have not yet been sent.
Upon the reception of the SHUTDOWN, the peer endpoint shall
- enter the SHUTDOWN-RECEIVED state,
- stop accepting new data from its SCTP user
- verify, by checking the Cumulative TSN Ack field of the chunk,
that all its outstanding DATA chunks have been received by the
SHUTDOWN sender.
Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT
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 shall continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s)
with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. 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 the SHUTDOWN-ACK-SENT state. If the timer expires, the
endpoint must re-send the SHUTDOWN ACK.
The sender of the SHUTDOWN ACK should limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter '
Association.Max.Retrans'. If this threshold is exceeded the endpoint
should destroy the TCB and may report the peer endpoint unreachable
to the upper layer (and thus the association enters the CLOSED
state).
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its 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
been acknowledged before initiating the shutdown procedure.
An endpoint should reject any new data request from its upper layer
if it is in SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or
SHUTDOWN-ACK-SENT state.
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 transport addresses (either in the IP addresses or in the
INIT chunk) that belong to this association, it should discard the
INIT chunk and retransmit the SHUTDOWN ACK chunk.
Note: Receipt of an INIT with the same source and destination IP
addresses as used in transport addresses assigned to an endpoint but
with a different port number indicates the initialization of a
separate association.
The sender of the INIT or COOKIE ECHO should respond to the receipt
of a 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 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 T1-init continue running and remains in the
COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration
will cause the INIT or COOKIE chunk to be retransmitted and thus
start a new association.
If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the