This repository has been archived by the owner on Jun 9, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
/
rfc9260.xml
7158 lines (6772 loc) · 345 KB
/
rfc9260.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
xml:lang="en"
ipr="pre5378Trust200902"
submissionType="IETF"
consensus="true"
category="std"
docName="draft-ietf-tsvwg-rfc4960-bis-19"
obsoletes="4460, 4960, 6096, 7053, 8540"
version="3"
tocInclude="true"
tocDepth="4"
number="9260"
sortRefs="false"
symRefs="true">
<front>
<title>Stream Control Transmission Protocol</title>
<seriesInfo name="RFC" value="9260"/>
<author initials="R." surname="Stewart" fullname="Randall R. Stewart">
<organization>Netflix, Inc.</organization>
<address>
<postal>
<street>2455 Heritage Green Ave</street>
<city>Davenport</city>
<region>FL</region>
<code>33837</code>
<country>United States of America</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization abbrev='Münster Univ. of Appl. Sciences'>
Münster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city>Steinfurt</city>
<country>Germany</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="K." surname="Nielsen" fullname="Karen E. E. Nielsen">
<organization>Kamstrup A/S</organization>
<address>
<postal>
<street>Industrivej 28</street>
<code>DK-8660</code>
<city>Skanderborg</city>
<country>Denmark</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date month="April" year="2022"/>
<abstract>
<t>This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the
specification of the I bit of DATA chunks from RFC 7053.
Therefore, RFCs 6096 and 7053 are also obsoleted by this document.
In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.
</t>
<t>SCTP was originally designed to transport Public Switched Telephone
Network (PSTN) signaling messages over IP networks.
It is also suited to be used for other applications, for example, WebRTC.</t>
<t>SCTP is a reliable transport protocol operating on top of a
connectionless packet network, such as IP.
It offers the following services to its users:</t>
<ul>
<li><t>acknowledged error-free, non-duplicated transfer of user data,</t></li>
<li><t>data fragmentation to conform to discovered Path Maximum Transmission Unit (PMTU) size,</t></li>
<li><t>sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user messages,</t></li>
<li><t>optional bundling of multiple user messages into a single SCTP packet, and</t></li>
<li><t>network-level fault tolerance through supporting of multi-homing
at either or both ends of an association.</t></li>
</ul>
<t>The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description
of the protocol.</t>
<t>This document obsoletes <xref target="RFC4960"/>.
In addition to that, it incorporates the specification of the chunk flags
registry from <xref target="RFC6096"/> and the specification of the I bit of
DATA chunks from <xref target="RFC7053"/>.
Therefore, <xref target="RFC6096"/> and <xref target="RFC7053"/> are also
obsoleted by this document.</t>
<section>
<name>Motivation</name>
<t>TCP <xref target="RFC0793"/> has performed immense service as the primary
means of reliable data transfer in IP networks.
However, an increasing number of recent applications have found TCP too
limiting and have incorporated their own reliable data transfer protocol
on top of UDP <xref target="RFC0768"/>.
The limitations that users have wished to bypass include the following:</t>
<ul>
<li><t>TCP provides both reliable data transfer and strict
order-of-transmission delivery of data.
Some applications need reliable transfer without sequence maintenance,
while others would be satisfied with partial ordering of the data.
In both of these cases, the head-of-line blocking offered by TCP causes
unnecessary delay.</t></li>
<li><t>The stream-oriented nature of TCP is often an inconvenience.
Applications add their own record marking to delineate their
messages and make explicit use of the push facility to
ensure that a complete message is transferred in a reasonable
time.</t></li>
<li><t>The limited scope of TCP sockets complicates the task of providing
highly available data transfer capability using multi-homed hosts.</t></li>
<li><t>TCP is relatively vulnerable to denial-of-service attacks, such
as SYN attacks.</t></li>
</ul>
<t>Transport of PSTN signaling across the IP network is an application
for which all of these limitations of TCP are relevant.
While this application directly motivated the development of SCTP, other
applications might find SCTP a good match to their requirements.
One example of this is the use of data channels in the WebRTC infrastructure.</t>
</section>
<section>
<name>Architectural View of SCTP</name>
<t>SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and a connectionless packet network service, such as
IP.
The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of user
messages between peer SCTP users.
It performs this service within the context of an association between
two SCTP endpoints.
<xref target='sec_api'/> of this document sketches the API that exists
at the boundary between SCTP and the SCTP upper layers.</t>
<t>SCTP is connection oriented in nature, but the SCTP association is a
broader concept than the TCP connection.
SCTP provides the means for each SCTP endpoint (<xref target="sec_key_terms"/>)
to provide the other endpoint (during association startup) with a list of
transport addresses (i.e., multiple IP addresses in combination with an SCTP
port) through which that endpoint can be reached and from which it will
originate SCTP packets.
The association spans transfers over all of the possible source/destination
combinations that can be generated from each endpoint's lists.</t>
<figure anchor='fig_association'
title='An SCTP Association'>
<artwork align='center'>
<![CDATA[
_____________ _____________
| SCTP User | | SCTP User |
| Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B
]]>
</artwork>
</figure>
<t>In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also possible
to encapsulate SCTP packets in UDP as specified in <xref target="RFC6951"/>
or encapsulate them in DTLS as specified in <xref target="RFC8261"/>.</t>
</section>
<section anchor='sec_key_terms'>
<name>Key Terms</name>
<t>Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the
key terms and their definitions.</t>
<dl newline="false">
<dt>Active Destination Transport Address:</dt>
<dd>A transport address on a peer endpoint that a transmitting endpoint considers
available for receiving user messages.</dd>
<dt>Association Maximum DATA Chunk Size (AMDCS):</dt>
<dd>The smallest Path Maximum DATA Chunk Size (PMDCS) of all destination
addresses.</dd>
<dt>Bundling of Chunks:</dt>
<dd>An optional multiplexing operation, whereby more than one chunk can
be carried in the same SCTP packet.</dd>
<dt>Bundling of User Messages:</dt>
<dd>An optional multiplexing operation, whereby more than one user message can
be carried in the same SCTP packet. Each user message occupies its own DATA chunk.</dd>
<dt>Chunk:</dt>
<dd>A unit of information within an SCTP packet, consisting of a chunk header
and chunk-specific content.</dd>
<dt>Congestion Window (cwnd):</dt>
<dd>An SCTP variable that limits outstanding data, in number of bytes,
that a sender can send to a particular destination transport address before
receiving an acknowledgement.</dd>
<dt>Control Chunk:</dt>
<dd>A chunk not being used for transmitting user data, i.e., every chunk that
is not a DATA chunk.</dd>
<dt>Cumulative TSN Ack Point:</dt>
<dd>The Transmission Sequence Number (TSN) of the last DATA chunk acknowledged via
the Cumulative TSN Ack field of a SACK chunk.</dd>
<dt>Flightsize:</dt>
<dd>The number of bytes of outstanding data to a particular destination transport
address at any given time.</dd>
<dt>Idle Destination Address:</dt>
<dd>An address that has not had user messages sent to it within some length
of time, normally the 'HB.interval' or greater.</dd>
<dt>Inactive Destination Transport Address:</dt>
<dd>An address that is considered inactive due to errors and unavailable to
transport user messages.</dd>
<dt>Message (or User Message):</dt>
<dd>Data submitted to SCTP by the Upper-Layer Protocol (ULP).</dd>
<dt>Network Byte Order:</dt>
<dd>Most significant byte first, a.k.a., big endian.</dd>
<dt>Ordered Message:</dt>
<dd>A user message that is delivered in order with respect to all previous user
messages sent within the stream on which the message was sent.</dd>
<dt>Outstanding Data (or Data Outstanding or Data In Flight):</dt>
<dd>The total size of the DATA chunks associated with outstanding TSNs.
A retransmitted DATA chunk is counted once in outstanding data.
A DATA chunk that is classified as lost but that has not yet been
retransmitted is not in outstanding data.</dd>
<dt>Outstanding TSN (at an SCTP Endpoint):</dt>
<dd>A TSN (and the associated DATA chunk) that has been sent by the endpoint
but for which it has not yet received an acknowledgement.</dd>
<dt>"Out of the Blue" (OOTB) Packet:</dt>
<dd>A correctly formed packet, for which the receiver cannot identify the
association it belongs to. See <xref target='sec_handle_out_of_the_blue_packets'/>.</dd>
<dt>Path:</dt>
<dd>The route taken by the SCTP packets sent by one SCTP endpoint to a specific
destination transport address of its peer SCTP endpoint.
Sending to different destination transport addresses does not necessarily
guarantee getting separate paths.
Within this specification, a path is identified by the destination transport
address, since the routing is assumed to be stable.
This includes, in particular, the source address being selected when sending
packets to the destination address.</dd>
<dt>Path Maximum DATA Chunk Size (PMDCS):</dt>
<dd>The maximum size (including the DATA chunk header) of a DATA chunk that fits
into an SCTP packet not exceeding the PMTU of a particular destination address.</dd>
<dt>Path Maximum Transmission Unit (PMTU):</dt>
<dd>The maximum size (including the SCTP common header and all chunks including
their paddings) of an SCTP packet that can be sent to a particular
destination address without using IP-level fragmentation.</dd>
<dt>Primary Path:</dt>
<dd>The destination and source address that will be put into
a packet outbound to the peer endpoint by default.
The definition includes the source address since an implementation <bcp14>MAY</bcp14> wish
to specify both destination and source address to better control the return
path taken by reply chunks and on which interface the packet is transmitted
when the data sender is multi-homed.</dd>
<dt>Receiver Window (rwnd):</dt>
<dd>An SCTP variable a data sender uses to store the most recently calculated
receiver window of its peer, in number of bytes.
This gives the sender an indication of the space available in the receiver's
inbound buffer.</dd>
<dt>SCTP Association:</dt>
<dd>A protocol relationship between SCTP endpoints, composed of the two SCTP
endpoints and protocol state information, including Verification Tags and the
currently active set of Transmission Sequence Numbers (TSNs), etc.
An association can be uniquely identified by the transport addresses used by the
endpoints in the association.
Two SCTP endpoints <bcp14>MUST NOT</bcp14> have more than one SCTP association between
them at any given time.</dd>
<dt>SCTP Endpoint:</dt>
<dd>The logical sender/receiver of SCTP packets.
On a multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a set of eligible destination transport addresses
to which SCTP packets can be sent and a set of eligible source
transport addresses from which SCTP packets can be received.
All transport addresses used by an SCTP endpoint <bcp14>MUST</bcp14> use the same
port number but can use multiple IP addresses.
A transport address used by an SCTP endpoint <bcp14>MUST NOT</bcp14> be used by another SCTP
endpoint.
In other words, a transport address is unique to an SCTP endpoint.</dd>
<dt>SCTP Packet (or Packet):</dt>
<dd>The unit of data delivery across the interface between SCTP and the
connectionless packet network (e.g., IP).
An SCTP packet includes the common SCTP header, possible SCTP control chunks,
and user data encapsulated within SCTP DATA chunks.</dd>
<dt>SCTP User Application (or SCTP User):</dt>
<dd>The logical higher-layer application entity that uses the services of SCTP,
also called the Upper-Layer Protocol (ULP).</dd>
<dt>Slow-Start Threshold (ssthresh):</dt>
<dd>An SCTP variable.
This is the threshold that the endpoint will use to determine whether to
perform slow-start or congestion avoidance on a particular destination
transport address. Ssthresh is in number of bytes.</dd>
<dt>State Cookie:</dt>
<dd>A container of all information needed to establish an association.</dd>
<dt>Stream:</dt>
<dd>
<t>A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence, except for those submitted to the
unordered delivery service.</t>
<t>Note: The relationship between stream numbers in opposite directions
is strictly a matter of how the applications use them. It is the
responsibility of the SCTP user to create and manage these
correlations if they are so desired.</t>
</dd>
<dt>Stream Sequence Number:</dt>
<dd>A 16-bit sequence number used internally by SCTP to ensure sequenced delivery
of the user messages within a given stream.
One Stream Sequence Number is attached to each ordered user message.</dd>
<dt>Tie-Tags:</dt>
<dd>Two 32-bit random numbers that together make a 64-bit nonce.
These tags are used within a State Cookie and TCB so that a newly restarting
association can be linked to the original association within the endpoint
that did not restart and yet not reveal the true Verification Tags of an
existing association.</dd>
<dt>Transmission Control Block (TCB):</dt>
<dd>An internal data structure created by an SCTP endpoint for each of its
existing SCTP associations to other SCTP endpoints.
TCB contains all the status and operational information for the endpoint
to maintain and manage the corresponding association.</dd>
<dt>Transmission Sequence Number (TSN):</dt>
<dd>A 32-bit sequence number used internally by SCTP.
One TSN is attached to each chunk containing user data to permit the
receiving SCTP endpoint to acknowledge its receipt and detect duplicate
deliveries.</dd>
<dt>Transport Address:</dt>
<dd>A transport address is typically defined by a network-layer address,
a transport-layer protocol, and a transport-layer port number.
In the case of SCTP running over IP, a transport address is defined by
the combination of an IP address and an SCTP port number (where SCTP is the
transport protocol).</dd>
<dt>Unordered Message:</dt>
<dd>Unordered messages are "unordered" with respect to any other message;
this includes both other unordered messages as well as other ordered messages.
An unordered message might be delivered prior to or later than ordered messages
sent on the same stream.</dd>
<dt>User Message:</dt>
<dd>The unit of data delivery across the interface between SCTP and its user.</dd>
<dt>Verification Tag:</dt>
<dd>A 32-bit unsigned integer that is randomly generated.
The Verification Tag provides a key that allows a receiver to verify that the
SCTP packet belongs to the current association and is not an old or stale
packet from a previous association.</dd>
</dl>
</section>
<section>
<name>Abbreviations</name>
<dl newline= "false" spacing='normal' indent="8">
<dt>MAC</dt>
<dd>Message Authentication Code <xref target="RFC2104"/></dd>
<dt>RTO</dt>
<dd>Retransmission Timeout</dd>
<dt>RTT</dt>
<dd>Round-Trip Time</dd>
<dt>RTTVAR</dt>
<dd>Round-Trip Time Variation</dd>
<dt>SCTP</dt>
<dd>Stream Control Transmission Protocol</dd>
<dt>SRTT</dt>
<dd>Smoothed RTT</dd>
<dt>TCB</dt>
<dd>Transmission Control Block</dd>
<dt>TLV</dt>
<dd>Type-Length-Value coding format</dd>
<dt>TSN</dt>
<dd>Transmission Sequence Number</dd>
<dt>ULP</dt>
<dd>Upper-Layer Protocol</dd>
</dl>
</section>
<section>
<name>Functional View of SCTP</name>
<t>The SCTP transport service can be decomposed into a number of functions.
These are depicted in <xref target='fig_functional_view'/> and explained
in the remainder of this section.</t>
<figure anchor='fig_functional_view'
title='Functional View of the SCTP Transport Service'>
<artwork align='center'>
<![CDATA[
SCTP User Application
-----------------------------------------------------
_____________ ____________________
| | | Sequenced Delivery |
| Association | | within Streams |
| | |____________________|
| Startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| Takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
]]>
</artwork>
</figure>
<section>
<name>Association Startup and Takedown</name>
<t>An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in <xref target="sec_api"/>).</t>
<t>A cookie mechanism, similar to one described by Karn and Simpson in
<xref target="RFC2522"/>, is employed during the initialization to provide
protection against synchronization attacks.
The cookie mechanism uses a four-way handshake, the last two legs of which
are allowed to carry user data for fast setup.
The startup sequence is described in <xref target='sec_assoc_initialization'/>
of this document.</t>
<t>SCTP provides for graceful close (i.e., shutdown) of an active
association on request from the SCTP user.
See the description of the SHUTDOWN primitive in <xref target='sec_api'/>.
SCTP also allows ungraceful close (i.e., abort), either on request from the
user (ABORT primitive) or as a result of an error condition detected within
the SCTP layer.
<xref target='sec_assoc_termination'/> describes both the graceful and the
ungraceful close procedures.</t>
<t>SCTP does not support a half-open state (like TCP) wherein one side
continues sending data while the other end is closed.
When either endpoint performs a shutdown, the association on each peer will
stop accepting new data from its user and only deliver data in queue at
the time of the graceful close (see <xref target='sec_assoc_termination'/>).</t>
</section>
<section>
<name>Sequenced Delivery within Streams</name>
<t>The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream.
This is in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document, a byte is assumed to be 8 bits).</t>
<t>At association startup time, the SCTP user can specify the number of
streams to be supported by the association.
This number is negotiated with the remote end
(see <xref target='sec_handle_stream_parameters'/>).
User messages are associated with stream numbers (SEND, RECEIVE primitives;
<xref target='sec_api'/>).
Internally, SCTP assigns a Stream Sequence Number to each message passed to
it by the SCTP user.
On the receiving side, SCTP ensures that messages are delivered to the SCTP
user in sequence within a given stream.
However, while one stream might be blocked waiting for the next in-sequence
user message, delivery from other streams might proceed.</t>
<t>SCTP provides a mechanism for bypassing the sequenced delivery
service.
User messages sent using this mechanism are delivered to the SCTP user as
soon as they are received.</t>
</section>
<section>
<name>User Data Fragmentation</name>
<t>When needed, SCTP fragments user messages to ensure that the size of the SCTP
packet passed to the lower layer does not exceed the PMTU.
Once a user message has been fragmented, this fragmentation cannot be changed
anymore.
On receipt, fragments are reassembled into complete messages before
being passed to the SCTP user.</t>
</section>
<section>
<name>Acknowledgement and Congestion Avoidance</name>
<t>SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message.
The TSN is independent of any Stream Sequence Number assigned at the
stream level.
The receiving end acknowledges all TSNs received, even if there are gaps in the
sequence.
If a user data fragment or unfragmented message needs to be retransmitted,
the TSN assigned to it is used.
In this way, reliable delivery is kept functionally separate from sequenced
stream delivery.</t>
<t>The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received.
Packet retransmission is conditioned by congestion avoidance procedures
similar to those used for TCP. See Sections <xref target='sec_user_data_transfer' format='counter'/> and
<xref target='sec_congestion_control' format='counter'/> for detailed descriptions of the
protocol procedures associated with this function.</t>
</section>
<section>
<name>Chunk Bundling</name>
<t>As described in <xref target='sec_sctp_packet_format'/>, the SCTP packet
as delivered to the lower layer consists of a common header followed by one
or more chunks.
Each chunk contains either user data or SCTP control information.
An SCTP implementation supporting bundling on the sender side might
delay the sending of user messages to allow the corresponding DATA
chunks to be bundled.</t>
<t>The SCTP user has the option to request that an SCTP implementation does not
delay the sending of a user message just for this purpose.
However, even if the SCTP user has chosen this option, the SCTP implementation
might delay the sending due to other reasons (for example, due to congestion
control or flow control) and might also bundle multiple DATA chunks, if
possible.</t>
</section>
<section>
<name>Packet Validation</name>
<t>A mandatory Verification Tag field and a 32-bit checksum field (see
<xref target='sec_crc32c'/> for a description of the 32-bit Cyclic Redundancy Check (CRC32c) 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 CRC32c checksum is 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 CRC32c checksum silently
discards the packet.</t>
</section>
<section>
<name>Path Management</name>
<t>The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP packets through the
primitives described in <xref target='sec_api'/>.
The SCTP path management function monitors reachability through heartbeats
when other packet traffic is inadequate to provide this information and advises
the SCTP user when reachability of any transport address of the peer endpoint
changes.
The path management function chooses the destination transport address
for each outgoing SCTP packet based on the SCTP user's instructions and the
currently perceived reachability status of the eligible destination set.
The path management function is also responsible for reporting the eligible
set of local transport addresses to the peer endpoint during association startup
and for reporting the transport addresses returned from the peer endpoint to the
SCTP user.</t>
<t>At association startup, a primary path is defined for each SCTP
endpoint and is used to send SCTP packets normally.</t>
<t>On the receiving end, the path management is responsible for
verifying the existence of a valid SCTP association to which the
inbound SCTP packet belongs before passing it for further processing.</t>
<t>Note: Path Management and Packet Validation are done at the same
time; although described separately above, in reality, they cannot
be performed as separate items.</t>
</section>
</section>
<section>
<name>Serial Number Arithmetic</name>
<t>It is essential to remember that the actual Transmission Sequence
Number space is finite, though very large.
This space ranges from 0 to 2<sup>32</sup> - 1.
Since the space is finite, all arithmetic dealing with Transmission Sequence
Numbers <bcp14>MUST</bcp14> be performed modulo 2<sup>32</sup>.
This unsigned arithmetic preserves the relationship of sequence numbers as
they cycle from 2<sup>32</sup> - 1 to 0 again.
There are some subtleties to computer modulo arithmetic, so great care has to
be taken in programming the comparison of such values.
When referring to TSNs, the symbol "<=" means
"less than or equal" (modulo 2<sup>32</sup>).</t>
<t>Comparisons and arithmetic on TSNs in this document <bcp14>SHOULD</bcp14> use Serial
Number Arithmetic, as defined in <xref target="RFC1982"/>,
where SERIAL_BITS = 32.</t>
<t>An endpoint <bcp14>SHOULD NOT</bcp14> transmit a DATA chunk with a TSN that is more
than 2<sup>31</sup> - 1 above the beginning TSN of its current send window.
Doing so will cause problems in comparing TSNs.</t>
<t>Transmission Sequence Numbers wrap around when they reach 2<sup>32</sup> - 1.
That is, the next TSN a DATA chunk <bcp14>MUST</bcp14> use after transmitting TSN =
2<sup>32</sup> - 1 is TSN = 0.</t>
<t>Any arithmetic done on Stream Sequence Numbers <bcp14>SHOULD</bcp14> use Serial
Number Arithmetic, as defined in <xref target="RFC1982"/>, where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document use normal
arithmetic.</t>
</section>
<section>
<name>Changes from RFC 4960</name>
<t>SCTP was originally defined in <xref target="RFC4960"/>, which this document
obsoletes.
Readers interested in the details of the various changes that this document
incorporates are asked to consult <xref target="RFC8540"/>.</t>
<t>In addition to these and further editorial changes, the following changes
have been incorporated in this document:</t>
<ul>
<li><t>Update references.</t></li>
<li><t>Improve the language related to requirements levels.</t></li>
<li><t>Allow the ASSOCIATE primitive to take multiple remote addresses;
also refer to the socket API specification.</t></li>
<li><t>Refer to the Packetization Layer Path MTU Discovery (PLPMTUD) specification for path MTU discovery.</t></li>
<li><t>Move the description of ICMP handling from the Appendix to the main
text.</t></li>
<li><t>Remove the Appendix describing Explicit Congestion Notification (ECN) handling from the document.</t></li>
<li><t>Describe the packet size handling more precisely by introducing PMTU,
PMDCS, and AMDCS.</t></li>
<li><t>Add the definition of control chunk.</t></li>
<li><t>Improve the description of the handling of INIT and INIT ACK chunks with
invalid mandatory parameters.</t></li>
<li><t>Allow using L > 1 for Appropriate Byte Counting (ABC) during
slow start.</t></li>
<li><t>Explicitly describe the reinitialization of the congestion controller on
route changes.</t></li>
<li><t>Improve the terminology to make it clear that this specification does not
describe a full mesh architecture.</t></li>
<li><t>Improve the description of sequence number generation
(Transmission Sequence Number and Stream Sequence Number).</t></li>
<li><t>Improve the description of reneging.</t></li>
<li><t>Don't require the change of the Cumulative TSN Ack anymore for increasing
the congestion window.
This improves the consistency with the handling in congestion
avoidance.</t></li>
<li><t>Improve the description of the State Cookie.</t></li>
<li><t>Fix the API for retrieving messages in case of association failures.</t></li>
</ul>
</section>
</section>
<section>
<name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor='sec_sctp_packet_format'>
<name>SCTP Packet Format</name>
<t>An SCTP packet is composed of a common header and chunks.
A chunk contains either control information or user data.</t>
<t>The SCTP packet format is shown below:</t>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<t>INIT, INIT ACK, and SHUTDOWN COMPLETE chunks <bcp14>MUST NOT</bcp14> be bundled
with any other chunk into an SCTP packet.
All other chunks <bcp14>MAY</bcp14> be bundled to form an SCTP packet that does not exceed
the PMTU.
See <xref target='sec_bundling'/> for more details on chunk bundling.</t>
<t>If a user data message does not fit into one SCTP packet, it can be
fragmented into multiple chunks using the procedure defined in
<xref target='sec_frag_reass'/>.</t>
<t>All integer fields in an SCTP packet <bcp14>MUST</bcp14> be transmitted in network
byte order, unless otherwise stated.</t>
<section anchor='sec_sctp_common_header_field_desriptions'>
<name>SCTP Common Header Field Descriptions</name>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Source Port Number: 16 bits (unsigned integer)</dt>
<dd>This is the SCTP sender's port number.
It can be used by the receiver in combination with the source IP address,
the SCTP Destination Port Number, and possibly the destination IP address to
identify the association to which this packet belongs.
The Source Port Number 0 <bcp14>MUST NOT</bcp14> be used.</dd>
<dt>Destination Port Number: 16 bits (unsigned integer)</dt>
<dd>This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application.
The Destination Port Number 0 <bcp14>MUST NOT</bcp14> be used.</dd>
<dt>Verification Tag: 32 bits (unsigned integer)</dt>
<dd>
<t>The receiver of an SCTP packet uses the Verification Tag to validate
the sender of this packet.
On transmit, the value of the Verification Tag <bcp14>MUST</bcp14> be set to the value of
the Initiate Tag received from the peer endpoint during the association
initialization, with the following exceptions:</t>
<ul>
<li>A packet containing an INIT chunk <bcp14>MUST</bcp14> have a zero Verification Tag.</li>
<li>A packet containing a SHUTDOWN COMPLETE chunk with the T bit set <bcp14>MUST</bcp14> have
the Verification Tag copied from the packet with the SHUTDOWN ACK chunk.</li>
<li>A packet containing an ABORT chunk <bcp14>MAY</bcp14> have the Verification Tag copied
from the packet that caused the ABORT chunk to be sent.
For details, see Sections <xref target='sec_handle_out_of_the_blue_packets' format='counter'/> and
<xref target='sec_verification_tag' format='counter'/>.</li>
</ul>
</dd>
<dt>Checksum: 32 bits (unsigned integer)</dt>
<dd>This field contains the checksum of the SCTP packet.
Its calculation is discussed in
<xref target='sec_crc32c_checksum_calculation'/>.
SCTP uses the CRC32c algorithm as described in <xref target='sec_crc32c'/> for
calculating the checksum.</dd>
</dl>
</section>
<section anchor='sec_chunk_field_descriptions'>
<name>Chunk Field Descriptions</name>
<t>The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet.
Each chunk is formatted with a Chunk Type field, a Chunk Flags field,
a Chunk Length field, and a Chunk Value field.</t>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Chunk Type: 8 bits (unsigned integer)</dt>
<dd>
<t>This field identifies the type of information contained in the Chunk Value
field. It takes a value from 0 to 254.
The value of 255 is reserved for future use as an extension field.</t>
<t>The values of Chunk Types defined in this document are as follows:</t>
<table>
<name>Chunk Types</name>
<thead>
<tr><th>ID Value</th> <th>Chunk Type</th></tr>
</thead>
<tbody>
<tr><td>0 </td> <td>Payload Data (DATA) </td></tr>
<tr><td>1 </td> <td>Initiation (INIT) </td></tr>
<tr><td>2 </td> <td>Initiation Acknowledgement (INIT ACK) </td></tr>
<tr><td>3 </td> <td>Selective Acknowledgement (SACK) </td></tr>
<tr><td>4 </td> <td>Heartbeat Request (HEARTBEAT) </td></tr>
<tr><td>5 </td> <td>Heartbeat Acknowledgement (HEARTBEAT ACK) </td></tr>
<tr><td>6 </td> <td>Abort (ABORT) </td></tr>
<tr><td>7 </td> <td>Shutdown (SHUTDOWN) </td></tr>
<tr><td>8 </td> <td>Shutdown Acknowledgement (SHUTDOWN ACK) </td></tr>
<tr><td>9 </td> <td>Operation Error (ERROR) </td></tr>
<tr><td>10 </td> <td>State Cookie (COOKIE ECHO) </td></tr>
<tr><td>11 </td> <td>Cookie Acknowledgement (COOKIE ACK) </td></tr>
<tr><td>12 </td> <td>Reserved for Explicit Congestion Notification Echo (ECNE)</td></tr>
<tr><td>13 </td> <td>Reserved for Congestion Window Reduced (CWR) </td></tr>
<tr><td>14 </td> <td>Shutdown Complete (SHUTDOWN COMPLETE) </td></tr>
<tr><td>15 to 62 </td> <td>Unassigned </td></tr>
<tr><td>63 </td> <td>Reserved for IETF-defined Chunk Extensions </td></tr>
<tr><td>64 to 126 </td> <td>Unassigned </td></tr>
<tr><td>127 </td> <td>Reserved for IETF-defined Chunk Extensions </td></tr>
<tr><td>128 to 190</td> <td>Unassigned </td></tr>
<tr><td>191 </td> <td>Reserved for IETF-defined Chunk Extensions </td></tr>
<tr><td>192 to 254</td> <td>Unassigned </td></tr>
<tr><td>255 </td> <td>Reserved for IETF-defined Chunk Extensions </td></tr>
</tbody>
</table>
<t>Note: The ECNE and CWR chunk types are reserved for future use of Explicit
Congestion Notification (ECN).</t>
<t>Chunk Types are encoded such that the highest-order 2 bits specify the action
that is taken if the processing endpoint does not recognize the Chunk Type.</t>
<table>
<name>Processing of Unknown Chunks</name>
<tbody>
<tr><td>00</td><td><t>Stop processing this SCTP packet and
discard the unrecognized chunk and all further chunks.</t></td></tr>
<tr><td>01</td><td><t>Stop processing this SCTP packet, discard the unrecognized
chunk and all further chunks, and report the unrecognized
chunk in an ERROR chunk using the 'Unrecognized Chunk Type'
error cause.</t></td></tr>
<tr><td>10</td><td><t>Skip this chunk and continue processing.</t></td></tr>
<tr><td>11</td><td><t>Skip this chunk and continue processing, but report it in
an ERROR chunk using the 'Unrecognized Chunk Type' error
cause.</t></td></tr>
</tbody>
</table>
</dd>
<dt>Chunk Flags: 8 bits</dt>
<dd>
<t>The usage of these bits depends on the Chunk Type, as given by the Chunk Type
field.
Unless otherwise specified, they are set to 0 on transmit and are ignored
on receipt.</t>
</dd>
<dt>Chunk Length: 16 bits (unsigned integer)</dt>
<dd>
<t>This value represents the size of the chunk in bytes, including the Chunk Type,
Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length field will be
set to 4.
The Chunk Length field does not count any chunk padding.
However, it does include any padding of variable-length parameters other than
the last parameter in the chunk.</t>
<t>Note: A robust implementation is expected to accept the chunk whether or not
the final padding has been included in the Chunk Length.</t>
</dd>
<dt>Chunk Value: variable length</dt>
<dd>
<t>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.</t>
</dd>
</dl>
<t>The total length of a chunk (including Type, Length, and Value fields) <bcp14>MUST</bcp14>
be a multiple of 4 bytes.
If the length of the chunk is not a multiple of 4 bytes, the sender <bcp14>MUST</bcp14> pad
the chunk with all zero bytes, and this padding is not included in the
Chunk Length field.
The sender <bcp14>MUST NOT</bcp14> pad with more than 3 bytes.
The receiver <bcp14>MUST</bcp14> ignore the padding bytes.</t>
<t>SCTP-defined chunks are described in detail in
<xref target='sec_sctp_chunk_definitions'/>.
The guidelines for IETF-defined chunk extensions can be found in
<xref target='sec_ietf_defined_chunks_extension'/> of this document.</t>
<section anchor='sec_parameter_format'>
<name>Optional/Variable-Length Parameter Format</name>
<t>Chunk values of SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters.
The optional and variable-length parameters contained in a chunk are
defined in a Type-Length-Value format, as shown below.</t>
<artwork align='center'>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Parameter Type: 16 bits (unsigned integer)</dt>
<dd>
<t>The Type field is a 16-bit identifier of the type of parameter.
It takes a value of 0 to 65534.</t>
<t>The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific SCTP chunk descriptions are
reserved for use by IETF.</t>
</dd>
<dt>Parameter Length: 16 bits (unsigned integer)</dt>
<dd>The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and Parameter Value
fields. Thus, a parameter with a zero-length Parameter Value field would have a
Parameter Length field of 4.
The Parameter Length does not include any padding bytes.</dd>
<dt>Parameter Value: variable length</dt>
<dd>
<t>The Parameter Value field contains the actual information to be transferred in
the parameter.</t>
</dd>
</dl>
<t>The total length of a parameter (including Parameter Type, Parameter Length,
and Parameter Value fields) <bcp14>MUST</bcp14> be a multiple of 4 bytes.
If the length of the parameter is not a multiple of 4 bytes, the sender pads the
parameter at the end (i.e., after the Parameter Value field) with all zero
bytes.
The length of the padding is not included in the Parameter Length field.
A sender <bcp14>MUST NOT</bcp14> pad with more than 3 bytes.
The receiver <bcp14>MUST</bcp14> ignore the padding bytes.</t>
<t>The Parameter Types are encoded such that the highest-order 2 bits specify the
action that is taken if the processing endpoint does not recognize the
Parameter Type.</t>
<table>
<name>Processing of Unknown Parameters</name>
<tbody>
<tr><td>00</td><td><t>Stop processing this parameter and do not process any
further parameters within this chunk.</t></td></tr>
<tr><td>01</td><td><t>Stop processing this parameter, do not process any
further parameters within this chunk, and report the
unrecognized parameter, as described in
<xref target='sec_reporting_of_unrecognized_parameters'/>.</t></td></tr>
<tr><td>10</td><td><t>Skip this parameter and continue processing.</t></td></tr>
<tr><td>11</td><td><t>Skip this parameter and continue processing, but report
the unrecognized parameter, as described in
<xref target='sec_reporting_of_unrecognized_parameters'/>.</t></td></tr>
</tbody>
</table>
<t>Please note that, when an INIT or INIT ACK chunk is received, in all
four cases, an INIT ACK or COOKIE ECHO chunk is sent in response, respectively.
In the 00 or 01 case, the processing of the parameters after the unknown
parameter is canceled, but no processing already done is rolled back.</t>
<t>The actual SCTP parameters are defined in the specific SCTP chunk sections.
The rules for IETF-defined parameter extensions are defined in
<xref target='sec_ietf_defined_chunk_parameter_extension'/>.
Parameter types <bcp14>MUST</bcp14> be unique across all chunks.
For example, the parameter type '5' is used to represent an IPv4 address
(see <xref target='sec_ipv4_address_parameter'/>).
The value '5' then is reserved across all chunks to represent an IPv4 address
and <bcp14>MUST NOT</bcp14> be reused with a different meaning in any other chunk.</t>
</section>
<section anchor='sec_reporting_of_unrecognized_parameters'>
<name>Reporting of Unrecognized Parameters</name>
<t>If the receiver of an INIT chunk detects unrecognized parameters and
has to report them according to <xref target='sec_parameter_format'/>,
it <bcp14>MUST</bcp14> put the "Unrecognized Parameter" parameter(s) in the INIT ACK chunk
sent in response to the INIT chunk.
Note that, if the receiver of the INIT chunk is not going to establish an
association (e.g., due to lack of resources), an "Unrecognized Parameters"
error cause would not be included with any ABORT chunk being sent to the sender
of the INIT chunk.</t>
<t>If the receiver of any other chunk (e.g., INIT ACK) detects unrecognized
parameters and has to report them according to
<xref target='sec_parameter_format'/>, it <bcp14>SHOULD</bcp14> bundle the ERROR chunk
containing the "Unrecognized Parameters" error cause with the chunk sent
in response (e.g., COOKIE ECHO).
If the receiver of an INIT ACK chunk cannot bundle the COOKIE ECHO chunk with
the ERROR chunk, the ERROR chunk <bcp14>MAY</bcp14> be sent separately but not before the
COOKIE ACK chunk has been received.</t>
<t>Any time a COOKIE ECHO chunk is sent in a packet, it <bcp14>MUST</bcp14> be the first
chunk.</t>
</section>
</section>
<section anchor='sec_sctp_chunk_definitions'>
<name>SCTP Chunk Definitions</name>
<t>This section defines the format of the different SCTP chunk types.</t>
<section anchor='sec_data_chunk'>
<name>Payload Data (DATA) (0)</name>
<t>The following format <bcp14>MUST</bcp14> be used for the DATA chunk:</t>
<artwork align='center'>
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) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Res: 4 bits</dt>
<dd>All set to 0 on transmit and ignored on receipt.</dd>
<dt>I bit: 1 bit</dt>
<dd>The (I)mmediate bit <bcp14>MAY</bcp14> be set by the sender whenever the sender of a DATA
chunk can benefit from the corresponding SACK chunk being sent back without delay.