Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8540

Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Pages: 94
Group: TSVWG
Informational
Part 6 of 7 – Pages 70 to 91
First   Prev   Next

Top   ToC   RFC8540 - Page 70   prevText
3.44.  Integration of RFC 6335

3.44.1.  Description of the Problem

   [RFC6335] updates [RFC4960] by updating procedures for the "Service
   Name and Transport Protocol Port Number Registry".  This should be
   integrated into the base specification.  Also, the "Guidelines for
   Writing an IANA Considerations Section in RFCs" reference needs to be
   changed to [RFC8126].

3.44.2.  Text Changes to the Document

   ---------
   Old text: (Section 14.5)
   ---------

   SCTP services may use contact port numbers to provide service to
   unknown callers, as in TCP and UDP.  IANA is therefore requested to
   open the existing Port Numbers registry for SCTP using the following
   rules, which we intend to mesh well with existing Port Numbers
   registration procedures.  An IESG-appointed Expert Reviewer supports
   IANA in evaluating SCTP port allocation requests, according to the
   procedure defined in [RFC2434].

   Port numbers are divided into three ranges.  The Well Known Ports are
   those from 0 through 1023, the Registered Ports are those from 1024
   through 49151, and the Dynamic and/or Private Ports are those from
   49152 through 65535.  Well Known and Registered Ports are intended
   for use by server applications that desire a default contact point on
   a system.  On most systems, Well Known Ports can only be used by
   system (or root) processes or by programs executed by privileged
   users, while Registered Ports can be used by ordinary user processes
   or programs executed by ordinary users.  Dynamic and/or Private Ports
   are intended for temporary use, including client-side ports, out-of-
   band negotiated ports, and application testing prior to registration
   of a dedicated port; they MUST NOT be registered.

   The Port Numbers registry should accept registrations for SCTP ports
   in the Well Known Ports and Registered Ports ranges.  Well Known and
   Registered Ports SHOULD NOT be used without registration.  Although
   in some cases -- such as porting an application from TCP to SCTP --
   it may seem natural to use an SCTP port before registration
   completes, we emphasize that IANA will not guarantee registration of
   particular Well Known and Registered Ports.  Registrations should be
   requested as early as possible.
Top   ToC   RFC8540 - Page 71
   Each port registration SHALL include the following information:

   o  A short port name, consisting entirely of letters (A-Z and a-z),
      digits (0-9), and punctuation characters from "-_+./*" (not
      including the quotes).

   o  The port number that is requested for registration.

   o  A short English phrase describing the port's purpose.

   o  Name and contact information for the person or entity performing
      the registration, and possibly a reference to a document defining
      the port's use.  Registrations coming from IETF working groups
      need only name the working group, but indicating a contact person
      is recommended.

   Registrants are encouraged to follow these guidelines when submitting
   a registration.

   o  A port name SHOULD NOT be registered for more than one SCTP port
      number.

   o  A port name registered for TCP MAY be registered for SCTP as well.
      Any such registration SHOULD use the same port number as the
      existing TCP registration.

   o  Concrete intent to use a port SHOULD precede port registration.
      For example, existing TCP ports SHOULD NOT be registered in
      advance of any intent to use those ports for SCTP.

   ---------
   New text: (Section 14.5)
   ---------

   SCTP services can use contact port numbers to provide service to
   unknown callers, as in TCP and UDP.  IANA is therefore requested to
   open the existing "Service Name and Transport Protocol Port Number
   Registry" for SCTP using the following rules, which we intend to mesh
   well with existing port-number registration procedures.  An
   IESG-appointed expert reviewer supports IANA in evaluating SCTP port
   allocation requests, according to the procedure defined in [RFC8126].
   The details of this process are defined in [RFC6335].

   This text is in final form and is not further updated in this
   document.
Top   ToC   RFC8540 - Page 72
3.44.3.  Solution Description

   [RFC6335] has been integrated, and the reference has been updated to
   [RFC8126].

3.45.  Integration of RFC 7053

3.45.1.  Description of the Problem

   [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk.
   This should be integrated into the base specification.

3.45.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.1)
   ---------

   The following format MUST be used 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 = 0    | Reserved|U|B|E|    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              TSN                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      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.
Top   ToC   RFC8540 - Page 73
   ---------
   New text: (Section 3.3.1)
   ---------

   The following format MUST be used 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 = 0    |  Res  |I|U|B|E|    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              TSN                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Stream Identifier S      |   Stream Sequence Number n    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Payload Protocol Identifier                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                 User Data (seq n of Stream S)                 /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Res: 4 bits

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

   I bit: 1 bit

      The (I)mmediate bit MAY be set by the sender whenever the sender
      of a DATA chunk can benefit from the corresponding SACK chunk
      being sent back without delay.  See Section 4 of [RFC7053] for a
      discussion of the benefits.

   This text is in final form and is not further updated in this
   document.
Top   ToC   RFC8540 - Page 74
   ---------
   New text: (Append to Section 6.1)
   ---------

   Whenever the sender of a DATA chunk can benefit from the
   corresponding SACK chunk being sent back without delay, the sender
   MAY set the I bit in the DATA chunk header.  Please note that why the
   sender has set the I bit is irrelevant to the receiver.

   Reasons for setting the I bit include, but are not limited to, the
   following (see Section 4 of [RFC7053] for a discussion of the
   benefits):

   o  The application requests that the I bit of the last DATA chunk of
      a user message be set when providing the user message to the SCTP
      implementation (see Section 7).

   o  The sender is in the SHUTDOWN-PENDING state.

   o  The sending of a DATA chunk fills the congestion or receiver
      window.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 6.2)
   ---------

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

   ---------
   New text: (Section 6.2)
   ---------

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

   Upon receipt of an SCTP packet containing a DATA chunk with the I bit
   set, the receiver SHOULD NOT delay the sending of the corresponding
   SACK chunk, i.e., the receiver SHOULD immediately respond with the
   corresponding SACK chunk.

   Please note that this change is only about adding a paragraph.
Top   ToC   RFC8540 - Page 75
   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 10.1 E))
   ---------

   E) Send

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

   ---------
   New text: (Section 10.1 E))
   ---------

   E) Send

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

   This text is in final form and is not further updated in this
   document.

   ---------
   New text: (Append optional parameter in item E) of Section 10.1)
   ---------

   o  sack-immediately flag - set the I bit on the last DATA chunk used
      for the user message to be transmitted.

   This text is in final form and is not further updated in this
   document.

3.45.3.  Solution Description

   [RFC7053] has been integrated.
Top   ToC   RFC8540 - Page 76
3.46.  CRC32c Code Improvements

3.46.1.  Description of the Problem

   The code given for the CRC32c computations uses types such as "long",
   which may have different lengths on different operating systems or
   processors.  Therefore, the code needs to be changed, so that it uses
   specific types such as uint32_t.

   Some syntax errors and a comment also need to be fixed.

   We remind the reader that per Section 3.10.2 of this document most of
   Appendix C of RFC 4960 will be moved to Appendix B in the bis
   document (thus the "Old text: (Appendix C)" and "New text:
   (Appendix B)" items in this section).
Top   ToC   RFC8540 - Page 77
3.46.2.  Text Changes to the Document

   ---------
   Old text: (Appendix C)
   ---------

   /*************************************************************/
   /* Note Definition for Ross Williams table generator would   */
   /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE        */
   /* For Mr. Williams direct calculation code use the settings */
   /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,      */
   /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000        */
   /*************************************************************/

   /* Example of the crc table file */
   #ifndef __crc32cr_table_h__
   #define __crc32cr_table_h__

   #define CRC32C_POLY 0x1EDC6F41
   #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])

   unsigned long  crc_c[256] =
   {
   0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
   0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
   0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
   0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
   0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
   0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
   0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
   0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
   0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
   0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
   0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
   0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
   0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,

   0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
   0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
   0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
   0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
   0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
   0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
   0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
   0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
   0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
   0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
   0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
Top   ToC   RFC8540 - Page 78
   0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
   0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
   0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
   0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
   0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
   0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
   0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,
   0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
   0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
   0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
   0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
   0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
   0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
   0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
   0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
   0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
   0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
   0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
   0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
   0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
   0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
   0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
   0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
   0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
   0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
   0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
   0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
   0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
   0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
   0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
   0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
   0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
   0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
   0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
   0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
   0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
   0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,

   0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
   0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
   0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
   };

   #endif
Top   ToC   RFC8540 - Page 79
   ---------
   New text: (Appendix B)
   ---------

   <CODE BEGINS>
   /****************************************************************/
   /* Note: The definitions for Ross Williams's table generator    */
   /* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE.      */
   /* For Mr. Williams's direct calculation code, use the settings */
   /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,         */
   /* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000.           */
   /****************************************************************/

   /* Example of the crc table file */
   #ifndef __crc32cr_h__
   #define __crc32cr_h__

   #define CRC32C_POLY 0x1EDC6F41UL
   #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])

   uint32_t crc_c[256] =
   {
   0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL,
   0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL,
   0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL,
   0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL,
   0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL,
   0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL,
   0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL,
   0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL,
   0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL,
   0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL,
   0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL,
   0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL,
   0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL,
   0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL,
   0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL,
   0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL,
   0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL,
   0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL,
   0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL,
   0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL,
   0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL,
   0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL,
   0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL,
   0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL,
   0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL,
   0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL,
Top   ToC   RFC8540 - Page 80
   0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL,
   0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL,
   0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL,
   0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL,
   0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL,
   0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL,
   0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL,
   0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL,
   0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL,
   0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL,
   0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL,
   0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL,
   0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL,
   0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL,
   0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL,
   0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL,
   0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL,
   0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL,
   0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL,
   0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL,
   0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL,
   0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL,
   0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL,
   0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL,
   0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL,
   0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL,
   0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL,
   0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL,
   0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL,
   0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL,
   0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL,
   0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL,
   0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL,
   0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL,
   0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL,
   0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL,
   0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL,
   0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL,
   };

   #endif

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.10.  It is in final form and is not
   further updated in this document.
Top   ToC   RFC8540 - Page 81
   ---------
   Old text: (Appendix C)
   ---------

   /* Example of table build routine */

   #include <stdio.h>
   #include <stdlib.h>

   #define OUTPUT_FILE   "crc32cr.h"
   #define CRC32C_POLY    0x1EDC6F41L
   FILE *tf;
   unsigned long
   reflect_32 (unsigned long b)
   {
     int i;
     unsigned long rw = 0L;

     for (i = 0; i < 32; i++){
         if (b & 1)
           rw |= 1 << (31 - i);
         b >>= 1;
     }
     return (rw);
   }

   unsigned long
   build_crc_table (int index)
   {
     int i;
     unsigned long rb;

     rb = reflect_32 (index);

     for (i = 0; i < 8; i++){
         if (rb & 0x80000000L)
          rb = (rb << 1) ^ CRC32C_POLY;
         else
          rb <<= 1;
     }
     return (reflect_32 (rb));
   }

   main ()

   {
     int i;
Top   ToC   RFC8540 - Page 82
     printf ("\nGenerating CRC-32c table file <%s>\n",
     OUTPUT_FILE);
     if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
         printf ("Unable to open %s\n", OUTPUT_FILE);
         exit (1);
     }
     fprintf (tf, "#ifndef __crc32cr_table_h__\n");
     fprintf (tf, "#define __crc32cr_table_h__\n\n");
     fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
     CRC32C_POLY);
     fprintf (tf,
     "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
     fprintf (tf, "\nunsigned long  crc_c[256] =\n{\n");
     for (i = 0; i < 256; i++){
         fprintf (tf, "0x%08lXL, ", build_crc_table (i));
         if ((i & 3) == 3)
           fprintf (tf, "\n");
     }
     fprintf (tf, "};\n\n#endif\n");

     if (fclose (tf) != 0)
       printf ("Unable to close <%s>." OUTPUT_FILE);
     else
       printf ("\nThe CRC-32c table has been written to <%s>.\n",
         OUTPUT_FILE);
   }

   ---------
   New text: (Appendix B)
   ---------

   /* Example of table build routine */

   #include <stdio.h>
   #include <stdlib.h>

   #define OUTPUT_FILE   "crc32cr.h"
   #define CRC32C_POLY    0x1EDC6F41UL

   static FILE *tf;

   static uint32_t
   reflect_32(uint32_t b)
   {
     int i;
     uint32_t rw = 0UL;

     for (i = 0; i < 32; i++) {
Top   ToC   RFC8540 - Page 83
         if (b & 1)
           rw |= 1 << (31 - i);
         b >>= 1;
     }
     return (rw);
   }

   static uint32_t
   build_crc_table (int index)
   {
     int i;
     uint32_t rb;

     rb = reflect_32(index);

     for (i = 0; i < 8; i++) {
         if (rb & 0x80000000UL)
          rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
         else
          rb <<= 1;
     }
     return (reflect_32(rb));
   }

   int
   main (void)
   {
     int i;

     printf("\nGenerating CRC32c table file <%s>.\n",
     OUTPUT_FILE);
     if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) {
         printf("Unable to open %s.\n", OUTPUT_FILE);
         exit (1);
     }
     fprintf(tf, "#ifndef __crc32cr_h__\n");
     fprintf(tf, "#define __crc32cr_h__\n\n");
     fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
       (uint32_t)CRC32C_POLY);
     fprintf(tf,
       "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
     fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
     for (i = 0; i < 256; i++) {
         fprintf(tf, "0x%08XUL,", build_crc_table (i));
         if ((i & 3) == 3)
Top   ToC   RFC8540 - Page 84
           fprintf(tf, "\n");
         else
           fprintf(tf, " ");
     }
     fprintf(tf, "};\n\n#endif\n");

     if (fclose(tf) != 0)
       printf("Unable to close <%s>.\n", OUTPUT_FILE);
     else
       printf("\nThe CRC32c table has been written to <%s>.\n",
         OUTPUT_FILE);
   }

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.10.  It is in final form and is not
   further updated in this document.

   ---------
   Old text: (Appendix C)
   ---------

   /* Example of crc insertion */

   #include "crc32cr.h"

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = ~0L;
     unsigned long result;
     unsigned char byte0,byte1,byte2,byte3;

     for (i = 0; i < length; i++){
         CRC32C(crc32, buffer[i]);
     }

     result = ~crc32;

     /*  result now holds the negated polynomial remainder;
      *  since the table and algorithm is "reflected" [williams95].
      *  That is, result has the same value as if we mapped the message
      *  to a polynomial, computed the host-bit-order polynomial
      *  remainder, performed final negation, then did an end-for-end
      *  bit-reversal.
      *  Note that a 32-bit bit-reversal is identical to four inplace
      *  8-bit reversals followed by an end-for-end byteswap.
      *  In other words, the bytes of each bit are in the right order,
Top   ToC   RFC8540 - Page 85
      *  but the bytes have been byteswapped.  So we now do an explicit
      *  byteswap.  On a little-endian machine, this byteswap and
      *  the final ntohl cancel out and could be elided.
      */

     byte0 = result & 0xff;
     byte1 = (result>>8) & 0xff;
     byte2 = (result>>16) & 0xff;
     byte3 = (result>>24) & 0xff;
     crc32 = ((byte0 << 24) |
              (byte1 << 16) |
              (byte2 << 8)  |
              byte3);
     return ( crc32 );
   }

   int
   insert_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned long crc32;
     message = (SCTP_message *) buffer;
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     /* and insert it into the message */
     message->common_header.checksum = htonl(crc32);
     return 1;
   }

   int
   validate_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned int i;
     unsigned long original_crc32;
     unsigned long crc32 = ~0L;

     /* save and zero checksum */
     message = (SCTP_message *) buffer;
     original_crc32 = ntohl(message->common_header.checksum);
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     return ((original_crc32 == crc32)? 1 : -1);
   }
Top   ToC   RFC8540 - Page 86
   ---------
   New text: (Appendix B)
   ---------

   /* Example of crc insertion */

   #include "crc32cr.h"

   uint32_t
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     uint32_t crc32 = 0xffffffffUL;
     uint32_t result;
     uint8_t byte0, byte1, byte2, byte3;

     for (i = 0; i < length; i++) {
         CRC32C(crc32, buffer[i]);
     }

     result = ~crc32;

     /*  result now holds the negated polynomial remainder,
      *  since the table and algorithm are "reflected" [williams95].
      *  That is, result has the same value as if we mapped the message
      *  to a polynomial, computed the host-bit-order polynomial
      *  remainder, performed final negation, and then did an
      *  end-for-end bit-reversal.
      *  Note that a 32-bit bit-reversal is identical to four in-place
      *  8-bit bit-reversals followed by an end-for-end byteswap.
      *  In other words, the bits of each byte are in the right order,
      *  but the bytes have been byteswapped.  So, we now do an explicit
      *  byteswap.  On a little-endian machine, this byteswap and
      *  the final ntohl cancel out and could be elided.
      */

     byte0 = result & 0xff;
     byte1 = (result>>8) & 0xff;
     byte2 = (result>>16) & 0xff;
     byte3 = (result>>24) & 0xff;
     crc32 = ((byte0 << 24) |
              (byte1 << 16) |
              (byte2 << 8)  |
              byte3);
     return (crc32);
   }

   int
Top   ToC   RFC8540 - Page 87
   insert_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     uint32_t crc32;
     message = (SCTP_message *) buffer;
     message->common_header.checksum = 0UL;
     crc32 = generate_crc32c(buffer,length);
     /* and insert it into the message */
     message->common_header.checksum = htonl(crc32);
     return 1;
   }

   int
   validate_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned int i;
     uint32_t original_crc32;
     uint32_t crc32;

     /* save and zero checksum */
     message = (SCTP_message *)buffer;
     original_crc32 = ntohl(message->common_header.checksum);
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer, length);
     return ((original_crc32 == crc32)? 1 : -1);
   }
   <CODE ENDS>

   This text has been modified by multiple errata.  It includes
   modifications from Sections 3.5 and 3.10.  It is in final form and is
   not further updated in this document.

3.46.3.  Solution Description

   The code was changed to use platform-independent types.

3.47.  Clarification of Gap Ack Blocks in SACK Chunks

3.47.1.  Description of the Problem

   The Gap Ack Blocks in the SACK chunk are intended to be isolated.
   However, this is not mentioned with normative text.

   This issue was reported as part of an errata for [RFC4960] with
   Errata ID 5202.
Top   ToC   RFC8540 - Page 88
3.47.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.4)
   ---------

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

   ---------
   New text: (Section 3.3.4)
   ---------

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  The Gap Ack Blocks SHOULD be
   isolated.  This means that the TSN just before each Gap Ack Block and
   the TSN just after each Gap Ack Block have not been received.  By
   definition, all TSNs acknowledged by Gap Ack Blocks are greater than
   the value of the Cumulative TSN Ack.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 3.3.4)
   ---------

   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 TSNs
      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been received
      correctly.
Top   ToC   RFC8540 - Page 89
   ---------
   New text: (Section 3.3.4)
   ---------

   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 TSNs
      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been received
      correctly.  Gap Ack Blocks SHOULD be isolated.  This means that
      the DATA chunks with TSNs equal to (Cumulative TSN Ack + Gap Ack
      Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1)
      have not been received.

   This text is in final form and is not further updated in this
   document.

3.47.3.  Solution Description

   Normative text describing the intended usage of Gap Ack Blocks has
   been added.

3.48.  Handling of SSN Wraparounds

3.48.1.  Description of the Problem

   The Stream Sequence Number (SSN) is used for preserving the ordering
   of user messages within each SCTP stream.  The SSN is limited to
   16 bits.  Therefore, multiple wraparounds of the SSN might happen
   within the current send window.  To allow the receiver to deliver
   ordered user messages in the correct sequence, the sender should
   limit the number of user messages per stream.

3.48.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.
Top   ToC   RFC8540 - Page 90
   ---------
   New text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than
   2**31 - 1 above the beginning TSN of the current send window.
   Note: For each stream, the data sender SHOULD NOT have more than
   2**16 - 1 ordered user messages in the current send window.

   This text is in final form and is not further updated in this
   document.

3.48.3.  Solution Description

   The data sender is required to limit the number of ordered user
   messages within the current send window.

3.49.  Update to RFC 2119 Boilerplate Text

3.49.1.  Description of the Problem

   The text to be used to refer to the terms ("key words") defined in
   [RFC2119] has been updated by [RFC8174].  This needs to be integrated
   into the base specification.

3.49.2.  Text Changes to the Document

   ---------
   Old text: (Section 2)
   ---------

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   ---------
   New text: (Section 2)
   ---------

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This text is in final form and is not further updated in this
   document.
Top   ToC   RFC8540 - Page 91
3.49.3.  Solution Description

   The text has been updated to the text specified in [RFC8174].

3.50.  Removal of Text (Previously Missed in RFC 4960)

3.50.1.  Description of the Problem

   When integrating the changes to Section 7.2.4 of [RFC2960] as
   described in Section 2.8.2 of [RFC4460], some text was not removed
   and is therefore still in [RFC4960].

3.50.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.4)
   ---------

   A straightforward implementation of the above keeps a counter for
   each TSN hole reported by a SACK.  The counter increments for each
   consecutive SACK reporting the TSN hole.  After reaching 3 and
   starting the Fast-Retransmit procedure, the counter resets to 0.
   Because cwnd in SCTP indirectly bounds the number of outstanding
   TSN's, the effect of TCP Fast Recovery is achieved automatically with
   no adjustment to the congestion control window size.

   ---------
   New text: (Section 7.2.4)
   ---------

   This text is in final form and is not further updated in this
   document.

3.50.3.  Solution Description

   The text has finally been removed.



(page 91 continued on part 7)

Next Section