tech-invite   World Map     

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

RFC 2960

 
 
 

Stream Control Transmission Protocol

Part 4 of 5, p. 80 to 114
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 80 
6.5 Stream Identifier and Stream Sequence Number

   Every DATA chunk MUST carry a valid stream identifier.  If an
   endpoint receives a DATA chunk with an invalid stream identifier, it
   shall acknowledge the reception of the DATA chunk following the
   normal procedure, immediately send an ERROR chunk with cause set to
   "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA
   chunk. The endpoint may bundle the ERROR chunk in the same packet as
   the SACK as long as the ERROR follows the SACK.

   The stream sequence number in all the streams shall start from 0 when
   the association is established.  Also, when the stream sequence
   number reaches the value 65535 the next stream sequence number shall
   be set to 0.

6.6 Ordered and Unordered Delivery

   Within a stream, an endpoint MUST deliver DATA chunks received with
   the U flag set to 0 to the upper layer according to the order of
   their stream sequence number.  If DATA chunks arrive out of order of
   their stream sequence number, the endpoint MUST hold the received
   DATA chunks from delivery to the ULP until they are re-ordered.

   However, an SCTP endpoint can indicate that no ordered delivery is
   required for a particular DATA chunk transmitted within the stream by
   setting the U flag of the DATA chunk to 1.

   When an endpoint receives a DATA chunk with the U flag set to 1, it
   must bypass the ordering mechanism and immediately deliver the data
   to the upper layer (after re-assembly if the user data is fragmented
   by the data sender).

   This provides an effective way of transmitting "out-of-band" data in
   a given stream.  Also, a stream can be used as an "unordered" stream
   by simply setting the U flag to 1 in all DATA chunks sent through
   that stream.

   IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an
   implementation may choose to place the DATA chunk in an outbound
   packet that is at the head of the outbound transmission queue if
   possible.

Top      Up      ToC       Page 81 
   The 'Stream Sequence Number' field in a DATA chunk with U flag set to
   1 has no significance.  The sender can fill it with arbitrary value,
   but the receiver MUST ignore the field.

   Note:  When transmitting ordered and unordered data, an endpoint does
   not increment its Stream Sequence Number when transmitting a DATA
   chunk with U flag set to 1.

6.7 Report Gaps in Received DATA TSNs

   Upon the reception of a new DATA chunk, an endpoint shall examine the
   continuity of the TSNs received.  If the endpoint detects a gap in
   the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack
   Blocks immediately.  The data receiver continues sending a SACK after
   receipt of each SCTP packet that doesn't fill the gap.

   Based on the Gap Ack Block from the received SACK, the endpoint can
   calculate the missing DATA chunks and make decisions on whether to
   retransmit them (see Section 6.2.1 for details).

   Multiple gaps can be reported in one single SACK (see Section 3.3.4).

   When its peer is multi-homed, the SCTP endpoint SHOULD always try to
   send the SACK to the same destination address from which the last
   DATA chunk was received.

   Upon the reception of a SACK, the endpoint MUST remove all DATA
   chunks which have been acknowledged by the SACK's Cumulative TSN Ack
   from its transmit queue.  The endpoint MUST also treat all the DATA
   chunks with TSNs not included in the Gap Ack Blocks reported by the
   SACK as "missing".  The number of "missing" reports for each
   outstanding DATA chunk MUST be recorded by the data sender in order
   to make retransmission decisions.  See Section 7.2.4 for details.

   The following example shows the use of SACK to report a gap.

Top      Up      ToC       Page 82 
      Endpoint A                                    Endpoint Z
      {App sends 3 messages; strm 0}
      DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
      (Start T3-rtx timer)

      DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)

      DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
                                                  immediately send ack)
                                      /----- SACK [TSN Ack=6,Block=1,
                                     /             Strt=2,End=2]
                              <-----/
      (remove 6 from out-queue,
       and mark 7 as "1" missing report)

                 Figure 9 - Reporting a Gap using SACK

   The maximum number of Gap Ack Blocks that can be reported within a
   single SACK chunk is limited by the current path MTU.  When a single
   SACK can not cover all the Gap Ack Blocks needed to be reported due
   to the MTU limitation, the endpoint MUST send only one SACK,
   reporting the Gap Ack Blocks from the lowest to highest TSNs, within
   the size limit set by the MTU, and leave the remaining highest TSN
   numbers unacknowledged.

6.8 Adler-32 Checksum Calculation

   When sending an SCTP packet, the endpoint MUST strengthen the data
   integrity of the transmission by including the Adler-32 checksum
   value calculated on the packet, as described below.

   After the packet is constructed (containing the SCTP common header
   and one or more control or DATA chunks), the transmitter shall:

   1) Fill in the proper Verification Tag in the SCTP common header and
      initialize the checksum field to 0's.

   2) Calculate the Adler-32 checksum of the whole packet, including the
      SCTP common header and all the chunks.  Refer to appendix B for
      details of the Adler-32 algorithm.  And,

   3) Put the resultant value into the checksum field in the common
      header, and leave the rest of the bits unchanged.

   When an SCTP packet is received, the receiver MUST first check the
   Adler-32 checksum:

   1) Store the received Adler-32 checksum value aside,

Top      Up      ToC       Page 83 
   2) Replace the 32 bits of the checksum field in the received SCTP
      packet with all '0's and calculate an Adler-32 checksum value of
      the whole received packet.  And,

   3) Verify that the calculated Adler-32 checksum is the same as the
      received Adler-32 checksum.  If not, the receiver MUST treat the
      packet as an invalid SCTP packet.

   The default procedure for handling invalid SCTP packets is to
   silently discard them.

6.9 Fragmentation and Reassembly

   An endpoint MAY support fragmentation when sending DATA chunks, but
   MUST support reassembly when receiving DATA chunks.  If an endpoint
   supports fragmentation, it MUST fragment a user message if the size
   of the user message to be sent causes the outbound SCTP packet size
   to exceed the current MTU.  If an implementation does not support
   fragmentation of outbound user messages, the endpoint must return an
   error to its upper layer and not attempt to send the user message.

   IMPLEMENTATION NOTE:  In this error case, the Send primitive
   discussed in Section 10.1 would need to return an error to the upper
   layer.

   If its peer is multi-homed, the endpoint shall choose a size no
   larger than the association Path MTU.  The association Path MTU is
   the smallest Path MTU of all destination addresses.

   Note: Once a message is fragmented it cannot be re-fragmented.
   Instead if the PMTU has been reduced, then IP fragmentation must be
   used.  Please see Section 7.3 for details of PMTU discovery.

   When determining when to fragment, the SCTP implementation MUST take
   into account the SCTP packet header as well as the DATA chunk
   header(s).  The implementation MUST also take into account the space
   required for a SACK chunk if bundling a SACK chunk with the DATA
   chunk.

   Fragmentation takes the following steps:

   1) The data sender MUST break the user message into a series of DATA
      chunks such that each chunk plus SCTP overhead fits into an IP
      datagram smaller than or equal to the association Path MTU.

   2) The transmitter MUST then assign, in sequence, a separate TSN to
      each of the DATA chunks in the series.  The transmitter assigns
      the same SSN to each of the DATA chunks.  If the user indicates

Top      Up      ToC       Page 84 
      that the user message is to be delivered using unordered delivery,
      then the U flag of each DATA chunk of the user message MUST be set
      to 1.

   3) The transmitter MUST also set the B/E bits of the first DATA chunk
      in the series to '10', the B/E bits of the last DATA chunk in the
      series to '01', and the B/E bits of all other DATA chunks in the
      series to '00'.

   An endpoint MUST recognize fragmented DATA chunks by examining the
   B/E bits in each of the received DATA chunks, and queue the
   fragmented DATA chunks for re-assembly.  Once the user message is
   reassembled, SCTP shall pass the re-assembled user message to the
   specific stream for possible re-ordering and final dispatching.

   Note: If the data receiver runs out of buffer space while still
   waiting for more fragments to complete the re-assembly of the
   message, it should dispatch part of its inbound message through a
   partial delivery API (see Section 10), freeing some of its receive
   buffer space so that the rest of the message may be received.

6.10 Bundling

   An endpoint bundles chunks by simply including multiple chunks in one
   outbound SCTP packet.  The total size of the resultant IP datagram,
   including the SCTP packet and IP headers, MUST be less or equal to
   the current Path MTU.

   If its peer endpoint is multi-homed, the sending endpoint shall
   choose a size no larger than the latest MTU of the current primary
   path.

   When bundling control chunks with DATA chunks, an endpoint MUST place
   control chunks first in the outbound SCTP packet.  The transmitter
   MUST transmit DATA chunks within a SCTP packet in increasing order of
   TSN.

   Note:  Since control chunks must be placed first in a packet and
   since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK
   chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK
   chunks.

   Partial chunks MUST NOT be placed in an SCTP packet.

Top      Up      ToC       Page 85 
   An endpoint MUST process received chunks in their order in the
   packet. The receiver uses the chunk length field to determine the end
   of a chunk and beginning of the next chunk taking account of the fact
   that all chunks end on a 4 byte boundary.  If the receiver detects a
   partial chunk, it MUST drop the chunk.

   An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with
   any other chunks.

7. Congestion control

   Congestion control is one of the basic functions in SCTP.  For some
   applications, it may be likely that adequate resources will be
   allocated to SCTP traffic to assure prompt delivery of time-critical
   data - thus it would appear to be unlikely, during normal operations,
   that transmissions encounter severe congestion conditions.  However
   SCTP must operate under adverse operational conditions, which can
   develop upon partial network failures or unexpected traffic surges.
   In such situations SCTP must follow correct congestion control steps
   to recover from congestion quickly in order to get data delivered as
   soon as possible.  In the absence of network congestion, these
   preventive congestion control algorithms should show no impact on the
   protocol performance.

   IMPLEMENTATION NOTE: As far as its specific performance requirements
   are met, an implementation is always allowed to adopt a more
   conservative congestion control algorithm than the one defined below.

   The congestion control algorithms used by SCTP are based on
   [RFC2581].  This section describes how the algorithms defined in
   RFC2581 are adapted for use in SCTP.  We first list differences in
   protocol designs between TCP and SCTP, and then describe SCTP's
   congestion control scheme.  The description will use the same
   terminology as in TCP congestion control whenever appropriate.

   SCTP congestion control is always applied to the entire association,
   and not to individual streams.

7.1 SCTP Differences from TCP Congestion control

   Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as
   the TCP SACK.  TCP considers the information carried in the SACK as
   advisory information only.  SCTP considers the information carried in
   the Gap Ack Blocks in the SACK chunk as advisory.  In SCTP, any DATA
   chunk that has been acknowledged by SACK, including DATA that arrived
   at the receiving end out of order, are not considered fully delivered
   until the Cumulative TSN Ack Point passes the TSN of the DATA chunk
   (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack

Top      Up      ToC       Page 86 
   field in the SACK).  Consequently, the value of cwnd controls the
   amount of outstanding data, rather than (as in the case of non-SACK
   TCP) the upper bound between the highest acknowledged sequence number
   and the latest DATA chunk that can be sent within the congestion
   window.  SCTP SACK leads to different implementations of fast-
   retransmit and fast-recovery than non-SACK TCP.  As an example see
   [FALL96].

   The biggest difference between SCTP and TCP, however, is multi-
   homing.  SCTP is designed to establish robust communication
   associations between two endpoints each of which may be reachable by
   more than one transport address.  Potentially different addresses may
   lead to different data paths between the two endpoints, thus ideally
   one may need a separate set of congestion control parameters for each
   of the paths.  The treatment here of congestion control for multi-
   homed receivers is new with SCTP and may require refinement in the
   future.  The current algorithms make the following assumptions:

   o  The sender usually uses the same destination address until being
      instructed by the upper layer otherwise; however, SCTP may change
      to an alternate destination in the event an address is marked
      inactive (see Section 8.2).  Also, SCTP may retransmit to a
      different transport address than the original transmission.

   o  The sender keeps a separate congestion control parameter set for
      each of the destination addresses it can send to (not each
      source-destination pair but for each destination).  The parameters
      should decay if the address is not used for a long enough time
      period.

   o  For each of the destination addresses, an endpoint does slow-start
      upon the first transmission to that address.

   Note:  TCP guarantees in-sequence delivery of data to its upper-layer
   protocol within a single TCP session.  This means that when TCP
   notices a gap in the received sequence number, it waits until the gap
   is filled before delivering the data that was received with sequence
   numbers higher than that of the missing data.  On the other hand,
   SCTP can deliver data to its upper-layer protocol even if there is a
   gap in TSN if the Stream Sequence Numbers are in sequence for a
   particular stream (i.e., the missing DATA chunks are for a different
   stream) or if unordered delivery is indicated.  Although this does
   not affect cwnd, it might affect rwnd calculation.

Top      Up      ToC       Page 87 
7.2 SCTP Slow-Start and Congestion Avoidance

   The slow start and congestion avoidance algorithms MUST be used by an
   endpoint to control the amount of data being injected into the
   network. The congestion control in SCTP is employed in regard to the
   association, not to an individual stream.  In some situations it may
   be beneficial for an SCTP sender to be more conservative than the
   algorithms allow; however, an SCTP sender MUST NOT be more aggressive
   than the following algorithms allow.

   Like TCP, an SCTP endpoint uses the following three control variables
   to regulate its transmission rate.

   o  Receiver advertised window size (rwnd, in bytes), which is set by
      the receiver based on its available buffer space for incoming
      packets.

      Note: This variable is kept on the entire association.

   o  Congestion control window (cwnd, in bytes), which is adjusted by
      the sender based on observed network conditions.

      Note: This variable is maintained on a per-destination address
      basis.

   o  Slow-start threshold (ssthresh, in bytes), which is used by the
      sender to distinguish slow start and congestion avoidance phases.

      Note: This variable is maintained on a per-destination address
      basis.

   SCTP also requires one additional control variable,
   partial_bytes_acked, which is used during congestion avoidance phase
   to facilitate cwnd adjustment.

   Unlike TCP, an SCTP sender MUST keep a set of these control variables
   cwnd, ssthresh and partial_bytes_acked for EACH destination address
   of its peer (when its peer is multi-homed).  Only one rwnd is kept
   for the whole association (no matter if the peer is multi-homed or
   has a single address).

7.2.1 Slow-Start

   Beginning data transmission into a network with unknown conditions or
   after a sufficiently long idle period requires SCTP to probe the
   network to determine the available capacity.  The slow start
   algorithm is used for this purpose at the beginning of a transfer, or
   after repairing loss detected by the retransmission timer.

Top      Up      ToC       Page 88 
   o  The initial cwnd before DATA transmission or after a sufficiently
      long idle period MUST be <= 2*MTU.

   o  The initial cwnd after a retransmission timeout MUST be no more
      than 1*MTU.

   o  The initial value of ssthresh MAY be arbitrarily high (for
      example, implementations MAY use the size of the receiver
      advertised window).

   o  Whenever cwnd is greater than zero, the endpoint is allowed to
      have cwnd bytes of data outstanding on that transport address.

   o  When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
      use the slow start algorithm to increase cwnd (assuming the
      current congestion window is being fully utilized).  If an
      incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
      increased by at most the lesser of 1) the total size of the
      previously outstanding DATA chunk(s) acknowledged, and 2) the
      destination's path MTU. This protects against the ACK-Splitting
      attack outlined in [SAVAGE99].

   In instances where its peer endpoint is multi-homed, if an endpoint
   receives a SACK that advances its Cumulative TSN Ack Point, then it
   should update its cwnd (or cwnds) apportioned to the destination
   addresses to which it transmitted the acknowledged data.  However if
   the received SACK does not advance the Cumulative TSN Ack Point, the
   endpoint MUST NOT adjust the cwnd of any of the destination
   addresses.

   Because an endpoint's cwnd is not tied to its Cumulative TSN Ack
   Point, as duplicate SACKs come in, even though they may not advance
   the Cumulative TSN Ack Point an endpoint can still use them to clock
   out new data.  That is, the data newly acknowledged by the SACK
   diminishes the amount of data now in flight to less than cwnd; and so
   the current, unchanged value of cwnd now allows new data to be sent.
   On the other hand, the increase of cwnd must be tied to the
   Cumulative TSN Ack Point advancement as specified above.  Otherwise
   the duplicate SACKs will not only clock out new data, but also will
   adversely clock out more new data than what has just left the
   network, during a time of possible congestion.

   o  When the endpoint does not transmit data on a given transport
      address, the cwnd of the transport address should be adjusted to
      max(cwnd/2, 2*MTU) per RTO.

Top      Up      ToC       Page 89 
7.2.2 Congestion Avoidance

   When cwnd is greater than ssthresh, cwnd should be incremented by
   1*MTU per RTT if the sender has cwnd or more bytes of data
   outstanding for the corresponding transport address.

   In practice an implementation can achieve this goal in the following
   way:

   o  partial_bytes_acked is initialized to 0.

   o  Whenever cwnd is greater than ssthresh, upon each SACK arrival
      that advances the Cumulative TSN Ack Point, increase
      partial_bytes_acked by the total number of bytes of all new chunks
      acknowledged in that SACK including chunks acknowledged by the new
      Cumulative TSN Ack and by Gap Ack Blocks.

   o  When partial_bytes_acked is equal to or greater than cwnd and
      before the arrival of the SACK the sender had cwnd or more bytes
      of data outstanding (i.e., before arrival of the SACK, flightsize
      was greater than or equal to cwnd), increase cwnd by MTU, and
      reset partial_bytes_acked to (partial_bytes_acked - cwnd).

   o  Same as in the slow start, when the sender does not transmit DATA
      on a given transport address, the cwnd of the transport address
      should be adjusted to max(cwnd / 2, 2*MTU) per RTO.

   o  When all of the data transmitted by the sender has been
      acknowledged by the receiver, partial_bytes_acked is initialized
      to 0.

7.2.3 Congestion Control

   Upon detection of packet losses from SACK  (see Section 7.2.4), An
   endpoint should do the following:

      ssthresh = max(cwnd/2, 2*MTU)
      cwnd = ssthresh

   Basically, a packet loss causes cwnd to be cut in half.

   When the T3-rtx timer expires on an address, SCTP should perform slow
   start by:

      ssthresh = max(cwnd/2, 2*MTU)
      cwnd = 1*MTU

Top      Up      ToC       Page 90 
   and assure that no more than one SCTP packet will be in flight for
   that address until the endpoint receives acknowledgement for
   successful delivery of data to that address.

7.2.4 Fast Retransmit on Gap Reports

   In the absence of data loss, an endpoint performs delayed
   acknowledgement.  However, whenever an endpoint notices a hole in the
   arriving TSN sequence, it SHOULD start sending a SACK back every time
   a packet arrives carrying data until the hole is filled.

   Whenever an endpoint receives a SACK that indicates some TSN(s)
   missing, it SHOULD wait for 3 further miss indications (via
   subsequent SACK's) on the same TSN(s) before taking action with
   regard to Fast Retransmit.

   When the TSN(s) is reported as missing in the fourth consecutive
   SACK, the data sender shall:

   1) Mark the missing DATA chunk(s) for retransmission,

   2) Adjust the ssthresh and cwnd of the destination address(es) to
      which the missing DATA chunks were last sent, according to the
      formula described in Section 7.2.3.

   3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
      marked for retransmission will fit into a single packet, subject
      to constraint of the path MTU of the destination transport address
      to which the packet is being sent.  Call this value K. Retransmit
      those K DATA chunks in a single packet.

   4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
      outstanding TSN number sent to that address, or the endpoint is
      retransmitting the first outstanding DATA chunk sent to that
      address.

   Note: Before the above adjustments, if the received SACK also
   acknowledges new DATA chunks and advances the Cumulative TSN Ack
   Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
   must be applied first.

   A straightforward implementation of the above keeps a counter for
   each TSN hole reported by a SACK. The counter increments for each
   consecutive SACK reporting the TSN hole.  After reaching 4 and
   starting the fast retransmit procedure, the counter resets to 0.

Top      Up      ToC       Page 91 
   Because cwnd in SCTP indirectly bounds the number of outstanding
   TSN's, the effect of TCP fast-recovery is achieved automatically with
   no adjustment to the congestion control window size.

7.3 Path MTU Discovery

   [RFC1191] specifies "Path MTU Discovery", whereby an endpoint
   maintains an estimate of the maximum transmission unit (MTU) along a
   given Internet path and refrains from sending packets along that path
   which exceed the MTU, other than occasional attempts to probe for a
   change in the Path MTU (PMTU).  RFC 1191 is thorough in its
   discussion of the MTU discovery mechanism and strategies for
   determining the current end-to-end MTU setting as well as detecting
   changes in this value.  [RFC1981] specifies the same mechanisms for
   IPv6.  An SCTP sender using IPv6 MUST use Path MTU Discovery unless
   all packets are less than the minimum IPv6 MTU [RFC2460].

   An endpoint SHOULD apply these techniques, and SHOULD do so on a
   per-destination-address basis.

   There are 4 ways in which SCTP differs from the description in RFC
   1191 of applying MTU discovery to TCP:

   1) SCTP associations can span multiple addresses.  An endpoint MUST
      maintain separate MTU estimates for each destination address of
      its peer.

   2) Elsewhere in this document, when the term "MTU" is discussed, it
      refers to the MTU associated with the destination address
      corresponding to the context of the discussion.

   3) Unlike TCP, SCTP does not have a notion of "Maximum Segment Size".
      Accordingly, the MTU for each destination address SHOULD be
      initialized to a value no larger than the link MTU for the local
      interface to which packets for that remote destination address
      will be routed.

   4) Since data transmission in SCTP is naturally structured in terms
      of TSNs rather than bytes (as is the case for TCP), the discussion
      in Section 6.5 of RFC 1191 applies: When retransmitting an IP
      datagram to a remote address for which the IP datagram appears too
      large for the path MTU to that address, the IP datagram SHOULD be
      retransmitted without the DF bit set, allowing it to possibly be
      fragmented.  Transmissions of new IP datagrams MUST have DF set.

Top      Up      ToC       Page 92 
   5) The sender should track an association PMTU which will be the
      smallest PMTU discovered for all of the peer's destination
      addresses.  When fragmenting messages into multiple parts this
      association PMTU should be used to calculate the size of each
      fragment.  This will allow retransmissions to be seamlessly sent
      to an alternate address without encountering IP fragmentation.

   Other than these differences, the discussion of TCP's use of MTU
   discovery in RFCs 1191 and 1981 applies to SCTP on a per-
   destination-address basis.

   Note: For IPv6 destination addresses the DF bit does not exist,
   instead the IP datagram must be fragmented as described in [RFC2460].

8.  Fault Management

8.1 Endpoint Failure Detection

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (including retransmissions to all the
   destination transport addresses of the peer if it is multi-homed).
   If the value of this counter exceeds the limit indicated in the
   protocol parameter 'Association.Max.Retrans', the endpoint shall
   consider the peer endpoint unreachable and shall stop transmitting
   any more data to it (and thus the association enters the CLOSED
   state).  In addition, the endpoint shall report the failure to the
   upper layer, and optionally report back all outstanding user data
   remaining in its outbound queue. The association is automatically
   closed when the peer endpoint becomes unreachable.

   The counter shall be reset each time a DATA chunk sent to that peer
   endpoint is acknowledged (by the reception of a SACK), or a
   HEARTBEAT-ACK is received from the peer endpoint.

8.2 Path Failure Detection

   When its peer endpoint is multi-homed, an endpoint should keep a
   error counter for each of the destination transport addresses of the
   peer endpoint.

   Each time the T3-rtx timer expires on any address, or when a
   HEARTBEAT sent to an idle address is not acknowledged within a RTO,
   the error counter of that destination address will be incremented.
   When the value in the error counter exceeds the protocol parameter
   'Path.Max.Retrans' of that destination address, the endpoint should
   mark the destination transport address as inactive, and a
   notification SHOULD be sent to the upper layer.

Top      Up      ToC       Page 93 
   When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
   address is acknowledged with a HEARTBEAT ACK, the endpoint shall
   clear the error counter of the destination transport address to which
   the DATA chunk was last sent (or HEARTBEAT was sent).  When the peer
   endpoint is multi-homed and the last chunk sent to it was a
   retransmission to an alternate address, there exists an ambiguity as
   to whether or not the acknowledgement should be credited to the
   address of the last chunk sent.  However, this ambiguity does not
   seem to bear any significant consequence to SCTP behavior.  If this
   ambiguity is undesirable, the transmitter may choose not to clear the
   error counter if the last chunk sent was a retransmission.

   Note: When configuring the SCTP endpoint, the user should avoid
   having the value of 'Association.Max.Retrans' larger than the
   summation of the 'Path.Max.Retrans' of all the destination addresses
   for the remote endpoint.  Otherwise, all the destination addresses
   may become inactive while the endpoint still considers the peer
   endpoint reachable.  When this condition occurs, how the SCTP chooses
   to function is implementation specific.

   When the primary path is marked inactive (due to excessive
   retransmissions, for instance), the sender MAY automatically transmit
   new packets to an alternate destination address if one exists and is
   active.  If more than one alternate address is active when the
   primary path is marked inactive only ONE transport address SHOULD be
   chosen and used as the new destination transport address.

8.3 Path Heartbeat

   By default, an SCTP endpoint shall monitor the reachability of the
   idle destination transport address(es) of its peer by sending a
   HEARTBEAT chunk periodically to the destination transport
   address(es).

   A destination transport address is considered "idle" if no new chunk
   which can be used for updating path RTT (usually including first
   transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no
   HEARTBEAT has been sent to it within the current heartbeat period of
   that address.  This applies to both active and inactive destination
   addresses.

   The upper layer can optionally initiate the following functions:

   A) Disable heartbeat on a specific destination transport address of a
      given association,

   B) Change the HB.interval,

Top      Up      ToC       Page 94 
   C) Re-enable heartbeat on a specific destination transport address of
      a given association, and,

   D) Request an on-demand HEARTBEAT on a specific destination transport
      address of a given association.

   The endpoint should increment the respective error counter of the
   destination transport address each time a HEARTBEAT is sent to that
   address and not acknowledged within one RTO.

   When the value of this counter reaches the protocol parameter '
   Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

   The sender of the HEARTBEAT chunk should include in the Heartbeat
   Information field of the chunk the current time when the packet is
   sent out and the destination address to which the packet is sent.

   IMPLEMENTATION NOTE: An alternative implementation of the heartbeat
   mechanism that can be used is to increment the error counter variable
   every time a HEARTBEAT is sent to a destination.  Whenever a
   HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of
   the destination that the HEARTBEAT was sent to.  This in effect would
   clear the previously stroked error (and any other error counts as
   well).

   The receiver of the HEARTBEAT should immediately respond with a
   HEARTBEAT ACK that contains the Heartbeat Information field copied
   from the received HEARTBEAT chunk.

   Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
   should clear the error counter of the destination transport address
   to which the HEARTBEAT was sent, and mark the destination transport
   address as active if it is not so marked.  The endpoint may
   optionally report to the upper layer when an inactive destination
   address is marked as active due to the reception of the latest
   HEARTBEAT ACK.  The receiver of the HEARTBEAT ACK must also clear the
   association overall error count as well (as defined in section 8.1).

   The receiver of the HEARTBEAT ACK should also perform an RTT
   measurement for that destination transport address using the time
   value carried in the HEARTBEAT ACK chunk.

Top      Up      ToC       Page 95 
   On an idle destination address that is allowed to heartbeat, a
   HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
   destination address plus the protocol parameter 'HB.interval' , with
   jittering of +/- 50%, and exponential back-off of the RTO if the
   previous HEARTBEAT is unanswered.

   A primitive is provided for the SCTP user to change the HB.interval
   and turn on or off the heartbeat on a given destination address.  The
   heartbeat interval set by the SCTP user is added to the RTO of that
   destination (including any exponential backoff).  Only one heartbeat
   should be sent each time the heartbeat timer expires (if multiple
   destinations are idle).  It is a implementation decision on how to
   choose which of the candidate idle destinations to heartbeat to (if
   more than one destination is idle).

   Note: When tuning the heartbeat interval, there is a side effect that
   SHOULD be taken into account.  When this value is increased, i.e.
   the HEARTBEAT takes longer, the detection of lost ABORT messages
   takes longer as well.  If a peer endpoint ABORTs the association for
   any reason and the ABORT chunk is lost, the local endpoint will only
   discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk
   (thus causing the peer to send another ABORT).  This must be
   considered when tuning the HEARTBEAT timer.  If the HEARTBEAT is
   disabled only sending DATA to the association will discover a lost
   ABORT from the peer.

8.4 Handle "Out of the blue" Packets

   An SCTP packet is called an "out of the blue" (OOTB) packet if it is
   correctly formed, i.e., passed the receiver's Adler-32 check (see
   Section 6.8), but the receiver is not able to identify the
   association to which this packet belongs.

   The receiver of an OOTB packet MUST do the following:

   1) If the OOTB packet is to or from a non-unicast address, silently
      discard the packet.  Otherwise,

   2) If the OOTB packet contains an ABORT chunk, the receiver MUST
      silently discard the OOTB packet and take no further action.
      Otherwise,

   3) If the packet contains an INIT chunk with a Verification Tag set
      to '0', process it as described in Section 5.1.  Otherwise,

   4) If the packet contains a COOKIE ECHO in the first chunk, process
      it as described in Section 5.1.  Otherwise,

Top      Up      ToC       Page 96 
   5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
      respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
      When sending the SHUTDOWN COMPLETE, the receiver of the OOTB
      packet must fill in the Verification Tag field of the outbound
      packet with the Verification Tag received in the SHUTDOWN ACK and
      set the T-bit in the Chunk Flags to indicate that no TCB was
      found. Otherwise,

   6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
      should silently discard the packet and take no further action.
      Otherwise,

   7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the
      SCTP Packet should be silently discarded.  Otherwise,

   8) The receiver should respond to the sender of the OOTB packet with
      an ABORT.  When sending the ABORT, the receiver of the OOTB packet
      MUST fill in the Verification Tag field of the outbound packet
      with the value found in the Verification Tag field of the OOTB
      packet and set the T-bit in the Chunk Flags to indicate that no
      TCB was found.  After sending this ABORT, the receiver of the OOTB
      packet shall discard the OOTB packet and take no further action.

8.5 Verification Tag

   The Verification Tag rules defined in this section apply when sending
   or receiving SCTP packets which do not contain an INIT, SHUTDOWN
   COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk.
   The rules for sending and receiving SCTP packets containing one of
   these chunk types are discussed separately in Section 8.5.1.

   When sending an SCTP packet, the endpoint MUST fill in the
   Verification Tag field of the outbound packet with the tag value in
   the Initiate Tag parameter of the INIT or INIT ACK received from its
   peer.

   When receiving an SCTP packet, the endpoint MUST ensure that the
   value in the Verification Tag field of the received SCTP packet
   matches its own Tag.  If the received Verification Tag value does not
   match the receiver's own tag value, the receiver shall silently
   discard the packet and shall not process it any further except for
   those cases listed in Section 8.5.1 below.

Top      Up      ToC       Page 97 
8.5.1 Exceptions in Verification Tag Rules

   A) Rules for packet carrying INIT:

      -  The sender MUST set the Verification Tag of the packet to 0.

      -  When an endpoint receives an SCTP packet with the Verification
         Tag set to 0, it should verify that the packet contains only an
         INIT chunk.  Otherwise, the receiver MUST silently discard the
         packet.

   B) Rules for packet carrying ABORT:

      -  The endpoint shall always fill in the Verification Tag field of
         the outbound packet with the destination endpoint's tag value
         if it is known.

      -  If the ABORT is sent in response to an OOTB packet, the
         endpoint MUST follow the procedure described in Section 8.4.

      -  The receiver MUST accept the packet if the Verification Tag
         matches either its own tag, OR the tag of its peer.  Otherwise,
         the receiver MUST silently discard the packet and take no
         further action.

   C) Rules for packet carrying SHUTDOWN COMPLETE:

      -  When sending a SHUTDOWN COMPLETE, if the receiver of the
         SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
         be used.  Only where no TCB exists should the sender use the
         Verification Tag from the SHUTDOWN ACK.

      -  The receiver of a SHUTDOWN COMPLETE shall accept the packet if
         the Verification Tag field of the packet matches its own tag OR
         it is set to its peer's tag and the T bit is set in the Chunk
         Flags. Otherwise, the receiver MUST silently discard the packet
         and take no further action.  An endpoint MUST ignore the
         SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.

   D) Rules for packet carrying a COOKIE ECHO

      -  When sending a COOKIE ECHO, the endpoint MUST use the value of
         the Initial Tag received in the INIT ACK.

      -  The receiver of a COOKIE ECHO follows the procedures in Section
         5.

Top      Up      ToC       Page 98 
   E) Rules for packet carrying a SHUTDOWN ACK

      -  If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the
         procedures in section 8.4 SHOULD be followed, in other words it
         should be treated as an Out Of The Blue packet.

9. Termination of Association

   An endpoint should terminate its association when it exits from
   service.  An association can be terminated by either abort or
   shutdown.  An abort of an association is abortive by definition in
   that any data pending on either end of the association is discarded
   and not delivered to the peer.  A shutdown of an association is
   considered a graceful close where all data in queue by either
   endpoint is delivered to the respective peers.  However, in the case
   of a shutdown, SCTP does not support a half-open state (like TCP)
   wherein one side may continue sending data while the other end is
   closed.  When either endpoint performs a shutdown, the association on
   each peer will stop accepting new data from its user and only deliver
   data in queue at the time of sending or receiving the SHUTDOWN chunk.

9.1 Abort of an Association

   When an endpoint decides to abort an existing association, it shall
   send an ABORT chunk to its peer endpoint.  The sender MUST fill in
   the peer's Verification Tag in the outbound packet and MUST NOT
   bundle any DATA chunk with the ABORT.

   An endpoint MUST NOT respond to any received packet that contains an
   ABORT chunk (also see Section 8.4).

   An endpoint receiving an ABORT shall apply the special Verification
   Tag check rules described in Section 8.5.1.

   After checking the Verification Tag, the receiving endpoint shall
   remove the association from its record, and shall report the
   termination to its upper layer.

9.2 Shutdown of an Association

   Using the SHUTDOWN primitive (see Section 10.1), the upper layer of
   an endpoint in an association can gracefully close the association.
   This will allow all outstanding DATA chunks from the peer of the
   shutdown initiator to be delivered before the association terminates.

   Upon receipt of the SHUTDOWN primitive from its upper layer, the
   endpoint enters SHUTDOWN-PENDING state and remains there until all
   outstanding data has been acknowledged by its peer.  The endpoint

Top      Up      ToC       Page 99 
   accepts no new data from its upper layer, but retransmits data to the
   far end if necessary to fill gaps.

   Once all its outstanding data has been acknowledged, the endpoint
   shall send a SHUTDOWN chunk to its peer including in the Cumulative
   TSN Ack field the last sequential TSN it has received from the peer.
   It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT
   state.  If the timer expires, the endpoint must re-send the SHUTDOWN
   with the updated last sequential TSN received from its peer.

   The rules in Section 6.3 MUST be followed to determine the proper
   timer value for T2-shutdown.  To indicate any gaps in TSN, the
   endpoint may also bundle a SACK with the SHUTDOWN chunk in the same
   SCTP packet.

   An endpoint should limit the number of retransmissions of the
   SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
   If this threshold is exceeded the endpoint should destroy the TCB and
   MUST report the peer endpoint unreachable to the upper layer (and
   thus the association enters the CLOSED state).  The reception of any
   packet from its peer (i.e. as the peer sends all of its queued DATA
   chunks) should clear the endpoint's retransmission count and restart
   the T2-Shutdown timer,  giving its peer ample opportunity to transmit
   all of its queued DATA chunks that have not yet been sent.

   Upon the reception of the SHUTDOWN, the peer endpoint shall

   -  enter the SHUTDOWN-RECEIVED state,

   -  stop accepting new data from its SCTP user

   -  verify, by checking the Cumulative TSN Ack field of the chunk,
      that all its outstanding DATA chunks have been received by the
      SHUTDOWN sender.

   Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT
   send a SHUTDOWN in response to a ULP request, and should discard
   subsequent SHUTDOWN chunks.

   If there are still outstanding DATA chunks left, the SHUTDOWN
   receiver shall continue to follow normal data transmission procedures
   defined in Section 6 until all outstanding DATA chunks are
   acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
   from its SCTP user.

   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
   respond to each received packet containing one or more DATA chunk(s)
   with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If

Top      Up      ToC       Page 100 
   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
   endpoint must re-send the SHUTDOWN ACK.

   The sender of the SHUTDOWN ACK should limit the number of
   retransmissions of the SHUTDOWN ACK chunk to the protocol parameter '
   Association.Max.Retrans'.  If this threshold is exceeded the endpoint
   should destroy the TCB and may report the peer endpoint unreachable
   to the upper layer (and thus the association enters the CLOSED
   state).

   Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop
   the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer,
   and remove all record of the association.

   Upon reception of the SHUTDOWN COMPLETE chunk the endpoint will
   verify that it is in SHUTDOWN-ACK-SENT state, if it is not the chunk
   should be discarded.  If the endpoint is in the SHUTDOWN-ACK-SENT
   state the endpoint should stop the T2-shutdown timer and remove all
   knowledge of the association (and thus the association enters the
   CLOSED state).

   An endpoint SHOULD assure that all its outstanding DATA chunks have
   been acknowledged before initiating the shutdown procedure.

   An endpoint should reject any new data request from its upper layer
   if it is in SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or
   SHUTDOWN-ACK-SENT state.

   If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT
   chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and
   destination transport addresses (either in the IP addresses or in the
   INIT chunk) that belong to this association, it should discard the
   INIT chunk and retransmit the SHUTDOWN ACK chunk.

   Note: Receipt of an INIT with the same source and destination IP
   addresses as used in transport addresses assigned to an endpoint but
   with a different port number indicates the initialization of a
   separate association.

   The sender of the INIT or COOKIE ECHO should respond to the receipt
   of a SHUTDOWN-ACK with a stand-alone SHUTDOWN COMPLETE in an SCTP
   packet with the Verification Tag field of its common header set to
   the same tag that was received in the SHUTDOWN ACK packet.  This is
   considered an Out of the Blue packet as defined in Section 8.4.  The
   sender of the INIT lets T1-init continue running and remains in the

Top      Up      ToC       Page 101 
   COOKIE-WAIT or COOKIE-ECHOED state.  Normal T1-init timer expiration
   will cause the INIT or COOKIE chunk to be retransmitted and thus
   start a new association.

   If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the
   SHUTDOWN chunk SHOULD be silently discarded.

   If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN
   chunk from its peer, the endpoint shall respond immediately with a
   SHUTDOWN ACK to its peer, and move into a SHUTDOWN-ACK-SENT state
   restarting its T2-shutdown timer.

   If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a
   SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN
   COMPLETE chunk to its peer, and remove all record of the association.

10. Interface with Upper Layer

   The Upper Layer Protocols (ULP) shall request for services by passing
   primitives to SCTP and shall receive notifications from SCTP for
   various events.

   The primitives and notifications described in this section should be
   used as a guideline for implementing SCTP.  The following functional
   description of ULP interface primitives is shown for illustrative
   purposes.  Different SCTP implementations may have different ULP
   interfaces.  However, all SCTPs must provide a certain minimum set of
   services to guarantee that all SCTP implementations can support the
   same protocol hierarchy.

10.1 ULP-to-SCTP

   The following sections functionally characterize a ULP/SCTP
   interface.  The notation used is similar to most procedure or
   function calls in high level languages.

   The ULP primitives described below specify the basic functions the
   SCTP must perform to support inter-process communication.  Individual
   implementations must define their own exact format, and may provide
   combinations or subsets of the basic functions in single calls.

   A) Initialize

   Format: INITIALIZE ([local port], [local eligible address list]) ->
   local SCTP instance name

Top      Up      ToC       Page 102 
   This primitive allows SCTP to initialize its internal data structures
   and allocate necessary resources for setting up its operation
   environment.  Once SCTP is initialized, ULP can communicate directly
   with other endpoints without re-invoking this primitive.

   SCTP will return a local SCTP instance name to the ULP.

   Mandatory attributes:

   None.

   Optional attributes:

   The following types of attributes may be passed along with the
   primitive:

   o  local port - SCTP port number, if ULP wants it to be specified;

   o  local eligible address list - An address list that the local SCTP
      endpoint should bind.  By default, if an address list is not
      included, all IP addresses assigned to the host should be used by
      the local endpoint.

   IMPLEMENTATION NOTE: If this optional attribute is supported by an
   implementation, it will be the responsibility of the implementation
   to enforce that the IP source address field of any SCTP packets sent
   out by this endpoint contains one of the IP addresses indicated in
   the local eligible address list.

   B) Associate

   Format: ASSOCIATE(local SCTP instance name, destination transport addr,
           outbound stream count)
   -> association id [,destination transport addr list] [,outbound stream
      count]

   This primitive allows the upper layer to initiate an association to a
   specific peer endpoint.

   The peer endpoint shall be specified by one of the transport
   addresses which defines the endpoint (see Section 1.4).  If the local
   SCTP instance has not been initialized, the ASSOCIATE is considered
   an error.

   An association id, which is a local handle to the SCTP association,
   will be returned on successful establishment of the association.  If
   SCTP is not able to open an SCTP association with the peer endpoint,
   an error is returned.

Top      Up      ToC       Page 103 
   Other association parameters may be returned, including the complete
   destination transport addresses of the peer as well as the outbound
   stream count of the local endpoint.  One of the transport address
   from the returned destination addresses will be selected by the local
   endpoint as default primary path for sending SCTP packets to this
   peer.  The returned "destination transport addr list" can be used by
   the ULP to change the default primary path or to force sending a
   packet to a specific transport address.

   IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
   blocking function call, the ASSOCIATE primitive can return
   association parameters in addition to the association id upon
   successful establishment.  If ASSOCIATE primitive is implemented as a
   non-blocking call, only the association id shall be returned and
   association parameters shall be passed using the COMMUNICATION UP
   notification.

   Mandatory attributes:

   o  local SCTP instance name - obtained from the INITIALIZE operation.

   o  destination transport addr - specified as one of the transport
      addresses of the peer endpoint with which the association is to be
      established.

   o  outbound stream count - the number of outbound streams the ULP
      would like to open towards this peer endpoint.

   Optional attributes:

   None.

   C) Shutdown

   Format: SHUTDOWN(association id)
   -> result

   Gracefully closes an association.  Any locally queued user data will
   be delivered to the peer.  The association will be terminated only
   after the peer acknowledges all the SCTP packets sent.  A success
   code will be returned on successful termination of the association.
   If attempting to terminate the association results in a failure, an
   error code shall be returned.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

Top      Up      ToC       Page 104 
   Optional attributes:

   None.

   D) Abort

   Format: ABORT(association id [, cause code])
   -> result

   Ungracefully closes an association.  Any locally queued user data
   will be discarded and an ABORT chunk is sent to the peer.  A success
   code will be returned on successful abortion of the association.  If
   attempting to abort the association results in a failure, an error
   code shall be returned.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   Optional attributes:

   o  cause code - reason of the abort to be passed to the peer.

   None.

   E) Send

   Format: SEND(association id, buffer address, byte count [,context]
           [,stream id] [,life time] [,destination transport address]
           [,unorder flag] [,no-bundle flag] [,payload protocol-id] )
   -> result

   This is the main method to send user data via SCTP.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  buffer address - the location where the user message to be
      transmitted is stored;

   o  byte count - The size of the user data in number of bytes;

   Optional attributes:

   o  context - an optional 32 bit integer that will be carried in the
      sending failure notification to the ULP if the transportation of
      this User Message fails.

Top      Up      ToC       Page 105 
   o  stream id - to indicate which stream to send the data on.  If not
      specified, stream 0 will be used.

   o  life time - specifies the life time of the user data.  The user
      data will not be sent by SCTP after the life time expires.  This
      parameter can be used to avoid efforts to transmit stale user
      messages.  SCTP notifies the ULP if the data cannot be initiated
      to transport (i.e. sent to the destination via SCTP's send
      primitive) within the life time variable.  However, the user data
      will be transmitted if SCTP has attempted to transmit a chunk
      before the life time expired.

   IMPLEMENTATION NOTE: In order to better support the data lifetime
   option, the transmitter may hold back the assigning of the TSN number
   to an outbound DATA chunk to the last moment.  And, for
   implementation simplicity, once a TSN number has been assigned the
   sender should consider the send of this DATA chunk as committed,
   overriding any lifetime option attached to the DATA chunk.

   o  destination transport address - specified as one of the
      destination transport addresses of the peer endpoint to which this
      packet should be sent.  Whenever possible, SCTP should use this
      destination transport address for sending the packets, instead of
      the current primary path.

   o  unorder flag - this flag, if present, indicates that the user
      would like the data delivered in an unordered fashion to the peer
      (i.e., the U flag is set to 1 on all DATA chunks carrying this
      message).

   o  no-bundle flag - instructs SCTP not to bundle this user data with
      other outbound DATA chunks.  SCTP MAY still bundle even when this
      flag is present, when faced with network congestion.

   o  payload protocol-id - A 32 bit unsigned integer that is to be
      passed to the peer indicating the type of payload protocol data
      being transmitted.  This value is passed as opaque data by SCTP.

   F) Set Primary

   Format: SETPRIMARY(association id, destination transport address,
                      [source transport address] )
   -> result

   Instructs the local SCTP to use the specified destination transport
   address as primary path for sending packets.

Top      Up      ToC       Page 106 
   The result of attempting this operation shall be returned.  If the
   specified destination transport address is not present in the
   "destination transport address list" returned earlier in an associate
   command or communication up notification, an error shall be returned.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  destination transport address - specified as one of the transport
      addresses of the peer endpoint, which should be used as primary
      address for sending packets.  This overrides the current primary
      address information maintained by the local SCTP endpoint.

   Optional attributes:

   o  source transport address - optionally, some implementations may
      allow you to set the default source address placed in all outgoing
      IP datagrams.

   G) Receive

   Format: RECEIVE(association id, buffer address, buffer size
           [,stream id])
   -> byte count [,transport address] [,stream id] [,stream sequence
      number] [,partial flag] [,delivery number] [,payload protocol-id]

   This primitive shall read the first user message in the SCTP in-queue
   into the buffer specified by ULP, if there is one available.  The
   size of the message read, in bytes, will be returned.  It may,
   depending on the specific implementation, also return other
   information such as the sender's address, the stream id on which it
   is received, whether there are more messages available for retrieval,
   etc.  For ordered messages, their stream sequence number may also be
   returned.

   Depending upon the implementation, if this primitive is invoked when
   no message is available the implementation should return an
   indication of this condition or should block the invoking process
   until data does become available.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  buffer address - the memory location indicated by the ULP to store
      the received message.

Top      Up      ToC       Page 107 
   o  buffer size - the maximum size of data to be received, in bytes.

   Optional attributes:

   o  stream id - to indicate which stream to receive the data on.

   o  stream sequence number - the stream sequence number assigned by
      the sending SCTP peer.

   o  partial flag - if this returned flag is set to 1, then this
      Receive contains  a partial delivery of the whole message.  When
      this flag is set, the stream id and stream sequence number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this stream sequence
      number.

   o  payload protocol-id - A 32 bit unsigned integer that is received
      from the peer indicating the type of payload protocol of the
      received data.  This value is passed as opaque data by SCTP.

   H) Status

   Format: STATUS(association id)
   -> status data

   This primitive should return a data block containing the following
   information:
     association connection state,
     destination transport address list,
     destination transport address reachability states,
     current receiver window size,
     current congestion window sizes,
     number of  unacknowledged DATA chunks,
     number of DATA chunks pending receipt,
     primary path,
     most recent SRTT on primary path,
     RTO on primary path,
     SRTT and RTO on other destination addresses, etc.

   Mandatory attributes:

   o association id - local handle to the SCTP association

   Optional attributes:

    None.

Top      Up      ToC       Page 108 
   I) Change Heartbeat

   Format: CHANGEHEARTBEAT(association id, destination transport address,
           new state [,interval])
   -> result

   Instructs the local endpoint to enable or disable heartbeat on the
   specified destination transport address.

   The result of attempting this operation shall be returned.

   Note: Even when enabled, heartbeat will not take place if the
   destination transport address is not idle.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  destination transport address - specified as one of the transport
      addresses of the peer endpoint.

   o  new state - the new state of heartbeat for this destination
      transport address (either enabled or disabled).

   Optional attributes:

   o  interval - if present, indicates the frequency of the heartbeat if
      this is to enable heartbeat on a destination transport address.
      This value is added to the RTO of the destination transport
      address. This value, if present, effects all destinations.

   J) Request HeartBeat

   Format: REQUESTHEARTBEAT(association id, destination transport
           address)
   -> result

   Instructs the local endpoint to perform a HeartBeat on the specified
   destination transport address of the given association.  The returned
   result should indicate whether the transmission of the HEARTBEAT
   chunk to the destination address is successful.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  destination transport address - the transport address of the
      association on which a heartbeat should be issued.

Top      Up      ToC       Page 109 
   K) Get SRTT Report

   Format: GETSRTTREPORT(association id, destination transport address)
   -> srtt result

   Instructs the local SCTP to report the current SRTT measurement on
   the specified destination transport address of the given association.
   The returned result can be an integer containing the most recent SRTT
   in milliseconds.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  destination transport address - the transport address of the
      association on which the SRTT measurement is to be reported.

   L) Set Failure Threshold

   Format: SETFAILURETHRESHOLD(association id, destination transport
           address, failure threshold)
   -> result

   This primitive allows the local SCTP to customize the reachability
   failure detection threshold 'Path.Max.Retrans' for the specified
   destination address.

   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  destination transport address - the transport address of the
      association on which the failure detection threshold is to be set.

   o  failure threshold - the new value of 'Path.Max.Retrans' for the
      destination address.

   M) Set Protocol Parameters

   Format: SETPROTOCOLPARAMETERS(association id, [,destination transport
           address,] protocol parameter list)
   -> result

   This primitive allows the local SCTP to customize the protocol
   parameters.

Top      Up      ToC       Page 110 
   Mandatory attributes:

   o  association id - local handle to the SCTP association

   o  protocol parameter list - The specific names and values of the
      protocol parameters (e.g., Association.Max.Retrans [see Section
      14]) that the SCTP user wishes to customize.

   Optional attributes:

   o  destination transport address - some of the protocol parameters
      may be set on a per destination transport address basis.

   N) Receive unsent message

   Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
           [,stream id] [, stream sequence number] [,partial flag]
           [,payload protocol-id])

   o  data retrieval id - The identification passed to the ULP in the
      failure notification.

   o  buffer address - the memory location indicated by the ULP to store
      the received message.

   o  buffer size - the maximum size of data to be received, in bytes.

   Optional attributes:

   o  stream id - this is a return value that is set to  indicate
      which stream the data was sent to.

   o  stream sequence number - this value is returned indicating
      the stream sequence number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When
      this flag is set, the stream id and stream sequence number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this stream sequence
      number.

   o  payload protocol-id - The 32 bit unsigned integer that was sent to
      be sent to the peer indicating the type of payload protocol of the
      received data.

Top      Up      ToC       Page 111 
   O)  Receive unacknowledged message

   Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,
           [,stream id] [, stream sequence number] [,partial flag]
           [,payload protocol-id])

   o  data retrieval id - The identification passed to the ULP in the
      failure notification.

   o  buffer address - the memory location indicated by the ULP to store
      the received message.

   o  buffer size - the maximum size of data to be received, in bytes.

   Optional attributes:

   o  stream id - this is a return value that is set to  indicate which
      stream the data was sent to.

   o  stream sequence number - this value is returned indicating the
      stream sequence number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When this
      flag is set, the stream id and stream sequence number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this stream sequence
      number.

   o  payload protocol-id - The 32 bit unsigned integer that was sent to
      be sent to the peer indicating the type of payload protocol of the
      received data.

   P) Destroy SCTP instance

   Format: DESTROY(local SCTP instance name)

   o  local SCTP instance name - this is the value that was passed to
      the application in the initialize primitive and it indicates which
      SCTP instance to be destroyed.

10.2 SCTP-to-ULP

   It is assumed that the operating system or application environment
   provides a means for the SCTP to asynchronously signal the ULP
   process.  When SCTP does signal an ULP process, certain information
   is passed to the ULP.

Top      Up      ToC       Page 112 
   IMPLEMENTATION NOTE: In some cases this may be done through a
   separate socket or error channel.

   A) DATA ARRIVE notification

   SCTP shall invoke this notification on the ULP when a user message is
   successfully received and ready for retrieval.

   The following may be optionally be passed with the notification:

   o  association id - local handle to the SCTP association

   o  stream id - to indicate which stream the data is received on.

   B) SEND FAILURE notification

   If a message can not be delivered SCTP shall invoke this notification
   on the ULP.

   The following may be optionally be passed with the notification:

   o  association id - local handle to the SCTP association

   o  data retrieval id - an identification used to retrieve unsent and
      unacknowledged data.

   o  cause code - indicating the reason of the failure, e.g., size too
      large, message life-time expiration, etc.

   o  context - optional information associated with this message (see D
      in Section 10.1).

   C) NETWORK STATUS CHANGE notification

   When a destination transport address is marked inactive (e.g., when
   SCTP detects a failure), or marked active (e.g., when SCTP detects a
   recovery), SCTP shall invoke this notification on the ULP.

   The following shall be passed with the notification:

   o  association id - local handle to the SCTP association

   o  destination transport address - This indicates the destination
      transport address of the peer endpoint affected by the change;

   o  new-status - This indicates the new status.

Top      Up      ToC       Page 113 
   D) COMMUNICATION UP notification

   This notification is used when SCTP becomes ready to send or receive
   user messages, or when a lost communication to an endpoint is
   restored.

   IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
   blocking function call, the association parameters are returned as a
   result of the ASSOCIATE primitive itself.  In that case,
   COMMUNICATION UP notification is optional at the association
   initiator's side.

   The following shall be passed with the notification:

   o  association id - local handle to the SCTP association

   o  status - This indicates what type of event has occurred

   o  destination transport address list - the complete set of transport
      addresses of the peer

   o  outbound stream count - the maximum number of streams allowed to
      be used in this association by the ULP

   o  inbound stream count - the number of streams the peer endpoint has
      requested with this association (this may not be the same number
      as 'outbound stream count').

   E) COMMUNICATION LOST notification

   When SCTP loses communication to an endpoint completely (e.g., via
   Heartbeats) or detects that the endpoint has performed an abort
   operation, it shall invoke this notification on the ULP.

   The following shall be passed with the notification:

   o  association id - local handle to the SCTP association

   o status - This indicates what type of event has occurred; The status
              may indicate a failure OR a normal termination event
              occurred in response to a shutdown or abort request.

   The following may be passed with the notification:

   o  data retrieval id - an identification used to retrieve unsent and
      unacknowledged data.

   o  last-acked - the TSN last acked by that peer endpoint;

Top      Up      ToC       Page 114 
   o  last-sent - the TSN last sent to that peer endpoint;

   F) COMMUNICATION ERROR notification

   When SCTP receives an ERROR chunk from its peer and decides to notify
   its ULP, it can invoke this notification on the ULP.

   The following can be passed with the notification:

   o  association id - local handle to the SCTP association

   o  error info - this indicates the type of error and optionally some
      additional information received through the ERROR chunk.

   G) RESTART notification

   When SCTP detects that the peer has restarted, it may send this
   notification to its ULP.

   The following can be passed with the notification:

   o  association id - local handle to the SCTP association

   H) SHUTDOWN COMPLETE notification

   When SCTP completes the shutdown procedures (section 9.2) this
   notification is passed to the upper layer.

   The following can be passed with the notification:

   o  association id - local handle to the SCTP association



(page 114 continued on part 5)

Next RFC Part