Internet DRAFT - draft-ahmed-lssctp

draft-ahmed-lssctp







Internet Engineering Task Force                             A. Abd El Al
INTERNET-DRAFT                                                T. Saadawi
Expires: October 2005                                             M. Lee 
 					               City University of New York
                                                               May, 2005


 	    Load Sharing in Stream Control Transmission Protocol
                     <draft-ahmed-lssctp-01.txt>


Status of this memo

    By submitting this Internet-Draft, each author represents that
    any applicable patent or other IPR claims of which he or she is
    aware have been or will be disclosed, and any of which he or she
    becomes aware will be disclosed, in accordance with Section 6 of
    BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html


Abstract

   Stream Control Transmission Protocol (SCTP) RFC2960 [SXM00] 
   specifications utilize the possible multiple paths between the 
   sender and receiver for retransmission of lost data chunks and as a 
   backup for the primary path, in case of primary path failure. 
   Other than that, all the data chunks are being sent on the primary 
   path chosen by the SCTP user during the association initiation. 
   This memo describes an extension to SCTP that allows endpoints to 
   use the multiple available paths for simultaneous data transmission. 
   The extension maintains SCTP congestion control on each path, so as 
   to ensure fair integration with other traffic in the network. 






Abd El Al, et al.                                               [Page 1]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


Table of Contents

  1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  1.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3
  1.2 Overview of LS-SCTP . . . . . . . . . . . . . . . . . . . . . . 3
  1.3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  1.4 Architectural View of LS-SCTP . . . . . . . . . . . . . . . . . 4  
  2. Conventions  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  3. Protocol Changes to support LS-SCTP  . . . . . . . . . . . . . . 5
  3.1 Load-Sharing-Supported Parameter for INIT and INIT-ACK  . . . . 5
  3.2 Initial-PSN (I-PSN) Parameter for COOKIE-ECHO and COOKIE-ACK  . 6  
  3.3 LS-SCTP Data chunk (LS-DATA)  . . . . . . . . . . . . . . . .   7
  3.4 LS-SCTP Selective Acknowledgement (LS-SACK) . . . . . . . . .  10 
  3.5 Negotiation of Load-Sharing-Supported parameter . . . . . . .  13
  3.5.1 Sending Load-Sharing-Supported param in INIT  . . . . . . .  13
  3.5.2 Receipt of Load-Sharing-Supported param in INIT or INIT-ACK  13
  3.5.3 Receipt of Op. Error for Load-Sharing-Supported Param . . .  14
  3.6 Exchanging Initial-PSN Param in the COOKIE-ECHO and 
      COOKIE-ACK  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  3.7 Sender Side Implementation of PR-SCTP . . . . . . . . . . . .  15
  3.7.1 Transmission of DATA Chunks . . . . . . . . . . . . . . . .  17
  3.7.2 Path MTU Discovery  . . . . . . . . . . . . . . . . . . . .  17
  3.7.3 Fragmentation  and Reassembly . . . . . . . . . . . . . . .  17
  3.7.4 Path Decision  .  . . . . . . . . . . . . . . . . . . . . .  18
  3.7.5 Distributing Data Chunks on Association Paths . . . . . . .  18
  3.7.6 Processing Received LS-SACK . . . . . . . . . . . . . . . .  19
  3.7.7 Re-transmitting Data Chunks   . . . . . . . . . . . . . . .  20
  3.7.8 Inactive Destination Address  . . . . . . . . . . . . . . .  20
  3.7.9 Bundling .  . . . . . . . . . . . . . . . . . . . . . . . .  20
  3.8 Receiver Side Implementation of PR-SCTP . . . . . . . . . . .  21
  3.8.1 Acknowledgement on Reception of DATA Chunks . . . . . . . .  23
  3.8.2 DATA Chunks Delivery to ULP . . . . . . . . . . . . . . . .  24
  4. Termination of Association . . . . . . . . . . . . . . . . . .  24 
  5. Security Considerations  . . . . . . . . . . . . . . . . . . .  25
  6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  26
  6.1 Chunk Extension . . . . . . . . . . . . . . . . . . . . . . .  26
  6.2 Chunk Parameter Extension   . . . . . . . . . . . . . . . . .  26
      References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
      Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .  27
      Full Copyright Statement  . . . . . . . . . . . . . . . . . .  29















Abd El Al, et al.                                               [Page 2]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


1. Introduction

   This memo describes an extension to the Stream Control Transmission
   Protocol (SCTP) RFC2960 [SXM00] that allows SCTP endpoints to utilize 
   the available multiple paths for simultaneous transmission of data 
   chunks, while maintaining the SCTP congestion control on each path, 
   so as to ensure fair integration with other traffic in the network. 
   This sort of resource aggregation was used at different layers of 
   the  protocol stack to achieve higher throughput [BTS95]. We believe 
   that the increase in the SCTP throughput provided by bandwidth 
   aggregation can be extremely beneficial for wireless networks, with 
   limited bandwidth and high loss rate. The extension is flexible, as 
   it allows the SCTP sender to allocate different data streams, within
   an association, to different paths. In addition, it allows 
   distributing the data chunks of one stream among multiple paths, 
   then the receiver reorders those chunks before delivering them to 
   the upper layer.

1.1 Abbreviations

   ASN       - Association Sequence Number
   IANA      - Internet Assigned Numbers Authority
   I-ASN     - Initial - Association Sequence Number
   IETF      - Internet Engineering Task Force
   IP        - Internet Protocol
   I-PSN     - Initial - Path Sequence Number
   LS-Data   - Load Sharing - Data
   LS-SACK   - Load Sharing - Selective Acknowledgement
   LS-SCTP   - Load Sharing - Stream Control Transmission Protocol
   MTU       - Maximum Transfer Unit
   PID       - Path Identifier
   PMTU      - Path Maximum Transfer Unit
   PSN       - Path Sequence Number
   QoS       - Quality of Service
   RFC       - Request For Comments
   SACK      - Selective Acknowledgement  
   SCTP      - Stream Control Transmission Protocol
   TCP       - Transmission Control Protocol
   ULP       - Upper Layer Application


1.2 Overview of LS-SCTP

   Hereafter, we use the notation "LS-SCTP" to refer to the SCTP
   protocol extended as defined in this document. Also, we use the 
   notation ˘Non LS-SCTP÷ to refer to the SCTP protocol as defined 
   RFC2960 [SXM00].

   


Abd El Al, et al.                                               [Page 3]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   The protocol extension described in this document consists of two 
   new elements:

   1.  A single new parameter in the INIT/INIT-ACK exchange that
     	 indicates whether the endpoint supports the extension

   2.  Two new chunk types. The first is a new Data Chunk, 
       LOAD SHARING DATA Chunk, used for sending data from the sender 
       endpoint to the  receiver endpoint. The second is a new SACK 
       chunk, LOAD SHARING SACK Chunk, used to provide selective 
       acknowledgement to the sender on a per path basis.

1.3 Motivations

   Our motivations to extend SCTP for load sharing are:

   1.	The increase in the number of multi-homed wireless devices that 
      can be simultaneously connected to different networks through  
      different interfaces.

   2.	By aggregating the bandwidth available on the different paths, 
      applications can gain higher throughput, as shown in [ASLJ04]
      [ASLD04]. We believe that this will be extremely important for 
      networks with limited bandwidth and high error rate.

   3.	SCTP is more attractive for load sharing than other transport 
      protocols such as TCP. As multi-homing is inherently a part of 
      the SCTP, extending SCTP to support load sharing will be easier 
      than TCP. Each TCP connection (Socket) can only send data to one 
      destination interface, thus extending TCP for load sharing will 
      require an overhead in establishing, monitoring and terminating 
      the multiple TCP sockets. In addition, implementing load sharing  
      in SCTP will provide the applications with the SCTP features that  
      do not exist in TCP such as, multi-streaming [AA01], transmission  
      paths monitoring through heartbeats control chunks, and protection 
      against denial of service attacks using the cookies concept [SXM00]. 

1.4 Architectural View of LS-SCTP

   The LS-SCTP is based on the idea of separating the association flow 
   control from congestion control. In LS-SCTP the flow control is 
   on association basis, thus both the sender and receiver endpoints  
   use their association buffer to hold the data chunks regardless
   the path on which these data chunks will be sent or received.
   On the other hand, congestion control is performed on per path basis, 
   thus the sender will have a separate congestion control for each 
   path, and these congestion control mechanisms can be used 
   simultaneously for the data chunks to be transmitted on the paths.



Abd El Al, et al.                                               [Page 4]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005

 
   Thus we can say that the  sender endpoint has a virtual congestion
   window (cwnd) size equal to the aggregate of the cwnds of all the 
   paths within the association, that are currently being used for load
   sharing. The congestion control mechanism on each path is following
   RFC2960[SXM00], section 7, so as to insure fair integration with other
   traffic in the network. 

   In order to separate the flow control from the congestion control, 
   LS-STCP uses two different sequence numbers. The first sequence 
   number is the Association Sequence Number (ASN), that is a per 
   association sequence number, and it is used to reorder the received 
   data chunks at the receiver association buffer, regardless the path 
   from which they have been received. The second sequence number is 
   the Path Sequence Number (PSN) which is a per path sequence number 
   used for reliability and congestion control on each path.


          -------------------------------------------------
         |           Association Flow Control              |
         |                                                 | 
          -------------------------------------------------  
              |                 |                      |
        -------------     -------------           -------------            
       | Congestion  |   | Congestion  |         | Congestion  |  
       |   Control   |   |   Control   |         |   Control   |        
       |    for      |   |    for      | . . . . |    for      |    
       |    Path     |   |    Path     |         |    Path     |             
       |     #1      |   |     #2      |         |     #N      | 
        -------------     -------------           ------------- 

                  Figure 1: Architectural View of LS-SCTP


2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC2119 [RFC2199].


3. Protocol Changes to support LS-SCTP

3.1 Load-Sharing-Supported Parameter for INIT and INIT-ACK

   The following new OPTIONAL parameter is added to the INIT and 
   INIT-ACK chunks.




Abd El Al, et al.                                               [Page 5]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


      Parameter Name                       Status     Type Value
       -------------------------------------------------------------
       Load-Sharing-Supported               OPTIONAL    0xC001

   At the initialization of the association, the sender of the INIT or
   INIT-ACK chunk shall include this OPTIONAL parameter to inform its
   peer that it is able to support Load Sharing.  The format of this 
   parameter is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Parameter Type = 0xC001    |  Parameter Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type: 16 bit u_int

          0xC001, indicating Load-Sharing-Supported parameter

       Length: 16 bit u_int

          Indicate the size of the parameter i.e. 4.


3.2 Initial-PSN (I-PSN) Parameter for COOKIE-ECHO and COOKIE-ACK

      Defines a new OPTIONAL Initial PSN parameter that the 
      COOKIE-ECHO/COOKIE-ACK sender will use to indicate the initial 
      PSN that the sender will use for each destination address. 

	The order of the I-PSN parameters within COOKIE-ECHO and 
      COOKIE-ACK MAY correspond to the destination addresses 
      specified by the receiver of this parameter during the 
      INIT/INIT-ACK exchange.
	
      
       Parameter Name                       Status     Type Value
       -------------------------------------------------------------
       Initial-PSN                          OPTIONAL    0x0010

      The format of this parameter is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Parameter Type = 0x0010    |  Parameter Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PID  |                      I-PSN                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      



Abd El Al, et al.                                               [Page 6]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


       Type: 16 bit u_int

          0x0010, indicating I-PSN parameter

       Length: 16 bit u_int

          Indicate the size of the parameter i.e. 8.

       Path Identifier PID: 4 bits (unsigned integer)

           An identification number for each destination address           

       Initial-Path Sequence Number I-PSN: 28 bits (unsigned integer)

           Defines the initial PSN that the sender will use for the 
           Data Chunks that will be sent to the destination address.  
           The valid range of I-PSN is from 0 to 68435455 (2**28 - 1).    

3.3 LS-SCTP Data chunk (LS-DATA) (10)

   The following format MUST be used by LS-SCTP association for the 
   DATA chunk:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 10   | Reserved|U|B|E|    Length                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ASN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PID  |                      PSN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Stream Identifier S      |   Stream Sequence Number n    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Payload Protocol Identifier                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                 User Data (seq n of Stream S)                 /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved: 5 bits

      Should be set to all '0's and ignored by the receiver.





Abd El Al, et al.                                               [Page 7]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   U bit: 1 bit

      The (U)nordered bit, if set to '1', indicates that this is an
      unordered DATA chunk, and there is no Stream Sequence Number
      assigned to this DATA chunk.  Therefore, the receiver MUST ignore
      the Stream Sequence Number field.

      After re-assembly (if necessary), unordered DATA chunks MUST be
      dispatched to the upper layer by the receiver without any attempt
      to re-order.

      If an unordered user message is fragmented, each fragment of the
      message MUST have its U bit set to '1'.

   B bit: 1 bit

      The (B)eginning fragment bit, if set, indicates the first   
      fragment of a user message.

   E bit:  1 bit

      The (E)nding fragment bit, if set, indicates the last fragment of
      a user message.


   An unfragmented user message shall have both the B and E bits set to
   '1'.  Setting both B and E bits to '0' indicates a middle fragment  
   of a multi-fragment user message, as summarized in the following 
   table:


            B E                  Description
         ===========================================================         |  1 0 | First piece of a fragmented user message          |
         +----------------------------------------------------------+
         |  0 0 | Middle piece of a fragmented user message         |
         +----------------------------------------------------------+
         |  0 1 | Last piece of a fragmented user message           |
         +----------------------------------------------------------+
         |  1 1 | Unfragmented Message                              |
         ===========================================================         |             Table 1: Fragment Description Flags          |
         ==========================================================   When a user message is fragmented into multiple chunks, the PSNs are
   used by the receiver to reassemble the message.  This means that the
   PSNs for each fragment, of a fragmented user message, MUST be 
   strictly sequential.


Abd El Al, et al.                                               [Page 8]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   Length:  16 bits (unsigned integer)

      This field indicates the length of the DATA chunk in bytes from
      the beginning of the type field to the end of the user data field
      excluding any padding.  A DATA chunk with no user data field will
      have Length set to 20 (indicating 20 bytes).

   Association Sequence Number ASN : 32 bits (unsigned integer)

      The ASN represents a sequence number for data chunks over the 
      association regardless the path over which the data chunks will 
      be sent. This value represents the ASN for this DATA chunk.  The   
      valid range of ASN is from 0 to 4294967295 (2**32 - 1).  ASN 
      wraps back to 0 after reaching 4294967295.

   Path Identifier PID: 4 bits (unsigned integer)

      Identifies the path over which the data chunk is being sent.

   Path Sequence Number PSN: 28 bits (unsigned integer)

      The PSN represents a sequence number for data chunks over the 
      a certain  path. This value represents the PSN for this DATA 
      chunk.  The valid range of PSN is from 0 to 268435455 
      (2**28 - 1).  PSN wraps back to 0 after reaching 268435455.

   Stream Identifier S: 16 bits (unsigned integer)

      Identifies the stream to which the following user data belongs.

   Stream Sequence Number n: 16 bits (unsigned integer)

      This value represents the stream sequence number of the following
      user data within the stream S.  Valid range is 0 to 65535.

      When a user message is fragmented by LS-SCTP for transport, the 
      same stream sequence number MUST be carried in each of the 
      fragments of the message.

   Payload Protocol Identifier: 32 bits (unsigned integer)

      This value represents an application (or upper layer) specified
      protocol identifier.  This value is passed to LS-SCTP by its 
      upper layer and sent to its peer.  This identifier is not used by 
      LS-SCTP but can be used by certain network entities as well as 
      the peer application to identify the type of information being 
      carried in this DATA chunk. This field must be sent even in 
      fragmented DATA chunks (to make sure it is available for agents 
      in the middle of the network).



Abd El Al, et al.                                               [Page 9]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


      The value 0 indicates no application identifier is specified by
      the upper layer for this payload data.

   User Data: variable length

      This is the payload user data.  The implementation MUST pad the
      end of the data to a 4 byte boundary with all-zero bytes.  Any
      padding MUST NOT be included in the length field.  A sender MUST
      never add more than 3 bytes of padding.

3.4 LS-SCTP Selective Acknowledgement (LS-SACK) (13)

   This chunk is sent to the peer endpoint to acknowledge received DATA
   chunks on a certain path and to inform the peer endpoint of gaps in 
   the received subsequences of DATA chunks as represented by their 
   PSNs.

   The LS-SACK MUST contain the Cumulative ASN Ack that indicates the 
   highest in-sequence ASN received at the receiver, as well as  
   Cumulative PSN that indicates the highest in-sequence PSN received 
   on this path. In addition, Advertised Receiver Window Credit 
   (a_rwnd) parameters, that indicates the available space at the 
   association receiver buffer, MUST be included.

   By definition, the value of the Cumulative ASN Ack parameter is the
   last ASN received before a break in the sequence of received ASNs
   occurs; the next ASN value following this one has not yet been
   received at the endpoint sending the LS-SACK.  This parameter 
   therefore acknowledges receipt of all ASNs less than or equal to its 
   value. The same is also true for the Cumulative PSN Ack parameter.

   The LS-SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of PSNs received following a break
   in the sequence of received PSNs.  By definition, all PSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative PSN Ack.

   A Time Stamp parameter is included in the LS-SACK to indicate the 
   time at which the receiver endpoint sent the LS-SACK.

   As the parameters that represent a PSN in the LS-SACK are 32 bits, 
   while the PSN in the data chunk is 28 bits, the implementer has to
   to use only 28 bits in the LS-SACK for the PSN, and pad the  
   remaining bits with 0s.  		







Abd El Al, et al.                                              [Page 10]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 13   |Chunk  Flags   |      Chunk Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Cumulative ASN Ack                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Advertised Receiver Window Credit (a_rwnd)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Time Stamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Cumulative PSN Ack                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Number of Gap Ack Blocks = N  |  Number of Duplicate PSNs = X |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Gap Ack Block #1 Start       |   Gap Ack Block #1 End        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      \                              ...                              \
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Gap Ack Block #N Start      |  Gap Ack Block #N End         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Duplicate PSN 1                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      \                              ...                              \
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Duplicate PSN X                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Flags: 8 bits

      Set to all zeros on transmit and ignored on receipt.

   Cumulative ASN Ack: 32 bits (unsigned integer)

      This parameter contains the ASN of the last DATA chunk received 
      in sequence before a gap.

   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
      integer)

      This field indicates the updated receive buffer space in bytes of
      the sender of this LS-SACK. 

 

 
 
Abd El Al, et al.                                              [Page 11]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   Time Stamp: 32 bits (unsigned integer)

      This parameter contains a time stamp that indicate the time at 
      which the LS-SACK was generated at the receiver. This time stamp 
      MAY be represented as the number of m-seconds since starting the 
      association. In this case, the receiver endpoint is responsible 
      for setting this parameter in the outgoing LS-SACKs, such that 
      consecutive LS-SACKs generated form the receiver, MUST have their
      Time Stamps incremented by 1, even they are acknowledging data 
      chunks received from different paths.

  Cumulative PSN Ack: 32 bits (unsigned integer)

      This parameter contains the PSN of the last DATA chunk received 
      in sequence before a gap, on the path this LS-SACK is 
      acknowleging.

   Number of Gap Ack Blocks: 16 bits (unsigned integer)

      Indicates the number of Gap Ack Blocks included in this LS-SACK.

   Number of Duplicate PSNs: 16 bit

      This field contains the number of duplicate PSNs the endpoint has
      received on a given path.  Each duplicate PSN is listed following 
      the Gap Ack Block list.

   Gap Ack Blocks:

      These fields contain the Gap Ack Blocks.  They are repeated for
      each Gap Ack Block up to the number of Gap Ack Blocks defined in
      the Number of Gap Ack Blocks field.  All DATA chunks with PSNs
      greater than or equal to (Cumulative PSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative PSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been 
      received correctly.

   Gap Ack Block Start: 16 bits (unsigned integer)

      Indicates the Start offset PSN for this Gap Ack Block.  To
      calculate the actual PSN number the Cumulative PSN Ack is added 
      to this offset number.  This calculated PSN identifies the first 
      PSN in this Gap Ack Block that has been received.

   Gap Ack Block End:  16 bits (unsigned integer)

      Indicates the End offset PSN for this Gap Ack Block.  To 
      calculate the actual PSN number the Cumulative PSN Ack is added 
      to this offset number.  This calculated PSN identifies the PSN of 
      the last DATA chunk received in this Gap Ack Block.

Abd El Al, et al.                                              [Page 12]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


3.5 Negotiation of Load-Sharing-Supported parameter

3.5.1 Sending Load-Sharing-Supported param in INIT

   If an SCTP endpoint supports the LS-SCTP, then any time it
   sends an INIT during association establishment, it SHOULD include 
   the Load-Sharing-Supported parameter in the INIT chunk to indicate 
   this fact to its peer.

   An endpoint SHOULD report Load-Sharing-Supported parameter if ALL  
   the following conditions are valid:

   o The endpoint is supporting and willing to use LS-SCTP,

   o The endpoint has more than one interface, and it is willing to use 
     them for load sharing during the association,

   o The endpoint will include the interface addresses, it is willing 
     to use for load sharing during the association, within the 
     INIT/INIT-ACK chunk using the optional address parameter.

   If the endpoint includes Load-Sharing-Supported parameter in the 
   INIT or INIT-ACK chunks, the initial sequence number in these chunks 
   should reflect the Initial-Association Sequence Number (I-ASN) that 
   the sender intends to use after association initiation.

3.5.2 Receipt of Load-Sharing-Supported param in INIT or INIT-ACK

   When a receiver of an INIT detects a Load-Sharing-Supported 
   parameter, and does not support LS-SCTP, the receiver SHOULD
   treat this parameter as an invalid or unrecognized parameter and
   respond to the data sender with an unrecognized parameter in the
   INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
   [SXM00].

   When a receiver of an INIT-ACK detects a Load-Sharing-Supported
   parameter, and does not support LS-SCTP, the receiver SHOULD treat  
   this parameter as an invalid or unrecognized parameter and respond  
   to the data sender with an unrecognized parameter error, following 
   the rules defined in Section 3.3.3 of RFC2960 [SXM00]. This error 
   SHOULD be reported in an ERROR chunk bundled with the COOKIE-ECHO.

   When a receiver of an INIT detects a Load-Sharing-Supported     
   parameter, and does support LS-SCTP, the receiver SHOULD respond 
   with a Load-Sharing-Supported parameter in the INIT-ACK chunk.

   When an endpoint that supports LS-SCTP receives an INIT that does 
   not contain the Load-Sharing-Supported Parameter, that endpoint:



Abd El Al, et al.                                              [Page 13]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   o  MAY include the Load-Sharing-Supported parameter in the INIT-ACK,

   o  SHOULD record the fact that the peer does not support the 
      LS-SCTP,

   o  MUST NOT use LS-SCTP at any time during the associations life,

   o  SHOULD inform the upper layer, if the upper layer has requested
      such notification.

3.5.3 Receipt of Op. Error for Load-Sharing-Supported Param

   When an SCTP endpoint that desires to use LS-SCTP feature receives   
   an operational error from the remote endpoint (either bundled with 
   the COOKIE or as a unrecognized parameter in the INIT-ACK),  
   indicating that the remote endpoint does not recognize the  
   Load-Sharing-Supported parameter, the local endpoint SHOULD inform 
   its upper layer of the remote endpoint's inability to support 
   LS-SCTP, if the upper layer has requested such notification.

   The local endpoint may then choose to either:

      1) end the initiation process (in cases where the initiation
      process have already ended the endpoint may need to send an
      ABORT), in consideration of the peer's inability to supply the
      requested features for the new association, or

      2) continue the initiation process (in cases where the initiation
      process has already completed the endpoint MUST just mark the
      association as not supporting LS-SCTP), but with the       
      understanding that LS-SCTP is not supported.  In this case, the 
      endpoint receiving the operational error SHOULD not use LS-SCTP  
      during the life of the association.

3.6 Exchanging Initial-PSN Param in the COOKIE-ECHO and COOKIE-ACK

   After the Load-Sharing-Supported parameter exchange, if both 
   endpoints support LS-SCTP, both endpoints MAY include I-PSN 
   parameter during their exchange of the COOKIE-ECHO and COOKIE-ACK. 

   The I-PSN parameter includes a Path Identifier (PID) field, that   
   indicates an identification assigned by the sender of the parameter   
   for each destination address, reported previously by the receiver of 
   the parameter during the INIT and INIT-ACK exchange. In addition, 
   the parameter includes Initial Path Sequence Number (I-PSN) field 
   that indicates the initial path sequence number that will be used by 
   the sender of the parameter for this destination address.




Abd El Al, et al.                                              [Page 14]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   The order of the I-PSN parameter(s) in the COOKIE-ECHO and the 
   COOKIE-ACK SHOULD be in the same order of the address parameter(s) 
   specified in the INIT and the INIT-ACK chunks, so that the receiver   
   of the I-PSN parameter(s) could easily correlate the parameter(s) to 
   the previously reported address(es).

   If both endpoints agree to use LS-SCTP, the Initial Sequence Number 
   included previously in the INIT/INIT-ACK SHOULD be interpreted as  
   the Initial Association Sequence Number (I-ASN). 

   The sender of the COOKIE-ECHO/COOKIE-ACK, MAY choose not to include 
   the I-PSN parameter(s), after agreeing with the peer endpoint to 
   use LS-SCTP. In this case, the sender SHOULD use the sequence 
   number specified previously in the INIT/INIT-ACK as the I-PSN over 
   all the paths within the association, as well as the Initial ASN.

   If an endpoint does not include the I-PSN parameter(s) in the 
   COOKIE-ECHO/COOKIE-ACK, after agreeing with the peer endpoint to 
   use LS-SCTP, the receiver of the COOKIE-ECHO/COOKIE-ACK SHOULD 
   assume that the sender will use the sequence number specified 
   previously in the INIT/INIT-ACK as the I-PSN over all the paths 
   within the association, as well as the Initial ASN.


3.7 Sender Side Implementation of PR-SCTP

   Figure 2, shows the outbound message passage at the sender endpoint.
























Abd El Al, et al.                                              [Page 15]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005



             -------    -------    -------    -------
  User      |       |  |       |  |       |  |       |   User 
  Messages   -------    -------    -------    -------  Application
   --------------------------------------------------------------         
                                | 
                          ---------------
   	                   | Fragmentation |               LS-SCTP   
                          ---------------               Transport
                                |                        Service  
                          ---------------
			       | Path Decision |
                          ---------------
   Association Buffer           |
    ------------------------------------------------------------------
   |  Data SSN SID ASN  Data SSN SID ASN  Data SSN SID ASN  Data SSN SID ASN   |
   | -------+-+-+-   -------+-+-+-    ------+-+-+-    -------+-+-+-   |
   ||       |2|2|4| |       |2|1|3|  |      |1|2|2|  |       |1|1|1|  |
   | ---------+-+-   ---------+-+-    --------+-+-    ---------+-+-   |
    ------------------------------------------------------------------
                               /           \
                              /             \     
    |    Data   SSN SID ASN PSN PID |        |    Data   SSN SID ASN PSN PID |
    |   -------+--+--+--+--+--   |        |   -------+--+--+--+--+--   |  
    |  |       |2 |2 |4 |2 |2 |  |        |  |       |1 |2 |2 |2 |1 |  |                 
    |   -----------------------  |        |   ----------------------   |
    |    Data  SSN SID ASN PSN PID  |        |    Data   SSN SID ASN PSN PID | 
    |   -------+--+--+--+--+--   |        |   -------+--+--+--+--+--   | 
    |  |       |2 |1 |3 |1 |2 |  |        |  |       |1 |1 |1 |1 |1 |  |                  
    |   ----------------------   |        |   ----------------------   |
     ----------------------------          ----------------------------
     Interface 0 Virtual Buffer             Interface 1 Virtual Buffer
                            \              /  
                             \ ---------- /     --------------------
	  		            | Bundling | <-> | LS-SCTP Controller |
                               ----------       --------------------
      Data     Control Common       /\                        
      Chunk     Chunk  Header      /  \
   ------------+------+------     /    \
  |            |      |      |   /      \
   ------------+------+------   /        \                         
   ----------------------------/----------\---------------------------                                                            
                              /            \                 IP Network 
               To Interface 0              To Interface 1     Service                      

          Figure 2: Outbound Message Passage in the LS-SCTP





Abd El Al, et al.                                              [Page 16]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


3.7.1 Transmission of DATA Chunks

   As the LS-SCTP sender receives data messages from Upper Layer 
   Protocol (ULP), if required, it fragments the message into multiple 
   Data chunks according to the message size and the current Path MTU  
   (PMTU). Sections 3.7.2 and 3.7.3 in this memo, detail Path MTU 
   discovery and fragmentation and reassembly of ULP messages 
   respectively. The sender endpoint assigns the Data chunks resulted 
   from fragmenting one ULP message the same SSN, as well as 
   assigning them the same ASN. The Data chunks are then passed 
   to the Path Decision module of the LS-SCTP, which, as will be 
   described in section 3.7.4 of this memo, can pre-select a 
   transmission path for the Data chunks. The Data chunks are then 
   placed in the association buffer, waiting for transmission. If no 
   path was pre-selected for a Data chunk, by the Path Decision module, 
   LS-SCTP will select a path based on the bandwidth availability of 
   the association paths. As soon as the Virtual Buffer, for the path 
   on which the Data chunks were assigned, is ready to accept more Data  
   chunks, the Data chunks will be assigned a PID and PSN for this 
   path. Before the Data chunks are sent on a given path, they can be  
   bundled together, or bundled with Control chunks. Bundling will be 
   described in detail in section 3.7.9 of this memo. The common header
   is then added to the bundled chunks and the packet is handed to the
   IP network layer for transmission on the specified path.

3.7.2 Path MTU Discovery

   As in RFC2960 [SXM00], section 7.3, an LS-SCTP endpoint MUST maintain 
   separate MTU estimates for each destination address of its peer,    
   using the mechanisms described in RFC1191 [RFC1191] and RFC1981 [RFC1981].

3.7.3 Fragmentation and Reassembly

   The sender SHOULD track an association Path MTU (PMTU), which will 
   be the smallest MTU 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.

   In addition, the LS-SCTP sender endpoint MAY assign all the 
   segments of a given message to the same path, so as to ensure that 
   the message fragments will be received in order at the receiver 
   endpoint, thus reducing the time required to reassemble the original 
   message.

   The sender endpoint MUST assign the same ASN to each of the DATA
   chunks in the fragments series.  Also, fragments DATA chunks are
   assigned the same SSN. After assigning the fragments Data chunks 


Abd El Al, et al.                                              [Page 17]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   to a transmission path, all the fragments Data chunks MUST be 
   assigned, in sequence, PSN on this path.     

   As in RFC2960[SXM00], section 6.9, the receiver endpoint MUST recognize 
   fragmented DATA chunks, received on each path, 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, 
   LS-SCTP shall pass the re-assembled user message to the specific 
   stream for possible reordering and final dispatching.

3.7.4 Path Decision

   The Path Decision module in LS-SCTP, is responsible for 
   pre-assigning  transmission paths for Data chunks. The decision can 
   be based on a criteria requested by the ULP during the association 
   initiation. For example, the ULP MAY request the LS-SCTP to assign 
   different data streams, within the association, to different paths. 
   The ULP request May be in the form of Quality of Service (QoS) 
   requirement for each stream. Based on the QoS requirements for the 
   streams as well as the current characteristic of the active 
   transmission paths, the Path Decision Module can dynamically change 
   the streams-Paths assignment, trying to fulfill the streams QoS. 
   If the Path Decision module makes no decision, the LS-SCTP will 
   decide the transmission paths for Data Chunks based on the bandwidth 
   availability of active paths within the association, as will be 
   described in the next section. Details of the design of the Path 
   Decision module is not discussed in this memo at this time, but it 
   will be added in a later version of this draft. 
   
3.7.5 Distributing Data Chunks on Association Paths

   If no transmission path was pre-assigned by the Path Decision 
   module, LS-SCTP assigns Data chunks to the transmission paths 
   based on a bandwidth estimate of these paths. LS-SCTP uses 
   non-intrusive mechanism for estimating the bandwidth, so it uses the  
   current Congestion Window (cwnd) of each path, as an estimate of the 
   current bandwidth of this path. The sender endpoint assigns Data 
   chunks from the association buffer to a Virtual Buffer, that 
   represents a path, whenever it has enough bandwidth to transmit the 
   Data chunk. The Virtual Buffer keeps track of the congestion 
   variables control on each path, as shown in RFC2960 [SXM00] section 7,
   including cwnd, slow-start threshold (ssthresh), Round Trip Time
   (RTT), Retransmission Time Out (RTO), Outstanding Data Count,  
   and partial bytes acknowledged (partial_bytes_acked). In addition,   
   the Virtual Buffer keeps track of the PSNs sent on each path, and 
   processes the LS-SACK received from the receiver endpoint for this 
   path. The Receiver window Size (rwnd), which represents the 
   available buffer space in the receiver association buffer is kept
   on the association basis, as the Data chunks that are sent on 



Abd El Al, et al.                                              [Page 18]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   different paths within the association will all share the 
   association buffer at the receiver. After assigning a Data chunk
   to Virtual Buffer, the Data chunk will be assigned the PID that 
   identifies the path, as well as an in-sequence PSN on this path. 

3.7.6 Processing Received LS-SACK

   Each LS-SACK, an endpoint Virtual Buffer receives, contains an 
   a_rwnd value.  This value represents the amount of association    
   buffer space that has been left, at the time of transmitting the 
   LS-SACK, out of the total association buffer space (as specified  
   in the INIT/INIT ACK).  

   Upon reception of a LS-SACK the following SHOULD be done by the 
   sender endpoint:

   o At the Virtual Buffer that receives the LS-SACK, the sender SHOULD  
   use the Cumulative PSN Ack, Gap Ack Blocks and Duplicate Ack Blocks  
   to determine the Data chunks that have been received successfully by 
   the receiver on this path.

   o The sender endpoint uses the Cumulative ASN Ack, included in the 
   LS-SACK, to update the Cumulative ASN Ack Point, and accordingly 
   it flushes, from the association buffer, the Data chunks that have 
   ASN less than the Cumulative ASN Ack Point.
 
   o Using a_rwnd and the outstanding Data chunks on each path, the 
   sender endpoint can develop a representation of the peer's receive   
   buffer space. After processing the Cumulative ASN Ack and the Gap 
   Ack Blocks in the last received LS-SACK, the sender SHOULD use the 
   following equation to calculate the current free space at the 
   receiver's association buffer: 

   Association rwnd  = a_rwnd reported in the last LS-SACK - Number of 
   bytes still outstanding on all the Active paths within the 
   association 
   
   One of the problems the data sender must take into account when
   processing a LS-SACK, that as LS-SACKs are received on all the paths 
   that are used for load sharing within the association, they can be 
   received out of order, due to the different delay of the paths on 
   which the LS-SACKs were sent. This out of order arrival of the 
   LS-SACKs can cause the data sender to develop an incorrect view of 
   the peerĂs receive buffer space, as all the LS-SACKs sent form the 
   receiver endpoint include the receiver free buffer space, at the 
   time the LS-SACK was sent. Thus the receiver of the LS-SACK SHOULD  
   use the Time Stamp field included in the LS-SACK in order to 
   determine their order. Consequently, when the sender endpoint 
   receives an old LS-SACK, it SHOULD not update its view of the 



Abd El Al, et al.                                              [Page 19]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   receiver buffer space, as well as the ASN Cumulative Point, based on 
   the values in this LS-SACK, but it SHOULD use the remaining values 
   for updating the Virtual Buffer for the path from which the LS-SACK 
   was received.

   The Virtual Buffers for each path SHOULD use the received LS-SACK 
   pertaining to the Data chunks sent over this path, as described in 
   RFC2960 [SXM00] section 6.2.1.

3.7.7 Re-transmitting Data Chunks

   LS-SCTP performs congestion control on a per path basis, which means  
   that all the Data chunks to be transmitted on a certain path should 
   be assigned in-sequence PSNs, in addition the LS-SACKs that will be 
   sent by the receiver endpoint to acknowledge these Data chunks MUST 
   be sent to the same address from which these chunks was received. 

   When a Data chunk is to be retransmitted, the sender endpoint SHOULD 
   try to retransmit this Data chunk to an active destination address 
   that is different from the last destination address to which the 
   DATA chunk was sent. The PSN that was assigned to the Data chunk on 
   the last path SHOULD be returned to the PSN pool for this path, and 
   can be used by other new Data chunks on this path. The retransmitted 
   Data chunk will be assigned a new PID and PSN according to the new 
   path it will be retransmitted on.

   LS-SCTP adjusts the outstanding data counts on the new path and the 
   old path according to the size of the retransmitted Data chunk.

3.7.8 Monitoring Transmission Paths
   
   The LS-SCTP sender keeps track of the set of Active destination 
   addresses. Initially, the set will  be set according to the 
   destination address(es) received from the receiver endpoint during 
   the association initiation, and all the addresses will be marked as 
   Active. The sender endpoint will only consider Active destination 
   addresses for load sharing. When the LS-SCTP sender detects the 
   failure of a destination address, using techniques similar to that 
   described in RFC2960 [SXM00] section 8.2, the sender changes the status 
   of a destination address to Inactive. The LS-SCTP will continue to 
   monitor Inactive destination addresses, using heartbeats, as shown 
   in RFC2960 [SXM00] section 8.3, and as soon as an Inactive paths turns 
   Active, the sender starts to use it again for load sharing.

3.7.9 Bundling
   
   LS-SCTP is following RFC2960 [SXM00], section 6.10, in performing the 
   bundling. There are only 2 specifics for the LS-SCTP:
  



Abd El Al, et al.                                              [Page 20]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005
   

   1) Only Data chunks that are to be sent on the same path, are 
   allowed to be bundled together. Also Data chunks that are assigned 
   to be sent on a certain path are only allowed to bundled with 
   control chunks pertaining to this path.
  
   2)	Bundling on each path MUST be based on the latest MTU of this 
   path.

3.8 Receiver Side Implementation of PR-SCTP

   Figure 3, shows the inbound message passage at the receiver 
   endpoint.
            






































Abd El Al, et al.                                              [Page 21]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


            |       |  |       |  |       |  |       |        User 
            |       |  |       |  |       |  |       |      Application
  --------- |-------|--|-------|--|-------|--|-------|-----------------              
            |-------|  |-------|  |-------|  |-------|   Stream                    
             -------    -------    -------    -------   Reordering    
                |           |         |          |       Queues 
                ----------------------------------     
                                |
                           ------------                     LS-SCTP   
 			        | Reassembly |                   Transport
                           ------------                     Service  
   Association Buffer           |                           
    ------------------------------------------------------------------
   |  Data SSN SID ASN  Data SSN SID ASN   Data SSN SID ASN   Data SSN SID ASN |
   | -------+-+-+-   -------+-+-+-    ------+-+-+-    -------+-+-+-   |
   ||       |2|2|4| |       |2|1|3|  |      |1|2|2|  |       |1|1|1|  |
   | ---------+-+-   ---------+-+-    --------+-+-    ---------+-+-   |
    ------------------------------------------------------------------
                               /             \     
    |    Data   SSN SID ASN PSN PID |       |    Data   SSN SID ASN PSN PID  |
    |   -------+--+--+--+--+--   |       |   -------+--+--+--+--+--    |  
    |  |       |2 |1 |3 |1 |2 |  |       |  |       |1 |1 |1 |1 |1 |   |                 
    |   ----------------------   |       |   ----------------------    |
    |    Data   SSN SID ASN PSN PID |       |    Data   SSN SID ASN PSN PID  | 
    |   -------+--+--+--+--+--   |       |   -------+--+--+--+--+--    | 
    |  |       |2 |2 |4 |2 |2 |  |       |  |       |1 |2 |2 |2 |1 |   |                  
    |   ----------------------   |       |   -----------------------   |
     ----------------------------         -----------------------------
     Interface 0 Virtual Buffer           Interface 1 Virtual Buffer
                             \ ---------- /     -------------------
	  		           |Un-Bundling| <->| LS-SCTP Controller |
                               ----------       -------------------
     Data      Control Common      /\                        
     Chunk      Chunk  Header     /  \ 
   ------------+------+-----     /    \ 
  |            |      |     |   /      \
   ------------+------+-----   /        \                         
  ----------------------------/----------\-----------------------------
                             /            \                 IP Network 
                From Interface 0           From Interface 1    Service                    

            Figure 3: Inbound Message Passage in the LS-SCTP










Abd El Al, et al.                                              [Page 22]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   As the LS-SCTP packets are received from the network layer, the 
   receiver endpoint will check the common header and strip it form the 
   packet, then unbundling module will unbundle Control chunks from 
   Data chunks. The Control chunks are delivered to the LS-Controller, 
   while the Data chunks are examined by the receiver endpoint and the 
   Virtual Buffer corresponding to the path from which the Data chunks 
   were received will be updated. The receiver will acknowledge the 
   Data chunks, as described in section 3.8.1 of this memo. The Data 
   chunks will be placed in the receiver association buffer, until they 
   are delivered to the ULP.

3.8.1 Acknowledgement on Reception of DATA Chunks

   The LS-SCTP endpoint MUST always acknowledge the reception of each 
   valid DATA chunk received on the paths used for load sharing within 
   the association.

   The LS-SCTP receiver SHOULD generate LS-SACK, following the  
   guidelines described in RFC2960 [SXM00] section 6.2.

   As DATA chunks are received and buffered in the receiver association 
   buffer, the receiver endpoint decrements the  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.

   As DATA chunks are delivered to the ULP and released from the
   receiver buffer, the receiver increments the 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
   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.

   When sending a LS-SACK on a certain path, the data receiver SHOULD 
   place the current value of a_rwnd into the a_rwnd field.  In 
   addition, the data receiver SHOULD set the Cumulative ASN, that 
   represents the highest ASN delivered to the ULP, taking into account 
   that the data sender will not retransmit DATA chunks that are      
   acknowledged via the Cumulative ASN Ack (i.e., will drop from its 
   retransmit queue). 

   The receiver has to set the Time Stamp within the LS-SACK to reflect 
   the time at which the receiver sent the LS-SACK. 

   The receiver Virtual Buffer for each path will be used to set the   
   Cumulative PSN in the LS-SACK, that represents the highest in 
   sequence PSN received at the receiver over this path. This value  
   will be used by the corresponding Virtual Buffer at the sender for  


Abd El Al, et al.                                              [Page 23]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   congestion control over this path. In addition, the duplicate and 
   missing PSNs over this path SHOULD be reported in the LS-SACK.

   THE LS-SACK SHOULD be sent to the source address from which the 
   acknowledged Data chunks were received. 

3.8.2 DATA Chunks Delivery to ULP

   As described in RFC2960 [SXM00] section 6.6, within a stream, an 
   endpoint MUST deliver DATA chunks received with the U flag set to 0 
   to the ULP 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. The receiver will be
   able to deliver Data chunks, within a stream, if there is no gaps
   in their Stream Sequence Number, even there is gaps in the ASN 
   proceeding the ASN of these Data chunks. As this feature has the  
   benefit of preventing head-of-line blocking in SCTP, it will have  
   more benefits in LS-SCTP, as there is high possibility of gaps in 
   the ASN due to out of order arrival of Data chunks at the receiver, 
   because different paths were used for transmitting the Data chunks.
      
   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).


4. Termination of Association

   LS-SCTP SHOULD follow the SCTP association termination procedure 
   described in RFC2960 [SXM00] section 9. 

 

















Abd El Al, et al.                                              [Page 24]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


5. Security Considerations

   [Open Issue TBD: Security issues are not discussed in this memo at
   this time, but will be added in a later version of this draft.]
















































Abd El Al, et al.                                              [Page 25]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


6. IANA Considerations

6.1 Chunk Extension

    Two new chunk types are added to SCTP by this document:

    1. LS-Data chunk (Š0x10Ă)
    2. LS-SACK chunk (Š0x13Ă)     

    The full description of these chunks are shown in sections 3.3 and 
    3.4 respectively.

6.2 Chunk Parameter Extension

   Two new chunk parameters are added to SCTP by this document:

   1. Load-Sharing-Supported Parameter for INIT and INIT-ACK (Š0xC001Ă)
   2. Initial-PSN (I-PSN) Parameter for COOKIE-ECHO and COOKIE-ACK 
   (Š0x0010Ă)     
   
   The full description of these chunk parameters are shown in sections 
   3.1 and 3.2 respectively.





























Abd El Al, et al.                                              [Page 26]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


7. References

7.1. Normative References

  [SXM00]  R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
           T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson,
           "Stream Control Transmission Protocol", RFC 2960, 
           October 2000.

7.2. Informative References

  [BTS95]  C. Brenden, S. Traw, M. Smith, ˘Striping Within the Network   
           Subsystem÷, IEEE Network, July/August 1995.

  [ASLJ04] A. Abd El Al, T. Saadawi, M. Lee, ˘Bandwidth Aggregation in 
           Stream Control Transmission Protocol÷, In Proceedings of 
           IEEE International Symposium on Computers and Communications 
           (ISCC), July 2004. 

  [ASLD04] A. Abd El Al, T. Saadawi, M. Lee, ˘Improving Throughput and 
           Reliability in Mobile Wireless Networks Via Transport Layer 
           Bandwidth Aggregation÷, Computer Networks, special issue on 
           Future Advances in Military Communications Systems & 
           Technologies, Vol. 46, No. 5, pp. 635-649, December 2004. 

  [AA01]   A. Caro, P. Amer et al., ˘Improving Multimedia Performance 
           Over Lossy Networks Via SCTP÷, ATIRP 2001, College Park, MD, 
           March 2001.

  [RFC2199] S. Bradner, "Key words for use in RFCs to Indicate 
            Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC1191] J. Mogul, S. Deering, ˘Path MTU Discovery÷, RFC 1191, 
            November 1990.

  [RFC1981] J. McCann, S. Deering, J. Mogul, ˘Path MTU Discovery for 
            IP version 6÷, RFC 1981, August 1996.


8. Authors' Addresses

   Ahmed Abd El Al
   Department of Electrical Engineering
   The City College of New York
   Convent Avenue and 138th St.
   New York, NY  10031
   USA

   Phone: +1-212-650-7158
   EMail: aabdelal@ieee.org


   

Abd El Al, et al.                                              [Page 27]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


   Tarek Saadawi
   Department of Electrical Engineering
   The City College of New York
   Convent Avenue and 138th St.
   New York, NY  10031
   USA

   Phone: +1-212-650-7263
   EMail: saadawi@ee1s0.engr.ccny.cuny.edu


   Myung Lee	
   Department of Electrical Engineering
   The City College of New York
   Convent Avenue and 138th St.
   New York, NY  10031
   USA

   Phone: +1-212-650-7260
   EMail: mjlee@ee1s0.engr.ccny.cuny.edu





























Abd El Al, et al.                                              [Page 28]


INTERNET-DRAFT            Load Sharing in SCTP                 May, 2005


 Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.



























Abd El Al, et al.                                              [Page 29]