tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2960

 
 
 

Stream Control Transmission Protocol

Part 3 of 5, p. 52 to 80
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 52 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part