Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8540

Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Pages: 94
Obsoleted by:  9260
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