Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2960

Stream Control Transmission Protocol

Pages: 134
Obsoleted by:  4960
Updated by:  3309
Part 3 of 5 – Pages 52 to 80
First   Prev   Next

ToP   noToC   RFC2960 - Page 52   prevText

5. Association Initialization

Before the first data transmission can take place from one SCTP endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must complete an initialization process in order to set up an SCTP association between them. The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint. IMPLEMENTATION NOTE: From an SCTP-user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see 10.1 B) being invoked, by the initiating endpoint's sending of the first user data to the destination endpoint. The initiating SCTP will assume default values for all mandatory and optional parameters for the INIT/INIT ACK. Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1).

5.1 Normal Establishment of an Association

The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association): A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state. B) "Z" shall respond immediately with an INIT ACK chunk. The destination IP address of the INIT ACK MUST be set to the source IP address of the INIT to which this INIT ACK is responding. In the response, besides filling in other parameters, "Z" must set the Verification Tag field to Tag_A, and also provide its own Verification Tag (Tag_Z) in the Initiate Tag field. Moreover, "Z" MUST generate and send along with the INIT ACK a State Cookie. See Section 5.1.3 for State Cookie generation. Note: After sending out INIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources, nor keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks.
ToP   noToC   RFC2960 - Page 53
   C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-
      init timer and leave COOKIE-WAIT state.  "A" shall then send the
      State Cookie received in the INIT ACK chunk in a COOKIE ECHO
      chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED
      state.

      Note: The COOKIE ECHO chunk can be bundled with any pending
      outbound DATA chunks, but it MUST be the first chunk in the packet
      and until the COOKIE ACK is returned the sender MUST NOT send any
      other packets to the peer.

   D) Upon reception of the COOKIE ECHO chunk, Endpoint "Z" will reply
      with a COOKIE ACK chunk after building a TCB and moving to the
      ESTABLISHED state.  A COOKIE ACK chunk may be bundled with any
      pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk
      MUST be the first chunk in the packet.

      IMPLEMENTATION NOTE: An implementation may choose to send the
      Communication Up notification to the SCTP user upon reception of a
      valid COOKIE ECHO chunk.

   E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
      COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-
      cookie timer.  It may also notify its ULP about the successful
      establishment of the association with a Communication Up
      notification (see Section 10).

   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
   them.

   An endpoint MUST send the INIT ACK to the IP address from which it
   received the INIT.

   Note: T1-init timer and T1-cookie timer shall follow the same rules
   given in Section 6.3.

   If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
   decides not to establish the new association due to missing mandatory
   parameters in the received INIT or INIT ACK, invalid parameter
   values, or lack of local resources, it MUST respond with an ABORT
   chunk.  It SHOULD also specify the cause of abort, such as the type
   of the missing mandatory parameters, etc., by including the error
   cause parameters with the ABORT chunk.  The Verification Tag field in
   the common header of the outbound SCTP packet containing the ABORT
   chunk MUST be set to the Initiate Tag value of the peer.
ToP   noToC   RFC2960 - Page 54
   After the reception of the first DATA chunk in an association the
   endpoint MUST immediately respond with a SACK to acknowledge the DATA
   chunk.  Subsequent acknowledgements should be done as described in
   Section 6.2.

   When the TCB is created, each endpoint MUST set its internal
   Cumulative TSN Ack Point to the value of its transmitted Initial TSN
   minus one.

   IMPLEMENTATION NOTE:  The IP addresses and SCTP port are generally
   used as the key to find the TCB within an SCTP instance.

5.1.1 Handle Stream Parameters

In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint. After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer. After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1.

5.1.2 Handle Address Parameters

During the association initialization, an endpoint shall use the following rules to discover and collect the destination transport address(es) of its peer. A) If there are no address parameters present in the received INIT or INIT ACK chunk, the endpoint shall take the source IP address from which the chunk arrives and record it, in combination with the SCTP source port number, as the only destination transport address for this peer. B) If there is a Host Name parameter present in the received INIT or INIT ACK chunk, the endpoint shall resolve that host name to a list of IP address(es) and derive the transport address(es) of this peer by combining the resolved IP address(es) with the SCTP source port.
ToP   noToC   RFC2960 - Page 55
      The endpoint MUST ignore any other IP address parameters if they
      are also present in the received INIT or INIT ACK chunk.

      The time at which the receiver of an INIT resolves the host name
      has potential security implications to SCTP.  If the receiver of
      an INIT resolves the host name upon the reception of the chunk,
      and the mechanism the receiver uses to resolve the host name
      involves potential long delay (e.g. DNS query), the receiver may
      open itself up to resource attacks for the period of time while it
      is waiting for the name resolution results before it can build the
      State Cookie and release local resources.

      Therefore, in cases where the name translation involves potential
      long delay, the receiver of the INIT MUST postpone the name
      resolution till the reception of the COOKIE ECHO chunk from the
      peer.  In such a case, the receiver of the INIT SHOULD build the
      State Cookie using the received Host Name (instead of destination
      transport addresses) and send the INIT ACK to the source IP
      address from which the INIT was received.

      The receiver of an INIT ACK shall always immediately attempt to
      resolve the name upon the reception of the chunk.

      The receiver of the INIT or INIT ACK MUST NOT send user data
      (piggy-backed or stand-alone) to its peer until the host name is
      successfully resolved.

      If the name resolution is not successful, the endpoint MUST
      immediately send an ABORT with "Unresolvable Address" error cause
      to its peer.  The ABORT shall be sent to the source IP address
      from which the last peer packet was received.

   C) If there are only IPv4/IPv6 addresses present in the received INIT
      or INIT ACK chunk, the receiver shall derive and record all the
      transport address(es) from the received chunk AND the source IP
      address that sent the INIT or INIT ACK.  The transport address(es)
      are derived by the combination of SCTP source port (from 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.
      The receiver should use only these transport addresses as
      destination transport addresses when sending subsequent packets 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.
ToP   noToC   RFC2960 - Page 56
   After all transport addresses are derived from the INIT or INIT ACK
   chunk using the above rules, the endpoint shall select one of the
   transport addresses as the initial primary path.

   Note: The INIT-ACK MUST be sent to the source address of the INIT.

   The sender of INIT may include a 'Supported Address Types' parameter
   in the INIT to indicate what types of address are acceptable.  When
   this parameter is present, the receiver of INIT (initiatee) MUST
   either use one of the address types indicated in the Supported
   Address Types parameter when responding to the INIT, or abort the
   association with an "Unresolvable Address" error cause if it is
   unwilling or incapable of using any of the address types indicated by
   its peer.

   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.

5.1.3 Generating State Cookie

When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a time stamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association. The following steps SHOULD be taken to generate the State Cookie: 1) Create an association TCB using information from both the received INIT and the outgoing INIT ACK chunk, 2) In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life', 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 4) Generate the State Cookie by combining this subset of information and the resultant MAC.
ToP   noToC   RFC2960 - Page 57
   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 association, so as to prevent resource attacks.

   The hashing method used to generate the MAC is strictly a private
   matter for the receiver of the INIT chunk.  The use of a MAC is
   mandatory to prevent denial of service attacks.  The secret key
   SHOULD be random ([RFC1750] provides some information on randomness
   guidelines); it SHOULD be changed reasonably frequently, and the
   timestamp in the State Cookie MAY be used to determine which key
   should be used to verify the MAC.

   An implementation SHOULD make the cookie as small as possible to
   insure interoperability.

5.1.4 State Cookie Processing

When an endpoint (in the COOKIE WAIT state) receives an INIT ACK chunk with a State Cookie parameter, it MUST immediately send a COOKIE ECHO chunk to its peer with the received State Cookie. The sender MAY also add any pending DATA chunks to the packet after the COOKIE ECHO chunk. The endpoint shall also start the T1-cookie timer after sending out the COOKIE ECHO chunk. If the timer expires, the endpoint shall retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated until either a COOKIE ACK is received or ' Max.Init.Retransmits' is reached causing the peer endpoint to be marked unreachable (and thus the association enters the CLOSED state).

5.1.5 State Cookie Authentication

When an endpoint receives a COOKIE ECHO chunk from another endpoint with which it has no association, it shall take the following actions: 1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). Reference [RFC2104] can be used as a guideline for generating the MAC, 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded,
ToP   noToC   RFC2960 - Page 58
   3) Compare the creation timestamp in the State Cookie to the current
      local time.  If the elapsed time is longer than the lifespan
      carried in the State Cookie, then the packet, including the COOKIE
      ECHO and any attached DATA chunks, SHOULD be discarded and the
      endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error
      cause to the peer endpoint,

   4) If the State Cookie is valid, create an association to the sender
      of the COOKIE ECHO chunk with the information in the TCB data
      carried in the COOKIE ECHO, and enter the ESTABLISHED state,

   5) Send a COOKIE ACK chunk to the peer acknowledging reception of the
      COOKIE ECHO.  The COOKIE ACK MAY be bundled with an outbound DATA
      chunk or SACK chunk; however, the COOKIE ACK MUST be the first
      chunk in the SCTP packet.

   6) Immediately acknowledge any DATA chunk bundled with the COOKIE
      ECHO with a SACK (subsequent DATA chunk acknowledgement should
      follow the rules defined in Section 6.2).  As mentioned in step
      5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
      MUST appear first in the SCTP packet.

   If a COOKIE ECHO is received from an endpoint with which the receiver
   of the COOKIE ECHO has an existing association, the procedures in
   Section 5.2 should be followed.

5.1.6 An Example of Normal Association Establishment

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 (assuming no bundling or fragmentation occurs):
ToP   noToC   RFC2960 - Page 59
   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,
                                  /              I-Tag=Tag_Z,
   (Cancel T1-init timer) <------/               Cookie_Z, & other info]
                                        (destroy temp TCB)
   COOKIE ECHO [Cookie_Z] ------\
   (Start T1-init timer)         \
   (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
                                         state)


                                  /---- COOKIE-ACK
                                 /
   (Cancel T1-init timer, <-----/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=initial TSN_A
       Strm=0,Seq=1 & user data]--\
    (Start T3-rtx timer)            \
                                     \->
                                 /----- SACK [TSN Ack=init
                                             TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

                                        ...
                                        {app sends 2 messages;strm 0}
                                  /---- DATA
                                 /        [TSN=init TSN_Z
                             <--/          Strm=0,Seq=1 & user data 1]
   SACK [TSN Ack=init TSN_Z,      /---- DATA
         Block=0]     --------\  /        [TSN=init TSN_Z +1,
                               \/          Strm=0,Seq=2 & user data 2]
                        <------/\
                                 \
                                  \------>

                     Figure 4: INITiation Example

   If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
   chunks are sent, the same INIT or COOKIE ECHO chunk with the same
   Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
ToP   noToC   RFC2960 - Page 60
   the timer restarted.  This shall be repeated Max.Init.Retransmits
   times before "A" considers "Z" unreachable and reports the failure to
   its upper layer (and thus the association enters the CLOSED state).
   When retransmitting the INIT, the endpoint MUST follow the rules
   defined in 6.3 to determine the proper timer value.

5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK

During the lifetime of an association (in one of the possible states), an endpoint may receive from its peer endpoint one of the setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it as described in this section. Note: An endpoint will not receive the chunk unless the chunk was sent to a SCTP transport address and is from a SCTP transport address associated with this endpoint. Therefore, the endpoint processes such a chunk as part of its current association. The following scenarios can cause duplicated or unexpected chunks: A) The peer has crashed without being detected, re-started itself and sent out a new INIT chunk trying to restore the association, B) Both sides are trying to initialize the association at about the same time, C) The chunk is from a stale packet that was used to establish the present association or a past association that is no longer in existence, D) The chunk is a false packet generated by an attacker, or E) The peer never received the COOKIE ACK and is retransmitting its COOKIE ECHO. The rules in the following sections shall be applied in order to identify and correctly handle these cases.

5.2.1 INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)

This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint. 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
ToP   noToC   RFC2960 - Page 61
   sent in its original INIT chunk (including its Initiation Tag,
   unchanged).  These original parameters are combined with those from
   the newly received INIT chunk.  The endpoint shall also generate a
   State Cookie with the INIT ACK.  The endpoint uses the parameters
   sent in its INIT to calculate the State Cookie.

   After that, the endpoint MUST NOT change its state, the T1-init timer
   shall be left running and the corresponding TCB MUST NOT be
   destroyed.  The normal procedures for handling State Cookies when 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, COOKIE-WAIT and SHUTDOWN-ACK-SENT

Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g. number of outbound streams) into the INIT ACK and cookie. After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- WAIT state are the Tie-Tags populated. For a normal association INIT (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.

5.2.3 Unexpected INIT ACK

If an INIT ACK is received by an endpoint in any state other than the COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk. An unexpected INIT ACK usually indicates the processing of an old or duplicated INIT chunk.
ToP   noToC   RFC2960 - Page 62

5.2.4 Handle a COOKIE ECHO when a TCB exists

When a COOKIE ECHO chunk is received by an endpoint in any state for an existing association (i.e., not in the CLOSED state) the following rules shall be applied: 1) Compute a MAC as described in Step 1 of Section 5.1.5, 2) Authenticate the State Cookie as described in Step 2 of Section 5.1.5 (this is case C or D above). 3) Compare the timestamp in the State Cookie to the current time. If the State Cookie is older than the lifespan carried in the State Cookie and the Verification Tags contained in the State Cookie do not match the current association's Verification Tags, the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint (this is case C or D in section 5.2). If both Verification Tags in the State Cookie match the Verification Tags of the current association, consider the State Cookie valid (this is case E of section 5.2) even if the lifespan is exceeded. 4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB. 5) Refer to Table 2 to determine the correct action to be taken.
ToP   noToC   RFC2960 - Page 63
+------------+------------+---------------+--------------+-------------+
|  Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag|   Action/   |
|            |            |               |              | Description |
+------------+------------+---------------+--------------+-------------+
|    X       |     X      |      M        |      M       |     (A)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     X      |      A        |      A       |     (B)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     0      |      A        |      A       |     (B)     |
+------------+------------+---------------+--------------+-------------+
|    X       |     M      |      0        |      0       |     (C)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     M      |      A        |      A       |     (D)     |
+======================================================================+
|       Table 2: Handling of a COOKIE ECHO when a TCB exists           |
+======================================================================+

   Legend:

      X - Tag does not match the existing TCB
      M - Tag matches the existing TCB.
      0 - No Tie-Tag in Cookie (unknown).
      A - All cases, i.e. M, X or 0.

   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
      recognizes this potential 'restart', the existing session is
      treated the same as if it received an ABORT followed by a new
      COOKIE ECHO with the following exceptions:

      -  Any SCTP DATA Chunks MAY be retained (this is an implementation
         specific option).

      -  A notification of RESTART SHOULD be sent to the ULP instead of
         a "COMMUNICATION LOST" notification.

      All the congestion control parameters (e.g., cwnd, ssthresh)
      related to this peer MUST be reset to their initial values (see
      Section 6.2.1).

      After this the endpoint shall enter the ESTABLISHED state.
ToP   noToC   RFC2960 - Page 64
      If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
      the peer has restarted (Action A), it MUST NOT setup a new
      association but instead resend the SHUTDOWN ACK and send an ERROR
      chunk with a "Cookie Received while Shutting Down" error cause to
      its peer.

   B) In this case, both sides may be attempting to start an association
      at about the same time but the peer endpoint started its INIT
      after responding to the local endpoint's INIT.  Thus it may have
      picked a new Verification Tag not being aware of the previous Tag
      it had sent this endpoint.  The endpoint should stay in or enter
      the ESTABLISHED state but it MUST update its peer's Verification
      Tag from the State Cookie, stop any init or cookie timers that may
      running and send a COOKIE ACK.

   C) In this case, the local endpoint's cookie has arrived late.
      Before it arrived, the local endpoint sent an INIT and received an
      INIT-ACK and finally sent a COOKIE ECHO with the peer's same tag
      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, if it has not already done so. It
      should stop any init or cookie timers that may be running and send
      a COOKIE ACK.

   Note: The "peer's Verification Tag" is the tag received in the
   Initiate Tag field of the INIT or INIT ACK chunk.

5.2.4.1 An Example of a Association Restart
In the following example, "A" initiates the association after a restart has occurred. Endpoint "Z" had no knowledge of the restart until the exchange (i.e. Heartbeats had not yet detected the failure of "A"). (assuming no bundling or fragmentation occurs):
ToP   noToC   RFC2960 - Page 65
Endpoint A                                          Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A                                             Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
      & other info]  --------\
(Start T1-init timer)         \
(Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                      compose temp TCB and Cookie_Z
                                      with Tie-Tags to previous
                                      association)
                                /--- INIT ACK [Veri Tag=Tag_A',
                               /               I-Tag=Tag_Z',
(Cancel T1-init timer) <------/                Cookie_Z[TieTags=
                                               Tag_A,Tag_Z
                                                & other info]
                                     (destroy temp TCB,leave original
                                      in place)
COOKIE ECHO [Veri=Tag_Z',
             Cookie_Z
             Tie=Tag_A,
             Tag_Z]----------\
(Start T1-init timer)         \
(Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                      Tie-Tags match old tags,
                                      Tags do not match i.e.
                                      case X X M M above,
                                      Announce Restart to ULP
                                      and reset association).
                               /---- COOKIE-ACK
                              /
(Cancel T1-init timer, <-----/
 Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
     Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer)            \
                                 \->
                              /----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/

                  Figure 5: A Restart Example
ToP   noToC   RFC2960 - Page 66

5.2.5 Handle Duplicate COOKIE-ACK.

At any state other than COOKIE-ECHOED, an endpoint should silently discard a received COOKIE ACK chunk.

5.2.6 Handle Stale COOKIE Error

Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates one of a number of possible events: A) That the association failed to completely setup before the State Cookie issued by the sender was processed. B) An old State Cookie was processed after setup completed. C) An old State Cookie is received from someone that the receiver is not interested in having an association with and the ABORT chunk was lost. When processing an ERROR chunk with a "Stale Cookie" error cause an endpoint should first examine if an association is in the process of being setup, i.e. the association is in the COOKIE-ECHOED state. In all cases if the association is not in the COOKIE-ECHOED state, the ERROR chunk should be silently discarded. If the association is in the COOKIE-ECHOED state, the endpoint may elect one of the following three alternatives. 1) Send a new INIT chunk to the endpoint to generate a new State Cookie and re-attempt the setup procedure. 2) Discard the TCB and report to the upper layer the inability to setup the association. 3) Send a new INIT chunk to the endpoint, adding a Cookie Preservative parameter requesting an extension to the lifetime of the State Cookie. When calculating the time extension, an implementation SHOULD use the RTT information measured based on the previous COOKIE ECHO / ERROR exchange, and should add no more than 1 second beyond the measured RTT, due to long State Cookie lifetimes making the endpoint more subject to a replay attack.
ToP   noToC   RFC2960 - Page 67

5.3 Other Initialization Issues

5.3.1 Selection of Tag Value

Initiate Tag values should be selected from the range of 1 to 2**32 - 1. It is very important that the Initiate Tag value be randomized to help protect against "man in the middle" and "sequence number" attacks. The methods described in [RFC1750] can be used for the Initiate Tag randomization. Careful selection of Initiate Tags is also necessary to prevent old duplicate packets from previous associations being mistakenly processed as belonging to the current association. Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the lifetime of an association. A new Verification Tag value MUST be used each time the endpoint tears-down and then re-establishes an association to the same peer.

6. User Data Transfer

Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN- PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunks are allowed to be 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 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 INIT or INIT ACK. For transmission efficiency, SCTP defines mechanisms for bundling of small user messages and fragmentation of large user messages. The following diagram depicts the flow of user messages through SCTP.
ToP   noToC   RFC2960 - Page 68
   In this section the term "data sender" refers to the endpoint that
   transmits a DATA chunk and the term "data receiver" refers to the
   endpoint that receives a DATA chunk.  A data receiver will transmit
   SACK chunks.

                 +--------------------------+
                 |      User Messages       |
                 +--------------------------+
       SCTP user        ^  |
      ==================|==|=======================================
                        |  v (1)
             +------------------+    +--------------------+
             | SCTP DATA Chunks |    |SCTP Control Chunks |
             +------------------+    +--------------------+
                        ^  |             ^  |
                        |  v (2)         |  v (2)
                     +--------------------------+
                     |      SCTP packets        |
                     +--------------------------+
       SCTP                      ^  |
      ===========================|==|===========================
                                 |  v
             Connectionless Packet Transfer Service (e.g., IP)

   Notes:

      1) When converting user messages into DATA chunks, an endpoint
         will fragment user messages larger than the current association
         path MTU into multiple DATA chunks.  The data receiver will
         normally reassemble the fragmented message from DATA chunks
         before delivery to the user (see Section 6.9 for details).

      2) Multiple DATA and control chunks may be bundled by the sender
         into a single SCTP packet for transmission, as long as the
         final size of the packet does not exceed the current path MTU.
         The receiver will unbundle the packet back into the original
         chunks.  Control chunks MUST come before DATA chunks in the
         packet.

                Figure 6: Illustration of User Data Transfer

   The fragmentation and bundling mechanisms, as detailed in Sections
   6.9 and 6.10, are OPTIONAL to implement by the data sender, but they
   MUST be implemented by the data receiver, i.e., an endpoint MUST
   properly receive and process bundled or fragmented data.
ToP   noToC   RFC2960 - Page 69

6.1 Transmission of DATA Chunks

This document is specified as if there is a single retransmission timer per destination transport address, but implementations MAY have a retransmission timer for each DATA chunk. The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks: A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender. B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks which are marked for retransmission (limited by the current cwnd). D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow. Multiple DATA chunks committed for transmission MAY be bundled in a single packet. Furthermore, DATA chunks being retransmitted MAY be bundled with new DATA chunks, as long as the resulting packet size does not exceed the path MTU. A ULP may request that no bundling is performed but this should only turn off any delays that a SCTP implementation may be using to increase bundling efficiency. It does not in itself stop all bundling from occurring (i.e. in case of congestion or retransmission). Before an endpoint transmits a DATA chunk, if any received DATA chunks have not been acknowledged (e.g., due to delayed ack), the sender should create a SACK and bundle it with the outbound DATA chunk, as long as the size of the final SCTP packet does not exceed the current MTU. See Section 6.2.
ToP   noToC   RFC2960 - Page 70
   IMPLEMENTATION NOTE: When the window is full (i.e., transmission is
   disallowed by Rule A and/or Rule B), the sender MAY still accept send
   requests from its upper layer, but MUST transmit no more DATA chunks
   until some or all of the outstanding DATA chunks are acknowledged and
   transmission is allowed by Rule A and Rule B again.

   Whenever a transmission or retransmission is made to any address, if
   the T3-rtx timer of that address is not currently running, the sender
   MUST start that timer.  If the timer for that address is already
   running, the sender MUST restart the timer if the earliest (i.e.,
   lowest TSN) outstanding DATA chunk sent to that address is being
   retransmitted.  Otherwise, the data sender MUST NOT restart the
   timer.

   When starting or restarting the T3-rtx timer, the timer value must be
   adjusted according to the timer rules defined in Sections 6.3.2, and
   6.3.3.

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.

6.2 Acknowledgement on Reception of DATA Chunks

The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. A SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words an implementation MAY lower this value below 500ms but MUST NOT raise it above 500ms.
ToP   noToC   RFC2960 - Page 71
   Acknowledgements MUST be sent in SACK chunks unless shutdown was
   requested by the ULP in which case an endpoint MAY send an
   acknowledgement in the SHUTDOWN chunk.  A SACK chunk can acknowledge
   the reception of multiple DATA chunks.  See Section 3.3.4 for SACK
   chunk format.  In particular, the SCTP endpoint MUST fill in the
   Cumulative TSN Ack field to indicate the latest sequential TSN (of a
   valid DATA chunk) it has received.  Any received DATA chunks with TSN
   greater than the value in the Cumulative TSN Ack field SHOULD also be
   reported in the Gap Ack Block fields.

   Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
   Therefore, the endpoint should use a SACK instead of the SHUTDOWN
   chunk to acknowledge DATA chunks received out of order .

   When a packet arrives with duplicate DATA chunk(s) and with no new
   DATA chunk(s), the endpoint MUST immediately send a SACK with no
   delay.  If a packet arrives with duplicate DATA chunk(s) bundled with
   new DATA chunks, the endpoint MAY immediately send a SACK.  Normally
   receipt of duplicate DATA chunks will occur when the original SACK
   chunk was lost and the peer's RTO has expired.  The duplicate TSN
   number(s) SHOULD be reported in the SACK as duplicate.

   When an endpoint receives a SACK, it MAY use the Duplicate TSN
   information to determine if SACK loss is occurring.  Further use of
   this data is for future study.

   The data receiver is responsible for maintaining its receive buffers.
   The data receiver SHOULD notify the data sender in a timely manner of
   changes in its ability to receive data.  How an implementation
   manages its receive buffers is dependent on many factors (e.g.,
   Operating System, memory management system, amount of memory, etc.).
   However, the data sender strategy defined in Section 6.2.1 is based
   on the assumption of receiver operation similar to the following:

      A) At initialization of the association, the endpoint tells the
         peer how much receive buffer space it has allocated to the
         association in the INIT or INIT ACK.  The endpoint sets a_rwnd
         to this value.

      B) As DATA chunks are received and buffered, decrement a_rwnd by
         the number of bytes received and buffered.  This is, in effect,
         closing rwnd at the data sender and restricting the amount of
         data it can transmit.

      C) As DATA chunks are delivered to the ULP and released from the
         receive buffers, increment a_rwnd by the number of bytes
         delivered to the upper layer.  This is, in effect, opening up
         rwnd on the data sender and allowing it to send more data.  The
ToP   noToC   RFC2960 - Page 72
         data receiver SHOULD NOT increment a_rwnd unless it has
         released bytes from its receive buffer.  For example, if the
         receiver is holding fragmented DATA chunks in a reassembly
         queue, it should not increment a_rwnd.

      D) When sending a SACK, the data receiver SHOULD place the current
         value of a_rwnd into the a_rwnd field.  The data receiver
         SHOULD take into account that the data sender will not
         retransmit DATA chunks that are acked via the Cumulative TSN
         Ack (i.e., will drop from its retransmit queue).

   Under certain circumstances, the data receiver may need to drop DATA
   chunks that it has received but hasn't released from its receive
   buffers (i.e., delivered to the ULP).  These DATA chunks may have
   been acked in Gap Ack Blocks.  For example, the data receiver may be
   holding data in its receive buffers while reassembling a fragmented
   user message from its peer when it runs out of receive buffer space.
   It may drop these DATA chunks even though it has acknowledged them in
   Gap Ack Blocks.  If a data receiver drops DATA chunks, it MUST NOT
   include them in Gap Ack Blocks in subsequent SACKs until they are
   received again via retransmission.  In addition, the endpoint should
   take into account the dropped data when calculating its a_rwnd.

   An endpoint SHOULD NOT revoke a SACK and discard data. Only in
   extreme circumstance should an endpoint use this procedure (such as
   out of buffer space).  The data receiver should take into account
   that dropping data that has been acked in Gap Ack Blocks can result
   in suboptimal retransmission strategies in the data sender and thus
   in suboptimal performance.

   The following example illustrates the use of delayed
   acknowledgements:
ToP   noToC   RFC2960 - Page 73
   Endpoint A                                      Endpoint Z

   {App sends 3 messages; strm 0}
   DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
   (Start T3-rtx timer)

   DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
                                 /------- SACK [TSN Ack=8,block=0]
   (cancel T3-rtx timer)  <-----/

   DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
   (Start T3-rtx timer)
                                          ...
                                          {App sends 1 message; strm 1}
                                          (bundle SACK with DATA)
                                   /----- SACK [TSN Ack=9,block=0] \
                                  /         DATA [TSN=6,Strm=1,Seq=2]
   (cancel T3-rtx timer)  <------/        (Start T3-rtx timer)

   (ack delayed)
   (send ack)
   SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)

          Figure 7:  Delayed Acknowledgment Example

   If an endpoint receives a DATA chunk with no user data (i.e., the
   Length field is set to 16) it MUST send an ABORT with error cause set
   to "No User Data".

   An endpoint SHOULD NOT send a DATA chunk with no user data part.

6.2.1 Processing a Received SACK

Each SACK an endpoint receives contains an a_rwnd value. This value represents the amount of buffer space the data receiver, at the time of transmitting the SACK, has left of its total receive buffer space (as specified in the INIT/INIT ACK). Using a_rwnd, Cumulative TSN Ack and Gap Ack Blocks, the data sender can develop a representation of the peer's receive buffer space. One of the problems the data sender must take into account when processing a SACK is that a SACK can be received out of order. That is, a SACK sent by the data receiver can pass an earlier SACK and be received first by the data sender. If a SACK is received out of order, the data sender can develop an incorrect view of the peer's receive buffer space.
ToP   noToC   RFC2960 - Page 74
   Since there is no explicit identifier that can be used to detect
   out-of-order SACKs, the data sender must use heuristics to determine
   if a SACK is new.

   An endpoint SHOULD use the following rules to calculate the rwnd,
   using the a_rwnd value, the Cumulative TSN Ack and Gap Ack Blocks in
   a received SACK.

   A) At the establishment of the association, the endpoint initializes
      the rwnd to the Advertised Receiver Window Credit (a_rwnd) the
      peer specified in the INIT or INIT ACK.

   B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
      the endpoint subtracts the data size of the chunk from the rwnd of
      that peer.

   C) Any time a DATA chunk is marked for retransmission (via either
      T3-rtx timer expiration (Section 6.3.3)or via fast retransmit
      (Section 7.2.4)), add the data size of those chunks to the rwnd.

      Note: If the implementation is maintaining a timer on each DATA
      chunk then only DATA chunks whose timer expired would be marked
      for retransmission.

   D) Any time a SACK arrives, the endpoint performs the following:

         i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
         Point, then drop the SACK.   Since Cumulative TSN Ack is
         monotonically increasing, a SACK whose Cumulative TSN Ack is
         less than the Cumulative TSN Ack Point indicates an out-of-
         order SACK.

         ii) Set rwnd equal to the newly received a_rwnd minus the
         number of bytes still outstanding after processing the
         Cumulative TSN Ack and the Gap Ack Blocks.

         iii) If the SACK is missing a TSN that was previously
         acknowledged via a Gap Ack Block (e.g., the data receiver
         reneged on the data), then mark the corresponding DATA chunk as
         available for retransmit:  Mark it as missing for fast
         retransmit as described in Section 7.2.4 and if no retransmit
         timer is running for the destination address to which the DATA
         chunk was originally transmitted, then T3-rtx is started for
         that destination address.
ToP   noToC   RFC2960 - Page 75

6.3 Management of Retransmission Timer

An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout). When an endpoint's peer is multi-homed, the endpoint will calculate a separate RTO for each different destination transport address of its peer endpoint. The computation and management of RTO in SCTP follows closely how TCP manages its retransmission timer. To compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation).

6.3.1 RTO Calculation

The rules governing the computation of SRTT, RTTVAR, and RTO are as follows: C1) Until an RTT measurement has been made for a packet sent to the given destination transport address, set RTO to the protocol parameter 'RTO.Initial'. C2) When the first RTT measurement R is made, set SRTT <- R, RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR. C3) When a new RTT measurement R' is made, set RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. After the computation, update RTO <- SRTT + 4 * RTTVAR. C4) When data is in flight and when allowed by rule C5 below, a new RTT measurement MUST be made each round trip. Furthermore, new RTT measurements SHOULD be made no more than once per round-trip for a given destination transport address. There are two reasons for this recommendation: First, it appears that measuring more frequently often does not in practice yield any significant benefit [ALLMAN99]; second, if measurements are made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes
ToP   noToC   RFC2960 - Page 76
       them to reflect new values) as they would if making only one
       measurement per round-trip and using RTO.Alpha and RTO.Beta as
       given in rule C3.  However, the exact nature of these adjustments
       remains a research issue.

   C5) Karn's algorithm: RTT measurements MUST NOT be made using packets
       that were retransmitted (and thus for which it is ambiguous
       whether the reply was for the first instance of the packet or a
       later instance).

   C6) Whenever RTO is computed, if it is less than RTO.Min seconds then
       it is rounded up to RTO.Min seconds.  The reason for this rule is
       that RTOs that do not have a high minimum value are susceptible
       to unnecessary timeouts [ALLMAN99].

   C7) A maximum value may be placed on RTO provided it is at least
       RTO.max seconds.

   There is no requirement for the clock granularity G used for
   computing RTT measurements and the different state variables, other
   than:

   G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <-
       G.

   Experience [ALLMAN99] has shown that finer clock granularities (<=
   100 msec) perform somewhat better than more coarse granularities.

6.3.2 Retransmission Timer Rules

The rules for managing the retransmission timer are as follows: R1) Every time a DATA chunk is sent to any address (including a retransmission), if the T3-rtx timer of that address is not running, start it running so that it will expire after the RTO of that address. The RTO used here is that obtained after any doubling due to previous T3-rtx timer expirations on the corresponding destination address as discussed in rule E2 below. R2) Whenever all outstanding data sent to an address have been acknowledged, turn off the T3-rtx timer of that address. R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address).
ToP   noToC   RFC2960 - Page 77
   R4) Whenever a SACK is received missing a TSN that was previously
       acknowledged via a Gap Ack Block, start T3-rtx for the
       destination address to which the DATA chunk was originally
       transmitted if it is not already running.

   The following example shows the use of various timer rules (assuming
   the receiver uses delayed acks).

   Endpoint A                                         Endpoint Z
   {App begins to send}
   Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
   (Start T3-rtx timer)
                                           {App sends 1 message; strm 1}
                                           (bundle ack with data)
   DATA [TSN=8,Strm=0,Seq=4] ----\     /-- SACK [TSN Ack=7,Block=0]
                                  \   /      DATA [TSN=6,Strm=1,Seq=2]
                                   \ /     (Start T3-rtx timer)
                                    \
                                   / \
   (Re-start T3-rtx timer) <------/   \--> (ack delayed)
   (ack delayed)
   {send ack}
   SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
                                           ..
                                           (send ack)
   (Cancel T3-rtx timer)  <-------------- SACK [TSN Ack=8,Block=0]

                 Figure 8 - Timer Rule Examples

6.3.3 Handle T3-rtx Expiration

Whenever the retransmission timer T3-rtx expires for a destination address, do the following: E1) For the destination address for which the timer expires, adjust its ssthresh with rules defined in Section 7.2.3 and set the cwnd <- MTU. E2) For the destination address for which the timer expires, set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in rule C7 above (RTO.max) may be used to provide an upper bound to this doubling operation. E3) Determine how many of the earliest (i.e., lowest TSN) outstanding DATA chunks for the address for which the T3-rtx has expired will fit into a single packet, subject to the MTU constraint for the path corresponding to the destination transport address to which the retransmission is being sent (this may be different from the
ToP   noToC   RFC2960 - Page 78
       address for which the timer expires [see Section 6.4]).  Call
       this value K.  Bundle and retransmit those K DATA chunks in a
       single packet to the destination endpoint.

   E4) Start the retransmission timer T3-rtx on the destination address
       to which the retransmission is sent, if rule R1 above indicates
       to do so.  The RTO to be used for starting T3-rtx should be the
       one for the destination address to which the retransmission is
       sent, which, when the receiver is multi-homed, may be different
       from the destination address for which the timer expired (see
       Section 6.4 below).

   After retransmitting, once a new RTT measurement is obtained (which
   can happen only when new data has been sent and acknowledged, per
   rule C5, or for a measurement made from a HEARTBEAT [see Section
   8.3]), the computation in rule C3 is performed, including the
   computation of RTO, which may result in "collapsing" RTO back down
   after it has been subject to doubling (rule E2).

   Note: Any DATA chunks that were sent to the address for which the
   T3-rtx timer expired but did not fit in one MTU (rule E3 above),
   should be marked for retransmission and sent as soon as cwnd allows
   (normally when a SACK arrives).

   The final rule for managing the retransmission timer concerns
   failover (see Section 6.4.1):

   F1) Whenever an endpoint switches from the current destination
       transport address to a different one, the current retransmission
       timers are left running.  As soon as the endpoint transmits a
       packet containing DATA chunk(s) to the new transport address,
       start the timer on that transport address, using the RTO value of
       the destination address to which the data is being sent, if rule
       R1 indicates to do so.

6.4 Multi-homed SCTP Endpoints

An SCTP endpoint is considered multi-homed if there are more than one transport address that can be used as a destination address to reach that endpoint. Moreover, the ULP of an endpoint shall select one of the multiple 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.
ToP   noToC   RFC2960 - Page 79
   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.
ToP   noToC   RFC2960 - Page 80
   Note: Rules for picking the most divergent source-destination pair
   are an implementation decision and is not specified within this
   document.



(page 80 continued on part 4)

Next Section