SCTP Programmer`s Guide

SCTP Programmer`s Guide
SCTP Programmer's Guide
HP-UX 11i v2, HP-UX 11i v3
HP Part Number: 5992-4578
Published: April 2008
Edition: 1
© Copyright 2007–2008 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and
12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set
forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
UNIX is a registered trademark of The Open Group.
Table of Contents
About This Document...................................................................................................................13
Intended Audience.............................................................................................................13
Document Organization.....................................................................................................13
Typographical Conventions................................................................................................13
Related Information............................................................................................................14
HP Encourages Your Comments........................................................................................15
1 Introduction..............................................................................................................................17
SCTP Overview...................................................................................................................17
Limitations of TCP and UDP..............................................................................................18
Limitations of TCP........................................................................................................18
Limitations of UDP........................................................................................................19
SCTP Architecture..............................................................................................................19
SCTP in the IP Stack......................................................................................................20
Connection Setup in SCTP............................................................................................21
SCTP Packet...................................................................................................................23
Congestion Control in SCTP.........................................................................................26
Slow Start and Congestion Avoidance Algorithms.................................................26
Fast Retransmit and Fast Recovery..........................................................................27
SCTP Features.....................................................................................................................27
Multihoming..................................................................................................................28
Multistreaming..............................................................................................................30
Conservation of Data Boundaries.................................................................................31
SCTP Graceful Shutdown Feature................................................................................31
SCTP Support for IPv4 and IPv6 Addresses.................................................................32
SCTP Data Exchange Features......................................................................................32
Support for Dynamic Address Reconfiguration ..........................................................33
Reporting Packet Drops to an Endpoint.......................................................................33
Support for ECN-Nonces in SCTP................................................................................34
SCTP Support for Partially Reliable Data Transmission...............................................35
Error Handling in SCTP.....................................................................................................37
Retransmission of DATA Chunks.................................................................................37
HEARTBEATs to Identify Path Failures........................................................................38
HEARTBEATs to Identify Endpoint Failure.................................................................38
SCTP Security.....................................................................................................................38
Cookie Mechanism........................................................................................................38
Verification Tag..............................................................................................................39
2 SCTP Socket APIs......................................................................................................................41
Table of Contents
3
Overview............................................................................................................................41
Socket API Versus SCTP Socket API..................................................................................41
Different Socket API Styles.................................................................................................42
One-to-One Socket APIs................................................................................................42
Basic One-to-One Call Flow Sequence..........................................................................43
The socket() Socket API............................................................................................43
The bind() Socket API..............................................................................................44
The listen() Socket API.............................................................................................45
The accept() Socket API...........................................................................................45
The connect() Socket API.........................................................................................45
The close() Socket API..............................................................................................46
The shutdown() Socket API.....................................................................................46
The sendmsg() and recvmsg() Socket APIs.............................................................47
The getpeername() Socket API.................................................................................48
One-to-Many Socket APIs.............................................................................................48
Basic One-to-Many Call Flow Sequence.......................................................................48
The socket() Socket API ......................................................................................49
The bind() Socket API..............................................................................................50
The listen() Socket API.............................................................................................51
The sendmsg() and recvmsg() Socket APIs.............................................................51
The close() Socket API..............................................................................................52
The connect() Socket API.........................................................................................52
API Options to Modify Socket Behavior............................................................................52
Common Socket Calls.........................................................................................................54
The send(), sendto(), recv(), and recvfrom() Socket Calls.............................................55
The setsocktopt() and getsockopt() Socket Calls...........................................................56
The read() and write() Socket Calls...............................................................................56
The getsockname() Socket Call......................................................................................57
SCTP Events and Notifications...........................................................................................57
SCTP Ancillary Data Structures.........................................................................................58
SCTP Initiation Structure (SCTP_INIT)........................................................................59
SCTP Header Information (SCTP_SNDRCV)...............................................................59
SCTP-Specific Socket APIs..................................................................................................61
The sctp_bindx() SCTP Socket API...............................................................................61
The sctp_peeloff() SCTP Socket API.............................................................................62
The sctp_getpaddrs() SCTP Socket API........................................................................62
The sctp_freepaddrs() SCTP Socket API.......................................................................63
The sctp_getladdrs() SCTP Socket API.........................................................................63
The sctp_freeladdrs() SCTP Socket API........................................................................64
The sctp_sendmsg() SCTP Socket API..........................................................................64
The sctp_recvmsg() SCTP Socket API...........................................................................65
The sctp_connectx() SCTP Socket API..........................................................................65
The sctp_send() SCTP Socket API.................................................................................66
The sctp_sendx() SCTP Socket API...............................................................................66
4
Table of Contents
3 Compiling and Running Applications that Use the SCTP Socket APIs..............................................69
Compiling Applications that Use the SCTP APIs..............................................................69
Running Sample Applications that use the SCTP APIs.....................................................70
4 Migrating TCP Applications to SCTP...........................................................................................73
A SCTP Sample Programs.............................................................................................................75
Sample Server Programs.....................................................................................................75
One-to-One Server Program..........................................................................................75
One-to-Many Server Program.......................................................................................77
Sample Client Programs.....................................................................................................80
One-to-One Client Program..........................................................................................80
One-to-Many Client Program.......................................................................................82
Glossary.....................................................................................................................................85
Index..........................................................................................................................................87
Table of Contents
5
6
List of Figures
1-1
1-2
1-3
1-4
1-5
1-6
1-7
1-8
The Internet Protocol Stack.........................................................................................20
Three-Way Handshake in TCP....................................................................................21
Four-Way Handshake in SCTP...................................................................................22
SCTP Packet Format....................................................................................................23
A Single-Homed Connection......................................................................................29
A Multihomed Connection.........................................................................................29
Multistreaming in an SCTP Association.....................................................................31
Shutdown in TCP and SCTP.......................................................................................32
7
8
List of Tables
1-1
1-2
2-1
Chunk Types...............................................................................................................24
Comparison Between SCTP, TCP, and UDP...............................................................27
Data Structures in the recvmsg() and sendmsg() Calls........................................60
9
10
List of Examples
3-1
3-2
3-3
Sample Commands to Compile the Server and Client Programs...............................70
Sample Command to Run the Server Application......................................................70
Sample Command to Run the Client Application......................................................71
11
12
About This Document
This document describes how to write, compile, and run applications using Stream
Control Transmission Protocol (SCTP) socket APIs on systems running the HP-UX 11i
v2 and HP-UX 11i v3 operating systems. HP's implementation of SCTP conforms to
the RFCs and RFC drafts listed in “Related Information” (page 14).
The document printing date and part number indicate the document’s current edition.
The printing date will change when a new edition is printed. Minor changes may be
made at reprint without changing the printing date. The document part number will
change when extensive changes are made.
The latest version of the document will be available at: http://www.docs.hp.com
Document updates can be issued between editions to correct errors or document product
changes. To ensure that you receive the updated or new edition, subscribe to the
appropriate support service.
Contact your HP sales representative for details.
Intended Audience
This document is intended for application developers who write programs using SCTP
socket APIs. Application developers are expected to be familiar with SCTP, C, UNIX®,
TCP, UDP, networking concepts, and operating system concepts. Application developers
are recommended to read the relevant SCTP RFCs for detailed information on SCTP.
This document is not a tutorial.
Document Organization
The SCTP Programmer's Guide is organized as follows:
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 1 (page 17) introduces the SCTP protocol. It also discusses the
SCTP protocol architecture, the message format, congestion control,
fault management, SCTP security, and error handling.
Chapter 2 (page 41) describes the different socket API styles, SCTP
events and notifications, common socket options, common socket calls,
SCTP ancillary data structures, and the new SCTP-specific socket APIs.
Chapter 3 (page 69) describes how to compile and run applications
that use the SCTP APIs.
Chapter 4 (page 73) describes how to migrate existing TCP applications
to SCTP. It also discusses the benefits of migrating TCP applications to
SCTP.
Typographical Conventions
This document uses the following typographical conventions:
Intended Audience
13
audit(5)
Book Title
KeyCap
Emphasis
Emphasis
Term
ComputerOut
UserInput
Command
Variable
[]
{}
...
|
An HP-UX manpage. The name of the manpage is audit and 5 is the
section in the HP-UX Reference. On the web and on the Instant
Information CD, it may be a link to the manpage itself. From the
HP-UX command line, you can enter “man audit” or “man 5
audit” to view the manpage. See man(1).
The title of a book. On the web and on the Instant Information CD,
it may be a link to the book itself.
The name of a keyboard key. Note that Return and Enter both refer
to the same key.
Text that is emphasized.
Text that is strongly emphasized.
The defined use of an important word or phrase.
Text displayed by the computer.
Commands and other text that you type.
A command name or qualified command phrase.
The name of a variable that you may replace in a command or
function or information in a display that represents several possible
values.
The contents are optional in formats and command descriptions.
The contents are required in formats and command descriptions. If
the contents are a list separated by , you must choose one of the
items
The preceding element may be repeated an arbitrary number of
times.
Separates items in a list of choices.
Related Information
The following related documents are available for the SCTP product:
•
SCTP Administrator's Guide at:
http://docs.hp.com/en/netcom.html
•
SCTP Release Notes at:
http://docs.hp.com/en/netcom.html
•
Request for Comments (RFC) documents:
— RFC 2960 (Stream Control Transmission Protocol) at:
http://www.ietf.org/rfc/rfc2960.txt?number=2960
— RFC 3286 (An Introduction to the Stream Control Transmission Protocol (SCTP))
at:
http://www.ietf.org/rfc/rfc3286.txt?number=3286
14
— RFC 3873 (Stream Control Transmission Protocol (SCTP) Management Information
Base (MIB)) at:
http://www.ietf.org/rfc/rfc3873.txt?number=3873
— RFC 3309 (Stream Control Transmission Protocol (SCTP) Checksum Change) at:
http://www.ietf.org/rfc/rfc3309.txt?number=3309
— RFC 3758 (Stream Control Transmission Protocol (SCTP) Partial Reliability Extension)
at:
http://www.ietf.org/rfc/rfc3758.txt?number=3758
— RFC 4460 (Stream Control Transmission Protocol (SCTP) Specification Errata and
Issues) at:
http://www.ietf.org/rfc/rfc4460.txt?number=4460
•
Draft RFCs:
— draft-ietf-tsvwg-sctpsocket-10.txt at:
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-sctpsocket/draft-ietf-tsvwg-sctpsocket-10.txt
— draft-ietf-tsvwg-addip-sctp-10.txt (Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration) at:
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-addip-sctp/draft-ietf-tsvwg-addip-sctp-10.txt
— draft-stewart-sctp-pktdrprep-02.txt (Stream Control Transmission Protocol (SCTP)
Packet Drop Reporting) at:
http://tools.ietf.org/html/draft-stewart-sctp-pktdrprep-02
— draft-ladha-sctp-nonce-01.txt (ECN Nonces for Stream Control Transmission
Protocol (SCTP)) at:
http://tools.ietf.org/html/draft-ladha-sctp-nonce-05
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to
providing documentation that meets your needs. Send any errors found, suggestions
for improvement, or compliments to:
[email protected]
Include the document title, manufacturing part number, and any comment, error found,
or suggestion for improvement you have concerning this document.
HP Encourages Your Comments
15
16
1 Introduction
This chapter introduces Stream Control Transmission Protocol (SCTP). It also discusses
the SCTP architecture, the features that SCTP supports, the security features that SCTP
offers, and error handling.
This chapter addresses the following topics:
•
•
•
•
•
•
“SCTP Overview” (page 17)
“Limitations of TCP and UDP” (page 18)
“SCTP Architecture” (page 19)
“SCTP Features” (page 27)
“Error Handling in SCTP” (page 37)
“SCTP Security” (page 38)
SCTP Overview
SCTP is a connection-oriented transport layer protocol that enables reliable transfer of
data over IP-based networks. In an IP stack, it exists at a level equivalent to that of
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). SCTP offers
all the features that are supported by TCP and UDP. It also overcomes certain limitations
in TCP and adopts the beneficial features of UDP.
SCTP offers the following features:
• Network-level fault tolerance through support for multihoming
• Minimized delay in data delivery by sending data in multiple streams
• Acknowledged, error-free non-duplicated transfer of data
• Data fragmentation to conform to discovered maximum transmission unit (MTU)
size
• Sequenced delivery of user messages within multiple streams
• Optional bundling of multiple user messages into an SCTP packet
• Improved SYN-flood protection
• Preservation of message boundaries
SCTP also includes mechanisms, such as checksums, sequence numbers, and selective
retransmission of data, to detect data corruption, loss of data, and duplication of data.
In addition, it contains different congestion control algorithms to minimize data loss
in an unstable network. SCTP supports improved error handling methods to avoid
unnecessary retransmission of data. The security methods implemented in SCTP enable
the endpoints of an association to avoid SYN-flooding, and to identify stale or unwanted
data packets.
Initially, the features of SCTP were designed to transport telephone signaling messages
over IP networks. Other applications that require similar features can also use SCTP.
SCTP Overview
17
NOTE: In SCTP, the term “stream” refers to a sequence of user messages that are
delivered in sequence, with respect to other messages within the same stream. In TCP,
“stream” refers to a sequence of bytes.
HP's implementation of SCTP conforms to the following RFCs and draft RFCs:
•
•
•
•
•
•
•
•
•
RFC 3286 (An Introduction to the Stream Control Transmission Protocol (SCTP))
RFC 2960 (Stream Control Transmission Protocol)
RFC 3873 (Stream Control Transmission Protocol (SCTP) Management Information Base
(MIB))
RFC 4460 (Stream Control Transmission Protocol (SCTP) Specification Errata and Issues)
RFC 3309 (Stream Control Transmission Protocol (SCTP) Checksum Change)
RFC 3758 (Stream Control Transmission Protocol (SCTP) Partial Reliability Extension)
draft-ladha-sctp-nonce-01.txt (ECN Nonces for Stream Control Transmission Protocol
(SCTP))
draft-ietf-tsvwg-addip-sctp-10.txt (Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration)
draft-stewart-sctp-pktdrprep-02.txt (Stream Control Transmission Protocol (SCTP)
Packet Drop Reporting)
•
Limitations of TCP and UDP
TCP and UDP are the most widely used network layer protocols. However, the data
transfer services offered by these protocols are inadequate to meet the requirements
of a wide range of commercial applications, such as real-time multimedia and
telecommunication applications. These applications require a robust protocol, which
provides the flexibility of UDP and reliability of TCP, for transferring data between
two endpoints.
This section discusses the limitations of the TCP and UDP protocols, which led to the
development of SCTP.
This section addresses the following topics:
•
•
“Limitations of TCP” (page 18)
“Limitations of UDP” (page 19)
Limitations of TCP
Following are the limitations of TCP:
•
18
TCP provides reliable data transfer, but it transmits data in a sequence. However,
some applications may need reliable data transfer, though not necessarily in a
strict sequence. These applications prefer partial ordering of data, wherein ordering
is maintained only within subflows of data. The strict sequence maintenance in
Introduction
•
•
•
TCP not only makes partial ordering of data impossible, it also causes unnecessary
delay in the overall data delivery. Moreover, if a single packet is lost, delivery of
subsequent packets is blocked until the lost TCP packet is delivered. This causes
head-of-line (HOL) blocking.
TCP transmits data in a stream. This requires that applications add their own
record marking, to delineate their messages. Applications must use the PUSH flag
in the TCP header, to ensure that a complete message is transferred in reasonable
time.
In a TCP connection, each host includes a single network interface, and a connection
is established between the network interfaces of the two hosts. As a result, if the
connection breaks because of a path failure, data becomes unavailable until the
connection is re-established.
TCP is vulnerable to denial of service (DoS) attacks, such as SYN flood attacks. A
DoS occurs when a malicious host forges an IP packet with a fake IP address and
sends a large number of TCP SYN messages to the victim host. Each time the TCP
stack, on the victim host, receives a new SYN message, the TCP stack allocates
kernel resources to service the new SYN message. When the TCP stack is flooded
with multiple SYN messages, the victim host can run out of resources and fail to
service the new legitimate SYN messages.
Limitations of UDP
Following are the limitations of UDP:
•
•
•
In UDP, the transfer of data is unreliable, because it is a connectionless protocol.
In a UDP connection, an application cannot verify if the packet has reached the
destination.
UDP does not contain an in-built congestion control mechanism to detect path
congestion. As a result, more data may be injected into an already congested
network. This results in data loss.
If stringent rules for reliable data transfer are implemented in applications that
use UDP, the implementation causes additional overhead and complexity in the
applications.
SCTP Architecture
SCTP is designed to address the shortcomings in TCP. It uses mechanisms, such as
four-way handshake to prevent DoS attacks. The SCTP architecture defines packet
format that contains additional fields, such as cookie and verification tag, to avoid SYN
flooding. The SCTP architecture includes improved congestion control algorithms that
are effective in controlling congestion in unstable networks.
This section addresses the following topics:
•
•
“SCTP in the IP Stack” (page 20)
“Connection Setup in SCTP” (page 21)
SCTP Architecture
19
•
•
“SCTP Packet” (page 23)
“Congestion Control in SCTP” (page 26)
SCTP in the IP Stack
Figure 1-1 illustrates a typical IP stack and denotes the layer in which SCTP is located.
Figure 1-1 The Internet Protocol Stack
An Internet protocol stack contains several layers and each layer provides a specific
functionality. Following are the layers in an IP stack and their functionalities:
•
•
•
•
20
The physical layer defines the physical means of sending data over network devices.
The data link layer transfers data between network entities, and detects and corrects
errors that can occur in the physical layer.
The network layer routes data packets from the sender to the receiver in the
network. The most common network layer protocol is IP.
The transport layer enables transfer of data between endpoints using the services
of the network layer. This layer has two primary protocols, the Transmission
Introduction
•
•
Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP supports
reliable and sequential packet delivery through error recovery and flow control
mechanisms. UDP is a simple message-based connectionless protocol compared
to TCP. SCTP is yet another transport layer protocol that application developers
can use to transmit data between endpoints.
The socket layer provides the transport layer with an interface to interact with the
application layer. The socket layer contains a set of APIs, which facilitate the
transport layer to interface with the application layer.
The application layer provides application programs with an interface to
communicate and transfer data across the network. All application layer protocols
use the sockets layer as their interface, to interact with the transport layer protocol.
Connection Setup in SCTP
This section discusses the connection setup between two endpoints in TCP and SCTP.
It also discusses how the connection setup in SCTP prevents the DoS attack.
Both TCP and SCTP initiate a new connection with a packet handshake. TCP uses a
three-way handshake to set up a new connection, whereas SCTP uses a four-way
handshake to set up a new connection.
Figure 1-2 illustrates the three-way handshake in TCP.
Figure 1-2 Three-Way Handshake in TCP
The following steps describe the three-way handshake in TCP:
SCTP Architecture
21
1.
2.
3.
Host A sends a Synchronize (SYN) packet to Host B.
Upon receiving the SYN packet, Host B allocates resources for the connection and
sends a Synchronize-Acknowledge (SYN-ACK) packet to Host A.
Host A sends an ACK packet to confirm the receipt of the SYN-ACK packet.
The connection is set up between Host A and Host B, and Host A can now start
sending data to Host B.
Figure 1-3 illustrates the four-way handshake in SCTP.
Figure 1-3 Four-Way Handshake in SCTP
The following steps describe the four-way handshake in SCTP:
1.
2.
Host A initiates an association by sending an INIT packet to Host B.
Host B responds with an INIT-ACK packet that contains the following fields:
• A Verification tag
• A Cookie
The TCP SYN-ACK packet does not contain these fields. The cookie contains the
necessary state information, which the server uses to allocate resources for the
association. The cookie field includes a signature for authenticity and a timestamp
to prevent replay attacks using old cookies. Unlike TCP, Host B in SCTP does not
allocate resources at this point in the connection. The verification tag provides a
key that enables Host A to verify that the SCTP packet belongs to the current
association.
3.
22
Host A sends the COOKIE-ECHO packet to Host B. If Host A has a forged IP address,
it never receives the INIT-ACK chunk. This prevents Host A from sending the
Introduction
4.
COOKIE-ECHO packet. As a result, the conversation ends without the server
allocating any resources for the connection.
Host B responds with a COOKIE-ACK chunk and allocates resources for the
connection.
The connection is now established between Host A and Host B. Host A can now
start sending data to Host B.
In SCTP, the transfer of data may be delayed because of the additional handshake. The
four-way handshake may seem to be less efficient than a three-way handshake. To
overcome this delay, SCTP permits data to be exchanged in the COOKIE-ECHO and
COOKIE-ACK chunks.
SCTP Packet
SCTP transmits data in the form of messages and each message contains one or more
packets.
Figure 1-4 illustrates an SCTP packet format.
Figure 1-4 SCTP Packet Format
SCTP Architecture
23
An SCTP packet contains a common header, and one or more chunks. The SCTP
common header contains the following information:
•
•
•
Source and destination port numbers to enable multiplexing of different SCTP
associations at the same address.
A 32-bit verification tag that guards against the insertion of an out-of-date or false
message into the SCTP association.
A 32-bit checksum for error detection. The checksum can be either a
32-bit CRC checksum or Adler-32 checksum.
A chunk can be either a control chunk or a DATA chunk. A control chunk incorporates
different flags and parameters, depending on the chunk type. The DATA chunk
incorporates flags to control segmentation and reassembly, and parameters for the
transmission sequence number (TSN), Stream Identifier (SID) and Stream Sequence Number
(SSN), and a Payload Protocol ID. The DATA chunk contains the actual data payload.
Each control and data chunk in the SCTP packet contains the following information:
Chunk Type
This field identifies the type of information contained in the Chunk
Data field. The value of the chunk field ranges from 0 to 254. The
value 255 is reserved for future use, as an extension field. SCTP
consists of one DATA chunk and 12 control chunks.
Table 1-1 lists the definitions and parameters of the different chunk
types.
Table 1-1 Chunk Types
24
Introduction
Chunk
Definition
Payload Data (DATA)
Used for data transfer.
Initiation (INIT)
Initiates an SCTP association between two
endpoints.
Initiation Acknowledgement (
INIT ACK)
Acknowledges the receipt of an INIT chunk.
The receipt of the INIT ACK chunk establishes
an association.
Selective Acknowledgement
(SACK)
Acknowledges the receipt of the DATA chunks
and also reports gaps in the data.
Cookie Echo (COOKIE ECHO)
Used during the initiation process. The
endpoint initiating the association sends the
COOKIE ECHO chunk to the peer endpoint.
Cookie Acknowledgement
(COOKIE ACK)
Acknowledges the receipt of the COOKIE
ECHO chunk. The COOKIE ACK chunk must
take precedence over any DATA chunk or SACK
chunk sent in the association. The COOKIE
ACK chunk can be bundled with DATA chunks
or SACK chunks
Table 1-1 Chunk Types (continued)
Chunk
Definition
Heartbeat Request (
HEARTBEAT)
Tests the connectivity of a specific destination
address in the association.
Heartbeat Acknowledgement ( Acknowledges the receipt of the HEARTBEAT
HEARTBEAT ACK)
chunk.
Chunk Flag
Chunk Length
Chunk Data
Abort Association (ABORT)
Informs the peer endpoint to close the
association. The ABORT chunk also informs the
receiver of the reason for aborting the
association.
Operation Error (ERROR)
Reports error conditions. The ERROR chunk
contains parameters that determine the type
of error.
Shutdown Association (
SHUTDOWN)
Triggers a graceful shutdown of an association
with a peer endpoint.
Shutdown Acknowledgement
(SHUTDOWN ACK)
Acknowledges the receipt of the SHUTDOWN
chunk at the end of the shutdown process.
Shutdown Complete (
SHUTDOWN COMPLETE)
Concludes the shutdown procedure.
This field contains the flags, such as U (unordered bit), B (beginning
fragment bit), and E (ending fragment bit). Usage of this field
depends on the chunk type specified in the chunk type field. Unless
otherwise specified, SCTP sets this field to 0 while transmitting the
packet and ignores the chunk flag on receipt of the packet.
This field represents the size of the fields chunk type, chunk flag,
chunk length, and chunk value, in bytes.
This field contains the actual information to be transferred in the
chunk. The usage and format of this field depends on the chunk
type.
The number of chunks in an SCTP packet is determined by the MTU size of the
transmission path. Multiple chunks can be bundled into one SCTP packet except the
INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. The SCTP packet size must not
be more than the MTU size.
The SCTP packet format supports bundling of multiple DATA and control chunks into
a single packet, to improve transport efficiency. An application can control bundling,
to avoid bundling during initial transmission. Bundling occurs on retransmission of
DATA chunks, to reduce the possibility of congestion. If the user data does not fit into
one packet, SCTP fragments data into multiple chunks.
For more information on the SCTP packet format, see RFC 2960 (Stream Control
Transmission Protocol).
SCTP Architecture
25
Congestion Control in SCTP
SCTP uses various congestion control algorithms to effectively handle network failures
or unexpected traffic surges, and ensures quick recovery from data congestion. SCTP
and TCP support the same set of congestion control algorithms. Following are the
congestion control algorithm supported by SCTP:
•
•
Slow Start and Congestion Control
Fast Retransmit and Fast Recovery
However, in SCTP, the congestion control algorithms are modified to suite the
protocol-specific requirements.
For information on the TCP congestion control algorithms, see RFC 2581 (TCP Congestion
Control).
This section addresses the following topics:
•
•
“Slow Start and Congestion Avoidance Algorithms”
“Fast Retransmit and Fast Recovery”
Slow Start and Congestion Avoidance Algorithms
The slow start and congestion avoidance algorithms are used to control the amount of
outstanding data being injected into the network. SCTP uses the slow start algorithm
at the beginning of the transmission, when the network condition is unknown, and
also in repairing loss detected by the retransmission timer. SCTP slowly probes the
network to determine the available capacity of the network to avoid congestion in the
network. If SCTP detects a congestion in the network, it switches to the congestion
avoidance algorithm to manage the congestion.
The slow start and congestion avoidance algorithms use the following congestion
control variables:
Congestion window (cwnd)
Receiver window (rwnd)
Specifies the limit on the amount of data the
sender can transmit through the network, before
receiving an acknowledgement. This variable is
maintained for each destination address.
Specifies the receiver’s limit on the amount of
outstanding data.
NOTE: The minimum value of the cwnd and
rwnd variables determine the amount of data
transmission.
Slow start threshold (ssthresh)
26
Introduction
Determines whether the slow start or congestion
avoidance algorithm must be used to control data
transmission.
Partial Bytes Acknowledged
(partial_byte_acked)
Adjusts of the cwnd parameter.
In an SCTP connection, the sender uses the slow start algorithm if the value of cwnd
is less than the ssthresh value. If the value of cwnd is greater than the ssthresh
value, the sender uses the congestion avoidance algorithm. If the values for cwnd and
ssthresh are same, the sender can use either the slow start or congestion avoidance
algorithm. Unlike TCP, an SCTP sender must store the cwnd, ssthresh, and
partial_bytes_acked congestion control variables for each destination address of
the peer. However, the sender needs to store only one rwnd value for the whole
association, irrespective of whether the peer is multihomed or contains only one address.
Fast Retransmit and Fast Recovery
The fast retransmit congestion control algorithm is used to intelligently retransmit
missing segments of information in an SCTP association. When a receiver in an SCTP
connection receives a DATA chunk out of sequence, the receiver sends a SACK packet
with the unordered TSN, to the sender. The fast retransmit algorithm uses four SACK
packets to indicate loss of data, and retransmits DATA without waiting for the
retransmission timer to timeout. After the fast retransmit algorithm sends the DATA
that appears to be missing, the fast recovery algorithm controls the transmission of
new data until all the lost segments are retransmitted.
SCTP Features
The Signaling Transport (SIGTRAN) Working Group in IETF developed SCTP to
address the limitations in TCP and UDP. Though the development of SCTP was directly
motivated by the need to transfer Public Switched Telephone Network (PSTN) signaling
messages across the IP network, SIGTRAN ensured that the design meets the
requirements of other applications with similar requirements.
Table 1-2 compares features of SCTP, TCP, and UDP.
Table 1-2 Comparison Between SCTP, TCP, and UDP
Feature
SCTP
TCP
UDP
State required at each endpoint
yes
yes
no1
Reliable data transfer
yes
yes
no
Congestion control and avoidance
yes
yes
no
Message boundary conservation
yes
no2
yes
Path MTU discovery and message fragmentation
yes
yes2
no
Message bundling
yes
yes2
no
Multi-homed hosts support
yes
no
no
SCTP Features
27
Table 1-2 Comparison Between SCTP, TCP, and UDP (continued)
Feature
SCTP
TCP
UDP
Multi-stream support
yes
no
no
Unordered data delivery
yes
no
yes
Security cookie against SYN flood attack
yes
no
no
Built-in heartbeat (reachability check)
yes
no3
1
2
3
In UDP, a node can communicate with another node without going through a setup procedure, or
without changing any state information. However, each UDP packet contains the required state
information to form a connection, so that an ongoing state need not be maintained at each endpoint.
TCP does not preserve any message boundaries. It treats all the data passed from its upper layer as a
formatless stream of data bytes. However, because TCP transfers data in sequence of bytes, it can
automatically resize all the data into new TCP segments that are suitable for the Path MTU, before
transmitting them.
TCP implements a keep-alive mechanism, which is similar to the SCTP HEARTBEAT chunk. In TCP,
however, the keep-alive interval is, by default, set to two hours for state cleanup. In SCTP, the HEARTBEAT
chunk is used to facilitate fast failover.
This section addresses the following topics:
•
•
•
•
•
•
•
•
•
•
“Multihoming” (page 28)
“Multistreaming” (page 30)
“Conservation of Data Boundaries” (page 31)
“SCTP Graceful Shutdown Feature” (page 31)
“SCTP Support for IPv4 and IPv6 Addresses” (page 32)
“SCTP Data Exchange Features” (page 32)
“Support for Dynamic Address Reconfiguration ” (page 33)
“Reporting Packet Drops to an Endpoint” (page 33)
“Support for ECN-Nonces in SCTP” (page 34)
“SCTP Support for Partially Reliable Data Transmission” (page 35)
Multihoming
Multihoming is the ability of a single SCTP endpoint to contain multiple interfaces with
different IP addresses. In a single-homed connection, an endpoint contains only one
network interface and one IP address.
Figure 1-5 illustrates the single-homed connection in TCP.
28
Introduction
Figure 1-5 A Single-Homed Connection
In Figure 1-5, Host A contains a single network interface (NIA1) and Host B contains a
single network interface (NIB1). NIA1 is the only interface for Host A to interact with
Host B.
When a network or path failure occurs, the endpoint is completely isolated from the
network. Multihoming in SCTP ensures better chances of survival if a network failure
occurs, when compared to TCP. The built-in support for multi-homed hosts in SCTP
enables a single SCTP association to run across multiple links or paths, to achieve link
or path redundancy. This enables an SCTP association to achieve faster failover from
one link or path to another, with minimum interruption in the data transfer service.
Figure 1-6 illustrates the mutli-homed connection in SCTP.
Figure 1-6 A Multihomed Connection
In this figure, Host A contains multiple network interfaces to interact with Host B,
which also has multiple interfaces.
SCTP selects a single address as the "primary" address and uses it as the destination
for all DATA chunks for normal transmission. All the other addresses are considered
as alternate IP addresses. SCTP uses these alternate IP addresses to retransmit DATA
chunks and to improve the probability of reaching the remote endpoint. Retransmission
SCTP Features
29
may occur because of continued failure to send DATA to the primary address. As a
result, all DATA chunks are transmitted to the alternate address until the HEARTBEAT
chunks have re-established contact with the primary address
During the initiation of an association, the SCTP endpoints exchange the list of IP
addresses, so that each endpoint can receive messages from any of the addresses
associated with the remote endpoint. For security reasons, SCTP sends response
messages to the source address in the message that prompted the response.
An endpoint can receive messages that are out of sequence or with different address
pairs, because multi-homing supports multiple IP addresses. To overcome this problem,
SCTP incorporates procedures to resolve parallel initiation attempts into a single
association.
Multistreaming
Multistreaming enables data to be sent in multiple, independent streams in parallel,
so that data loss in one stream does not affect or stop the delivery of data in other
streams. Each stream in an SCTP association uses two sets of sequence numbers, namely
a Transmission Sequence Number (TSN) that governs the transmission of messages
and the detection of message loss, and the Stream ID/Stream Sequence Number
(SID/SSN) pair that determines the sequence of delivery of the received data.
TCP transmits data sequentially in the form of bytes in a single stream and ensures
that all the bytes are delivered in a particular order. Therefore, a second byte is sent
only after the first byte has safely reached the destination. The sequential delivery of
data causes delay when a message loss or sequence error occurs within the network.
An additional delay occurs when TCP stops sending data until the correct sequencing
is restored, either upon receiving an out-of-sequence message or by retransmitting a
lost message.
The strict preservation of message sequence in TCP poses a limitation for certain
applications. These applications require sequencing of messages that affect the same
resource (such as the same call or the same channel), so that messages are loosely
correlated and delivered without maintaining the overall sequence integrity.
The multistreaming feature in an SCTP, in which reliable data transmission and data
delivery are independent of each other, overcomes this problem. This feature also
avoids HOL blocking. This independence improves the flexibility of an application, by
allowing it to define semantically different streams of data inside the overall SCTP
message flow, and by enforcing message ordering only within each of the streams. As
a result, message loss in one particular stream does not affect the delivery of messages
in a different stream. The receiver can immediately determine if there is a gap in the
transmission sequence (for example, caused by message loss), and also can determine
whether messages received following the gap are within the affected stream. If SCTP
receives a message that belongs to the affected stream, a corresponding gap occurs in
SSN. The sender can continue to deliver messages to the unaffected streams while
buffering messages in the affected stream until retransmission occurs.
30
Introduction
Figure 1-7 illustrates how multi-streaming works in an SCTP association.
Figure 1-7 Multistreaming in an SCTP Association
NOTE: By default, SCTP contains two streams. SCTP uses stream 0 as the default
stream to transmit data. Applications can modify the number of streams through which
SCTP transmits data.
Conservation of Data Boundaries
In SCTP, a sending application can construct a message out of a block of data bytes
and instruct SCTP to transport the message to a receiving application. SCTP guarantees
the delivery of this message (data block) in its entirety. It also indicates to the receiver
about both the beginning and end of the data block. This is called conservation of
message boundaries. TCP does not conserve data boundaries. It treats all the data
passed to it from the sending application as a sequence or stream of data bytes. It
delivers all the data bytes to the receiver in the same sequential order as they were
passed from the application. TCP does not conserve data boundaries when packets
arrive out of sequence. As a result, the receiver cannot rearrange the packets. It has to
wait till the packets arrive in sequence, starting from the last unreceived packet to the
received out-of-sequence packet.
SCTP Graceful Shutdown Feature
SCTP does not support a "half-open" connection, which can occur in TCP. In a half-open
connection, even though an endpoint indicates that it has no more data to send, the
other endpoint continues to send data indefinitely. SCTP, on the other hand, assumes
that when the shutdown procedure begins, both the endpoints will stop sending new
data across the association. It also assumes that it needs only to clear up
acknowledgements of the previously sent data.
The SCTP shutdown feature uses a three-message procedure to gracefully shutdown
the association, in which each endpoint has confirmed the receipt of the DATA chunks
SCTP Features
31
before completing the shutdown process. When an immediate shutdown is required,
SCTP sends an ABORT message to an endpoint.
Figure 1-8 illustrates graceful shutdown in SCTP and the half-closed state in TCP.
Figure 1-8 Shutdown in TCP and SCTP
SCTP Support for IPv4 and IPv6 Addresses
SCTP supports both IPv4 and IPv6 address parameters in an SCTP packet, as defined
in RFC 2960 (Stream Control Transmission Protocol). When an association is set up, the
SCTP endpoints exchange the list of addresses of the endpoints in the INIT and
INIT-ACK chunks. The address of the endpoint is represented by the following
parameters: an IPv4 address parameter with value 5 and an IPv6 address parameter
with value 6. The INIT chunks can contain multiple addresses, which can be an IPv4
or IPv6 address.
SCTP Data Exchange Features
This section discusses the enhanced features in SCTP that ensures reliable data exchange
between endpoints.
Following are the data exchange features in SCTP:
•
32
In SCTP, data is transmitted in the form of packets. Each packet contains a DATA
chunk and a control chunk. An SCTP endpoint acknowledges the receipt of a DATA
chunk by sending a SACK chunk to the other endpoint. The SACK chunk indicates
the range of cumulative TSNs and non-cumulative TSNs, if any. The
non-cumulative TSNs indicate gaps in the received TSN sequence. When SCTP
identifies gaps in the TSN sequence, it resends the missing DATA chunks to the
other endpoint. SCTP uses the “delayed ack” method to send the SACK chunks.
In this method, SACK is sent for every second packet, but with an upper limit on
Introduction
the delay between SACKs. The frequency of sending SACKs increases to one per
received packet if gaps are detected in the TSN sequence.
For information on an SCTP packet, see “SCTP Packet” (page 23).
•
SCTP contains various congestion control algorithms, such as slow start, congestion
avoidance, fast recovery, and fast retransmit, to control the flow and retransmission
of data. For information on these congestion control algorithms see, “Congestion
Control in SCTP” (page 26). In these algorithms, the receiver advertises the receive
window and a sender advertises a per-path congestion window to handle
congestion. The receiver window indicates buffer occupancy of the receiver. The
per-path congestion window manages the packets in flight. The congestion control
algorithms in SCTP are similar to that of TCP, except that the endpoints in an SCTP
connection manages the conversion between bytes sent and received, and TSNs
sent and received. This is because a TSN is attached only to a chunk.
•
An HP-UX application can specify a lifetime for the data to be transmitted. If the
lifetime of the data has expired and the data has not been transmitted, the data,
such as time-sensitive signalling messages, can be discarded. If the lifetime of the
data has expired and the data has been transmitted, data must be delivered to
avoid a hole in the TSN sequence.
Support for Dynamic Address Reconfiguration
SCTP enables an endpoint to reconfigure the IP address information dynamically for
an existing association. When the endpoints exchange information during association
startup, the usability of SCTP also improves without modifying the SCTP protocol.
This feature is useful in computational and networking applications that add or remove
physical interface cards dynamically and need the IP address of the interface to be
changed dynamically. This feature also enables an endpoint to set the primary
destination address of a remote peer so that when the primary address of an endpoint
is deleted, the remote peer is informed of the address to which the data must be sent.
To enable SCTP to reconfigure IP addresses dynamically, an SCTP packet contains the
following chunk types:
Address Configuration Change
Chunk (ASCONF)
Address Configuration
Acknowledgment (ASCONF-ACK)
The ASCONF chunk communicates the
configuration change requests that must be
acknowledged, to the remote endpoint.
The ASCONF-ACK chunk is used by the receiver
of an ASCONF chunk to acknowledge the
reception of the ASCONF chunk.
Reporting Packet Drops to an Endpoint
When a packet drop occurs because of an error other than congestion, an endpoint can
mistakenly interpret the packet drop as an indication of congestion in the network. The
misinterpretation can cause an SCTP sender to stop sending packets. This results in
SCTP Features
33
under-utilization of the network link. Depending on the severity of the error, the sender
can remain in a state of congestion, which affects the performance of the association.
SCTP contains the PKTDROP chunk that discovers packets that are dropped because of
errors other than congestion. After receiving the PKTDROP chunk, an SCTP endpoint
can inform its peer that it has received an SCTP packet with an incorrect CRC32C or
Adler-32 checksum. The peer can then retransmit the SCTP packet without modifying
the congestion window.
For information on packet drop scenarios, see draft-stewart-sctp-pktdrprep-02.txt
(Stream Control Transmission Protocol (SCTP) Packet Drop Reporting) at:
http://tools.ietf.org/html/draft-stewart-sctp-pktdrprep-02
Support for ECN-Nonces in SCTP
With the increased deployment of real-time applications and transport services that
are sensitive to the delay and loss of packets, relying on packet loss alone as indicative
of congestion is not sufficient. SCTP's congestion management algorithms have built-in
techniques, such as Fast Retransmit and Fast Recovery, to minimize the impact of losses.
These mechanisms consider the network as a black box and continue to send packets
till packets are dropped because of congestion. However, these mechanisms are not
intended to help applications that are sensitive to the delay or loss of one or more
individual packets.
With the inclusion of active queue management techniques in the Internet infrastructure,
routers can assist in managing congestion. When a congestion occurs and the sender
continues to send packets, the number of packets in the queue in the router increases
and causes a bottleneck in the router. In such a case, the router marks the packets with
congestion experienced (CE) bits and sends them to the receiver to indicate congestion,
instead of dropping the packets. Explicit Congestion Notification (ECN) is a congestion
management algorithm that uses a similar method to handle congestion. ECN uses the
ECN field and the congestion experienced (CE) field in the IP header to mark the packets.
The ECN field contains the ECN-Capable Transport (ECT) field, which is set by the
data sender to indicate that the endpoints are ECN-capable. The CE bit is set by the
router to indicate congestion. The ECT code points range from 00 to 01. Senders use
the ECT (0) or ECT(1) code point to indicate ECT for each packet.
ECN uses the following information to provide congestion notifications:
•
•
•
Negotiation between the endpoints during connection setup to determine whether
they are both ECN-capable.
An ECN-Echo (ECNE) flag in the the IP header, which enables the data receiver to
inform the data sender when a CE packet is received.
A congestion window reduced (cwr) flag in the IP header, which enables the data
sender to inform the data receiver that the congestion window has been reduced.
The drawback in ECN is that a poorly implemented receiver or an intermediate network
element, such as router, firewall, intrusion detection system, can erase the ECNE flag
34
Introduction
that provides congestion signal to the sender. This is because ECN does not contain
mechanisms to avoid network elements from clearing the ECNE flag. Moreover, ECN
requires the cooperation of the receiver to return congestion experienced signals to the
sender. If the receiver erases the congestion signals to conceal congestion and does not
send these signals to the sender, the sender gains a performance advantage at the
expense of competing connections that do not experience congestion.
SCTP supports the ECN method and is exposed to misbehaving receivers that conceal
congestion signals. The misbehavior includes concealment of ECNE signals that may
cause an SCTP sender to be aggressive and unfair to compliant flows. SCTP supports
ECN-nonce to avoid misbehaving receivers from concealing congestion signals.
ECN-nonce also protects senders from other forms of misbehavior, such as optimistic
acknowledgements and false duplicate TSN notifications.
The ECN-nonce is a modification of the ECN signaling mechanism. It improves the
congestion control by preventing receivers from exploiting ECN to gain an unfair share
of network bandwidth. ECN-nonce improves the robustness of ECN by preventing
receivers from concealing marked or dropped packets. Like ECN, ECN-nonce uses the
ECT(0) and ECT(1) code points, the IP header flag, the cwr, and the ECNE bits.
The ECN-nonce uses two bits of the IP header called the ECT bits. The sender randomly
generates a single bit nonce and encodes it in the ECT codepoints, ECT(0) or ECT(1).
To indicate congestion in the network, routers overwrite the ECT codepoints with the
CE bit. The nonce sum (NS) is a cumulative one bit addition of the nonces received
from the receiver. The receiver calculates the nonce sum and returns it in the NS flag
of the SACK chunk. The sender verifies the value of the NS flag in the SACK chunk.
An incorrect nonce sum implies that one or more nonces are missing at the receiver,
because all the nonces are required to calculate the correct nonce sum. If an incorrect
nonce sum is received by the sender without ECNE signals, the sender can infer that
the receiver is concealing congestion notifications.
The ECN-nonce support in SCTP includes the following:
•
•
A single nonce-supported parameter in the INIT or INIT-ACK chunk that is
exchanged during the association establishment, to indicate to the peer whether
ECN-nonce is supported at both endpoints.
A single bit flag in the SACK chunk called the Nonce Sum (NS).
SCTP Support for Partially Reliable Data Transmission
SCTP supports partially reliable data transmission service (PR-SCTP) that enables an
SCTP sender to signal the receiver that it must not expect data from the SCTP sender.
PR-SCTP enables ordered and unreliable data transfer service between endpoints, in
addition to unordered and unreliable data transfer (similar to UDP). PR-SCTP employs
similar congestion control and congestion avoidance algorithms as SCTP, for both
reliable or partially reliable data traffic.
SCTP Features
35
The communication failure detection and protection capabilities of reliable SCTP data
traffic are also applicable to partially reliable data traffic. PR-SCTP enables an endpoint
to detect a failure destination address quickly and to failover to an alternate destination
address. It also notifies when the destination address becomes unreachable.
The chunk bundling capability in SCTP enables reliable and unreliable messages to be
multiplexed over a single PR-SCTP association. Multiplexing enables a single protocol
(that is SCTP) to be used to transmit different types of messages, instead of using
separate protocols.
SCTP includes the following parameter and chunk to support the partially reliable data
transmission service:
The Forward-TSN-Supported
parameter
The Forward Cumulative TSN
(FORWARD TSN) chunk
This is an optional parameter in the INIT and
INIT ACK chunks. When an association is
initialized, the SCTP sender must include this
parameter in the INIT or INIT ACK chunk to
inform its peer that it supports partially reliable
data service.
The receiver sends this chunk to a sender to
inform its support for PR-SCTP. An SCTP sender
uses this chunk to inform the receiver to move
its cumulative received TSN forward, because
the missing TSNs are associated with data chunks
that must not be transmitted or retransmitted by
the sender.
The timed-reliability service is an example of a partially reliable service that SCTP
provides to the upper layer using PR-SCTP. This service enables the service user to
indicate a limit on the duration of time that the sender must try to transmit or retransmit
the message.
If an SCTP endpoint supports the FORWARD TSN chunk, it can include the
Forward-TSN-supported parameter in the INIT chunk to indicate support for FORWARD
TSN chunk to its peer. If an endpoint chooses not to include the Forward-TSN-Supported
parameter, it cannot send or process a FORWARD TSN chunk anytime during the lifetime
of an association. Instead, it must pretend as if it does not support the FORWARD TSN
chunk and return an error to the peer upon the receipt of any FORWARD TSN chunk.
When a receiver of an INIT or INIT ACK chunk detects a Forward-TSN-Supported
parameter and does not support the Forward-TSN chunk type, the receiver may
optionally respond with the Unsupported Parameters parameter, as defined in
Section 3.3.3 of RFC 2960.
A receiver can perform the following tasks if it receives an INIT chunk that does not
contain the Forward-TSN-Supported parameter:
•
•
36
Include the Forward-TSN-Supported parameter in INIT-ACK.
Record the information that the peer does not support the FORWARD TSN chunk.
Introduction
•
•
Restrain from sending a FORWARD TSN chunk at any time during the lifetime of
an association.
Check with the upper layer if it has requested a notification on whether the peer
endpoint supports the Forward-TSN-Supported parameter.
Error Handling in SCTP
The network traffic in the Internet is unpredictable. Sudden network failures and traffic
surges can occur, which result in non-reachability of an endpoint. Such a network is
error prone and a sending application must be cautious while transmitting or
retransmitting data, because the receiving endpoint may be unavailable to receive data.
The unavailability of the endpoint is caused either by a path failure or an endpoint
failure.
SCTP offers appropriate error handling methods, to overcome this problem. Before
transmitting data, SCTP sends chunks of information to verify whether a destination
is active. Even before using a different path to reach a destination or closing an
association, SCTP ensures that the destination address is not reachable or inactive.
SCTP uses the following error handling methods:
•
•
•
Retransmission of DATA chunks
HEARTBEATs to identify path failures
HEARTBEATs to identify endpoint failures
This section addresses the following topics:
•
•
•
“Retransmission of DATA Chunks” (page 37)
“HEARTBEATs to Identify Path Failures” (page 38)
“HEARTBEATs to Identify Endpoint Failure” (page 38)
Retransmission of DATA Chunks
SCTP uses DATA chunks to exchange information between two addresses. Upon
receiving a DATA chunk, the receiving address sends an acknowledgement to the
sending address. If the receiving address does not receive the DATA chunk properly,
it sends a SACK packet that triggers the sending address to retransmit the DATA chunk.
The sending address also retransmits the DATA chunk when the retransmission timer
times out.
SCTP limits the rate of retransmission of DATA chunks, to reduce chances of congestion.
It modifies the retransmission timeout (RTO) value, based on the estimates of the round
trip delay and reduces the transmission rate exponentially when the message loss
increases.
In an active SCTP association with constant DATA transmission, SACKs are more likely
to cause retransmission than the retransmission timeout. To reduce unnecessary
retransmission of data, SCTP uses the four SACK rule, so that SCTP retransmits a DATA
chunk only after receiving the fourth SACK, which indicates a missing DATA chunk.
Error Handling in SCTP
37
SCTP also uses the four SACK rule to avoid retransmission caused by normal
occurrences, such as packets received out of sequence.
HEARTBEATs to Identify Path Failures
SCTP periodically sends HEARTBEAT chunks to idle destinations, or alternate addresses
to identify a path failure. SCTP maintains a counter to store the number of heartbeats
that are sent to the inactive destination, without receiving a corresponding Heartbeat
Ack chunk. When the counter reaches the specified maximum value, SCTP also declares
the destination address as inactive. SCTP notifies the application about the inactive
destination address and starts using an alternate address for sending the DATA chunks.
However, SCTP continues to send heartbeats to the inactive destination address until
it receives an ACK chunk. On receipt of an ACK chunk, SCTP considers the destination
address as active again. The rate at which SCTP sends heartbeats depends on the sum
of the RTO value and the delay parameter, which allow Heartbeat traffic to be tailored
per the needs of the user application.
HEARTBEATs to Identify Endpoint Failure
SCTP identifies an endpoint failure in a way that is similar to path failure discussed in
“HEARTBEATs to Identify Path Failures” (page 38)
SCTP maintains a counter across all destination addresses, to store the number of
retransmits or Heartbeats sent to the remote endpoint without a successful ACK. When
the value of the counter exceeds a preconfigured maximum value, SCTP declares the
endpoint as unreachable and closes the association.
SCTP Security
SCTP uses the following methods to provide security:
•
•
Cookie Mechanism
Verification Tag
This section addresses the following topics:
•
•
“Cookie Mechanism” (page 38)
“Verification Tag” (page 39)
Cookie Mechanism
A cookie mechanism is employed during the initialization of an association, to provide
protection against security attacks. The cookie mechanism uses a four-way handshake,
and the last pair of handshake is allowed to carry user data for fast setup.
The cookie mechanism guards against a blind attacker from generating INIT chunks,
which overload the resources of an SCTP server by causing the server to use memory
and resources to handle new INIT requests. Instead of allocating memory for a
Transmission Control Block (TCB), the server creates a cookie parameter with the TCB
38
Introduction
information, together with a valid lifetime and a signature for authentication, and sends
these back in the INIT ACK chunk. The blind attacker cannot obtain the cookie, because
the INIT ACK always goes back to the source address of the INIT. A valid SCTP client
gets the cookie and returns it in the COOKIE ECHO chunk, where the SCTP server can
validate the cookie and use it to rebuild the TCB. The cookie is created by the server,
and the cookie format and secret key remain with the server. The server does not
exchange these details with the client.
Verification Tag
A verification tag is a 32–bit unsigned integer that is randomly generated to verify
whether the SCTP packet belongs to the current association, or to a stale packet from
a previous association. SCTP discards packets received without the expected verification
tag value, to protect against blind masquerade attacks and also from receiving stale
SCTP packets from a previous association.
The verification tag rules apply when sending or receiving SCTP packets that do not
contain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO, ABORT, or a SHUTDOWN ACK
chunk.
While sending an SCTP packet, the endpoint must fill in the verification tag field of
the outbound packet, with the tag value in the Initiate Tag parameter of INIT or
INIT ACK received from its peer.
After receiving an SCTP packet, the endpoint must ensure that the value in the
verification tag field of the received SCTP packet matches its own tag. If the received
verification tag value does not match the receiver's own tag value, the receiver silently
discards the packet and does not process it any further.
The verification tag value is chosen by each endpoint of the association during
association startup.
SCTP Security
39
40
2 SCTP Socket APIs
This chapter discusses the different SCTP socket API types, their call flow sequence,
SCTP events and notifications, socket options, command socket calls, and the SCTP
ancillary data structures.
This chapter addresses the following topics:
•
•
•
•
•
•
•
•
“Overview” (page 41)
“Socket API Versus SCTP Socket API” (page 41)
“Different Socket API Styles” (page 42)
“API Options to Modify Socket Behavior” (page 52)
“Common Socket Calls” (page 54)
“SCTP Events and Notifications” (page 57)
“SCTP Ancillary Data Structures” (page 58)
“SCTP-Specific Socket APIs” (page 61)
Overview
The socket layer in an IP stack contains socket APIs that enable the transport layer to
interface with the application layer. The socket APIs make the various protocol-specific
features available to an application.
SCTP contains the existing socket APIs and the SCTP-specific APIs. Both these APIs
enable SCTP to interface with the application layer. These APIs are also compatible
with TCP applications that can be migrated to SCTP with minimum changes.
Following are the design objectives of the SCTP socket APIs:
•
•
•
•
Maintain consistency and ensure compatibility with the existing sockets APIs
Define socket mapping for SCTP that is consistent with other socket API protocols,
such as UDP, TCP, IPv4, and IPv6
Support a one-to-many style interface
Support a one-to one style interface
The following sections discuss the differences between the socket API and the SCTP
socket APIs, the different SCTP socket API styles, data structures that enable applications
to control an association, and socket APIs to modify the socket options.
Socket API Versus SCTP Socket API
The SCTP APIs use the existing socket APIs to perform operations that are similar to
the operating behavior of the socket APIs. For example, in the existing socket APIs and
the SCTP socket APIs, an application can call the bind() API only once and an
application can specify only a single address in the bind() API.
Overview
41
However, because of the unique features of SCTP, such as multistreaming and
multihoming, the existing socket APIs either do not work on an SCTP socket, or the
semantics of the socket APIs need modification. For example, because of the
multi-homing feature supported in SCTP, the socket APIs, getsockname() and
getpeername(), do not work on an SCTP socket if a given association is bound to
multiple local addresses and the association has multiple peer addresses. Applications
must use the sctp_getpaddrs() SCTP socket API to obtain the peer addresses in
an association.
Unlike the existing socket APIs, the SCTP socket APIs disclose many features of the
SCTP protocol and association status to the application, to enable applications gain
better control over the SCTP protocol. For example, an application can specify some
of the association setup parameters, such as the number of desired outbound streams
and maximum number of inbound streams, to control an association.
Different Socket API Styles
This section discusses the different socket API styles and the basic call flow sequence
of each socket API style.
Following are the different socket API styles:
•
•
One-to-one socket APIs
One-to-many socket APIs
The one-to-one style API is similar to the existing socket APIs for a connection-oriented
protocol, such as TCP. The one-to-many style API facilitates simultaneous associations
with multiple peers using one end point (that is, it associates with multiple peers using
one socket file descriptor simultaneously).
These socket API styles share common data structures and operations. However, each
socket API style requires a different application programming style. You can use these
socket APIs to implement all the SCTP features. You can also select the API style
depending on the type of association you need in the application.
This section addresses the following topics:
•
•
•
•
“One-to-One Socket APIs” (page 42)
“Basic One-to-One Call Flow Sequence” (page 43)
“One-to-Many Socket APIs” (page 48)
“Basic One-to-Many Call Flow Sequence” (page 48)
One-to-One Socket APIs
The one-to-one style socket APIs are designed to enable the existing TCP applications
to migrate to SCTP with minimal changes. The sequence of socket calls made by the
client and server of a one-to-one style SCTP application is similar to the sequence of
socket calls made by a TCP application. A one-to-one style SCTP application can control
only one association using one file descriptor.
42
SCTP Socket APIs
Basic One-to-One Call Flow Sequence
A one-to-one style SCTP application uses the following system call sequence to prepare
an SCTP endpoint for servicing requests:
1.
2.
3.
4.
5.
6.
socket()
bind() or sctp_bindx()
sctp_getladdrs()
sctp_freeladdrs
listen()
accept()
When a client sends a connection request to the server, the accept() call returns
with a new socket descriptor. The server then uses the new socket descriptor to
communicate with the client, using recv() and send() calls to receive requests
and send responses.
7.
8.
9.
10.
11.
sctp_getpaddrs()
sctp_freepaddrs
recv() or recvmsg()
send() or sctp_sendx() or sctp_send()
close() terminates the association.
An SCTP client uses the following system call sequence to set up an association with
a server to request services:
1. socket()
2. connect() or sctp_connectx()
After returning from connect(), the client uses send() and recv() calls to
send out requests and receive responses from the server.
3.
The client calls close() to terminate this association when .
For more information about the one-to-one style socket calls, see“Common Socket
Calls” (page 54).
The socket() Socket API
Applications call socket() to create a socket descriptor, to represent an SCTP endpoint.
Following is the syntax for the socket() socket API:
int socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP);
or
int socket(PF_INET6, SOCK_STREAM, IPPROTO_SCTP);
where:
PF_INET
PF_INET6
Specifies the IPv4 domain.
Specifies the IPv6 domain.
Different Socket API Styles
43
SOCK_STREAM
IPPROTO_SCTP
Indicates the creation of a one-to-one style socket.
Specifies the type of the protocol.
The first syntax of the socket() socket API creates an endpoint that can use only IPv4
addresses, while the second syntax creates an endpoint, which can use both IPv6 and
IPv4 addresses.
The bind() Socket API
Applications use bind() to specify the local address with which an SCTP endpoint
must associate.
These addresses, associated with a socket, are eligible transport addresses for the
endpoint to send and receive data. The endpoint also presents these addresses to its
peers during the association initialization process. To accept new associations on the
socket, the endpoint must call listen(), after calling bind(). For information on
listen(), see “The listen() Socket API” (page 45).
Following is the syntax for the bind() API:
ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen);
where:
sd
addr
addrlen
Represents the socket descriptor returned by the socket() call.
Represents the address structure (struct sockaddr_in or struct
sockaddr_in6).
Represents the size of the address structure.
If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv6
socket, the address passed can either be an IPv4 or an IPv6 address.
Applications cannot call bind() multiple times to associate multiple addresses to an
endpoint. After the first call to bind(), all the subsequent calls will return an error.
If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or
IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system
associates the endpoint with an optimal address set of the available interfaces. If bind()
is not called before a sendmsg() call that initiates a new association, the endpoint
picks a transient port and chooses an address set that is equivalent to binding with a
wildcard address. One of the addresses in the address set serves as the primary address
for the association. Thus, when an application calls bind() with the INADDR_ANY or
the IN6ADDR_ANY_INIT wildcard address, the multihoming feature is enabled in
SCTP.
The completion of the bind() process alone does not prepare the SCTP endpoint to
accept inbound SCTP association requests. When a listen() system call is performed
on the socket, the SCTP endpoint promptly rejects an inbound INIT request using an
ABORT flag.
44
SCTP Socket APIs
The listen() Socket API
Applications use listen() to prepare the SCTP endpoint for accepting inbound
associations.
Following is the syntax for the listen() socket API:
int listen(int sd, int backlog);
where:
sd
backlog
Represents the socket descriptor of the SCTP endpoint.
Represents the maximum number of outstanding associations allowed in
the accept queue of the socket. These associations have completed the
four-way initiation handshake and are in the ESTABLISHED state. A
backlog of 0 (zero) indicates that the caller no longer wants to receive new
associations.
The accept() Socket API
Applications use the accept() call to remove an established SCTP association from
the accept queue. The accept() API returns a new socket descriptor, to represent the
newly formed association.
Following is the syntax for the accept() socket API:
new_sd = accept(int sd, struct sockaddr *addr, socklen_t *addrlen);
where:
new_sd
sd
addr
addrlen
Represents the socket descriptor for the newly formed association.
Represents the listening socket descriptor.
Contains the primary address of the peer endpoints.
Specifies the size of addr.
The connect() Socket API
Applications use connect() to initiate an association with a peer.
Following is the syntax for the connect() socket API:
int connect(int sd, const struct sockaddr *addr, socklen_t addrlen);
where:
sd
addr
addrlen
Represents the socket descriptor of the endpoint.
Represents the address of the peer.
Represents the size of the address.
By default, the newly created association has only one outbound stream. Applications
must use the SCTP_INITMSG option before connecting to the server, to change the
number of outbound streams. The SCTP_INITMSG option enables you to set a socket
option and get a socket option, using the setsockopt() and getsockopt() APIs.
Different Socket API Styles
45
If SCTP does not call the bind() API before calling connect() , the application picks
a transient port and chooses an address set that is equivalent to binding with
INADDR_ANY and IN6ADDR_ANY for IPv4 and IPv6 sockets, respectively. One of these
addresses serves as the primary address for the association. When an application calls
bind() with the INADDR_ANY or the IN6ADDR_ANY_INIT wildcard address, the
multihoming feature is enabled in SCTP.
The close() Socket API
Applications use close() to gracefully close down an association.
Following is the syntax for the close() socket API:
int close(int sd);
where:
sd
Represents the socket descriptor of the association to be closed.
After an application calls close() on a socket descriptor, no further socket operations
succeed on that descriptor.
The shutdown() Socket API
Applications use the shutdown() socket API to disable send or receive operations at
an endpoint. The effect of the shutdown() call is different in SCTP and TCP. In TCP,
a connection is in half-closed state even after an application calls shutdown(). In the
half-close state, an application at the sending endpoint continues to send data even if
an application at the receiving endpoint has stopped receiving data. In SCTP,
shutdown() completely disables applications at both the endpoints from sending or
receiving data.
NOTE: Applications can use the SCTP streams feature to achieve the half closed state
in SCTP.
Following is the syntax for the shutdown() socket call:
int shutdown(int sd, int how);
sd
how
Specifies the socket descriptor of the association that needs to be closed.
Specifies the type of shutdown. The values are as follows:
Disables further receive operations
SHUT_RD
Disables further send operations and initiates the SCTP shutdown
SHUT_WR
sequence
SHUT_RDWR Disables further send and receive operations, and initiates the
SCTP shutdown sequence
In SCTP, SHUT_WR initiates an immediate and full protocol shutdown. In TCP, SHUT_WR
causes TCP to enter a half-closed state. The SHUT_RD value behaves in the same way
for SCTP and TCP. SCTP_WR closes the SCTP association while leaving the socket
46
SCTP Socket APIs
descriptor open, so that the receiving endpoint can receive data that SCTP was unable
to deliver.
The sendmsg() and recvmsg() Socket APIs
Applications use the sendmsg() and recvmsg() socket APIs to transmit data to and
receive data from its peer.
Following is the syntax for the sendmsg() and recvmsg() socket APIs:
ssize_t sendmsg(int sd, const struct msghdr *message, int flags);
ssize_t recvmsg(int sd, struct msghdr *message, int flags);
where:
sd
message
Represents the socket descriptor of the endpoint.
Specifies the pointer to the msghdr structure that contains a single user
message and the ancillary data. Following is the structure for the msghdr
structure:
struct msghdr {
void
*msg_name;
socklen_t
msg_namelen;
struct iovec *msg_iov;
size_t
msg_iovlen;
void
*msg_control;
socklen_t msg_controllen;
int
msg_flags;
};
where:
msg_name
msg_namelen
msg_iov
msg_iovlen
msg_control
msg_controllen
msg_flags
Specifies the pointer to the socket address structure.
Specifies the size of the socket address structure.
Includes an array of message buffers.
Specifies the number of elements in the msg_iov
structure.
Specifies the ancillary data.
Specifies the length of the ancillary data buffer.
Specifies the flags on the received message.
For more information on the msghdr, see RFC 2292 (Advanced Sockets API
for IPv6).
flags
Contains flags that affect the messages being sent or received
Different Socket API Styles
47
NOTE: A sendmsg() API does not fail if it contains an invalid SCTP stream identifier
but an error is returned on all subsequent calls on the file descriptor.
The getpeername() Socket API
Applications use the getpeername() socket API to retrieve the primary socket address
of the peer.
Following is the syntax for the getpeername() socket API:
int getpeername(int sd, struct sockaddr *address, socklen_t *len);
where:
sd
address
len
Specifies the socket descriptor to be queried.
Contains the primary peer address. If the socket is an IPv4 socket, the
address will be an IPv4 address. If the socket is an IPv6 socket, the address
will be either an IPv6 or an IPv4 address.
Specifies the length of the address.
If the actual length of the address is greater than the length of the supplied sockaddr
structure, SCTP truncates the stored address.
NOTE: The getpeername() socket API is available only for TCP compatibility. It
must not be used for the multihoming feature in SCTP, because this socket API does
not work with one-to-many style sockets.
One-to-Many Socket APIs
The one-to-many style APIs are designed to enable applications to control many
associations from a single endpoint, using a single file descriptor. Similar to the APIs
in UDP, one-to-many style APIs in SCTP enable a single socket file descriptor to connect
to multiple remote endpoints. A one-to-many style socket can send and receive data
without connecting to an endpoint. Unlike UDP, however, SCTP always has a valid
association with the specified endpoints, because SCTP is a connection-oriented protocol.
Basic One-to-Many Call Flow Sequence
A server in the one-to-many style uses the following socket call sequence to prepare
an endpoint for servicing requests:
1.
2.
3.
4.
5.
6.
48
socket()
bind() or sctp_bindx()
sctp_getladdrs()
sctp_freeladdrs()
listen()
sctp_getpaddrs()
SCTP Socket APIs
7.
8.
9.
10.
11.
sctp_setpaddrs()
recvmsg() or sctp_recvmsg()
sendmsg() or sctp_sendmsg()
sctp_peeloff()
close()
A client in the one-to-many style API uses the following call sequence to set up an
association with a server, and to request services from that server:
1.
2.
3.
4.
socket()
sendmsg() or sctp_sendmsg()
recvmsg() or sctp_recvmsg()
close()
By default, all the associations connected to an endpoint are represented with a single
socket. Each association is assigned an association ID (of type uint32_t
sctp_assoc_t), so that an application can use it to differentiate between different
associations. Applications can also use the sendto() call to set up an association.
However, an application cannot use the sendto() call to send data to an established
association, because the association ID cannot be specified in the sendto() call.
When an association ID is assigned to an SCTP association, SCTP must not reuse the
ID until the application explicitly terminates the association. The resources belonging
to that association are not freed until the association terminates. This is similar to the
close() call on a normal socket. The only difference between a normal socket and a
one-to-many socket is the availability of the SCTP_AUTOCLOSE option in the
one-to-many socket. When the SCTP_AUTOCLOSE option is set in a one-to-many socket,
an application can reuse the association ID assigned to the association once the
association terminates automatically. Applications that use this option must ensure
that they do not send data to an incorrect peer endpoint, because the association ID is
being reused.
A server or client can branch off an existing one-to-many association into a separate
socket. When an association is branched off to a separate socket, the branched off socket
is completely separated from the original socket. All subsequent control and data
operations on that association must be done through the new socket. For example, the
close() operation on the original socket does not terminate associations that have
been branched off to a different socket.
For more information on the one-to-many style socket APIs, see the subsequent
subsections and “SCTP-Specific Socket APIs” (page 61).
The socket() Socket API
The socket() socket API is used to create a socket descriptor that represents an SCTP
endpoint.
Following is the syntax for the socket() socket API:
Different Socket API Styles
49
sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
or
sd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);
where:
SOCK_SEQPACKET
IPProto_SCTP
PF_INET
PF_INET6
Indicates the creation of a one-to-one or one-to-many style
socket.
Specifies the type of the protocol.
Specifies the IPv4 domain.
Specifies the IPv6 domain.
The first syntax of socket() creates an endpoint that can use only IPv4 addresses,
while the second syntax creates an endpoint that can use both IPv6 and IPv4 addresses.
The bind() Socket API
Applications use bind() to specify the local address to which an SCTP endpoint must
associate.
An SCTP endpoint can be associated with multiple addresses. The sctp_bindx()
API enables applications to associate with multiple addresses. For information on
sctp_bindx(), see “The sctp_bindx() SCTP Socket API” (page 61). These addresses,
associated with a socket, are eligible transport addresses for the endpoint to send and
receive data. The endpoint also presents these addresses to its peers during the
association initialization process. To accept new associations on the socket, applications
must call listen(), after calling bind(). For information on listen(), see “The
listen() Socket API” (page 45).
Following is the syntax for the bind() socket API:
ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen);
where:
sd
addr
addrlen
Represents the socket descriptor returned by the socket() call.
Represents the address structure (struct sockaddr_in or struct
sockaddr_in6).
Represents the size of the address structure.
If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv6
socket, the address passed can be either an IPv4 or an IPv6 address.
Applications cannot call bind() multiple times to associate multiple addresses to an
endpoint. After the first call to bind(), all the subsequent calls will return an error.
If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or
IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system
associates the endpoint with an optimal address set of the available interfaces.
If a bind() call is not called before a sendmsg() call that initiates a new association,
the endpoint picks a transient port and chooses an address set that is equivalent to
50
SCTP Socket APIs
binding with a wildcard address. One of the addresses in the address set serves as the
primary address for the association. This automatically enables the multi-homing
feature of SCTP.
The listen() Socket API
An application uses listen() to indicate that a socket is ready to accept new
associations.
Following is the syntax for the listen() socket API:
int listen(int sd, int backlog);
where:
sd
backlog
Specifies the socket descriptor of the endpoint.
Defines the number of connections in the listen queue.
By default, one-to-many style sockets do not accept new associations. If applications
that use one-to-many style socket APIs call the accept() API to accept new
associations, SCTP returns the EOPNOTSUPP error to the application. In the one-to-many
style socket APIs, new associations are accepted automatically and notifications of the
new associations are delivered using the recvmsg() API with the
SCTP_ASSOC_CHANGE event (if these notifications are enabled). A client in a
one-to-many association does not call listen(). Therefore, clients can be assured that
the only associations on the socket are the associations that are actively initiated. On
the contrary, a server or a peer-to-peer socket in a one-to-many connection always
accepts new associations. Therefore, an application running on a server using a
one-to-many style API must be prepared to handle new associations from unwanted
peers.
The SCTP_ASSOC_CHANGE event provides the association ID for a new association. If
applications want to use the association ID as input for other socket calls, they must
ensure that the SCTP_ASSOC_CHANGE event is enabled (it is enabled by default).
The sendmsg() and recvmsg() Socket APIs
An application uses sendmsg() and recvmsg() calls to transmit data to and receive
data from its peer.
ssize_t sendmsg(int sd, const struct msghdr *message, int flags);
ssize_t recvmsg(int sd, struct msghdr *message, int flags);
where:
sd
message
flags
Specifies the socket descriptor.
Specifies the pointer to the msghdr structure, which contains a single user
message and the ancillary data.
Contains flags that affect messages that are being sent and received.
Different Socket API Styles
51
The close() Socket API
Applications use close() to gracefully shutdown all the associations represented by
a one-to-many style socket.
Following is the syntax for the close() socket API:
close(int sd);
where:
sd
Specifies the socket descriptor of the associations to be closed.
To gracefully shutdown a specific association that is represented by the one-to-many
style socket, an application must use the sendmsg() call and include the MSG_EOF
flag. A user can optionally terminate an association non-gracefully by sending the
MSG_ABORT flag, and possibly by passing a user specified abort code in the data field.
Both the flags, MSG_EOF and MSG_ABORT, are passed with ancillary data in the
sendmsg() call.
If sd in the close() call is a branched-off socket that represents only one association,
the shutdown is performed only on that association.
The connect() Socket API
An application can use the connect() call in the one-to-many style to initiate an
association without sending data.
Following is the syntax for the connect() socket API:
connect(int sd, const struct sockaddr *nam, socklen_t len);
where:
sd
len
Specifies the socket descriptor for a new association.
Specifies the size of the address.
Multiple connect() calls can be made on the same socket to create multiple
associations. In UDP, a connect() call cannot make multiple associations on the same
socket.
API Options to Modify Socket Behavior
This section describes the APIs that include options to modify the socket behavior.
SCTP provides many socket options to modify options that are associated with a socket.
These socket options can enable or disable certain functions to facilitate applications
to control the transport of data.
If you modify a socket option, you must specify the level to which the option belongs.
The level indicates whether the option applies to the socket interface, or to a lower-level
communications protocol interface, such as IP, TCP, or SCTP.
52
SCTP Socket APIs
You can use the getsockopt() and setsockopt() system calls to modify the socket
options. These system calls set or retrieve socket interface options, or lower-level
protocol options.
Following is the syntax for the getsockopt() system call:
int getsockopt(
int s,
int level,
int optname,
void *optval,
int *optlen
);
where:
s
level
optname
optval
optlen
Indicates the file descriptor.
Specifies the type of protocol. You must set the level to IPPROTO_SCTP
for all the SCTP options.
Specifies the option name.
Specifies the buffer to store the value of the option.
Specifies the size of the buffer (or the length of the option returned).
Following is the syntax for the setsockopt() API:
int setsockopt(
int s,
int level,
int optname,
const void *optval,
int optlen
);
where:
s
level
optname
optval
optlen
Indicates the file descriptor.
Specifies the type of protocol. You must set the level to IPPROTO_SCTP
for all SCTP options.
Specifies the option name.
Specifies the buffer to store the value of the option.
Specifies the size of the buffer (or the length of the option returned).
SCTP associations being multihomed, certain option parameters include the
sockaddr_storage structure to select the peer address to which the option must be
applied. For a one-to-many style socket, applications can use an association ID
(sctp_assoc_t structure) to identify the association instance that is affected by the
option. Applications must set this association ID while using a one-to-many API style
socket. In the case of one-to-one style socket APIs and the branched off one-to-many
style sockets, SCTP ignores this association ID parameter.
API Options to Modify Socket Behavior
53
In the case of the one-to-many style APIs, the socket options are applied to all
associations that belong to a socket. For a one-to-one API, the socket options apply to
all peer addresses of the association controlled by the socket.
In the SCTP stack, the getsockopt() is read-only. This means that applications cannot
specify any information in the getsockopt() call. As a result, applications must use
the sctp_opt_info() API to pass information both into and out of the SCTP stack.
Following is the syntax for the sctp_opt_info() API:
int sctp_opt_info(int sd,
sctp_assoc_t id,
int opt,
void *arg,
socklen_t *size);
where:
id
opt
Specifies the association ID. For a one-to-many style socket, id specifies the
association to query. For a one-to-one style socket, SCTP ignores the ID.
Specifies the SCTP socket option. The sctp_opt_info() API retrieves socket
options, specified as follows:
• SCTP_RTOINFO
• SCTP_ASSOCINFO
• SCTP_DEFAULT_SEND_PARAM
• SCTP_GET_PEER_ADDR_INFO
• SCTP_PRIMARY_ADDR
• SCTP_PEER_ADDR_PARAMS
• SCTP_STATUS
sctp_opt_info() does not support the authentication related-options
SCTP_AUTH_CHUNKS, SCTP_AUTH_SECRET, and SCTP_PEER_AUTH_CHUNKS.
arg
Specifies an option-specific structure buffer that is provided by an application.
The sctp_opt_info() API returns 0 on success, and returns -1 on failure. It sets
errno to the appropriate error code.
The sctp_opt_info() call is a replacement for getsockopt(), and
sctp_opt_info() does not set any option associated with the specified socket. You
must use the setsockopt() call to set any writeable option, such as SO_LINGER and
SCTP_NODELAY.
Common Socket Calls
This section discusses socket calls that are common to both one-to-one and one-to-many
style APIs.
54
SCTP Socket APIs
The send(), sendto(), recv(), and recvfrom() Socket Calls
Applications can use the send() and sendto() socket calls to transmit data to the
peer. The recv() and recvfrom() socket calls can be used to receive data from the
peer.
Following are the syntaxes for the send(), sendto(), recv(), and recvfrom()
socket calls, respectively:
ssize_t send(int sd, const void *msg, size_t len, int flags);
ssize_t sendto(int sd, const void *msg, size_t len, int flags,
const struct sockaddr *to, socklen_t tolen);
ssize_t recv(int sd, void *buf, size_t len, int flags);
ssize_t recvfrom(int sd, void *buf, size_t len, int flags,
struct sockaddr *from, socklen_t *fromlen);
where:
sd
msg
len
to
tolen
buf
from
fromlen
flags
Specifies the socket descriptor of an SCTP endpoint.
Specifies the message to be sent.
Specifies the size of the message or the size of buffer.
Specifies one of the peer addresses of the association to be used to send
the message.
Specifies the size of the address.
Specifies the buffer to store a received message.
Specifies the buffer to store the peer address used to send the received
message.
Specifies the size of the from address.
Contains flags affecting the message being sent.
The send(), sendto(), recv(), and recvfrom() calls provide access to only basic
SCTP protocol features. If a peer in an association uses multiple streams or sends
unordered data, these calls may not be adequate. As a result, it may deliver data in
unpredictable ways.
These calls do not allow the application to specify the stream on which a message must
be sent. SCTP uses stream 0 as the default stream to send data using send() and
sendto(). The recv() and recvfrom() calls return data from any stream. However,
the application cannot distinguish the different streams. As a result, data arrives without
any order. Similarly, if an application sends unordered data chunk, recv() and
recvfrom() do not provide any notification for the unordered data.
The message buffer buf in the send() and sendto() calls is a single message buffer.
If the caller wants to send a message that is composed of several buffers, the caller must
combine all the buffers, before calling send() and sendto(). Alternately, the caller
can use the sendmsg() call to send multiple buffers, without combining the buffers.
The recv() and recvfrom() calls cannot distinguish message boundaries.
You cannot use the send() and recv() calls in the case of one-to-many style sockets.
Common Socket Calls
55
NOTE: If an application calls a send function without user and ancillary data, SCTP
rejects the request with an appropriate error message.
The setsocktopt() and getsockopt() Socket Calls
Applications use the setsockopt() and the getsockopt() calls to set and retrieve
socket options. You can use the socket options to modify the default behavior of the
sockets calls. For information on socket options, see “API Options to Modify Socket
Behavior” (page 52).
NOTE: While using the SCTP_ASSOCINFO option to set the maximum number of
retransmissions, the sctp_opt_info() call does not fail if this number is greater than
the sum of all maximum path retransmissions for each remote address. Therefore, the
success or failure of this option does not depend on the number of remote addresses
and whether the association is up.
Following are the syntaxes for the getsockopt() and setsockopt() socket calls,
respectively:
getsockopt(int sd, int level, int optname, void *optval,
socklen_t *optlen);
setsockopt(int sd, int level, int optname, const void *optval,
socklen_t optlen);
where:
sd
level
optname
optval
optlen
Specifies the socket description.
Specifies the type of protocol. You must set the level to IPPROTO_SCTP
for all SCTP options.
Specifies the option name.
Specifies the buffer to store the value of the option.
Specifies the size of the buffer (or the length of the option returned).
NOTE: A positive linger time for the SO_LINGER option results in an immediate
termination of the process following the SCTP shutdown.
The read() and write() Socket Calls
Applications use read() and write() socket calls to send and receive data to and
from a peer. These socket calls have the same functionality as the send() and recv()
socket calls, except that the flags parameter is not present in the read() and write()
calls.
If these calls are used in one-to-many style sockets, applications can use these calls only
with branched off socket descriptors.
56
SCTP Socket APIs
The getsockname() Socket Call
Applications use getsockname() to retrieve the locally-bound socket address of the
specified socket. This is especially useful if the caller allows SCTP to select a local port.
The getsockname() API is also useful if an SCTP endpoint is not multihomed. An
HP-UX socket uses its copy of the bound address to implement the getsockname()
system call.
Following is the syntax for the getsockname() socket call:
int getsockname(int sd, struct sockaddr *address,
socklen_t *len);
where:
sd
address
len
Specifies the socket descriptor to be queried.
Stores the locally bound address that is selected by the SCTP stack. If the
socket is an IPv4 socket, the address will be an IPv4 address. If the socket
is an IPv6 socket, the address can be either an IPv6 or IPv4 address.
Specifies the length of the address.
If the actual length of the address is greater than the length of the sockaddr structure,
the stored address is truncated. If the socket is not bound to a local name, the value
contained in the address variable is not specified.
SCTP Events and Notifications
An event refers to a change in the network status, association startups, remote
operational errors, or undeliverable messages. An SCTP application must understand
and process these events, and resolve errors that occur on an SCTP stack.
If an SCTP application wants the SCTP stack to deliver notifications for a particular
event, the SCTP application can set the appropriate socket option for notifications in
the setsockopt() call. You can configure an SCTP application to send notifications
using the setsockoptg() call. When an SCTP application sends a recvmsg() call
to another application at the peer endpoint, the SCTP application normally reads the
data message from the peer endpoint. For information on recvmsg(), see “The
sendmsg() and recvmsg() Socket APIs” (page 47).
If the SCTP application reads a non-data message, the application sets the message
notification flag in the recvmsg() API. When the notification arrives, recvmsg()
returns the notification in the application-supplied data buffer in the msg_iov parameter,
and sets the MSG_NOTIFICATION flag in the msg_flags parameter. A recvmsg()
call returns only one notification at a time. While the SCTP application is reading data,
recvmsg() returns a part of a notification if the msg_iov buffer is not sufficient. If a
single read is not sufficient, MSG_EOR is not set in the msg_flags parameter. The SCTP
application must finish reading the notification before the subsequent data arrives.
Following is the SCTP notification structure:
SCTP Events and Notifications
57
union sctp_notification {
struct {
uint16_t sn_type;
uint16_t sn_flags;
uint32_t sn_length;
} sn_header;
struct sctp_assoc_change
struct sctp_paddr_change
struct sctp_remote_error
struct sctp_send_failed
struct sctp_shutdown_event
struct sctp_adaption_event
struct sctp_pdapi_event
};
/* Notification type. */
sn_assoc_change;
sn_paddr_change;
sn_remote_error;
sn_send_failed;
sn_shutdown_event;
sn_adaption_event;
sn_pdapi_event;
For more information on the SCTP notification structure, see
draft-ietf-tsvwg-sctpsocket-10.txt
SCTP Ancillary Data Structures
The SCTP socket APIs can use the ancillary data structures to enable applications to
control an association. These structures also enable SCTP to notify applications about
association events.
The ancillary data mechanism uses the definition of struct msghdr, which is available
to an SCTP application when it uses the X/Open socket.
NOTE: An application that uses BSD43 socket cannot use the features related to
ancillary data.
SCTP processes each ancillary data using the cmsghdr structure, which defines the
function and purpose of the data. Following is the structure for the cmsghdr structure:
struct cmsghdr {
socklen_t cmsg_len;
int
cmsg_level;
int
cmsg_type;
};
Where:
cms_len
cmsg_level
cmsg_type
Specifies the number of bytes, including the header.
Specifies the originating protocol.
Specifies the type of the protocol followed by an unsigned character,
cmsg_data.
For the structure definition of the msghdr structure, see “The sendmsg() and recvmsg()
Socket APIs” (page 47).
58
SCTP Socket APIs
An SCTP application can use ancillary data structures to communicate certain aspects
of an association, such as:
•
•
Treating a user date if it cannot be sent in a certain time
Specifying the number of inbound streams to be advertised during association
setup
SCTP provides the following ancillary data structures:
•
•
SCTP Initiation Structure
SCTP Header Information
The following sections discuss these ancillary data structures in detail.
SCTP Initiation Structure (SCTP_INIT)
When an application calls sendmsg() using a one-to-many style socket API, it uses
an SCTP initiation structure to set the protocol parameters for a new association. The
SCTP initiation structure is represented by the sctp_initmsg ancillary data structure.
The name of the ancillary data type is SCTP_INIT, and the data type is defined at the
IPPROTO_SCTP level.
Following is the data structure for the sctp_initmsg structure:
struct sctp_initmsg {
uint16_t sinit_num_ostreams;
uint16_t sinit_max_instreams;
uint16_t sinit_max_attempts;
uint16_t sinit_max_init_timeo;
};
where:
sinit_num_ostreams
sinit_num_ostreams
sinit_max_instreams
sinit_max_init_timeo
Represents the number of outbound streams.
Represents the number of inbound streams to be
supported.
Represents the maximum number of times INIT must
be transmitted before giving up an association setup.
Represents the largest time out value to use in
attempting a INIT.
The values provided by an application are for a association and overrides the default
values.
SCTP Header Information (SCTP_SNDRCV)
An application uses the SCTP header information to describe the SCTP header
information of a message that is received through the recvmsg() call, and to specify
the SCTP options for the sendmsg() call. The SCTP header information is represented
by the sctp_sndrcvinfo ancillary data structure. The name of the ancillary data
type is SCTP_SNDRCV, and the data type is defined at the IPPROTO_SCTP level.
SCTP Ancillary Data Structures
59
Following is the data structure for the sctp_sndrcvinfo structure:
struct sctp_sndrcvinfo {
uint16_t sinfo_stream;
uint16_t sinfo_ssn;
uint16_t sinfo_flags;
uint32_t sinfo_ppid;
uint32_t sinfo_context;
uint32_t sinfo_timetolive;
uint32_t sinfo_tsn;
uint32_t sinfo_cumtsn;
sctp_assoc_t sinfo_assoc_id;
};
The msghdr structure in the recvmsg() and sendmsg() APIs uses the
sctp_sndrcvinfo structure to set and get various control information from the SCTP
endpoint.
Table 2-1 lists the elements in the sctp_sndrcvinfo structure for the recvmsg()
and sendmsg() calls.
Table 2-1 Data Structures in the recvmsg() and sendmsg() Calls
Variable
recvmsg()
sendmsg()
sinfo_stream
Specifies the stream number of the
message.
Specifies the stream number to which the
application wants to send the message.
sinfo_ssn
Contains the stream sequence number
in the DATA chunk.
Not applicable
sinfo_ppid
Specifies the information that is passed Specifies an opaque unsigned value that
by the upper layer in the peer
is passed to the remote endpoint in each
application.
user message.
sinfo_context
Not applicable
Specifies an opaque context data that is
passed back to the application while
reporting an error on the concerned
sendmsg() call.
sinfo_flags
Specifies the flag (MSG_UNORDRED) to
inform the application that the message
received was unordered. The
recvmsg() API contains only one flag
(MSG_UNORDRED), whereas the
sendmsg() API contains multiple flags.
Specifies the flag that controls the send
behavior of the data chunk, or the
association itself. For example,
sendmsg() contains the MSG_UNORDRED
flag to indicate unordered send of data,
and MSG_EOF to close a given
association.
sinfo_timetolive Not applicable
60
SCTP Socket APIs
Specifies the time-to-live (TTL) for a
given message. If an application does not
send a message within the specified TTL
value, the message expires and a
notification is sent to the application, if
notification is enabled.
Table 2-1 Data Structures in the recvmsg() and sendmsg() Calls (continued)
Variable
recvmsg()
sendmsg()
sinfo_tsn
Specifies the transmission sequence
number (TSN) assigned to one of the
SCTP data chunks.
Not applicable
sinfo_cumtsn
Specifies the cumulative TSN, while
presenting an unordered message (if the
MSG_UNORDRED flag is set)
Not applicable
sinfo_assoc_id
Specifies the association ID.
Specifies the association ID.
SCTP-Specific Socket APIs
This section discusses the SCTP-specific socket APIs.
Following are the SCTP-specific socket APIs:
•
•
•
•
•
•
•
•
•
•
•
The sctp_bindx() API
The sctp_peeloff() API
The sctp_getpaddrs() API
The sctp_freepaddrs() API
The sctp_getladdrs() API
The sctp_freeladdrs() API
The sctp_sendmsg() API
The sctp_recvmsg() API
The sctp_connectx() API
The sctp_send() API
The sctp_sendx() API
The following subsections discuss these APIs in detail.
The sctp_bindx() SCTP Socket API
Applications can use the sctp_bindx() API to associate with multiple addresses.
Following is the syntax for the sctp_bindx() socket API:
int sctp_bindx(int sd, struct sockaddr *addrs, int addrcnt,
int flags);
where:
sd
addrs
Specifies the socket descriptor. If sd is an IPv4 socket, the addresses passed
must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passed
can either be an IPv4 or an IPv6 addresses.
Specifies a pointer to an array of one or more socket addresses. Each
address is specified in its appropriate structure. For an IPv6 socket,
SCTP-Specific Socket APIs
61
sctp_bindx() returns an array of type sockaddr_in6. For an IPv4
socket, sctp_bindx() returns an array of type sockaddr_in.
Specifies the number of addresses in the array (sockaddr_in6 or
sockaddr_in). You cannot use wildcard addresses with sctp_bindx().
Contains flags affecting the message that is being sent. The flags parameter
is formed from the bitwise OR of zero or more of the following flags:
• SCTP_BINDX_ADD_ADDR
• SCTP_BINDX_REM_ADDR
addrcnt
flags
SCTP_BINDX_ADD_ADDR directs SCTP to add the given addresses to the
association, and SCTP_BINDX_REM_ADDR directs SCTP to remove the
given addresses from the association. These flags are mutually exclusive.
On success, sctp_bindx() returns 0. On failure, sctp_bindx() returns -1, and sets
errno to the appropriate error code.
The sctp_peeloff() SCTP Socket API
Applications can use the sctp_peeloff() socket API to branch off an association
into a separate socket. This API is a one-to-one style socket API.
Following is the syntax for the sctp_peeloff() socket API:
sctp_peeloff(int sd, sctp_assoc_t assoc_id)
where:
sd
assoc_id
Specifies the socket descriptor representing the branched-off association.
Specifies the identifier of the association that must be branched off to a
separate file descriptor.
The sctp_getpaddrs() SCTP Socket API
Applications can use the sctp_getpaddrs() socket API to return all peer addresses
in an association.
Following is the syntax for the sctp_getpaddrs() socket API:
int sctp_getpaddrs(int sd, sctp_assoc_t id,
struct sockaddr **addrs);
where:
sd
id
addrs
62
Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned
will be IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be
either an IPv4 or an IPv6 addresses.
Specifies the association ID. For one-to-many style sockets, ID specifies the
association to query. An application ignores id for one-to-one style sockets.
Points to the dynamically allocated array of sockaddr structures of the
appropriate socket type. An application must use the sctp_freepaddrs()
call to free the memory.
SCTP Socket APIs
On success, sctp_getpaddrs() returns the number of peer addresses in the
association. The sctp_getpaddrs() API can fail for the following reasons:
•
•
If an association does not exist on a socket, sctp_getpaddrs() returns 0. The
value of *addrs is undefined.
If an error occurs, sctp_getpaddrs() returns -1 and the value of *addrs is left
undefined.
The sctp_freepaddrs() SCTP Socket API
Applications must use the sctp_freepaddrs() socket API to free all resources
allocated by the sctp_getpaddrs() API.
Following is the syntax for the sctp_freepaddrs() socket API:
void sctp_freepaddrs(struct sockaddr *addrs);
where:
addrs
Specifies the array of peer addresses returned by sctp_getpaddrs().
The sctp_getladdrs() SCTP Socket API
Applications can use the sctp_getladdrs() SCTP socket API to return all the locally
bound addresses on a socket.
Following is the syntax for the sctp_getladdrs() SCTP socket API:
int sctp_getladdrs(int sd, sctp_assoc_t id, struct sockaddr **ss);
where:
sd
id
ss
Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned will
be an IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be either
an IPv4 or IPv6 address.
Specifies the association ID. For one-to-many style sockets, id specifies the
association to query. An application ignores id for one-to-one style sockets. If id
is set to 0 (zero), the locally bound addresses are returned irrespective of the
particular association.
Points to a dynamically allocated array of sockaddr structures of the appropriate
socket type.
An application must use sctp_freeaddrs() to free the memory that is allocated by
sctp_getladdrs(), to store addresses.
On success, sctp_getladdrs() returns the number of local addresses bound to the
socket. If the socket is unbound, sctp_getladdrs() returns 0, and the value of
*addrs is left undefined. If an error occurs, sctp_getladdrs() returns -1, and the
value of *addrs is left undefined.
SCTP-Specific Socket APIs
63
The sctp_freeladdrs() SCTP Socket API
Applications use the sctp_freeladdrs() API to free all resources allocated by the
sctp_getladdrs() socket API.
Following is the syntax for the sctp_freeladdrs() API:
void sctp_freeladdrs(struct sockaddr *addrs);
where:
addrs
Specifies the array of peer addresses returned by the sctp_getladdrs()
socket API.
The sctp_sendmsg() SCTP Socket API
Applications can use sctp_sendmsg() to send an SCTP message. This API is similar
to the sendmsg() call, with the SCTP_SNDRCV option.
Following is the syntax for the sctp_sendmsg() SCTP socket API:
ssize_t sctp_sendmsg(int sd,
const void *msg,
size_t len,
const struct sockaddr *to,
socklen_t tolen,
uint32_t ppid,
uint32_t flags,
uint16_t stream_no,
uint32_t timetolive,
uint32_t context)
where:
sd
msg
len
to
tolen
ppid
flags
stream_no
timetolive
context
64
SCTP Socket APIs
Specifies the socket descriptor.
Specifies the message to be sent.
Specifies the length of the message.
Specifies the destination address of the message.
Specifies the length of the destination address.
Specifies the payload protocol identifier, which is entered in the
payload protocol identifier field of the SCTP data header.
Contains flags affecting the message being sent.
Contains the stream number of the message.
Specifies the TTL value for a message in milliseconds.
Specifies a 32-bit unsigned integer that is used by sendmsg(). When
an application fails to send the data and an SCTP_SEND_FAILED
notification is sent to the upper layer in the peer application, an
application returns context as part of the information.
The sctp_recvmsg() SCTP Socket API
Applications can use the sctp_recvmsg() SCTP socket API to receive messages. This
API is similar to the recvmsg() API, with the SCTP_SNDRCV option. For the
sctp_sndrcvinfo structure to be populated by sctp_recvmsg(), an application
must enable the sctp_data_io_events with the SCTP_EVENTS option.
Following is the syntax for the sctp_recvmsg() socket API:
ssize_t sctp_recvmsg(int sd,
void *msg,
size_t len,
struct sockaddr *from,
socklen_t *fromlen
struct sctp_sndrcvinfo *sinfo
int *msg_flags)
where:
sd
msg
len
from
fromlen
sinfo
msg_flags
Specifies the socket descriptor.
Specifies a message buffer.
Specifies the length of the message buffer.
Specifies the sender of a message.
Specifies the length of the address.
Denotes a pointer to an sctp_sndrcvinfo structure that is filled after
the message is received.
Denotes a pointer to an integer to be filled with a message flag.
The sctp_connectx() SCTP Socket API
Applications can use the sctp_connectx() SCTP socket API to associate to an
endpoint that is multihomed. This API enables an application to specify multiple
addresses on which a peer can be reached. This API only specifies that the SCTP will
try to make use of all the addresses in the list when required.
Following is the syntax for the sctp_connectx() SCTP socket API:
int sctp_connectx(int sd,
struct sockaddr *addrs,
int addrcnt)
where:
sd
addrs
addrcnt
Specifies the socket descriptor.
Specifies an array of addresses.
Specifies the number of addresses in the array.
The list of addresses passed to sctp_connectx() is used only for setting up the
association and does not specify the set of addresses the peer uses for the resulting
association. If applications want to find out the set of peer addresses, applications must
use the sctp_getpaddrs() to retrieve them after the association is set up.
SCTP-Specific Socket APIs
65
The sctp_send() SCTP Socket API
Applications can use the sctp_send() SCTP socket API to send data without using
the cmsg header structures. This API is similar to the sendmsg() API, with the
SCTP_SNDRCV option.
Following is the syntax for the sctp_send() SCTP socket API:
int sctp_send(int sd,
const void *msg,
size_t len,
const struct sctp_sndrcvinfo *sinfo,
int flags);
where:
sd
msg
len
sinfo
flags
Specifies the socket descriptor.
Specifies the message to be sent.
Specifies the length of the message.
Specifies a pointer to a sctp_sndrcvinfo structure that is used for a
sendmsg() call.
Contains flags similar to the flags passed to the sendmsg() call.
Applications can also use this API to terminate an association using an association ID,
by setting the sinfo.sinfo_flags to MSG_EOF, and the sinfo.sinf_associd to
the association that must be terminated. In this case, the length of the message is 0
(zero).
The sctp_sendx() SCTP Socket API
Applications can use the sctp_sendx() SCTP socket API to send data, without using
the cmsg header structures that provide a list of addresses.
Following is the syntax for the sctp_sendx() SCTP socket API:
int sctp_sendx(int sd,
const void *msg,
size_t len,
struct sockaddr *addrs,
int addrcnt,
struct sctp_sndrcvinfo *sinfo,
int flags);
where:
sd
msg
len
addrs
addrcnt
66
SCTP Socket APIs
Specifies the socket descriptor.
Specifies the message to be sent.
Specifies the length of the message.
Specifies an array of addresses.
Specifies the number of addresses in the array.
sinfo
flags
Specifies a pointer to an sctp_sndrcvinfo structure used for a
sendmsg() call.
Contains flags in the same format as the sendmsg() call flags (for example,
MSG_DONTROUTE)
This API can also be used to terminate an association using an association ID, by setting
the sinfo.sinfo_flags to MSG_EOF, and the sinfo.sinf_associd to the
association that must be terminated. In such a case, the length of the message is 0 (zero).
SCTP-Specific Socket APIs
67
68
3 Compiling and Running Applications that Use the SCTP
Socket APIs
This chapter discusses how to compile and run an application using the SCTP APIs.
SCTP offers one-to-one and one-to-many APIs. Applications can use these APIs to use
the protocol-specific features of SCTP.
The following libraries contain both the one-to-one and one-to-many APIs:
•
•
libxnet
libsctp
The libxnet library is an XOPEN library, and the libsctp library is an HP-specific
library.
This chapter addresses the following topics:
•
•
“Compiling Applications that Use the SCTP APIs” (page 69)
“Running Sample Applications that use the SCTP APIs” (page 70)
Compiling Applications that Use the SCTP APIs
Before compiling an application, ensure the following:
•
The SCTP product is installed in your system. The SCTP product is available for
download at:
http://www.software.hp.com
•
The XOPEN_SOURCE_EXTENDED macro is defined in the application program.
NOTE: If the macro is not defined in your application program, you can define
it while compiling the application.
To compile an application program that uses the SCTP APIs, enter the following
command at the HP-UX prompt:
# cc –o <output_filename> -D_XOPEN_SOURCE_EXTENDED
<input_filename> -lxnet –lsctp
where:
output_filename
-D_XOPEN_SOURCE_EXTENDED
input_filename
Specifies the executable file name.
Specifies the XOPEN macro. You need to specify
this macro while compiling only if you have not
defined it in your application program. For more
information on the XOPEN_SOURCE_EXTENDED
macro, see xopen_networking(7).
Specifies the name of the application program.
Compiling Applications that Use the SCTP APIs
69
Specifies the /usr/lib/libxnet library. This
option indicates that the application program
must use the libraries defined in this library
during compilation.
Specifies the libsctp library. This option
indicates that the application program must use
the libraries defined in this library during
compilation.
-lxnet
-lsctp
Example 3-1 Sample Commands to Compile the Server and Client Programs
Consider a server application called srv.c and a client application called cli.c.
You can use the following command to compile the server application:
# cc –o srv -D_XOPEN_SOURCE_EXTENDED srv.c -lxnet –lsctp
You can use the following command to compile the client application:
# cc –o cli -D_XOPEN_SOURCE_EXTENDED cli.c -lxnet –lsctp
Running Sample Applications that use the SCTP APIs
This section discusses how to run the sample applications that are compiled using the
SCTP APIs.
Consider the sample server and client applications listed in Appendix A (page 75) for
one-to-one and one-to-many connections. These sample applications are available in
the /usr/lib/demos/networking/sctp directory.
To run the sample server application, enter the following command:
# ./srv_app <port_number>
where:
srv_app
port_number
Specifies the executable file.
Specifies the port number on which the server accepts connections.
Example 3-2 Sample Command to Run the Server Application
To run the sample server application in a one-to-one or one-to-many connection, enter
the following command:
# ./srv_app 6000
The following output is displayed:
{one-to-one}: Waiting for associations ...
This output denotes that the server is ready to accept connections on port 6000.
To run the sample client application , enter the following command:
70
Compiling and Running Applications that Use the SCTP Socket APIs
#./cli_app <ip_address> <port_number>
where:
cli_app
ip_address
port_number
Specifies the executable file.
Specifies the IP address of the server to which the client wants to
connect.
Specifies the port number on which the server accepts connections.
NOTE: Before running the server and client applications, ensure that sctpd is running
on the system that contains the server and client applications.
To check whether sctpd is running on the system, enter the following command:
# ps –ef | grep sctpd
The following output is displayed if sctpd is running:
root 6854 25317 1 18:36:25 pts/tc 0:00 grep scptd
Example 3-3 Sample Command to Run the Client Application
To run the sample client application in a one-to-one or one-to-many connection, enter
the following command:
#./cli_app 15.70.189.135 6000
The following output is displayed:
Connected to [15.70.189.135]
<S>:
This output denotes that the client has established an association with the server on
the port 6000.
Running Sample Applications that use the SCTP APIs
71
72
4 Migrating TCP Applications to SCTP
This chapter discusses the changes required to a migrate a TCP application to SCTP.
NOTE: TCP calls, such as bind(), listen(), accept(), connect(), send(),
recv(), sendto(), recvfrom(), senmsg(), recvmsg(), work in an SCTP stack
without incorporating any changes.
To migrate TCP applications to SCTP, you must modify the following:
•
To migrate native TCP applications, such as FTP, TELNET, RLOGIN, HTTP, to SCTP,
modify the IPPROTO_TCP definition in the TCP socket call to IPPROTO_SCTP, as
follows:
socket(AF_INET, SOCK_STREAM,
IPPROTO_SCTP);
The IPPROTO_SCTP parameter is defined in the netinet/in.h header file.
NOTE: You need not explicitly mention the netinet/in.h header file in the
application, because this header file is already included in the TCP applications.
•
To enable TCP applications to use the advanced features of SCTP, such as sending
and receiving ancillary information, and receiving event notifications, TCP
applications can use the sendmsg() and recvmsg() calls. However, applications
must define the _XOPEN_SOURCE_EXTENDED macro and the /usr/lib/libxnet
library while compiling the application, because only the X/OPEN style msghdr
structure supports the ancillary mechanism.
SCTP APIs provide applications with an alternate method to read and write
ancillary information, and receive event notifications, without using the msghdr
structure. The alternate method is to use the sctp_sendmsg() and
sctp_recvmsg() calls instead of using the sendmsg() and recvmsg() calls.
These applications need not be compiled using the /usr/lib/libxnet library.
You can compile these applications using the /usr/lib/libsctp library.
Following are the benefits of migrating TCP applications to SCTP:
•
•
•
The TCP applications can avail all the advanced features of SCTP, such as
multi-streaming, multi-homing, and also avoid head-of-line blocking.
An FTP application in a TCP stack uses two sockets to send and receive data. It
uses one socket for controlling the connection and the other socket for sending or
receiving data. However, in an SCTP stack, an FTP application can use only one
socket and use two streams within the same association to achieve the same
functionality as that of TCP.
HTTP applications can use the multi-streaming feature, such as multiple queries
within the same page wherein queries can be sent in parallel.
73
74
A SCTP Sample Programs
This appendix lists the sample programs for a client and server, in both one-to-one and
one-to-many associations.
Sample Server Programs
This section lists the sample server programs in one-to-one and one-to-many
associations.
This section addresses the following topics:
• “One-to-One Server Program”
• “One-to-Many Server Program” (page 77)
One-to-One Server Program
The following sample program is an implementation of an echo server over SCTP in
a one-to-one association:
#include
#include
#include
#include
#include
#include
#include
#include
#include
<stdio.h>
<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
<stdlib.h>
<unistd.h>
<netinet/sctp.h>
<sys/uio.h>
#define BUFLEN
100
int debug=0;
static void
handle_event(void *buf)
{
struct sctp_assoc_change *sac;
struct sctp_send_failed *ssf;
struct sctp_paddr_change *spc;
struct sctp_remote_error *sre;
union sctp_notification *snp;
char addrbuf[INET6_ADDRSTRLEN];
const char *ap;
struct sockaddr_in *sin;
struct sockaddr_in6 *sin6;
snp = buf;
switch (snp->sn_header.sn_type) {
case SCTP_ASSOC_CHANGE:
sac = &snp->sn_assoc_change;
printf("^^^ assoc_change: state=%hu, error=%hu, instr=%hu "
"outstr=%hu\n", sac->sac_state, sac->sac_error,
sac->sac_inbound_streams, sac->sac_outbound_streams);
break;
case SCTP_SEND_FAILED:
ssf = &snp->sn_send_failed;
Sample Server Programs
75
printf("^^^ sendfailed: len=%hu err=%d\n", ssf->ssf_length,
ssf->ssf_error);
break;
case SCTP_PEER_ADDR_CHANGE:
spc = &snp->sn_paddr_change;
if (spc->spc_aaddr.ss_family == AF_INET) {
sin = (struct sockaddr_in *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET, &sin->sin_addr,
addrbuf, INET6_ADDRSTRLEN);
} else {
sin6 = (struct sockaddr_in6 *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET6, &sin6>sin6_addr,
addrbuf, INET6_ADDRSTRLEN);
}
printf("^^^ intf_change: %s state=%d, error=%d\n", ap,
spc->spc_state, spc->spc_error);
break;
case SCTP_REMOTE_ERROR:
sre = &snp->sn_remote_error;
printf("^^^ remote_error: err=%hu len=%hu\n",
ntohs(sre->sre_error), ntohs(sre->sre_length));
break;
case SCTP_SHUTDOWN_EVENT:
printf("^^^ shutdown event\n");
break;
default:
printf("unknown type: %hu\n", snp->sn_header.sn_type);
break;
}
}
int main(int argc, char **argv)
{
int fd, new_fd, sz, len, msg_flags;
int idleTime = 20;
struct sockaddr_in sin[1], cli_addr;
struct sctp_event_subscribe event;
char readbuf[100];
struct sctp_sndrcvinfo sri;
fd_set fdset;
if (argc < 2) {
printf ("\nUsage: <%s> \n\n", argv[0]);
return -1;
}
if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) == -1) {
perror("socket");
exit(1);
}
sin->sin_family = AF_INET;
sin->sin_port = htons(atoi(argv[1]));
sin->sin_addr.s_addr = INADDR_ANY;
if (bind(fd, (struct sockaddr *)sin, sizeof (*sin)) == -1) {
perror("bind");
exit(1);
}
/* Allow new associations to be accepted */
if (listen(fd, 1) < 0) {
76
SCTP Sample Programs
perror("listen");
exit(1);
}
memset (&sri, 0, sizeof(sri));
printf ("{one-to-one}: Waiting for associations ...\n");
FD_ZERO(&fdset);
FD_SET(fd, &fdset);
/* Wait for new associations */
while(1) {
if (select (fd+1, &fdset, 0, 0, 0) <= 0)
continue;
new_fd = accept (fd, (struct sockaddr *) &cli_addr, (socklen_t *) &le);
if (new_fd >=0 )
printf ("\n Connection from: %s\n", inet_ntoa(cli_addr.sin_addr));
/* Not interested in any events for now */
memset (&event, 0, sizeof(event));
if (setsockopt(new_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) {
perror("setevent failed");
exit(1);
}
while (1) {
/* Echo back any and all data */
memset (readbuf, 0, sizeof(readbuf));
len = sizeof (struct sockaddr_in);
#if 0
sz = recv(new_fd, readbuf, sizeof(readbuf), 0);
if (debug)
printf ("recv:[%d,e:%d]: ", sz, errno);
#endif
sz = sctp_recvmsg (new_fd, readbuf, sizeof(readbuf),
0, 0, &sri, 0);
if (debug) printf ("sctp_recvmsg:[%d,e:%d,fl:%X]: ", sz, errno, msg_flags);
if (sz <= 0)
break;
printf ("<-- %s
on str: %d\n", readbuf,
sri.sinfo_stream);
sz = sctp_sendmsg (new_fd, readbuf, sz, 0, len, 0, 0,
sri.sinfo_stream, 0, 0);
if (debug)
printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno);
}
close(new_fd);
}
/* unreachable */
close(fd);
}
One-to-Many Server Program
The following sample program is an implementation of an echo server over SCTP in
a one-to-many association:
Sample Server Programs
77
#include
#include
#include
#include
#include
#include
#include
#include
#include
<stdio.h>
<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
<stdlib.h>
<unistd.h>
<netinet/sctp.h>
<sys/uio.h>
#define BUFLEN
100
int debug=0;
static void
handle_event(void *buf)
{
struct sctp_assoc_change *sac;
struct sctp_send_failed *ssf;
struct sctp_paddr_change *spc;
struct sctp_remote_error *sre;
union sctp_notification *snp;
char addrbuf[INET6_ADDRSTRLEN];
const char *ap;
struct sockaddr_in *sin;
struct sockaddr_in6 *sin6;
snp = buf;
switch (snp->sn_header.sn_type) {
case SCTP_ASSOC_CHANGE:
sac = &snp->sn_assoc_change;
printf("^^^ assoc_change: state=%hu, error=%hu, instr=%hu "
"outstr=%hu\n", sac->sac_state, sac->sac_error,
sac->sac_inbound_streams, sac->sac_outbound_streams);
break;
case SCTP_SEND_FAILED:
ssf = &snp->sn_send_failed;
printf("^^^ sendfailed: len=%hu err=%d\n", ssf->ssf_length,
ssf->ssf_error);
break;
case SCTP_PEER_ADDR_CHANGE:
spc = &snp->sn_paddr_change;
if (spc->spc_aaddr.ss_family == AF_INET) {
sin = (struct sockaddr_in *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET, &sin->sin_addr,
addrbuf, INET6_ADDRSTRLEN);
} else {
sin6 = (struct sockaddr_in6 *)&spc->spc_aaddr;
ap = inet_ntop(AF_INET6, &sin6>sin6_addr,
addrbuf, INET6_ADDRSTRLEN);
}
printf("^^^ intf_change: %s state=%d, error=%d\n", ap,
spc->spc_state, spc->spc_error);
break;
case SCTP_REMOTE_ERROR:
sre = &snp->sn_remote_error;
printf("^^^ remote_error: err=%hu len=%hu\n",
ntohs(sre->sre_error), ntohs(sre->sre_length));
break;
case SCTP_SHUTDOWN_EVENT:
78
SCTP Sample Programs
printf("^^^ shutdown event\n");
break;
default:
printf("unknown type: %hu\n", snp->sn_header.sn_type);
break;
}
}
int main(int argc, char **argv)
{
int fd, sz, len, msg_flags;
int idleTime = 20;
struct sockaddr_in sin[1], cli_addr;
struct sctp_event_subscribe event;
char readbuf[100];
struct sctp_sndrcvinfo sri;
if (argc < 2) {
printf ("\nUsage: <%s> <port>\n\n", argv[0]);
return -1;
}
if ((fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) == -1) {
perror("socket");
exit(1);
}
sin->sin_family = AF_INET;
sin->sin_port = htons(atoi(argv[1]));
sin->sin_addr.s_addr = INADDR_ANY;
if (bind(fd, (struct sockaddr *)sin, sizeof (*sin)) == -1) {
perror("bind");
exit(1);
}
#if 0
/* Not interested in any events for now */
memset (&event, 0, sizeof(event));
#else
/* Enable all events */
event.sctp_data_io_event = 1;
event.sctp_association_event = 1;
event.sctp_address_event = 1;
event.sctp_send_failure_event = 1;
event.sctp_peer_error_event = 1;
event.sctp_shutdown_event = 1;
event.sctp_partial_delivery_event = 1;
event.sctp_adaption_layer_event = 1;
#endif
if (setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) {
perror("setevent failed");
exit(1);
}
/* Set associations to auto-close in 20 seconds of
* inactivity
*/
if (setsockopt(fd, IPPROTO_SCTP, SCTP_AUTOCLOSE,
&idleTime, 4) < 0) {
perror("setsockopt SCTP_AUTOCLOSE");
exit(1);
}
/* Allow new associations to be accepted */
Sample Server Programs
79
if (listen(fd, 1) < 0) {
perror("listen");
exit(1);
}
memset (&sri, 0, sizeof(sri));
printf ("{one-to-many}: Waiting for associations ...\n");
/* Wait for new associations */
while(1) {
/* Echo back any and all data */
memset (readbuf, 0, sizeof(readbuf));
len = sizeof (struct sockaddr_in);
sz = sctp_recvmsg (fd, readbuf, sizeof(readbuf),
&cli_addr, &len, &sri, &msg_flags);
if (debug)
printf ("sctp_recvmsg:[%d,e:%d,fl:%X]: ", sz, errno, msg_flags);
if (sz <= 0)
break;
if (msg_flags & MSG_NOTIFICATION) {
handle_event(readbuf);
continue;
}
printf ("<-- %s
on str: %d\n", readbuf, sri.sinfo_stream);
sz = sctp_sendmsg (fd, readbuf, sz, &cli_addr, len,
sri.sinfo_ppid, sri.sinfo_flags,
sri.sinfo_stream, 0, 0);
if (debug)
printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno);
}
close(fd);
}
Sample Client Programs
This section lists the sample client programs for both one-to-one and one-to-many
associations.
This section addresses the following topics:
• “One-to-One Client Program”
• “One-to-Many Client Program” (page 82)
One-to-One Client Program
The following sample program is an implementation of an echo client over SCTP in a
one-to-one association:
#include
#include
#include
#include
#include
#include
#include
#include
#include
80
<stdio.h>
<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
<stdlib.h>
<unistd.h>
<netinet/sctp.h>
<sys/uio.h>
SCTP Sample Programs
int debug=0;
int main(argc, argv)
int argc;
char **argv;
{
int sock_fd, sz, len, msg_flags;
int idleTime = 2;
struct sockaddr_in sin[1], serv_addr;
struct sctp_event_subscribe event;
char buf[256];
struct sctp_sndrcvinfo sri;
if (argc < 3) {
printf ("\nUsage: <%s> <remote-ip> <port>
return -1;
}
\n\n", argv[0]);
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons (atoi(argv[2]));
serv_addr.sin_addr.s_addr = inet_addr(argv[1]);
sock_fd = socket (AF_INET, SOCK_STREAM, IPPROTO_SCTP);
if (sock_fd == -1) {
printf ("\nUnable to create socket \n");
return -1;
}
if (connect (sock_fd, (struct sockaddr *) &serv_addr,
sizeof(serv_addr)) < 0) {
printf ("\nUnable to connect to remote server [%s] !! \n\n",
inet_ntoa(serv_addr.sin_addr));
return -1;
} else {
printf ("\nConnected to [%s]\n", inet_ntoa(serv_addr.sin_addr));
}
memset (&event, 0, sizeof(event));
if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS,
&event, sizeof(event)) != 0) {
perror("setevent failed");
exit(1);
}
memset (buf, 0, sizeof(buf));
len = sizeof(serv_addr);
printf ("<S>: ");
while (fgets(buf, 256, stdin)) {
if (buf[0] != '[') {
if (!strncmp(buf, "exit", 4))
Sample Client Programs
81
break;
printf ("Error, line must be of the form '[stream#]text'\n");
continue;
}
sri.sinfo_stream = strtol(buf+1, NULL, 0);
sz = strlen(buf);
len = sizeof(serv_addr);
sz = sctp_sendmsg (sock_fd, buf, sz, 0, len, 0, 0,
sri.sinfo_stream, 0, 0);
if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno);
if (sz <= 0)
break;
sz = sctp_recvmsg (sock_fd, buf, sizeof(buf),
0, 0, &sri, &msg_flags);
if (debug) printf ("sctp_recvmsg:[%d,e:%d] ", sz, errno);
if (sz <= 0)
break;
printf ("<-- %s on str %d\n", buf, sri.sinfo_stream);
memset (buf, 0, sizeof(buf));
printf ("<S>: ");
}
printf ("\nOver !!\n");
close (sock_fd);
return 0;
}
One-to-Many Client Program
The following sample program is an implementation of an echo client over SCTP in a
one-to-one association:
#include
#include
#include
#include
#include
#include
#include
#include
#include
<stdio.h>
<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
<stdlib.h>
<unistd.h>
<netinet/sctp.h>
<sys/uio.h>
int debug=0;
int main(argc, argv)
int argc;
char **argv;
82
SCTP Sample Programs
{
int sock_fd, sz, len, msg_flags;
int idleTime = 2;
struct sockaddr_in sin[1], serv_addr;
struct sctp_event_subscribe event;
char buf[256];
struct sctp_sndrcvinfo sri;
if (argc < 3) {
printf ("\nUsage: <%s> <remote-ip> <port> \n\n", argv[0]);
return -1;
}
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons (atoi(argv[2]));
serv_addr.sin_addr.s_addr = inet_addr(argv[1]);
sock_fd = socket (AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
if (sock_fd == -1) {
printf ("\nUnable to create socket \n");
return -1;
}
if (connect (sock_fd, (struct sockaddr *) &serv_addr,
sizeof(serv_addr)) < 0) {
printf ("\nUnable to connect to remote server [%s] !! \n\n",
inet_ntoa(serv_addr.sin_addr));
return -1;
} else {
printf ("\nConnected to [%s]\n", inet_ntoa(serv_addr.sin_addr));
}
memset (&event, 0, sizeof(event));
if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS,
&event, sizeof(event)) != 0) {
perror("setevent failed");
exit(1);
}
memset (buf, 0, sizeof(buf));
len = sizeof(serv_addr);
printf ("<S>: ");
while (fgets(buf, 256, stdin)) {
if (buf[0] != '[') {
if (!strncmp(buf, "exit", 4))
break;
printf ("Error, line must be of the form '[stream#]text'\n");
continue;
}
sri.sinfo_stream = strtol(buf+1, NULL, 0);
sz = strlen(buf);
Sample Client Programs
83
len = sizeof(serv_addr);
sz = sctp_sendmsg (sock_fd, buf, sz, &serv_addr, len, 0, 0,
sri.sinfo_stream, 0, 0);
if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno);
sz = sctp_recvmsg (sock_fd, buf, sizeof(buf),
&serv_addr, &len, &sri, &msg_flags);
if (debug) printf ("sctp_recvmsg:[%d,e:%d] ", sz, errno);
if (sz <= 0)
break;
printf ("<-- %s on str %d\n", buf, sri.sinfo_stream);
memset (buf, 0, sizeof(buf));
printf ("<S>: ");
}
printf ("\nOver !!\n");
close (sock_fd);
return 0;
}
84
SCTP Sample Programs
Glossary
Bundling
An optional multiplexing operation, where more than one user message can be carried in the
same SCTP packet. Each user message occupies its own DATA chunk.
Chunk
A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific
content.
Congestion
Window
An SCTP variable that limits the data (in bytes) that a sender can send to a particular destination
transport address before receiving an acknowledgement.
Maximum
Transmission
Unit
The Maximum Transmission Unit (MTU) determines the maximum size of the packet that is
supported by a communications protocol.
Message
Data submitted to SCTP by the Upper Layer Protocol (ULP).
Path
The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport
address of its peer SCTP endpoint
Receiver
Window
An SCTP variable that a sender uses to store the most recently calculated receiver window (in
bytes) of its peer. The value of rwnd indicates the space available in the receiver's inbound buffer.
SCTP
association
A protocol relationship between two SCTP endpoints. The association also contains the protocol
state information that includes verification tags and the currently active set of TSNs. An association
can be uniquely identified by the transport addresses used by the endpoints in the association.
SCTP
endpoint
The logical sender or receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is
represented to its peers as a combination of a set of eligible destination transport addresses to
which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP
packets can be received. All transport addresses used by an SCTP endpoint must use the same
port number but the endpoint can use multiple IP addresses. A transport address is unique to an
SCTP endpoint. Therefore, a transport address used by an SCTP endpoint must not be used by
another SCTP endpoint.
SCTP packet
The unit of data delivery across the interface between SCTP and the connectionless packet network
(for example, IP). An SCTP packet contains the common SCTP header, possible SCTP control
chunks, and user data encapsulated within SCTP DATA chunks.
Slow Start
Threshold
An SCTP variable. This is the threshold (in bytes) that the endpoint uses to determine whether
to perform slow start or congestion avoidance on a particular destination transport address.
Stream
A uni-directional logical channel established from one to another associated SCTP endpoint,
within which all user messages are delivered in sequence except for those submitted to the
unordered delivery service.
Stream
Sequence
Number
A 16-bit sequence number used by SCTP to assure sequenced delivery of the user messages within
a given stream. One stream sequence number is attached to each user message.
Transmission
Control Block
The transmission control block (TCB) is an internal data structure created by an SCTP endpoint
for each SCTP association. TCB contains the status and operational information for the endpoint
to maintain and manage the association.
Transmission
Sequence
Number
The transmission sequence number (TSN) is a 32-bit sequence number used by SCTP. One TSN
is attached to each chunk containing user data to permit the receiving SCTP endpoint to
acknowledge its receipt and detect duplicate deliveries.
Transport
address
A transport address is defined by the network layer address, the transport layer protocol, and
the transport layer port number. In the case of SCTP running over IP, a transport address is
85
defined by the combination of an IP address and an SCTP port number (where SCTP is the
transport protocol).
Unordered
Message
Unordered messages are "unordered" with respect to any other message, this includes both other
unordered and ordered messages. Unordered message can be delivered before or later than
ordered messages sent on the same stream.
Verification
Tag
A 32-bit unsigned integer that is randomly generated. The verification tag provides a key that
allows a receiver to verify that the SCTP packet belongs to the current association and is not an
old or stale packet from a previous association.
86
Glossary
Index
Symbols
D
-lsctp library, 70
-lxnet library, 70
/usr/lib/libsctp library, 73
/usr/lib/libxnet library, 70, 73
D_XOPEN_SOURCE_EXTENDED macro, 69
data boundaries, 31
DATA chunk, 24, 37
default stream
in SCTP, 55
delayed acknowledgement, 32
denial of service attack (see DoS)
difference in TCP and SCTP, 46
disabling receive operation
at an endpoint, 46
disabling send operation
at an endpoint, 46
DoS, 19
preventing, 21
A
ABORT chunk, 25, 32
achieving half-closed state
in SCTP, 46
ACK packet, 22
acknowledge packet (see ACK packet)
addrcnt parameter, 62
address length (see addrlen)
address size (see tolen)
addrlen, 45
addrs parameter, 61, 62
alternate IP address, 29
ancillary data structure (see sctp_initmsg structure) (see
sctp_sndrcvinfo)
associating an endpoint, 44
B
backlog, 51
of outstanding associations, 45
blind masquerade attack, 39
branched off socket, 56
branching an association, 62
socket descriptor, 62
buffer size, 53, 55
E
enabling multihoming, 44
endpoint failure, 38
EOPNOTSUPP error, 51
ERROR chunk, 25
ESTABLISHED state, 45
existing socket APIs, 41
F
four-way handshake, 22, 38
overcome delay, 23
four-way initiation handshake, 45
freeing resources, 63, 64
fromlen paremeter, 55
C
G
changing outbound streams
number of (see SCTP_INITMSG)
chunk data, 25
chunk flag, 25
chunk length, 25
cmsghdr structure, 58
congestion window, 26
control chunk
information, 24
COOKIE ACK chunk, 24
COOKIE ECHO chunk, 24
cookie field, 22
COOKIE-ACK chunk, 23
COOKIE-ECHO chunk, 22
creating a socket, 43, 49
cwnd variable, 26
gap
in transmission sequence, 30
getsockopt() call, 53
getting control information (see scto_sndrcvinfo structure)
gracefully closing
an association, 46
H
half-closed state
in TCP, 46
half-open connection, 31
head-of-line blocking (see HOL)
HEARTBEAT ACK chunk, 25
HEARTBEAT chunk, 25, 38
HOL, 19, 30
HP-specific library (see libsctp)
87
I
O
IN6ADDR_ANY option, 46
IN6ADDR_ANY_INIT option, 44
INADDR_ANY option, 44, 46
INIT ACK chunk, 24
INIT chunk, 24
INIT-ACK chunk, 22
Initiate tag, 39
initiating an association, 45
IP stack
application layer, 21
data link layer, 20
network layer, 20
physical layer, 20
socket layer, 21
transport layer
SCTP, 20
IPPROTO_SCTP, 53
IPPROTO_SCTP parameter, 44
IPPROTO_SCTP value, 56
one-to-many client
call sequence, 49
one-to-one client
call sequence, 43
optlen, 53
buffer size, 53
optlen parameter, 56
optname, 53
optname parameter, 53, 56
optval, 53
optval paremeter, 53, 56
P
libsctp library, 69
libxnet library, 69
partial bytes acknowledged, 27
partial_byte_acked variable, 27
passing data
into the SCTP stack (see sctp_opt_info() call)
payload data chunk, 24
PF_INET parameter, 43
PF_INET6 parameter, 43
preparing an endpoint
for accepting associations, 45
primary address, 29
M
R
maximum transmission unit (see MTU)
message buffer, 55
message size, 55
migrate
existing TCP application, 42
migrating TCP applications
to SCTP,
benefits of, 73
MSG_ABORT flag, 52
msg_control parameter, 47
msg_controllen parameter, 47
MSG_EOF flag, 52
msg_flags parameter, 47
msg_iov parameter, 47, 57
msg_iovlen parameter, 47
msg_name parameter, 47
msg_namelen parameter, 47
MSG_NOTIFICATION flag, 57
msghdr structure, 47
MTU, 25
multihoming, 42
enabling, 44
overcoming network failure, 29
overcoming path failure, 29
multistreaming, 42
avoid HOL blocking, 30
receiver window, 26
receiving data, 47
receiving messages, 65
removing an association
from the accept queue, 45
retransmission timeout (see RTO)
retrieving a socket, 48
retrieving socket option, 53
RFC 2581, 26
RFC 2960, 25
RTO, 37
rwnd variable, 26
L
N
new_sd parameter, 45
88
Index
S
SACK chunk, 24, 37
SCTP
COOKIE-ACK chunk, 23
COOKIE-ECHO chunk, 22
data boundaries, 31
default stream, 31
definition, 17
draft compliance, 18
four-way handshake, 22
INIT chunk, 22
INIT-ACK chunk, 22
RFC compliance, 18
SCTP notification structure, 57
SCTP packet
chunk type, 24
common header, 24
control chunk, 24
DATA chunk, 24
SID, 24
SCTP_ASSOC_CHANGE event, 51
SCTP_AUTOCLOSE option, 49
SCTP_EVENTS option, 65
SCTP_INITMSG option, 45
sctp_initmsg structure, 59
sctp_notification structure, 57
sctp_opt_info() call, 54
SCTP_SNDRCV option, 64, 65
sctp_sndrcvinfo structure, 60
selecting peer address (see sockaddr_storage)
setsockoptg() call, 57
setting control information (see scto_sndrcvinfo structure)
setting socket option, 53
SHUT_RD parameter, 46
SHUT_RDWR parameter, 46
SHUT_WR parameter, 46
shutdown
types of, 46
SHUTDOWN ACK chunk, 25
SHUTDOWN chunk, 25
SHUTDOWN COMPLETE chunk, 25
shutdown() call
difference in SCTP and TCP, 46
SID, 24, 30
sinfo.sinf_associd flag, 66
sinfo.sinfo_flags flag, 66
single-homed connection, 28
slow start threshold variable, 26
SO_LINGER option, 56
SOCK_SEQPACKET parameter, 50
SOCK_STREAM parameter, 44
sockaddr_in structure, 44, 50, 62
sockaddr_in6 strcuture, 44
sockaddr_in6 structure, 50, 62
sockaddr_storage, 53
socket descriptor
creating, 43
for new association (see new_sd)
specifying local address, 50
specifying multiple addresses, 65
specifying protocol level (see IPPROTO_SCTP)
SSN, 24, 30
Stream Control Transmission Protocol (see SCTP)
stream identifier (see SID)
stream sequence number (see SSN)
SYN packet, 22
SYN-ACK packet, 22
SYN-flooding, 17
Synchronize packet (see SYN packet)
synchronize-acknowledge packet (see SYN-ACK packet)
ACK packet, 22
data boundaries, 31
half-open connection , 31
single-homed connection, 28
SYN flood attack, 19
SYN packet, 22
SYN-ACK packet, 22
the PUSH flag, 19
three-way handshake, 21
time-to-live (see TTL)
tolen parameter, 55
transmission control block (see TCB)
Transmission Control Protocol (see TCP)
transmission sequence number (see TSN)
transmitting data, 47
to a peer, 55
TSN, 24, 30
TTL, 60, 64
U
unordered bit, 25
User Datagram Protocol (see UDP)
V
verification tag, 22
X
XOPEN library (see see libxnet library)
XOPEN macro (see D_XOPEN_SOURCE_EXTENDED)
XOPEN_SOURCE_EXTENDED macro, 69
T
TCB, 38
TCP
89
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement