SCTP Programmer's GuideHP-UX 11i v2

HP Part Number: 5992-0620Published: September 2007Edition: 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 and12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items arelicensed 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 setforth in the express warranty statements accompanying such products and services. Nothing herein should be construed asconstituting 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...................................................................................................................13Intended Audience.............................................................................................................13Document Organization.....................................................................................................13Typographical Conventions................................................................................................13Related Information............................................................................................................14HP Encourages Your Comments........................................................................................15

1 Introduction..............................................................................................................................17SCTP Overview...................................................................................................................17Limitations of TCP and UDP..............................................................................................18

Limitations of TCP........................................................................................................18Limitations of UDP........................................................................................................19

SCTP Architecture..............................................................................................................19SCTP in the IP Stack......................................................................................................20Connection Setup in SCTP............................................................................................21SCTP Packet...................................................................................................................23Congestion Control in SCTP.........................................................................................26

Slow Start and Congestion Avoidance Algorithms.................................................26Fast Retransmit and Fast Recovery..........................................................................27

SCTP Features.....................................................................................................................27Multihoming..................................................................................................................28Multistreaming..............................................................................................................30Conservation of Data Boundaries.................................................................................31SCTP Graceful Shutdown Feature................................................................................31SCTP Support for IPv4 and IPv6 Addresses.................................................................32SCTP Data Exchange Features......................................................................................32Support for Dynamic Address Reconfiguration ..........................................................33Reporting Packet Drops to an Endpoint.......................................................................33Support for ECN-Nonces in SCTP................................................................................34SCTP Support for Partially Reliable Data Transmission...............................................35

Error Handling in SCTP.....................................................................................................37Retransmission of DATA Chunks.................................................................................37HEARTBEATs to Identify Path Failures........................................................................38HEARTBEATs to Identify Endpoint Failure.................................................................38

SCTP Security.....................................................................................................................38Cookie Mechanism........................................................................................................38Verification Tag..............................................................................................................39

2 SCTP Socket APIs......................................................................................................................41

Table of Contents 3

Overview............................................................................................................................41Socket API Versus SCTP Socket API..................................................................................41Different Socket API Styles.................................................................................................42

One-to-One Socket APIs................................................................................................42Basic One-to-One Call Flow Sequence..........................................................................43

The socket() Socket API............................................................................................43The bind() Socket API..............................................................................................44The listen() Socket API.............................................................................................45The accept() Socket API...........................................................................................45The connect() Socket API.........................................................................................45The close() Socket API..............................................................................................46The shutdown() Socket API.....................................................................................46The sendmsg() and recvmsg() Socket APIs.............................................................47The getpeername() Socket API.................................................................................48

One-to-Many Socket APIs.............................................................................................48Basic One-to-Many Call Flow Sequence.......................................................................48

The socket() Socket API ...........................................................................................49The bind() Socket API..............................................................................................50The listen() Socket API.............................................................................................51The sendmsg() and recvmsg() Socket APIs.............................................................51The close() Socket API..............................................................................................52The connect() Socket API.........................................................................................52

API Options to Modify Socket Behavior............................................................................52Common Socket Calls.........................................................................................................54

The send(), sendto(), recv(), and recvfrom() Socket Calls.............................................55The setsocktopt() and getsockopt() Socket Calls...........................................................56The read() and write() Socket Calls...............................................................................56The getsockname() Socket Call......................................................................................57

SCTP Events and Notifications...........................................................................................57SCTP Ancillary Data Structures.........................................................................................58

SCTP Initiation Structure (SCTP_INIT)........................................................................59SCTP Header Information (SCTP_SNDRCV)...............................................................59

SCTP-Specific Socket APIs..................................................................................................61The sctp_bindx() SCTP Socket API...............................................................................61The sctp_peeloff() SCTP Socket API.............................................................................62The sctp_getpaddrs() SCTP Socket API........................................................................62The sctp_freepaddrs() SCTP Socket API.......................................................................63The sctp_getladdrs() SCTP Socket API.........................................................................63The sctp_freeladdrs() SCTP Socket API........................................................................64The sctp_sendmsg() SCTP Socket API..........................................................................64The sctp_recvmsg() SCTP Socket API...........................................................................65The sctp_connectx() SCTP Socket API..........................................................................65The sctp_send() SCTP Socket API.................................................................................66The sctp_sendx() SCTP Socket API...............................................................................66

4 Table of Contents

3 Compiling and Running Applications that Use the SCTP Socket APIs..............................................69Compiling Applications that Use the SCTP APIs..............................................................69Running Sample Applications that use the SCTP APIs.....................................................70

4 Migrating TCP Applications to SCTP...........................................................................................73

A SCTP Sample Programs.............................................................................................................75Sample Server Programs.....................................................................................................75

One-to-One Server Program..........................................................................................75One-to-Many Server Program.......................................................................................77

Sample Client Programs.....................................................................................................80One-to-One Client Program..........................................................................................80One-to-Many Client Program.......................................................................................82

Glossary.....................................................................................................................................85

Index..........................................................................................................................................87

Table of Contents 5

6

List of Figures1-1 The Internet Protocol Stack.........................................................................................201-2 Three-Way Handshake in TCP....................................................................................211-3 Four-Way Handshake in SCTP...................................................................................221-4 SCTP Packet Format....................................................................................................231-5 A Single-Homed Connection......................................................................................291-6 A Multihomed Connection.........................................................................................291-7 Multistreaming in an SCTP Association.....................................................................311-8 Shutdown in TCP and SCTP.......................................................................................32

7

8

List of Tables1-1 Chunk Types...............................................................................................................241-2 Comparison Between SCTP, TCP, and UDP...............................................................272-1 Data Structures in the recvmsg() and sendmsg() Calls...............................................60

9

10

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

11

12

About This DocumentThis document describes how to write, compile, and run applications using StreamControl 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 “RelatedInformation” (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 bemade at reprint without changing the printing date. The document part number willchange when extensive changes are made.The latest version of the document will be available at: http://www.docs.hp.comDocument updates can be issued between editions to correct errors or document productchanges. To ensure that you receive the updated or new edition, subscribe to theappropriate support service.Contact your HP sales representative for details.

Intended AudienceThis document is intended for application developers who write programs using SCTPsocket APIs. Application developers are expected to be familiar with SCTP, C, UNIX®,TCP, UDP, networking concepts, and operating system concepts. Application developersare recommended to read the relevant SCTP RFCs for detailed information on SCTP.This document is not a tutorial.

Document OrganizationThe 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, SCTPevents 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 applicationsthat use the SCTP APIs.

Chapter 4 Chapter 4 (page 73) describes how to migrate existing TCP applicationsto SCTP. It also discusses the benefits of migrating TCP applications toSCTP.

Typographical ConventionsThis 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 thesection in the HP-UX Reference. On the web and on the InstantInformation CD, it may be a link to the manpage itself. From theHP-UX command line, you can enter “man audit” or “man 5audit” 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.

KeyCap The name of a keyboard key. Note that Return and Enter both referto the same key.

Emphasis Text that is emphasized.Emphasis Text that is strongly emphasized.Term The defined use of an important word or phrase.ComputerOut Text displayed by the computer.UserInput Commands and other text that you type.Command A command name or qualified command phrase.Variable The name of a variable that you may replace in a command or

function or information in a display that represents several possiblevalues.

[ ] 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 theitems

... The preceding element may be repeated an arbitrary number oftimes.

| Separates items in a list of choices.

Related InformationThe 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 InformationBase (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 (StreamControl 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 andIssues) 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 (StreamControl 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 TransmissionProtocol (SCTP)) at:http://tools.ietf.org/html/draft-ladha-sctp-nonce-05

HP Encourages Your CommentsHP encourages your comments concerning this document. We are committed toproviding documentation that meets your needs. Send any errors found, suggestionsfor improvement, or compliments to:feedback@fc.hp.comInclude the document title, manufacturing part number, and any comment, error found,or suggestion for improvement you have concerning this document.

HP Encourages Your Comments 15

16

1 IntroductionThis chapter introduces Stream Control Transmission Protocol (SCTP). It also discussesthe SCTP architecture, the features that SCTP supports, the security features that SCTPoffers, 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 OverviewSCTP is a connection-oriented transport layer protocol that enables reliable transfer ofdata over IP-based networks. In an IP stack, it exists at a level equivalent to that ofTransmission Control Protocol (TCP) and User Datagram Protocol (UDP). SCTP offersall the features that are supported by TCP and UDP. It also overcomes certain limitationsin 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 boundariesSCTP also includes mechanisms, such as checksums, sequence numbers, and selectiveretransmission of data, to detect data corruption, loss of data, and duplication of data.In addition, it contains different congestion control algorithms to minimize data lossin an unstable network. SCTP supports improved error handling methods to avoidunnecessary retransmission of data. The security methods implemented in SCTP enablethe endpoints of an association to avoid SYN-flooding, and to identify stale or unwanteddata packets.Initially, the features of SCTP were designed to transport telephone signaling messagesover 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 aredelivered 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 (StreamControl Transmission Protocol (SCTP)Management Information Base

(MIB))• RFC 4460 (StreamControl 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 UDPTCP and UDP are the most widely used network layer protocols. However, the datatransfer services offered by these protocols are inadequate to meet the requirementsof a wide range of commercial applications, such as real-time multimedia andtelecommunication applications. These applications require a robust protocol, whichprovides the flexibility of UDP and reliability of TCP, for transferring data betweentwo endpoints.This section discusses the limitations of the TCP and UDP protocols, which led to thedevelopment of SCTP.This section addresses the following topics:• “Limitations of TCP” (page 18)• “Limitations of UDP” (page 19)

Limitations of TCPFollowing 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 astrict sequence. These applications prefer partial ordering of data, wherein orderingis 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 unnecessarydelay in the overall data delivery. Moreover, if a single packet is lost, delivery ofsubsequent packets is blocked until the lost TCP packet is delivered. This causeshead-of-line (HOL) blocking.

• TCP transmits data in a stream. This requires that applications add their ownrecord marking, to delineate their messages. Applications must use the PUSH flagin the TCP header, to ensure that a complete message is transferred in reasonabletime.

• In a TCP connection, each host includes a single network interface, and a connectionis established between the network interfaces of the two hosts. As a result, if theconnection breaks because of a path failure, data becomes unavailable until theconnection is re-established.

• TCP is vulnerable to denial of service (DoS) attacks, such as SYN flood attacks. ADoS occurs when a malicious host forges an IP packet with a fake IP address andsends a large number of TCP SYN messages to the victim host. Each time the TCPstack, on the victim host, receives a new SYN message, the TCP stack allocateskernel resources to service the new SYN message. When the TCP stack is floodedwith multiple SYN messages, the victim host can run out of resources and fail toservice the new legitimate SYN messages.

Limitations of UDPFollowing 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 thedestination.

• UDP does not contain an in-built congestion control mechanism to detect pathcongestion. As a result, more data may be injected into an already congestednetwork. This results in data loss.

• If stringent rules for reliable data transfer are implemented in applications thatuse UDP, the implementation causes additional overhead and complexity in theapplications.

SCTP ArchitectureSCTP is designed to address the shortcomings in TCP. It uses mechanisms, such asfour-way handshake to prevent DoS attacks. The SCTP architecture defines packetformat that contains additional fields, such as cookie and verification tag, to avoid SYNflooding. The SCTP architecture includes improved congestion control algorithms thatare 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 StackFigure 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 specificfunctionality. 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 supportsreliable and sequential packet delivery through error recovery and flow controlmechanisms. UDP is a simple message-based connectionless protocol comparedto TCP. SCTP is yet another transport layer protocol that application developerscan use to transmit data between endpoints.

• The socket layer provides the transport layer with an interface to interact with theapplication layer. The socket layer contains a set of APIs, which facilitate thetransport layer to interface with the application layer.

• The application layer provides application programs with an interface tocommunicate and transfer data across the network. All application layer protocolsuse the sockets layer as their interface, to interact with the transport layer protocol.

Connection Setup in SCTPThis 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 athree-way handshake to set up a new connection, whereas SCTP uses a four-wayhandshake 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 startsending 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 CookieThe TCP SYN-ACK packet does not contain these fields. The cookie contains thenecessary state information, which the server uses to allocate resources for theassociation. The cookie field includes a signature for authenticity and a timestampto prevent replay attacks using old cookies. Unlike TCP, Host B in SCTP does notallocate resources at this point in the connection. The verification tag provides akey that enables Host A to verify that the SCTP packet belongs to the currentassociation.

3. Host A sends theCOOKIE-ECHOpacket 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 serverallocating any resources for the connection.

4. Host B responds with a COOKIE-ACK chunk and allocates resources for theconnection.The connection is now established between Host A and Host B. Host A can nowstart sending data to Host B.

In SCTP, the transfer of data may be delayed because of the additional handshake. Thefour-way handshake may seem to be less efficient than a three-way handshake. Toovercome this delay, SCTP permits data to be exchanged in the COOKIE-ECHO andCOOKIE-ACK chunks.

SCTP PacketSCTP transmits data in the form of messages and each message contains one or morepackets.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 SCTPcommon 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 incorporatesdifferent flags and parameters, depending on the chunk type. The DATA chunkincorporates flags to control segmentation and reassembly, and parameters for thetransmission 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. Thevalue 255 is reserved for future use, as an extension field. SCTPconsists of one DATA chunk and 12 control chunks.Table 1-1 lists the definitions and parameters of the different chunktypes.

Table 1-1 Chunk Types

DefinitionChunk

Used for data transfer.Payload Data (DATA)

Initiates an SCTP association between twoendpoints.

Initiation (INIT)

Acknowledges the receipt of an INIT chunk.The receipt of theINIT ACK chunk establishesan association.

Initiation Acknowledgement (INIT ACK)

Acknowledges the receipt of the DATA chunksand also reports gaps in the data.

Selective Acknowledgement(SACK)

Used during the initiation process. Theendpoint initiating the association sends theCOOKIE ECHO chunk to the peer endpoint.

Cookie Echo (COOKIE ECHO)

Acknowledges the receipt of the COOKIEECHO chunk. The COOKIE ACK chunk musttake precedence over anyDATA chunk orSACKchunk sent in the association. The COOKIEACK chunk can be bundled with DATA chunksor SACK chunks

Cookie Acknowledgement(COOKIE ACK)

24 Introduction

Table 1-1 Chunk Types (continued)

DefinitionChunk

Tests the connectivity of a specific destinationaddress in the association.

Heartbeat Request (HEARTBEAT)

Acknowledges the receipt of the HEARTBEATchunk.

Heartbeat Acknowledgement (HEARTBEAT ACK)

Informs the peer endpoint to close theassociation. TheABORT chunk also informs thereceiver of the reason for aborting theassociation.

Abort Association (ABORT)

Reports error conditions. The ERROR chunkcontains parameters that determine the typeof error.

Operation Error (ERROR)

Triggers a graceful shutdown of an associationwith a peer endpoint.

Shutdown Association (SHUTDOWN)

Acknowledges the receipt of the SHUTDOWNchunk at the end of the shutdown process.

Shutdown Acknowledgement(SHUTDOWN ACK)

Concludes the shutdown procedure.Shutdown Complete (SHUTDOWN COMPLETE)

Chunk Flag This field contains the flags, such as U (unordered bit), B (beginningfragment bit), and E (ending fragment bit). Usage of this fielddepends on the chunk type specified in the chunk type field. Unlessotherwise specified, SCTP sets this field to 0 while transmitting thepacket 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 thechunk. The usage and format of this field depends on the chunktype.

The number of chunks in an SCTP packet is determined by the MTU size of thetransmission path. Multiple chunks can be bundled into one SCTP packet except theINIT, INIT ACK, and SHUTDOWN COMPLETE chunks. The SCTP packet size must notbe more than the MTU size.The SCTP packet format supports bundling of multiple DATA and control chunks intoa single packet, to improve transport efficiency. An application can control bundling,to avoid bundling during initial transmission. Bundling occurs on retransmission ofDATA chunks, to reduce the possibility of congestion. If the user data does not fit intoone packet, SCTP fragments data into multiple chunks.For more information on the SCTP packet format, see RFC 2960 (Stream ControlTransmission Protocol).

SCTP Architecture 25

Congestion Control in SCTPSCTP uses various congestion control algorithms to effectively handle network failuresor unexpected traffic surges, and ensures quick recovery from data congestion. SCTPand TCP support the same set of congestion control algorithms. Following are thecongestion control algorithm supported by SCTP:• Slow Start and Congestion Control• Fast Retransmit and Fast RecoveryHowever, in SCTP, the congestion control algorithms are modified to suite theprotocol-specific requirements.For information on the TCP congestion control algorithms, see RFC 2581 (TCPCongestionControl).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 ofoutstanding data being injected into the network. SCTP uses the slow start algorithmat the beginning of the transmission, when the network condition is unknown, andalso in repairing loss detected by the retransmission timer. SCTP slowly probes thenetwork to determine the available capacity of the network to avoid congestion in thenetwork. If SCTP detects a congestion in the network, it switches to the congestionavoidance algorithm to manage the congestion.The slow start and congestion avoidance algorithms use the following congestioncontrol variables:Congestion window (cwnd) Specifies the limit on the amount of data the

sender can transmit through the network, beforereceiving an acknowledgement. This variable ismaintained for each destination address.

Receiver window (rwnd) Specifies the receiver’s limit on the amount ofoutstanding data.

NOTE: The minimum value of the cwnd andrwnd variables determine the amount of datatransmission.

Slow start threshold (ssthresh) Determines whether the slow start or congestionavoidance algorithm must be used to control datatransmission.

26 Introduction

Partial Bytes Acknowledged(partial_byte_acked)

Adjusts of the cwnd parameter.

In an SCTP connection, the sender uses the slow start algorithm if the value of cwndis less than the ssthresh value. If the value of cwnd is greater than the ssthreshvalue, the sender uses the congestion avoidance algorithm. If the values for cwnd andssthresh are same, the sender can use either the slow start or congestion avoidancealgorithm. Unlike TCP, an SCTP sender must store the cwnd, ssthresh, andpartial_bytes_acked congestion control variables for each destination address ofthe peer. However, the sender needs to store only one rwnd value for the wholeassociation, 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 retransmitmissing segments of information in an SCTP association. When a receiver in an SCTPconnection receives a DATA chunk out of sequence, the receiver sends a SACK packetwith the unordered TSN, to the sender. The fast retransmit algorithm uses four SACKpackets to indicate loss of data, and retransmits DATA without waiting for theretransmission timer to timeout. After the fast retransmit algorithm sends the DATAthat appears to be missing, the fast recovery algorithm controls the transmission ofnew data until all the lost segments are retransmitted.

SCTP FeaturesThe Signaling Transport (SIGTRAN) Working Group in IETF developed SCTP toaddress the limitations in TCP and UDP. Though the development of SCTP was directlymotivated by the need to transfer Public Switched Telephone Network (PSTN) signalingmessages across the IP network, SIGTRAN ensured that the design meets therequirements 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

UDPTCPSCTPFeature

no1yesyesState required at each endpoint

noyesyesReliable data transfer

noyesyesCongestion control and avoidance

yesno2yesMessage boundary conservation

noyes2yesPath MTU discovery and message fragmentation

noyes2yesMessage bundling

nonoyesMulti-homed hosts support

SCTP Features 27

Table 1-2 Comparison Between SCTP, TCP, and UDP (continued)

UDPTCPSCTPFeature

nonoyesMulti-stream support

yesnoyesUnordered data delivery

nonoyesSecurity cookie against SYN flood attack

no3yesBuilt-in heartbeat (reachability check)

1 In UDP, a node can communicate with another node without going through a setup procedure, orwithout changing any state information. However, each UDP packet contains the required stateinformation 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 aformatless stream of data bytes. However, because TCP transfers data in sequence of bytes, it canautomatically resize all the data into new TCP segments that are suitable for the Path MTU, beforetransmitting 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 HEARTBEATchunk 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)

MultihomingMultihoming is the ability of a single SCTP endpoint to contain multiple interfaces withdifferent IP addresses. In a single-homed connection, an endpoint contains only onenetwork 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 asingle network interface (NIB1). NIA1 is the only interface for Host A to interact withHost B.When a network or path failure occurs, the endpoint is completely isolated from thenetwork. Multihoming in SCTP ensures better chances of survival if a network failureoccurs, when compared to TCP. The built-in support for multi-homed hosts in SCTPenables a single SCTP association to run across multiple links or paths, to achieve linkor path redundancy. This enables an SCTP association to achieve faster failover fromone link or path to another, with minimum interruption in the data transfer service.Figure 1-6 illustrates the mutli-homed connection in SCTP.

Figure 1-6 A Multihomed Connection

In this figure, Host A contains multiple network interfaces to interact with Host B,which also has multiple interfaces.SCTP selects a single address as the "primary" address and uses it as the destinationfor all DATA chunks for normal transmission. All the other addresses are consideredas alternate IP addresses. SCTP uses these alternate IP addresses to retransmit DATAchunks 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 aresult, all DATA chunks are transmitted to the alternate address until the HEARTBEATchunks have re-established contact with the primary addressDuring the initiation of an association, the SCTP endpoints exchange the list of IPaddresses, so that each endpoint can receive messages from any of the addressesassociated with the remote endpoint. For security reasons, SCTP sends responsemessages to the source address in the message that prompted the response.An endpoint can receive messages that are out of sequence or with different addresspairs, because multi-homing supports multiple IP addresses. To overcome this problem,SCTP incorporates procedures to resolve parallel initiation attempts into a singleassociation.

MultistreamingMultistreaming 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 otherstreams. Each stream in an SCTP association uses two sets of sequence numbers, namelya Transmission Sequence Number (TSN) that governs the transmission of messagesand 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 ensuresthat all the bytes are delivered in a particular order. Therefore, a second byte is sentonly after the first byte has safely reached the destination. The sequential delivery ofdata 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 sequencingis restored, either upon receiving an out-of-sequence message or by retransmitting alost message.The strict preservation of message sequence in TCP poses a limitation for certainapplications. These applications require sequencing of messages that affect the sameresource (such as the same call or the same channel), so that messages are looselycorrelated and delivered without maintaining the overall sequence integrity.The multistreaming feature in an SCTP, in which reliable data transmission and datadelivery are independent of each other, overcomes this problem. This feature alsoavoids HOL blocking. This independence improves the flexibility of an application, byallowing it to define semantically different streams of data inside the overall SCTPmessage flow, and by enforcing message ordering only within each of the streams. Asa result, message loss in one particular stream does not affect the delivery of messagesin a different stream. The receiver can immediately determine if there is a gap in thetransmission sequence (for example, caused by message loss), and also can determinewhether messages received following the gap are within the affected stream. If SCTPreceives a message that belongs to the affected stream, a corresponding gap occurs inSSN. The sender can continue to deliver messages to the unaffected streams whilebuffering 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 defaultstream to transmit data. Applications can modify the number of streams through whichSCTP transmits data.

Conservation of Data BoundariesIn SCTP, a sending application can construct a message out of a block of data bytesand instruct SCTP to transport the message to a receiving application. SCTP guaranteesthe delivery of this message (data block) in its entirety. It also indicates to the receiverabout both the beginning and end of the data block. This is called conservation ofmessage boundaries. TCP does not conserve data boundaries. It treats all the datapassed to it from the sending application as a sequence or stream of data bytes. Itdelivers all the data bytes to the receiver in the same sequential order as they werepassed from the application. TCP does not conserve data boundaries when packetsarrive out of sequence. As a result, the receiver cannot rearrange the packets. It has towait till the packets arrive in sequence, starting from the last unreceived packet to thereceived out-of-sequence packet.

SCTP Graceful Shutdown FeatureSCTP does not support a "half-open" connection, which can occur in TCP. In a half-openconnection, even though an endpoint indicates that it has no more data to send, theother endpoint continues to send data indefinitely. SCTP, on the other hand, assumesthat when the shutdown procedure begins, both the endpoints will stop sending newdata across the association. It also assumes that it needs only to clear upacknowledgements of the previously sent data.The SCTP shutdown feature uses a three-message procedure to gracefully shutdownthe 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 AddressesSCTP supports both IPv4 and IPv6 address parameters in an SCTP packet, as definedin RFC 2960 (Stream Control Transmission Protocol). When an association is set up, theSCTP endpoints exchange the list of addresses of the endpoints in the INIT andINIT-ACK chunks. The address of the endpoint is represented by the followingparameters: an IPv4 address parameter with value 5 and an IPv6 address parameterwith value 6. The INIT chunks can contain multiple addresses, which can be an IPv4or IPv6 address.

SCTP Data Exchange FeaturesThis section discusses the enhanced features in SCTP that ensures reliable data exchangebetween 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 DATAchunk by sending a SACK chunk to the other endpoint. The SACK chunk indicatesthe range of cumulative TSNs and non-cumulative TSNs, if any. Thenon-cumulative TSNs indicate gaps in the received TSN sequence. When SCTPidentifies gaps in the TSN sequence, it resends the missing DATA chunks to theother 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 perreceived 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, congestionavoidance, fast recovery, and fast retransmit, to control the flow and retransmissionof data. For information on these congestion control algorithms see, “CongestionControl in SCTP” (page 26). In these algorithms, the receiver advertises the receivewindow and a sender advertises a per-path congestion window to handlecongestion. The receiver window indicates buffer occupancy of the receiver. Theper-path congestion window manages the packets in flight. The congestion controlalgorithms in SCTP are similar to that of TCP, except that the endpoints in an SCTPconnection manages the conversion between bytes sent and received, and TSNssent 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 thelifetime 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 thedata has expired and the data has been transmitted, data must be delivered toavoid a hole in the TSN sequence.

Support for Dynamic Address ReconfigurationSCTP enables an endpoint to reconfigure the IP address information dynamically foran existing association. When the endpoints exchange information during associationstartup, the usability of SCTP also improves without modifying the SCTP protocol.This feature is useful in computational and networking applications that add or removephysical interface cards dynamically and need the IP address of the interface to bechanged dynamically. This feature also enables an endpoint to set the primarydestination address of a remote peer so that when the primary address of an endpointis 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 thefollowing chunk types:Address Configuration ChangeChunk (ASCONF)

The ASCONF chunk communicates theconfiguration change requests that must beacknowledged, to the remote endpoint.

Address ConfigurationAcknowledgment (ASCONF-ACK)

The ASCONF-ACK chunk is used by the receiverof an ASCONF chunk to acknowledge thereception of the ASCONF chunk.

Reporting Packet Drops to an EndpointWhen a packet drop occurs because of an error other than congestion, an endpoint canmistakenly interpret the packet drop as an indication of congestion in the network. Themisinterpretation 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 sendercan 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 oferrors other than congestion. After receiving the PKTDROP chunk, an SCTP endpointcan inform its peer that it has received an SCTP packet with an incorrect CRC32C orAdler-32 checksum. The peer can then retransmit the SCTP packet without modifyingthe 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 SCTPWith the increased deployment of real-time applications and transport services thatare sensitive to the delay and loss of packets, relying on packet loss alone as indicativeof congestion is not sufficient. SCTP's congestion management algorithms have built-intechniques, 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 packetstill packets are dropped because of congestion. However, these mechanisms are notintended to help applications that are sensitive to the delay or loss of one or moreindividual 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 sendercontinues to send packets, the number of packets in the queue in the router increasesand causes a bottleneck in the router. In such a case, the router marks the packets withcongestion experienced (CE) bits and sends them to the receiver to indicate congestion,instead of dropping the packets. Explicit Congestion Notification (ECN) is a congestionmanagement algorithm that uses a similar method to handle congestion. ECN uses theECN 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 thedata sender to indicate that the endpoints are ECN-capable. The CE bit is set by therouter to indicate congestion. The ECT code points range from 00 to 01. Senders usethe 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 networkelement, 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 containmechanisms to avoid network elements from clearing the ECNE flag. Moreover, ECNrequires the cooperation of the receiver to return congestion experienced signals to thesender. If the receiver erases the congestion signals to conceal congestion and does notsend these signals to the sender, the sender gains a performance advantage at theexpense of competing connections that do not experience congestion.SCTP supports the ECN method and is exposed to misbehaving receivers that concealcongestion signals. The misbehavior includes concealment of ECNE signals that maycause an SCTP sender to be aggressive and unfair to compliant flows. SCTP supportsECN-nonce to avoid misbehaving receivers from concealing congestion signals.ECN-nonce also protects senders from other forms of misbehavior, such as optimisticacknowledgements and false duplicate TSN notifications.The ECN-nonce is a modification of the ECN signaling mechanism. It improves thecongestion control by preventing receivers from exploiting ECN to gain an unfair shareof network bandwidth. ECN-nonce improves the robustness of ECN by preventingreceivers from concealing marked or dropped packets. Like ECN, ECN-nonce uses theECT(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 randomlygenerates 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 theCE bit. The nonce sum (NS) is a cumulative one bit addition of the nonces receivedfrom the receiver. The receiver calculates the nonce sum and returns it in the NS flagof 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 incorrectnonce sum is received by the sender without ECNE signals, the sender can infer thatthe 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 whetherECN-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 TransmissionSCTP supports partially reliable data transmission service (PR-SCTP) that enables anSCTP 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, inaddition to unordered and unreliable data transfer (similar to UDP). PR-SCTP employssimilar congestion control and congestion avoidance algorithms as SCTP, for bothreliable or partially reliable data traffic.

SCTP Features 35

The communication failure detection and protection capabilities of reliable SCTP datatraffic are also applicable to partially reliable data traffic. PR-SCTP enables an endpointto detect a failure destination address quickly and to failover to an alternate destinationaddress. It also notifies when the destination address becomes unreachable.The chunk bundling capability in SCTP enables reliable and unreliable messages to bemultiplexed 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 usingseparate protocols.SCTP includes the following parameter and chunk to support the partially reliable datatransmission service:The Forward-TSN-Supportedparameter

This is an optional parameter in the INIT andINIT ACK chunks. When an association isinitialized, the SCTP sender must include thisparameter in the INIT or INIT ACK chunk toinform its peer that it supports partially reliabledata service.

The Forward Cumulative TSN(FORWARD TSN) chunk

The receiver sends this chunk to a sender toinform its support for PR-SCTP. An SCTP senderuses this chunk to inform the receiver to moveits cumulative received TSN forward, becausethe missing TSNs are associated with data chunksthat must not be transmitted or retransmitted bythe sender.

The timed-reliability service is an example of a partially reliable service that SCTPprovides to the upper layer using PR-SCTP. This service enables the service user toindicate a limit on the duration of time that the sender must try to transmit or retransmitthe message.If an SCTP endpoint supports the FORWARD TSN chunk, it can include theForward-TSN-supported parameter in theINIT chunk to indicate support forFORWARDTSN chunk to its peer. If an endpoint chooses not to include the Forward-TSN-Supportedparameter, it cannot send or process aFORWARD TSN chunk anytime during the lifetimeof an association. Instead, it must pretend as if it does not support the FORWARD TSNchunk 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-Supportedparameter and does not support the Forward-TSN chunk type, the receiver mayoptionally respond with the Unsupported Parameters parameter, as defined inSection 3.3.3 of RFC 2960.A receiver can perform the following tasks if it receives an INIT chunk that does notcontain 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 ofan association.

• Check with the upper layer if it has requested a notification on whether the peerendpoint supports the Forward-TSN-Supported parameter.

Error Handling in SCTPThe network traffic in the Internet is unpredictable. Sudden network failures and trafficsurges can occur, which result in non-reachability of an endpoint. Such a network iserror prone and a sending application must be cautious while transmitting orretransmitting 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 endpointfailure.SCTP offers appropriate error handling methods, to overcome this problem. Beforetransmitting data, SCTP sends chunks of information to verify whether a destinationis active. Even before using a different path to reach a destination or closing anassociation, 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 failuresThis 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 ChunksSCTP uses DATA chunks to exchange information between two addresses. Uponreceiving a DATA chunk, the receiving address sends an acknowledgement to thesending 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 timertimes 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 roundtrip delay and reduces the transmission rate exponentially when the message lossincreases.In an active SCTP association with constant DATA transmission, SACKs are more likelyto cause retransmission than the retransmission timeout. To reduce unnecessaryretransmission of data, SCTP uses the four SACK rule, so that SCTP retransmits a DATAchunk 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 normaloccurrences, such as packets received out of sequence.

HEARTBEATs to Identify Path FailuresSCTP periodically sends HEARTBEAT chunks to idle destinations, or alternate addressesto identify a path failure. SCTP maintains a counter to store the number of heartbeatsthat are sent to the inactive destination, without receiving a corresponding HeartbeatAck chunk. When the counter reaches the specified maximum value, SCTP also declaresthe destination address as inactive. SCTP notifies the application about the inactivedestination address and starts using an alternate address for sending the DATA chunks.However, SCTP continues to send heartbeats to the inactive destination address untilit receives an ACK chunk. On receipt of an ACK chunk, SCTP considers the destinationaddress as active again. The rate at which SCTP sends heartbeats depends on the sumof the RTO value and the delay parameter, which allow Heartbeat traffic to be tailoredper the needs of the user application.

HEARTBEATs to Identify Endpoint FailureSCTP 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 ofretransmits or Heartbeats sent to the remote endpoint without a successful ACK. Whenthe value of the counter exceeds a preconfigured maximum value, SCTP declares theendpoint as unreachable and closes the association.

SCTP SecuritySCTP uses the following methods to provide security:• Cookie Mechanism• Verification TagThis section addresses the following topics:• “Cookie Mechanism” (page 38)• “Verification Tag” (page 39)

Cookie MechanismA cookie mechanism is employed during the initialization of an association, to provideprotection 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 memoryand resources to handle new INIT requests. Instead of allocating memory for aTransmission 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 sendsthese back in the INIT ACK chunk. The blind attacker cannot obtain the cookie, becausethe INIT ACK always goes back to the source address of the INIT. A valid SCTP clientgets the cookie and returns it in the COOKIE ECHO chunk, where the SCTP server canvalidate 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 notexchange these details with the client.

Verification TagA verification tag is a 32–bit unsigned integer that is randomly generated to verifywhether the SCTP packet belongs to the current association, or to a stale packet froma previous association. SCTP discards packets received without the expected verificationtag value, to protect against blind masquerade attacks and also from receiving staleSCTP packets from a previous association.The verification tag rules apply when sending or receiving SCTP packets that do notcontain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO, ABORT, or a SHUTDOWN ACKchunk.While sending an SCTP packet, the endpoint must fill in the verification tag field ofthe outbound packet, with the tag value in the Initiate Tag parameter of INIT orINIT ACK received from its peer.After receiving an SCTP packet, the endpoint must ensure that the value in theverification tag field of the received SCTP packet matches its own tag. If the receivedverification tag value does not match the receiver's own tag value, the receiver silentlydiscards the packet and does not process it any further.The verification tag value is chosen by each endpoint of the association duringassociation startup.

SCTP Security 39

40

2 SCTP Socket APIsThis chapter discusses the different SCTP socket API types, their call flow sequence,SCTP events and notifications, socket options, command socket calls, and the SCTPancillary 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)

OverviewThe socket layer in an IP stack contains socket APIs that enable the transport layer tointerface with the application layer. The socket APIs make the various protocol-specificfeatures available to an application.SCTP contains the existing socket APIs and the SCTP-specific APIs. Both these APIsenable SCTP to interface with the application layer. These APIs are also compatiblewith 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 interfaceThe following sections discuss the differences between the socket API and the SCTPsocket APIs, the different SCTP socket API styles, data structures that enable applicationsto control an association, and socket APIs to modify the socket options.

Socket API Versus SCTP Socket APIThe SCTP APIs use the existing socket APIs to perform operations that are similar tothe operating behavior of the socket APIs. For example, in the existing socket APIs andthe SCTP socket APIs, an application can call the bind() API only once and anapplication can specify only a single address in the bind() API.

Overview 41

However, because of the unique features of SCTP, such as multistreaming andmultihoming, the existing socket APIs either do not work on an SCTP socket, or thesemantics of the socket APIs need modification. For example, because of themulti-homing feature supported in SCTP, the socket APIs, getsockname() andgetpeername(), do not work on an SCTP socket if a given association is bound tomultiple local addresses and the association has multiple peer addresses. Applicationsmust use the sctp_getpaddrs() SCTP socket API to obtain the peer addresses inan association.Unlike the existing socket APIs, the SCTP socket APIs disclose many features of theSCTP protocol and association status to the application, to enable applications gainbetter control over the SCTP protocol. For example, an application can specify someof the association setup parameters, such as the number of desired outbound streamsand maximum number of inbound streams, to control an association.

Different Socket API StylesThis section discusses the different socket API styles and the basic call flow sequenceof each socket API style.Following are the different socket API styles:• One-to-one socket APIs• One-to-many socket APIsThe one-to-one style API is similar to the existing socket APIs for a connection-orientedprotocol, such as TCP. The one-to-many style API facilitates simultaneous associationswith multiple peers using one end point (that is, it associates with multiple peers usingone socket file descriptor simultaneously).These socket API styles share common data structures and operations. However, eachsocket API style requires a different application programming style. You can use thesesocket APIs to implement all the SCTP features. You can also select the API styledepending 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 APIsThe one-to-one style socket APIs are designed to enable the existing TCP applicationsto migrate to SCTP with minimal changes. The sequence of socket calls made by theclient and server of a one-to-one style SCTP application is similar to the sequence ofsocket calls made by a TCP application. A one-to-one style SCTP application can controlonly one association using one file descriptor.

42 SCTP Socket APIs

Basic One-to-One Call Flow SequenceA one-to-one style SCTP application uses the following system call sequence to preparean 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 returnswith a new socket descriptor. The server then uses the new socket descriptor tocommunicate with the client, using recv() and send() calls to receive requestsand 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 witha server to request services:1. socket()

2. connect() or sctp_connectx()After returning from connect(), the client uses send() and recv() calls tosend 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 SocketCalls” (page 54).

The socket() Socket API

Applications callsocket() 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);

orint socket(PF_INET6, SOCK_STREAM, IPPROTO_SCTP);

where:PF_INET Specifies the IPv4 domain.PF_INET6 Specifies the IPv6 domain.

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 IPv4addresses, while the second syntax creates an endpoint, which can use both IPv6 andIPv4 addresses.

The bind() Socket API

Applications use bind() to specify the local address with which an SCTP endpointmust associate.These addresses, associated with a socket, are eligible transport addresses for theendpoint to send and receive data. The endpoint also presents these addresses to itspeers during the association initialization process. To accept new associations on thesocket, the endpoint must call listen(), after calling bind(). For information onlisten(), see “The listen() Socket API” (page 45).Following is the syntax for the bind() API:ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen);

where:sd Represents the socket descriptor returned by the socket() call.addr Represents the address structure (struct sockaddr_in or struct

sockaddr_in6).addrlen Represents the size of the address structure.If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv6socket, the address passed can either be an IPv4 or an IPv6 address.Applications cannot call bind() multiple times to associate multiple addresses to anendpoint. 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, orIN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating systemassociates the endpoint with an optimal address set of the available interfaces. Ifbind()is not called before a sendmsg() call that initiates a new association, the endpointpicks a transient port and chooses an address set that is equivalent to binding with awildcard address. One of the addresses in the address set serves as the primary addressfor the association. Thus, when an application calls bind() with the INADDR_ANY orthe IN6ADDR_ANY_INIT wildcard address, the multihoming feature is enabled inSCTP.The completion of the bind() process alone does not prepare the SCTP endpoint toaccept inbound SCTP association requests. When a listen() system call is performedon the socket, the SCTP endpoint promptly rejects an inbound INIT request using anABORT flag.

44 SCTP Socket APIs

The listen() Socket API

Applications use listen() to prepare the SCTP endpoint for accepting inboundassociations.Following is the syntax for the listen() socket API:int listen(int sd, int backlog);

where:sd Represents the socket descriptor of the SCTP endpoint.backlog Represents the maximum number of outstanding associations allowed in

the accept queue of the socket. These associations have completed thefour-way initiation handshake and are in the ESTABLISHED state. Abacklog of 0 (zero) indicates that the caller no longer wants to receive newassociations.

The accept() Socket API

Applications use the accept() call to remove an established SCTP association fromthe accept queue. The accept() API returns a new socket descriptor, to represent thenewly formed association.Following is the syntax for the accept() socket API:new_sd = accept(int sd, struct sockaddr *addr, socklen_t *addrlen);

where:new_sd Represents the socket descriptor for the newly formed association.sd Represents the listening socket descriptor.addr Contains the primary address of the peer endpoints.addrlen Specifies the size of addr.

The connect() Socket API

Applications use connect() to initiate an association with a peer.Following is the syntax for the connect() socket API:int connect(int sd, const struct sockaddr *addr, socklen_t addrlen);

where:sd Represents the socket descriptor of the endpoint.addr Represents the address of the peer.addrlen Represents the size of the address.By default, the newly created association has only one outbound stream. Applicationsmust use the SCTP_INITMSG option before connecting to the server, to change thenumber of outbound streams. The SCTP_INITMSG option enables you to set a socketoption 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 picksa transient port and chooses an address set that is equivalent to binding withINADDR_ANY and IN6ADDR_ANY for IPv4 and IPv6 sockets, respectively. One of theseaddresses serves as the primary address for the association. When an application callsbind() with the INADDR_ANY or the IN6ADDR_ANY_INIT wildcard address, themultihoming feature is enabled in SCTP.

The close() Socket API

Applications use close() to gracefully close down an association.Following is the syntax for the close() socket API:int close(int sd);

where:sd Represents the socket descriptor of the association to be closed.After an application calls close() on a socket descriptor, no further socket operationssucceed on that descriptor.

The shutdown() Socket API

Applications use the shutdown() socket API to disable send or receive operations atan 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 thehalf-close state, an application at the sending endpoint continues to send data even ifan application at the receiving endpoint has stopped receiving data. In SCTP,shutdown() completely disables applications at both the endpoints from sending orreceiving data.

NOTE: Applications can use the SCTP streams feature to achieve the half closed statein SCTP.

Following is the syntax for the shutdown() socket call:int shutdown(int sd, int how);

sd Specifies the socket descriptor of the association that needs to be closed.how Specifies the type of shutdown. The values are as follows:

SHUT_RD Disables further receive operationsSHUT_WR Disables further send operations and initiates the SCTP shutdown

sequenceSHUT_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_WRcauses TCP to enter a half-closed state. The SHUT_RD value behaves in the same wayfor 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 unableto deliver.

The sendmsg() and recvmsg() Socket APIs

Applications use the sendmsg() and recvmsg() socket APIs to transmit data to andreceive data from its peer.Following is the syntax for the sendmsg() and recvmsg() socket APIs:ssize_t sendmsg(int sd, const struct msghdr *message, int flags);ssize_t recvmsg(int sd, struct msghdr *message, int flags);

where:sd Represents the socket descriptor of the endpoint.message Specifies the pointer to the msghdr structure that contains a single user

message and the ancillary data. Following is the structure for the msghdrstructure:struct msghdr { void *msg_name; socklen_t msg_namelen; struct iovec *msg_iov; size_t msg_iovlen; void *msg_control; socklen_t msg_controllen; int msg_flags; };

where:msg_name Specifies the pointer to the socket address structure.msg_namelen Specifies the size of the socket address structure.msg_iov Includes an array of message buffers.msg_iovlen Specifies the number of elements in the msg_iov

structure.msg_control Specifies the ancillary data.msg_controllen Specifies the length of the ancillary data buffer.msg_flags Specifies the flags on the received message.For more information on the msghdr, see RFC 2292 (Advanced Sockets APIfor IPv6).

flags Contains flags that affect the messages being sent or received

Different Socket API Styles 47

NOTE: A sendmsg()API does not fail if it contains an invalid SCTP stream identifierbut an error is returned on all subsequent calls on the file descriptor.

The getpeername() Socket API

Applications use thegetpeername() socket API to retrieve the primary socket addressof the peer.Following is the syntax for the getpeername() socket API:int getpeername(int sd, struct sockaddr *address, socklen_t *len);

where:sd Specifies the socket descriptor to be queried.address Contains the primary peer address. If the socket is an IPv4 socket, the

address will be an IPv4 address. If the socket is an IPv6 socket, the addresswill be either an IPv6 or an IPv4 address.

len Specifies the length of the address.If the actual length of the address is greater than the length of the supplied sockaddrstructure, SCTP truncates the stored address.

NOTE: The getpeername() socket API is available only for TCP compatibility. Itmust not be used for the multihoming feature in SCTP, because this socket API doesnot work with one-to-many style sockets.

One-to-Many Socket APIsThe one-to-many style APIs are designed to enable applications to control manyassociations from a single endpoint, using a single file descriptor. Similar to the APIsin UDP, one-to-many style APIs in SCTP enable a single socket file descriptor to connectto multiple remote endpoints. A one-to-many style socket can send and receive datawithout connecting to an endpoint. Unlike UDP, however, SCTP always has a validassociation with the specified endpoints, because SCTP is a connection-oriented protocol.

Basic One-to-Many Call Flow SequenceA server in the one-to-many style uses the following socket call sequence to preparean 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 anassociation 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 singlesocket. Each association is assigned an association ID (of type uint32_tsctp_assoc_t), so that an application can use it to differentiate between differentassociations. 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 establishedassociation, 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 theID until the application explicitly terminates the association. The resources belongingto that association are not freed until the association terminates. This is similar to theclose() call on a normal socket. The only difference between a normal socket and aone-to-many socket is the availability of the SCTP_AUTOCLOSE option in theone-to-many socket. When theSCTP_AUTOCLOSE option is set in a one-to-many socket,an application can reuse the association ID assigned to the association once theassociation terminates automatically. Applications that use this option must ensurethat they do not send data to an incorrect peer endpoint, because the association ID isbeing reused.A server or client can branch off an existing one-to-many association into a separatesocket. When an association is branched off to a separate socket, the branched off socketis completely separated from the original socket. All subsequent control and dataoperations on that association must be done through the new socket. For example, theclose() operation on the original socket does not terminate associations that havebeen branched off to a different socket.For more information on the one-to-many style socket APIs, see the subsequentsubsections 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 SCTPendpoint.Following is the syntax for the socket() socket API:

Different Socket API Styles 49

sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);

orsd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);

where:SOCK_SEQPACKET Indicates the creation of a one-to-one or one-to-many style

socket.IPProto_SCTP Specifies the type of the protocol.PF_INET Specifies the IPv4 domain.PF_INET6 Specifies the IPv6 domain.The first syntax of socket() creates an endpoint that can use only IPv4 addresses,while the second syntax creates an endpoint that can use both IPv6 and IPv4 addresses.

The bind() Socket API

Applications use bind() to specify the local address to which an SCTP endpoint mustassociate.An SCTP endpoint can be associated with multiple addresses. The sctp_bindx()API enables applications to associate with multiple addresses. For information onsctp_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 andreceive data. The endpoint also presents these addresses to its peers during theassociation initialization process. To accept new associations on the socket, applicationsmust call listen(), after calling bind(). For information on listen(), see “Thelisten() Socket API” (page 45).Following is the syntax for the bind() socket API:ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen);

where:sd Represents the socket descriptor returned by the socket() call.addr Represents the address structure (struct sockaddr_in or struct

sockaddr_in6).addrlen Represents the size of the address structure.If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv6socket, the address passed can be either an IPv4 or an IPv6 address.Applications cannot call bind() multiple times to associate multiple addresses to anendpoint. 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, orIN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating systemassociates 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 theprimary address for the association. This automatically enables the multi-homingfeature of SCTP.

The listen() Socket API

An application uses listen() to indicate that a socket is ready to accept newassociations.Following is the syntax for the listen() socket API:int listen(int sd, int backlog);

where:sd Specifies the socket descriptor of the endpoint.backlog Defines the number of connections in the listen queue.By default, one-to-many style sockets do not accept new associations. If applicationsthat use one-to-many style socket APIs call the accept() API to accept newassociations, SCTP returns theEOPNOTSUPP error to the application. In the one-to-manystyle socket APIs, new associations are accepted automatically and notifications of thenew associations are delivered using the recvmsg() API with theSCTP_ASSOC_CHANGE event (if these notifications are enabled). A client in aone-to-many association does not call listen(). Therefore, clients can be assured thatthe only associations on the socket are the associations that are actively initiated. Onthe contrary, a server or a peer-to-peer socket in a one-to-many connection alwaysaccepts new associations. Therefore, an application running on a server using aone-to-many style API must be prepared to handle new associations from unwantedpeers.The SCTP_ASSOC_CHANGE event provides the association ID for a new association. Ifapplications want to use the association ID as input for other socket calls, they mustensure 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 receivedata from its peer.ssize_t sendmsg(int sd, const struct msghdr *message, int flags);

ssize_t recvmsg(int sd, struct msghdr *message, int flags);

where:sd Specifies the socket descriptor.message Specifies the pointer to the msghdr structure, which contains a single user

message and the ancillary data.flags Contains flags that affect messages that are being sent and received.

Different Socket API Styles 51

The close() Socket API

Applications use close() to gracefully shutdown all the associations represented bya one-to-many style socket.Following is the syntax for the close() socket API:close(int sd);

where:sd Specifies the socket descriptor of the associations to be closed.To gracefully shutdown a specific association that is represented by the one-to-manystyle socket, an application must use the sendmsg() call and include the MSG_EOFflag. A user can optionally terminate an association non-gracefully by sending theMSG_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 thesendmsg() 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 anassociation without sending data.Following is the syntax for the connect() socket API:connect(int sd, const struct sockaddr *nam, socklen_t len);

where:sd Specifies the socket descriptor for a new association.len Specifies the size of the address.Multiple connect() calls can be made on the same socket to create multipleassociations. In UDP, a connect() call cannot make multiple associations on the samesocket.

API Options to Modify Socket BehaviorThis 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 applicationsto 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-levelcommunications protocol interface, such as IP, TCP, or SCTP.

52 SCTP Socket APIs

You can use thegetsockopt() andsetsockopt() system calls to modify the socketoptions. These system calls set or retrieve socket interface options, or lower-levelprotocol options.Following is the syntax for the getsockopt() system call:int getsockopt( int s, int level, int optname, void *optval, int *optlen);

where:s Indicates the file descriptor.level Specifies the type of protocol. You must set the level to IPPROTO_SCTP

for all the SCTP options.optname Specifies the option name.optval Specifies the buffer to store the value of the option.optlen Specifies the size of the buffer (or the length of the option returned).Following is the syntax for the setsockopt() API:int setsockopt( int s, int level, int optname,const void *optval, int optlen );

where:s Indicates the file descriptor.level Specifies the type of protocol. You must set the level to IPPROTO_SCTP

for all SCTP options.optname Specifies the option name.optval Specifies the buffer to store the value of the option.optlen Specifies the size of the buffer (or the length of the option returned).SCTP associations being multihomed, certain option parameters include thesockaddr_storage structure to select the peer address to which the option must beapplied. 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 theoption. Applications must set this association ID while using a one-to-many API stylesocket. In the case of one-to-one style socket APIs and the branched off one-to-manystyle 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 allassociations that belong to a socket. For a one-to-one API, the socket options apply toall peer addresses of the association controlled by the socket.In the SCTP stack, the getsockopt() is read-only. This means that applications cannotspecify any information in the getsockopt() call. As a result, applications must usethe sctp_opt_info() API to pass information both into and out of the SCTP stack.Following is the syntax for the sctp_opt_info() API:int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg, socklen_t *size);

where:id Specifies the association ID. For a one-to-many style socket, id specifies the

association to query. For a one-to-one style socket, SCTP ignores the ID.opt Specifies the SCTP socket option. The sctp_opt_info() API retrieves socket

options, specified as follows:• SCTP_RTOINFO

• SCTP_ASSOCINFO

• SCTP_DEFAULT_SEND_PARAM

• SCTP_GET_PEER_ADDR_INFO

• SCTP_PRIMARY_ADDR

• SCTP_PEER_ADDR_PARAMS

• SCTP_STATUS

sctp_opt_info() does not support the authentication related-optionsSCTP_AUTH_CHUNKS,SCTP_AUTH_SECRET, andSCTP_PEER_AUTH_CHUNKS.

arg Specifies an option-specific structure buffer that is provided by an application.The sctp_opt_info() API returns 0 on success, and returns -1 on failure. It setserrno to the appropriate error code.The sctp_opt_info() call is a replacement for getsockopt(), andsctp_opt_info() does not set any option associated with the specified socket. Youmust use the setsockopt() call to set any writeable option, such as SO_LINGER andSCTP_NODELAY.

Common Socket CallsThis section discusses socket calls that are common to both one-to-one and one-to-manystyle APIs.

54 SCTP Socket APIs

The send(), sendto(), recv(), and recvfrom() Socket CallsApplications can use the send() and sendto() socket calls to transmit data to thepeer. The recv() and recvfrom() socket calls can be used to receive data from thepeer.Following are the syntaxes for the send(), sendto(), recv(), and recvfrom()socket calls, respectively:ssize_t send(int sd, const void *msg, size_t len, int flags);ssize_t sendto(int sd, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen);ssize_t recv(int sd, void *buf, size_t len, int flags);ssize_t recvfrom(int sd, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen);

where:sd Specifies the socket descriptor of an SCTP endpoint.msg Specifies the message to be sent.len Specifies the size of the message or the size of buffer.to Specifies one of the peer addresses of the association to be used to send

the message.tolen Specifies the size of the address.buf Specifies the buffer to store a received message.from Specifies the buffer to store the peer address used to send the received

message.fromlen Specifies the size of the from address.flags Contains flags affecting the message being sent.The send(), sendto(), recv(), and recvfrom() calls provide access to only basicSCTP protocol features. If a peer in an association uses multiple streams or sendsunordered data, these calls may not be adequate. As a result, it may deliver data inunpredictable ways.These calls do not allow the application to specify the stream on which a message mustbe sent. SCTP uses stream 0 as the default stream to send data using send() andsendto(). Therecv() andrecvfrom() calls return data from any stream. However,the application cannot distinguish the different streams. As a result, data arrives withoutany order. Similarly, if an application sends unordered data chunk, recv() andrecvfrom() 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 mustcombine all the buffers, before calling send() and sendto(). Alternately, the callercan 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, SCTPrejects the request with an appropriate error message.

The setsocktopt() and getsockopt() Socket CallsApplications use the setsockopt() and the getsockopt() calls to set and retrievesocket options. You can use the socket options to modify the default behavior of thesockets calls. For information on socket options, see “API Options to Modify SocketBehavior” (page 52).

NOTE: While using the SCTP_ASSOCINFO option to set the maximum number ofretransmissions, the sctp_opt_info() call does not fail if this number is greater thanthe sum of all maximum path retransmissions for each remote address. Therefore, thesuccess or failure of this option does not depend on the number of remote addressesand whether the association is up.

Following are the syntaxes for the getsockopt() and setsockopt() socket calls,respectively:getsockopt(int sd, int level, int optname, void *optval, socklen_t *optlen);setsockopt(int sd, int level, int optname, const void *optval, socklen_t optlen);

where:sd Specifies the socket description.level Specifies the type of protocol. You must set the level to IPPROTO_SCTP

for all SCTP options.optname Specifies the option name.optval Specifies the buffer to store the value of the option.optlen Specifies the size of the buffer (or the length of the option returned).

NOTE: A positive linger time for the SO_LINGER option results in an immediatetermination of the process following the SCTP shutdown.

The read() and write() Socket CallsApplications use read() and write() socket calls to send and receive data to andfrom 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 onlywith branched off socket descriptors.

56 SCTP Socket APIs

The getsockname() Socket CallApplications use getsockname() to retrieve the locally-bound socket address of thespecified 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. AnHP-UX socket uses its copy of the bound address to implement the getsockname()system call.Following is the syntax for the getsockname() socket call: int getsockname(int sd, struct sockaddr *address, socklen_t *len);

where:sd Specifies the socket descriptor to be queried.address Stores the locally bound address that is selected by the SCTP stack. If the

socket is an IPv4 socket, the address will be an IPv4 address. If the socketis an IPv6 socket, the address can be either an IPv6 or IPv4 address.

len Specifies the length of the address.If the actual length of the address is greater than the length of the sockaddr structure,the stored address is truncated. If the socket is not bound to a local name, the valuecontained in the address variable is not specified.

SCTP Events and NotificationsAn event refers to a change in the network status, association startups, remoteoperational errors, or undeliverable messages. An SCTP application must understandand 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 particularevent, the SCTP application can set the appropriate socket option for notifications inthe setsockopt() call. You can configure an SCTP application to send notificationsusing the setsockoptg() call. When an SCTP application sends a recvmsg() callto another application at the peer endpoint, the SCTP application normally reads thedata message from the peer endpoint. For information on recvmsg(), see “Thesendmsg() and recvmsg() Socket APIs” (page 47).If the SCTP application reads a non-data message, the application sets the messagenotification flag in the recvmsg() API. When the notification arrives, recvmsg()returns the notification in the application-supplied data buffer in themsg_iovparameter,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 asingle read is not sufficient, MSG_EOR is not set in the msg_flags parameter. The SCTPapplication 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, seedraft-ietf-tsvwg-sctpsocket-10.txt

SCTP Ancillary Data StructuresThe SCTP socket APIs can use the ancillary data structures to enable applications tocontrol an association. These structures also enable SCTP to notify applications aboutassociation events.The ancillary data mechanism uses the definition ofstruct msghdr, which is availableto an SCTP application when it uses the X/Open socket.

NOTE: An application that uses BSD43 socket cannot use the features related toancillary data.

SCTP processes each ancillary data using the cmsghdr structure, which defines thefunction and purpose of the data. Following is the structure for the cmsghdr structure:struct cmsghdr { socklen_t cmsg_len; int cmsg_level; int cmsg_type; };

Where:cms_len Specifies the number of bytes, including the header.cmsg_level Specifies the originating protocol.cmsg_type Specifies the type of the protocol followed by an unsigned character,

cmsg_data.For the structure definition of the msghdr structure, see “The sendmsg() and recvmsg()Socket APIs” (page 47).

58 SCTP Socket APIs

An SCTP application can use ancillary data structures to communicate certain aspectsof 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

setupSCTP provides the following ancillary data structures:• SCTP Initiation Structure• SCTP Header InformationThe 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 usesan SCTP initiation structure to set the protocol parameters for a new association. TheSCTP 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 theIPPROTO_SCTP level.Following is the data structure for the sctp_initmsg structure:struct sctp_initmsg { uint16_t sinit_num_ostreams; uint16_t sinit_max_instreams; uint16_t sinit_max_attempts; uint16_t sinit_max_init_timeo;};

where:sinit_num_ostreams Represents the number of outbound streams.sinit_num_ostreams Represents the number of inbound streams to be

supported.sinit_max_instreams Represents the maximum number of times INITmust

be transmitted before giving up an association setup.sinit_max_init_timeo Represents the largest time out value to use in

attempting a INIT.The values provided by an application are for a association and overrides the defaultvalues.

SCTP Header Information (SCTP_SNDRCV)An application uses the SCTP header information to describe the SCTP headerinformation of a message that is received through the recvmsg() call, and to specifythe SCTP options for the sendmsg() call. The SCTP header information is representedby the sctp_sndrcvinfo ancillary data structure. The name of the ancillary datatype 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 thesctp_sndrcvinfo structure to set and get various control information from the SCTPendpoint.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

sendmsg()recvmsg()Variable

Specifies the stream number to which theapplication wants to send the message.

Specifies the stream number of themessage.

sinfo_stream

Not applicableContains the stream sequence numberin the DATA chunk.

sinfo_ssn

Specifies an opaque unsigned value thatis passed to the remote endpoint in eachuser message.

Specifies the information that is passedby the upper layer in the peerapplication.

sinfo_ppid

Specifies an opaque context data that ispassed back to the application whilereporting an error on the concernedsendmsg() call.

Not applicablesinfo_context

Specifies the flag that controls the sendbehavior of the data chunk, or theassociation itself. For example,sendmsg() contains theMSG_UNORDREDflag to indicate unordered send of data,and MSG_EOF to close a givenassociation.

Specifies the flag (MSG_UNORDRED) toinform the application that the messagereceived was unordered. Therecvmsg() API contains only one flag(MSG_UNORDRED), whereas thesendmsg()API contains multiple flags.

sinfo_flags

Specifies the time-to-live (TTL) for agiven message. If an application does notsend a message within the specified TTLvalue, the message expires and anotification is sent to the application, ifnotification is enabled.

Not applicablesinfo_timetolive

60 SCTP Socket APIs

Table 2-1 Data Structures in the recvmsg() and sendmsg() Calls (continued)

sendmsg()recvmsg()Variable

Not applicableSpecifies the transmission sequencenumber (TSN) assigned to one of theSCTP data chunks.

sinfo_tsn

Not applicableSpecifies the cumulative TSN, whilepresenting an unordered message (if theMSG_UNORDRED flag is set)

sinfo_cumtsn

Specifies the association ID.Specifies the association ID.sinfo_assoc_id

SCTP-Specific Socket APIsThis 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() APIThe following subsections discuss these APIs in detail.

The sctp_bindx() SCTP Socket APIApplications can use the sctp_bindx() API to associate with multiple addresses.Following is the syntax for the sctp_bindx() socket API: int sctp_bindx(int sd, struct sockaddr *addrs, int addrcnt, int flags);

where:sd Specifies the socket descriptor. If sd is an IPv4 socket, the addresses passed

must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passedcan either be an IPv4 or an IPv6 addresses.

addrs Specifies a pointer to an array of one or more socket addresses. Eachaddress 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 IPv4socket, sctp_bindx() returns an array of type sockaddr_in.

addrcnt Specifies the number of addresses in the array (sockaddr_in6 orsockaddr_in). You cannot use wildcard addresses withsctp_bindx().

flags Contains flags affecting the message that is being sent. The flags parameteris 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 theassociation, and SCTP_BINDX_REM_ADDR directs SCTP to remove thegiven addresses from the association. These flags are mutually exclusive.

On success, sctp_bindx() returns 0. On failure, sctp_bindx() returns -1, and setserrno to the appropriate error code.

The sctp_peeloff() SCTP Socket APIApplications can use the sctp_peeloff() socket API to branch off an associationinto a separate socket. This API is a one-to-one style socket API.Following is the syntax for the sctp_peeloff() socket API:sctp_peeloff(int sd, sctp_assoc_t assoc_id)

where:sd Specifies the socket descriptor representing the branched-off association.assoc_id Specifies the identifier of the association that must be branched off to a

separate file descriptor.

The sctp_getpaddrs() SCTP Socket APIApplications can use the sctp_getpaddrs() socket API to return all peer addressesin an association.Following is the syntax for the sctp_getpaddrs() socket API:int sctp_getpaddrs(int sd, sctp_assoc_t id, struct sockaddr **addrs);

where:sd Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned

will be IPv4 addresses. If sd is an IPv6 socket, the addresses returned can beeither an IPv4 or an IPv6 addresses.

id Specifies the association ID. For one-to-many style sockets, ID specifies theassociation to query. An application ignores id for one-to-one style sockets.

addrs Points to the dynamically allocated array of sockaddr structures of theappropriate 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 theassociation. 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 APIApplications must use the sctp_freepaddrs() socket API to free all resourcesallocated by the sctp_getpaddrs() API.Following is the syntax for the sctp_freepaddrs() socket API:void sctp_freepaddrs(struct sockaddr *addrs);

where:addrs Specifies the array of peer addresses returned by sctp_getpaddrs().

The sctp_getladdrs() SCTP Socket APIApplications can use the sctp_getladdrs() SCTP socket API to return all the locallybound addresses on a socket.Following is the syntax for the sctp_getladdrs() SCTP socket API:int sctp_getladdrs(int sd, sctp_assoc_t id, struct sockaddr **ss);

where:sd Specifies the socket descriptor. If sd is an IPv4 socket, the addresses returned will

be an IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be eitheran IPv4 or IPv6 address.

id Specifies the association ID. For one-to-many style sockets, id specifies theassociation to query. An application ignores id for one-to-one style sockets. If idis set to 0 (zero), the locally bound addresses are returned irrespective of theparticular association.

ss Points to a dynamically allocated array of sockaddr structures of the appropriatesocket type.

An application must use sctp_freeaddrs() to free the memory that is allocated bysctp_getladdrs(), to store addresses.On success, sctp_getladdrs() returns the number of local addresses bound to thesocket. 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 thevalue of *addrs is left undefined.

SCTP-Specific Socket APIs 63

The sctp_freeladdrs() SCTP Socket APIApplications use the sctp_freeladdrs() API to free all resources allocated by thesctp_getladdrs() socket API.Following is the syntax for the sctp_freeladdrs() API:void sctp_freeladdrs(struct sockaddr *addrs);

where:addrs Specifies the array of peer addresses returned by the sctp_getladdrs()

socket API.

The sctp_sendmsg() SCTP Socket APIApplications can use sctp_sendmsg() to send an SCTP message. This API is similarto the sendmsg() call, with the SCTP_SNDRCV option.Following is the syntax for the sctp_sendmsg() SCTP socket API: ssize_t sctp_sendmsg(int sd, const void *msg, size_t len, const struct sockaddr *to, socklen_t tolen, uint32_t ppid, uint32_t flags, uint16_t stream_no, uint32_t timetolive, uint32_t context)

where:sd Specifies the socket descriptor.msg Specifies the message to be sent.len Specifies the length of the message.to Specifies the destination address of the message.tolen Specifies the length of the destination address.ppid Specifies the payload protocol identifier, which is entered in the

payload protocol identifier field of the SCTP data header.flags Contains flags affecting the message being sent.stream_no Contains the stream number of the message.timetolive Specifies the TTL value for a message in milliseconds.context Specifies a 32-bit unsigned integer that is used by sendmsg(). When

an application fails to send the data and an SCTP_SEND_FAILEDnotification is sent to the upper layer in the peer application, anapplication returns context as part of the information.

64 SCTP Socket APIs

The sctp_recvmsg() SCTP Socket APIApplications can use thesctp_recvmsg() SCTP socket API to receive messages. ThisAPI is similar to the recvmsg() API, with the SCTP_SNDRCV option. For thesctp_sndrcvinfo structure to be populated by sctp_recvmsg(), an applicationmust enable the sctp_data_io_events with the SCTP_EVENTS option.Following is the syntax for the sctp_recvmsg() socket API: ssize_t sctp_recvmsg(int sd, void *msg, size_t len, struct sockaddr *from, socklen_t *fromlen struct sctp_sndrcvinfo *sinfo int *msg_flags)

where:sd Specifies the socket descriptor.msg Specifies a message buffer.len Specifies the length of the message buffer.from Specifies the sender of a message.fromlen Specifies the length of the address.sinfo Denotes a pointer to an sctp_sndrcvinfo structure that is filled after

the message is received.msg_flags Denotes a pointer to an integer to be filled with a message flag.

The sctp_connectx() SCTP Socket APIApplications can use the sctp_connectx() SCTP socket API to associate to anendpoint that is multihomed. This API enables an application to specify multipleaddresses on which a peer can be reached. This API only specifies that the SCTP willtry to make use of all the addresses in the list when required.Following is the syntax for the sctp_connectx() SCTP socket API: int sctp_connectx(int sd, struct sockaddr *addrs, int addrcnt)

where:sd Specifies the socket descriptor.addrs Specifies an array of addresses.addrcnt Specifies the number of addresses in the array.The list of addresses passed to sctp_connectx() is used only for setting up theassociation and does not specify the set of addresses the peer uses for the resultingassociation. If applications want to find out the set of peer addresses, applications mustuse the sctp_getpaddrs() to retrieve them after the association is set up.

SCTP-Specific Socket APIs 65

The sctp_send() SCTP Socket APIApplications can use the sctp_send() SCTP socket API to send data without usingthe cmsg header structures. This API is similar to the sendmsg() API, with theSCTP_SNDRCV option.Following is the syntax for the sctp_send() SCTP socket API: int sctp_send(int sd, const void *msg, size_t len, const struct sctp_sndrcvinfo *sinfo, int flags);

where:sd Specifies the socket descriptor.msg Specifies the message to be sent.len Specifies the length of the message.sinfo Specifies a pointer to a sctp_sndrcvinfo structure that is used for a

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 tothe association that must be terminated. In this case, the length of the message is 0(zero).

The sctp_sendx() SCTP Socket APIApplications can use the sctp_sendx() SCTP socket API to send data, without usingthe cmsg header structures that provide a list of addresses.Following is the syntax for the sctp_sendx() SCTP socket API: int sctp_sendx(int sd, const void *msg, size_t len, struct sockaddr *addrs, int addrcnt, struct sctp_sndrcvinfo *sinfo, int flags);

where:sd Specifies the socket descriptor.msg Specifies the message to be sent.len Specifies the length of the message.addrs Specifies an array of addresses.addrcnt Specifies the number of addresses in the array.

66 SCTP Socket APIs

sinfo Specifies a pointer to an sctp_sndrcvinfo structure used for asendmsg() call.

flags Contains flags in the same format as thesendmsg() call flags (for example,MSG_DONTROUTE)

This API can also be used to terminate an association using an association ID, by settingthe sinfo.sinfo_flags to MSG_EOF, and the sinfo.sinf_associd to theassociation that must be terminated. In such a case, the length of the message is 0 (zero).

SCTP-Specific Socket APIs 67

68

3 Compiling and Running Applications that Use the SCTPSocket 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 usethe 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-specificlibrary.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 APIsBefore 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 defineit while compiling the application.

To compile an application program that uses the SCTP APIs, enter the followingcommand at the HP-UX prompt:# cc –o <output_filename> -D_XOPEN_SOURCE_EXTENDED<input_filename> -lxnet –lsctp

where:output_filename Specifies the executable file name.-D_XOPEN_SOURCE_EXTENDED Specifies the XOPEN macro. You need to specify

this macro while compiling only if you have notdefined it in your application program. For moreinformation on the XOPEN_SOURCE_EXTENDEDmacro, see xopen_networking(7).

input_filename Specifies the name of the application program.

Compiling Applications that Use the SCTP APIs 69

-lxnet Specifies the /usr/lib/libxnet library. Thisoption indicates that the application programmust use the libraries defined in this libraryduring compilation.

-lsctp Specifies the libsctp library. This optionindicates that the application program must usethe libraries defined in this library duringcompilation.

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 APIsThis section discusses how to run the sample applications that are compiled using theSCTP APIs.Consider the sample server and client applications listed in Appendix A (page 75) forone-to-one and one-to-many connections. These sample applications are available inthe /usr/lib/demos/networking/sctp directory.To run the sample server application, enter the following command:# ./srv_app <port_number>

where:srv_app Specifies the executable file.port_number Specifies the port number on which the server accepts connections.

Example 3-2 Sample Command to Run the Server Application

To run the sample server application in a one-to-one or one-to-many connection, enterthe following command:# ./srv_app 6000

The following output is displayed:{one-to-one}: Waiting for associations ...

This output denotes that the server is ready to accept connections on port 6000.

To run the sample client application , enter the following command:

70 Compiling and Running Applications that Use the SCTP Socket APIs

#./cli_app <ip_address> <port_number>

where:cli_app Specifies the executable file.ip_address Specifies the IP address of the server to which the client wants to

connect.port_number Specifies the port number on which the server accepts connections.

NOTE: Before running the server and client applications, ensure thatsctpd is runningon 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, enterthe 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 onthe port 6000.

Running Sample Applications that use the SCTP APIs 71

72

4Migrating TCP Applications to SCTPThis 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 stackwithout 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, asfollows: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 theapplication, because this header file is already included in the TCP applications.

• To enable TCP applications to use the advanced features of SCTP, such as sendingand receiving ancillary information, and receiving event notifications, TCPapplications can use the sendmsg() and recvmsg() calls. However, applicationsmust define the_XOPEN_SOURCE_EXTENDEDmacro and the/usr/lib/libxnetlibrary while compiling the application, because only the X/OPEN style msghdrstructure supports the ancillary mechanism.SCTP APIs provide applications with an alternate method to read and writeancillary information, and receive event notifications, without using the msghdrstructure. The alternate method is to use the sctp_sendmsg() andsctp_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 orreceiving data. However, in an SCTP stack, an FTP application can use only onesocket and use two streams within the same association to achieve the samefunctionality as that of TCP.

• HTTP applications can use the multi-streaming feature, such as multiple querieswithin the same page wherein queries can be sent in parallel.

73

74

A SCTP Sample ProgramsThis appendix lists the sample programs for a client and server, in both one-to-one andone-to-many associations.

Sample Server ProgramsThis section lists the sample server programs in one-to-one and one-to-manyassociations.This section addresses the following topics:• “One-to-One Server Program”• “One-to-Many Server Program” (page 77)

One-to-One Server ProgramThe following sample program is an implementation of an echo server over SCTP ina 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 voidhandle_event(void *buf){ struct sctp_assoc_change *sac; struct sctp_send_failed *ssf; struct sctp_paddr_change *spc; struct sctp_remote_error *sre; union sctp_notification *snp; char addrbuf[INET6_ADDRSTRLEN]; const char *ap; struct sockaddr_in *sin; struct sockaddr_in6 *sin6;

snp = buf;

switch (snp->sn_header.sn_type) { case SCTP_ASSOC_CHANGE: sac = &snp->sn_assoc_change; printf("^^^ assoc_change: state=%hu, error=%hu, instr=%hu " "outstr=%hu\n", sac->sac_state, sac->sac_error, sac->sac_inbound_streams, sac->sac_outbound_streams); break;

case SCTP_SEND_FAILED: ssf = &snp->sn_send_failed;

Sample Server Programs 75

printf("^^^ sendfailed: len=%hu err=%d\n", ssf->ssf_length, ssf->ssf_error); break;

case SCTP_PEER_ADDR_CHANGE: spc = &snp->sn_paddr_change; if (spc->spc_aaddr.ss_family == AF_INET) { sin = (struct sockaddr_in *)&spc->spc_aaddr; ap = inet_ntop(AF_INET, &sin->sin_addr, addrbuf, INET6_ADDRSTRLEN); } else { sin6 = (struct sockaddr_in6 *)&spc->spc_aaddr; ap = inet_ntop(AF_INET6, &sin6>sin6_addr, addrbuf, INET6_ADDRSTRLEN); } printf("^^^ intf_change: %s state=%d, error=%d\n", ap, spc->spc_state, spc->spc_error); break;

case SCTP_REMOTE_ERROR: sre = &snp->sn_remote_error; printf("^^^ remote_error: err=%hu len=%hu\n", ntohs(sre->sre_error), ntohs(sre->sre_length)); break;

case SCTP_SHUTDOWN_EVENT: printf("^^^ shutdown event\n"); break;

default: printf("unknown type: %hu\n", snp->sn_header.sn_type); break; }}

int main(int argc, char **argv){ int fd, new_fd, sz, len, msg_flags; int idleTime = 20; struct sockaddr_in sin[1], cli_addr; struct sctp_event_subscribe event; char readbuf[100]; struct sctp_sndrcvinfo sri; fd_set fdset;

if (argc < 2) { printf ("\nUsage: <%s> \n\n", argv[0]); return -1; }

if ((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) == -1) { perror("socket"); exit(1); }

sin->sin_family = AF_INET; sin->sin_port = htons(atoi(argv[1])); sin->sin_addr.s_addr = INADDR_ANY; if (bind(fd, (struct sockaddr *)sin, sizeof (*sin)) == -1) { perror("bind"); exit(1); }

/* Allow new associations to be accepted */ if (listen(fd, 1) < 0) {

76 SCTP Sample Programs

perror("listen"); exit(1); }

memset (&sri, 0, sizeof(sri));

printf ("{one-to-one}: Waiting for associations ...\n");

FD_ZERO(&fdset); FD_SET(fd, &fdset);

/* Wait for new associations */ while(1) { if (select (fd+1, &fdset, 0, 0, 0) <= 0) continue;

new_fd = accept (fd, (struct sockaddr *) &cli_addr, (socklen_t *) &le); if (new_fd >=0 ) printf ("\n Connection from: %s\n", inet_ntoa(cli_addr.sin_addr));

/* Not interested in any events for now */ memset (&event, 0, sizeof(event)); if (setsockopt(new_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror("setevent failed"); exit(1); }

while (1) { /* Echo back any and all data */ memset (readbuf, 0, sizeof(readbuf)); len = sizeof (struct sockaddr_in);

#if 0 sz = recv(new_fd, readbuf, sizeof(readbuf), 0); if (debug) printf ("recv:[%d,e:%d]: ", sz, errno);#endif sz = sctp_recvmsg (new_fd, readbuf, sizeof(readbuf), 0, 0, &sri, 0); if (debug) printf ("sctp_recvmsg:[%d,e:%d,fl:%X]: ", sz, errno, msg_flags); if (sz <= 0) break; printf ("<-- %s on str: %d\n", readbuf, sri.sinfo_stream); sz = sctp_sendmsg (new_fd, readbuf, sz, 0, len, 0, 0, sri.sinfo_stream, 0, 0); if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno); } close(new_fd); }

/* unreachable */ close(fd);}

One-to-Many Server ProgramThe following sample program is an implementation of an echo server over SCTP ina 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 voidhandle_event(void *buf){ struct sctp_assoc_change *sac; struct sctp_send_failed *ssf; struct sctp_paddr_change *spc; struct sctp_remote_error *sre; union sctp_notification *snp; char addrbuf[INET6_ADDRSTRLEN]; const char *ap; struct sockaddr_in *sin; struct sockaddr_in6 *sin6;

snp = buf;

switch (snp->sn_header.sn_type) { case SCTP_ASSOC_CHANGE: sac = &snp->sn_assoc_change; printf("^^^ assoc_change: state=%hu, error=%hu, instr=%hu " "outstr=%hu\n", sac->sac_state, sac->sac_error, sac->sac_inbound_streams, sac->sac_outbound_streams); break;

case SCTP_SEND_FAILED: ssf = &snp->sn_send_failed; printf("^^^ sendfailed: len=%hu err=%d\n", ssf->ssf_length, ssf->ssf_error); break;

case SCTP_PEER_ADDR_CHANGE: spc = &snp->sn_paddr_change; if (spc->spc_aaddr.ss_family == AF_INET) { sin = (struct sockaddr_in *)&spc->spc_aaddr; ap = inet_ntop(AF_INET, &sin->sin_addr, addrbuf, INET6_ADDRSTRLEN); } else { sin6 = (struct sockaddr_in6 *)&spc->spc_aaddr; ap = inet_ntop(AF_INET6, &sin6>sin6_addr, addrbuf, INET6_ADDRSTRLEN); } printf("^^^ intf_change: %s state=%d, error=%d\n", ap, spc->spc_state, spc->spc_error); break;

case SCTP_REMOTE_ERROR: sre = &snp->sn_remote_error; printf("^^^ remote_error: err=%hu len=%hu\n", ntohs(sre->sre_error), ntohs(sre->sre_length)); break;

case SCTP_SHUTDOWN_EVENT:

78 SCTP Sample Programs

printf("^^^ shutdown event\n"); break;

default: printf("unknown type: %hu\n", snp->sn_header.sn_type); break; }}

int main(int argc, char **argv){ int fd, sz, len, msg_flags; int idleTime = 20; struct sockaddr_in sin[1], cli_addr; struct sctp_event_subscribe event; char readbuf[100]; struct sctp_sndrcvinfo sri;

if (argc < 2) { printf ("\nUsage: <%s> <port>\n\n", argv[0]); return -1; }

if ((fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) == -1) { perror("socket"); exit(1); }

sin->sin_family = AF_INET; sin->sin_port = htons(atoi(argv[1])); sin->sin_addr.s_addr = INADDR_ANY; if (bind(fd, (struct sockaddr *)sin, sizeof (*sin)) == -1) { perror("bind"); exit(1); }

#if 0 /* Not interested in any events for now */ memset (&event, 0, sizeof(event));#else /* Enable all events */ event.sctp_data_io_event = 1; event.sctp_association_event = 1; event.sctp_address_event = 1; event.sctp_send_failure_event = 1; event.sctp_peer_error_event = 1; event.sctp_shutdown_event = 1; event.sctp_partial_delivery_event = 1; event.sctp_adaption_layer_event = 1;#endif if (setsockopt(fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror("setevent failed"); exit(1); }

/* Set associations to auto-close in 20 seconds of * inactivity */ if (setsockopt(fd, IPPROTO_SCTP, SCTP_AUTOCLOSE, &idleTime, 4) < 0) { perror("setsockopt SCTP_AUTOCLOSE"); exit(1); }

/* Allow new associations to be accepted */

Sample Server Programs 79

if (listen(fd, 1) < 0) { perror("listen"); exit(1); }

memset (&sri, 0, sizeof(sri));

printf ("{one-to-many}: Waiting for associations ...\n");

/* Wait for new associations */ while(1) { /* Echo back any and all data */ memset (readbuf, 0, sizeof(readbuf)); len = sizeof (struct sockaddr_in); sz = sctp_recvmsg (fd, readbuf, sizeof(readbuf), &cli_addr, &len, &sri, &msg_flags); if (debug) printf ("sctp_recvmsg:[%d,e:%d,fl:%X]: ", sz, errno, msg_flags); if (sz <= 0) break; if (msg_flags & MSG_NOTIFICATION) { handle_event(readbuf); continue; } printf ("<-- %s on str: %d\n", readbuf, sri.sinfo_stream); sz = sctp_sendmsg (fd, readbuf, sz, &cli_addr, len, sri.sinfo_ppid, sri.sinfo_flags, sri.sinfo_stream, 0, 0); if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno); } close(fd);}

Sample Client ProgramsThis section lists the sample client programs for both one-to-one and one-to-manyassociations.This section addresses the following topics:• “One-to-One Client Program”• “One-to-Many Client Program” (page 82)

One-to-One Client ProgramThe following sample program is an implementation of an echo client over SCTP in aone-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 ("\nUsage: <%s> <remote-ip> <port> \n\n", argv[0]); return -1; }

serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons (atoi(argv[2])); serv_addr.sin_addr.s_addr = inet_addr(argv[1]);

sock_fd = socket (AF_INET, SOCK_STREAM, IPPROTO_SCTP); if (sock_fd == -1) { printf ("\nUnable to create socket \n"); return -1; }

if (connect (sock_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) { printf ("\nUnable to connect to remote server [%s] !! \n\n", inet_ntoa(serv_addr.sin_addr)); return -1; } else { printf ("\nConnected to [%s]\n", inet_ntoa(serv_addr.sin_addr)); }

memset (&event, 0, sizeof(event)); if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror("setevent failed"); exit(1); }

memset (buf, 0, sizeof(buf)); len = sizeof(serv_addr); printf ("<S>: ");

while (fgets(buf, 256, stdin)) { if (buf[0] != '[') { if (!strncmp(buf, "exit", 4))

Sample Client Programs 81

break; printf ("Error, line must be of the form '[stream#]text'\n"); continue; } sri.sinfo_stream = strtol(buf+1, NULL, 0); sz = strlen(buf);

len = sizeof(serv_addr); sz = sctp_sendmsg (sock_fd, buf, sz, 0, len, 0, 0, sri.sinfo_stream, 0, 0); if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno); if (sz <= 0) break;

sz = sctp_recvmsg (sock_fd, buf, sizeof(buf), 0, 0, &sri, &msg_flags); if (debug) printf ("sctp_recvmsg:[%d,e:%d] ", sz, errno); if (sz <= 0) break; printf ("<-- %s on str %d\n", buf, sri.sinfo_stream);

memset (buf, 0, sizeof(buf)); printf ("<S>: "); }

printf ("\nOver !!\n"); close (sock_fd);

return 0;}

One-to-Many Client ProgramThe following sample program is an implementation of an echo client over SCTP in aone-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 ("\nUsage: <%s> <remote-ip> <port> \n\n", argv[0]); return -1; }

serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons (atoi(argv[2])); serv_addr.sin_addr.s_addr = inet_addr(argv[1]);

sock_fd = socket (AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP); if (sock_fd == -1) { printf ("\nUnable to create socket \n"); return -1; }

if (connect (sock_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) { printf ("\nUnable to connect to remote server [%s] !! \n\n", inet_ntoa(serv_addr.sin_addr)); return -1; } else { printf ("\nConnected to [%s]\n", inet_ntoa(serv_addr.sin_addr)); }

memset (&event, 0, sizeof(event)); if (setsockopt(sock_fd, IPPROTO_SCTP, SCTP_EVENTS, &event, sizeof(event)) != 0) { perror("setevent failed"); exit(1); }

memset (buf, 0, sizeof(buf)); len = sizeof(serv_addr); printf ("<S>: ");

while (fgets(buf, 256, stdin)) { if (buf[0] != '[') { if (!strncmp(buf, "exit", 4)) break; printf ("Error, line must be of the form '[stream#]text'\n"); continue; } sri.sinfo_stream = strtol(buf+1, NULL, 0); sz = strlen(buf);

Sample Client Programs 83

len = sizeof(serv_addr); sz = sctp_sendmsg (sock_fd, buf, sz, &serv_addr, len, 0, 0, sri.sinfo_stream, 0, 0); if (debug) printf ("sctp_sendmsg:[%d,e:%d]\n", sz, errno);

sz = sctp_recvmsg (sock_fd, buf, sizeof(buf), &serv_addr, &len, &sri, &msg_flags); if (debug) printf ("sctp_recvmsg:[%d,e:%d] ", sz, errno); if (sz <= 0) break; printf ("<-- %s on str %d\n", buf, sri.sinfo_stream);

memset (buf, 0, sizeof(buf)); printf ("<S>: "); }

printf ("\nOver !!\n"); close (sock_fd);

return 0;}

84 SCTP Sample Programs

GlossaryBundling 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.CongestionWindow

An SCTP variable that limits the data (in bytes) that a sender can send to a particular destinationtransport address before receiving an acknowledgement.

MaximumTransmissionUnit

The Maximum Transmission Unit (MTU) determines the maximum size of the packet that issupported by a communications protocol.

Message Data submitted to SCTP by the Upper Layer Protocol (ULP).Path The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport

address of its peer SCTP endpointReceiverWindow

An SCTP variable that a sender uses to store the most recently calculated receiver window (inbytes) of its peer. The value of rwnd indicates the space available in the receiver's inbound buffer.

SCTPassociation

A protocol relationship between two SCTP endpoints. The association also contains the protocolstate information that includes verification tags and the currently active set of TSNs. An associationcan be uniquely identified by the transport addresses used by the endpoints in the association.

SCTPendpoint

The logical sender or receiver of SCTP packets. On a multi-homed host, an SCTP endpoint isrepresented to its peers as a combination of a set of eligible destination transport addresses towhich SCTP packets can be sent and a set of eligible source transport addresses from which SCTPpackets can be received. All transport addresses used by an SCTP endpoint must use the sameport number but the endpoint can use multiple IP addresses. A transport address is unique to anSCTP endpoint. Therefore, a transport address used by an SCTP endpoint must not be used byanother 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 controlchunks, and user data encapsulated within SCTP DATA chunks.

Slow StartThreshold

An SCTP variable. This is the threshold (in bytes) that the endpoint uses to determine whetherto 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 theunordered delivery service.

StreamSequenceNumber

A 16-bit sequence number used by SCTP to assure sequenced delivery of the user messages withina given stream. One stream sequence number is attached to each user message.

TransmissionControl Block

The transmission control block (TCB) is an internal data structure created by an SCTP endpointfor each SCTP association. TCB contains the status and operational information for the endpointto maintain and manage the association.

TransmissionSequenceNumber

The transmission sequence number (TSN) is a 32-bit sequence number used by SCTP. One TSNis attached to each chunk containing user data to permit the receiving SCTP endpoint toacknowledge its receipt and detect duplicate deliveries.

Transportaddress

A transport address is defined by the network layer address, the transport layer protocol, andthe 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 thetransport protocol).

UnorderedMessage

Unordered messages are "unordered" with respect to any other message, this includes both otherunordered and ordered messages. Unordered message can be delivered before or later thanordered messages sent on the same stream.

VerificationTag

A 32-bit unsigned integer that is randomly generated. The verification tag provides a key thatallows a receiver to verify that the SCTP packet belongs to the current association and is not anold or stale packet from a previous association.

86 Glossary

Index

Symbols-lsctp library, 70-lxnet library, 70/usr/lib/libsctp library, 73/usr/lib/libxnet library, 70, 73

AABORT chunk, 25, 32achieving half-closed state

in SCTP, 46ACK packet, 22acknowledge packet (see ACK packet)addrcnt parameter, 62address length (see addrlen)address size (see tolen)addrlen, 45addrs parameter, 61, 62alternate IP address, 29ancillary data structure (see sctp_initmsg structure) (see

sctp_sndrcvinfo)associating an endpoint, 44

Bbacklog, 51

of outstanding associations, 45blind masquerade attack, 39branched off socket, 56branching an association, 62

socket descriptor, 62buffer size, 53, 55

Cchanging outbound streams

number of (see SCTP_INITMSG)chunk data, 25chunk flag, 25chunk length, 25cmsghdr structure, 58congestion window, 26control chunk

information, 24COOKIE ACK chunk, 24COOKIE ECHO chunk, 24cookie field, 22COOKIE-ACK chunk, 23COOKIE-ECHO chunk, 22creating a socket, 43, 49cwnd variable, 26

DD_XOPEN_SOURCE_EXTENDED macro, 69data boundaries, 31DATA chunk, 24, 37default stream

in SCTP, 55delayed acknowledgement, 32denial of service attack (see DoS)difference in TCP and SCTP, 46disabling receive operation

at an endpoint, 46disabling send operation

at an endpoint, 46DoS, 19

preventing, 21

Eenabling multihoming, 44endpoint failure, 38EOPNOTSUPP error, 51ERROR chunk, 25ESTABLISHED state, 45existing socket APIs, 41

Ffour-way handshake, 22, 38

overcome delay, 23four-way initiation handshake, 45freeing resources, 63, 64fromlen paremeter, 55

Ggap

in transmission sequence, 30getsockopt() call, 53getting control information (see scto_sndrcvinfo structure)gracefully closing

an association, 46

Hhalf-closed state

in TCP, 46half-open connection, 31head-of-line blocking (see HOL)HEARTBEAT ACK chunk, 25HEARTBEAT chunk, 25, 38HOL, 19, 30HP-specific library (see libsctp)

87

IIN6ADDR_ANY option, 46IN6ADDR_ANY_INIT option, 44INADDR_ANY option, 44, 46INIT ACK chunk, 24INIT chunk, 24INIT-ACK chunk, 22Initiate tag, 39initiating an association, 45IP stack

application layer, 21data link layer, 20network layer, 20physical layer, 20socket layer, 21transport layer

SCTP, 20IPPROTO_SCTP, 53IPPROTO_SCTP parameter, 44IPPROTO_SCTP value, 56

Llibsctp library, 69libxnet library, 69

Mmaximum transmission unit (see MTU)message buffer, 55message size, 55migrate

existing TCP application, 42migrating TCP applications

to SCTP,benefits of, 73

MSG_ABORT flag, 52msg_control parameter, 47msg_controllen parameter, 47MSG_EOF flag, 52msg_flags parameter, 47msg_iov parameter, 47, 57msg_iovlen parameter, 47msg_name parameter, 47msg_namelen parameter, 47MSG_NOTIFICATION flag, 57msghdr structure, 47MTU, 25multihoming, 42

enabling, 44overcoming network failure, 29overcoming path failure, 29

multistreaming, 42avoid HOL blocking, 30

Nnew_sd parameter, 45

Oone-to-many client

call sequence, 49one-to-one client

call sequence, 43optlen, 53

buffer size, 53optlen parameter, 56optname, 53optname parameter, 53, 56optval, 53optval paremeter, 53, 56

Ppartial bytes acknowledged, 27partial_byte_acked variable, 27passing data

into the SCTP stack (see sctp_opt_info() call)payload data chunk, 24PF_INET parameter, 43PF_INET6 parameter, 43preparing an endpoint

for accepting associations, 45primary address, 29

Rreceiver window, 26receiving data, 47receiving messages, 65removing an association

from the accept queue, 45retransmission timeout (see RTO)retrieving a socket, 48retrieving socket option, 53RFC 2581, 26RFC 2960, 25RTO, 37rwnd variable, 26

SSACK chunk, 24, 37SCTP

COOKIE-ACK chunk, 23COOKIE-ECHO chunk, 22data boundaries, 31default stream, 31definition, 17draft compliance, 18four-way handshake, 22INIT chunk, 22INIT-ACK chunk, 22RFC compliance, 18

SCTP notification structure, 57SCTP packet

chunk type, 24common header, 24

88 Index

control chunk, 24DATA chunk, 24SID, 24

SCTP_ASSOC_CHANGE event, 51SCTP_AUTOCLOSE option, 49SCTP_EVENTS option, 65SCTP_INITMSG option, 45sctp_initmsg structure, 59sctp_notification structure, 57sctp_opt_info() call, 54SCTP_SNDRCV option, 64, 65sctp_sndrcvinfo structure, 60selecting peer address (see sockaddr_storage)setsockoptg() call, 57setting control information (see scto_sndrcvinfo structure)setting socket option, 53SHUT_RD parameter, 46SHUT_RDWR parameter, 46SHUT_WR parameter, 46shutdown

types of, 46SHUTDOWN ACK chunk, 25SHUTDOWN chunk, 25SHUTDOWN COMPLETE chunk, 25shutdown() call

difference in SCTP and TCP, 46SID, 24, 30sinfo.sinf_associd flag, 66sinfo.sinfo_flags flag, 66single-homed connection, 28slow start threshold variable, 26SO_LINGER option, 56SOCK_SEQPACKET parameter, 50SOCK_STREAM parameter, 44sockaddr_in structure, 44, 50, 62sockaddr_in6 strcuture, 44sockaddr_in6 structure, 50, 62sockaddr_storage, 53socket descriptor

creating, 43for new association (see new_sd)

specifying local address, 50specifying multiple addresses, 65specifying protocol level (see IPPROTO_SCTP)SSN, 24, 30Stream Control Transmission Protocol (see SCTP)stream identifier (see SID)stream sequence number (see SSN)SYN packet, 22SYN-ACK packet, 22SYN-flooding, 17Synchronize packet (see SYN packet)synchronize-acknowledge packet (see SYN-ACK packet)

TTCB, 38TCP

ACK packet, 22data boundaries, 31half-open connection , 31single-homed connection, 28SYN flood attack, 19SYN packet, 22SYN-ACK packet, 22the PUSH flag, 19three-way handshake, 21

time-to-live (see TTL)tolen parameter, 55transmission control block (see TCB)Transmission Control Protocol (see TCP)transmission sequence number (see TSN)transmitting data, 47

to a peer, 55TSN, 24, 30TTL, 60, 64

Uunordered bit, 25User Datagram Protocol (see UDP)

Vverification tag, 22

XXOPEN library (see see libxnet library)XOPEN macro (see D_XOPEN_SOURCE_EXTENDED)XOPEN_SOURCE_EXTENDED macro, 69

89