Subject: [Tsvwg] New RFC2960bis

From: Randall Stewart <[email-masked]>
Date: Fri, 11 May 2001 10:39:47 -0500

Dear all:

I have just sent to the I-D editor the 2960BIS... first pass..
I am sure we will have a couple of more :)

Now attached please find a diff -c of the changes...

I first de-paged the RFC and saved it... this is my
rcs base 1.2 text (used in the diff).

The 1.6 version is the updated final version I just sent
off to the editor (minus the paging).

Regards

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

Index: draft-ietf-tsvwg-rfc2960bis-00.txt
===================================================================
RCS file: /home/sourceTree/doc/sctp/draft-ietf-tsvwg-rfc2960bis-00.txt,v
retrieving revision 1.2
retrieving revision 1.6
diff -c -r1.2 -r1.6
*** draft-ietf-tsvwg-rfc2960bis-00.txt	2001/05/08 14:31:37	1.2
--- draft-ietf-tsvwg-rfc2960bis-00.txt	2001/05/11 14:59:52	1.6
***************
*** 112,117 ****
--- 112,118 ----
           3.3.10.8 Unrecognized Parameters............................ 45
           3.3.10.9 No User Data....................................... 46
           3.3.10.10 Cookie Received While Shutting Down............... 46
+          3.3.10.11 Restart of an association with new addresses......
         3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
         3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
         3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
***************
*** 150,156 ****
       6.5 Stream Identifier and Stream Sequence Number................ 80
       6.6 Ordered and Unordered Delivery.............................. 80
       6.7 Report Gaps in Received DATA TSNs........................... 81
!      6.8 Adler-32 Checksum Calculation............................... 82
       6.9 Fragmentation............................................... 83
       6.10 Bundling .................................................. 84
     7. Congestion Control   .......................................... 85
--- 151,157 ----
       6.5 Stream Identifier and Stream Sequence Number................ 80
       6.6 Ordered and Unordered Delivery.............................. 80
       6.7 Report Gaps in Received DATA TSNs........................... 81
!      6.8 fletcher-16 Checksum Calculation............................ 82
       6.9 Fragmentation............................................... 83
       6.10 Bundling .................................................. 84
     7. Congestion Control   .......................................... 85
***************
*** 415,429 ****
  1.3.6 Packet Validation
  
     A mandatory Verification Tag field and a 32 bit checksum field (see
!    Appendix B for a description of the Adler-32 checksum) are included
     in the SCTP common header.  The Verification Tag value is chosen by
     each end of the association during association startup.  Packets
     received without the expected Verification Tag value are discarded,
     as a protection against blind masquerade attacks and against stale
!    SCTP packets from a previous association.  The Adler-32 checksum
     should be set by the sender of each SCTP packet to provide additional
     protection against data corruption in the network.  The receiver of
!    an SCTP packet with an invalid Adler-32 checksum silently discards
     the packet.
  
  1.3.7 Path Management
--- 416,430 ----
  1.3.6 Packet Validation
  
     A mandatory Verification Tag field and a 32 bit checksum field (see
!    appendix B for a description of the fletcher-16 checksum) are included
     in the SCTP common header.  The Verification Tag value is chosen by
     each end of the association during association startup.  Packets
     received without the expected Verification Tag value are discarded,
     as a protection against blind masquerade attacks and against stale
!    SCTP packets from a previous association.  The Fletcher-16 checksum
     should be set by the sender of each SCTP packet to provide additional
     protection against data corruption in the network.  The receiver of
!    an SCTP packet with an invalid Fletcher-16 checksum silently discards
     the packet.
  
  1.3.7 Path Management
***************
*** 756,763 ****
     Checksum: 32 bits (unsigned integer)
  
           This field contains the checksum of this SCTP packet.  Its
!          calculation is discussed in Section 6.8.  SCTP uses the Adler-
!          32 algorithm as described in Appendix B for calculating the
           checksum
  
  3.2  Chunk Field Descriptions
--- 757,764 ----
     Checksum: 32 bits (unsigned integer)
  
           This field contains the checksum of this SCTP packet.  Its
!          calculation is discussed in Section 6.8.  SCTP uses the Fletcher-
!          16 algorithm as described in Appendix B for calculating the
           checksum
  
  3.2  Chunk Field Descriptions
***************
*** 820,826 ****
  
     01 - Stop processing this SCTP packet and discard it, do not process
          any further chunks within it, and report the unrecognized
!         parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
     10 - Skip this chunk and continue processing.
--- 821,827 ----
  
     01 - Stop processing this SCTP packet and discard it, do not process
          any further chunks within it, and report the unrecognized
!         parameter in an 'Unrecognized Chunk Type' (in either an
          ERROR or in the INIT ACK).
  
     10 - Skip this chunk and continue processing.
***************
*** 845,863 ****
        field will be set to 4.  The Chunk Length field does not count any
        padding.
  
     Chunk Value: variable length
  
        The Chunk Value field contains the actual information to be
        transferred in the chunk.  The usage and format of this field is
        dependent on the Chunk Type.
  
-    The total length of a chunk (including Type, Length and Value fields)
-    MUST be a multiple of 4 bytes.  If the length of the chunk is not a
-    multiple of 4 bytes, the sender MUST pad the chunk with all zero
-    bytes and this padding is not included in the chunk length field.
-    The sender should never pad with more than 3 bytes.  The receiver
-    MUST ignore the padding bytes.
- 
     SCTP defined chunks are described in detail in Section 3.3.  The
     guidelines for IETF-defined chunk extensions can be found in Section
     13.1 of this document.
--- 846,868 ----
        field will be set to 4.  The Chunk Length field does not count any
        padding.
  
+       Chunks (including Type, Length and Value fields) are padded out
+       by the sender with all zero bytes to be a multiple of 4 bytes
+       long. This padding MUST NOT be more than 3 bytes in total.
+       The Chunk Length value does not include terminating padding
+       of the Chunk. However, it does include padding of any variable
+       length parameter except the last parameter in the Chunk. The
+       receiver MUST ignore the padding.
+ 
+       Note: A robust implementation should accept the Chunk whether
+       or not the final padding has been included in the Chunk Length.
+ 
     Chunk Value: variable length
  
        The Chunk Value field contains the actual information to be
        transferred in the chunk.  The usage and format of this field is
        dependent on the Chunk Type.
  
     SCTP defined chunks are described in detail in Section 3.3.  The
     guidelines for IETF-defined chunk extensions can be found in Section
     13.1 of this document.
***************
*** 913,923 ****
     specify the action that must be taken if the processing endpoint does
     not recognize the Parameter Type.
  
!    00 - Stop processing this SCTP packet and discard it, do not process
!         any further chunks within it.
  
!    01 - Stop processing this SCTP packet and discard it, do not process
!         any further chunks within it, and report the unrecognized
          parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
--- 918,928 ----
     specify the action that must be taken if the processing endpoint does
     not recognize the Parameter Type.
  
!    00 - Stop processing this SCTP chunk and discard it, do not process
!         any further parmameters within this chunk.
  
!    01 - Stop processing this SCTP chunk and discard it, do not process
!         any further parameters within this chunks, and report the unrecognized
          parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
***************
*** 929,935 ****
  
     The actual SCTP parameters are defined in the specific SCTP chunk
     sections.  The rules for IETF-defined parameter extensions are
!    defined in Section 13.2.
  
  3.3 SCTP Chunk Definitions
  
--- 934,944 ----
  
     The actual SCTP parameters are defined in the specific SCTP chunk
     sections.  The rules for IETF-defined parameter extensions are
!    defined in Section 13.2. Note that a parameter value MUST be unique
!    across all chunks. For example, the parameter value '5' is used to
!    represent an IPv4 address (see section 3.3.2). The value '5' then
!    is reserved across all chunks to represent an IPv4 address and 
!    MUST NOT be reused with a different meaning in any other chunk.
  
  3.3 SCTP Chunk Definitions
  
***************
*** 1155,1161 ****
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details.
  
        Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
        the association.
--- 1164,1170 ----
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details. 
  
        Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
        the association.
***************
*** 1378,1384 ****
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details.
  
        Note: A receiver of an INIT ACK  with the MIS value set to 0
        SHOULD destroy the association discarding its TCB.
--- 1387,1396 ----
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details. The Number of Inbound Streams
!       sent in the INIT-ACK MUST NOT be greater than the value found
!       in the number of outbound streams received in the INIT.
! 
  
        Note: A receiver of an INIT ACK  with the MIS value set to 0
        SHOULD destroy the association discarding its TCB.
***************
*** 1870,1875 ****
--- 1882,1888 ----
         8              Unrecognized Parameters
         9              No User Data
        10              Cookie Received While Shutting Down
+       11              Restart of an association with new addresses
  
     Cause Length: 16 bits (unsigned integer)
  
***************
*** 1880,1886 ****
  
        This field carries the details of the error condition.
  
!    Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
     Guidelines for the IETF to define new error cause values are
     discussed in Section 13.3.
  
--- 1893,1899 ----
  
        This field carries the details of the error condition.
  
!    Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
     Guidelines for the IETF to define new error cause values are
     discussed in Section 13.3.
  
***************
*** 2017,2023 ****
     ---------------
     Invalid Mandatory Parameter:  This error cause is returned to the
     originator of an INIT or INIT ACK chunk when one of the mandatory
!    parameters is set to a invalid value.
  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Cause Code=7              |      Cause Length=4           |
--- 2030,2036 ----
     ---------------
     Invalid Mandatory Parameter:  This error cause is returned to the
     originator of an INIT or INIT ACK chunk when one of the mandatory
!    parameters is set to an invalid value.
  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Cause Code=7              |      Cause Length=4           |
***************
*** 2082,2087 ****
--- 2095,2120 ----
        |     Cause Code=10              |      Cause Length=4          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
+ 3.3.10.11 Restart of an association with new addresses (11)
+ 
+     Cause of error
+     --------------
+     Restart of an association with new addresses: A COOKIE ECHO was
+     received on an existing association. But the COOKIE ECHO added
+     addresses to the association that were previously NOT part
+     of the association. The New addresses are listed in the
+     error code. This ERROR is normally sent as part of an ABORT
+     refusing the Cookie Echo (see section 5.2.4).
+ 
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     Cause Code=11              |      Cause Length=Variable   |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /                  New Address TLVs                             /
+       \                                                               \
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       
+ 
+ 
  3.3.11 Cookie Echo (COOKIE ECHO) (10):
  
     This chunk is used only during the initialization of an association.
***************
*** 2532,2537 ****
--- 2565,2620 ----
     using a 'Supported Address Types' parameter in the new INIT to
     indicate what types of address it prefers.
  
+ 5.1.2.1 Special rules for IPv6 address scoping
+ 
+     When selecting IPv6 addresses to include as parameters in the INIT
+     chunk the following rules MUST be applied:
+ 
+     A1) The INIT chunk MUST NOT include any IPv6 Link Local
+         address parameters.
+ 
+     A2) An IPv6 Link Local address MAY be used as a destination
+         address for an SCTP packet containing an INIT chunk.
+ 
+     A3) If the destination address of the INIT is a Site-Local or
+         Link Local address, then both Site-Local and Global IPv6
+         address parameters SHOULD be included in the INIT chunk.
+ 
+     A4) If the destination address of the INIT is an IPv6 Global 
+         address then the sender MUST NOT include any Site-Local
+         IPv6 address parameters in the INIT chunk.
+ 
+     A5) If the destination address of the INIT is an IPv4 Address
+         then the sender MUST NOT include any Site-Local IPV6 
+         address parameters in the INIT chunk.
+ 
+     When responding to an INIT chunk and selecting IPv6 address
+     parameters to be included in the INIT-ACK chunk, the following rules
+     MUST be applied:
+  
+     B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local
+         address parameters.
+ 
+     B2) If the source address of the SCTP packet containing the INIT
+         chunk is an IPv6 Link-Local address, then both Site-Local and
+         Global IPv6 address parameters SHOULD be included in the 
+         INIT-ACK chunk.
+ 
+     B3) If the source address of the SCTP packet containing the INIT
+         chunk is an IPv6 Site-Local address, then both Site-Local 
+         and Global IPv6 address parameters SHOULD be included in 
+         the INIT-ACK chunk.
+ 
+     B4) If the source address of the SCTP packet containing the INIT
+         chunk is an IPv6 Global address, then the sender MUST NOT 
+         include any Site-Local IPv6 address parameters in the 
+         INIT-ACK chunk.
+ 
+     B5) If the source address of the SCTP packet containing the INIT
+         chunk is an IPv4 address, then the sender MUST NOT 
+         include any Site-Local IPv6 address parameters in the 
+         INIT-ACK chunk.
+ 
  5.1.3 Generating State Cookie
  
     When sending an INIT ACK as a response to an INIT chunk, the sender
***************
*** 2875,2880 ****
--- 2958,2976 ----
        related to this peer MUST be reset to their initial values (see
        Section 6.2.1).
  
+       If the cookie indicates that a new address(es) have been added 
+       to a restarting association, then the entire cookie MUST be discarded.
+       An ABORT MUST be sent that SHOULD include the error 'restart 
+       of an association with new addresses'. The error SHOULD list the
+       addresses that were added to the restarting assocation.
+ 
+     This error should also list the TLV(s) with the new address(es) 
+     that was/were not present in the old association. This would allow 
+     a true restarting association to go through a recovery procedure 
+     (if it desired) to bring back the association.
+ 
+ 
+ 
        After this the endpoint shall enter the ESTABLISHED state.
  
        If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
***************
*** 2907,2913 ****
     Note: The "peer's Verification Tag" is the tag received in the
     Initiate Tag field of the INIT or INIT ACK chunk.
  
! 5.2.4.1 An Example of a Association Restart
  
     In the following example, "A" initiates the association after a
     restart has occurred.  Endpoint "Z" had no knowledge of the restart
--- 3003,3009 ----
     Note: The "peer's Verification Tag" is the tag received in the
     Initiate Tag field of the INIT or INIT ACK chunk.
  
! 5.2.4.1 An Example of an Association Restart
  
     In the following example, "A" initiates the association after a
     restart has occurred.  Endpoint "Z" had no knowledge of the restart
***************
*** 2931,2942 ****
  Tag=Tag_A                                             Tag=Tag_Z
  <--------------------------------------------------------------->
  {A crashes and restarts}
! {app sets up a association with Z}
  (build TCB)
  INIT [I-Tag=Tag_A'
        & other info]  --------\
  (Start T1-init timer)         \
! (Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                        compose temp TCB and Cookie_Z
                                        with Tie-Tags to previous
                                        association)
--- 3027,3038 ----
  Tag=Tag_A                                             Tag=Tag_Z
  <--------------------------------------------------------------->
  {A crashes and restarts}
! {app sets up an association with Z}
  (build TCB)
  INIT [I-Tag=Tag_A'
        & other info]  --------\
  (Start T1-init timer)         \
! (Enter COOKIE-WAIT state)      \---> (find an existing TCB
                                        compose temp TCB and Cookie_Z
                                        with Tie-Tags to previous
                                        association)
***************
*** 3143,3149 ****
  
     B) At any given time, the sender MUST NOT transmit new data to a
        given transport address if it has cwnd or more bytes of data
!       outstanding to that transport address.
  
     C) When the time comes for the sender to transmit, before sending new
        DATA chunks, the sender MUST first transmit any outstanding DATA
--- 3239,3247 ----
  
     B) At any given time, the sender MUST NOT transmit new data to a
        given transport address if it has cwnd or more bytes of data
!       outstanding to that transport address. The sender may exceed
!       cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd
!       is not currently exceeded.
  
     C) When the time comes for the sender to transmit, before sending new
        DATA chunks, the sender MUST first transmit any outstanding DATA
***************
*** 3156,3162 ****
     Multiple DATA chunks committed for transmission MAY be bundled in a
     single packet.  Furthermore, DATA chunks being retransmitted MAY be
     bundled with new DATA chunks, as long as the resulting packet size
!    does not exceed the path MTU.  A ULP may request that no bundling is
     performed but this should only turn off any delays that a SCTP
     implementation may be using to increase bundling efficiency.  It does
     not in itself stop all bundling from occurring (i.e. in case of
--- 3254,3260 ----
     Multiple DATA chunks committed for transmission MAY be bundled in a
     single packet.  Furthermore, DATA chunks being retransmitted MAY be
     bundled with new DATA chunks, as long as the resulting packet size
!    does not exceed the path MTU.  An ULP may request that no bundling is
     performed but this should only turn off any delays that a SCTP
     implementation may be using to increase bundling efficiency.  It does
     not in itself stop all bundling from occurring (i.e. in case of
***************
*** 3225,3231 ****
     chunk format.  In particular, the SCTP endpoint MUST fill in the
     Cumulative TSN Ack field to indicate the latest sequential TSN (of a
     valid DATA chunk) it has received.  Any received DATA chunks with TSN
!    greater than the value in the Cumulative TSN Ack field SHOULD also be
     reported in the Gap Ack Block fields.
  
     Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
--- 3323,3329 ----
     chunk format.  In particular, the SCTP endpoint MUST fill in the
     Cumulative TSN Ack field to indicate the latest sequential TSN (of a
     valid DATA chunk) it has received.  Any received DATA chunks with TSN
!    greater than the value in the Cumulative TSN Ack field MUST also be
     reported in the Gap Ack Block fields.
  
     Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
***************
*** 3768,3777 ****
     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
--- 3866,3875 ----
     the size limit set by the MTU, and leave the remaining highest TSN
     numbers unacknowledged.
  
! 6.8 Fletcher-32 Checksum Calculation
  
     When sending an SCTP packet, the endpoint MUST strengthen the data
!    integrity of the transmission by including the Fletcher-16 checksum
     value calculated on the packet, as described below.
  
     After the packet is constructed (containing the SCTP common header
***************
*** 3780,3803 ****
     1) Fill in the proper Verification Tag in the SCTP common header and
        initialize the checksum field to 0's.
  
!    2) Calculate the Adler-32 checksum of the whole packet, including the
        SCTP common header and all the chunks.  Refer to appendix B for
!       details of the Adler-32 algorithm.  And,
  
     3) Put the resultant value into the checksum field in the common
        header, and leave the rest of the bits unchanged.
  
     When an SCTP packet is received, the receiver MUST first check the
!    Adler-32 checksum:
  
!    1) Store the received Adler-32 checksum value aside,
  
     2) Replace the 32 bits of the checksum field in the received SCTP
!       packet with all '0's and calculate an Adler-32 checksum value of
        the whole received packet.  And,
  
!    3) Verify that the calculated Adler-32 checksum is the same as the
!       received Adler-32 checksum.  If not, the receiver MUST treat the
        packet as an invalid SCTP packet.
  
     The default procedure for handling invalid SCTP packets is to
--- 3878,3901 ----
     1) Fill in the proper Verification Tag in the SCTP common header and
        initialize the checksum field to 0's.
  
!    2) Calculate the Fletcher-16 checksum of the whole packet, including the
        SCTP common header and all the chunks.  Refer to appendix B for
!       details of the Fletcher-16 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
!    Fletcher-16 checksum:
  
!    1) Store the received Fletcher-16 checksum value aside,
  
     2) Replace the 32 bits of the checksum field in the received SCTP
!       packet with all '0's and calculate an Fletcher-16 checksum value of
        the whole received packet.  And,
  
!    3) Verify that the calculated Fletcher-16 checksum is the same as the
!       received Fletcher-16 checksum.  If not, the receiver MUST treat the
        packet as an invalid SCTP packet.
  
     The default procedure for handling invalid SCTP packets is to
***************
*** 4147,4159 ****
        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
--- 4245,4263 ----
        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. When a Fast Retransmit
!       is being performed the sender SHOULD ignore the value of cwnd and
!       SHOULD NOT delay retransmission.
  
     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.
  
+    5) Mark the DATA chunk(s) as being fast retransmitted and thus
+       ineligible for a subsequent fast retransmit until after the 
+       T3-rxt timer expires.
+ 
     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
***************
*** 4167,4172 ****
--- 4271,4283 ----
     TSN's, the effect of TCP fast-recovery is achieved automatically with
     no adjustment to the congestion control window size.
  
+    Upon acknowledgement of a DATA chunk that has been fast retransmitted,
+    the protocol parameter 'Max.Burst' MUST be applied to limit
+    how many SCTP packets may be sent upon the completion of SACK
+    processing. 
+ 
+ 
+ 
  7.3 Path MTU Discovery
  
     [RFC1191] specifies "Path MTU Discovery", whereby an endpoint
***************
*** 4226,4242 ****
  
  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
--- 4337,4354 ----
  
  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,
!     and unacknowledged HEARTBEAT Chunks).  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
***************
*** 4288,4294 ****
     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
--- 4400,4410 ----
     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). HEARTBEAT sending MAY begin upon reaching the
!    ESTABLISHED state, and is discontinued after sending either
!    SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST
!    respond to a HEARTBEAT with a HEARTBEAT-ACK after entering
!    the COOKIE-SENT state up until reaching the CLOSED state.
  
     A destination transport address is considered "idle" if no new chunk
     which can be used for updating path RTT (usually including first
***************
*** 4335,4342 ****
     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
--- 4451,4459 ----
     well).
  
     The receiver of the HEARTBEAT should immediately respond with a
!    HEARTBEAT ACK that contains the Heartbeat Information TLV, together
!    with any other received TLVs, copied unchanged 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
***************
*** 4362,4368 ****
     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).
  
--- 4479,4485 ----
     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 an implementation decision on how to
     choose which of the candidate idle destinations to heartbeat to (if
     more than one destination is idle).
  
***************
*** 4380,4386 ****
  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.
  
--- 4497,4503 ----
  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 Fletcher-16 check (see
     Section 6.8), but the receiver is not able to identify the
     association to which this packet belongs.
  
***************
*** 4573,4579 ****
        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
--- 4690,4696 ----
        SHUTDOWN sender.
  
     Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT
!    send a SHUTDOWN in response to an ULP request, and should discard
     subsequent SHUTDOWN chunks.
  
     If there are still outstanding DATA chunks left, the SHUTDOWN
***************
*** 4664,4670 ****
  
  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.
  
--- 4781,4787 ----
  
  10.1 ULP-to-SCTP
  
!    The following sections functionally characterize an ULP/SCTP
     interface.  The notation used is similar to most procedure or
     function calls in high level languages.
  
***************
*** 5750,5755 ****
--- 5867,5875 ----
        instances of this parameter type may be found within the same
        chunk.
  
+    e) Each parameter type MUST be unique across all chunks. 
+ 
+ 
  13.3 IETF-defined Additional Error Causes
  
     Additional cause codes may be allocated in the range 11 to 65535
***************
*** 5791,5800 ****
  
     RTO.Initial              - 3  seconds
     RTO.Min                  - 1  second
!    RTO.Max                 -  60 seconds
     RTO.Alpha                - 1/8
     RTO.Beta                 - 1/4
!    Valid.Cookie.Life        - 60  seconds
     Association.Max.Retrans  - 10 attempts
     Path.Max.Retrans         - 5  attempts (per destination address)
     Max.Init.Retransmits     - 8  attempts
--- 5911,5921 ----
  
     RTO.Initial              - 3  seconds
     RTO.Min                  - 1  second
!    RTO.Max                  - 60 seconds
!    Max.Burst                - 4  packets
     RTO.Alpha                - 1/8
     RTO.Beta                 - 1/4
!    Valid.Cookie.Life        - 60 seconds
     Association.Max.Retrans  - 10 attempts
     Path.Max.Retrans         - 5  attempts (per destination address)
     Max.Init.Retransmits     - 8  attempts
***************
*** 6068,6084 ****
  
        Note: The CWR is considered a Control chunk.
  
- Appendix B Alder 32 bit checksum calculation
  
!    The Adler-32 checksum calculation given in this appendix is copied from
!    [RFC1950].
  
!    Adler-32 is composed of two sums accumulated per byte: s1 is the sum
!    of all bytes, s2 is the sum of all s1 values.  Both sums are done
!    modulo 65521.  s1 is initialized to 1, s2 to zero.  The Adler-32
!    checksum is stored as s2*65536 + s1 in network byte order.
  
!    The following C code computes the Adler-32 checksum of a data buffer.
     It is written for clarity, not for speed.  The sample code is in the
     ANSI C programming language.  Non C users may find it easier to read
     with these hints:
--- 6189,6220 ----
  
        Note: The CWR is considered a Control chunk.

!    Appendix B Fletcher-16 checksum
  
!    The 16-bit Fletcher Checksum Algorithm is calculated over a sequence
!    of 16 bit data quantities (call them D[1] through D[N]) by maintaining 
!    2 unsigned 1's-complement 16-bit accumulators A and B whose contents are
!    initially zero, and performing the following loop where i ranges from
!    1 to N:
! 
!            A := A + D[i]
!            B := B + A
! 
!    It can be shown that at the end of the loop A will contain the 16-bit
!    1's complement sum of all octets in the datagram, and that B will
!    contain (N)D[1] + (N-1)D[2] + ... + D[N].
! 
!    The octets covered by this algorithm should be the entire SCTP
!    packet including the Common header and all chunks. Note that, 
!    for purposes of the checksum computation, the checksum field 
!    itself must be equal to zero.
! 
!    The result of the checksum should be placed in the 32-bit checksum
!    field with B being placed in the most signifigant bit postion and
!    A being placed in the least signifigant position.
  
!    The following C code computes the Fletcher-16 checksum of a data buffer.
     It is written for clarity, not for speed.  The sample code is in the
     ANSI C programming language.  Non C users may find it easier to read
     with these hints:
***************
*** 6091,6130 ****
            bit(s) at the right.
     ++     "n++" increments the variable n.
     %      modulo operator: a % b is the remainder of a divided by b.
!     #define BASE 65521 /* largest prime smaller than 65536 */
      /*
!       Update a running Adler-32 checksum with the bytes buf[0..len-1]
!       and return the updated checksum.  The Adler-32 checksum should be
!       initialized to 1.
! 
!        Usage example:
! 
!          unsigned long adler = 1L;
! 
!          while (read_buffer(buffer, length) != EOF) {
!            adler = update_adler32(adler, buffer, length);
!          }
!          if (adler != original_adler) error();
!       */
!       unsigned long update_adler32(unsigned long adler,
!          unsigned char *buf, int len)
        {
!         unsigned long s1 = adler & 0xffff;
!         unsigned long s2 = (adler >> 16) & 0xffff;
!         int n;
! 
!         for (n = 0; n < len; n++) {
!           s1 = (s1 + buf[n]) % BASE;
!           s2 = (s2 + s1)     % BASE;
          }
!         return (s2 << 16) + s1;
!       }
  
-       /* Return the adler32 of the bytes buf[0..len-1] */
-       unsigned long adler32(unsigned char *buf, int len)
-       {
-         return update_adler32(1L, buf, len);
-       }
  
  Full Copyright Statement
  
--- 6227,6276 ----
            bit(s) at the right.
     ++     "n++" increments the variable n.
     %      modulo operator: a % b is the remainder of a divided by b.
! 
      /*
!       Update a running Fletcher-16 checksum with the bytes buf[0..len-1]
!       and return the updated checksum.  The checksum should be
!       initialized to 0.
! 
!        Usage example (assuming buf is a sctp packet):
!                unsigned int sum,insum,*inp;
! 
!                inp = &buf[8];
!                insum = *inp;
! 	       *inp = 0;
!                sum = fletcher(buf, length);
! 	       if(sum != insum){
!                   /* drop packet, csum error */
! 	       }
!      */
!       unsigned int fletcher(unsigned char *buf, int len)
        {
!         unsigned long s1 = 0;
! 	unsigned long s2 = 0;
! 	unsigned short *bufp;
!         int n,nlen;
!         nlen = len / 2;
! 
!         bufp = (unsigned short *)buf;
!         for (n = 0; n < nlen; n++,bufp++) {
!             s1 = ((s1 + *bufp) & 0x0000ffff);
!             s2 = ((s2 + s1) & 0x0000ffff);
          }
!         if(len > (nlen *2)){
!          /* do the odd byte, we don't
!           * expect this code to execute,
!           * since SCTP does NOT have Odd byte
!           * messages.
!           */
!           unsigned short x;
!           x = buf[(len-1)] << 8 | 0;
!           s1 = ((s1 + x) & 0x0000ffff);
!           s2 = ((s2 + s1) & 0x0000ffff);
!         }
!         return ((unsigned int)(s2 << 16) + s1);
!      }

  Full Copyright Statement