RFC2960 - Stream Control Transmission Protocol(2)

时间:2005-02-17 来源: 作者: 点击:
Congestion Notification. Note 3: An INIT chunk MUST NOT contain more than one Host Name address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name
  
Congestion Notification.

Note 3: An INIT chunk MUST NOT contain more than one Host Name
address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name address in the INIT. The
receiver of INIT MUST ignore any other address types if the Host Name
address parameter is present in the received INIT chunk.

Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address type.

The Chunk Flags field in INIT is reserved and all bits in it should
be set to 0 by the sender and ignored by the receiver. The sequence
of parameters within an INIT can be processed in any order.

Initiate Tag: 32 bits (unsigned integer)

The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP packet that the receiver of
the INIT transmits within this association.

The Initiate Tag is allowed to have any value except 0. See
Section 5.3.1 for more on the selection of the tag value.

If the value of the Initiate Tag in a received INIT chunk is found
to be 0, the receiver MUST treat it as an error and close the
association by transmitting an ABORT.

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

This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT has reserved in association with
this window. During the life of the association this buffer space
SHOULD not be lessened (i.e. dedicated buffers taken away from
this association); however, an endpoint MAY change the value of
a_rwnd it sends in SACK chunks.

Number of Outbound Streams (OS): 16 bits (unsigned integer)

Defines the number of outbound streams the sender of this INIT
chunk wishes to create in this association. The value of 0 MUST
NOT be used.

Note: A receiver of an INIT with the OS value set to 0 SHOULD
abort the association.

Number of Inbound Streams (MIS) : 16 bits (unsigned integer)

Defines the maximum number of streams the sender of this INIT
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.

Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details.

Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
the association.

Initial TSN (I-TSN) : 32 bits (unsigned integer)

Defines the initial TSN that the sender will use. The valid range
is from 0 to 4294967295. This field MAY be set to the value of
the Initiate Tag field.

3.3.2.1 Optional/Variable Length Parameters in INIT

The following parameters follow the Type-Length-Value format as
defined in Section 3.2.1. Any Type-Length-Value fields MUST come
after the fixed-length fields defined in the previous section.

IPv4 Address Parameter (5)

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 = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Address: 32 bits (unsigned integer)

Contains an IPv4 address of the sending endpoint. It is binary
encoded.

IPv6 Address Parameter (6)

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 = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Address: 128 bit (unsigned integer)

Contains an IPv6 address of the sending endpoint. It is binary
encoded.

Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
but should instead use an IPv4 Address Parameter for an IPv4
address.

Combined with the Source Port Number in the SCTP common header,
the value passed in an IPv4 or IPv6 Address parameter indicates a
transport address the sender of the INIT will support for the
association being initiated. That is, during the lifetime of this
association, this IP address can appear in the source address
field of an IP datagram sent from the sender of the INIT, and can
be used as a destination address of an IP datagram sent from the
receiver of the INIT.

More than one IP Address parameter can be included in an INIT
chunk when the INIT sender is multi-homed. Moreover, a multi-
homed endpoint may have access to different types of network, thus
more than one address type can be present in one INIT chunk, i.e.,
IPv4 and IPv6 addresses are allowed in the same INIT chunk.

If the INIT contains at least one IP Address parameter, then the
source address of the IP datagram containing the INIT chunk and
any additional address(es) provided within the INIT can be used as
destinations by the endpoint receiving the INIT. If the INIT does
not contain any IP Address parameters, the endpoint receiving the
INIT MUST use the source address associated with the received IP
datagram as its sole destination address for the association.

Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely to
work across a NAT box.

Cookie Preservative (9)

The sender of the INIT shall use this parameter to suggest to the
receiver of the INIT for a longer life-span of the State Cookie.

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 = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Suggested Cookie Life-span Increment: 32 bits (unsigned integer)

This parameter indicates to the receiver how much increment in
milliseconds the sender wishes the receiver to add to its default
cookie life-span.

This optional parameter should be added to the INIT chunk by the
sender when it re-attempts establishing an association with a peer
to which its previous attempt of establishing the association failed
due to a stale cookie operation error. The receiver MAY choose to
ignore the suggested cookie life-span increase for its own security
reasons.

Host Name Address (11)

The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer. The peer is responsible
for resolving the name. Using this parameter might make it more
likely for the association to work across a NAT box.

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 = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Host Name: variable length

This field contains a host name in "host name syntax" per RFC1123
Section 2.1 [RFC1123]. The method for resolving the host name is
out of scope of SCTP.

Note: At least one null terminator is included in the Host Name
string and must be included in the length.

Supported Address Types (12)

The sender of INIT uses this parameter to list all the address
types it can support.

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 = 12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Type: 16 bits (unsigned integer)

This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Hostname = 11).

3.3.3 Initiation Acknowledgement (INIT ACK) (2):

The INIT ACK chunk is used to acknowledge the initiation of an SCTP
association.

The parameter part of INIT ACK is formatted similarly to the INIT
chunk. It uses two extra variable parameters: The State Cookie and
the Unrecognized Parameter:

The format of the INIT ACK chunk is shown below:

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 = 2 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Initiate Tag: 32 bits (unsigned integer)

The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits
within this association.

The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value.

If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST treat it as an error and close
the association by transmitting an ABORT.

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

This value represents the dedicated buffer space, in number of
bytes, the sender of the INIT ACK has reserved in association with
this window. During the life of the association this buffer space
SHOULD not be lessened (i.e. dedicated buffers taken away from
this association).

Number of Outbound Streams (OS): 16 bits (unsigned integer)

Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used.

Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.

Number of Inbound Streams (MIS) : 16 bits (unsigned integer)

Defines the maximum number of streams the sender of this INIT ACK
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.

Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details.

Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB.

Initial TSN (I-TSN) : 32 bits (unsigned integer)

Defines the initial TSN that the INIT-ACK sender will use. The
valid range is from 0 to 4294967295. This field MAY be set to the
value of the Initiate Tag field.

Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory

Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11

Note 1: The INIT ACK chunks can contain any number of IP address
parameters that can be IPv4 and/or IPv6 in any combination.

Note 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.

Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
address parameter. Moreover, the sender of the INIT ACK MUST NOT
combine any other address types with the Host Name address in the
INIT ACK. The receiver of the INIT ACK MUST ignore any other address
types if the Host Name address parameter is present.

IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a
INIT ACK that is quite large (more than 1500 bytes) due to the
variable size of the state cookie AND the variable address list. For
example if a responder to the INIT has 1000 IPv4 addresses it wishes
to send, it would need at least 8,000 bytes to encode this in the
INIT ACK.

In combination with the Source Port carried in the SCTP common
header, each IP Address parameter in the INIT ACK indicates to the
receiver of the INIT ACK a valid transport address supported by the
sender of the INIT ACK for the lifetime of the association being
initiated.

If the INIT ACK contains at least one IP Address parameter, then the
source address of the IP datagram containing the INIT ACK and any
additional address(es) provided within the INIT ACK may be used as
destinations by the receiver of the INIT-ACK. If the INIT ACK does
not contain any IP Address parameters, the receiver of the INIT-ACK
MUST use the source address associated with the received IP datagram
as its sole destination address for the association.

The State Cookie and Unrecognized Parameters use the Type-Length-
Value format as defined in Section 3.2.1 and are described below.
The other fields are defined the same as their counterparts in the
INIT chunk.

3.3.3.1 Optional or Variable Length Parameters

State Cookie

Parameter Type Value: 7

Parameter Length: variable size, depending on Size of Cookie

Parameter Value:

This parameter value MUST contain all the necessary state and
parameter information required for the sender of this INIT ACK
to create the association, along with a Message Authentication
Code (MAC). See Section 5.1.3 for details on State Cookie
definition.

Unrecognized Parameters:

Parameter Type Value: 8

Parameter Length: Variable Size.

Parameter Value:

This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter which has a
value that indicates that it should be reported to the sender.
This parameter value field will contain unrecognized parameters
copied from the INIT chunk complete with Parameter Type, Length
and Value fields.

3.3.4 Selective Acknowledgement (SACK) (3):

This chunk is sent to the peer endpoint to acknowledge received DATA
chunks and to inform the peer endpoint of gaps in the received
subsequences of DATA chunks as represented by their TSNs.

The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver
Window Credit (a_rwnd) parameters.

By definition, the value of the Cumulative TSN Ack parameter is the
last TSN received before a break in the sequence of received TSNs
occurs; the next TSN value following this one has not yet been
received at the endpoint sending the SACK. This parameter therefore
acknowledges receipt of all TSNs less than or equal to its value.

The handling of a_rwnd by the receiver of the SACK is discussed in
detail in Section 6.2.1.

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.

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 = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to all zeros on transmit and ignored on receipt.

Cumulative TSN Ack: 32 bits (unsigned integer)

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

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

This field indicates the updated receive buffer space in bytes of
the sender of this SACK, see Section 6.2.1 for details.

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

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

Number of Duplicate TSNs: 16 bit

This field contains the number of duplicate TSNs the endpoint has
received. Each duplicate TSN is listed following the Gap Ack
Block list.

Gap Ack Blocks:

These fields contain the Gap Ack Blocks. They are repeated for
each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with 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 Block Start: 16 bits (unsigned integer)

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

Gap Ack Block End: 16 bits (unsigned integer)

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

For example, assume the receiver has the following DATA chunks newly
arrived at the time when it decides to send a Selective ACK,

----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------

then, the parameter part of the SACK MUST be constructed as follows
(assuming the new a_rwnd is set to 4660 by the sender):

+--------------------------------+
| Cumulative TSN Ack = 12 |
+--------------------------------+
| a_rwnd = 4660 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+

Duplicate TSN: 32 bits (unsigned integer)

Indicates the number of times a TSN was received in duplicate
since the last SACK was sent. Every time a receiver gets a
duplicate TSN (before sending the SACK) it adds it to the list of
duplicates. The duplicate count is re-initialized to zero after
sending each SACK.

For example, if a receiver were to get the TSN 19 three times it
would list 19 twice in the outbound SACK. After sending the SACK
if it received yet one more TSN 19 it would list 19 as a duplicate
once in the next outgoing SACK.

3.3.5 Heartbeat Request (HEARTBEAT) (4):

An endpoint should send this chunk to its peer endpoint to probe the
reachability of a particular destination transport address defined in
the present association.

The parameter field contains the Heartbeat Information which is a
variable length opaque data structure understood only by the sender.

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 = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

Heartbeat Length: 16 bits (unsigned integer)

Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field.

Heartbeat Information: variable length

Defined as a variable-length parameter using the format described
in Section 3.2.1, i.e.:

Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Sender-specific Heartbeat Info field should normally include
information about the sender's current time when this HEARTBEAT
chunk is sent and the destination transport address to which this
HEARTBEAT is sent (see Section 8.3).

3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):

An endpoint should send this chunk to its peer endpoint as a response
to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always
sent to the source IP address of the IP datagram containing the
HEARTBEAT chunk to which this ack is responding.

The parameter field contains a variable length opaque data structure.

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 = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

Heartbeat Ack Length: 16 bits (unsigned integer)

Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field.

Heartbeat Information: variable length

This field MUST contain the Heartbeat Information parameter of
the Heartbeat Request to which this Heartbeat Acknowledgement is
responding.

Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1

3.3.7 Abort Association (ABORT) (6):

The ABORT chunk is sent to the peer of an association to close the
association. The ABORT chunk may contain Cause Parameters to inform
the receiver the reason of the abort. DATA chunks MUST NOT be
bundled with ABORT. Control chunks (except for INIT, INIT ACK and
SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be
placed before the ABORT in the SCTP packet, or they will be ignored
by the receiver.

If an endpoint receives an ABORT with a format error or for an
association that doesn't exist, it MUST silently discard it.
Moreover, under any circumstances, an endpoint that receives an ABORT
MUST NOT respond to that ABORT by sending an ABORT of its own.

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 = 6 |Reserved |T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Reserved: 7 bits

Set to 0 on transmit and ignored on receipt.

T bit: 1 bit

The T bit is set to 0 if the sender had a TCB that it destroyed.
If the sender did not have a TCB it should set this bit to 1.

Note: Special rules apply to this chunk for verification, please see
Section 8.5.1 for details.

Length: 16 bits (unsigned integer)

Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present.

See Section 3.3.10 for Error Cause definitions.

3.3.8 Shutdown Association (SHUTDOWN) (7):

An endpoint in an association MUST use this chunk to initiate a
graceful close of the association with its peer. This chunk has the
following format.

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 = 7 | Chunk Flags | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

Length: 16 bits (unsigned integer)

Indicates the length of the parameter. Set to 8.

Cumulative TSN Ack: 32 bits (unsigned integer)

This parameter contains the TSN of the last chunk received in
sequence before any gaps.

Note: Since the SHUTDOWN message does not contain Gap Ack Blocks,
it cannot be used to acknowledge TSNs received out of order. In a
SACK, lack of Gap Ack Blocks that were previously included
indicates that the data receiver reneged on the associated DATA
chunks. Since SHUTDOWN does not contain Gap Ack Blocks, the
receiver of the SHUTDOWN shouldn't interpret the lack of a Gap Ack
Block as a renege. (see Section 6.2 for information on reneging)

3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (8):

This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
chunk at the completion of the shutdown process, see Section 9.2 for
details.

The SHUTDOWN ACK chunk has no parameters.

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 = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

3.3.10 Operation Error (ERROR) (9):

An endpoint sends this chunk to its peer endpoint to notify it of
certain error conditions. It contains one or more error causes. An
Operation Error is not considered fatal in and of itself, but may be
used with an ABORT chunk to report a fatal condition. It has the
following parameters:

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 = 9 | Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ one or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

Length: 16 bits (unsigned integer)

Set to the size of the chunk in bytes, including the chunk header
and all the Error Cause fields present.

Error causes are defined as variable-length parameters using the
format described in 3.2.1, i.e.:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cause Code: 16 bits (unsigned integer)

Defines the type of error conditions being reported.

Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down

Cause Length: 16 bits (unsigned integer)

Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields

Cause-specific Information: variable length

This field carries the details of the error condition.

Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.

3.3.10.1 Invalid Stream Identifier (1)

Cause of error
---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk
sent to a nonexistent stream.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stream Identifier: 16 bits (unsigned integer)

Contains the Stream Identifier of the DATA chunk received in
error.

Reserved: 16 bits

This field is reserved. It is set to all 0's on transmit and
Ignored on receipt.

3.3.10.2 Missing Mandatory Parameter (2)

Cause of error
---------------
Missing Mandatory Parameter: Indicates that one or more mandatory
TLV parameters are missing in a received INIT or INIT ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Number of Missing params: 32 bits (unsigned integer)

This field contains the number of parameters contained in the
Cause-specific Information field.

Missing Param Type: 16 bits (unsigned integer)

Each field will contain the missing mandatory parameter number.

3.3.10.3 Stale Cookie Error (3)

Cause of error
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Measure of Staleness: 32 bits (unsigned integer)

This field contains the difference, in microseconds, between the
current time and the time the State Cookie expired.

The sender of this error cause MAY choose to report how long past
expiration the State Cookie is by including a non-zero value in
the Measure of Staleness field. If the sender does not wish to
provide this information it should set the Measure of Staleness
field to the value of zero.

3.3.10.4 Out of Resource (4)

Cause of error
---------------
Out of Resource: Indicates that the sender is out of resource. This
is usually sent in combination with or within an ABORT.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.5 Unresolvable Address (5)

Cause of error
---------------
Unresolvable Address: Indicates that the sender is not able to
resolve the specified address parameter (e.g., type of address is not
supported by the sender). This is usually sent in combination with
or within an ABORT.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unresolvable Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unresolvable Address: variable length

The unresolvable address field contains the complete Type, Length
and Value of the address parameter (or Host Name parameter) that
contains the unresolvable address or host name.

3.3.10.6 Unrecognized Chunk Type (6)

Cause of error
---------------
Unrecognized Chunk Type: This error cause is returned to the
originator of the chunk if the receiver does not understand the chunk
and the upper bits of the 'Chunk Type' are set to 01 or 11.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Chunk: variable length

The Unrecognized Chunk field contains the unrecognized Chunk from
the SCTP packet complete with Chunk Type, Chunk Flags and Chunk
Length.

3.3.10.7 Invalid Mandatory Parameter (7)

Cause of error
---------------
Invalid Mandatory Parameter: This error cause is returned to the
originator of an INIT or INIT ACK chunk when one of the mandatory
parameters is set to a invalid value.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.8 Unrecognized Parameters (8)

Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the
originator of the INIT ACK chunk if the receiver does not recognize
one or more Optional TLV parameters in the INIT ACK chunk.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Parameters: variable length

The Unrecognized Parameters field contains the unrecognized
parameters copied from the INIT ACK chunk complete with TLV. This
error cause is normally contained in an ERROR chunk bundled with
the COOKIE ECHO chunk when responding to the INIT ACK, when the
sender of the COOKIE ECHO chunk wishes to report unrecognized
parameters.

3.3.10.9 No User Data (9)

Cause of error
---------------
No User Data: This error cause is returned to the originator of a
DATA chunk if a received DATA chunk has no user data.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN value: 32 bits (+unsigned integer)

The TSN value field contains the TSN of the DATA chunk received
with no user data field.

This cause code is normally returned in an ABORT chunk (see
Section 6.2)

3.3.10.10 Cookie Received While Shutting Down (10)

Cause of error
---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received
While the endpoint was in SHUTDOWN-ACK-SENT state. This error is
usually returned in an ERROR chunk bundled with the retransmitted
SHUTDOWN ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.11 Cookie Echo (COOKIE ECHO) (10):

This chunk is used only during the initialization of an association.
It is sent by the initiator of an association to its peer to complete
the initialization process. This chunk MUST precede any DATA chunk
sent within the association, but MAY be bundled with one or more DATA
chunks in the same packet.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cookie /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bit

Set to zero on transmit and ignored on receipt.

Length: 16 bits (unsigned integer)

Set to the size of the chunk in bytes, including the 4 bytes of
the chunk header and the size of the Cookie.

Cookie: variable size

This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.

An implementation SHOULD make the cookie as small as possible to
insure interoperability.

3.3.12 Cookie Acknowledgement (COOKIE ACK) (11):

This chunk is used only during the initialization of an association.
It is used to acknowledge the receipt of a COOKIE ECHO chunk. This
chunk MUST precede any DATA or SACK chunk sent within the
association, but MAY be bundled with one or more DATA chunks or SACK
chunk in the same SCTP packet.

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 = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Set to zero on transmit and ignored on receipt.

3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (14):

This chunk MUST be used to acknowledge the receipt of the SHUTDOWN
ACK chunk at the completion of the shutdown process, see Section 9.2
for details.

The SHUTDOWN COMPLETE chunk has no parameters.

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 = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: 8 bits

Reserved: 7 bits

Set to 0 on transmit and ignored on receipt.

T bit: 1 bit

The T bit is set to 0 if the sender had a TCB that it destroyed.
If the sender did not have a TCB it should set this bit to 1.

Note: Special rules apply to this chunk for verification, please see
Section 8.5.1 for details.

4. SCTP Association State Diagram

During the lifetime of an SCTP association, the SCTP endpoint's
association progress from one state to another in response to various
events. The events that may potentially advance an association's
state include:

o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],

o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control
chunks, or

o Some timeout events.

The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that
some of the error conditions are not shown in the state diagram.
Full description of all special cases should be found in the text.

Note: Chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE ECHO chunk type
vs. State Cookie parameter. If more than one event/message can occur
which causes a state transition it is labeled (A), (B) etc.

----- -------- (frm any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+

(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN/check
|PENDING | | outstanding DATA
+---------+ | chunks
| |------------------
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |

| | (D)rcv SHUTDOWN ACK
| |--------------
| | stop shutdown timer
| | send SHUTDOWN COMPLETE
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+

Figure 3: State Transition Diagram of SCTP

Notes:

1) If the State Cookie in the received COOKIE ECHO is invalid (i.e.,
failed to pass the integrity check), the receiver MUST silently
discard the packet. Or, if the received State Cookie is expired
(see Section 5.1.5), the receiver MUST send back an ERROR chunk.
In either case, the receiver stays in the CLOSED state.

2) If the T1-init timer expires, the endpoint MUST retransmit INIT
and re-start the T1-init timer without changing state. This MUST
be repeated up to 'Max.Init.Retransmits' times. After that, the
endpoint MUST abort the initialization process and report the
error to SCTP user.

3) If the T1-cookie timer expires, the endpoint MUST retransmit
COOKIE ECHO and re-start the T1-cookie timer without changing
state. This MUST be repeated up to 'Max.Init.Retransmits' times.
After that, the endpoint MUST abort the initialization process and
report the error to SCTP user.

4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received
DATA chunks without delay.

5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new
send request from its SCTP user.

6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or
retransmit data and leave this state when all data in queue is
transmitted.

7) In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new
send request from its SCTP user.

The CLOSED state is used to indicate that an association is not
created (i.e., doesn't exist).

5. Association Initialization

Before the first data transmission can take place from one SCTP
endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must
complete an initialization process in order to set up an SCTP
association between them.

The SCTP user at an endpoint should use the ASSOCIATE primitive to
initialize an SCTP association to another SCTP endpoint.

IMPLEMENTATION NOTE: From an SCTP-user's point of view, an
association may be implicitly opened, without an ASSOCIATE primitive
(see 10.1 B) being invoked, by the initiating endpoint's sending of
the first user data to the destination endpoint. The initiating SCTP
will assume default values for all mandatory and optional parameters
for the INIT/INIT ACK.

Once the association is established, unidirectional streams are open
for data transfer on both ends (see Section 5.1.1).

5.1 Normal Establishment of an Association

The initialization process consists of the following steps (assuming
that SCTP endpoint "A" tries to set up an association with SCTP
endpoint "Z" and "Z" accepts the new association):

A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must
provide its Verification Tag (Tag_A) in the Initiate Tag field.
Tag_A SHOULD be a random number in the range of 1 to 4294967295
(see 5.3.1 for Tag value selection). After sending the INIT, "A"
starts the T1-init timer and enters the COOKIE-WAIT state.

B) "Z" shall respond immediately with an INIT ACK chunk. The
destination IP address of the INIT ACK MUST be set to the source
IP address of the INIT to which this INIT ACK is responding. In
the response, besides filling in other parameters, "Z" must set
the Verification Tag field to Tag_A, and also provide its own
Verification Tag (Tag_Z) in the Initiate Tag field.

Moreover, "Z" MUST generate and send along with the INIT ACK a
State Cookie. See Section 5.1.3 for State Cookie generation.

Note: After sending out INIT ACK with the State Cookie parameter,
"Z" MUST NOT allocate any resources, nor keep any states for the
new association. Otherwise, "Z" will be vulnerable to resource
attacks.

C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-
init timer and leave COOKIE-WAIT state. "A" shall then send the
State Cookie received in the INIT ACK chunk in a COOKIE ECHO
chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED
state.

Note: The COOKIE ECHO chunk can be bundled with any pending
outbound DATA chunks, but it MUST be the first chunk in the packet
and until the COOKIE ACK is returned the sender MUST NOT send any
other packets to the peer.

D) Upon reception of the COOKIE ECHO chunk, Endpoint "Z" will reply
with a COOKIE ACK chunk after building a TCB and moving to the
ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk
MUST be the first chunk in the packet.

IMPLEMENTATION NOTE: An implementation may choose to send the
Communication Up notification to the SCTP user upon reception of a
valid COOKIE ECHO chunk.

E) Upon reception of the COOKIE ACK, endpoint "A" will move from the
COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-
cookie timer. It may also notify its ULP about the successful
establishment of the association with a Communication Up
notification (see Section 10).

An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.
They MUST be the only chunks present in the SCTP packets that carry
them.

An endpoint MUST send the INIT ACK to the IP address from which it
received the INIT.

Note: T1-init timer and T1-cookie timer shall follow the same rules
given in Section 6.3.

If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter
values, or lack of local resources, it MUST respond with an ABORT
chunk. It SHOULD also specify the cause of abort, such as the type
of the missing mandatory parameters, etc., by including the error
cause parameters with the ABORT chunk. The Verification Tag field in
the common header of the outbound SCTP packet containing the ABORT
chunk MUST be set to the Initiate Tag value of the peer.

After the reception of the first DATA chunk in an association the
endpoint MUST immediately respond with a SACK to acknowledge the DATA
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容