Rfc sctp pdf

Invalid Mandatory Parameter Unrecognized Parameters No User Data Cookie Received While Shutting Down Restart of an Association with New Addresses User-Initiated Abort Protocol Violation Association Initialization Normal Establishment of an Association Handle Stream Parameters Handle Address Parameters Generating State Cookie State Cookie Processing State Cookie Authentication An Example of Normal Association Establishment An Example of a Association Restart Other Initialization Issues Selection of Tag Value Path Verification User Data Transfer Management of Retransmission Timer RTO Calculation Retransmission Timer Rules Handle T3-rtx Expiration Failover from an Inactive Destination Address Stream Identifier and Stream Sequence Number Ordered and Unordered Delivery CRC32c Checksum Calculation Fragmentation and Reassembly Congestion Control Congestion Avoidance Fast Retransmit on Gap Reports Path MTU Discovery Fault Management Endpoint Failure Detection Path Failure Detection Path Heartbeat Handle "Out of the Blue" Packets Verification Tag Exceptions in Verification Tag Rules Termination of Association Abort of an Association Shutdown of an Association Interface with Upper Layer Security Considerations Security Objectives Countering Insider Attacks Protecting against Data Corruption in the Network Protecting Confidentiality Protecting against Blind Denial-of-Service Attacks Blind Masquerade Improper Monopolization of Services Network Management Considerations Parameters Necessary per Association i.

Per Transport Address Data General Parameters Needed IANA Considerations Payload Protocol Identifiers Port Numbers Registry Explicit Congestion Notification ICMP Handling Introduction 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.

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 [ RFC ]. The limitations that users have wished to bypass include the following: -- 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.

Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. It performs this service within the context of an association between two SCTP endpoints.

This section provides a consolidated list of the key terms and their definitions. Each user message occupies its own DATA chunk. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties.

The term "MAC" has different meanings in different contexts. Sending to different destination transport addresses does not necessarily guarantee getting separate paths. The definition includes the source address since an implementation MAY 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. This gives the sender an indication of the space available in the receiver's inbound buffer.

An association can be uniquely identified by the transport addresses used by the endpoints in the association. 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. In other words, a transport address is unique to an SCTP endpoint. 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. 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. One Stream Sequence Number is attached to each user message. 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.

TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.

Or in the opposite case, for a packet that has been sent but no acknowledgement has been received. Stewart Standards Track [Page 9] RFC Stream Control Transmission Protocol September o Unordered Message: 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.

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. These are depicted in Figure 2 and explained in the remainder of this section. A cookie mechanism, similar to one described by Karn and Simpson in [ RFC ], 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 Section 5 of this document. SCTP provides for graceful close i. SCTP also allows ungraceful close i. Section 9 describes both the graceful and the ungraceful close procedures. SCTP does not support a half-open state like TCP wherein one side may continue 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 Section 9.

Sequenced Delivery within Streams 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. The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end see Section 5. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed. 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. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery.

Stewart Standards Track [Page 12] RFC Stream Control Transmission Protocol September 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 Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function. Chunk Bundling As described in Section 3 , the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks.

Each chunk may contain either user data or SCTP control information. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission to attempt to encourage bundling. When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission. 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 should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network.

The SCTP 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 monitors reachability through heartbeats Stewart Standards Track [Page 13] RFC Stream Control Transmission Protocol September when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes.

The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user. 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.

Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items. Serial Number Arithmetic It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values.

Doing so will cause problems in comparing TSNs. All other arithmetic and comparisons in this document use normal arithmetic. Readers interested in the details of the various changes that this document incorporates are asked to consult [ RFC ]. A chunk contains either control information or user data. See Section 6. If a user data message doesn't fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.

It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. For details see Section 8. Its calculation is discussed in Section 6. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field.

It takes a value from 0 to The value of is reserved for future use as an extension field. Chunk Flags: 8 bits 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. 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. The Chunk Length value does not include terminating padding of the chunk.

However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding. Note: A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.

If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The receiver MUST ignore the padding bytes. SCTP-defined chunks are described in detail in Section 3. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below. It takes a value of 0 to The value of is reserved for IETF-defined extensions.

Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Chunk Parameter Value: variable length The Parameter Value field contains the actual information to be transferred in the parameter.

If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end i. The length of the padding is not included in the Parameter Length field. The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type.

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. Note that a parameter type MUST be unique across all chunks.

For example, the parameter type '5' is used to represent an IPv4 address see Section 3. If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to '1'. B bit: 1 bit The B eginning fragment bit, if set, indicates the first fragment of a user message. E bit: 1 bit The E nding fragment bit, if set, indicates the last fragment of a user message. Length: 16 bits unsigned integer This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding.

TSN wraps back to 0 after reaching Stream Identifier S: 16 bits unsigned integer Identifies the stream to which the following user data belongs. Stream Sequence Number n: 16 bits unsigned integer This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to Payload Protocol Identifier: 32 bits unsigned integer This value represents an application or upper layer specified protocol identifier.

This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk.

This field must be sent even in fragmented DATA chunks to make sure it is available for agents in the middle of the network. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data.

User Data: variable length This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. A sender MUST never add more than 3 bytes of padding. 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.

The Initiate Tag is allowed to have any value except 0. See Section 5. Note: There is no negotiation of the actual number of streams but instead the two endpoints will use the min requested, offered. The valid range is from 0 to It is binary encoded.

That is, during the life time 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.

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. This optional parameter should be added to the INIT chunk by the sender when it reattempts 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.

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. The method for resolving the host name is out of scope of SCTP. The other fields are defined the same as their counterparts in the INIT chunk. Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender.

This parameter therefore acknowledges receipt of all TSNs less than or equal to its value. The duplicate count is reinitialized to zero after sending each SACK. The parameter field contains the Heartbeat Information, which is a variable-length opaque data structure understood only by the sender. 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. The parameter field contains a variable-length opaque data structure. 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.

T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. Reflecting means that the sent Verification Tag is the same as the received one.

Note: Special rules apply to this chunk for verification; please see Section 8. 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. This chunk has the following format. Length: 16 bits unsigned integer Indicates the length of the parameter. Set to 8. It contains one or more error causes. Cause-Specific Information: variable length This field carries the details of the error condition.

Section 3. Reserved: 16 bits This field is reserved. It is set to all 0's on transmit and ignored on receipt. 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.

For this purpose, two new and one adapted congestion control approach — all based on the Resource Pooling principle — will be introduced and examined in similar as well as dissimilar path setups, in order to show how to fairly deploy Ietff transport in the Internet. Finally, we analyse the performance of our approaches by using simulations. Clearly, a key feature of this testbed is to work in the real-world Internet.

This talk provides an introduction to the NorNet Core testbed as well as a status overview on the development and deployment in August This leads to the desire for simultaneously utilising all available access paths to improve application data throughput. Any explicit references itef that referenced document should also be listed: However, real-life network measurements are missing.

Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.

With the rapid development of Internet communications, there is a growing demand to support devices being connected to multiple Internet service providers simultaneously. Then, it examines three test scenarios in the NorNet testbed, particularly highlighting the performance difference between using uncoupled and coupled congestion controls in multi-homed, real-world Internet setups.

For specific details on the protocol and its extensions, have frc look at the RFCs and various Internet Drafts in the Standardisation section. Rfcc this approach works well for similar paths, i. RFC defines the protocol. However, dissimilar paths — i. It is designed to transport PSTN signaling messages over the connectionless packet network, but is ierf of broader applications.

Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. An association id, which is a local handle to the SCTP association, will be returned on successful establishment of the association. We argue that this leads to ketf very conservative behavior when paths do not share a bottleneck. Clearly, service interruptions due to network problems may have a severe impact. Their larger-scale deployment in the Internet is expected for the near future.

Rrc endpoint accepts no new data from its upper layer, but retransmits data to the far end if necessary to fill gaps.

One of the transport addresses from the returned destination addresses will be selected by the local endpoint as default primary path for sending SCTP packets to this peer. However, nowadays, applications are beginning to directly set the DSCP themselves, in the hope that this will yield a more appropriate service for their respective video, audio and data streams. Each SCTP end point needs to ack the heartbeats it receives from the remote end point.

Today, a steadily growing number of ierf contains multiple network interfaces. NorNet, and particularly its landline network part NorNet Core, is furthermore described in some detail.

SCTP is a general-purpose Transport Layer protocol with out-of-the-box support for multi-streaming as well as multi-homing. Multi-homing denotes the simultaneous connection of endpoints e.

While the protocol itself is already quite old, its deployment has only recently picked up speed. Finally, we show some results of our performance evaluation. As opposed to renegable data, a data sender can consider non-renegable data as never requiring retransmission, and therefore can remove non-renegable data from the retransmission queue.

Procedures should be in place for the operator to act on such alarms if a clear pattern of abuse emerges. The user data will not be sent by SCTP after the life time expires.