draft-ietf-tsvwg-sctpsocket-11.txt   draft-ietf-tsvwg-sctpsocket-12.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: March 11, 2006 Q. Xie Expires: August 21, 2006 Q. Xie
Motorola, Inc. Motorola, Inc.
L. Yarroll L. Yarroll
TimeSys Corp TimeSys Corp
J. Wood
DoCoMo USA Labs
K. Poon K. Poon
Sun Microsystems, Inc. Sun Microsystems, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
September 7, 2005 February 17, 2006
Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
draft-ietf-tsvwg-sctpsocket-11.txt draft-ietf-tsvwg-sctpsocket-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2006. This Internet-Draft will expire on August 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a mapping of the Stream Control Transmission This document describes a mapping of the Stream Control Transmission
Protocol SCTP RFC2960 [8] into a sockets API. The benefits of this Protocol SCTP RFC2960 [RFC2960] into a sockets API. The benefits of
mapping include compatibility for TCP applications, access to new this mapping include compatibility for TCP applications, access to
SCTP features and a consolidated error and event notification scheme. new SCTP features and a consolidated error and event notification
scheme.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 6
3. one-to-many style Interface . . . . . . . . . . . . . . . . . 8 3. one-to-many style Interface . . . . . . . . . . . . . . . . . 6
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. socket() - one-to-many style socket . . . . . . . . . 9 3.1.1. socket() - one-to-many style socket . . . . . . . . . 7
3.1.2. bind() - one-to-many style socket . . . . . . . . . . 10 3.1.2. bind() - one-to-many style socket . . . . . . . . . . 8
3.1.3. listen() - One-to-many style socket . . . . . . . . . 11 3.1.3. listen() - One-to-many style socket . . . . . . . . . 9
3.1.4. sendmsg() and recvmsg() - one-to-many style socket . . 11 3.1.4. sendmsg() and recvmsg() - one-to-many style socket . . 9
3.1.5. close() - one-to-many style socket . . . . . . . . . . 13 3.1.5. close() - one-to-many style socket . . . . . . . . . . 11
3.1.6. connect() - one-to-many style socket . . . . . . . . . 13 3.1.6. connect() - one-to-many style socket . . . . . . . . . 11
3.2. Implicit Association Setup . . . . . . . . . . . . . . . . 14 3.2. Implicit Association Setup . . . . . . . . . . . . . . . . 12
3.3. Non-blocking mode . . . . . . . . . . . . . . . . . . . . 14 3.3. Non-blocking mode . . . . . . . . . . . . . . . . . . . . 13
3.4. Special considerations . . . . . . . . . . . . . . . . . . 15 3.4. Special considerations . . . . . . . . . . . . . . . . . . 13
4. one-to-one style Interface . . . . . . . . . . . . . . . . . . 18 4. one-to-one style Interface . . . . . . . . . . . . . . . . . . 15
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 18 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. socket() - one-to-one style socket . . . . . . . . . . 19 4.1.1. socket() - one-to-one style socket . . . . . . . . . . 16
4.1.2. bind() - one-to-one style socket . . . . . . . . . . . 19 4.1.2. bind() - one-to-one style socket . . . . . . . . . . . 16
4.1.3. listen() - one-to-one style socket . . . . . . . . . . 20 4.1.3. listen() - one-to-one style socket . . . . . . . . . . 17
4.1.4. accept() - one-to-one style socket . . . . . . . . . . 21 4.1.4. accept() - one-to-one style socket . . . . . . . . . . 18
4.1.5. connect() - one-to-one style socket . . . . . . . . . 21 4.1.5. connect() - one-to-one style socket . . . . . . . . . 18
4.1.6. close() - one-to-one style socket . . . . . . . . . . 22 4.1.6. close() - one-to-one style socket . . . . . . . . . . 19
4.1.7. shutdown() - one-to-one style socket . . . . . . . . . 22 4.1.7. shutdown() - one-to-one style socket . . . . . . . . . 19
4.1.8. sendmsg() and recvmsg() - one-to-one style socket . . 23 4.1.8. sendmsg() and recvmsg() - one-to-one style socket . . 20
4.1.9. getpeername() . . . . . . . . . . . . . . . . . . . . 24 4.1.9. getpeername() . . . . . . . . . . . . . . . . . . . . 20
5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 25 5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The msghdr and cmsghdr Structures . . . . . . . . . . . . 25 5.1. The msghdr and cmsghdr Structures . . . . . . . . . . . . 21
5.2. SCTP msg_control Structures . . . . . . . . . . . . . . . 26 5.2. SCTP msg_control Structures . . . . . . . . . . . . . . . 22
5.2.1. SCTP Initiation Structure (SCTP_INIT) . . . . . . . . 27 5.2.1. SCTP Initiation Structure (SCTP_INIT) . . . . . . . . 23
5.2.2. SCTP Header Information Structure (SCTP_SNDRCV) . . . 28 5.2.2. SCTP Header Information Structure (SCTP_SNDRCV) . . . 24
5.3. SCTP Events and Notifications . . . . . . . . . . . . . . 31 5.3. SCTP Events and Notifications . . . . . . . . . . . . . . 27
5.3.1. SCTP Notification Structure . . . . . . . . . . . . . 31 5.3.1. SCTP Notification Structure . . . . . . . . . . . . . 27
5.4. Ancillary Data Considerations and Semantics . . . . . . . 42 5.4. Ancillary Data Considerations and Semantics . . . . . . . 38
5.4.1. Multiple Items and Ordering . . . . . . . . . . . . . 43 5.4.1. Multiple Items and Ordering . . . . . . . . . . . . . 38
5.4.2. Accessing and Manipulating Ancillary Data . . . . . . 43 5.4.2. Accessing and Manipulating Ancillary Data . . . . . . 38
5.4.3. Control Message Buffer Sizing . . . . . . . . . . . . 43 5.4.3. Control Message Buffer Sizing . . . . . . . . . . . . 39
6. Common Operations for Both Styles . . . . . . . . . . . . . . 45 6. Common Operations for Both Styles . . . . . . . . . . . . . . 40
6.1. send(), recv(), sendto(), recvfrom() . . . . . . . . . . . 45 6.1. send(), recv(), sendto(), recvfrom() . . . . . . . . . . . 40
6.2. setsockopt(), getsockopt() . . . . . . . . . . . . . . . . 46 6.2. setsockopt(), getsockopt() . . . . . . . . . . . . . . . . 41
6.3. read() and write() . . . . . . . . . . . . . . . . . . . . 46 6.3. read() and write() . . . . . . . . . . . . . . . . . . . . 42
6.4. getsockname() . . . . . . . . . . . . . . . . . . . . . . 46 6.4. getsockname() . . . . . . . . . . . . . . . . . . . . . . 42
7. Socket Options . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Socket Options . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Read / Write Options . . . . . . . . . . . . . . . . . . . 49 7.1. Read / Write Options . . . . . . . . . . . . . . . . . . . 44
7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) . . . 49 7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) . . . 44
7.1.2. Association Parameters (SCTP_ASSOCINFO) . . . . . . . 50 7.1.2. Association Parameters (SCTP_ASSOCINFO) . . . . . . . 45
7.1.3. Initialization Parameters (SCTP_INITMSG) . . . . . . . 52 7.1.3. Initialization Parameters (SCTP_INITMSG) . . . . . . . 46
7.1.4. SO_LINGER . . . . . . . . . . . . . . . . . . . . . . 52 7.1.4. SO_LINGER . . . . . . . . . . . . . . . . . . . . . . 47
7.1.5. SCTP_NODELAY . . . . . . . . . . . . . . . . . . . . . 52 7.1.5. SCTP_NODELAY . . . . . . . . . . . . . . . . . . . . . 47
7.1.6. SO_RCVBUF . . . . . . . . . . . . . . . . . . . . . . 53 7.1.6. SO_RCVBUF . . . . . . . . . . . . . . . . . . . . . . 47
7.1.7. SO_SNDBUF . . . . . . . . . . . . . . . . . . . . . . 53 7.1.7. SO_SNDBUF . . . . . . . . . . . . . . . . . . . . . . 47
7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE) . . . 53 7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE) . . . 48
7.1.9. Set Peer Primary Address 7.1.9. Set Peer Primary Address
(SCTP_SET_PEER_PRIMARY_ADDR) . . . . . . . . . . . . . 53 (SCTP_SET_PEER_PRIMARY_ADDR) . . . . . . . . . . . . . 48
7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR) . . . . . . . 54 7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR) . . . . . . . 48
7.1.11. Set Adaption Layer Indicator (SCTP_ADAPTION_LAYER) . . 54 7.1.11. Set Adaptation Layer Indicator
(SCTP_ADAPTATION_LAYER) . . . . . . . . . . . . . . . 49
7.1.12. Enable/Disable message fragmentation 7.1.12. Enable/Disable message fragmentation
(SCTP_DISABLE_FRAGMENTS) . . . . . . . . . . . . . . . 55 (SCTP_DISABLE_FRAGMENTS) . . . . . . . . . . . . . . . 49
7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) . . . 55 7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) . . . 49
7.1.14. Set default send parameters 7.1.14. Set default send parameters
(SCTP_DEFAULT_SEND_PARAM) . . . . . . . . . . . . . . 57 (SCTP_DEFAULT_SEND_PARAM) . . . . . . . . . . . . . . 52
7.1.15. Set notification and ancillary events (SCTP_EVENTS) . 57 7.1.15. Set notification and ancillary events (SCTP_EVENTS) . 52
7.1.16. Set/clear IPv4 mapped addresses 7.1.16. Set/clear IPv4 mapped addresses
(SCTP_I_WANT_MAPPED_V4_ADDR) . . . . . . . . . . . . . 57 (SCTP_I_WANT_MAPPED_V4_ADDR) . . . . . . . . . . . . . 53
7.1.17. Set the maximum fragmentation size (SCTP_MAXSEG) . . . 57 7.1.17. Set the maximum fragmentation size (SCTP_MAXSEG) . . . 53
7.1.18. Add a chunk that must be authenticated 7.1.18. Add a chunk that must be authenticated
(SCTP_AUTH_CHUNK) . . . . . . . . . . . . . . . . . . 58 (SCTP_AUTH_CHUNK) . . . . . . . . . . . . . . . . . . 53
7.1.19. Set the endpoint pair shared key (SCTP_AUTH_KEY) . . . 58 7.1.19. Set the endpoint pair shared key (SCTP_AUTH_KEY) . . . 54
7.1.20. Get the list of chunks the peer requires to be 7.1.20. Get the list of chunks the peer requires to be
authenticated (SCTP_PEER_AUTH_CHUNKS) . . . . . . . . 59 authenticated (SCTP_PEER_AUTH_CHUNKS) . . . . . . . . 54
7.1.21. Get the list of chunks the local endpoint requires 7.1.21. Get the list of chunks the local endpoint requires
to be authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . 60 to be authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . 55
7.1.22. Set the list of supported HMAC Identifiers 7.1.22. Set the list of supported HMAC Identifiers
(SCTP_HMAC_IDENT) . . . . . . . . . . . . . . . . . . 60 (SCTP_HMAC_IDENT) . . . . . . . . . . . . . . . . . . 55
7.1.23. Get or set the active key 7.1.23. Get or set the active key
(SCTP_AUTH_SETKEY_ACTIVE) . . . . . . . . . . . . . . 61 (SCTP_AUTH_SETKEY_ACTIVE) . . . . . . . . . . . . . . 55
7.1.24. Get or set delayed ack timer 7.1.24. Get or set delayed ack timer
(SCTP_DELAYED_ACK_TIME) . . . . . . . . . . . . . . . 63 (SCTP_DELAYED_ACK_TIME) . . . . . . . . . . . . . . . 56
7.2. Read-Only Options . . . . . . . . . . . . . . . . . . . . 63 7.1.25. Get or set fragmented interleave
7.2.1. Association Status (SCTP_STATUS) . . . . . . . . . . . 63 (SCTP_FRAGMENT_INTERLEAVE) . . . . . . . . . . . . . . 57
7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO) . . 65 7.1.26. Set or Get the sctp partial delivery point
7.3. Ancillary Data and Notification Interest Options . . . . . 65 (SCTP_PARTIAL_DELIVERY_POINT) . . . . . . . . . . . . 57
8. New Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 69 7.2. Read-Only Options . . . . . . . . . . . . . . . . . . . . 58
8.1. sctp_bindx() . . . . . . . . . . . . . . . . . . . . . . . 69 7.2.1. Association Status (SCTP_STATUS) . . . . . . . . . . . 58
8.2. Branched-off Association . . . . . . . . . . . . . . . . . 70 7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO) . . 59
8.3. sctp_getpaddrs() . . . . . . . . . . . . . . . . . . . . . 71 7.3. Ancillary Data and Notification Interest Options . . . . . 60
8.4. sctp_freepaddrs() . . . . . . . . . . . . . . . . . . . . 71 8. New Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 62
8.5. sctp_getladdrs() . . . . . . . . . . . . . . . . . . . . . 71 8.1. sctp_bindx() . . . . . . . . . . . . . . . . . . . . . . . 62
8.6. sctp_freeladdrs() . . . . . . . . . . . . . . . . . . . . 72 8.2. Branched-off Association . . . . . . . . . . . . . . . . . 63
8.7. sctp_sendmsg() . . . . . . . . . . . . . . . . . . . . . . 72 8.3. sctp_getpaddrs() . . . . . . . . . . . . . . . . . . . . . 64
8.8. sctp_recvmsg() . . . . . . . . . . . . . . . . . . . . . . 73 8.4. sctp_freepaddrs() . . . . . . . . . . . . . . . . . . . . 64
8.9. sctp_connectx() . . . . . . . . . . . . . . . . . . . . . 74 8.5. sctp_getladdrs() . . . . . . . . . . . . . . . . . . . . . 65
8.10. sctp_send() . . . . . . . . . . . . . . . . . . . . . . . 75 8.6. sctp_freeladdrs() . . . . . . . . . . . . . . . . . . . . 65
8.11. sctp_sendx() . . . . . . . . . . . . . . . . . . . . . . . 75 8.7. sctp_sendmsg() . . . . . . . . . . . . . . . . . . . . . . 66
9. Preprocessor Constants . . . . . . . . . . . . . . . . . . . . 77 8.8. sctp_recvmsg() . . . . . . . . . . . . . . . . . . . . . . 66
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 8.9. sctp_connectx() . . . . . . . . . . . . . . . . . . . . . 67
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 8.10. sctp_send() . . . . . . . . . . . . . . . . . . . . . . . 67
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.11. sctp_sendx() . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix A. one-to-one style Code Example . . . . . . . . . . . . 80 8.12. sctp_getaddrlen . . . . . . . . . . . . . . . . . . . . . 69
Appendix B. one-to-many style Code Example . . . . . . . . . . . 86 9. Preprocessor Constants . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 70
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.1. Normative references . . . . . . . . . . . . . . . . . . . 71
13.2. Informational References . . . . . . . . . . . . . . . . . 71
Appendix A. one-to-one style Code Example . . . . . . . . . . . . 71
Appendix B. one-to-many style Code Example . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79
Intellectual Property and Copyright Statements . . . . . . . . . . 81
1. Introduction 1. Introduction
The sockets API has provided a standard mapping of the Internet The sockets API has provided a standard mapping of the Internet
Protocol suite to many operating systems. Both TCP RFC793 [1] and Protocol suite to many operating systems. Both TCP RFC793 [RFC0793]
UDP RFC768 [2] have benefited from this standard representation and and UDP RFC768 [RFC0768] have benefited from this standard
access method across many diverse platforms. SCTP is a new protocol representation and access method across many diverse platforms. SCTP
that provides many of the characteristics of TCP but also is a new protocol that provides many of the characteristics of TCP
incorporates semantics more akin to UDP. This document defines a but also incorporates semantics more akin to UDP. This document
method to map the existing sockets API for use with SCTP, providing defines a method to map the existing sockets API for use with SCTP,
both a base for access to new features and compatibility so that most providing both a base for access to new features and compatibility so
existing TCP applications can be migrated to SCTP with few (if any) that most existing TCP applications can be migrated to SCTP with few
changes. (if any) changes.
There are three basic design objectives: There are three basic design objectives:
1) Maintain consistency with existing sockets APIs: 1) Maintain consistency with existing sockets APIs:
We define a sockets mapping for SCTP that is consistent with other We define a sockets mapping for SCTP that is consistent with other
sockets API protocol mappings (for instance, UDP, TCP, IPv4, and sockets API protocol mappings (for instance, UDP, TCP, IPv4, and
IPv6). IPv6).
2) Support a one-to-many style interface 2) Support a one-to-many style interface
This set of semantics is similar to that defined for connection- This set of semantics is similar to that defined for connection-
less protocols, such as UDP. A one-to-many style SCTP socket less protocols, such as UDP. A one-to-many style SCTP socket
should be able to control multiple SCTP associations. This is should be able to control multiple SCTP associations. This is
similar to an UDP socket, which can communicate with many peer end similar to an UDP socket, which can communicate with many peer end
points. Each of these associations is assigned an association ID points. Each of these associations is assigned an association ID
so that an applications can use the ID to differentiate them. so that an applications can use the ID to differentiate them.
Note that SCTP is connection-oriented in nature, and it does not Note that SCTP is connection-oriented in nature, and it does not
support broadcast or multicast communications, as UDP does. support broadcast or multicast communications, as UDP does.
3) Support a one-to-one style interface 3) Support a one-to-one style interface
This interface supports a similar semantics as sockets for This interface supports a similar semantics as sockets for
connection-oriented protocols, such as TCP. A one-to-one style connection-oriented protocols, such as TCP. A one-to-one style
SCTP socket should only control one SCTP association. SCTP socket should only control one SCTP association.
One purpose of defining this interface is to allow existing One purpose of defining this interface is to allow existing
applications built on other connection-oriented protocols be applications built on other connection-oriented protocols be
ported to use SCTP with very little effort. And developers ported to use SCTP with very little effort. And developers
familiar with those semantics can easily adapt to SCTP. Another familiar with those semantics can easily adapt to SCTP. Another
purpose is to make sure that existing mechanisms in most OSes to purpose is to make sure that existing mechanisms in most OSes to
deal with socket, such as select(), should continue to work with deal with socket, such as select(), should continue to work with
this style of socket. this style of socket.
Extensions are added to this mapping to provide mechanisms to Extensions are added to this mapping to provide mechanisms to
exploit new features of SCTP. exploit new features of SCTP.
Goals 2 and 3 are not compatible, so in this document we define two Goals 2 and 3 are not compatible, so in this document we define two
modes of mapping, namely the one-to-many style mapping and the one- modes of mapping, namely the one-to-many style mapping and the one-
to-one style mapping. These two modes share some common data to-one style mapping. These two modes share some common data
structures and operations, but will require the use of two different structures and operations, but will require the use of two different
application programming styles. Note that all new SCTP features can application programming styles. Note that all new SCTP features can
be used with both styles of socket. The decision on which one to use be used with both styles of socket. The decision on which one to use
depends mainly on the nature of applications. depends mainly on the nature of applications.
skipping to change at page 9, line 12 skipping to change at page 7, line 27
between different associations, the sendto() call can only be used to between different associations, the sendto() call can only be used to
setup an association implicitly. It cannot be used to send data to setup an association implicitly. It cannot be used to send data to
an established association as the association ID cannot be specified. an established association as the association ID cannot be specified.
Once as association ID is assigned to an SCTP association, that ID Once as association ID is assigned to an SCTP association, that ID
will not be reused until the application explicitly terminates the will not be reused until the application explicitly terminates the
association. The resources belonged to that association will not be association. The resources belonged to that association will not be
freed until that happens. This is similar to the close() operation freed until that happens. This is similar to the close() operation
on a normal socket. The only exception is when the SCTP_AUTOCLOSE on a normal socket. The only exception is when the SCTP_AUTOCLOSE
option (section 7.1.8) is set. In this case, after the association option (section 7.1.8) is set. In this case, after the association
is terminated automatically, the association ID assigned to it can be is terminated gracefully automatically, the association ID assigned
reused. All applications using this option should be aware of this to it can be reused. All applications using this option should be
to avoid the possible problem of sending data to an incorrect peer aware of this to avoid the possible problem of sending data to an
end point. incorrect peer end point.
If the server or client wishes to branch an existing association off If the server or client wishes to branch an existing association off
to a separate socket, it is required to call sctp_peeloff() and in to a separate socket, it is required to call sctp_peeloff() and in
the parameter specifies the association identification. The the parameter specifies the association identification. The
sctp_peeloff() call will return a new socket which can then be used sctp_peeloff() call will return a new socket which can then be used
with recv() and send() functions for message passing. See with recv() and send() functions for message passing. See
Section 8.2 for more on branched-off associations. Section 8.2 for more on branched-off associations.
Once an association is branched off to a separate socket, it becomes Once an association is branched off to a separate socket, it becomes
completely separated from the original socket. All subsequent completely separated from the original socket. All subsequent
skipping to change at page 10, line 18 skipping to change at page 8, line 32
Applications use bind() to specify which local address the SCTP Applications use bind() to specify which local address the SCTP
endpoint should associate itself with. endpoint should associate itself with.
An SCTP endpoint can be associated with multiple addresses. To do An SCTP endpoint can be associated with multiple addresses. To do
this, sctp_bindx() is introduced in section Section 8.1 to help this, sctp_bindx() is introduced in section Section 8.1 to help
applications do the job of associating multiple addresses. applications do the job of associating multiple addresses.
These addresses associated with a socket are the eligible transport These addresses associated with a socket are the eligible transport
addresses for the endpoint to send and receive data. The endpoint addresses for the endpoint to send and receive data. The endpoint
will also present these addresses to its peers during the association will also present these addresses to its peers during the association
initialization process, see RFC2960 [8]. initialization process, see RFC2960 [RFC2960].
After calling bind(), if the endpoint wishes to accept new After calling bind(), if the endpoint wishes to accept new
associations on the socket, it must call listen() (see section associations on the socket, it must call listen() (see section
Section 3.1.3). Section 3.1.3).
The syntax of bind() is, The syntax of bind() is,
ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen); ret = bind(int sd, struct sockaddr *addr, socklen_t addrlen);
sd: the socket descriptor returned by socket(). sd - the socket descriptor returned by socket().
addr - the address structure (struct sockaddr_in or struct
addr: the address structure (struct sockaddr_in or struct sockaddr_in6 RFC2553 [RFC2553]).
sockaddr_in6 RFC2553 [7]). addrlen - the size of the address structure.
addrlen: the size of the address structure.
If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv4 socket, the address passed must be an IPv4 address.
If the sd is an IPv6 socket, the address passed can either be an IPv4 If the sd is an IPv6 socket, the address passed can either be an IPv4
or an IPv6 address. or an IPv6 address.
Applications cannot call bind() multiple times to associate multiple Applications cannot call bind() multiple times to associate multiple
addresses to an endpoint. After the first call to bind(), all addresses to an endpoint. After the first call to bind(), all
subsequent calls will return an error. subsequent calls will return an error.
If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, If addr is specified as a wildcard (INADDR_ANY for an IPv4 address,
skipping to change at page 11, line 4 skipping to change at page 9, line 15
If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, If addr is specified as a wildcard (INADDR_ANY for an IPv4 address,
or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the
operating system will associate the endpoint with an optimal address operating system will associate the endpoint with an optimal address
set of the available interfaces. set of the available interfaces.
If a bind() is not called prior to a sendmsg() call that initiates a If a bind() is not called prior to a sendmsg() call that initiates a
new association, the system picks an ephemeral port and will choose new association, the system picks an ephemeral port and will choose
an address set equivalent to binding with a wildcard address. One of an address set equivalent to binding with a wildcard address. One of
those addresses will be the primary address for the association. those addresses will be the primary address for the association.
This automatically enables the multi-homing capability of SCTP. This automatically enables the multi-homing capability of SCTP.
3.1.3. listen() - One-to-many style socket 3.1.3. listen() - One-to-many style socket
By default, new associations are not accepted for one-to-many style By default, new associations are not accepted for one-to-many style
sockets. An application uses listen() to mark a socket as being able sockets. An application uses listen() to mark a socket as being able
to accept new associations. The syntax is, to accept new associations. The syntax is,
int listen(int sd, int backlog); int listen(int sd, int backlog);
sd - the socket descriptor of the endpoint. sd - the socket descriptor of the endpoint.
backlog - if backlog is non-zero, enable listening else backlog - if backlog is non-zero, enable listening else disable
disable listening. listening.
Note that one-to-many style socket consumers do not need to call Note that one-to-many style socket consumers do not need to call
accept to retrieve new associations. Calling accept() on a one-to- accept to retrieve new associations. Calling accept() on a one-to-
many style socket should return EOPNOTSUPP. Rather, new associations many style socket should return EOPNOTSUPP. Rather, new associations
are accepted automatically, and notifications of the new associations are accepted automatically, and notifications of the new associations
are delivered via recvmsg() with the SCTP_ASSOC_CHANGE event (if are delivered via recvmsg() with the SCTP_ASSOC_CHANGE event (if
these notifications are enabled). Clients will typically not call these notifications are enabled). Clients will typically not call
listen(), so that they can be assured that the only associations on listen(), so that they can be assured that the only associations on
the socket will be ones they actively initiated. Server or peer-to- the socket will be ones they actively initiated. Server or peer-to-
peer sockets, on the other hand, will always accept new associations, peer sockets, on the other hand, will always accept new associations,
skipping to change at page 11, line 44 skipping to change at page 10, line 9
3.1.4. sendmsg() and recvmsg() - one-to-many style socket 3.1.4. sendmsg() and recvmsg() - one-to-many style socket
An application uses sendmsg() and recvmsg() call to transmit data to An application uses sendmsg() and recvmsg() call to transmit data to
and receive data from its peer. and receive data from its peer.
ssize_t sendmsg(int sd, const struct msghdr *message, int flags); ssize_t sendmsg(int sd, const struct msghdr *message, int flags);
ssize_t recvmsg(int sd, struct msghdr *message, int flags); ssize_t recvmsg(int sd, struct msghdr *message, int flags);
sd: the socket descriptor of the endpoint. sd - the socket descriptor of the endpoint.
message: pointer to the msghdr structure which contains a single user message: pointer to the msghdr structure which contains a single user
message and possibly some ancillary data. See Section 5 for message and possibly some ancillary data. See Section 5 for
complete description of the data structures. complete description of the data structures.
flags - No new flags are defined for SCTP at this level. See Section
flags: No new flags are defined for SCTP at this level. See Section
5 for SCTP-specific flags used in the msghdr structure. 5 for SCTP-specific flags used in the msghdr structure.
As we will see in Section 5, along with the user data, the ancillary As we will see in Section 5, along with the user data, the ancillary
data field is used to carry the sctp_sndrcvinfo and/or the data field is used to carry the sctp_sndrcvinfo and/or the
sctp_initmsg structures to perform various SCTP functions including sctp_initmsg structures to perform various SCTP functions including
specifying options for sending each user message. Those options, specifying options for sending each user message. Those options,
depending on whether sending or receiving, include stream number, depending on whether sending or receiving, include stream number,
stream sequence number, various flags, context and payload protocol stream sequence number, various flags, context and payload protocol
Id, etc. Id, etc.
skipping to change at page 12, line 45 skipping to change at page 11, line 4
applications must use the peer transport address provided in the applications must use the peer transport address provided in the
msg_name field by recvmsg() to perform correlation to an association, msg_name field by recvmsg() to perform correlation to an association,
since they will not have the association ID. since they will not have the association ID.
If all data in a single message has been delivered, MSG_EOR will be If all data in a single message has been delivered, MSG_EOR will be
set in the msg_flags field of the msghdr structure (see section set in the msg_flags field of the msghdr structure (see section
Section 5.1). Section 5.1).
If the application does not provide enough buffer space to completely If the application does not provide enough buffer space to completely
receive a data message, MSG_EOR will not be set in msg_flags. receive a data message, MSG_EOR will not be set in msg_flags.
Successive reads will consume more of the same message until the Successive reads will consume more of the same message until the
entire message has been delivered, and MSG_EOR will be set. entire message has been delivered, and MSG_EOR will be set.
If the SCTP stack is running low on buffers, it may partially deliver If the SCTP stack is running low on buffers, it may partially deliver
a message. In this case, MSG_EOR will not be set, and more calls to a message. In this case, MSG_EOR will not be set, and more calls to
recvmsg() will be necessary to completely consume the message. Only recvmsg() will be necessary to completely consume the message. Only
one message at a time can be partially delivered. one message at a time per stream can be partially delivered.
Note, if the socket is a branched-off socket that only represents one Note, if the socket is a branched-off socket that only represents one
association (see Section 3.1), the msg_name field can be used to association (see Section 3.1), the msg_name field can be used to
override the primary address when sending data. override the primary address when sending data.
3.1.5. close() - one-to-many style socket 3.1.5. close() - one-to-many style socket
Applications use close() to perform graceful shutdown (as described Applications use close() to perform graceful shutdown (as described
in Section 10.1 of RFC2960 [8]) on ALL the associations currently in Section 10.1 of RFC2960 [RFC2960]) on ALL the associations
represented by a one-to-many style socket. currently represented by a one-to-many style socket.
The syntax is: The syntax is:
ret = close(int sd); ret = close(int sd);
sd - the socket descriptor of the associations to be closed. sd - the socket descriptor of the associations to be closed.
To gracefully shutdown a specific association represented by the one- To gracefully shutdown a specific association represented by the one-
to-many style socket, an application should use the sendmsg() call, to-many style socket, an application should use the sendmsg() call,
and including the SCTP_EOF flag. A user may optionally terminate an and including the SCTP_EOF flag. A user may optionally terminate an
skipping to change at page 13, line 40 skipping to change at page 12, line 4
one association, the shutdown is performed on that association only. one association, the shutdown is performed on that association only.
3.1.6. connect() - one-to-many style socket 3.1.6. connect() - one-to-many style socket
An application may use the connect() call in the one-to-many style to An application may use the connect() call in the one-to-many style to
initiate an association without sending data. initiate an association without sending data.
The syntax is: The syntax is:
ret = connect(int sd, const struct sockaddr *nam, socklen_t len); ret = connect(int sd, const struct sockaddr *nam, socklen_t len);
sd - the socket descriptor to have a new association added to.
sd: the socket descriptor to have a new association added to. nam - the address structure (either struct sockaddr_in or struct
sockaddr_in6 defined in RFC2553 [RFC2553]).
nam: the address structure (either struct sockaddr_in or struct len - the size of the address.
sockaddr_in6 defined in RFC2553 [7]).
len: the size of the address.
Multiple connect() calls can be made on the same socket to create Multiple connect() calls can be made on the same socket to create
multiple associations. This is different from the semantics of multiple associations. This is different from the semantics of
connect() on a UDP socket. connect() on a UDP socket.
3.2. Implicit Association Setup 3.2. Implicit Association Setup
Once the bind() call is complete on a one-to-many style socket, the Once the bind() call is complete on a one-to-many style socket, the
application can begin sending and receiving data using the sendmsg()/ application can begin sending and receiving data using the sendmsg()/
recvmsg() or sendto()/recvfrom() calls, without going through any recvmsg() or sendto()/recvfrom() calls, without going through any
explicit association setup procedures (i.e., no connect() calls explicit association setup procedures (i.e., no connect() calls
skipping to change at page 14, line 27 skipping to change at page 12, line 34
dest_addr field in the sendto() call), the SCTP stack will dest_addr field in the sendto() call), the SCTP stack will
automatically setup an association to the intended receiver. automatically setup an association to the intended receiver.
Upon the successful association setup a SCTP_COMM_UP notification Upon the successful association setup a SCTP_COMM_UP notification
will be dispatched to the socket at both the sender and receiver will be dispatched to the socket at both the sender and receiver
side. This notification can be read by the recvmsg() system call side. This notification can be read by the recvmsg() system call
(see Section 3.1.3). (see Section 3.1.3).
Note, if the SCTP stack at the sender side supports bundling, the Note, if the SCTP stack at the sender side supports bundling, the
first user message may be bundled with the COOKIE ECHO message first user message may be bundled with the COOKIE ECHO message
RFC2960 [8]. RFC2960 [RFC2960].
When the SCTP stack sets up a new association implicitly, it first When the SCTP stack sets up a new association implicitly, it first
consults the sctp_initmsg structure, which is passed along within the consults the sctp_initmsg structure, which is passed along within the
ancillary data in the sendmsg() call (see Section 5.2.1 for details ancillary data in the sendmsg() call (see Section 5.2.1 for details
of the data structures), for any special options to be used on the of the data structures), for any special options to be used on the
new association. new association.
If this information is not present in the sendmsg() call, or if the If this information is not present in the sendmsg() call, or if the
implicit association setup is triggered by a sendto() call, the implicit association setup is triggered by a sendto() call, the
default association initialization parameters will be used. These default association initialization parameters will be used. These
skipping to change at page 19, line 43 skipping to change at page 17, line 8
Applications use bind() to pass an address to be associated with an Applications use bind() to pass an address to be associated with an
SCTP endpoint to the system. bind() allows only either a single SCTP endpoint to the system. bind() allows only either a single
address or a IPv4 or IPv6 wildcard address to be bound. An SCTP address or a IPv4 or IPv6 wildcard address to be bound. An SCTP
endpoint can be associated with multiple addresses. To do this, endpoint can be associated with multiple addresses. To do this,
sctp_bindx() is introduced in Section 8.1 to help applications do the sctp_bindx() is introduced in Section 8.1 to help applications do the
job of associating multiple addresses. job of associating multiple addresses.
These addresses associated with a socket are the eligible transport These addresses associated with a socket are the eligible transport
addresses for the endpoint to send and receive data. The endpoint addresses for the endpoint to send and receive data. The endpoint
will also present these addresses to its peers during the association will also present these addresses to its peers during the association
initialization process, see RFC2960 [8]. initialization process, see RFC2960 [RFC2960].
The syntax is: The syntax is:
int bind(int sd, struct sockaddr *addr, socklen_t addrlen); int bind(int sd, struct sockaddr *addr, socklen_t addrlen);
sd: the socket descriptor returned by socket() call.
sd: the socket descriptor returned by socket() call.
addr: the address structure (either struct sockaddr_in or struct addr: the address structure (either struct sockaddr_in or struct
sockaddr_in6 defined in RFC2553 [7]). sockaddr_in6 defined in RFC2553 [RFC2553]).
addrlen: the size of the address structure. addrlen: the size of the address structure.
If sd is an IPv4 socket, the address passed must be an IPv4 address. If sd is an IPv4 socket, the address passed must be an IPv4 address.
Otherwise, i.e., the sd is an IPv6 socket, the address passed can Otherwise, i.e., the sd is an IPv6 socket, the address passed can
either be an IPv4 or an IPv6 address. either be an IPv4 or an IPv6 address.
Applications cannot call bind() multiple times to associate multiple Applications cannot call bind() multiple times to associate multiple
addresses to the endpoint. After the first call to bind(), all addresses to the endpoint. After the first call to bind(), all
subsequent calls will return an error. subsequent calls will return an error.
skipping to change at page 20, line 44 skipping to change at page 18, line 4
with an SCTP ABORT. with an SCTP ABORT.
4.1.3. listen() - one-to-one style socket 4.1.3. listen() - one-to-one style socket
Applications use listen() to ready the SCTP endpoint for accepting Applications use listen() to ready the SCTP endpoint for accepting
inbound associations. inbound associations.
The syntax is: The syntax is:
int listen(int sd, int backlog); int listen(int sd, int backlog);
sd: the socket descriptor of the SCTP endpoint. sd: the socket descriptor of the SCTP endpoint.
backlog: this specifies the max number of outstanding associations backlog: this specifies the max number of outstanding associations
allowed in the socket's accept queue. These are the associations allowed in the socket's accept queue. These are the associations
that have finished the four-way initiation handshake (see Section that have finished the four-way initiation handshake (see Section
5 of RFC2960 [8]) and are in the ESTABLISHED state. Note, a 5 of RFC2960 [RFC2960]) and are in the ESTABLISHED state. Note, a
backlog of '0' indicates that the caller no longer wishes to backlog of '0' indicates that the caller no longer wishes to
receive new associations. receive new associations.
4.1.4. accept() - one-to-one style socket 4.1.4. accept() - one-to-one style socket
Applications use accept() call to remove an established SCTP Applications use accept() call to remove an established SCTP
association from the accept queue of the endpoint. A new socket association from the accept queue of the endpoint. A new socket
descriptor will be returned from accept() to represent the newly descriptor will be returned from accept() to represent the newly
formed association. formed association.
The syntax is: The syntax is:
new_sd = accept(int sd, struct sockaddr *addr, socklen_t *addrlen); new_sd = accept(int sd, struct sockaddr *addr, socklen_t *addrlen);
new_sd: the socket descriptor for the newly formed association. new_sd - the socket descriptor for the newly formed association.
sd - the listening socket descriptor.
sd the listening socket descriptor. addr - on return, will contain the primary address of the peer
addr on return, will contain the primary address of the peer
endpoint. endpoint.
addrlen - on return, will contain the size of addr.
addrlen on return, will contain the size of addr.
4.1.5. connect() - one-to-one style socket 4.1.5. connect() - one-to-one style socket
Applications use connect() to initiate an association to a peer. Applications use connect() to initiate an association to a peer.
The syntax is: The syntax is:
int connect(int sd, const struct sockaddr *addr, socklen_t addrlen); int connect(int sd, const struct sockaddr *addr, socklen_t addrlen);
sd: the socket descriptor of the endpoint. sd - the socket descriptor of the endpoint.
addr - the peer's address.
addr the peer's address. addrlen - the size of the address.
addrlen the size of the address.
This operation corresponds to the ASSOCIATE primitive described in This operation corresponds to the ASSOCIATE primitive described in
section 10.1 of RFC2960 [8]. section 10.1 of RFC2960 [RFC2960].
By default, the new association created has only one outbound stream. By default, the new association created has only one outbound stream.
The SCTP_INITMSG option described in Section 7.1.3 should be used The SCTP_INITMSG option described in Section 7.1.3 should be used
before connecting to change the number of outbound streams. before connecting to change the number of outbound streams.
If a bind() is not called prior to the connect() call, the system If a bind() is not called prior to the connect() call, the system
picks an ephemeral port and will choose an address set equivalent to picks an ephemeral port and will choose an address set equivalent to
binding with INADDR_ANY and IN6ADDR_ANY for IPv4 and IPv6 socket binding with INADDR_ANY and IN6ADDR_ANY for IPv4 and IPv6 socket
respectively. One of those addresses will be the primary address for respectively. One of those addresses will be the primary address for
the association. This automatically enables the multi-homing the association. This automatically enables the multi-homing
capability of SCTP. capability of SCTP.
Note that SCTP allows data exchange, similar to T/TCP RFC1644 [3], Note that SCTP allows data exchange, similar to T/TCP RFC1644
during the association set up phase. If an application wants to do [RFC1644], during the association set up phase. If an application
this, it cannot use connect() call. Instead, it should use sendto() wants to do this, it cannot use connect() call. Instead, it should
or sendmsg() to initiate an association. If it uses sendto() and it use sendto() or sendmsg() to initiate an association. If it uses
wants to change initialization behavior, it needs to use the sendto() and it wants to change initialization behavior, it needs to
SCTP_INITMSG socket option before calling sendto(). Or it can use use the SCTP_INITMSG socket option before calling sendto(). Or it
SCTP_INIT type sendmsg() to initiate an association without doing the can use SCTP_INIT type sendmsg() to initiate an association without
setsockopt(). Note that some sockets implementations may not support doing the setsockopt(). Note that some sockets implementations may
the sending of data to initiate an assocation with the one-to-one not support the sending of data to initiate an assocation with the
style (implementations that do not support T/TCP normally have this one-to-one style (implementations that do not support T/TCP normally
restriction). Implementations which allow sending of data to have this restriction). Implementations which allow sending of data
initiate an association without calling connect() define the to initiate an association without calling connect() define the
preprocessor constant HAVE_SCTP_NOCONNECT to 1. preprocessor constant HAVE_SCTP_NOCONNECT to 1.
SCTP does not support half close semantics. This means that unlike SCTP does not support half close semantics. This means that unlike
T/TCP, SCTP_EOF should not be set in the flags parameter when calling T/TCP, MSG_EOF should not be set in the flags parameter when calling
sendto() or sendmsg() when the call is used to initiate a connection. sendto() or sendmsg() when the call is used to initiate a connection.
SCTP_EOF is not an acceptable flag with SCTP socket. MSG_EOF is not an acceptable flag with SCTP socket.
4.1.6. close() - one-to-one style socket 4.1.6. close() - one-to-one style socket
Applications use close() to gracefully close down an association. Applications use close() to gracefully close down an association.
The syntax is: The syntax is:
int close(int sd); int close(int sd);
sd - the socket descriptor of the association to be closed. sd - the socket descriptor of the association to be closed.
skipping to change at page 23, line 6 skipping to change at page 20, line 4
Hence the shutdown() call for SCTP is an approximation of the TCP Hence the shutdown() call for SCTP is an approximation of the TCP
shutdown() call, and solves some different problems. Full TCP- shutdown() call, and solves some different problems. Full TCP-
compatibility is not provided, so developers porting TCP applications compatibility is not provided, so developers porting TCP applications
to SCTP may need to recode sections that use shutdown(). (Note that to SCTP may need to recode sections that use shutdown(). (Note that
it is possible to achieve the same results as half close in SCTP it is possible to achieve the same results as half close in SCTP
using SCTP streams.) using SCTP streams.)
The syntax is: The syntax is:
int shutdown(int sd, int how); int shutdown(int sd, int how);
sd - the socket descriptor of the association to be closed. sd - the socket descriptor of the association to be closed.
how - Specifies the type of shutdown. The values are as follows:
how - Specifies the type of shutdown. The values are SHUT_RD - Disables further receive operations. No SCTP protocol
as follows: action is taken.
SHUT_WR - Disables further send operations, and initiates the SCTP
SHUT_RD shutdown sequence.
Disables further receive operations. No SCTP SHUT_RDWR - Disables further send and receive operations and
protocol action is taken. initiates the SCTP shutdown sequence.
SHUT_WR
Disables further send operations, and initiates
the SCTP shutdown sequence.
SHUT_RDWR
Disables further send and receive operations
and initiates the SCTP shutdown sequence.
The major difference between SCTP and TCP shutdown() is that SCTP The major difference between SCTP and TCP shutdown() is that SCTP
SHUT_WR initiates immediate and full protocol shutdown, whereas TCP SHUT_WR initiates immediate and full protocol shutdown, whereas TCP
SHUT_WR causes TCP to go into the half closed state. SHUT_RD behaves SHUT_WR causes TCP to go into the half closed state. SHUT_RD behaves
the same for SCTP as TCP. The purpose of SCTP SHUT_WR is to close the same for SCTP as TCP. The purpose of SCTP SHUT_WR is to close
the SCTP association while still leaving the socket descriptor open, the SCTP association while still leaving the socket descriptor open,
so that the caller can receive back any data SCTP was unable to so that the caller can receive back any data SCTP was unable to
deliver (see Section 5.3.1.4 for more information). deliver (see Section 5.3.1.4 for more information).
To perform the ABORT operation described in RFC2960 [8] section 10.1, To perform the ABORT operation described in RFC2960 [RFC2960] section
an application can use the socket option SO_LINGER. It is described 10.1, an application can use the socket option SO_LINGER. It is
in Section 7.1.4. described in Section 7.1.4.
4.1.8. sendmsg() and recvmsg() - one-to-one style socket 4.1.8. sendmsg() and recvmsg() - one-to-one style socket
With a one-to-one style socket, the application can also use With a one-to-one style socket, the application can also use
sendmsg() and recvmsg() to transmit data to and receive data from its sendmsg() and recvmsg() to transmit data to and receive data from its
peer. The semantics is similar to those used in the one-to-many peer. The semantics is similar to those used in the one-to-many
style (section Section 3.1.3), with the following differences: style (section Section 3.1.3), with the following differences:
1) When sending, the msg_name field in the msghdr is not used to 1) When sending, the msg_name field in the msghdr is not used to
specify the intended receiver, rather it is used to indicate a specify the intended receiver, rather it is used to indicate a
skipping to change at page 24, line 16 skipping to change at page 21, line 4
Applications use getpeername() to retrieve the primary socket address Applications use getpeername() to retrieve the primary socket address
of the peer. This call is for TCP compatibility, and is not multi- of the peer. This call is for TCP compatibility, and is not multi-
homed. It does not work with one-to-many style sockets. See homed. It does not work with one-to-many style sockets. See
Section 8.3 for a multi-homed/one-to-many style version of the call. Section 8.3 for a multi-homed/one-to-many style version of the call.
The syntax is: The syntax is:
int getpeername(int sd, struct sockaddr *address, int getpeername(int sd, struct sockaddr *address,
socklen_t *len); socklen_t *len);
sd - the socket descriptor to be queried. sd - the socket descriptor to be queried.
address - On return, the peer primary address is stored in this
address - On return, the peer primary address is stored in buffer. If the socket is an IPv4 socket, the address will be
this buffer. If the socket is an IPv4 socket, the IPv4. If the socket is an IPv6 socket, the address will be either
address will be IPv4. If the socket is an IPv6 socket, an IPv6 or IPv4 address.
the address will be either an IPv6 or IPv4 len - The caller should set the length of address here. On return,
address. this is set to the length of the returned address.
len - The caller should set the length of address here.
On return, this is set to the length of the returned
address.
If the actual length of the address is greater than the length of the If the actual length of the address is greater than the length of the
supplied sockaddr structure, the stored address will be truncated. supplied sockaddr structure, the stored address will be truncated.
5. Data Structures 5. Data Structures
We discuss in this section important data structures which are We discuss in this section important data structures which are
specific to SCTP and are used with sendmsg() and recvmsg() calls to specific to SCTP and are used with sendmsg() and recvmsg() calls to
control SCTP endpoint operations and to access ancillary information control SCTP endpoint operations and to access ancillary information
and notifications. and notifications.
5.1. The msghdr and cmsghdr Structures 5.1. The msghdr and cmsghdr Structures
The msghdr structure used in the sendmsg() and recvmsg() calls, as The msghdr structure used in the sendmsg() and recvmsg() calls, as
well as the ancillary data carried in the structure, is the key for well as the ancillary data carried in the structure, is the key for
the application to set and get various control information from the the application to set and get various control information from the
SCTP endpoint. SCTP endpoint.
The msghdr and the related cmsghdr structures are defined and The msghdr and the related cmsghdr structures are defined and
discussed in details in RFC2292 [6]. Here we will cite their discussed in details in RFC2292 [RFC2292]. Here we will cite their
definitions from RFC2292 [6]. definitions from RFC2292 [RFC2292].
The msghdr structure: The msghdr structure:
struct msghdr { struct msghdr {
void *msg_name; /* ptr to socket address structure */ void *msg_name; /* ptr to socket address structure */
socklen_t msg_namelen; /* size of socket address structure */ socklen_t msg_namelen; /* size of socket address structure */
struct iovec *msg_iov; /* scatter/gather array */ struct iovec *msg_iov; /* scatter/gather array */
size_t msg_iovlen; /* # elements in msg_iov */ size_t msg_iovlen; /* # elements in msg_iov */
void *msg_control; /* ancillary data */ void *msg_control; /* ancillary data */
socklen_t msg_controllen; /* ancillary data buffer length */ socklen_t msg_controllen; /* ancillary data buffer length */
skipping to change at page 26, line 39 skipping to change at page 23, line 7
report parameters on individual messages in a stream. See report parameters on individual messages in a stream. See
Section 5.2.2 for how to use SNDRCV ancillary data. Section 5.2.2 for how to use SNDRCV ancillary data.
By default on a one-to-one style socket, SCTP will pass no ancillary By default on a one-to-one style socket, SCTP will pass no ancillary
data; on a one-to-many style socket, SCTP will only pass SCTP_SNDRCV data; on a one-to-many style socket, SCTP will only pass SCTP_SNDRCV
and SCTP_ASSOC_CHANGE information. Specific ancillary data items can and SCTP_ASSOC_CHANGE information. Specific ancillary data items can
be enabled with socket options defined for SCTP; see Section 7.3. be enabled with socket options defined for SCTP; see Section 7.3.
Note that all ancillary types are fixed length; see Section 5.4 for Note that all ancillary types are fixed length; see Section 5.4 for
further discussion on this. These data structures use struct further discussion on this. These data structures use struct
sockaddr_storage (defined in RFC2553 [7]) as a portable, fixed length sockaddr_storage (defined in RFC2553 [RFC2553]) as a portable, fixed
address format. length address format.
Other protocols may also provide ancillary data to the socket layer Other protocols may also provide ancillary data to the socket layer
consumer. These ancillary data items from other protocols may consumer. These ancillary data items from other protocols may
intermingle with SCTP data. For example, the IPv6 socket API intermingle with SCTP data. For example, the IPv6 socket API
definitions (RFC2292 [6] and RFC2553 [7]) define a number of definitions (RFC2292 [RFC2292] and RFC2553 [RFC2553]) define a number
ancillary data items. If a socket API consumer enables delivery of of ancillary data items. If a socket API consumer enables delivery
both SCTP and IPv6 ancillary data, they both may appear in the same of both SCTP and IPv6 ancillary data, they both may appear in the
msg_control buffer in any order. An application may thus need to same msg_control buffer in any order. An application may thus need
handle other types of ancillary data besides that passed by SCTP. to handle other types of ancillary data besides that passed by SCTP.
The sockets application must provide a buffer large enough to The sockets application must provide a buffer large enough to
accommodate all ancillary data provided via recvmsg(). If the buffer accommodate all ancillary data provided via recvmsg(). If the buffer
is not large enough, the ancillary data will be truncated and the is not large enough, the ancillary data will be truncated and the
msghdr's msg_flags will include MSG_CTRUNC. msghdr's msg_flags will include MSG_CTRUNC.
5.2.1. SCTP Initiation Structure (SCTP_INIT) 5.2.1. SCTP Initiation Structure (SCTP_INIT)
This cmsghdr structure provides information for initializing new SCTP This cmsghdr structure provides information for initializing new SCTP
associations with sendmsg(). The SCTP_INITMSG socket option uses associations with sendmsg(). The SCTP_INITMSG socket option uses
skipping to change at page 30, line 7 skipping to change at page 26, line 5
of which fail, multiple different sinfo_context values will be of which fail, multiple different sinfo_context values will be
returned. One with each user data message). returned. One with each user data message).
sinfo_flags: 16 bits (unsigned integer) sinfo_flags: 16 bits (unsigned integer)
This field may contain any of the following flags and is composed of This field may contain any of the following flags and is composed of
a bitwise OR of these values. a bitwise OR of these values.
recvmsg() flags: recvmsg() flags:
SCTP_UNORDERED - This flag is present when the message was sent SCTP_UNORDERED - This flag is present when the message was sent non-
non-ordered. ordered.
sendmsg() flags: sendmsg() flags:
SCTP_UNORDERED - This flag requests the un-ordered delivery of the SCTP_UNORDERED - This flag requests the un-ordered delivery of the
message. If this flag is clear the datagram is message. If this flag is clear the datagram is considered an
considered an ordered send. ordered send.
SCTP_ADDR_OVER - This flag, in the one-to-many style, requests the
SCTP_ADDR_OVER - This flag, in the one-to-many style, requests the SCTP SCTP stack to override the primary destination address with the
stack to override the primary destination address address found with the sendto/sendmsg call.
with the address found with the sendto/sendmsg SCTP_ABORT - Setting this flag causes the specified association to
call. abort by sending an ABORT message to the peer (one-to-many style
only). The ABORT chunk will contain an error cause 'User
SCTP_ABORT - Setting this flag causes the specified association Initiated Abort' with cause code 12. The cause specific
to abort by sending an ABORT message to the peer
(one-to-many style only). The ABORT chunk
will contain an error cause 'User Initiated Abort'
with cause code 12.The cause specific
information of this error cause is provided in msg_iov. information of this error cause is provided in msg_iov.
SCTP_EOF - Setting this flag invokes the SCTP graceful shutdown SCTP_EOF - Setting this flag invokes the SCTP graceful shutdown
procedures on the specified association. Graceful procedures on the specified association. Graceful shutdown
shutdown assures that all data enqueued by both assures that all data enqueued by both endpoints is successfully
endpoints is successfully transmitted before closing transmitted before closing the association (one-to-many style
the association (one-to-many style only). only).
SCTP_SENDALL - This flag, if set, will cause a one-to-many model SCTP_SENDALL - This flag, if set, will cause a one-to-many model
socket to send the message to all associations socket to send the message to all associations that are currently
that are currently established on this socket. For established on this socket. For the one-to-one socket, this flag
the one-to-one socket, this flag has no effect. has no effect.
sinfo_timetolive: 32 bit (unsigned integer) sinfo_timetolive: 32 bit (unsigned integer)
For the sending side, this field contains the message time to live in For the sending side, this field contains the message time to live in
milliseconds. The sending side will expire the message within the milliseconds. The sending side will expire the message within the
specified time period if the message as not been sent to the peer specified time period if the message as not been sent to the peer
within this time period. This value will override any default value within this time period. This value will override any default value
set using any socket option. Also note that the value of 0 is set using any socket option. Also note that the value of 0 is
special in that it indicates no timeout should occur on this message. special in that it indicates no timeout should occur on this message.
skipping to change at page 32, line 16 skipping to change at page 28, line 16
struct { struct {
uint16_t sn_type; /* Notification type. */ uint16_t sn_type; /* Notification type. */
uint16_t sn_flags; uint16_t sn_flags;
uint32_t sn_length; uint32_t sn_length;
} sn_header; } sn_header;
struct sctp_assoc_change sn_assoc_change; struct sctp_assoc_change sn_assoc_change;
struct sctp_paddr_change sn_paddr_change; struct sctp_paddr_change sn_paddr_change;
struct sctp_remote_error sn_remote_error; struct sctp_remote_error sn_remote_error;
struct sctp_send_failed sn_send_failed; struct sctp_send_failed sn_send_failed;
struct sctp_shutdown_event sn_shutdown_event; struct sctp_shutdown_event sn_shutdown_event;
struct sctp_adaption_event sn_adaption_event; struct sctp_adaption_event sn_adaptation_event;
struct sctp_pdapi_event sn_pdapi_event; struct sctp_pdapi_event sn_pdapi_event;
struct sctp_authkey_event sn_auth_event; struct sctp_authkey_event sn_auth_event;
}; };
sn_type: 16 bits (unsigned integer) sn_type: 16 bits (unsigned integer)
The following list describes the SCTP notification and event types The following list describes the SCTP notification and event types
for the field sn_type. for the field sn_type.
SCTP_ASSOC_CHANGE: This tag indicates that an association has either SCTP_ASSOC_CHANGE: This tag indicates that an association has either
skipping to change at page 32, line 28 skipping to change at page 28, line 28
struct sctp_authkey_event sn_auth_event; struct sctp_authkey_event sn_auth_event;
}; };
sn_type: 16 bits (unsigned integer) sn_type: 16 bits (unsigned integer)
The following list describes the SCTP notification and event types The following list describes the SCTP notification and event types
for the field sn_type. for the field sn_type.
SCTP_ASSOC_CHANGE: This tag indicates that an association has either SCTP_ASSOC_CHANGE: This tag indicates that an association has either
been opened or closed. Refer to Section 5.3.1.1 for details. been opened or closed. Refer to Section 5.3.1.1 for details.
SCTP_PEER_ADDR_CHANGE: This tag indicates that an address that is SCTP_PEER_ADDR_CHANGE: This tag indicates that an address that is
part of an existing association has experienced a change of state part of an existing association has experienced a change of state
(e.g. a failure or return to service of the reachability of a (e.g. a failure or return to service of the reachability of a
endpoint via a specific transport address). Please see endpoint via a specific transport address). Please see
Section 5.3.1.2 for data structure details. Section 5.3.1.2 for data structure details.
SCTP_REMOTE_ERROR: The attached error message is an Operational Error SCTP_REMOTE_ERROR: The attached error message is an Operational Error
received from the remote peer. It includes the complete TLV sent received from the remote peer. It includes the complete TLV sent
by the remote endpoint. See Section 5.3.1.3 for the detailed by the remote endpoint. See Section 5.3.1.3 for the detailed
format. format.
SCTP_SEND_FAILED: The attached datagram could not be sent to the SCTP_SEND_FAILED: The attached datagram could not be sent to the
remote endpoint. This structure includes the original remote endpoint. This structure includes the original
SCTP_SNDRCVINFO that was used in sending this message i.e. this SCTP_SNDRCVINFO that was used in sending this message i.e. this
structure uses the sctp_sndrecvinfo per Section 5.3.1.4. structure uses the sctp_sndrecvinfo per Section 5.3.1.4.
SCTP_SHUTDOWN_EVENT: The peer has sent a SHUTDOWN. No further data SCTP_SHUTDOWN_EVENT: The peer has sent a SHUTDOWN. No further data
should be sent on this socket. should be sent on this socket.
SCTP_ADAPTATION_INDICATION: This notification holds the peers
SCTP_ADAPTION_INDICATION: This notification holds the peers indicated indicated adaptation layer. Please see Section 5.3.1.6.
adaption layer. Please see Section 5.3.1.6.
SCTP_PARTIAL_DELIVERY_EVENT: This notification is used to tell a SCTP_PARTIAL_DELIVERY_EVENT: This notification is used to tell a
receiver that the partial delivery has been aborted. This may receiver that the partial delivery has been aborted. This may
indicate the association is about to be aborted. Please see indicate the association is about to be aborted. Please see
Section 5.3.1.7 Section 5.3.1.7
SCTP_AUTHENTICATION_EVENT: This notification is used to tell a SCTP_AUTHENTICATION_EVENT: This notification is used to tell a
receiver that either an error occured on authentication, or a new receiver that either an error occured on authentication, or a new
key was made active. Section 5.3.1.8 key was made active. Section 5.3.1.8
All standard values for sn_type are greater than 2^15. Values from All standard values for sn_type are greater than 2^15. Values from
2^15 and down are reserved. 2^15 and down are reserved.
sn_flags: 16 bits (unsigned integer) sn_flags: 16 bits (unsigned integer)
These are notification-specific flags. These are notification-specific flags.
skipping to change at page 34, line 16 skipping to change at page 30, line 11
This field is the total length of the notification data, including This field is the total length of the notification data, including
the notification header. the notification header.
sac_state: 16 bits (signed integer) sac_state: 16 bits (signed integer)
This field holds one of a number of values that communicate the event This field holds one of a number of values that communicate the event
that happened to the association. They include: that happened to the association. They include:
Event Name Description Event Name Description
---------------- ---------------
SCTP_COMM_UP A new association is now ready
and data may be exchanged with this
peer.
SCTP_COMM_LOST The association has failed. The association ---------------- ---------------
is now in the closed state. If SEND FAILED SCTP_COMM_UP - A new association is now ready and data may be
notifications are turned on, a SCTP_COMM_LOST exchanged with this peer.
is followed by a series of SCTP_SEND_FAILED SCTP_COMM_LOST - The association has failed. The association is now
in the closed state. If SEND FAILED notifications are turned on,
a SCTP_COMM_LOST is followed by a series of SCTP_SEND_FAILED
events, one for each outstanding message.
SCTP_RESTART - SCTP has detected that the peer has restarted.
SCTP_SHUTDOWN_COMP - The association has gracefully closed.
SCTP_CANT_STR_ASSOC - The association failed to setup. If non
blocking mode is set and data was sent (in the udp mode), a
SCTP_CANT_STR_ASSOC is followed by a series of SCTP_SEND_FAILED
events, one for each outstanding message. events, one for each outstanding message.
SCTP_RESTART SCTP has detected that the peer has restarted.
SCTP_SHUTDOWN_COMP The association has gracefully closed.
SCTP_CANT_STR_ASSOC The association failed to setup. If non blocking
mode is set and data was sent (in the udp mode),
a SCTP_CANT_STR_ASSOC is followed by a series of
SCTP_SEND_FAILED events, one for each outstanding
message.
sac_error: 16 bits (signed integer) sac_error: 16 bits (signed integer)
If the state was reached due to a error condition (e.g. If the state was reached due to a error condition (e.g.
SCTP_COMM_LOST) any relevant error information is available in this SCTP_COMM_LOST) any relevant error information is available in this
field. This corresponds to the protocol error codes defined in field. This corresponds to the protocol error codes defined in
RFC2960 [8]. RFC2960 [RFC2960].
sac_outbound_streams: 16 bits (unsigned integer) sac_outbound_streams: 16 bits (unsigned integer)
sac_inbound_streams: 16 bits (unsigned integer) sac_inbound_streams: 16 bits (unsigned integer)
The maximum number of streams allowed in each direction are available The maximum number of streams allowed in each direction are available
in sac_outbound_streams and sac_inbound streams. in sac_outbound_streams and sac_inbound streams.
sac_assoc_id: sizeof (sctp_assoc_t) sac_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
All notifications for a given association have the same association All notifications for a given association have the same association
identifier. For one-to-one style socket, this field is ignored. identifier. For one-to-one style socket, this field is ignored.
sac_info: variable sac_info: variable
If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received
for this association, sac_info[] contains the complete ABORT chunk as for this association, sac_info[] contains the complete ABORT chunk as
defined in the SCTP specification RFC2960 [8] section 3.3.7. defined in the SCTP specification RFC2960 [RFC2960] section 3.3.7.
5.3.1.2. SCTP_PEER_ADDR_CHANGE 5.3.1.2. SCTP_PEER_ADDR_CHANGE
When a destination address on a multi-homed peer encounters a change When a destination address on a multi-homed peer encounters a change
an interface details event is sent. The information has the an interface details event is sent. The information has the
following structure: following structure:
struct sctp_paddr_change { struct sctp_paddr_change {
uint16_t spc_type; uint16_t spc_type;
uint16_t spc_flags; uint16_t spc_flags;
uint32_t spc_length; uint32_t spc_length;
struct sockaddr_storage spc_aaddr; struct sockaddr_storage spc_aaddr;
int spc_state; uint32_t spc_state;
int spc_error; uint32_t spc_error;
sctp_assoc_t spc_assoc_id; sctp_assoc_t spc_assoc_id;
} }
spc_type: spc_type:
It should be SCTP_PEER_ADDR_CHANGE. It should be SCTP_PEER_ADDR_CHANGE.
spc_flags: 16 bits (unsigned integer) spc_flags: 16 bits (unsigned integer)
Currently unused. Currently unused.
skipping to change at page 36, line 7 skipping to change at page 31, line 45
The affected address field, holds the remote peer's address that is The affected address field, holds the remote peer's address that is
encountering the change of state. encountering the change of state.
spc_state: 32 bits (signed integer) spc_state: 32 bits (signed integer)
This field holds one of a number of values that communicate the event This field holds one of a number of values that communicate the event
that happened to the address. They include: that happened to the address. They include:
Event Name Description Event Name Description
---------------- ---------------
SCTP_ADDR_AVAILABLE This address is now reachable.
SCTP_ADDR_UNREACHABLE The address specified can no
longer be reached. Any data sent
to this address is rerouted to an
alternate until this address becomes
reachable.
SCTP_ADDR_REMOVED The address is no longer part of
the association.
SCTP_ADDR_ADDED The address is now part of the ---------------- ---------------
association. SCTP_ADDR_AVAILABLE - This address is now reachable.
SCTP_ADDR_MADE_PRIM This address has now been made SCTP_ADDR_UNREACHABLE - The address specified can no longer be
to be the primary destination address. reached. Any data sent to this address is rerouted to an
alternate until this address becomes reachable.
SCTP_ADDR_REMOVED - The address is no longer part of the association.
SCTP_ADDR_ADDED - The address is now part of the association.
SCTP_ADDR_MADE_PRIM - This address has now been made to be the
primary destination address.
spc_error: 32 bits (signed integer) spc_error: 32 bits (signed integer)
If the state was reached due to any error condition (e.g. If the state was reached due to any error condition (e.g.
SCTP_ADDR_UNREACHABLE) any relevant error information is available in SCTP_ADDR_UNREACHABLE) any relevant error information is available in
this field. this field.
spc_assoc_id: sizeof (sctp_assoc_t) spc_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
All notifications for a given association have the same association All notifications for a given association have the same association
identifier. For one-to-one style socket, this field is ignored. identifier. For one-to-one style socket, this field is ignored.
5.3.1.3. SCTP_REMOTE_ERROR 5.3.1.3. SCTP_REMOTE_ERROR
A remote peer may send an Operational Error message to its peer. A remote peer may send an Operational Error message to its peer.
This message indicates a variety of error conditions on an This message indicates a variety of error conditions on an
association. The entire ERROR chunk as it appears on the wire is association. The entire ERROR chunk as it appears on the wire is
included in a SCTP_REMOTE_ERROR event. Please refer to the SCTP included in a SCTP_REMOTE_ERROR event. Please refer to the SCTP
specification RFC2960 [8] and any extensions for a list of possible specification RFC2960 [RFC2960] and any extensions for a list of
error formats. SCTP error notifications have the format: possible error formats. SCTP error notifications have the format:
struct sctp_remote_error { struct sctp_remote_error {
uint16_t sre_type; uint16_t sre_type;
uint16_t sre_flags; uint16_t sre_flags;
uint32_t sre_length; uint32_t sre_length;
uint16_t sre_error; uint16_t sre_error;
sctp_assoc_t sre_assoc_id; sctp_assoc_t sre_assoc_id;
uint8_t sre_data[0]; uint8_t sre_data[0];
}; };
skipping to change at page 37, line 41 skipping to change at page 33, line 24
sre_assoc_id: sizeof (sctp_assoc_t) sre_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
All notifications for a given association have the same association All notifications for a given association have the same association
identifier. For one-to-one style socket, this field is ignored. identifier. For one-to-one style socket, this field is ignored.
sre_data: variable sre_data: variable
This contains the ERROR chunk as defined in the SCTP specification This contains the ERROR chunk as defined in the SCTP specification
RFC2960 [8] section 3.3.10. RFC2960 [RFC2960] section 3.3.10.
5.3.1.4. SCTP_SEND_FAILED 5.3.1.4. SCTP_SEND_FAILED
If SCTP cannot deliver a message it may return the message as a If SCTP cannot deliver a message it may return the message as a
notification. notification.
struct sctp_send_failed { struct sctp_send_failed {
uint16_t ssf_type; uint16_t ssf_type;
uint16_t ssf_flags; uint16_t ssf_flags;
uint32_t ssf_length; uint32_t ssf_length;
uint32_t ssf_error; uint32_t ssf_error;
struct sctp_sndrcvinfo ssf_info; struct sctp_sndrcvinfo ssf_info;
sctp_assoc_t ssf_assoc_id; sctp_assoc_t ssf_assoc_id;
uint8_t ssf_data[0]; uint8_t ssf_data[0];
}; };
ssf_type: ssf_type:
It should be SCTP_SEND_FAILED. It should be SCTP_SEND_FAILED.
The flag value will take one of the following values The flag value will take one of the following values:
SCTP_DATA_UNSENT - Indicates that the data was never put on
the wire.
SCTP_DATA_SENT - Indicates that the data was put on the wire. SCTP_DATA_UNSENT - Indicates that the data was never put on the wire.
Note that this does not necessarily mean that the SCTP_DATA_SENT - Indicates that the data was put on the wire. Note
data was (or was not) successfully delivered. that this does not necessarily mean that the data was (or was not)
successfully delivered.
ssf_length: 32 bits (unsigned integer) ssf_length: 32 bits (unsigned integer)
This field is the total length of the notification data, including This field is the total length of the notification data, including
the notification header and the payload in ssf_data. the notification header and the payload in ssf_data.
ssf_error: 16 bits (unsigned integer) ssf_error: 16 bits (unsigned integer)
This value represents the reason why the send failed, and if set, This value represents the reason why the send failed, and if set,
will be a SCTP protocol error code as defined in RFC2960 [8] section will be a SCTP protocol error code as defined in RFC2960 [RFC2960]
3.3.10. section 3.3.10.
ssf_info: sizeof (struct sctp_sndrcvinfo) ssf_info: sizeof (struct sctp_sndrcvinfo)
The original send information associated with the undelivered The original send information associated with the undelivered
message. message.
ssf_assoc_id: sizeof (sctp_assoc_t) ssf_assoc_id: sizeof (sctp_assoc_t)
The association id field, sf_assoc_id, holds the identifier for the The association id field, sf_assoc_id, holds the identifier for the
association. All notifications for a given association have the same association. All notifications for a given association have the same
skipping to change at page 39, line 47 skipping to change at page 35, line 24
sse_flags: 16 bits (unsigned integer) sse_flags: 16 bits (unsigned integer)
Currently unused. Currently unused.
sse_assoc_id: sizeof (sctp_assoc_t) sse_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
All notifications for a given association have the same association All notifications for a given association have the same association
identifier. For one-to-one style socket, this field is ignored. identifier. For one-to-one style socket, this field is ignored.
5.3.1.6. SCTP_ADAPTION_INDICATION 5.3.1.6. SCTP_ADAPTATION_INDICATION
When a peer sends a Adaption Layer Indication parameter , SCTP When a peer sends a Adaptation Layer Indication parameter , SCTP
delivers this notification to inform the application that of the delivers this notification to inform the application that of the
peers requested adaption layer. peers requested adaptation layer.
struct sctp_adaption_event { struct sctp_adaptation_event {
uint16_t sai_type; uint16_t sai_type;
uint16_t sai_flags; uint16_t sai_flags;
uint32_t sai_length; uint32_t sai_length;
uint32_t sai_adaption_ind; uint32_t sai_adaptation_ind;
sctp_assoc_t sai_assoc_id; sctp_assoc_t sai_assoc_id;
}; };
sai_type sai_type
It should be SCTP_ADAPTION_INDICATION It should be SCTP_ADAPTATION_INDICATION
sai_flags: 16 bits (unsigned integer) sai_flags: 16 bits (unsigned integer)
Currently unused. Currently unused.
sai_length: 32 bits (unsigned integer) sai_length: 32 bits (unsigned integer)
This field is the total length of the notification data, including This field is the total length of the notification data, including
the notification header. It will generally be sizeof (struct the notification header. It will generally be sizeof (struct
sctp_adaption_event). sctp_adaptation_event).
sai_adaption_ind: 32 bits (unsigned integer) sai_adaptation_ind: 32 bits (unsigned integer)
This field holds the bit array sent by the peer in the adaption layer This field holds the bit array sent by the peer in the adaptation
indication parameter. The bits are in network byte order. layer indication parameter. The bits are in network byte order.
sai_assoc_id: sizeof (sctp_assoc_t) sai_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
All notifications for a given association have the same association All notifications for a given association have the same association
identifier. For one-to-one style socket, this field is ignored. identifier. For one-to-one style socket, this field is ignored.
5.3.1.7. SCTP_PARTIAL_DELIVERY_EVENT 5.3.1.7. SCTP_PARTIAL_DELIVERY_EVENT
When a receiver is engaged in a partial delivery of a message this When a receiver is engaged in a partial delivery of a message this
skipping to change at page 42, line 27 skipping to change at page 38, line 5
auth_altkeynumber: 32 bits (unsigned integer) auth_altkeynumber: 32 bits (unsigned integer)
This field holds an alternate keynumber which is used by some This field holds an alternate keynumber which is used by some
notifications. notifications.
auth_indication: 32 bits (unsigned integer) auth_indication: 32 bits (unsigned integer)
This field hold the error or indication being reported. The This field hold the error or indication being reported. The
following values are currently defined: following values are currently defined:
1) - SCTP_AUTH_NEWKEY, this report indicates that a new key has been SCTP_AUTH_NEWKEY - this report indicates that a new key has been made
made active (used for the first time by the peer) and is now the active (used for the first time by the peer) and is now the active
active key. The auth_keynumber field holds the user specified key key. The auth_keynumber field holds the user specified key
number. number.
SCTP_KEY_CONFLICT - this report indicates that an association was
2) - SCTP_KEY_CONFLICT, this report indicates that an association was
attempting to be formed and that two seperate keys were discovered attempting to be formed and that two seperate keys were discovered
for the same peer endpoint. In other words, two distinct keys for the same peer endpoint. In other words, two distinct keys
would have been active for the same association due to multi- would have been active for the same association due to multi-
homing. The field auth_keynumber contains one of the conflicting homing. The field auth_keynumber contains one of the conflicting
keys and the field auth_altkeynumber contains one of the other keys and the field auth_altkeynumber contains one of the other
keys. Note that more than two key COULD be in conflict. keys. Note that more than two key COULD be in conflict.
auth_assoc_id: sizeof (sctp_assoc_t) auth_assoc_id: sizeof (sctp_assoc_t)
The association id field, holds the identifier for the association. The association id field, holds the identifier for the association.
skipping to change at page 43, line 28 skipping to change at page 38, line 51
5.4.2. Accessing and Manipulating Ancillary Data 5.4.2. Accessing and Manipulating Ancillary Data
Applications can infer the presence of data or ancillary data by Applications can infer the presence of data or ancillary data by
examining the msg_iovlen and msg_controllen msghdr members, examining the msg_iovlen and msg_controllen msghdr members,
respectively. respectively.
Implementations may have different padding requirements for ancillary Implementations may have different padding requirements for ancillary
data, so portable applications should make use of the macros data, so portable applications should make use of the macros
CMSG_FIRSTHDR, CMSG_NXTHDR, CMSG_DATA, CMSG_SPACE, and CMSG_LEN. See CMSG_FIRSTHDR, CMSG_NXTHDR, CMSG_DATA, CMSG_SPACE, and CMSG_LEN. See
RFC2292 [6] and your SCTP implementation's documentation for more RFC2292 [RFC2292] and your SCTP implementation's documentation for
information. Following is an example, from RFC2292 [6], more information. Following is an example, from RFC2292 [RFC2292],
demonstrating the use of these macros to access ancillary data: demonstrating the use of these macros to access ancillary data:
struct msghdr msg; struct msghdr msg;
struct cmsghdr *cmsgptr; struct cmsghdr *cmsgptr;
/* fill in msg */ /* fill in msg */
/* call recvmsg() */ /* call recvmsg() */
for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL; for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL;
skipping to change at page 44, line 23 skipping to change at page 39, line 46
the buffer is too small, and crucial data is truncated, it may pose a the buffer is too small, and crucial data is truncated, it may pose a
fatal error condition. fatal error condition.
Thus it is essential that applications be able to deterministically Thus it is essential that applications be able to deterministically
calculate the maximum required buffer size to pass to recvmsg(). One calculate the maximum required buffer size to pass to recvmsg(). One
constraint imposed on this specification that makes this possible is constraint imposed on this specification that makes this possible is
that all ancillary data definitions are of a fixed length. One way that all ancillary data definitions are of a fixed length. One way
to calculate the maximum required buffer size might be to take the to calculate the maximum required buffer size might be to take the
sum the sizes of all enabled ancillary data item structures, as sum the sizes of all enabled ancillary data item structures, as
calculated by CMSG_SPACE. For example, if we enabled calculated by CMSG_SPACE. For example, if we enabled
SCTP_SNDRCV_INFO and IPV6_RECVPKTINFO RFC2292 [6], we would calculate SCTP_SNDRCV_INFO and IPV6_RECVPKTINFO RFC2292 [RFC2292], we would
and allocate the buffer size as follows: calculate and allocate the buffer size as follows:
size_t total; size_t total;
void *buf; void *buf;
total = CMSG_SPACE(sizeof (struct sctp_sndrcvinfo)) + total = CMSG_SPACE(sizeof (struct sctp_sndrcvinfo)) +
CMSG_SPACE(sizeof (struct in6_pktinfo)); CMSG_SPACE(sizeof (struct in6_pktinfo));
buf = malloc(total); buf = malloc(total);
We could then use this buffer for msg_control on each call to We could then use this buffer for msg_control on each call to
skipping to change at page 45, line 25 skipping to change at page 40, line 37
ssize_t send(int sd, const void *msg, size_t len, int flags); 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, ssize_t sendto(int sd, const void *msg, size_t len, int flags,
const struct sockaddr *to, socklen_t tolen); const struct sockaddr *to, socklen_t tolen);
ssize_t recv(int sd, void *buf, size_t len, int flags); ssize_t recv(int sd, void *buf, size_t len, int flags);
ssize_t recvfrom(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); struct sockaddr *from, socklen_t *fromlen);
sd - the socket descriptor of an SCTP endpoint. sd - the socket descriptor of an SCTP endpoint.
msg - the message to be sent. msg - the message to be sent.
len - the size of the message or the size of buffer. len - the size of the message or the size of buffer.
to - one of the peer addresses of the association to be to - one of the peer addresses of the association to be used to send
used to send the message. the message.
tolen - the size of the address. tolen - the size of the address.
buf - the buffer to store a received message. buf - the buffer to store a received message.
from - the buffer to store the peer address used to send the from - the buffer to store the peer address used to send the received
received message. message.
fromlen - the size of the from address fromlen - the size of the from address
flags - (described below). flags - (described below).
These calls give access to only basic SCTP protocol features. If These calls give access to only basic SCTP protocol features. If
either peer in the association uses multiple streams, or sends either peer in the association uses multiple streams, or sends
unordered data these calls will usually be inadequate, and may unordered data these calls will usually be inadequate, and may
deliver the data in unpredictable ways. deliver the data in unpredictable ways.
SCTP has the concept of multiple streams in one association. The SCTP has the concept of multiple streams in one association. The
above calls do not allow the caller to specify on which stream a above calls do not allow the caller to specify on which stream a
skipping to change at page 46, line 17 skipping to change at page 41, line 30
In receiving, if the buffer supplied is not large enough to hold a In receiving, if the buffer supplied is not large enough to hold a
complete message, the receive call acts like a stream socket and complete message, the receive call acts like a stream socket and
returns as much data as will fit in the buffer. returns as much data as will fit in the buffer.
Note, the send() and recv() calls may not be used for a one-to-many Note, the send() and recv() calls may not be used for a one-to-many
style socket. style socket.
Note, if an application calls a send function with no user data and Note, if an application calls a send function with no user data and
no ancillary data the SCTP implementation should reject the request no ancillary data the SCTP implementation should reject the request
with an appropriate error message. An implementation is NOT allowed with an appropriate error message. An implementation is NOT allowed
to send a Data chunk with no user data RFC2960 [8]. to send a Data chunk with no user data RFC2960 [RFC2960].
6.2. setsockopt(), getsockopt() 6.2. setsockopt(), getsockopt()
Applications use setsockopt() and getsockopt() to set or retrieve Applications use setsockopt() and getsockopt() to set or retrieve
socket options. Socket options are used to change the default socket options. Socket options are used to change the default
behavior of sockets calls. They are described in Section 7 behavior of sockets calls. They are described in Section 7
The syntax is: The syntax is:
ret = getsockopt(int sd, int level, int optname, void *optval, ret = getsockopt(int sd, int level, int optname, void *optval,
socklen_t *optlen); socklen_t *optlen);
ret = setsockopt(int sd, int level, int optname, const void *optval, ret = setsockopt(int sd, int level, int optname, const void *optval,
socklen_t optlen); socklen_t optlen);
sd - the socket descript. sd - the socket descriptor.
level - set to IPPROTO_SCTP for all SCTP options. level - set to IPPROTO_SCTP for all SCTP options.
optname - the option name. optname - the option name.
optval - the buffer to store the value of the option. optval - the buffer to store the value of the option.
optlen - the size of the buffer (or the length of the option optlen - the size of the buffer (or the length of the option
returned). returned).
6.3. read() and write() 6.3. read() and write()
Applications can use read() and write() to send and receive data to Applications can use read() and write() to send and receive data to
and from peer. They have the same semantics as send() and recv() and from peer. They have the same semantics as send() and recv()
except that the flags parameter cannot be used. except that the flags parameter cannot be used.
skipping to change at page 47, line 14 skipping to change at page 42, line 33
caller let SCTP chose a local port. This call is for where the caller let SCTP chose a local port. This call is for where the
endpoint is not multi-homed. It does not work well with multi-homed endpoint is not multi-homed. It does not work well with multi-homed
sockets. See Section 8.5 for a multi-homed version of the call. sockets. See Section 8.5 for a multi-homed version of the call.
The syntax is: The syntax is:
int getsockname(int sd, struct sockaddr *address, int getsockname(int sd, struct sockaddr *address,
socklen_t *len); socklen_t *len);
sd - the socket descriptor to be queried. sd - the socket descriptor to be queried.
address - On return, one locally bound address (chosen by the SCTP
address - On return, one locally bound address (chosen by stack) is stored in this buffer. If the socket is an IPv4 socket,
the SCTP stack) is stored in this buffer. If the the address will be IPv4. If the socket is an IPv6 socket, the
socket is an IPv4 socket, the address will be IPv4. address will be either an IPv6 or IPv4 address.
If the socket is an IPv6 socket, the address will len - The caller should set the length of address here. On return,
be either an IPv6 or IPv4 address. this is set to the length of the returned address.
len - The caller should set the length of address here.
On return, this is set to the length of the returned
address.
If the actual length of the address is greater than the length of the If the actual length of the address is greater than the length of the
supplied sockaddr structure, the stored address will be truncated. supplied sockaddr structure, the stored address will be truncated.
If the socket has not been bound to a local name, the value stored in If the socket has not been bound to a local name, the value stored in
the object pointed to by address is unspecified. the object pointed to by address is unspecified.
7. Socket Options 7. Socket Options
The following sub-section describes various SCTP level socket options The following sub-section describes various SCTP level socket options
skipping to change at page 49, line 51 skipping to change at page 44, line 40
c) If neither the sockaddr_storage or association identification is c) If neither the sockaddr_storage or association identification is
set, i.e. the sockaddr_storage is set to all 0's (INADDR_ANY) and set, i.e. the sockaddr_storage is set to all 0's (INADDR_ANY) and
the association identification is 0, the settings are a default the association identification is 0, the settings are a default
and to be applied to the endpoint (all future associations). and to be applied to the endpoint (all future associations).
7.1. Read / Write Options 7.1. Read / Write Options
7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) 7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO)
The protocol parameters used to initialize and bound retransmission The protocol parameters used to initialize and bound retransmission
timeout (RTO) are tunable. See RFC2960 [8] for more information on timeout (RTO) are tunable. See RFC2960 [RFC2960] for more
how these parameters are used in RTO calculation. information on how these parameters are used in RTO calculation.
The following structure is used to access and modify these The following structure is used to access and modify these
parameters: parameters:
struct sctp_rtoinfo { struct sctp_rtoinfo {
sctp_assoc_t srto_assoc_id; sctp_assoc_t srto_assoc_id;
uint32_t srto_initial; uint32_t srto_initial;
uint32_t srto_max; uint32_t srto_max;
uint32_t srto_min; uint32_t srto_min;
}; };
srto_initial - This contains the initial RTO value. srto_initial - This contains the initial RTO value.
srto_max and srto_min - These contain the maximum and minimum bounds srto_max and srto_min - These contain the maximum and minimum bounds
for all RTOs. for all RTOs.
srto_assoc_id - (one-to-many style socket) This is filled in srto_assoc_id - (one-to-many style socket) This is filled in the
the application, and identifies the association application, and identifies the association for this query. If
for this query. If this parameter is '0' this parameter is '0' (on a one-to-many style socket), then the
(on a one-to-many style socket), then the change change effects the entire endpoint.
effects the entire endpoint.
All parameters are time values, in milliseconds. A value of 0, when All parameters are time values, in milliseconds. A value of 0, when
modifying the parameters, indicates that the current value should not modifying the parameters, indicates that the current value should not
be changed. be changed.
To access or modify these parameters, the application should call To access or modify these parameters, the application should call
getsockopt or setsockopt() respectively with the option name getsockopt or setsockopt() respectively with the option name
SCTP_RTOINFO. SCTP_RTOINFO.
7.1.2. Association Parameters (SCTP_ASSOCINFO) 7.1.2. Association Parameters (SCTP_ASSOCINFO)
This option is used to both examine and set various association and This option is used to both examine and set various association and
endpoint parameters. endpoint parameters.
See RFC2960 [8] for more information on how this parameter is used. See RFC2960 [RFC2960] for more information on how this parameter is
The peer address parameter is ignored for one-to-one style socket. used. The peer address parameter is ignored for one-to-one style
socket.
The following structure is used to access and modify this parameters: The following structure is used to access and modify this parameters:
struct sctp_assocparams { struct sctp_assocparams {
sctp_assoc_t sasoc_assoc_id; sctp_assoc_t sasoc_assoc_id;
uint16_t sasoc_asocmaxrxt; uint16_t sasoc_asocmaxrxt;
uint16_t sasoc_number_peer_destinations; uint16_t sasoc_number_peer_destinations;
uint32_t sasoc_peer_rwnd; uint32_t sasoc_peer_rwnd;
uint32_t sasoc_local_rwnd; uint32_t sasoc_local_rwnd;
uint32_t sasoc_cookie_life; uint32_t sasoc_cookie_life;
skipping to change at page 51, line 13 skipping to change at page 45, line 39
The following structure is used to access and modify this parameters: The following structure is used to access and modify this parameters:
struct sctp_assocparams { struct sctp_assocparams {
sctp_assoc_t sasoc_assoc_id; sctp_assoc_t sasoc_assoc_id;
uint16_t sasoc_asocmaxrxt; uint16_t sasoc_asocmaxrxt;
uint16_t sasoc_number_peer_destinations; uint16_t sasoc_number_peer_destinations;
uint32_t sasoc_peer_rwnd; uint32_t sasoc_peer_rwnd;
uint32_t sasoc_local_rwnd; uint32_t sasoc_local_rwnd;
uint32_t sasoc_cookie_life; uint32_t sasoc_cookie_life;
}; };
sasoc_asocmaxrxt - This contains the maximum retransmission attempts sasoc_asocmaxrxt - This contains the maximum retransmission attempts
to make for the association. to make for the association.
sasoc_number_peer_destinations - This is the number of destination sasoc_number_peer_destinations - This is the number of destination
addresses that the peer has. addresses that the peer has.
sasoc_peer_rwnd - This holds the current value of the peers sasoc_peer_rwnd - This holds the current value of the peers rwnd
rwnd (reported in the last SACK) minus any (reported in the last SACK) minus any outstanding data (i.e. data
outstanding data (i.e. data inflight). inflight).
sasoc_local_rwnd - This holds the last reported rwnd that was sasoc_local_rwnd - This holds the last reported rwnd that was sent to
sent to the peer. the peer.
sasoc_cookie_life - This is the associations cookie life value
used when issuing cookies. sasoc_cookie_life - This is the associations cookie life value used
sasoc_assoc_id - (one-to-many style socket) This is filled in the when issuing cookies.
application, and identifies the association sasoc_assoc_id - This is filled in the application, and identifies
for this query. the association for this query.
This information may be examined for either the endpoint or a This information may be examined for either the endpoint or a
specific association. To examine a endpoints default parameters the specific association. To examine a endpoints default parameters the
association id (sasoc_assoc_id) should must be set to the value '0'. association id (sasoc_assoc_id) should must be set to the value '0'.
The values of the sasoc_peer_rwnd is meaningless when examining The values of the sasoc_peer_rwnd is meaningless when examining
endpoint information. endpoint information.
All parameters are time values, in milliseconds. A value of 0, when All parameters are time values, in milliseconds. A value of 0, when
modifying the parameters, indicates that the current value should not modifying the parameters, indicates that the current value should not
be changed. be changed.
skipping to change at page 52, line 5 skipping to change at page 46, line 35
To access or modify these parameters, the application should call To access or modify these parameters, the application should call
getsockopt or setsockopt() respectively with the option name getsockopt or setsockopt() respectively with the option name
SCTP_ASSOCINFO. SCTP_ASSOCINFO.
The maximum number of retransmissions before an address is considered The maximum number of retransmissions before an address is considered
unreachable is also tunable, but is address-specific, so it is unreachable is also tunable, but is address-specific, so it is
covered in a separate option. If an application attempts to set the covered in a separate option. If an application attempts to set the
value of the association maximum retransmission parameter to more value of the association maximum retransmission parameter to more
than the sum of all maximum retransmission parameters, setsockopt() than the sum of all maximum retransmission parameters, setsockopt()
shall return an error. The reason for this, from RFC2960 [8] section shall return an error. The reason for this, from RFC2960 [RFC2960]
8.2: section 8.2:
Note: When configuring the SCTP endpoint, the user should avoid Note: When configuring the SCTP endpoint, the user should avoid
having the value of 'Association.Max.Retrans' larger than the having the value of 'Association.Max.Retrans' larger than the
summation of the 'Path.Max.Retrans' of all the destination addresses summation of the 'Path.Max.Retrans' of all the destination addresses
for the remote endpoint. Otherwise, all the destination addresses for the remote endpoint. Otherwise, all the destination addresses
may become inactive while the endpoint still considers the peer may become inactive while the endpoint still considers the peer
endpoint reachable. endpoint reachable.
7.1.3. Initialization Parameters (SCTP_INITMSG) 7.1.3. Initialization Parameters (SCTP_INITMSG)
skipping to change at page 53, line 34 skipping to change at page 48, line 15
that can be sent in a single send call. For one-to-many style that can be sent in a single send call. For one-to-many style
sockets, the effect is the same, except that it applies to one or all sockets, the effect is the same, except that it applies to one or all
associations (see Section 3.4) bound to the socket descriptor used in associations (see Section 3.4) bound to the socket descriptor used in
the setsockopt() or getsockopt() call. The option applies to each the setsockopt() or getsockopt() call. The option applies to each
association's window size separately. The call expects an integer. association's window size separately. The call expects an integer.
7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE) 7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE)
This socket option is applicable to the one-to-many style socket This socket option is applicable to the one-to-many style socket
only. When set it will cause associations that are idle for more only. When set it will cause associations that are idle for more
than the specified number of seconds to automatically close. An than the specified number of seconds to automatically close using the
association being idle is defined as an association that has NOT sent graceful shutdown procedure. An association being idle is defined as
or received user data. The special value of '0' indicates that no an association that has NOT sent or received user data. The special
automatic close of any associations should be performed, this is the value of '0' indicates that no automatic close of any associations
default value. The option expects an integer defining the number of should be performed, this is the default value. The option expects
seconds of idle time before an association is closed. an integer defining the number of seconds of idle time before an
association is closed.
An application using this option should enable receiving the An application using this option should enable receiving the
association change notification. This is the only mechanism an association change notification. This is the only mechanism an
application is informed about the closing of an association. After application is informed about the closing of an association. After
an association is closed, the association ID assigned to it can be an association is closed, the association ID assigned to it can be
reused. An application should be aware of this to avoid the possible reused. An application should be aware of this to avoid the possible
problem of sending data to an incorrect peer end point. problem of sending data to an incorrect peer end point.
7.1.9. Set Peer Primary Address (SCTP_SET_PEER_PRIMARY_ADDR) 7.1.9. Set Peer Primary Address (SCTP_SET_PEER_PRIMARY_ADDR)
Requests that the peer mark the enclosed address as the association Requests that the peer mark the enclosed address as the association
primary. The enclosed address must be one of the association's primary. The enclosed address must be one of the association's
locally bound addresses. The following structure is used to make a locally bound addresses. The following structure is used to make a
set primary request: set primary request:
struct sctp_setpeerprim { struct sctp_setpeerprim {
sctp_assoc_t sspp_assoc_id; sctp_assoc_t sspp_assoc_id;
struct sockaddr_storage sspp_addr; struct sockaddr_storage sspp_addr;
}; };
sspp_addr The address to set as primary sspp_addr - The address to set as primary
sspp_assoc_id (one-to-many style socket) This is filled in by the sspp_assoc_id - This is filled in by the application, and identifies
application, and identifies the association the association for this request.
for this request.
This functionality is optional. Implementations that do not support This functionality is optional. Implementations that do not support
this functionality should return EOPNOTSUPP. this functionality should return EOPNOTSUPP.
7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR) 7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR)
Requests that the local SCTP stack use the enclosed peer address as Requests that the local SCTP stack use the enclosed peer address as
the association primary. The enclosed address must be one of the the association primary. The enclosed address must be one of the
association peer's addresses. The following structure is used to association peer's addresses. The following structure is used to
make a set peer primary request: make a set peer primary request:
struct sctp_setprim { struct sctp_setprim {
sctp_assoc_t ssp_assoc_id; sctp_assoc_t ssp_assoc_id;
struct sockaddr_storage ssp_addr; struct sockaddr_storage ssp_addr;
}; };
ssp_addr The address to set as primary
ssp_assoc_id (one-to-many style socket) This is filled in by the
application, and identifies the association
for this request.
7.1.11. Set Adaption Layer Indicator (SCTP_ADAPTION_LAYER) ssp_addr - The address to set as primary
ssp_assoc_id - This is filled in by the application, and identifies
the association for this request.
Requests that the local endpoint set the specified Adaption Layer 7.1.11. Set Adaptation Layer Indicator (SCTP_ADAPTATION_LAYER)
Requests that the local endpoint set the specified Adaptation Layer
Indication parameter for all future INIT and INIT-ACK exchanges. Indication parameter for all future INIT and INIT-ACK exchanges.
struct sctp_setadaption { struct sctp_setadaptation {
uint32_t ssb_adaption_ind; uint32_t ssb_adaptation_ind;
}; };
ssb_adaption_ind The adaption layer indicator that will be included ssb_adaptation_ind - The adaptation layer indicator that will be
in any outgoing Adaption Layer Indication included in any outgoing Adaptation Layer Indication parameter
parameter.
7.1.12. Enable/Disable message fragmentation (SCTP_DISABLE_FRAGMENTS) 7.1.12. Enable/Disable message fragmentation (SCTP_DISABLE_FRAGMENTS)
This option is a on/off flag and is passed an integer where a non- This option is a on/off flag and is passed an integer where a non-
zero is on and a zero is off. If enabled no SCTP message zero is on and a zero is off. If enabled no SCTP message
fragmentation will be performed. Instead if a message being sent fragmentation will be performed. Instead if a message being sent
exceeds the current PMTU size, the message will NOT be sent and exceeds the current PMTU size, the message will NOT be sent and
instead a error will be indicated to the user. instead a error will be indicated to the user.
7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) 7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS)
skipping to change at page 55, line 30 skipping to change at page 50, line 13
address's parameters: address's parameters:
struct sctp_paddrparams { struct sctp_paddrparams {
sctp_assoc_t spp_assoc_id; sctp_assoc_t spp_assoc_id;
struct sockaddr_storage spp_address; struct sockaddr_storage spp_address;
uint32_t spp_hbinterval; uint32_t spp_hbinterval;
uint16_t spp_pathmaxrxt; uint16_t spp_pathmaxrxt;
uint32_t spp_pathmtu; uint32_t spp_pathmtu;
uint32_t spp_sackdelay; uint32_t spp_sackdelay;
uint32_t spp_flags; uint32_t spp_flags;
uint32_t spp_ipv6_flowlabel;
uint8_t spp_ipv4_tos;
}; };
spp_assoc_id - (one-to-many style socket) This is filled in the spp_assoc_id - (one-to-many style socket) This is filled in the
application, and identifies the association for application, and identifies the association for this query.
this query.
spp_address - This specifies which address is of interest. spp_address - This specifies which address is of interest.
spp_hbinterval - This contains the value of the heartbeat interval, spp_hbinterval - This contains the value of the heartbeat interval,
in milliseconds. If a value of zero in milliseconds. Note that unless the spp_flag is set to
is present in this field then no changes are to SPP_HB_ENABLE the value of this field is ignored. Note also that
be made to this parameter. a value of zero indicates the current setting should be left
spp_pathmaxrxt - This contains the maximum number of unchanged. To set an actual value of zero the use of the flag
retransmissions before this address shall be SPP_HB_TIME_IS_ZERO should be used.
considered unreachable. If a value of zero spp_pathmaxrxt - This contains the maximum number of retransmissions
is present in this field then no changes are to before this address shall be considered unreachable. Note that
be made to this parameter. unless the spp_flag is set to SPP_PMTUD_ENABLE the value of this
spp_pathmtu - When Path MTU discovery is disabled the value field is ignored. Note also that a value of zero indicates the
specified here will be the "fixed" path mtu. current setting should be left unchanged.
Note that if the spp_address field is empty spp_pathmtu - When Path MTU discovery is disabled the value specified
then all associations on this address will here will be the "fixed" path mtu (i.e. the value of the spp_flags
have this fixed path mtu set upon them. field must include the flag SPP_PMTUD_DISABLE for this field to
have any effect). Note that if the spp_address field is empty
then all associations on this address will have this fixed path
mtu set upon them. If an address is specified, then only that
address will be effected.
spp_sackdelay - When delayed sack is enabled, this value specifies spp_sackdelay - When delayed sack is enabled, this value specifies
the number of milliseconds that sacks will be delayed the number of milliseconds that sacks will be delayed for. This
for. This value will apply to all addresses of an value will apply to all addresses of an association if the
association if the spp_address field is empty. Note spp_address field is empty. Note that unless the spp_flag is set
also, that if delayed sack is enabled and this to SPP_SACKDELAY_ENABLE the value of this field is ignored. Note
value is set to 0, no change is made to the last also that a value of zero indicates the current setting should be
recorded delayed sack timer value. left unchanged.
spp_ipv6_flowlabel- This field is used in conjunction with the
spp_flags - These flags are used to control various features SPP_IPV4_FLOWLABEL flag.
on an association. The flag field may contain spp_ipv4_tos- This field is used in conjunction with the SPP_IPV4_TOS
zero or more of the following options. flag.
SPP_HB_ENABLE - Enable heartbeats on the
specified address. Note that if the address
field is empty all addresses for the association
have heartbeats enabled upon them.
SPP_HB_DISABLE - Disable heartbeats on the
speicifed address. Note that if the address
field is empty all addresses for the association
will have their heartbeats disabled. Note also
that SPP_HB_ENABLE and SPP_HB_DISABLE are
mutually exclusive, only one of these two should
be specified. Enabling both fields will have
undetermined results.
SPP_HB_DEMAND - Request a user initiated heartbeat
to be made immediately.
SPP_PMTUD_ENABLE - This field will enable PMTU spp_flags- These flags are used to control various features on an
discovery upon the specified address. Note that association. The flag field may contain zero or more of the
if the address feild is empty then all addresses following options.
on the association are effected.
SPP_PMTUD_DISABLE - This field will disable PMTU SPP_HB_ENABLE - Enable heartbeats on the specified address. Note
discovery upon the specified address. Note that that if the address field is empty all addresses for the
if the address feild is empty then all addresses association have heartbeats enabled upon them.
on the association are effected. Not also that SPP_HB_DISABLE - Disable heartbeats on the speicifed address.
SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually Note that if the address field is empty all addresses for the
exclusive. Enabling both will have undetermined association will have their heartbeats disabled. Note also
results. that SPP_HB_ENABLE and SPP_HB_DISABLE are mutually exclusive,
only one of these two should be specified. Enabling both
fields will have undetermined results.
SPP_HB_DEMAND - Request a user initiated heartbeat to be made
immediately.
SPP_HB_TIME_IS_ZERO - Specify's that the time for heartbeat delay
is to be set to the value of 0 milliseconds.
SPP_PMTUD_ENABLE - This field will enable PMTU discovery upon the
specified address. Note that if the address feild is empty
then all addresses on the association are effected.
SPP_PMTUD_DISABLE - This field will disable PMTU discovery upon
the specified address. Note that if the address feild is empty
then all addresses on the association are effected. Not also
that SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually
exclusive. Enabling both will have undetermined results.
SPP_SACKDELAY_ENABLE - Setting this flag turns on delayed sack.
The time specified in spp_sackdelay is used to specify the sack
delay for this address. Note that if spp_address is empty then
all addresses will enable delayed sack and take on the sack
delay value specified in spp_sackdelay.
SPP_SACKDELAY_DISABLE - Setting this flag turns off delayed sack.
If the spp_address field is blank then delayed sack is disabled
for the entire association. Note also that this field is
mutually exclusive to SPP_SACKDELAY_ENABLE, setting both will
have undefined results.
SPP_IPV6_FLOWLABEL - Setting this flag enables setting of the IPV6
flowlabel value associated with either the association or the
specific address. If the address field is filled in, then the
specific destination address has this value set upon it. If
the association is specified, but not the address, then the
flowlabel value is set for any future destination addresses
that may be added. The value is obtained in the
spp_ipv6_flowlabel field.
SPP_SACKDELAY_ENABLE - Setting this flag turns Upon retrieval, this flag will be set to indicate that the
on delayed sack. The time specified in spp_sackdelay spp_ipv6_flowlabel field has a valid value returned. If a
is used to specify the sack delay for this address. Note specific destination addresses is set (in the spp_address
that if spp_address is empty then all addresses will field) when called then the value returned is that of the
enable delayed sack and take on the sack delay address. If just an assocaition is specified (and no address)
value specified in spp_sackdelay. then the association default flowlabel is returned. If neither
an association nor an destination is specified, then the
sockets default flowlabel is returned. For non IPv6 sockets,
then this flag will be left cleared.
SPP_IPV4_TOS - Setting this flag enables setting of the IPV4 tos
value associated with either the association or specific
address. If the address field is filled in, then the specific
destination address has this value set upon it. If the
association is specified, but not the address, then the tos
value is set for any future destination addresses that may be
added. The value is obtained in the spp_ipv4_tos field.
SPP_SACKDELAY_DISABLE - Setting this flag turns Upon retrieval, this flag will be set to indicate that the
off delayed sack. If the spp_address field is blank then spp_ipv4_tos field has a valid value returned. If a specific
delayed sack is disabled for the entire association. Note destination addresses is set when called (in the spp_address
also that this field is mutually exclusive to field) then that specific destination addresses tos value is
SPP_SACKDELAY_ENABLE, setting both will have undefined returned. If just an assocaition is specified then the
results. association default tos is returned. If neither an association
nor an destination is specified, then the sockets default tos
is returned. For non IPv4 sockets, then this flag will be left
cleared.
To read or modify these parameters, the application should call To read or modify these parameters, the application should call
sctp_opt_info() with the SCTP_PEER_ADDR_PARAMS option. sctp_opt_info() with the SCTP_PEER_ADDR_PARAMS option.
7.1.14. Set default send parameters (SCTP_DEFAULT_SEND_PARAM) 7.1.14. Set default send parameters (SCTP_DEFAULT_SEND_PARAM)
Applications that wish to use the sendto() system call may wish to Applications that wish to use the sendto() system call may wish to
specify a default set of parameters that would normally be supplied specify a default set of parameters that would normally be supplied
through the inclusion of ancillary data. This socket option allows through the inclusion of ancillary data. This socket option allows
such an application to set the default sctp_sndrcvinfo structure. such an application to set the default sctp_sndrcvinfo structure.
skipping to change at page 59, line 13 skipping to change at page 54, line 18
build the association shared key. build the association shared key.
struct sctp_authkey { struct sctp_authkey {
sctp_assoc_t sca_assoc_id; sctp_assoc_t sca_assoc_id;
uint32_t sca_keynumber; uint32_t sca_keynumber;
struct sockaddr_storage sca_address; struct sockaddr_storage sca_address;
uint8_t sca_key[]; uint8_t sca_key[];
}; };
sca_assoc_id - This parameter, if non-zero, indicates what sca_assoc_id - This parameter, if non-zero, indicates what
association that the shared key is being set association that the shared key is being set upon. Note that if
upon. Note that if this element contains zero, then this element contains zero, then the secret is set upon the
the secret is set upon the endpoint and all future endpoint and all future associations will use this secret (if not
associations will use this secret (if not changed by changed by subsequent calls to SCTP_AUTH_KEY).
subsequent calls to SCTP_AUTH_KEY).
sca_address - this parameter contains either a zero filled address, sca_address - this parameter contains either a zero filled address,
in which case it has no effect on the call. Or this in which case it has no effect on the call. Or this parameter may
parameter may contain an existing association. contain an existing association. An address may also be specified
An address may also be specified for a future association for a future association including the IP layer address and the
including the IP layer address and the transport port, or transport port, or just the IP layer address. Note that if
just the IP layer address. Note that if multiple keys multiple keys are defined for addresses of the same endpoint (for
are defined for addresses of the same endpoint (for a a multihomed endpoint) then an error will be returned and NO
multihomed endpoint) then an error will be returned and association will be formed on recipt of the INIT or INIT-ACK.
NO association will be formed on recipt of the INIT sca_keynumber - this parameter is the key index by which the
or INIT-ACK. application will refer to this key. If a key of the specified
index already exists, then this new key will replace the old key.
sca_keynumber - this parameter is the key index by which the application sca_key - This parameter contains an array of bytes that is to be
will refer to this key. If a key of the specified used by the endpoint (or association) as the shared secret.
index already exists, then this new key will replace
the old key.
sca_key - This parameter contains an array of bytes
that is to be used by the endpoint (or association)
as the shared secret.
7.1.20. Get the list of chunks the peer requires to be authenticated 7.1.20. Get the list of chunks the peer requires to be authenticated
(SCTP_PEER_AUTH_CHUNKS) (SCTP_PEER_AUTH_CHUNKS)
This option gets a list of chunks for a specified association that This option gets a list of chunks for a specified association that
the peer requires to be received authenticated only. the peer requires to be received authenticated only.
struct sctp_authchunks { struct sctp_authchunks {
sctp_assoc_t gauth_assoc_id; sctp_assoc_t gauth_assoc_id;
uint8_t gauth_chunks[]; uint8_t gauth_chunks[];
skipping to change at page 60, line 9 skipping to change at page 55, line 4
7.1.20. Get the list of chunks the peer requires to be authenticated 7.1.20. Get the list of chunks the peer requires to be authenticated
(SCTP_PEER_AUTH_CHUNKS) (SCTP_PEER_AUTH_CHUNKS)
This option gets a list of chunks for a specified association that This option gets a list of chunks for a specified association that
the peer requires to be received authenticated only. the peer requires to be received authenticated only.
struct sctp_authchunks { struct sctp_authchunks {
sctp_assoc_t gauth_assoc_id; sctp_assoc_t gauth_assoc_id;
uint8_t gauth_chunks[]; uint8_t gauth_chunks[];
}; };
gauth_assoc_id - This parameter, indicates for which association the gauth_assoc_id - This parameter, indicates for which association the
user is requesting the list of peer authenticated user is requesting the list of peer authenticated chunks.
chunks. gauth_chunks - This parameter contains an array of chunks that the
peer is requesting to be authenticated.
gauth_chunks - This parameter contains an array of chunks
that the peer is requesting to be authenticated.
7.1.21. Get the list of chunks the local endpoint requires to be 7.1.21. Get the list of chunks the local endpoint requires to be
authenticated (SCTP_LOCAL_AUTH_CHUNKS) authenticated (SCTP_LOCAL_AUTH_CHUNKS)
This option gets a list of chunks for a specified association that This option gets a list of chunks for a specified association that
the local endpoint requires to be received authenticated only. the local endpoint requires to be received authenticated only.
struct sctp_authchunks { struct sctp_authchunks {
sctp_assoc_t gauth_assoc_id; sctp_assoc_t gauth_assoc_id;
uint8_t gauth_chunks[]; uint8_t gauth_chunks[];
}; };
gauth_assoc_id - This parameter, indicates for which association the gauth_assoc_id - This parameter, indicates for which association the
user is requesting the list of local authenticated user is requesting the list of local authenticated chunks.
chunks. gauth_chunks - This parameter contains an array of chunks that the
local endpoint is requesting to be authenticated.
gauth_chunks - This parameter contains an array of chunks
that the local endpoint is requesting to be authenticated.
7.1.22. Set the list of supported HMAC Identifiers (SCTP_HMAC_IDENT) 7.1.22. Set the list of supported HMAC Identifiers (SCTP_HMAC_IDENT)
This option sets a list of algorithms for a specified association This option sets a list of algorithms for a specified association
that the local endpoint requires the peer to use. that the local endpoint requires the peer to use.
struct sctp_hmacalgo { struct sctp_hmacalgo {
sctp_assoc_t shmac_assoc_id; sctp_assoc_t shmac_assoc_id;
uint32_t shmac_idents[]; uint32_t shmac_idents[];
}; };
skipping to change at page 62, line 15 skipping to change at page 56, line 15
struct sctp_authkey { struct sctp_authkey {
sctp_assoc_t scact_assoc_id; sctp_assoc_t scact_assoc_id;
uint32_t scact_keynumber; uint32_t scact_keynumber;
uint32_t scact_sec_old; uint32_t scact_sec_old;
uint32_t scact_sec_new; uint32_t scact_sec_new;
struct sockaddr_storage scact_address; struct sockaddr_storage scact_address;
}; };
scact_assoc_id - This parameter, if non-zero, indicates what scact_assoc_id - This parameter, if non-zero, indicates what
association that the shared key is being set association that the shared key is being set upon. Note that if
upon. Note that if this element contains zero, then this element contains zero, then the secret activation applys to
the secret activation applys to the endpoint and the endpoint and all future associations will use this secret (if
all future associations will use this secret (if not changed by not changed by subsequent calls).
subsequent calls).
scact_address - this parameter contains either a zero filled address, scact_address - this parameter contains either a zero filled address,
in which case it has no effect on the call. Or this in which case it has no effect on the call. Or this parameter may
parameter may contain an existing association address. contain an existing association address. An address may also be
An address may also be specified for a future association specified for a future association including the IP layer address
including the IP layer address and the transport port, or and the transport port, or just the IP layer address. Note that
just the IP layer address. Note that if multiple keys if multiple keys are defined for addresses of the same endpoint
are defined for addresses of the same endpoint (for a (for a multihomed endpoint) then an error will be returned and NO
multihomed endpoint) then an error will be returned and association will be formed on recipt of the INIT or INIT-ACK.
NO association will be formed on recipt of the INIT scact_keynumber - this parameter is the key index by which the
or INIT-ACK. application will refer to this key. If a key of the specified
index already exists, then this new key will replace the old key.
scact_keynumber - this parameter is the key index by which the application scact_sec_old - this parameter list the number of seconds for which
will refer to this key. If a key of the specified both keys will be accepted. If this value is 0, then the new key
index already exists, then this new key will replace is made active immediately and packets with the old key will be
the old key. discarded. If this value is non-zero, then for the specified time
in seconds both keys will be accepted.
scact_sec_old this parameter list the number of seconds for which scact_sec_new - this parameter indicates the number of seconds until
both keys will be accepted. If this value is 0, then the new key will start being used as the active key. If this
the new key is made active immediately and packets value is '0' then the new key will start being used immediately.
with the old key will be discarded. If this value If this value is non-zero then the specified number of seconds
is non-zero, then for the specified time in seconds will be delayed until new chunks being transmitted begin using the
both keys will be accepted. new key.
scact_sec_new this parameter indicates the number of seconds until
the new key will start being used as the active key.
If this value is '0' then the new key will start
being used immediately. If this value is non-zero then
the specified number of seconds will be delayed until
new chunks being transmitted begin using the new
key.
7.1.24. Get or set delayed ack timer (SCTP_DELAYED_ACK_TIME) 7.1.24. Get or set delayed ack timer (SCTP_DELAYED_ACK_TIME)
This options will get or set the delayed ack timer. The time is set This options will get or set the delayed ack timer. The time is set
in milliseconds. If the assoc_id is 0, then this sets or gets the in milliseconds. If the assoc_id is 0, then this sets or gets the
endpoints default delayed ack timer value. If the assoc_id field is endpoints default delayed ack timer value. If the assoc_id field is
non-zero, then the set or get effects the specified association. non-zero, then the set or get effects the specified association.
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
}; };
assoc_id - This parameter, indicates which association the assoc_id - This parameter, indicates which association the user is
user is preforming an action upon. Note that if preforming an action upon. Note that if this field's value is
this field's value is zero then the endpoints zero then the endpoints default value is changed (effecting future
default value is changed (effecting future
associations only). associations only).
assoc_value - This parameter contains the number of milliseconds that
the user is requesting the delayed ACK timer be set to. Note that
this value is defined in the standard to be between 200 and 500
milliseconds.
assoc_value - This parameter contains the number of milliseconds 7.1.25. Get or set fragmented interleave (SCTP_FRAGMENT_INTERLEAVE)
that the user is requesting the delayed ACK timer
be set to. Note that this value is defined in This options will at a minimum specify if the implementation is doing
the standard to be between 200 and 500 milliseconds. fragmented interleave. Fragmented interleave, for a one to many
socket, is when subsequent calls to receive a message may return
parts of messages from different associations. Some implementations
may allow you to turn this value on or off. If so, when turned off,
no fragment interleave will occur (which will cause a head of line
blocking amongst multiple associations sharing the same one to many
socket). When this option is turned on, then each receive call may
come from a different association (thus the user must receive data
with the extended calls (e.g. sctp_recvmsg) to keep track of which
association each receive belongs to.
This option takes a boolean value. A non-zero value indicates that
fragmented interleave is on. A value of zero indicates that
fragmented interleave is off.
Note that it is important that an implementation that allows this
option to be turned on, have it off by default. Otherwise an unaware
application using the one to many model may become confused and act
incorrectly.
7.1.26. Set or Get the sctp partial delivery point
(SCTP_PARTIAL_DELIVERY_POINT)
This option will set or get the SCTP partial delivery point. This
point is the size of a message where the partial delivery API will be
invoked to help free up rwnd space for the peer. Setting this to a
lower value will cause partial delivery's to happen more often. The
call's argument is an integer that sets or gets the partial delivery
point.
7.2. Read-Only Options 7.2. Read-Only Options
7.2.1. Association Status (SCTP_STATUS) 7.2.1. Association Status (SCTP_STATUS)
Applications can retrieve current status information about an Applications can retrieve current status information about an
association, including association state, peer receiver window size, association, including association state, peer receiver window size,
number of unacked data chunks, and number of data chunks pending number of unacked data chunks, and number of data chunks pending
receipt. This information is read-only. The following structure is receipt. This information is read-only. The following structure is
used to access this information: used to access this information:
skipping to change at page 64, line 17 skipping to change at page 58, line 27
int32_t sstat_state; int32_t sstat_state;
uint32_t sstat_rwnd; uint32_t sstat_rwnd;
uint16_t sstat_unackdata; uint16_t sstat_unackdata;
uint16_t sstat_penddata; uint16_t sstat_penddata;
uint16_t sstat_instrms; uint16_t sstat_instrms;
uint16_t sstat_outstrms; uint16_t sstat_outstrms;
uint32_t sstat_fragmentation_point; uint32_t sstat_fragmentation_point;
struct sctp_paddrinfo sstat_primary; struct sctp_paddrinfo sstat_primary;
}; };
sstat_state - This contains the association's current state one sstat_state - This contains the association's current state one of
of the following values: the following values:
SCTP_CLOSED SCTP_CLOSED
SCTP_BOUND SCTP_BOUND
SCTP_LISTEN SCTP_LISTEN
SCTP_COOKIE_WAIT SCTP_COOKIE_WAIT
SCTP_COOKIE_ECHOED SCTP_COOKIE_ECHOED
SCTP_ESTABLISHED SCTP_ESTABLISHED
SCTP_SHUTDOWN_PENDING SCTP_SHUTDOWN_PENDING
SCTP_SHUTDOWN_SENT SCTP_SHUTDOWN_SENT
SCTP_SHUTDOWN_RECEIVED SCTP_SHUTDOWN_RECEIVED
SCTP_SHUTDOWN_ACK_SENT SCTP_SHUTDOWN_ACK_SENT
sstat_rwnd - This contains the association peer's current receiver
sstat_rwnd - This contains the association peer's current window size.
receiver window size.
sstat_unackdata - This is the number of unacked data chunks. sstat_unackdata - This is the number of unacked data chunks.
sstat_penddata - This is the number of data chunks pending receipt. sstat_penddata - This is the number of data chunks pending receipt.
sstat_primary - This is information on the current primary peer sstat_primary - This is information on the current primary peer
address. address.
sstat_assoc_id - (one-to-many style socket) This holds the an sstat_assoc_id - (one-to-many style socket) This holds the an
identifier for the association. All identifier for the association. All notifications for a given
notifications for a given association association have the same association identifier.
have the same association identifier.
sstat_instrms - The number of streams that the peer will
be using inbound.
sstat_outstrms - The number of streams that the endpoint is
allowed to use outbound.
sstat_fragmentation_point - The size at which SCTP fragmentation sstat_instrms - The number of streams that the peer will be using
will occur. inbound.
sstat_outstrms - The number of streams that the endpoint is allowed
to use outbound.
sstat_fragmentation_point - The size at which SCTP fragmentation will
occur.
To access these status values, the application calls getsockopt() To access these status values, the application calls getsockopt()
with the option name SCTP_STATUS. The sstat_assoc_id parameter is with the option name SCTP_STATUS. The sstat_assoc_id parameter is
ignored for one-to-one style socket. ignored for one-to-one style socket.
7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO) 7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO)
Applications can retrieve information about a specific peer address Applications can retrieve information about a specific peer address
of an association, including its reachability state, congestion of an association, including its reachability state, congestion
window, and retransmission timer values. This information is read- window, and retransmission timer values. This information is read-
skipping to change at page 65, line 26 skipping to change at page 59, line 33
struct sctp_paddrinfo { struct sctp_paddrinfo {
sctp_assoc_t spinfo_assoc_id; sctp_assoc_t spinfo_assoc_id;
struct sockaddr_storage spinfo_address; struct sockaddr_storage spinfo_address;
int32_t spinfo_state; int32_t spinfo_state;
uint32_t spinfo_cwnd; uint32_t spinfo_cwnd;
uint32_t spinfo_srtt; uint32_t spinfo_srtt;
uint32_t spinfo_rto; uint32_t spinfo_rto;
uint32_t spinfo_mtu; uint32_t spinfo_mtu;
}; };
spinfo_address - This is filled in the application, and contains spinfo_address - This is filled in the application, and contains the
the peer address of interest. peer address of interest.
On return from getsockopt(): On return from getsockopt():
spinfo_state - This contains the peer addresses's state (either spinfo_state - This contains the peer addresses's state (either
SCTP_ACTIVE or SCTP_INACTIVE and possibly the modifer SCTP_ACTIVE or SCTP_INACTIVE and possibly the modifer
SCTP_UNCONFIRMED) SCTP_UNCONFIRMED)
spinfo_cwnd - This contains the peer addresses's current congestion spinfo_cwnd - This contains the peer addresses's current congestion
window. window.
spinfo_srtt - This contains the peer addresses's current smoothed spinfo_srtt - This contains the peer addresses's current smoothed
round-trip time calculation in milliseconds. round-trip time calculation in milliseconds.
spinfo_rto - This contains the peer addresses's current spinfo_rto - This contains the peer addresses's current
retransmission timeout value in milliseconds. retransmission timeout value in milliseconds.
spinfo_mtu - The current P-MTU of this address. spinfo_mtu - The current P-MTU of this address.
spinfo_assoc_id - (one-to-many style socket) This is filled in
the application, and identifies the spinfo_assoc_id - (one-to-many style socket) This is filled in the
association for this query. application, and identifies the association for this query.
To retrieve this information, use sctp_opt_info() with the To retrieve this information, use sctp_opt_info() with the
SCTP_GET_PEER_ADDR_INFO options. SCTP_GET_PEER_ADDR_INFO options.
7.3. Ancillary Data and Notification Interest Options 7.3. Ancillary Data and Notification Interest Options
Applications can receive per-message ancillary information and Applications can receive per-message ancillary information and
notifications of certain SCTP events with recvmsg(). notifications of certain SCTP events with recvmsg().
The following optional information is available to the application: The following optional information is available to the application:
skipping to change at page 66, line 10 skipping to change at page 60, line 20
7.3. Ancillary Data and Notification Interest Options 7.3. Ancillary Data and Notification Interest Options
Applications can receive per-message ancillary information and Applications can receive per-message ancillary information and
notifications of certain SCTP events with recvmsg(). notifications of certain SCTP events with recvmsg().
The following optional information is available to the application: The following optional information is available to the application:
1. SCTP_SNDRCV (sctp_data_io_event): Per-message information (i.e. 1. SCTP_SNDRCV (sctp_data_io_event): Per-message information (i.e.
stream number, TSN, SSN, etc. described in Section 5.2.2) stream number, TSN, SSN, etc. described in Section 5.2.2)
2. SCTP_ASSOC_CHANGE (sctp_association_event): (described in 2. SCTP_ASSOC_CHANGE (sctp_association_event): (described in
Section 5.3.1.1) Section 5.3.1.1)
3. SCTP_PEER_ADDR_CHANGE (sctp_address_event): (described in 3. SCTP_PEER_ADDR_CHANGE (sctp_address_event): (described in
Section 5.3.1.2) Section 5.3.1.2)
4. SCTP_SEND_FAILED (sctp_send_failure_event): (described in 4. SCTP_SEND_FAILED (sctp_send_failure_event): (described in
Section 5.3.1.4) Section 5.3.1.4)
5. SCTP_REMOTE_ERROR (sctp_peer_error_event): (described in 5. SCTP_REMOTE_ERROR (sctp_peer_error_event): (described in
Section 5.3.1.3) Section 5.3.1.3)
6. SCTP_SHUTDOWN_EVENT (sctp_shtudown_event): (described in 6. SCTP_SHUTDOWN_EVENT (sctp_shtudown_event): (described in
Section 5.3.1.5) Section 5.3.1.5)
7. SCTP_PARTIAL_DELIVERY_EVENT (sctp_partial_delivery_event): 7. SCTP_PARTIAL_DELIVERY_EVENT (sctp_partial_delivery_event):
(described in Section 5.3.1.7) (described in Section 5.3.1.7)
8. SCTP_ADAPTATION_INDICATION (sctp_adaptation_layer_event):
8. SCTP_ADAPTION_INDICATION (sctp_adaption_layer_event): (described (described in Section 5.3.1.6)
in Section 5.3.1.6)
9. SCTP_AUTHENTICATION_INDICATION (sctp_authentication_event): 9. SCTP_AUTHENTICATION_INDICATION (sctp_authentication_event):
(described in Section 5.3.1.8) (described in Section 5.3.1.8)
To receive any ancillary data or notifications, first the application To receive any ancillary data or notifications, first the application
registers it's interest by calling the SCTP_EVENTS setsockopt() with registers it's interest by calling the SCTP_EVENTS setsockopt() with
the following structure. the following structure.
struct sctp_event_subscribe{ struct sctp_event_subscribe{
uint8_t sctp_data_io_event; uint8_t sctp_data_io_event;
uint8_t sctp_association_event; uint8_t sctp_association_event;
uint8_t sctp_address_event; uint8_t sctp_address_event;
uint8_t sctp_send_failure_event; uint8_t sctp_send_failure_event;
uint8_t sctp_peer_error_event; uint8_t sctp_peer_error_event;
uint8_t sctp_shutdown_event; uint8_t sctp_shutdown_event;
uint8_t sctp_partial_delivery_event; uint8_t sctp_partial_delivery_event;
uint8_t sctp_adaption_layer_event; uint8_t sctp_adaptation_layer_event;
uint8_t sctp_authentication_event; uint8_t sctp_authentication_event;
}; };
sctp_data_io_event - Setting this flag to 1 will cause the reception sctp_data_io_event - Setting this flag to 1 will cause the reception
of SCTP_SNDRCV information on a per message basis. The application of SCTP_SNDRCV information on a per message basis. The application
will need to use the recvmsg() interface so that it can receive the will need to use the recvmsg() interface so that it can receive the
event information contained in the msg_control field. Please see event information contained in the msg_control field. Please see
Section 5.2 for further details. Setting the flag to 0 will disable Section 5.2 for further details. Setting the flag to 0 will disable
reception of the message control information. reception of the message control information.
sctp_association_event - Setting this flag to 1 will enable the sctp_association_event - Setting this flag to 1 will enable the
reception of association event notifications. Setting the flag to 0 reception of association event notifications. Setting the flag to 0
will disable association event notifications. For more information will disable association event notifications. For more information
skipping to change at page 67, line 40 skipping to change at page 61, line 41
sctp_shutdown_event - Setting this flag to 1 will enable the sctp_shutdown_event - Setting this flag to 1 will enable the
reception of shutdown event notifications. Setting the flag to 0 reception of shutdown event notifications. Setting the flag to 0
will disable shutdown event notifications. For more information on will disable shutdown event notifications. For more information on
event notifications please see Section 5.3. event notifications please see Section 5.3.
sctp_partial_delivery_event - Setting this flag to 1 will enable the sctp_partial_delivery_event - Setting this flag to 1 will enable the
reception of partial delivery notifications. Setting the flag to 0 reception of partial delivery notifications. Setting the flag to 0
will disable partial delivery event notifications. For more will disable partial delivery event notifications. For more
information on event notifications please see Section 5.3. information on event notifications please see Section 5.3.
sctp_adaption_layer_event - Setting this flag to 1 will enable the sctp_adaptation_layer_event - Setting this flag to 1 will enable the
reception of adaption layer notifications. Setting the flag to 0 reception of adaptation layer notifications. Setting the flag to 0
will disable adaption layer event notifications. For more will disable adaptation layer event notifications. For more
information on event notifications please see Section 5.3. information on event notifications please see Section 5.3.
sctp_authentication_event - Setting this flag to 1 will enable the sctp_authentication_event - Setting this flag to 1 will enable the
receiption of authentication layer notifications. Setting the flag receiption of authentication layer notifications. Setting the flag
to 0 will disable authentication layer event notifications. For More to 0 will disable authentication layer event notifications. For More
information please see Section 5.3. information please see Section 5.3.
An example where an application would like to receive data io events An example where an application would like to receive data io events
and association events but no others would be as follows: and association events but no others would be as follows:
skipping to change at page 74, line 18 skipping to change at page 67, line 9
void *msg, void *msg,
size_t len, size_t len,
struct sockaddr *from, struct sockaddr *from,
socklen_t *fromlen socklen_t *fromlen
struct sctp_sndrcvinfo *sinfo struct sctp_sndrcvinfo *sinfo
int *msg_flags) int *msg_flags)
sd - is the socket descriptor sd - is the socket descriptor
msg - is a message buffer to be filled. msg - is a message buffer to be filled.
len - is the length of the message buffer. len - is the length of the message buffer.
from - is a pointer to a address to be filled with from - is a pointer to a address to be filled with the sender of this
the sender of this messages address. messages address.
fromlen - is the from length. fromlen - is the from length.
sinfo - A pointer to a sctp_sndrcvinfo structure sinfo - A pointer to a sctp_sndrcvinfo structure to be filled upon
to be filled upon receipt of the message. receipt of the message.
msg_flags - A pointer to a integer to be filled with msg_flags - A pointer to a integer to be filled with any message
any message flags (e.g. MSG_NOTIFICATION). flags (e.g. MSG_NOTIFICATION).
8.9. sctp_connectx() 8.9. sctp_connectx()
An implementation may provide a library function (or possibly system An implementation may provide a library function (or possibly system
call) to assist the user with associating to an endpoint that is call) to assist the user with associating to an endpoint that is
multi-homed. Much like sctp_bindx() this call allows a caller to multi-homed. Much like sctp_bindx() this call allows a caller to
specify multiple addresses at which a peer can be reached. The way specify multiple addresses at which a peer can be reached. The way
the SCTP stack uses the list of addresses to set up the association the SCTP stack uses the list of addresses to set up the association
is implementation dependant. This function only specifies that the is implementation dependant. This function only specifies that the
stack will try to make use of all the addresses in the list when stack will try to make use of all the addresses in the list when
skipping to change at page 75, line 23 skipping to change at page 68, line 17
int sctp_send(int sd, int sctp_send(int sd,
const void *msg, const void *msg,
size_t len, size_t len,
const struct sctp_sndrcvinfo *sinfo, const struct sctp_sndrcvinfo *sinfo,
int flags); int flags);
sd - is the socket descriptor sd - is the socket descriptor
msg - The message to be sent msg - The message to be sent
len - The length of the message len - The length of the message
sinfo - A pointer to a sctp_sndrcvinfo struture used sinfo - A pointer to a sctp_sndrcvinfo struture used as described in
as described in 5.2.2 for a sendmsg call. 5.2.2 for a sendmsg call.
flags - is used in the same format as the sendmsg call flags - is used in the same format as the sendmsg call flags (e.g.
flags (e.g. MSG_DONTROUTE). MSG_DONTROUTE).
This function call may also be used to terminate an association using This function call may also be used to terminate an association using
an association identification by setting the sinfo.sinfo_flags to an association identification by setting the sinfo.sinfo_flags to
SCTP_EOF and the sinfo.sinf_associd to the association that needs to SCTP_EOF and the sinfo.sinf_associd to the association that needs to
be terminated. In such a case the len of the message would be zero. be terminated. In such a case the len of the message would be zero.
8.11. sctp_sendx() 8.11. sctp_sendx()
An implementation may provide another alternative function or system An implementation may provide another alternative function or system
call to assist an application with the sending of data without the call to assist an application with the sending of data without the
skipping to change at page 76, line 14 skipping to change at page 69, line 4
sctp_sendx(). Its syntax is, sctp_sendx(). Its syntax is,
int sctp_sendx(int sd, int sctp_sendx(int sd,
const void *msg, const void *msg,
size_t len, size_t len,
struct sockaddr *addrs, struct sockaddr *addrs,
int addrcnt, int addrcnt,
struct sctp_sndrcvinfo *sinfo, struct sctp_sndrcvinfo *sinfo,
int flags); int flags);
sd - is the socket descriptor sd - is the socket descriptor
msg - The message to be sent msg - The message to be sent
len - The length of the message len - The length of the message
addrs - is an array of addresses. addrs - is an array of addresses.
addrcnt - is the number of addresses in the array. addrcnt - is the number of addresses in the array.
sinfo - A pointer to a sctp_sndrcvinfo struture used sinfo - A pointer to a sctp_sndrcvinfo struture used as described in
as described in 5.2.2 for a sendmsg call. 5.2.2 for a sendmsg call.
flags - is used in the same format as the sendmsg call flags - is used in the same format as the sendmsg call flags (e.g.
flags (e.g. MSG_DONTROUTE). MSG_DONTROUTE).
Note that on return from this call the sinfo structure will have Note that on return from this call the sinfo structure will have
changed in that the sinfo_assoc_id will be filled in with the new changed in that the sinfo_assoc_id will be filled in with the new
association id. association id.
This function call may also be used to terminate an association using This function call may also be used to terminate an association using
an association identification by setting the sinfo.sinfo_flags to an association identification by setting the sinfo.sinfo_flags to
SCTP_EOF and the sinfo.sinfo_associd to the association that needs to SCTP_EOF and the sinfo.sinfo_associd to the association that needs to
be terminated. In such a case the len of the message would be zero. be terminated. In such a case the len of the message would be zero.
8.12. sctp_getaddrlen
For application binary portability it is sometimes desireable to know
what the kernel thinks is the length of a socket address family.
This function, when called with a valid family type will return the
length that the operating system uses in the specified family's
socket address structure.
int sctp_getaddrlen(sa_family_t family);
9. Preprocessor Constants 9. Preprocessor Constants
For application portability it is desireable to define pre-processor For application portability it is desireable to define pre-processor
constants for determination if sctp is present and supports various constants for determination if sctp is present and supports various
features. The following pre-processor constants should be defined in features. The following pre-processor constants should be defined in
a include file, sctp.h. a include file, sctp.h.
HAVE_SCTP - If this constant is defined to 1, then an implementation HAVE_SCTP - If this constant is defined to 1, then an implementation
of SCTP is available. of SCTP is available.
HAVE_KERNEL_SCTP - If this constant is defined to 1, then a kernel HAVE_KERNEL_SCTP - If this constant is defined to 1, then a kernel
SCTP implementation is available through the sockets interface. SCTP implementation is available through the sockets interface.
HAVE_SCTP_PRSCTP - If this constant is defined to 1, then the SCTP HAVE_SCTP_PRSCTP - If this constant is defined to 1, then the SCTP
implementation supports the partial reliablility extension to implementation supports the partial reliablility extension to
SCTP. SCTP.
HAVE_SCTP_ADDIP - If this constant is defined to 1, then the SCTP HAVE_SCTP_ADDIP - If this constant is defined to 1, then the SCTP
implementation supports the dynamic address extension to SCTP. implementation supports the dynamic address extension to SCTP.
HAVE_SCTP_CANSET_PRIMARY - If this constant is defined to 1, then the HAVE_SCTP_CANSET_PRIMARY - If this constant is defined to 1, then the
SCTP implementation supports the ability to request setting of the SCTP implementation supports the ability to request setting of the
remote primary address. remote primary address.
HAVE_SCTP_SAT_NETWORK_CAPABILITY - If this constant is defined to 1, HAVE_SCTP_SAT_NETWORK_CAPABILITY - If this constant is defined to 1,
then the SCTP implementation supports the satellite network then the SCTP implementation supports the satellite network
extension to SCTP. extension to SCTP.
HAVE_SCTP_MULTIBUF - If this constant is defined to 1, then the SCTP HAVE_SCTP_MULTIBUF - If this constant is defined to 1, then the SCTP
implementation dedicates separate buffer space to each association implementation dedicates separate buffer space to each association
on a one-to-many socket. If this constant is defined to 0, then on a one-to-many socket. If this constant is defined to 0, then
the implementation provides a single block of shared buffer space the implementation provides a single block of shared buffer space
for a one-to-many socket. for a one-to-many socket.
HAVE_SCTP_NOCONNECT - If this constant is defined to 1, then the SCTP HAVE_SCTP_NOCONNECT - If this constant is defined to 1, then the SCTP
implementation supports initiating an association on a one-to-one implementation supports initiating an association on a one-to-one
style socket without the use of connect(), as outlined in style socket without the use of connect(), as outlined in
Section 4.1.5. Section 4.1.5.
10. Security Considerations 10. IANA considerations
This document contains no IANA considerations.
11. Security Considerations
Many TCP and UDP implementations reserve port numbers below 1024 for Many TCP and UDP implementations reserve port numbers below 1024 for
privileged users. If the target platform supports privileged users, privileged users. If the target platform supports privileged users,
the SCTP implementation SHOULD restrict the ability to call bind() or the SCTP implementation SHOULD restrict the ability to call bind() or
sctp_bindx() on these port numbers to privileged users. sctp_bindx() on these port numbers to privileged users.
Similarly unpriviledged users should not be able to set protocol Similarly unpriviledged users should not be able to set protocol
parameters which could result in the congestion control algorithm parameters which could result in the congestion control algorithm
being more aggressive than permitted on the public Internet. These being more aggressive than permitted on the public Internet. These
parameters are: parameters are:
struct sctp_rtoinfo struct sctp_rtoinfo
If an unprivileged user inherits a one-to-many style socket with open If an unprivileged user inherits a one-to-many style socket with open
associations on a privileged port, it MAY be permitted to accept new associations on a privileged port, it MAY be permitted to accept new
associations, but it SHOULD NOT be permitted to open new associations, but it SHOULD NOT be permitted to open new
associations. This could be relevant for the r* family of protocols. associations. This could be relevant for the r* family of protocols.
11. Acknowledgments 12. Acknowledgments
Special acknowledgment is givne to Ken Fujita who helped extensively Special acknowledgment is given to Ken Fujita and Jonathan Woods who
in the early formation of this document. helped extensively in the early formation of this document.
The authors also wish to thank Kavitha Baratakke, Mike Bartlett, Jon The authors also wish to thank Kavitha Baratakke, Mike Bartlett, Jon
Berger, Scott Kimble, Renee Revis, and many others on the TSVWG Berger, Mark Butler, Scott Kimble, Renee Revis, and many others on
mailing list for contributing valuable comments. the TSVWG mailing list for contributing valuable comments.
A special thanks to Phillip Conrad, for his suggested text, quick and A special thanks to Phillip Conrad, for his suggested text, quick and
constructive insights, and most of all his persistent fighting to constructive insights, and most of all his persistent fighting to
keep the interface to SCTP usable for the application programmer. keep the interface to SCTP usable for the application programmer.
12. References 13. References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 13.1. Normative references
September 1981.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[3] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for
RFC 2292, February 1998. IPv6", RFC 2292, February 1998.
[7] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
Socket Interface Extensions for IPv6", RFC 2553, March 1999. "Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
"Stream Control Transmission Protocol", RFC 2960, October 2000. Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
13.2. Informational References
Appendix A. one-to-one style Code Example Appendix A. one-to-one style Code Example
The following code is a simple implementation of an echo server over The following code is a simple implementation of an echo server over
SCTP. The example shows how to use some features of one-to-one style SCTP. The example shows how to use some features of one-to-one style
IPv4 SCTP sockets, including: IPv4 SCTP sockets, including:
o Opening, binding, and listening for new associations on a socket; o Opening, binding, and listening for new associations on a socket;
o Enabling ancillary data o Enabling ancillary data
o Enabling notifications o Enabling notifications
o Using ancillary data with sendmsg() and recvmsg() o Using ancillary data with sendmsg() and recvmsg()
o Using MSG_EOR to determine if an entire message has been read o Using MSG_EOR to determine if an entire message has been read
o Handling notifications o Handling notifications
#include <stdio.h> #include <stdio.h>
#include <sys/types.h> #include <sys/types.h>
#include <sys/socket.h> #include <sys/socket.h>
#include <netinet/in.h> #include <netinet/in.h>
#include <arpa/inet.h> #include <arpa/inet.h>
#include <stdlib.h> #include <stdlib.h>
#include <unistd.h> #include <unistd.h>
#include <netinet/sctp.h> #include <netinet/sctp.h>
skipping to change at page 81, line 41 skipping to change at page 73, line 29
sre = &snp->sn_remote_error; sre = &snp->sn_remote_error;
printf("^^^ remote_error: err=%hu len=%hu\n", printf("^^^ remote_error: err=%hu len=%hu\n",
ntohs(sre->sre_error), ntohs(sre->sre_length)); ntohs(sre->sre_error), ntohs(sre->sre_length));
break; break;
case SCTP_SHUTDOWN_EVENT: case SCTP_SHUTDOWN_EVENT:
printf("^^^ shutdown event\n"); printf("^^^ shutdown event\n");
break; break;
default: default:
printf("unknown type: %hu\n", snp->sn_header.sn_type); printf("unknown type: %hu\n", snp->sn_header.sn_type);
break; break;
} };
} }
static void * static void *
mysctp_recvmsg(int fd, struct msghdr *msg, void *buf, size_t *buflen, mysctp_recvmsg(int fd, struct msghdr *msg, void *buf, size_t *buflen,
ssize_t *nrp, size_t cmsglen) ssize_t *nrp, size_t cmsglen)
{ {
ssize_t nr = 0, nnr = 0; ssize_t nr = 0, nnr = 0;
struct iovec iov[1]; struct iovec iov[1];
*nrp = 0; *nrp = 0;
skipping to change at page 83, line 27 skipping to change at page 75, line 12
/* Set up the msghdr structure for receiving */ /* Set up the msghdr structure for receiving */
memset(msg, 0, sizeof (*msg)); memset(msg, 0, sizeof (*msg));
msg->msg_control = cbuf; msg->msg_control = cbuf;
msg->msg_controllen = cmsglen; msg->msg_controllen = cmsglen;
msg->msg_flags = 0; msg->msg_flags = 0;
cmsg = (struct cmsghdr *)cbuf; cmsg = (struct cmsghdr *)cbuf;
sri = (struct sctp_sndrcvinfo *)(cmsg + 1); sri = (struct sctp_sndrcvinfo *)(cmsg + 1);
/* Wait for something to echo */ /* Wait for something to echo */
while (buf = mysctp_recvmsg(fd, msg, buf, &buflen, &nr, cmsglen)) { while (buf = mysctp_recvmsg(fd, msg,
buf, &buflen, &nr, cmsglen)) {
/* Intercept notifications here */ /* Intercept notifications here */
if (msg->msg_flags & MSG_NOTIFICATION) { if (msg->msg_flags & MSG_NOTIFICATION) {
handle_event(buf); handle_event(buf);
continue; continue;
} }
iov->iov_base = buf; iov->iov_base = buf;
iov->iov_len = nr; iov->iov_len = nr;
msg->msg_iov = iov; msg->msg_iov = iov;
skipping to change at page 84, line 51 skipping to change at page 76, line 36
} }
/* Enable all events */ /* Enable all events */
event.sctp_data_io_event = 1; event.sctp_data_io_event = 1;
event.sctp_association_event = 1; event.sctp_association_event = 1;
event.sctp_address_event = 1; event.sctp_address_event = 1;
event.sctp_send_failure_event = 1; event.sctp_send_failure_event = 1;
event.sctp_peer_error_event = 1; event.sctp_peer_error_event = 1;
event.sctp_shutdown_event = 1; event.sctp_shutdown_event = 1;
event.sctp_partial_delivery_event = 1; event.sctp_partial_delivery_event = 1;
event.sctp_adaption_layer_event = 1; event.sctp_adaptation_layer_event = 1;
if (setsockopt(cfd, IPPROTO_SCTP, if (setsockopt(cfd, IPPROTO_SCTP,
SCTP_EVENTS, &event, SCTP_EVENTS, &event,
sizeof(event)) != 0) { sizeof(event)) != 0) {
perror("setevent failed"); perror("setevent failed");
exit(1); exit(1);
} }
/* Echo back any and all data */ /* Echo back any and all data */
echo(cfd,0); echo(cfd,0);
} }
} }
skipping to change at page 87, line 4 skipping to change at page 77, line 44
} }
/* Enable all notifications and events */ /* Enable all notifications and events */
event.sctp_data_io_event = 1; event.sctp_data_io_event = 1;
event.sctp_association_event = 1; event.sctp_association_event = 1;
event.sctp_address_event = 1; event.sctp_address_event = 1;
event.sctp_send_failure_event = 1; event.sctp_send_failure_event = 1;
event.sctp_peer_error_event = 1; event.sctp_peer_error_event = 1;
event.sctp_shutdown_event = 1; event.sctp_shutdown_event = 1;
event.sctp_partial_delivery_event = 1; event.sctp_partial_delivery_event = 1;
event.sctp_adaption_layer_event = 1; event.sctp_adaptation_layer_event = 1;
if (setsockopt(fd, IPPROTO_SCTP, if (setsockopt(fd, IPPROTO_SCTP,
SCTP_EVENTS, &event, SCTP_EVENTS, &event,
sizeof(event)) != 0) { sizeof(event)) != 0) {
perror("setevent failed"); perror("setevent failed");
exit(1); exit(1);
} }
/* Set associations to auto-close in 2 seconds of /* Set associations to auto-close in 2 seconds of
* inactivity * inactivity
*/ */
if (setsockopt(fd, IPPROTO_SCTP, SCTP_AUTOCLOSE, if (setsockopt(fd, IPPROTO_SCTP, SCTP_AUTOCLOSE,
skipping to change at page 88, line 35 skipping to change at page 79, line 35
La Monte H.P. Yarroll La Monte H.P. Yarroll
TimeSys Corp TimeSys Corp
925 Liberty Ave. 925 Liberty Ave.
Pittsburgh, PA 15222 Pittsburgh, PA 15222
USA USA
Phone: Phone:
Email: piggy@acm.org Email: piggy@acm.org
Jonathan Wood
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone:
Email: jonwood@speakeasy.net
Kacheong Poon Kacheong Poon
Sun Microsystems, Inc. Sun Microsystems, Inc.
4150 Network Circle 4150 Network Circle
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Phone: Phone:
Email: kacheong.poon@sun.com Email: kacheong.poon@sun.com
Michael Tuexen Michael Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 90, line 41 skipping to change at page 81, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 198 change blocks. 
629 lines changed or deleted 591 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/