2 - SCTP

Doc.
Code
eRAN2.2
SCTP
Issue Date
01 2011-09-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com support@huawei.com
Issue 01 (2011-09-30)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd
ii
eRAN2.2 SCTP
About This Document
About This Document

Change History
The change history records the changes in each release, and the change history in the latest document contains all changes in the documents in earlier versions.
Issue 01 (2011-09-30)
First official release.
Issue 01 (2011-09-30)
iii
eRAN2.2 SCTP
Contents
Contents
About This Document.....................................................................iii About This Document.....................................................................iii 1 Overview..................................................................................... 1 2 Terms.......................................................................................... 2 3 SCTP Functions............................................................................5
3.1 Association Setup and Shutdown............................................................................................................................5 3.2 Sequenced Delivery Within Streams.......................................................................................................................6 3.3 User Data Fragmentation.........................................................................................................................................6 3.4 Acknowledgement and Congestion Avoidance.......................................................................................................6 3.5 Chunk Bundling.......................................................................................................................................................7 3.6 Packet Validation.....................................................................................................................................................7 3.7 Path Management....................................................................................................................................................7
4 SCTP Primitive.............................................................................8
4.1 Request Primitive Sent from an SCTP User to the SCTP Protocol.........................................................................8 4.2 Notification Primitive Sent from an SCTP Protocol to an SCTP User..................................................................11
5 SCTP Messages..........................................................................13
5.1 Structure.................................................................................................................................................................13 5.2 SCTP Data Chunk Format.....................................................................................................................................18 5.3 SCTP Endpoint Maintenance Parameters and Recommended Values..................................................................33
6 SCTP Basic Signaling Procedure..................................................36

6.1 Association Setup..................................................................................................................................................36 6.2 Association Termination........................................................................................................................................39
Issue 01 (2011-09-30)
iv
eRAN2.2 SCTP
6 SCTP Basic Signaling Procedure
Overview
The Stream Control Transmission Protocol (SCTP) is a new Internet Protocol (IP) transport protocol, existing at an equivalent level with the User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), which provide transport layer functions to Signaling System No. 7. As a connectionless transmission protocol, the UDP cannot meet the requirements for transmission quality of Signaling System No. 7. As a transmission protocol with connections, the TCP provides reliable transmission with a congested header, poor realtime performance, and poor multihoming. In addition, denial of service (DoS) may attack the data during transmission. Therefore, the Internet Engineering Task Force (IETF) approves the reliable connection-oriented packet data transmission protocol SCTP in RFC2960. Unlike the TCP, the SCTP provides reliable signaling transmission. The design of the SCTP includes congestion avoidance behavior, resistance to flooding and spoofing attacks, and integration of the real-time performance and multihoming function. Therefore, the SCTP becomes one member of the SIGTRAN series protocols. The SCTP is regarded as a protocol applicable to the transport layer between the SCTP user application and packet network services. During actual application, the LTE control plane functions as SCTP upper-layer users, such as S1 Application Protocol (S1AP) and X2 Application Protocol (X2AP), and Internet Protocol (IP) networks function as the lower layer.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
2
Transport Address Host and SCTP Endpoint
Terms
A transport address is defined by an IP address, transport layer protocol, and transport layer port No. In the case of SCTP transportation over IP, a transport address is defined by an IP address and an SCTP port No. The SCTP uses the SCTP port No. to identify users with the same IP address. It has the same meaning as the TCP port No. For example, the IP address 10.105.28.92 and the SCTP port No. 1024 define a transport address, the IP address 10.105.28.93 and the SCTP port No. 1024 define a transport address, and the IP address 10.105.28.92 and the SCTP port No. 1023 define another transport address.
Host
A host is configured with one or more IP addresses, and is a typical physical entity.
SCTP endpoint
An endpoint is the basic SCTP logical concept. It transmits and receives data packets and is a typical logical entity. Each transport address defined by an IP address and an SCTP port No. identifies only one endpoint. An endpoint can be defined by multiple transport addresses. One target endpoint can be configured with different IP addresses, but with the same SCTP port No.
A host can have multiple endpoints.
Association and Stream
Association
Association is a logical connection or tunnel for data transmission. It is established between two SCTP endpoints following the four-way handshake mechanism defined in the SCTP protocol. The SCTP protocol defines that two endpoints can have only one association at any time. Association is defined by the transport addresses of two endpoints. After configuring the local IP address, local SCTP port No., peer IP address, and peer SCTP port No., a unique SCTP association is determined.
Issue 01 (2011-09-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 2
eRAN2.2 SCTP
Stream
Stream is a special term in the SCTP protocol. The term stream is used in an SCTP association to specify a sequence of user messages to be delivered to the upper-layer protocol. Generally, messages in the same stream are delivered in a sequence. A stream refers to a unidirectional logical tunnel from one endpoint to another endpoint in an SCTP association. Each association consists of multiple unidirectional streams. The streams, identified by different IDs, are independent from each other. Each steam can transmit data without interference from other streams.
Each association can have multiple streams, and the number of available streams depends on the negotiation result of the two endpoints during association setup. In addition, one stream belongs to only one association. The number of outbound streams can be different from that of inbound streams. Data delivered in sequence must be transmitted in the same stream.
Path and Primary Path
Path
A path refers to a route on which an endpoint transmits SCTP packets to the specific transport address of the peer endpoint. If the packet data is to be transmitted to different destination transport addresses, an independent path is not required.
Primary path
A primary path refers to a path on which the source and target addresses in an SCTP packet are transmitted to the peer endpoint by default. If multiple target addresses function as the target address of an endpoint, the endpoint supports multihoming. If the endpoint transmitting SCPT packets supports multihoming, the source and target addresses must be defined so that the following two items can be controlled: the path for responding to the returned chunk and the interface to transmit packets. The two SCTP endpoints of an SCTP association can be configured with multiple IP addresses. Therefore, there are multiple paths between the two endpoints. In this case, the SCTP association supports multiple addresses. This feature is the unique difference of the SCTP from the TCP. The principle for an endpoint to transmit SCTP packets is as follows: The local endpoint transmits the SCTP packets from the transport address A to the peer endpoint through the primary path. If the primary path is faulty, the SCTP packet is automatically switched to a standby path. The transport address of the peer endpoint takes precedence over the transport address of the local endpoint. The SCTP protocol also defines heartbeat messages. If a path is in idle mode, the local SCTP user instructs the SCTP protocol to generate a heart beat message and sends the message to the peer endpoint through this idle path. Then, the peer endpoint must respond with a heat beat acknowledgement message immediately. This mechanism is used to precisely measure the round trip time (RTT). In this case, association status can be monitored in real time and the active state of an SCTP association can be sustained.
TSN and SSN
Transmission sequence number (TSN)
The SCTP protocol uses the TSN mechanism to acknowledge data transmission. In an association, each chunk sent from one endpoint to the peer endpoint is assigned a 32-bit
eRAN2.2 SCTP
sequence number derived from the initial TSN in sequence. The TSN is maintained in an association.
In the TCP protocol, the acknowledgement of data transmission and data delivery in sequence is implemented based on the TSN. If the TSN is not consecutive, data is retransmitted based on the TCP protocol until the TSN is consecutive. Then, data is transmitted to upper-layer users. However, this mechanism defined in the TCP protocol cannot meet the requirements for low-rate transmission delay specified in the Signaling System No. 7.
Stream sequence number (SSN)
The SCTP protocol assigns a 16-bit SSN for each chunk transmitted from the local endpoint in a stream in sequence. This ensures sequence transmission in the stream. During association setup, the SSNs for all streams start from 0. If the SSN reaches 65535, the next SSN starts from 0. The TSN and SSN are independent from each other.
Congestion Window (CWND)

The SCTP protocol supports a sliding window. A congestion window is maintained in each target address, and can adjust its size based on the network status. If the length of an unacknowledged message sent from the target address exceeds the size of the CWND, the endpoint stops transmitting data to the address.
Receive Window (RWND)

The RWND specifies the size of a receive buffer for a peer endpoint in an association. During association setup, the two endpoints exchange their RWNDs. The RWND adjusts itself based on the status of data transmission and acknowledgement. The RWND size specifies the maximum size of data that can be transmitted based on the SCTP protocol. If the RWND size is 0, one more packet can be transmitted based on the SCTP protocol to obtain the buffer changes of the peer endpoint. It keeps on transmitting packets until it is restricted by the CWND value.
Transmission Control Block (TCB)

A TCB is an internal data structure. It is generated by an SCTP endpoint for each association between the SCTP endpoint and other endpoints. The TCB contains all the status and operation information about an endpoint. This helps the endpoints maintain and manage the corresponding association.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
3
Figure 1.1 SCTP functions
SCTP Functions
SCTP functions include association setup and shutdown, sequenced delivery within streams, user data fragmentation, acknowledgement and congestion avoidance, chunk bundling, packet validation, and path management.
3.1 Association Setup and Shutdown

An association is initiated by a request from the SCTP users, such as S1AP and X2AP. Association startup is complex compared with a TCP connection. It is a four-way handshake and uses the cookie mechanism. A cookie is a chunk containing initial information and encryption information about an endpoint. It is processed and exchanged between two endpoints during association setup. This ensures protocol security and avoids spoofing attacks and DoS. The SCTP protocol provides a shutdown function in a normal situation for active associations. The function must be performed based on SCTP user requests. In addition, the SCTP protocol provides a shutdown function in an emergency such as interruption. This function can be
eRAN2.2 SCTP
started based either on SCTP user requests or errors detected by the SCTP protocol. The SCTP protocol does not support half-enabled status, that is, one endpoint continues transmitting data after the peer endpoint stops transmitting data. If either of two endpoints performs this function, the two endpoints of an association must stop receiving request primitives from SCTP users.
3.2 Sequenced Delivery Within Streams

Packets can be delivered in a sequence based on the SCTP protocol, and must be transmitted in the same stream. A stream is the basic for sequenced delivery. In a stream, the SCTP protocol defines two mechanisms for data transmission acknowledgement and sequenced delivery. It uses the TSN mechanism for data transmission acknowledgement, and uses the stream No. and SSN mechanism for sequenced delivery. If SCTP receives data with sequenced SSNs, it delivers the data to SCTP users, and does not need to deliver the data after the TSN is consecutive. If a stream is blocked, the next consecutive SCTP user message can be delivered on another stream. The SCTP also provides data delivery without sequence. A received user message can be delivered in this mode to SCTP users without considering the sequence.
3.3 User Data Fragmentation

The SCTP protocol detects the path maximum transmission unit (PMTU) on each path to pack user data with a large size. This avoids multiple fragmentations and regrouping on the IP layer, and reduces data on the IP layer.
On the transmit end, the SCTP protocol fragments user data with a large size to allow the data to apply to the maximum transmission unit (MTU) on the path at the lower layer. On the receive end, the SCTP combines all fragmented data to form a complete packet, and then delivers it to SCTP users.
3.4 Acknowledgement and Congestion Avoidance

Acknowledgement and congestion avoidance is a policy to ensure data transmission reliability. The acknowledgement mechanism is basic for data transmission reliability. Congestion avoidance derives from the TCP window mechanism to control traffic.
The SCTP protocol assigns a TSN to each data fragment or user packet without fragmentation in sequence and then transmits the data to the lower layer. The TSN and SSN are independent from each other. The TSN is used to ensure data transmission reliability, and the SSN is used to ensure that messages within a stream are transmitted in sequence. The TSN and SSN separate reliable transmission from sequenced transmission. The receive end acknowledges all TSNs, even if there are gaps in the sequence.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 6
Issue 01 (2011-09-30)
eRAN2.2 SCTP
Packet retransmission is used to acknowledge the TSN and congestion avoidance.
3.5 Chunk Bundling

If user data with a short length has an SCTP message header with a large size, data transmission efficiency decreases. Therefore, the SCTP protocol binds several user data into an SCTP packet to efficiently use bandwidth resources.
An SCTP packet consists of a common header followed by one or more chunks. Each chunk can contain either user data or SCTP control information. SCTP users can request bundling of more than one user messages into a single SCTP packet based on requirements. To improve bundling efficiency, bundling is performed during congestion or retransmission, even if users have stopped this function.
3.6 Packet Validation

Packet validation ensures reliably data transmission without errors. The common header of an SCTP packet consists of a verification tag and an optional 32-bit checksum. The value of a verification tag is determined by each end of an association during association setup. If a received packet does not contain the expected value of the verification tag, the receive end will discard this packet to avoid attacks and invalid SCTP packets. The 32-bit checksum is set by the transmit end of each SCTP packet to provide additional protection against data corruption in the network. The receive end discards an SCTP packet with an invalid 32-bit checksum.
3.7 Path Management

SCTP users at the transmit end use a set of transport addresses as destinations for SCTP packets. The SCTP path management function chooses a destination transport address for each SCTP packet that has been transmitted based on the SCTP user's instructions and the reachability status of the currently valid destination set. If other packet traffic cannot indicate the reachability, the path management function can monitor the reachability of a destination transport address using heartbeat messages. In addition, this function can provide information for an SCTP user if the reachability of any transport addresses changes. The path management function can also report the set of local transport addresses to the peer end during association setup, and report the transport addresses returned from the peer end to SCTP users. During association setup, the path management function defines a primary path for each SCTP endpoint to transmit SCTP packets. At the receive end, the path management function checks whether the association to which the inbound SCTP packet belongs exists before the SCTP packets is processed.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
4
SCTP primitive uses the following formats:

SCTP Primitive
The SCTP protocol receives the request primitive sent from SCTP users served by the upperlayer protocol, and then provides services for SCTP users. In addition, the SCTP protocol informs SCTP users of notification primitive based on different events.
Primitive name: mandatory attribute [optional attribute] Returned result: mandatory attribute [optional attribute]
4.1 Request Primitive Sent from an SCTP User to the SCTP Protocol
Table 1.1 shows the 16 types of request primitives sent from an SCTP user to the SCTP protocol. Table 1.1 SCTP request primitives Name INITIALIZE Function This primitive allows the SCTP protocol to initiate its internal data structure and allocate necessary resources for setting up its operation environment. After the SCTP protocol is initiated, the upper-layer protocol can communicate with other endpoints without using this primitive. The SCTP protocol returns a local SCTP association instance name to the upper-layer protocol.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
Name ASSOCIATE
Function This primitive allows the upper layer to initiate an association to a specific peer endpoint. The peer endpoint is specified by one of the transport addresses that define the endpoint. If the association instance is not started, this primitive is regarded as an error. An association ID, which is used to locally process an SCTP association, is returned to indicate whether an association is successfully set up. If association setup fails, an error code is returned. If association setup succeeds, the returned result contains the complete peer destination transport addresses and the number of outbound streams at the local endpoint. One of the transport addresses is chosen as the default primary path for sending SCTP packets to the peer endpoint. SCTP uses can use the returned destination transport address list to change the primary path or to forcibly send an SCTP packet to a specific transport address. Returned result: association ID
SHUTDOWN
This primitive is used to gracefully close an association. Any locally queued user data is delivered to the peer endpoint. The association is terminated only after the peer endpoint acknowledges all received SCTP packets. The returned result indicates whether an association is successfully closed. A success code is returned if an association is successfully closed. Otherwise, an error code is returned.
ABORT
This primitive is used to ungracefully close an association. Any locally queued user data is discarded and an ABORT chunk is sent to the peer endpoint. The returned result indicates whether an association is successfully aborted. A success code is returned if an association is successfully aborted. Otherwise, an error code is returned.
SEND
This primitive allows SCTP users to instruct the SCTP protocol to transmit data to a destination transport address in the specific stream. The returned result indicates whether data is successfully transmitted. This primitive allows the upper-layer protocol to instruct the local SCTP protocol to use the specific destination transport address as the primary path for transmitting a packet. The returned result indicates whether the operation succeeds. If the specified destination transport address is not in the destination transport address list returned earlier in an ASSOCIATE request primitive or COMMUNCIATION UP notification primitive, an error code is returned.
SET PRIMARY
RECEIVE
This primitive reads the available user message in the SCTP queue into the buffer specified by SCTP users. The size of messages that have been read is returned in bytes. Other information may be returned based on specific requirements, for example, transmit end's address, the stream ID on which the message is received, and whether there are more available messages for recovery. For sequenced messages, the SSN may also be returned.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
Name STATUS
Function This primitive returns a data block containing the following information:

Association connection state Destination transport list Destination transport address reachability states Current receive end window size Current congestion window size Number of unacknowledged DATA chunks Number of received DATA chunks Primary path Recently received SRTT on the primary path RTO on the primary path
The returned results indicate the status of a specific message. CHANGE HEARTBEAT This primitive allows the upper-layer protocol to instruct the local endpoint to enable or disable heartbeat messages to the specified destination transport address. The returned result indicates the operating status. Heartbeat takes place only when the destination transport address is idle. REQUEST HERATBEAT This primitive instructs the upper-layer protocol to instruct the local endpoint to perform a heartbeat on the specified destination transport address with the specific association. The returned result indicates whether the HEART BEART chunk is successfully transmitted to the destination transport address. GET SRTT REPORT This primitive allows the upper-layer protocol to instruct the local SCTP protocol to report the current SRTT measurement on the specified destination transport address with the specific association. The returned result is an integer containing the latest SRTT in milliseconds. SET FRAILURE THRESHOLD SET PROTOCOL PARAMETER S RECEIVE UNSENT MESSAGE This primitive allows the local SCTP protocol to customize the threshold for detecting a reachability failure for the specified destination transport address. The returned result indicates whether the operation succeeds. This primitive allows the local SCTP protocol to customize the protocol parameters. The returned result indicates whether the operation succeeds. This primitive allows the upper-layer protocol to instruct the local SCTP protocol to save the received failure messages in the buffer defined by the upper-layer protocol. The returned result shows the failure messages in bytes.
Issue 01 (2011-09-30)
10
eRAN2.2 SCTP
Name RECEIVE UNACKNOW LEDGED MESSAGE DESTROY
Function This primitive allows the upper-layer protocol to instruct the local SCTP protocol to save the received unacknowledged failure messages in the buffer defined by the upper-layer protocol. The returned result shows the unacknowledged failure messages in bytes. This primitive indicates the destroyed SCTP events. The SCTP event No. is generated by the INITIALIZE primitive. The returned result indicates whether the operation succeeds.
4.2 Notification Primitive Sent from an SCTP Protocol to an SCTP User

Table 1.1 shows the 8 types of notification primitives sent from an SCTP protocol to an SCTP user. Table 1.1 SCTP notification primitives Name DATA ARRIVE Function This primitive allows the SCTP protocol to notify an upper-layer user when a user message is successfully received and is to be transmitted to an SCTP user. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Stream ID: specifies the stream from which data is received.
SEND FAILURE
This primitive allows the SCTP protocol to notify an SCTP user if a message cannot be transmitted. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Data recovery ID: indicates the untransmitted and unacknowledged data to be recovered. Cause code: indicates the reason of a failure, for example, large size, message lifetime expiration.
NETWORK STATUS CHANGE
If a destination transport address is marked inactive, for example, when the SCTP protocol detects a failure, or marked active, for example, when the SCTP protocol detects a fault rectification, the SCTP uses this primitive to notify an SCTP user. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Destination transport address: indicates the destination transport address of the peer endpoint affected by a status change. New status: indicates the new status.
Issue 01 (2011-09-30)
11
eRAN2.2 SCTP
Name COMMUNCIA TION UP
Function The primitive allows the SCTP protocol to notify an SCTP user that the local SCTP protocol is ready for receiving and transmitting SCTP packets or an endpoint losing communication is restored. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Status: indicates the type of events that occur. Destination transport address list: indicates the complete set of transport addresses for the peer endpoint. Number of outbound streams: indicates the maximum number of streams that allowed to be used by an SCTP user. Number of inbound streams: indicates the number of streams that requested by the peer endpoint in the association. The value may be different from the number of outbound streams.
COMMUNICA TION LOST
If the SCTP protocol cannot communicate with an endpoint using heartbeat messages or detects that the endpoint has performed an abort, it uses this primitive to notify an SCTP user. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Status: indicates the type of events that occur. The status indicates a failure or a normal termination event occurred in response to a SHUTDOWN or ABORT request. Data recovery ID: indicates the untransmitted and unacknowledged data to be recovered. Last-acknowledged TSN: indicates the last TSN that is acknowledged by the peer endpoint. Last-transmitted TSN: indicates the last TSN received by the peer endpoint.
COMMUNICA TION ERROR
If the SCTP protocol receives an ERROR chunk from the peer endpoint, the SCTP protocol uses this primitive to notify the upper-layer protocol. The following information is to be transmitted:

Association ID: specifies an SCTP association processed locally. Error information: indicates the error types and additional information optionally received from the ERROR chunk.
RESTART
This primitive allows the SCTP protocol to notify an SCTP user when the protocol detects that the peer endpoint is restarted. Association IDs are transmitted. This primitive allows the SCTP protocol to notify an SCTP user after the protocol closes an association. IDs of SCTP associations processed locally are transmitted.
SHUTDOWN COMPLETE
Issue 01 (2011-09-30)
12
eRAN2.2 SCTP
5
5.1 Structure
Figure 1.1 Structure of an SCTP packet
16 bits Source Port Number
SCTP Messages
Figure 1.1 shows the structure of an SCTP packet.
16 bits
Destination Port Number
Verification Tag
Common Header
Checksum
Chunk Type
Chunk Flags
Chunk Length Chunk #1
Chunk Value
Chunk Type
Chunk Flags
Chunk Length
Chunk #n Chunk Value
Issue 01 (2011-09-30)
13
eRAN2.2 SCTP
Each SCTP packet consists of a common header and several chunks, and each chunk contains control information or user data. All chunks except INIT, INIT ACK, and SHUTDOWN COMPLETE can be bound into an SCTP packet to meet the requirements for the MTU size. Each of the chunks may be independent from other chunks in an SCTP packet. If a user message cannot be transmitted in an SCTP packet, the message can be divided into several chunks.
Format of a Common Header

An SCTP common header consists of the source port No., destination port No., verification tag, and checksum.
Source port No. (16 bits)
It specifies the SCTP port No. for an SCTP transmit endpoint. The receive end can use the source port No., source IP address, destination port No., and destination IP address to specify the association to which an SCTP packet belongs.
Destination port No. (16 bits)
It specifies the SCTP port No. of the destination endpoint. The receive end can use this destination port No. to demultiplex an SCTP packet to the correct receive endpoint or application.
Verification tag (32 bits)
It is a random mark generated by the local endpoint for the association during association setup. During association setup, the two endpoints exchange the tag. Then, the transmit end must contain the tag of the peer endpoint in the common header for verification before data transmission.
Verification code (32 bits)
The SCTP protocol obtains a 32-bit verification code after using the ADLER-32 algorithm for user data. In the data packet, the receive end performs the same calculation and uses the verification code to check whether the user data is damaged.
Chunk Format
Each chunk is formatted with the following fields: Chunk Type, Chunk Flag, Chunk Length, and Chunk Value.
Chunk type (8 bits)
The chunk type specifies the type of information contained in the Chunk Value field. Table 1.1 lists the major chunk types. Table 1.1 SCTP chunk types ID 0 1 Chunk Type DATA (payload data) INIT Description Specifies a user chunk to be transmitted. Initiates an SCTP association between two endpoints.
Issue 01 (2011-09-30)
14
eRAN2.2 SCTP
ID 2 3
Chunk Type INIT ACK SACK
Description Acknowledges the initiated messages related to an SCTP association. Transmitted to the peer endpoint to acknowledge a received DATA chunk and notify the peer endpoint of the sequence interval for the received DATA chunk. Transmitted by an endpoint to the peer endpoint to check the reachability of a specific destination transport address defined in the current association. Responds to a HEARTBEAT chunk. Aborts an association. Used by an endpoint in an association to gracefully close the association. Responds to a SHUTDOWN chunk and transmitted after an association is closed. Transmitted to the peer endpoint to notify it of an SCTP association error. Used only during association setup and transmitted by the initiating end of an association to the peer endpoint. Acknowledges a COOKIE ECHO chunk. Reserved for providing an echo after congestion occurs in the external environment. Reserved for reducing the congestion window. Acknowledges a SHUTDOWN ACK chunk after a closure program. Reserved by IETF. Used for IETF-defined chunk extension. Reserved by IETF. Used for IETF-defined chunk extension. Reserved by IETF. Used for IETF-defined chunk extension. Reserved by IETF. Used for IETF-defined chunk extension.
HEARTBEAT
5 6 7 8 9 10 11 12 13 14 15 to 62 63 64 to 126 127 128 to 190 191 192 to 254 255
HEARTBEAT ACK ABORT SHUTDOWN SHUTDOWN ACK ERROR COOKIE ECHO COOKIE ACK ECNE CWR SHUTDOWN COMPLETE
If the receive endpoint cannot identify a chunk type, the two left-most bits of this field
eRAN2.2 SCTP
indicate various operations. Table 1.2 shows the meanings for different combination of bits. Table 1.2 Meanings for the two left-most bits Two Left-most Bits 00 01 Meaning Stop processing an SCTP packet and discard it, and do not process other chunks in the SCTP packet. Stop processing an SCTP packet and discard it, do not process other chunks in the SCTP packet, and report the unrecognized parameters in the ERROR or INIT ACK chunk to the initiating endpoint. Skip this chunk and continue processing. Skip this chunk and continue processing and report the unrecognized parameters in the ERROR or INIT ACK chunk to the initiating endpoint.
10 11
Chunk Flags (8 bits)
The usage of the bits depends on the chunk type. Unless otherwise specified, the bits are set to 0 on the transmit endpoint and are ignored by the receive endpoint.
Chunk Length (16 bits)
The chunk length specifies the size of a chunk in the binary system, including the following fields: Chunk Type, Chunk Flags, Chunk Length, and Chunk Value.
Chunk Value (variable length)
The Chunk Value field contains actual information to be transmitted in a chunk. The content depends on the chunk type. The value is variable.
The total length of a chunk, including type, length, and value, must be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the transmit end must add 0s to the chunk and the padding is not included in the chunk length. The receive end can add a maximum of 3 bytes, and all the added bytes are ignored at the receive end.
Optional or Variable-Length Parameter Format

Chunk values of an SCTP control chunk except the DATA chunk consist of a chunk-typespecific header with required fields, followed by one or more parameters. The optional and variable-length parameters contained in a chunk are defined based on the parameter type, parameter length, and parameter value, as shown in Figure 1.2.
Issue 01 (2011-09-30)
16
eRAN2.2 SCTP
Figure 1.2 Optional or variable-length parameter format

16 bits 16 bits
Parameter Type Parameter Value
Parameter Length
Chunk Parameter Type (16 bits)
It specifies the parameter type, and the value ranges from 0 to 65534. The value 65535 is reserved for IETF-defined extension. If the receive endpoint cannot identify a parameter type, the two left-most bits of this field indicate various operations. Table 2.1 shows the meanings for different combination of bits. Table 2.1 Meanings for the two left-most bits Two Leftmost Bits 00 01 Meaning Stop processing an SCTP packet and discard it, and do not process other chunks in the SCTP packet. Stop processing an SCTP packet and discard it, do not process other chunks in the SCTP packet, and report the unrecognized parameters in an Unrecognized Parameter Type field in the ERROR or INIT ACK chunk. Skip this chunk and continue processing. Skip this chunk and continue processing and report the unrecognized parameters in an Unrecognized Parameter Type field in the ERROR or INIT ACK field.
10 11
Chunk Parameter Length (16 bits)
It contains the size of the parameter in bytes, including the following fields: Parameter Type, Parameter Length, and Parameter Value. If the Parameter Value field of a parameter is 0, its Length field is 4. The parameter length does not include any padding bytes.
Chunk parameter value (variable length)
The Parameter Value field contains actual information to be transmitted in the parameter.
The total length of a parameter, including type, length, and value, must be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the transmit end must add 0s to the chunk and the padding is not included in the parameter length. The receive end can add a maximum of 3 bytes, and all the added bytes are ignored at the receive end.
Issue 01 (2011-09-30)
17
eRAN2.2 SCTP
5.2 SCTP Data Chunk Format

DATA Chunk Format
Figure 1.1 shows the DATA chunk format. Figure 1.1 DATA chunk 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 = 0 Reserve U B E Length
TSN Stream ID SSN
Payload Protocol Identifier
User Data
The Type field is set to 0. The reserved 5 bits are all set to 0s and ignored at the receive end. U bit (1 bit)
U bit is an unordered bit. If the U bit is set to 1, this chunk is an unordered DATA chunk and no SSN is assigned to this DATA chunk. Therefore, the receive end must ignore the SSN. After re-assembly (if necessary), unordered DATA chunks do not need to be reordered before being dispatched to the SCTP users by the receive end. If an unordered user message is fragmented, the U bit in each message fragment must be set to 1.
B bit B bit is a beginning fragment bit. If it is set in a fragment, the fragment is the first fragment of a user message.
E bit E bit is an ending fragment bit. If it is set in a fragment, the fragment is the last fragment of a user message. The B and E bits in an unfragmented user message must be set to 1. If both the B and E bits are set to 0 in a fragment, the fragment is a middle fragment of a multi-fragment user message. If a user message is fragmented into multiple chunks, the receive end must use TSNs to reassemble the message. The TSNs for the fragments of a fragmented user message must be sequential. Table 1.1 describes the meanings for the values of B and E bits.
Issue 01 (2011-09-30)
18
eRAN2.2 SCTP
Table 1.1 Meanings for the values of B and E bits BE 10 00 11 11 Meaning Indicates the first fragment of a user message. Indicates the middle fragment of a user message. Indicates the last fragment of a user message. Indicates an unfragmented message.
Length (16 bits) The Length field indicates the number of bytes between the beginning of the Type field and the end of the User Data field, excluding any padding. If the User Data field of a DATA chunk is 0, the Length field of the DATA chunk is set to 16.
TSN (32 bits) The TSN field specifies the TSN of a DATA chunk and the valid value ranges from 0 to 4294967295 (232 1). The TSN value starts from 0 after reaching 4294967295.
Stream ID The Stream ID field identifies the stream carrying user data. The value of this field is generated by the transmit end transmitting INIT and INIT ACK chunks.
SSN (16 bits) The SSN field specifies the transmission sequence number of user data in a stream. The valid value range of this field is 0 and 65535. If a user message is fragmented based on the SCTP, each fragment of the user message must have the same SSN.
Payload Protocol Identifier (32 bits) The Payload Protocol Identifier field specifies an application (or upper layer) identifier. The value of this field is transmitted to SCTP by its upper layer and then sent to its peer layer. The payload protocol identifier is not used by SCTP, but can be used by a network entity or the peer application to identify the type of the information in a DATA chunk. This field must be sent even in fragmented DATA chunks to ensure that agents in the network can use it. If this field is set to 0, the upper layer does not specify any application identifiers for the payload data.
User Data (variable length) The User Data field specifies payload user data. This field must be set to a value of a 4 byte boundary with all-zero bytes. A transmit end can add a maximum of 3 bytes of padding. A receive end ignores the padding.
INIT Chunk Format

The INIT chunk is used to initiate an association between two SCTP endpoints. Figure 1.2 shows the INIT chunk format:
Issue 01 (2011-09-30)
19
eRAN2.2 SCTP
Figure 1.2 INIT chunk 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 = 1 Chunk Flags Length
Initiate Tag Advertised Receiver Window Credit Number of Outbound Streams Initial TSN Optional/Variable-Length Parameters Number of Inbound Streams
An INIT chunk contains the following fields. Unless otherwise expressly noted, each of the following fields can be included once in an INIT chunk. Mandatory fields: Initiate Tag, Advertised Receiver Window Credit, Number of Outbound Streams, Number of Inbound Streams, and Initial TSN. Variable fields: IPV4 Address, IPV6 Address, Cookie Preservative, Reserved for ECN Capable, Host Name Address, and Supported Address Types.
Chunk Flags The Chunk Flags field in an INIT chunk is reserved and all bits in the field are set to 0. Fields in an INIT chunk can be processed in any order.
Initiate Tag (32 bits) The receive end of the INIT chunk records the value of the Initiate Tag field. The parameter value must be put in the Verification Tag field in each SCTP packet transmitted by the receive end of the INIT chunk within this association. The Initiate Tag field can be set to any value except 0. If the value of the Initiate Tag field in a received INIT chunk is 0, the receive end must treat it as an error and transmit an ABORT chunk to abort the association.
Advertised Receiver Window Credit (A_RWND:32 bits) The Advertised Receiver Window Credit field specifies the dedicated buffer size in bytes. The transmit end of the INIT chunk reserves a window for the association. During the lifetime of the association, the buffer size does not decrease and dedicated buffers cannot be taken away from this association. However, an endpoint can change the value of the A_Rwnd field in SACK chunks sent by it.
Number of Outbound Streams (OS) The OS field specifies the number of outbound streams the transmit end of an INIT chunk expects to create in this association. This field cannot be set to 0. If a receive end receives an INIT chunk with the OS field set to 0, the receive end aborts the association.
Number of Outbound Streams (MIS) The MIS field specifies the maximum number of streams the transmit end of the INIT chunk allows the peer endpoint to create in this association. This field cannot be set to 0.
Issue 01 (2011-09-30)
20
eRAN2.2 SCTP
If a receive end receives an INIT chunk with the MIS field set to 0, the receive end aborts the association.
Initial TSN The Initial TSN field specifies the TSN to be used by the transmit end. This field can be set to the value of the INIT Tag field.
IPv4 Address The IPv4 Address field specifies an IPv4 address in binary coding for the transmit end. An INIT chunk may contain multiple IPv4 addresses, IPv6 addresses, or combination of IPv4 and IPv6 addresses.
IPv6 Address The IPv6 Address field specifies an IPv6 address in binary coding for the transmit end. An INIT chunk may contain multiple IPv4 addresses, IPv6 addresses, or combination of IPv4 and IPv6 addresses. A transmit end can use the IPv4 address specified by the IPv4 Address field, instead of mapping an IPv4 address to an IPv6 address. The value of the IPv4 Address or IPv6 Address field, combined with the source port number in the SCTP common header, indicates a transport address supported by the transmit end of the INIT chunk. During the lifetime of the association, the IP address can appear in the source address field of an IP packet sent from the transmit end of the INIT chunk, or be used as a destination address of an IP packet sent from the receive end of the INIT chunk. If the transmit end of an INIT chunk supports multihoming, the INIT chunk can contain more than one IP address parameter. A transmit end supporting multihoming can access different types of networks, and therefore more than one address type may appear in an INIT chunk, that is, an IPv4 address and an IPv6 address can appear in the same INIT chunk. If an INIT chunk contains at least one IP address parameter, the following addresses can be used as destination addresses by the receive end of the INIT chunk:

Source address of the IP packet in the INIT chunk Any additional addresses provided in the INIT chunk If the INIT chunk does not contain any IP address parameters, the receive end of the INIT chunk must use the source address in the received IP packet as its destination address for the association.
Cookie Preservative The transmit end of the INIT chunk must use this field to suggest to the receive end of the INIT chunk for a longer life-span of the Cookie state. The transmit end adds the Cookie Preservative field to the INIT chunk when it re-attempts to establish an association with a peer to which its previous attempt of establishing the association fails. The receive end can ignore the suggested cookie lift-span increase to ensure its security. The Cookie Preservative field contains the Suggested Cookie Life-span Increment field that has a 32-bit value. The Suggested Cookie Life-span Increment field indicates the increment in milliseconds the transmit end expects the receive end to add to the default cookie life-span.
Host Name Address The transmit end of the INIT chunk uses this field to pass its Host Name instead of its IP addresses to the peer layer. The peer layer resolves the name. This field increases the possibility for the association working across a NAT box.
Host Name The length of the host name is variable. The Host Name field specifies a host name based on the host name syntax in RFC1123. This document does not describe the method for resolving the host name.
Issue 01 (2011-09-30)
21
eRAN2.2 SCTP
The host name string contains at least one null terminator and the length of the null terminator(s) must be included in the length of the host name.
Supported Address Types The transmit end of the INIT chunk uses the Supported Address Types field to list all the address types it supports.
Address Type The Address Type field specifies an address type, such as IPv4 = 5, IPv6 = 6, and Hostname = 11.
INIT ACK Chunk Format

The INIT ACK chunk acknowledges the initiation of an SCTP association. As shown in Figure 1.3, the format of an INIT ACK chunk is similar to that of an INIT chunk. An INIT ACK chunk uses two extra variable fields: State Cookie and Unrecognized Parameter Figure 1.3 INIT ACK chunk format
0 1 2 3
Initiate Tag Advertised Receiver Window Credit Number of Outbound Streams Initial TSN Optional/Variable-Length Parameters Number of Inbound Streams
Initiate Tag (32 bits) The receive end of the INIT ACK records the value of the Initiate Tag field. The value of this field must be put into the Verification Tag field in each SCTP packet transmitted by the receive end of the INIT ACK chunk within this association. This field can be set to any values except 0. If the value of the Initiate Tag field in a received INIT ACK chunk is 0, the receive end must treat it as an error and transmit an ABORT chunk to abort the association.
Advertised Receiver Window Credit (32 bits) The Advertised Receiver Window Credit field specifies the dedicated buffer size in number of bytes. The transmit end of the INIT ACK chunk reserves a window for the association. During the lifetime of the association, the buffer size does not decrease.
Number of Outbound Streams (OS: 16 bits) The OS field specifies the number of outbound streams the transmit end of an INIT ACK chunk expects to create in this association. This field cannot be set to 0. If a receive end receives an INIT ACK chunk with the OS field set to 0, the receive end aborts the
Issue 01 (2011-09-30)
22
eRAN2.2 SCTP
association and discards the TCB.
Number of Inbound Streams (MIS: 16 bits) The MIS field specifies the maximum number of streams the transmit end of the INIT ACK chunk allows the peer endpoint to create in this association. This field cannot be set to 0. If a receive end receives an INIT ACK chunk with the OS field set to 0, the receive end aborts the association and discards the TCB.
Initial TSN (32 bits) The Initial TSN field specifies the TSN to be used by the transmit end. This field can be set to the value of the INIT Tag field.
IPV4 Address and IPv6 Address The value of the IPv4 Address or IPv6 Address field, combined with the source port number in the SCTP common header, indicates a transport address supported by the transmit end of the INIT ACK chunk. During the lifetime of the association, the IP address can appear in the source address field of an IP packet sent from the transmit end of the INIT ACK chunk, or be used as a destination address of an IP packet sent from the receive end of the INIT ACK chunk. If the transmit end of an INIT chunk supports multihoming, the INIT ACK chunk can contain more than one IP address parameter. A transmit end supporting multihoming can access different types of networks, and therefore more than one address type may appear in an INIT ACK chunk, that is, an IPv4 address and an IPv6 address can appear in the same INIT ACK chunk. If an INIT ACK chunk contains at least one IP address parameter, the following addresses can be used as destination addresses by the receive end of the INIT ACK chunk:

Source address of the IP packet in the INIT ACK chunk Any additional addresses provided in the INIT ACK chunk
If the INIT ACK chunk does not contain any IP address parameters, the receive end of the INIT ACK chunk must use the source address in the received IP packet as its destination address for the association.
State Cookie The length of the State Cookie field depends on the length of a cookie. This field value must contain all the necessary state, field information, and message authentication code required for the transmit end of this INIT ACK chunk to set up the association.
Unrecognized Parameters: variable size The Unrecognized Parameters field is returned to the originator of the INIT chunk containing an unrecognized parameter with a value indicating that the field must be reported to the transmit end. The value of this field contains unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
SACK Chunk Format

The SACK chunk is used 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. A gap indicates that the received TSNs of DATA chunks are not sequential. Figure 1.4 shows the SACK chunk format.
Issue 01 (2011-09-30)
23
eRAN2.2 SCTP
Figure 1.4 SACK chunk format

0 1 2 3
Cumulative TSN Ack Advertised Receiver Window Credit (a_rwnd) Number of Gap Ack Blocks = N Gap Ack Block #1 Start Number of Duplicate TSNs = X Gap Ack Block #1 End
Gap Ack Block #n Start
Gap Ack Block #n End Duplicate TSN 1
Duplicate TSN X
Type The Type field is set to 3. Chunk Flags The Chunk Flags field is set to all 0s. Cumulative TSN Ack The Cumulative TSN Ack field specifies the TSN of the last DATA chunk received in sequence before a gap. This field acknowledges that all TSNs equal to or greater than the value of this field have been received.
Advertised Receiver Window Credit (A_RWND) The A_RWND field specifies the updated maximum number of bytes allowed by the buffer of the transmit end of the SACK chunk.
Number of Gap Ack Blocks The Number of Gap Ack Blocks field specifies the number of Gap Ack Blocks in a SACK chunk. Gap Ack Blocks acknowledge TSNs received after a TSN not in a sequence is received. Each of the TSN acknowledged by a Gap Ack Block is greater than the value of Cumulative TSN Ack.
Number of Duplicate TSNs The Number of Duplicate TSNs field specifies the number of duplicate TSNs received. Each duplicate TSN is listed following the Gap Ack Block list.
Gap Ack Block The Gap Ack Blocks fields specify Gap Ack Blocks. These fields are repeated up to the value of Number of Gap Ack Blocks. If a DATA chunk has a TSN greater than or equal to the sum of the values of Cumulative TSN Ack and Gap Ack Block Start and less than or equal to the sum of values of Cumulative TSN Ack and Gap Ack Block End of each
Issue 01 (2011-09-30)
24
eRAN2.2 SCTP
Gap Ack Block, the DTAT chunk has been received correctly.
Gap Ack Block Start The Gap Ack Block Start field specifies the start offset TSN for this Gap Ack Block. The actual TSN is equal to the sum of the values of Cumulative TSN Ack and this field. The actual TSN identifies the first TSN received in the Gap Ack Block.
Gap Ack Block End The Gap Ack Block End field specifies the end offset TSN for this Gap Ack Block. The actual TSN is equal to the sum of the values of Cumulative TSN Ack and this field. The actual TSN identifies the last TSN received in the Gap Ack Block.
Duplicate TSN The Duplicate TSN field specifies the number of times a TSN is received after the last SACK chunk is sent. All duplicate TSNs received by a receive end before sending the SACK chunk are added to the list of duplicates. The duplicate counter is reset to zero after a SACK chunk is sent.
HeartBeat Request (HEARTBEAT) Chunk Format

The HEARTBEAT chunk is sent to check whether the destination transport address defined in an association is available. Figure 1.5 shows the HEARTBEAT chunk format. Figure 1.5 HEARTBEAT chunk 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 = 4 Chunk Flags HEARTBEAT Length
Heartbeat Information TLV (Variable-Length)
Type (8 bits) The Type field is set to 4. Chunk Flags (8 bits) The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end. HEARTBEAT Length The HEARTBEAT Length field specifies the length of a chunk in bytes, including the length of the chunk header and Heartbeat Information field.
HERATBEAT Information The HEARTBEAT Information field includes Heartbeat Information, which has a variable length and is in a half-transparent data structure. The value of the Heartbeat Information field must be identified by the transmit end. Figure 1.6 shows the Heartbeat Information field format.
Issue 01 (2011-09-30)
25
eRAN2.2 SCTP
Figure 1.6 Heartbeat Information field 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 Heartbeat Info Type=1 Sender-specific Heartbeat Info
HB Info Length
The Sender-specific Heartbeat Info field in a HEARTBEAT chunk includes the time when the transmit end transmits this chunk.
HeartBeat Request Acknowledgement (HEARTBEAT ACK) Chunk Format

A HEARTBEAT ACK chunk is sent as a response to a HEARTBEAT chunk. A HEARTBEAT ACK chunk responding to a HEARTBEAT chunk is sent to the source IP address in the IP packet that contains the HEARTBEAT chunk. Figure 1.7 shows the HEARTBEAT ACK chunk format. Figure 1.7 HEARTBEAT ACK chunk 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 = 5 Chunk Flags Heartbeat Ack Length
Heartbeat Information TLV (Variable-Length)
Type (8 bits) The Type field is set to 5. Chunk Flags (8 bits) The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end. HEARTBEAT ACK Length The HEARTBEAT Length field specifies the length of a chunk in bytes, including the length of the chunk header and Heartbeat Information field.
HERATBEAT Information The Heartbeat Information field has a variable length and is in a half-transparent data structure. This field must contain the Heartbeat information in the Heartbeat Request message.
ABORT Chunk Format

An ABORT chunk is sent to abort an association. Cause parameters in the ABORT chunk are to inform the receive end of abort reasons. DATA chunks cannot be in the same SCTP group with ABORT chunks. Control chunks, except for INIT, INIT ACK, and SHUTDOWN
eRAN2.2 SCTP
COMPLETE chunks, can be bundled with an ABORT chunk, but the Control chunks must be placed before the ABORT chunk in the SCTP packet. Otherwise, the receive end ignores these control chunks. An ABORT chunk with a format error or for an association that does not exist is discarded. If an endpoint receives an ABORT chunk, it cannot respond to the ABORT chunk by sending an ABORT chunk of its own. Figure 1.8 shows the ABORT chunk format. Figure 1.8 ABORT chunk 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 = 6 Reserved T Length
zero or more Error Causes
Type (8 bits) The Type field is set to 6. Chunk Flags (8 bits) The seven left-most bits are reserved. The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end. If the transmit end has a damaged TCB, the T bit is set to 0. If the transmit end does not have a TCB, the T bit must be set to 1.
Length (16 bits) The Length field specifies the size of an ABORT chunk in bytes, including the chunk header and all the Error Cause fields.
Zero or more Error Causes The information in an ABORT chunk is error causes.
SHUTDOWN Chunk Format

If an endpoint in an association needs to close the association, the SHUTDOWN chunk is used to gracefully close the association. Figure 1.9 shows the SHUTDOWN chunk format. Figure 1.9 SHUTDOWN chunk 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
Type The Type field is set to 7.
Issue 01 (2011-09-30)
27
eRAN2.2 SCTP
Chunk Flags (8 bits) The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end. Length The Length field specifies the size of a SHUTDOWN chunk. This field is set to 8. Cumulative TSN Ack The value of the Cumulative TSN Ack field includes the TSN of the last chunk received in sequence before any gaps. The SHUTDOWN message does not contain Gap Ack Blocks and therefore it cannot be used to acknowledge TSNs received out of order.
SHUTDOWN ACK Chunk Format

At an association is closed, a SHUTDOWN ACK chunk is used to acknowledge the receipt of a SHUTDOWN chunk. Figure 1.10 shows the SHUTDOWN ACK chunk format. Figure 1.10 SHUTDOWN ACK chunk 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 = 8 Chunk Flags Length=4
Chunk Flags The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end. A SHUTDOWN ACK chunk does not contain other parameters and therefore the Length field is set to 4.
ERROR Chunk Format

An ERROR chunk is used to notify the receive end of error conditions. An ERROR chunk contains one or more error causes. An operation error is not considered to be critical. A critical error is reported using an ABORT chunk. Figure 1.11 shows the ERROR chunk format. Figure 1.11 ERROR chunk 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 =9 Chunk Flags one or more Error Causes Length
Type (8 bits)
The Type field is set to 9.
The Chunk Flags field is set to all 0s on the transmit end and ignored by the receive end.
eRAN2.2 SCTP
Length (16 bits)
The Length field specifies the size of an ERROR chunk in bytes, including the chunk header and all the Error Cause fields.
Error causes
An error cause includes the cause code, cause length, and cause-specific information, as shown in Figure 1.12. Figure 1.12 Error cause 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 Cause Code Cause Length Cause-specific Information
The cause-specific information depends on the cause code. The mapping between the cause code and the cause-specific information is shown in Table 12.1. Table 12.1 Mapping between the cause-specific information and the cause code Cause Code Value 1 Cause Code and Meaning Invalid Stream Identifier: Indicates that the received DATA chunk contains a nonexistent stream. Parameter Information
Stream ID (16 bits): Includes the stream ID of the DATA chunk received in error. Reserved (16 bits) The Reserved field is set to all 0s on the transmit end and ignored by the receive end. Cause Length = 8
Missing mandatory parameters: Indicates that one or more mandatory parameters are missing in a received INIT or INIT ACK chunk.
Number of Missing parameters (32 bits): Indicates the number of parameters contained in the Cause-specific Information field. Missing Parameter Type (16 bits): Indicates the number of the missing mandatory parameter. Cause Length = 8 + N x 2
Stale Cookie Error: Indicates that a valid State Cookie chunk that is received has expired.
Measure of Staleness (32 bits): Contains the difference in microseconds between the current time and the time when the State Cookie chunk expires. The transmit end of this error cause can report the expiration duration of the State Cookie chunk by sending a non-zero value in the Measure of Staleness field. If the transmit end does not expect to provide this information, the Measure of Staleness field must be set to 0.
29
Issue 01 (2011-09-30)
eRAN2.2 SCTP
Cause Code Value
Cause Code and Meaning
Parameter Information
Cause Length = 8 4 Out of Resource: Indicates that the transmit end is out of resource. This field is sent with or within an ABORT chunk. Unresolvable Address: Indicates that the transmit end cannot resolve the specified address parameter. For example, the transmit end does not support the address type. This cause code is sent in combination with or within an ABORT chunk. Unrecognized Chunk Type: Returned to the originator of the chunk if the receive end cannot recognize the chunk type and the upper bits of the Chunk Type field are set to 01 or 11. Invalid mandatory parameter: Returned to the originator of an INIT or INIT ACK chunk when one of the mandatory parameters is set to an invalid value. Unrecognized parameters: Returned to the originator of the INIT ACK chunk if the receive end cannot recognize one or more Optional TLV parameters in an INIT ACK chunk. Cause Length = 4
Unresolvable Address (variable length) Contains the Type, Length and Value of the address parameter (or Host Name parameter) that contains the unresolvable address or host name. The cause length is variable.
Unrecognized Chunk (variable length): Contains the Chunk Type, Chunk Flags, and Chunk Length of the unrecognized chunk in an SCTP packet. The cause length is variable.
Cause Length = 4
Unrecognized Parameters(variable length): Contains the unrecognized parameters copied from an INIT ACK chunk. When the transmit end of the COOKIE ECHO chunk expects to report unrecognized parameters, this error cause is normally contained in an ERROR chunk bundled with the COOKIE ECHO chunk for responding to the INIT ACK chunk. The cause length is variable.
No User Data: Returned to the originator of a DATA chunk if the received DATA chunk does not have user data.
TSN: Contains the TSN of the received DATA chunk without user data. Cause Length = 8
Issue 01 (2011-09-30)
30
eRAN2.2 SCTP
Cause Code Value 10
Cause Code and Meaning Cookie Received While Shutting Down: Returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK chunk when a COOKIE ECHO chunk was received while the endpoint was in the SHUTDOWN-ACK-SENT state.
Parameter Information
Cause Length = 4
COOKIE ECHO Chunk Format

The COOKIE ECHO chunk is used only during association initiation. It is sent by the initiator of an association to its peer endpoint to complete the initiation. The COOKIE ECHO chunk must be sent within the association before any DATA chunk is sent, but may be bundled with one or more DATA chunks in the same packet. Figure 1.13 shows the COOKIE ECHO chunk format. Figure 1.13 COOKIE ECHO chunk 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 =10 Chunk Flags COOKIE Length
Type (8 bits)
The Type field is set to 10.
Length (16 bits)
The Length field is 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)
The Cookie field must contain the exact cookie received in the State Cookie field in the previous INIT ACK chunk. An implementation must make the cookie as small as possible to ensure interoperability.
Issue 01 (2011-09-30)
31
eRAN2.2 SCTP
COOKIE ACK Chunk Format

The COOKIE ACK chunk is used only during the association initiation. This chunk acknowledges the receipt of a COOKIE ECHO chunk. The COOKIE ACK chunk must be sent within the association before any DATA or SACK chunk is sent, but may be bundled with one or more DATA or SACK chunks in the same SCTP packet. As shown in Figure 1.14, the COOKIE ACK chunk does not contain any parameters. Figure 1.14 COOKIE ACK chunk 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 =11 Chunk Flags Length=4
SHUTDOWN COMPLETE Chunk Format

The SHUTDOWN COMPLETE chunk acknowledges the receipt of a SHUTDOWN ACK chunk at the completion of a shutdown process. As shown in Figure 1.15, the SHUTDOWN COMPLETE chunk does not have any fields. Figure 1.15 SHUTDOWN COMPLETE chunk 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 =14 Reserved T Length=4
Type (8 bits)
The seven left-most bits are reserved. The reserved bits are set to all 0s on the transmit end and ignored at the receive end.
T bit (1 bit)
The T bit is set to 0 if the transmit end has a damaged TCB. If the transmit end has no TCB, the T bit is set to 1.
Issue 01 (2011-09-30)
32
eRAN2.2 SCTP
5.3 SCTP Endpoint Maintenance Parameters and Recommended Values

Mandatory Parameters for Each SCTP Instance
Table 1.1 describes the mandatory parameters for each SCTP instance. Table 1.1 Mandatory parameters for each SCTP instance Paramete r Associations Secret Key Meaning Specifies a list of current associations and corresponding to the data consumers for each association. Specifies a secret key for the endpoint calculating the MAC. This parameter must set to a random cryptographic quality number with a sufficient length. For details about the selection of secret keys, see the RFC 4086. Specifies a list of IP addresses bound with an instance. The value of this parameter is transmitted to the peer endpoint in an INIT or INIT ACK chunk. Specifies a local SCTP port number to which the endpoint is bound.
Address List
SCTP Port
Mandatory Parameters for Each SCTP Association

Table 1.2 describes mandatory parameters for each SCTP association. Table 1.2 Mandatory parameters for each SCTP association Parameter Peer Verification Tag My Verification Tag Peer Transport Address List Meaning Specifies a tag value to be sent in each packet and be received in an INIT or INIT ACK chunk. Specifies a tag expected in every inbound packet and sent in an INIT or INIT ACK chunk. Specifies a list of SCTP transport addresses to which the peer endpoint is bound. The value of this parameter derives from the INIT or INIT ACK chunk and is used to associate an inbound packet with a given association. Specifies the current primary destination transport address of the peer endpoint and a source transport address on this endpoint. Specifies the number of errors in an overall association. Controls an association. If the Overall Error Count parameter reaches the value of this parameter, the association will be closed or aborted.
Primary Path Overall Error Count Overall Error Threshold

Issue 01 (2011-09-30)
eRAN2.2 SCTP
Parameter Peer RWND Nest TSN
Meaning Specifies the current calculated value for RWND of the peer endpoint. Specifies the next TSN to be assigned to a new DATA chunk. This parameter is sent in an INIT or INIT ACK chunk to the peer and incremented each time a DATA chunk is assigned a TSN (normally prior to transmit or during fragmentation). Specifies the last TSN received in sequence. This parameter is initially set to the initial TSN of the peer endpoint, and the value is subtracted 1 in the received an INIT or INIT ACK chunk. Specifies an array of bits or bytes indicating which out-of-order TSNs have been received (relative to the Last RCVD TSN). If no gaps exist, for example, no out-of-order packets have been received, this parameter is set to all 0s. Specifies whether a SACK chunk responds to the next received packet. The initial value is 0. Specifies an array of structures to track the inbound streams, normally including the next sequence number expected and the stream number. Specifies an array of structures to track the outbound streams, normally including the next sequence number to be sent on the stream. Specifies a reassembly queue. Specifies a list of local IP addresses bound with this association. Specifies the smallest PMTU discovered for all transport addresses of the peer endpoint.
Last RCVD TSN
Mapping Array
ACK State Inbound Streams Outbound Streams Reasm Queue Local Transport Address List Association PMTU
For a specific association, verification tags used by the two endpoints do not change during the association lifetime. After this association is released, an endpoint must use a new verification tag to set up a new association with the peer endpoint.
Mandatory Parameters for Each Transport Address

For each destination transport address in the peer endpoint's address list derived in an INIT or INIT ACK chunk, an endpoint needs to maintain the parameters listed in Table 1.3. Table 1.3 Mandatory parameters for each transport address Parameter Error Count Error Threshold Meaning Indicates the number of current errors for this destination transport address. Indicates the error threshold for this destination. When the number of errors reaches the value of this parameter, the association with this destination transport address stops.
Issue 01 (2011-09-30)
34
eRAN2.2 SCTP
Parameter CWND RTO SRTT RTTVAR Partial bytes acked State PMTU Per Destination Timer Last-time
Meaning Indicates the current congestion window. Indicates the current retransmission timeout value. Indicates the current smoothed round-trip time. Indicates the current RTT variation. Indicates the tracking method for CWND increase in congestion avoidance mode. Indicates the current state of this destination, such as OWN, UP, ALLOW-HEARTBEAT, and NO-HEARTBEAT. Indicates the current acknowledged path MTU. Indicates a timer used by each destination. Indicates the time when the last packet is sent to this destination. This parameter determines whether a HEARTBEAT chunk is to be sent.
General Parameters

Outbound queue: Indicates a queue of outbound DATA chunks. Inbound queue: Indicates a queue of inbound DATA chunks.
Recommended Values for SCTP Protocol Parameters

RTO.Initial: 3 seconds RTO.Min 1 second RTO.Max 60 seconds RTO Alpha: 1/8 RTO Beta: 1/4 Valid.Cookie.Life: 60 seconds Association.Max.Retrans: 10 attempts Path.Max.Retrans: 5 attempts Max.Init.Retransmits: 8 attempts HB.interval: 30 seconds
Issue 01 (2011-09-30)
35
eRAN2.2 SCTP
SCTP Basic Signaling Procedure
6.1 Association Setup

SCTP endpoint A sends an INIT chunk to SCTP endpoint B to set up an association with endpoint B. Then, endpoint B responds to endpoint A with two chunks. Assume that these chunks are not bound or fragmented. Figure 1.1 shows the signaling procedure. Figure 1.1 Signaling exchange for setting up an association
Endpoint A (1) INIT (2) INIT ACK (3) COOKIE ECHO (4) COOKIE ACK (5) DATA Endpoint B
(6) SACK (7) DATA
(8) DATA (9) SACK
1.
Endpoint A creates a TCB indicating an association is to be set up and sends an INIT chunk to endpoint B. An INIT chunk includes the following parameters:
Initiate Tag: Put in the Verification Tags field. For example, this parameter can be set
Issue 01 (2011-09-30)
eRAN2.2 SCTP
to Tag_A, ranging from 1 to 4294967295.

OS: Indicates the maximum number of outbound streams expected by the local endpoint. MIS: Indicates the maximum number of inbound streams allowed by the local endpoint.
After receiving the stream configuration from the peer endpoint, each endpoint must check information in each stream. If the MIS of the peer is less than the OS of the local endpoint, the peer endpoint cannot support the outbound streams expected by the local endpoint, the local endpoint must use the MIS as the outbound streams of the local endpoint and may report any resource shortage to the upper layer. If the upper layer cannot accept the resource shortage, it may abort the association.
After sending an INIT chunk, endpoint A starts an INIT timer and enters the COOKIE-WAIT state.
The INIT timer is used for waiting an INIT ACK chunk from the peer endpoint. If no INIT chunk is received before the timer expires, the local endpoint resends an INIT chunk until the number of INIT chunks reaches the value of Max.Init.Retransmits.
2.
Upon the receipt of the INIT chunk, endpoint B immediately responds with an INIT ACK chunk. The INIT ACK chunk must contain the following parameters:

Destination IP address: Set to the source IP address of the INIT chunk. Initiate Tag: Set to Tag_B. STATE COOKIE: A temporary TCB is generated based on the basic association information. After the TCB is generated, a 32-bit MAC is generated using a secret key of the local endpoint and the necessary information based on an irreversible algorithm described in RFC2401. Necessary information includes a timer stamp for generating a COOKIE and the COKKIE life-span. The STATE COOKIE parameter is generated based on the necessary information and the MAC. Transport address of the local endpoint MIS OS
3.
After receiving the INIT ACK chunk, endpoint A stops the INIT timer, exits the COOKIE-WAIT state, and sends a COOKIE ECHO chunk. The COOKIE ECHO chunk includes the STATE COOKIE parameter in the INIT ACK chunk. Then, endpoint A starts the COOKIE timer and enters the COOKIE-ECHOED state.
The COOKIE ECHO chunk can be bound in the same SCTP packet with a DATA chunk, but the COOKIE ECHO chunk must be the first DATA chunk in the SCTP packet. The transmit endpoint transmits other packets to the peer endpoint only after receiving a COOKIE ACK chunk. 4. After receiving the COOKIE ECHO chunk, endpoint B checks it. Endpoint B calculates the MAC using the MAC algorithm described in RFC2401 based on the TCB in STATE COOKIE and the secret key, and compares the calculated MAC with the MAC carried by the STATE COOKIE parameter. If they are different, endpoint B discards the message. If they are the same, endpoint B compares the time stamp when the TCB is
Issue 01 (2011-09-30)
eRAN2.2 SCTP
generated with the current time to check whether the time stamp exceeds the COOKIE life-span. If the time stamp exceeds the COOKIE life-span, the message is discarded. If the time stamp is within the COOKIE life-span, endpoint B sets up an association with endpoint A based on the information in a TCB. Endpoint B enters the ESTABLISHED state and sends a COOKIE ACK chunk. Endpoint B sends the SCOMMUNCIATION UP message to an SCTP user.
The COOKIE ACK chunk can be bound in the same SCTP packet with a DATA chunk, but the COOKIE ACK chunk must be the first DATA chunk in the SCTP packet. After receiving a COOKIE ACK chunk, endpoint A enters the ESTAABLISHED state from the COOKIE-ECHOED state and stops the COOKIE timer. Endpoint A sends the COMMUNICATION UP message to inform SCTP users of a successful association setup.
An association is set up using a four-way startup handshake, including: INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK.
5.
Endpoint A sends a DATA chunk to endpoint B and starts the T3-RTS timer. The DATA chunk must contain the following parameters:

TSN: Indicates the initial TSN in a DATA chunk. Stream Identifier: Identifies the stream to which user data belongs. For example, 0. Stream Sequence Number: Specifies the transmission sequence number of user data in a stream. The value ranges from 0 to 65535. User Data: Carries user payload.
6.
After receiving the DATA chunk, endpoint B sends a SACK chunk. The SACK chunk must contain the following parameters:

Cumulative TSN Ack: Specifies the initial TSN of endpoint A. Gap Ack Block: Set to 0.
After receiving a SACK chunk, endpoint A stops the T3-RTX timer. 7. Endpoint B sends the first DATA chunk to endpoint A. The DATA chunk must contain the following parameters:

TSN: Indicates the initial TSN of endpoint B. Stream Identifier: Identifies the stream to which user data belongs. For example, 0. Stream Sequence Number: Specifies the transmission sequence number of user data in a stream. For example, 0. User Data: Carries user payload.
8.
Endpoint B sends the second DATA chunk to endpoint A. The DATA chunk must contain the following parameters:

TSN: Indicates the initial TSN + 1 of endpoint B. Stream Identifier: Identifies the stream to which user data belongs. For example, 0. Stream Sequence Number: Specifies the transmission sequence number of user data in a stream. For example, 1. User Data: Carries user payload.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
9.
After receiving the DATA chunk, endpoint B sends a SACK chunk. The SACK chunk must contain the following parameters:

Cumulative TSN Ack: Specifies the initial TSN of endpoint B. Gap Ack Block: Set to 0.
6.2 Association Termination

If an endpoint exits from services, it must terminate its association. An association can be terminated by abort (graceful) or shutdown (ungraceful). Association abort can be performed in any time with data discarded on both endpoints and not delivered to the peer endpoint. This method cannot ensure data safety. The procedure for association abort is simple, as described in the following: An endpoint who decides to abort an existing association sends an ABORT chunk to its peer endpoint. The endpoint must fill in the peers verification tag in the outbound packet and must not bundle any DATA chunk with this ABORT chunk. After checking the Verification Tag field, the receive endpoint releases the association from its record and reports the termination to its upper layer. Graceful association shutdown: When an endpoint gracefully shuts down an association, the two endpoints cannot accept new data from SCTP users, but can submit data in the transmitted or received SHUTDOWN chunk to SCTP users. Association shutdown ensures that all data is sent to the peer endpoint and all outstanding data is acknowledged before an association is shut down. Figure 1.1 Signaling exchange for association shutdown
Endpoint A (1) SHUTDOWN (2) SHUTDOWN ACK (3) SHUTDOWN COMPLETE Endpoint B
The procedure for shutting down an association is as follows: 1. Endpoint A sends a SHUTDOWN chunk to endpoint B. Upon the reception of the SHUTDOWN chunk, endpoint B enters the SHUTDOWN-PENDING state from the ESTABLISHED state. In the SHUTDOWN-PENDING state, endpoint B does not accept any new data from its SCTP users. At the same time, endpoint B waits for endpoint A to verify all outstanding data that has been received by endpoint A. After endpoint A verifies all outstanding data, it sends a SHUTDOWN chunk to endpoint B. Endpoint A starts the T2-shutdown timer and enters the SHUTDOWN-SENT state. The SHUTDOWN-SENT timer is started waiting endpoint B to sends a SHUTDOWN-ACK chunk. If no SHUTDOWN-ACK chunk is received before the timer expires, endpoint A resends a SHUTDOWN chunk. After receiving the SHUTDOWN chunk, endpoint B enters the SHOUTDOWNRECEIVED state indicating that it does not receive new data from its SCTP users, and check the Cumulative TSN ACK field in the SHUTDOWN chunk to verify that all outstanding data has been acknowledged by the transmit end of the SHUTDOWN chunk. After verifying that data has been sent and all outstanding data has been acknowledged,
2.
Issue 01 (2011-09-30)
eRAN2.2 SCTP
endpoint B sends a SHUTDOWN ACK chunk and starts the T2-SHUTDOWN timer, entering the SHUTDOWN-ACK-SENT state. If endpoint A does not receive the SHUTDOWN ACK chunk before the T2-SHUTDOWN timer expires, endpoint B resends a SHUTDOWN ACK chunk. 3. After receiving the SHUTDOWN ACK, endpoint A stops the T2-shutdown timer, sends a SHUTDOWN COMPLETE chunk to endpoint B, and removes all data about the association. After receiving the SHUTDOWN COMPLETE chunk, endpoint B checks whether it is in the SHUTDOWN-ACK-SENT state. If endpoint B is not in the SHUTDOWN-ACK-SENT state, it discards the SHUTDOWN COMPLETE chunk. If it is in the SHUTDOWN-ACK-SENT state, it stops the T2-shutdown timer, removes all data about the association, and enters the CLOSED state.
Issue 01 (2011-09-30)
40

2 - SCTP

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2 - SCTP

Загружено:

Авторское право:

Доступные форматы

Doc.

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

About This Document

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure..................................................36

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

A host can have multiple endpoints.

Association and Stream

6 SCTP Basic Signaling Procedure

Path and Primary Path

TSN and SSN

Transmission sequence number (TSN)

6 SCTP Basic Signaling Procedure

Stream sequence number (SSN)

Congestion Window (CWND)

Receive Window (RWND)

Transmission Control Block (TCB)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

3.1 Association Setup and Shutdown

6 SCTP Basic Signaling Procedure

3.2 Sequenced Delivery Within Streams

3.3 User Data Fragmentation

3.4 Acknowledgement and Congestion Avoidance

6 SCTP Basic Signaling Procedure

Packet retransmission is used to acknowledge the TSN and congestion avoidance.

3.5 Chunk Bundling

3.6 Packet Validation

3.7 Path Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Name RECEIVE UNACKNOW LEDGED MESSAGE DESTROY

4.2 Notification Primitive Sent from an SCTP Protocol to an SCTP User

NETWORK STATUS CHANGE

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Name COMMUNCIA TION UP

COMMUNICA TION LOST

COMMUNICA TION ERROR

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Figure 1.1 shows the structure of an SCTP packet.

Destination Port Number

Chunk Length Chunk #1

Chunk #n Chunk Value

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

6 SCTP Basic Signaling Procedure

Format of a Common Header

Source port No. (16 bits)