Sctp

SCTP Programmer's Guide HP-UX 1 v2 1i HP Part Number: 5992-0620 Published: September 2007 Edition: 1

© Copyright 2007 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

List of Figures 1-1 The Internet Protocol Stack.........................................................................................20 1-2 Three-Way Handshake in TCP....................................................................................21 1-3 Four-Way Handshake in SCTP...................................................................................22 1-4 SCTP Packet Format....................................................................................................23 1-5 A Single-Homed Connection......................................................................................29 1-6 A Multihomed Connection.........................................................................................29 1-7 Multistreaming in an SCTP Association.....................................................................31 1-8 Shutdown in TCP and SCTP.......................................................................................32 7

List of Tables 1-1 Chunk Types...............................................................................................................24 1-2 Comparison Between SCTP, TCP, and UDP...............................................................27 2-1 Data Structures in the recvmsg() and sendmsg() Calls...............................................60 9

List of Examples 3-1 Sample Commands to Compile the Server and Client Programs...............................70 3-2 Sample Command to Run the Server Application......................................................70 3-3 Sample Command to Run the Client Application......................................................71 11

About This Document This document describes how to write, compile, and run applications using Stream Control Transmission Protocol (SCTP) socket APIs on systems running HP-UX 11i v2. 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 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 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 Chapter 3 (page 69) describes how to compile and run applications that use the SCTP APIs. Chapter 4 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) 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). Book Title 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 KeyCap to the same key. Emphasis Text that is emphasized. Emphasis Text that is strongly emphasized. Term The defined use of an important word or phrase. Text displayed by the computer. ComputerOut Commands and other text that you type. UserInput A command name or qualified command phrase. Command The name of a variable that you may replace in a command or Variable 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 About This Document

— 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: feedback@fc.hp.com 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

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: • 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 18 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: • 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 20 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. Host A sends a Synchronize (SYN) packet to Host B. 2. Upon receiving the SYN packet, Host B allocates resources for the connection and sends a Synchronize-Acknowledge (SYN-ACK) packet to Host A. 3. 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. Host A initiates an association by sending an INIT packet to Host B. 2. 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. 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 22 Introduction

COOKIE-ECHO packet. As a result, the conversation ends without the server allocating any resources for the connection. 4. 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 Chunk Definition Used for data transfer. Payload Data (DATA) Initiates an SCTP association between two Initiation (INIT) endpoints. Initiation Acknowledgement ( Acknowledges the receipt of an INIT chunk. The receipt of the INIT ACK chunk establishes INIT ACK) an association. Selective Acknowledgement Acknowledges the receipt of the DATA chunks (SACK) and also reports gaps in the data. Used during the initiation process. The Cookie Echo (COOKIE ECHO) endpoint initiating the association sends the COOKIE ECHO chunk to the peer endpoint. Cookie Acknowledgement Acknowledges the receipt of the COOKIE (COOKIE ACK) 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 24 Introduction

Table 1-1 Chunk Types (continued) Chunk Definition Heartbeat Request ( Tests the connectivity of a specific destination address in the association. HEARTBEAT) Heartbeat Acknowledgement ( Acknowledges the receipt of the HEARTBEAT chunk. HEARTBEAT ACK) Informs the peer endpoint to close the Abort Association (ABORT) 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 ( Triggers a graceful shutdown of an association with a peer endpoint. SHUTDOWN) Shutdown Acknowledgement Acknowledges the receipt of the SHUTDOWN (SHUTDOWN ACK) chunk at the end of the shutdown process. Shutdown Complete ( Concludes the shutdown procedure. SHUTDOWN COMPLETE) Chunk Flag 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. Chunk Length This field represents the size of the fields chunk type, chunk flag, chunk length, and chunk value, in bytes. Chunk Data 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: Specifies the limit on the amount of data the Congestion window (cwnd) 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 Receiver window (rwnd) outstanding data. NOTE: The minimum value of the cwnd and rwnd variables determine the amount of data transmission. Determines whether the slow start or congestion Slow start threshold (ssthresh) avoidance algorithm must be used to control data transmission. 26 Introduction

Partial Bytes Acknowledged Adjusts of the cwnd parameter. (partial_byte_acked) 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 no1 State required at each endpoint yes yes Reliable data transfer yes yes no Congestion control and avoidance yes yes no no2 Message boundary conservation yes yes yes2 Path MTU discovery and message fragmentation yes no yes2 Message bundling yes 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 yes no no Security cookie against SYN flood attack no3 Built-in heartbeat (reachability check) yes 1 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. 2 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. 3 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 quot;primaryquot; 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 quot;half-openquot; 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: • 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 32 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 The ASCONF chunk communicates the Chunk (ASCONF) configuration change requests that must be acknowledged, to the remote endpoint. Address Configuration The ASCONF-ACK chunk is used by the receiver Acknowledgment (ASCONF-ACK) 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 This is an optional parameter in the INIT and parameter 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 Forward Cumulative TSN The receiver sends this chunk to a sender to inform its support for PR-SCTP. An SCTP sender (FORWARD TSN) chunk 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: • Include the Forward-TSN-Supported parameter in INIT-ACK. • Record the information that the peer does not support the FORWARD TSN chunk. 36 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

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. socket() 2. bind() or sctp_bindx() 3. sctp_getladdrs() 4. sctp_freeladdrs 5. listen() 6. 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. sctp_getpaddrs() 8. sctp_freepaddrs 9. recv() or recvmsg() 10. send() or sctp_sendx() or sctp_send() 11. 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: Specifies the IPv4 domain. PF_INET Specifies the IPv6 domain. PF_INET6 Different Socket API Styles 43

SOCK_STREAM Indicates the creation of a one-to-one style socket. IPPROTO_SCTP 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: Represents the socket descriptor returned by the socket() call. sd Represents the address structure (struct sockaddr_in or struct addr sockaddr_in6). Represents the size of the address structure. addrlen 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: Represents the socket descriptor of the SCTP endpoint. sd Represents the maximum number of outstanding associations allowed in backlog 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: Represents the socket descriptor for the newly formed association. new_sd Represents the listening socket descriptor. sd Contains the primary address of the peer endpoints. addr Specifies the size of addr. addrlen 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: Represents the socket descriptor of the endpoint. sd Represents the address of the peer. addr Represents the size of the address. addrlen 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: Represents the socket descriptor of the association to be closed. sd 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); Specifies the socket descriptor of the association that needs to be closed. sd Specifies the type of shutdown. The values are as follows: how 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: Represents the socket descriptor of the endpoint. sd Specifies the pointer to the msghdr structure that contains a single user message 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: Specifies the pointer to the socket address structure. msg_name Specifies the size of the socket address structure. msg_namelen Includes an array of message buffers. msg_iov Specifies the number of elements in the msg_iov msg_iovlen structure. Specifies the ancillary data. msg_control Specifies the length of the ancillary data buffer. msg_controllen Specifies the flags on the received message. msg_flags For more information on the msghdr, see RFC 2292 (Advanced Sockets API for IPv6). Contains flags that affect the messages being sent or received flags 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: Specifies the socket descriptor to be queried. sd Contains the primary peer address. If the socket is an IPv4 socket, the address 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. len 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. socket() 2. bind() or sctp_bindx() 3. sctp_getladdrs() 4. sctp_freeladdrs() 5. listen() 6. sctp_getpaddrs() 48 SCTP Socket APIs

7. sctp_setpaddrs() 8. recvmsg() or sctp_recvmsg() 9. sendmsg() or sctp_sendmsg() 10. sctp_peeloff() 11. 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. socket() 2. sendmsg() or sctp_sendmsg() 3. recvmsg() or sctp_recvmsg() 4. 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: Indicates the creation of a one-to-one or one-to-many style SOCK_SEQPACKET socket. Specifies the type of the protocol. IPProto_SCTP Specifies the IPv4 domain. PF_INET Specifies the IPv6 domain. PF_INET6 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: Represents the socket descriptor returned by the socket() call. sd addr Represents the address structure (struct sockaddr_in or struct sockaddr_in6). Represents the size of the address structure. addrlen 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: Specifies the socket descriptor of the endpoint. sd Defines the number of connections in the listen queue. backlog 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: Specifies the socket descriptor. sd Specifies the pointer to the msghdr structure, which contains a single user message message and the ancillary data. Contains flags that affect messages that are being sent and received. flags 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: Specifies the socket descriptor of the associations to be closed. sd 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: Specifies the socket descriptor for a new association. sd Specifies the size of the address. len 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: Indicates the file descriptor. s Specifies the type of protocol. You must set the level to IPPROTO_SCTP level for all the SCTP options. Specifies the option name. optname Specifies the buffer to store the value of the option. optval Specifies the size of the buffer (or the length of the option returned). optlen Following is the syntax for the setsockopt() API: int setsockopt( int s, int level, int optname, const void *optval, int optlen ); where: Indicates the file descriptor. s Specifies the type of protocol. You must set the level to IPPROTO_SCTP level for all SCTP options. Specifies the option name. optname Specifies the buffer to store the value of the option. optval Specifies the size of the buffer (or the length of the option returned). optlen 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: Specifies the association ID. For a one-to-many style socket, id specifies the id 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 opt 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. Specifies an option-specific structure buffer that is provided by an application. arg 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: Specifies the socket descriptor of an SCTP endpoint. sd Specifies the message to be sent. msg Specifies the size of the message or the size of buffer. len Specifies one of the peer addresses of the association to be used to send to the message. Specifies the size of the address. tolen Specifies the buffer to store a received message. buf Specifies the buffer to store the peer address used to send the received from message. Specifies the size of the from address. fromlen Contains flags affecting the message being sent. flags 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: Specifies the socket description. sd Specifies the type of protocol. You must set the level to IPPROTO_SCTP level for all SCTP options. Specifies the option name. optname Specifies the buffer to store the value of the option. optval Specifies the size of the buffer (or the length of the option returned). optlen 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: Specifies the socket descriptor to be queried. sd Stores the locally bound address that is selected by the SCTP stack. If the address 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. len 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; /* Notification type. */ uint16_t sn_flags; uint32_t sn_length; } sn_header; struct sctp_assoc_change sn_assoc_change; struct sctp_paddr_change sn_paddr_change; struct sctp_remote_error sn_remote_error; struct sctp_send_failed sn_send_failed; struct sctp_shutdown_event sn_shutdown_event; struct sctp_adaption_event sn_adaption_event; struct sctp_pdapi_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: Specifies the number of bytes, including the header. cms_len Specifies the originating protocol. cmsg_level Specifies the type of the protocol followed by an unsigned character, cmsg_type 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: Represents the number of outbound streams. sinit_num_ostreams Represents the number of inbound streams to be sinit_num_ostreams supported. Represents the maximum number of times INIT must sinit_max_instreams be transmitted before giving up an association setup. Represents the largest time out value to use in sinit_max_init_timeo 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() Specifies the stream number of the Specifies the stream number to which the sinfo_stream message. application wants to send the message. Contains the stream sequence number Not applicable sinfo_ssn in the DATA chunk. Specifies the information that is passed Specifies an opaque unsigned value that sinfo_ppid by the upper layer in the peer is passed to the remote endpoint in each application. user message. Not applicable Specifies an opaque context data that is sinfo_context passed back to the application while reporting an error on the concerned sendmsg() call. Specifies the flag that controls the send Specifies the flag (MSG_UNORDRED) to sinfo_flags behavior of the data chunk, or the inform the application that the message association itself. For example, received was unordered. The sendmsg() contains the MSG_UNORDRED recvmsg() API contains only one flag flag to indicate unordered send of data, (MSG_UNORDRED), whereas the and MSG_EOF to close a given sendmsg() API contains multiple flags. association. sinfo_timetolive Not applicable 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. 60 SCTP Socket APIs

Table 2-1 Data Structures in the recvmsg() and sendmsg() Calls (continued) Variable recvmsg() sendmsg() Specifies the transmission sequence Not applicable sinfo_tsn number (TSN) assigned to one of the SCTP data chunks. Specifies the cumulative TSN, while Not applicable sinfo_cumtsn presenting an unordered message (if the MSG_UNORDRED flag is set) Specifies the association ID. Specifies the association ID. sinfo_assoc_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: Specifies the socket descriptor. If sd is an IPv4 socket, the addresses passed sd 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 addrs 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 addrcnt sockaddr_in). You cannot use wildcard addresses with sctp_bindx(). Contains flags affecting the message that is being sent. The flags parameter flags is formed from the bitwise OR of zero or more of the following flags: • SCTP_BINDX_ADD_ADDR • SCTP_BINDX_REM_ADDR 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: Specifies the socket descriptor representing the branched-off association. sd Specifies the identifier of the association that must be branched off to a assoc_id 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: Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned sd 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 id association to query. An application ignores id for one-to-one style sockets. Points to the dynamically allocated array of sockaddr structures of the addrs appropriate socket type. An application must use the sctp_freepaddrs() call to free the memory. 62 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: Specifies the array of peer addresses returned by sctp_getpaddrs(). addrs 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: Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned will sd 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 id 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 ss 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: Specifies the array of peer addresses returned by the sctp_getladdrs() addrs 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: Specifies the socket descriptor. sd Specifies the message to be sent. msg Specifies the length of the message. len Specifies the destination address of the message. to Specifies the length of the destination address. tolen Specifies the payload protocol identifier, which is entered in the ppid payload protocol identifier field of the SCTP data header. Contains flags affecting the message being sent. flags Contains the stream number of the message. stream_no Specifies the TTL value for a message in milliseconds. timetolive Specifies a 32-bit unsigned integer that is used by sendmsg(). When context 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. 64 SCTP Socket APIs

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: Specifies the socket descriptor. sd Specifies a message buffer. msg Specifies the length of the message buffer. len Specifies the sender of a message. from Specifies the length of the address. fromlen Denotes a pointer to an sctp_sndrcvinfo structure that is filled after sinfo the message is received. Denotes a pointer to an integer to be filled with a message flag. msg_flags 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: Specifies the socket descriptor. sd Specifies an array of addresses. addrs Specifies the number of addresses in the array. addrcnt 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: Specifies the socket descriptor. sd Specifies the message to be sent. msg Specifies the length of the message. len Specifies a pointer to a sctp_sndrcvinfo structure that is used for a sinfo sendmsg() call. flags 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: Specifies the socket descriptor. sd Specifies the message to be sent. msg Specifies the length of the message. len Specifies an array of addresses. addrs Specifies the number of addresses in the array. addrcnt 66 SCTP Socket APIs

Specifies a pointer to an sctp_sndrcvinfo structure used for a sinfo sendmsg() call. flags 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

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: Specifies the executable file name. output_filename Specifies the XOPEN macro. You need to specify -D_XOPEN_SOURCE_EXTENDED 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. input_filename Compiling Applications that Use the SCTP APIs 69

Specifies the /usr/lib/libxnet library. This -lxnet option indicates that the application program must use the libraries defined in this library during compilation. Specifies the libsctp library. This option -lsctp indicates that the application program must use the libraries defined in this library during compilation. 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: Specifies the executable file. srv_app Specifies the port number on which the server accepts connections. port_number 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: Specifies the executable file. cli_app Specifies the IP address of the server to which the client wants to ip_address connect. Specifies the port number on which the server accepts connections. port_number 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

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

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 <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdlib.h> #include <unistd.h> #include <netinet/sctp.h> #include <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(quot;^^^ assoc_change: state=%hu, error=%hu, instr=%hu quot; quot;outstr=%hunquot;, 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(quot;^^^ sendfailed: len=%hu err=%dnquot;, 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(quot;^^^ intf_change: %s state=%d, error=%dnquot;, ap, spc->spc_state, spc->spc_error); break; case SCTP_REMOTE_ERROR: sre = &snp->sn_remote_error; printf(quot;^^^ remote_error: err=%hu len=%hunquot;, ntohs(sre->sre_error), ntohs(sre->sre_length)); break; case SCTP_SHUTDOWN_EVENT: printf(quot;^^^ shutdown eventnquot;); break; default: printf(quot;unknown type: %hunquot;, 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 (quot;nUsage: <%s> nnquot;, argv[0]); return -1; } if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) == -1) { perror(quot;socketquot;); 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(quot;bindquot;); exit(1); } /* Allow new associations to be accepted */ if (listen(fd, 1) < 0) { 76 SCTP Sample Programs

perror(quot;listenquot;); exit(1); } memset (&sri, 0, sizeof(sri)); printf (quot;{one-to-one}: Waiting for associations ...nquot;); 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 (quot;n Connection from: %snquot;, 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(quot;setevent failedquot;); 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 (quot;recv:[%d,e:%d]: quot;, sz, errno); #endif sz = sctp_recvmsg (new_fd, readbuf, sizeof(readbuf), 0, 0, &sri, 0); if (debug) printf (quot;sctp_recvmsg:[%d,e:%d,fl:%X]: quot;, sz, errno, msg_flags); if (sz <= 0) break; printf (quot;<-- %s on str: %dnquot;, readbuf, sri.sinfo_stream); sz = sctp_sendmsg (new_fd, readbuf, sz, 0, len, 0, 0, sri.sinfo_stream, 0, 0); if (debug) printf (quot;sctp_sendmsg:[%d,e:%d]nquot;, 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 <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdlib.h> #include <unistd.h> #include <netinet/sctp.h> #include <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(quot;^^^ assoc_change: state=%hu, error=%hu, instr=%hu quot; quot;outstr=%hunquot;, 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(quot;^^^ sendfailed: len=%hu err=%dnquot;, 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(quot;^^^ intf_change: %s state=%d, error=%dnquot;, ap, spc->spc_state, spc->spc_error); break; case SCTP_REMOTE_ERROR: sre = &snp->sn_remote_error; printf(quot;^^^ remote_error: err=%hu len=%hunquot;, ntohs(sre->sre_error), ntohs(sre->sre_length)); break; case SCTP_SHUTDOWN_EVENT: 78 SCTP Sample Programs

printf(quot;^^^ shutdown eventnquot;); break; default: printf(quot;unknown type: %hunquot;, 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 (quot;nUsage: <%s> <port>nnquot;, argv[0]); return -1; } if ((fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) == -1) { perror(quot;socketquot;); 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(quot;bindquot;); 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(quot;setevent failedquot;); exit(1); } /* Set associations to auto-close in 20 seconds of * inactivity */ if (setsockopt(fd, IPPROTO_SCTP, SCTP_AUTOCLOSE, &idleTime, 4) < 0) { perror(quot;setsockopt SCTP_AUTOCLOSEquot;); exit(1); } /* Allow new associations to be accepted */ Sample Server Programs 79

if (listen(fd, 1) < 0) { perror(quot;listenquot;); exit(1); } memset (&sri, 0, sizeof(sri)); printf (quot;{one-to-many}: Waiting for associations ...nquot;); /* 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 (quot;sctp_recvmsg:[%d,e:%d,fl:%X]: quot;, sz, errno, msg_flags); if (sz <= 0) break; if (msg_flags & MSG_NOTIFICATION) { handle_event(readbuf); continue; } printf (quot;<-- %s on str: %dnquot;, 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 (quot;sctp_sendmsg:[%d,e:%d]nquot;, 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 <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdlib.h> #include <unistd.h> #include <netinet/sctp.h> #include <sys/uio.h> 80 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 (quot;nUsage: <%s> <remote-ip> <port> nnquot;, 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_STREAM, IPPROTO_SCTP); if (sock_fd == -1) { printf (quot;nUnable to create socket nquot;); return -1; } if (connect (sock_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) { printf (quot;nUnable to connect to remote server [%s] !! nnquot;, inet_ntoa(serv_addr.sin_addr)); return -1; } else { printf (quot;nConnected to [%s]nquot;, inet_ntoa(serv_addr.sin_addr)); } memset (&event, 0, sizeof(event)); if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror(quot;setevent failedquot;); exit(1); } memset (buf, 0, sizeof(buf)); len = sizeof(serv_addr); printf (quot;<S>: quot;); while (fgets(buf, 256, stdin)) { if (buf[0] != '[') { if (!strncmp(buf, quot;exitquot;, 4)) Sample Client Programs 81

break; printf (quot;Error, line must be of the form '[stream#]text'nquot;); 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 (quot;sctp_sendmsg:[%d,e:%d]nquot;, sz, errno); if (sz <= 0) break; sz = sctp_recvmsg (sock_fd, buf, sizeof(buf), 0, 0, &sri, &msg_flags); if (debug) printf (quot;sctp_recvmsg:[%d,e:%d] quot;, sz, errno); if (sz <= 0) break; printf (quot;<-- %s on str %dnquot;, buf, sri.sinfo_stream); memset (buf, 0, sizeof(buf)); printf (quot;<S>: quot;); } printf (quot;nOver !!nquot;); 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 <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdlib.h> #include <unistd.h> #include <netinet/sctp.h> #include <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 (quot;nUsage: <%s> <remote-ip> <port> nnquot;, 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 (quot;nUnable to create socket nquot;); return -1; } if (connect (sock_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) { printf (quot;nUnable to connect to remote server [%s] !! nnquot;, inet_ntoa(serv_addr.sin_addr)); return -1; } else { printf (quot;nConnected to [%s]nquot;, inet_ntoa(serv_addr.sin_addr)); } memset (&event, 0, sizeof(event)); if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror(quot;setevent failedquot;); exit(1); } memset (buf, 0, sizeof(buf)); len = sizeof(serv_addr); printf (quot;<S>: quot;); while (fgets(buf, 256, stdin)) { if (buf[0] != '[') { if (!strncmp(buf, quot;exitquot;, 4)) break; printf (quot;Error, line must be of the form '[stream#]text'nquot;); 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 (quot;sctp_sendmsg:[%d,e:%d]nquot;, sz, errno); sz = sctp_recvmsg (sock_fd, buf, sizeof(buf), &serv_addr, &len, &sri, &msg_flags); if (debug) printf (quot;sctp_recvmsg:[%d,e:%d] quot;, sz, errno); if (sz <= 0) break; printf (quot;<-- %s on str %dnquot;, buf, sri.sinfo_stream); memset (buf, 0, sizeof(buf)); printf (quot;<S>: quot;); } printf (quot;nOver !!nquot;); 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 An SCTP variable that limits the data (in bytes) that a sender can send to a particular destination Window transport address before receiving an acknowledgement. Maximum The Maximum Transmission Unit (MTU) determines the maximum size of the packet that is Transmission supported by a communications protocol. Unit 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 An SCTP variable that a sender uses to store the most recently calculated receiver window (in Window bytes) of its peer. The value of rwnd indicates the space available in the receiver's inbound buffer. SCTP A protocol relationship between two SCTP endpoints. The association also contains the protocol association 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 The logical sender or receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is endpoint 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 An SCTP variable. This is the threshold (in bytes) that the endpoint uses to determine whether Threshold 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 A 16-bit sequence number used by SCTP to assure sequenced delivery of the user messages within Sequence a given stream. One stream sequence number is attached to each user message. Number Transmission The transmission control block (TCB) is an internal data structure created by an SCTP endpoint Control Block for each SCTP association. TCB contains the status and operational information for the endpoint to maintain and manage the association. Transmission The transmission sequence number (TSN) is a 32-bit sequence number used by SCTP. One TSN Sequence is attached to each chunk containing user data to permit the receiving SCTP endpoint to Number acknowledge its receipt and detect duplicate deliveries. Transport A transport address is defined by the network layer address, the transport layer protocol, and address 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 Unordered messages are quot;unorderedquot; with respect to any other message, this includes both other Message unordered and ordered messages. Unordered message can be delivered before or later than ordered messages sent on the same stream. Verification A 32-bit unsigned integer that is randomly generated. The verification tag provides a key that Tag 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 D_XOPEN_SOURCE_EXTENDED macro, 69 -lxnet library, 70 data boundaries, 31 /usr/lib/libsctp library, 73 DATA chunk, 24, 37 /usr/lib/libxnet library, 70, 73 default stream in SCTP, 55 delayed acknowledgement, 32 A denial of service attack (see DoS) ABORT chunk, 25, 32 difference in TCP and SCTP, 46 achieving half-closed state disabling receive operation in SCTP, 46 at an endpoint, 46 ACK packet, 22 disabling send operation acknowledge packet (see ACK packet) at an endpoint, 46 addrcnt parameter, 62 DoS, 19 address length (see addrlen) preventing, 21 address size (see tolen) addrlen, 45 E addrs parameter, 61, 62 alternate IP address, 29 enabling multihoming, 44 ancillary data structure (see sctp_initmsg structure) (see endpoint failure, 38 sctp_sndrcvinfo) EOPNOTSUPP error, 51 associating an endpoint, 44 ERROR chunk, 25 ESTABLISHED state, 45 existing socket APIs, 41 B backlog, 51 F of outstanding associations, 45 blind masquerade attack, 39 four-way handshake, 22, 38 branched off socket, 56 overcome delay, 23 branching an association, 62 four-way initiation handshake, 45 socket descriptor, 62 freeing resources, 63, 64 buffer size, 53, 55 fromlen paremeter, 55 C G changing outbound streams gap number of (see SCTP_INITMSG) in transmission sequence, 30 chunk data, 25 getsockopt() call, 53 chunk flag, 25 getting control information (see scto_sndrcvinfo structure) chunk length, 25 gracefully closing cmsghdr structure, 58 an association, 46 congestion window, 26 control chunk H information, 24 half-closed state COOKIE ACK chunk, 24 in TCP, 46 COOKIE ECHO chunk, 24 half-open connection, 31 cookie field, 22 head-of-line blocking (see HOL) COOKIE-ACK chunk, 23 HEARTBEAT ACK chunk, 25 COOKIE-ECHO chunk, 22 HEARTBEAT chunk, 25, 38 creating a socket, 43, 49 HOL, 19, 30 cwnd variable, 26 HP-specific library (see libsctp) 87

I O IN6ADDR_ANY option, 46 one-to-many client IN6ADDR_ANY_INIT option, 44 call sequence, 49 INADDR_ANY option, 44, 46 one-to-one client INIT ACK chunk, 24 call sequence, 43 INIT chunk, 24 optlen, 53 INIT-ACK chunk, 22 buffer size, 53 Initiate tag, 39 optlen parameter, 56 initiating an association, 45 optname, 53 IP stack optname parameter, 53, 56 application layer, 21 optval, 53 data link layer, 20 optval paremeter, 53, 56 network layer, 20 physical layer, 20 P socket layer, 21 partial bytes acknowledged, 27 transport layer partial_byte_acked variable, 27 SCTP, 20 passing data IPPROTO_SCTP, 53 into the SCTP stack (see sctp_opt_info() call) IPPROTO_SCTP parameter, 44 payload data chunk, 24 IPPROTO_SCTP value, 56 PF_INET parameter, 43 PF_INET6 parameter, 43 L preparing an endpoint libsctp library, 69 for accepting associations, 45 libxnet library, 69 primary address, 29 M R maximum transmission unit (see MTU) receiver window, 26 message buffer, 55 receiving data, 47 message size, 55 receiving messages, 65 migrate removing an association existing TCP application, 42 from the accept queue, 45 migrating TCP applications retransmission timeout (see RTO) to SCTP, retrieving a socket, 48 benefits of, 73 retrieving socket option, 53 MSG_ABORT flag, 52 RFC 2581, 26 msg_control parameter, 47 RFC 2960, 25 msg_controllen parameter, 47 RTO, 37 MSG_EOF flag, 52 rwnd variable, 26 msg_flags parameter, 47 msg_iov parameter, 47, 57 S msg_iovlen parameter, 47 SACK chunk, 24, 37 msg_name parameter, 47 SCTP msg_namelen parameter, 47 COOKIE-ACK chunk, 23 MSG_NOTIFICATION flag, 57 COOKIE-ECHO chunk, 22 msghdr structure, 47 data boundaries, 31 MTU, 25 default stream, 31 multihoming, 42 definition, 17 enabling, 44 draft compliance, 18 overcoming network failure, 29 four-way handshake, 22 overcoming path failure, 29 INIT chunk, 22 multistreaming, 42 INIT-ACK chunk, 22 avoid HOL blocking, 30 RFC compliance, 18 SCTP notification structure, 57 N SCTP packet new_sd parameter, 45 chunk type, 24 common header, 24 88 Index

control chunk, 24 ACK packet, 22 DATA chunk, 24 data boundaries, 31 SID, 24 half-open connection , 31 SCTP_ASSOC_CHANGE event, 51 single-homed connection, 28 SCTP_AUTOCLOSE option, 49 SYN flood attack, 19 SCTP_EVENTS option, 65 SYN packet, 22 SCTP_INITMSG option, 45 SYN-ACK packet, 22 sctp_initmsg structure, 59 the PUSH flag, 19 sctp_notification structure, 57 three-way handshake, 21 sctp_opt_info() call, 54 time-to-live (see TTL) SCTP_SNDRCV option, 64, 65 tolen parameter, 55 sctp_sndrcvinfo structure, 60 transmission control block (see TCB) selecting peer address (see sockaddr_storage) Transmission Control Protocol (see TCP) setsockoptg() call, 57 transmission sequence number (see TSN) setting control information (see scto_sndrcvinfo structure) transmitting data, 47 setting socket option, 53 to a peer, 55 SHUT_RD parameter, 46 TSN, 24, 30 SHUT_RDWR parameter, 46 TTL, 60, 64 SHUT_WR parameter, 46 shutdown U types of, 46 unordered bit, 25 SHUTDOWN ACK chunk, 25 User Datagram Protocol (see UDP) SHUTDOWN chunk, 25 SHUTDOWN COMPLETE chunk, 25 V shutdown() call verification tag, 22 difference in SCTP and TCP, 46 SID, 24, 30 sinfo.sinf_associd flag, 66 X sinfo.sinfo_flags flag, 66 XOPEN library (see see libxnet library) single-homed connection, 28 XOPEN macro (see D_XOPEN_SOURCE_EXTENDED) slow start threshold variable, 26 XOPEN_SOURCE_EXTENDED macro, 69 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) T TCB, 38 TCP 89

Sctp

by raj sri

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Sctp Document Transcript