Subject: text for pd-api changes

From: Randall Stewart <[email-masked]>
Date: Sat, 21 Apr 2007 07:47:21 -0400

Dear all:

I have attached the rfc-diff of the -14 to the upcoming
-15 changes.

I made all the changes on the plane as discussed previously.
There are some other changes in here that Michael did a ways
back I believe.. he can comment on those..

The big things I added were:

a) The changes to the PD-API event
b) The mega-changes to the Fragment_interleave
c) Kacheong's typos
d) A restriction, that I felt made sense, that you don't
    get the extinfo unless you have a MSG_EOR. The stack
    will only assure what your next msg is if and only
    if you are fully consuming the present message. This
    makes sense to me :-D

Michaels changes I believe had to do with the MAXSEG option..

R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
draft-ietf-tsvwg-sctpsocket-14.txt

draft-ietf-tsvwg-sctpsocket-15.txt

Network Working Group R. Stewart

Network Working Group R. Stewart

Internet-Draft Cisco Systems, Inc.

Internet-Draft Cisco Systems, Inc.

Expires: June 14, 2007 Q. Xie

Expires: October 23, 2007 Q. Xie

Motorola, Inc.

Motorola, Inc.

L. Yarroll

L. Yarroll

TimeSys Corp

TimeSys Corp

K. Poon

K. Poon

Sun Microsystems, Inc.

Sun Microsystems, Inc.

M. Tuexen

M. Tuexen

Univ. of Applied Sciences Muenster

Univ. of Applied Sciences Muenster

December 11, 2006

April 21, 2007

Sockets API Extensions for Stream Control Transmission Protocol (SCTP)

Sockets API Extensions for Stream Control Transmission Protocol (SCTP)

draft-ietf-tsvwg-sctpsocket-14.txt

draft-ietf-tsvwg-sctpsocket-15.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 41

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 June 14, 2007.

This Internet-Draft will expire on October 23, 2007.

Copyright Notice

Copyright Notice

Copyright (C) The IETF Trust (2006).

Copyright (C) The IETF Trust (2007).

Abstract

Abstract

This document describes a mapping of the Stream Control Transmission

This document describes a mapping of the Stream Control Transmission

Protocol SCTP into a sockets API. The benefits of this mapping

Protocol SCTP into a sockets API. The benefits of this mapping

include compatibility for TCP applications, access to new SCTP

include compatibility for TCP applications, access to new SCTP

features and a consolidated error and event notification scheme.

features and a consolidated error and event notification scheme.

Table of Contents

Table of Contents

skipping to change at page 2, line 42

skipping to change at page 2, line 42

4.1.7. shutdown() - one-to-one style socket . . . . . . . . . 19

4.1.7. shutdown() - one-to-one style socket . . . . . . . . . 19

4.1.8. sendmsg() and recvmsg() - one-to-one style socket . . 20

4.1.8. sendmsg() and recvmsg() - one-to-one style socket . . 20

4.1.9. getpeername() . . . . . . . . . . . . . . . . . . . . 20

4.1.9. getpeername() . . . . . . . . . . . . . . . . . . . . 20

5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 21

5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 21

5.1. The msghdr and cmsghdr Structures . . . . . . . . . . . . 21

5.1. The msghdr and cmsghdr Structures . . . . . . . . . . . . 21

5.2. SCTP msg_control Structures . . . . . . . . . . . . . . . 22

5.2. SCTP msg_control Structures . . . . . . . . . . . . . . . 22

5.2.1. SCTP Initiation Structure (SCTP_INIT) . . . . . . . . 23

5.2.1. SCTP Initiation Structure (SCTP_INIT) . . . . . . . . 23

5.2.2. SCTP Header Information Structure (SCTP_SNDRCV) . . . 24

5.2.2. SCTP Header Information Structure (SCTP_SNDRCV) . . . 24

5.2.3. Extended SCTP Header Information Structure

5.2.3. Extended SCTP Header Information Structure

(SCTP_EXTRCV) . . . . . . . . . . . . . . . . . . . . 27

(SCTP_EXTRCV) . . . . . . . . . . . . . . . . . . . . 27

5.3. SCTP Events and Notifications . . . . . . . . . . . . . . 31

5.3. SCTP Events and Notifications . . . . . . . . . . . . . . 29

5.3.1. SCTP Notification Structure . . . . . . . . . . . . . 31

5.3.1. SCTP Notification Structure . . . . . . . . . . . . . 29

5.4. Ancillary Data Considerations and Semantics . . . . . . . 42

5.4. Ancillary Data Considerations and Semantics . . . . . . . 40

5.4.1. Multiple Items and Ordering . . . . . . . . . . . . . 42

5.4.1. Multiple Items and Ordering . . . . . . . . . . . . . 40

5.4.2. Accessing and Manipulating Ancillary Data . . . . . . 42

5.4.2. Accessing and Manipulating Ancillary Data . . . . . . 40

5.4.3. Control Message Buffer Sizing . . . . . . . . . . . . 43

5.4.3. Control Message Buffer Sizing . . . . . . . . . . . . 41

6. Common Operations for Both Styles . . . . . . . . . . . . . . 44

6. Common Operations for Both Styles . . . . . . . . . . . . . . 42

6.1. send(), recv(), sendto(), recvfrom() . . . . . . . . . . . 44

6.1. send(), recv(), sendto(), recvfrom() . . . . . . . . . . . 42

6.2. setsockopt(), getsockopt() . . . . . . . . . . . . . . . . 45

6.2. setsockopt(), getsockopt() . . . . . . . . . . . . . . . . 43

6.3. read() and write() . . . . . . . . . . . . . . . . . . . . 46

6.3. read() and write() . . . . . . . . . . . . . . . . . . . . 44

6.4. getsockname() . . . . . . . . . . . . . . . . . . . . . . 46

6.4. getsockname() . . . . . . . . . . . . . . . . . . . . . . 44

7. Socket Options . . . . . . . . . . . . . . . . . . . . . . . . 47

7. Socket Options . . . . . . . . . . . . . . . . . . . . . . . . 45

7.1. Read / Write Options . . . . . . . . . . . . . . . . . . . 48

7.1. Read / Write Options . . . . . . . . . . . . . . . . . . . 46

7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) . . . 48

7.1.1. Retransmission Timeout Parameters (SCTP_RTOINFO) . . . 46

7.1.2. Association Parameters (SCTP_ASSOCINFO) . . . . . . . 49

7.1.2. Association Parameters (SCTP_ASSOCINFO) . . . . . . . 47

7.1.3. Initialization Parameters (SCTP_INITMSG) . . . . . . . 51

7.1.3. Initialization Parameters (SCTP_INITMSG) . . . . . . . 49

7.1.4. SO_LINGER . . . . . . . . . . . . . . . . . . . . . . 51

7.1.4. SO_LINGER . . . . . . . . . . . . . . . . . . . . . . 49

7.1.5. SCTP_NODELAY . . . . . . . . . . . . . . . . . . . . . 51

7.1.5. SCTP_NODELAY . . . . . . . . . . . . . . . . . . . . . 49

7.1.6. SO_RCVBUF . . . . . . . . . . . . . . . . . . . . . . 51

7.1.6. SO_RCVBUF . . . . . . . . . . . . . . . . . . . . . . 50

7.1.7. SO_SNDBUF . . . . . . . . . . . . . . . . . . . . . . 52

7.1.7. SO_SNDBUF . . . . . . . . . . . . . . . . . . . . . . 50

7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE) . . . 52

7.1.8. Automatic Close of associations (SCTP_AUTOCLOSE) . . . 50

7.1.9. Set Peer Primary Address

7.1.9. Set Peer Primary Address

(SCTP_SET_PEER_PRIMARY_ADDR) . . . . . . . . . . . . . 52

(SCTP_SET_PEER_PRIMARY_ADDR) . . . . . . . . . . . . . 50

7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR) . . . . . . . 53

7.1.10. Set Primary Address (SCTP_PRIMARY_ADDR) . . . . . . . 51

7.1.11. Set Adaptation Layer Indicator

7.1.11. Set Adaptation Layer Indicator

(SCTP_ADAPTATION_LAYER) . . . . . . . . . . . . . . . 53

(SCTP_ADAPTATION_LAYER) . . . . . . . . . . . . . . . 51

7.1.12. Enable/Disable message fragmentation

7.1.12. Enable/Disable message fragmentation

(SCTP_DISABLE_FRAGMENTS) . . . . . . . . . . . . . . . 53

(SCTP_DISABLE_FRAGMENTS) . . . . . . . . . . . . . . . 51

7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) . . . 54

7.1.13. Peer Address Parameters (SCTP_PEER_ADDR_PARAMS) . . . 52

7.1.14. Set default send parameters

7.1.14. Set default send parameters

(SCTP_DEFAULT_SEND_PARAM) . . . . . . . . . . . . . . 56

(SCTP_DEFAULT_SEND_PARAM) . . . . . . . . . . . . . . 54

7.1.15. Set notification and ancillary events (SCTP_EVENTS) . 57

7.1.15. Set notification and ancillary events (SCTP_EVENTS) . 54

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) . . . . . . . . . . . . . 54

7.1.17. Set the maximum fragmentation size (SCTP_MAXSEG) . . . 57

7.1.17. Get or set the maximum fragmentation size

(SCTP_MAXSEG) . . . . . . . . . . . . . . . . . . . . 55

7.1.18. Add a chunk that must be authenticated

7.1.18. Add a chunk that must be authenticated

(SCTP_AUTH_CHUNK) . . . . . . . . . . . . . . . . . . 57

(SCTP_AUTH_CHUNK) . . . . . . . . . . . . . . . . . . 55

7.1.19. Get or set the list of supported HMAC Identifiers

7.1.19. Get or set the list of supported HMAC Identifiers

(SCTP_HMAC_IDENT) . . . . . . . . . . . . . . . . . . 58

(SCTP_HMAC_IDENT) . . . . . . . . . . . . . . . . . . 56

7.1.20. Set a shared key (SCTP_AUTH_KEY) . . . . . . . . . . . 58

7.1.20. Set a shared key (SCTP_AUTH_KEY) . . . . . . . . . . . 56

7.1.21. Get or set the active shared key

7.1.21. Get or set the active shared key

(SCTP_AUTH_ACTIVE_KEY) . . . . . . . . . . . . . . . . 59

(SCTP_AUTH_ACTIVE_KEY) . . . . . . . . . . . . . . . . 57

7.1.22. Delete a shared key (SCTP_AUTH_DELETE_KEY) . . . . . . 59

7.1.22. Delete a shared key (SCTP_AUTH_DELETE_KEY) . . . . . . 57

7.1.23. Get or set delayed ack timer

7.1.23. Get or set delayed ack timer

(SCTP_DELAYED_ACK_TIME) . . . . . . . . . . . . . . . 60

(SCTP_DELAYED_ACK_TIME) . . . . . . . . . . . . . . . 58

7.1.24. Get or set fragmented interleave

7.1.24. Get or set fragmented interleave

(SCTP_FRAGMENT_INTERLEAVE) . . . . . . . . . . . . . . 60

(SCTP_FRAGMENT_INTERLEAVE) . . . . . . . . . . . . . . 58

7.1.25. Set or Get the sctp partial delivery point

7.1.25. Set or Get the sctp partial delivery point

(SCTP_PARTIAL_DELIVERY_POINT) . . . . . . . . . . . . 61

(SCTP_PARTIAL_DELIVERY_POINT) . . . . . . . . . . . . 59

7.1.26. Set or Get the use of extended receive info

7.1.26. Set or Get the use of extended receive info

(SCTP_USE_EXT_RCVINFO) . . . . . . . . . . . . . . . . 61

(SCTP_USE_EXT_RCVINFO) . . . . . . . . . . . . . . . . 60

7.1.27. Set or Get the auto asconf flag (SCTP_AUTO_ASCONF) . . 61

7.1.27. Set or Get the auto asconf flag (SCTP_AUTO_ASCONF) . . 60

7.1.28. Set or Get the maximum burst (SCTP_MAX_BURST) . . . . 61

7.1.28. Set or Get the maximum burst (SCTP_MAX_BURST) . . . . 60

7.1.29. Set or Get the default context (SCTP_CONTEXT) . . . . 62

7.1.29. Set or Get the default context (SCTP_CONTEXT) . . . . 60

7.1.30. Enable or disable explicit EOR marking

7.1.30. Enable or disable explicit EOR marking

(SCTP_EXPLICIT_EOR) . . . . . . . . . . . . . . . . . 62

(SCTP_EXPLICIT_EOR) . . . . . . . . . . . . . . . . . 61

7.2. Read-Only Options . . . . . . . . . . . . . . . . . . . . 62

7.2. Read-Only Options . . . . . . . . . . . . . . . . . . . . 61

7.2.1. Association Status (SCTP_STATUS) . . . . . . . . . . . 62

7.2.1. Association Status (SCTP_STATUS) . . . . . . . . . . . 61

7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO) . . 64

7.2.2. Peer Address Information (SCTP_GET_PEER_ADDR_INFO) . . 63

7.2.3. Get the list of chunks the peer requires to be

7.2.3. Get the list of chunks the peer requires to be

authenticated (SCTP_PEER_AUTH_CHUNKS) . . . . . . . . 65

authenticated (SCTP_PEER_AUTH_CHUNKS) . . . . . . . . 64

7.2.4. Get the list of chunks the local endpoint requires

7.2.4. Get the list of chunks the local endpoint requires

to be authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . . 65

to be authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . . 64

7.2.5. Get the list of current associations

7.2.5. Get the list of current associations

(SCTP_GET_ASOC_ID_LIST) . . . . . . . . . . . . . . . 65

(SCTP_GET_ASOC_ID_LIST) . . . . . . . . . . . . . . . 64

7.3. Ancillary Data and Notification Interest Options . . . . . 66

7.3. Ancillary Data and Notification Interest Options . . . . . 65

8. New Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 68

8. New Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 67

8.1. sctp_bindx() . . . . . . . . . . . . . . . . . . . . . . . 69

8.1. sctp_bindx() . . . . . . . . . . . . . . . . . . . . . . . 68

8.2. Branched-off Association . . . . . . . . . . . . . . . . . 70

8.2. Branched-off Association . . . . . . . . . . . . . . . . . 69

8.3. sctp_getpaddrs() . . . . . . . . . . . . . . . . . . . . . 70

8.3. sctp_getpaddrs() . . . . . . . . . . . . . . . . . . . . . 69

8.4. sctp_freepaddrs() . . . . . . . . . . . . . . . . . . . . 71

8.4. sctp_freepaddrs() . . . . . . . . . . . . . . . . . . . . 70

8.5. sctp_getladdrs() . . . . . . . . . . . . . . . . . . . . . 71

8.5. sctp_getladdrs() . . . . . . . . . . . . . . . . . . . . . 70

8.6. sctp_freeladdrs() . . . . . . . . . . . . . . . . . . . . 72

8.6. sctp_freeladdrs() . . . . . . . . . . . . . . . . . . . . 71

8.7. sctp_sendmsg() . . . . . . . . . . . . . . . . . . . . . . 72

8.7. sctp_sendmsg() . . . . . . . . . . . . . . . . . . . . . . 71

8.8. sctp_recvmsg() . . . . . . . . . . . . . . . . . . . . . . 73

8.8. sctp_recvmsg() . . . . . . . . . . . . . . . . . . . . . . 72

8.9. sctp_connectx() . . . . . . . . . . . . . . . . . . . . . 73

8.9. sctp_connectx() . . . . . . . . . . . . . . . . . . . . . 72

8.10. sctp_send() . . . . . . . . . . . . . . . . . . . . . . . 74

8.10. sctp_send() . . . . . . . . . . . . . . . . . . . . . . . 73

8.11. sctp_sendx() . . . . . . . . . . . . . . . . . . . . . . . 75

8.11. sctp_sendx() . . . . . . . . . . . . . . . . . . . . . . . 74

8.12. sctp_getaddrlen . . . . . . . . . . . . . . . . . . . . . 76

8.12. sctp_getaddrlen . . . . . . . . . . . . . . . . . . . . . 75

9. Preprocessor Constants . . . . . . . . . . . . . . . . . . . . 76

9. Preprocessor Constants . . . . . . . . . . . . . . . . . . . . 75

10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 77

10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 76

11. Security Considerations . . . . . . . . . . . . . . . . . . . 77

11. Security Considerations . . . . . . . . . . . . . . . . . . . 76

12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77

12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76

13. Normative references . . . . . . . . . . . . . . . . . . . . . 78

13. Normative references . . . . . . . . . . . . . . . . . . . . . 77

Appendix A. one-to-one style Code Example . . . . . . . . . . . . 78

Appendix A. one-to-one style Code Example . . . . . . . . . . . . 77

Appendix B. one-to-many style Code Example . . . . . . . . . . . 84

Appendix B. one-to-many style Code Example . . . . . . . . . . . 83

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84

Intellectual Property and Copyright Statements . . . . . . . . . . 87

Intellectual Property and Copyright Statements . . . . . . . . . . 86

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

Protocol suite to many operating systems. Both TCP RFC793 [RFC0793]

and UDP RFC768 [RFC0768] have benefited from this standard

and UDP RFC768 [RFC0768] have benefited from this standard

representation and access method across many diverse platforms. SCTP

representation and access method across many diverse platforms. SCTP

is a new protocol that provides many of the characteristics of TCP

is a new protocol that provides many of the characteristics of TCP

but also incorporates semantics more akin to UDP. This document

but also incorporates semantics more akin to UDP. This document

defines a method to map the existing sockets API for use with SCTP,

defines a method to map the existing sockets API for use with SCTP,

skipping to change at page 11, line 11

skipping to change at page 11, line 11

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 per stream can be partially delivered.

one message at a time can be partially delivered in any stream. The

socket option SCTP_FRAGMENT_INTERLEAVE controls various aspects of

what interlacing of messages occurs for both the one-to-one and the

one-to-many model sockets. Please consult Section 7.1.24 for further

details on message delivery options.

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 [RFC2960]) on ALL the associations

in Section 10.1 of RFC2960 [RFC2960]) on ALL the associations

currently represented by a one-to-many style socket.

currently represented by a one-to-many style socket.

skipping to change at page 27, line 21

skipping to change at page 27, line 21

for the association announced in the SCTP_COMM_UP notification. All

for the association announced in the SCTP_COMM_UP notification. All

notifications for a given association have the same identifier.

notifications for a given association have the same identifier.

Ignored for one-to-one style sockets.

Ignored for one-to-one style sockets.

A sctp_sndrcvinfo item always corresponds to the data in msg_iov.

A sctp_sndrcvinfo item always corresponds to the data in msg_iov.

5.2.3. Extended SCTP Header Information Structure (SCTP_EXTRCV)

5.2.3. Extended SCTP Header Information Structure (SCTP_EXTRCV)

This cmsghdr structure specifies SCTP options for SCTP header

This cmsghdr structure specifies SCTP options for SCTP header

information about a received message via recvmsg(). Note that this

information about a received message via recvmsg(). Note that this

structure is an extended version of SCTP_SNDRCV and will only be

structure is an extended version of SCTP_SNDRCV (see Section 5.2.2)

received if the user has set the socket option SCTP_USE_EXT_RCVINFO

and will only be received if the user has set the socket option

to true in addition to any event subscription needed to receive

SCTP_USE_EXT_RCVINFO to true in addition to any event subscription

ancillary data..

needed to receive ancillary data. Note that next message data is not

valid unless the current message is completely read, i.e. the MSG_EOR

is set, in other words if you have more data to read from the current

message then no next message information will be available.

cmsg_level cmsg_type cmsg_data[]

cmsg_level cmsg_type cmsg_data[]

------------ ------------ ----------------------

------------ ------------ ----------------------

IPPROTO_SCTP SCTP_SNDRCV struct sctp_sndrcvinfo

IPPROTO_SCTP SCTP_EXTRCV struct sctp_extrcvinfo

Here is the definition of sctp_sndrcvinfo:

Here is the definition of sctp_extrcvinfo

struct sctp_extrcvinfo {

struct sctp_extrcvinfo {

uint16_t sinfo_stream;

struct sctp_sndrcvinfo serinfo_sinfo;

uint16_t sinfo_ssn;

uint16_t serinfo_next_flags;

uint16_t sinfo_flags;

uint16_t serinfo_next_stream;

uint32_t sinfo_ppid;

uint32_t serinfo_next_aid;

uint32_t sinfo_context;

uint32_t serinfo_next_length;

uint32_t sinfo_timetolive;

uint32_t serinfo_next_ppid;

uint32_t sinfo_tsn;

uint32_t sinfo_cumtsn;

sctp_assoc_t sinfo_assoc_id;

uint16_t next_flags;

uint16_t next_stream;

uint32_t next_asocid;

uint32_t next_length;

uint32_t next_ppid;

};

};

sinfo_stream: 16 bits (unsigned integer)

serinfo_sinfo: structure

For recvmsg() the SCTP stack places the message's stream number in

this value. For sendmsg() this value holds the stream number that

the application wishes to send this message to. If a sender

specifies an invalid stream number an error indication is returned

and the call fails.

sinfo_ssn: 16 bits (unsigned integer)

For recvmsg() this value contains the stream sequence number that the

remote endpoint placed in the DATA chunk. For fragmented messages

this is the same number for all deliveries of the message (if more

than one recvmsg() is needed to read the message). The sendmsg()

call will ignore this parameter.

sinfo_ppid: 32 bits (unsigned integer)

This value in sendmsg() is an unsigned integer that is passed to the

remote end in each user message. In recvmsg() this value is the same

information that was passed by the upper layer in the peer

application. Please note that the SCTP stack performs no byte order

modification of this field. For example, if the DATA chunk has to

contain a given value in network byte order, the SCTP user has to

perform the htonl() computation.

sinfo_context: 32 bits (unsigned integer)

This value is an opaque 32 bit context datum that is used in the

sendmsg() function. This value is passed back to the upper layer if

a error occurs on the send of a message and is retrieved with each

undelivered message (Note: if a endpoint has done multiple sends, all

of which fail, multiple different sinfo_context values will be

returned. One with each user data message).

sinfo_flags: 16 bits (unsigned integer)

This field may contain any of the following flags and is composed of

a bitwise OR of these values.

recvmsg() flags:

SCTP_UNORDERED - This flag is present when the message was sent non-

ordered.

sendmsg() flags:

SCTP_UNORDERED - This flag requests the un-ordered delivery of the

message. If this flag is clear the datagram is considered an

ordered send.

SCTP_ADDR_OVER - This flag, in the one-to-many style, requests the

SCTP stack to override the primary destination address with the

address found with the sendto/sendmsg call.

SCTP_ABORT - Setting this flag causes the specified association 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.

SCTP_EOF - Setting this flag invokes the SCTP graceful shutdown

procedures on the specified association. Graceful shutdown

assures that all data enqueued by both endpoints is successfully

transmitted before closing the association (one-to-many style

only).

SCTP_SENDALL - This flag, if set, will cause a one-to-many model

socket to send the message to all associations that are currently

established on this socket. For the one-to-one socket, this flag

has no effect.

SCTP_EOR - This flag, if set, will indicate that this send

terminates the record.

sinfo_timetolive: 32 bit (unsigned integer)

For the sending side, this field contains the message time to live in

milliseconds. The sending side will expire the message within the

specified time period if the message as not been sent to the peer

within this time period. This value will override any default value

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.

sinfo_tsn: 32 bit (unsigned integer)

For the receiving side, this field holds a TSN that was assigned to

one of the SCTP Data Chunks.

sinfo_cumtsn: 32 bit (unsigned integer)

This field will hold the current cumulative TSN as known by the

underlying SCTP layer. Note this field is ignored when sending and

only valid for a receive operation when sinfo_flags are set to

SCTP_UNORDERED.

sinfo_assoc_id: sizeof (sctp_assoc_t)

The association handle field, sinfo_assoc_id, holds the identifier

for the association announced in the SCTP_COMM_UP notification. All

notifications for a given association have the same identifier.

Ignored for one-to-one style sockets.

A sctp_sndrcvinfo item always corresponds to the data in msg_iov.

Please see Section 5.2.2 for the details for this structure.

next_flags: 16 bit (unsigned integer)

serinfo_next_flags: 16 bit (unsigned integer)

This bitmask will hold one or more of the following values:

This bitmask will hold one or more of the following values:

SCTP_NEXT_MSG_AVAIL - This bit, when set to 1, indicates that next

SCTP_NEXT_MSG_AVAIL - This bit, when set to 1, indicates that next

message information is available i.e.: next_stream, next_asocid,

message information is available i.e.: next_stream, next_asocid,

next_length and next_ppid fields all have valid values. If this

next_length and next_ppid fields all have valid values. If this

bit is set to 0, then these fields are not valid and should be

bit is set to 0, then these fields are not valid and should be

ignored.

ignored.

SCTP_NEXT_MSG_ISCOMPLETE - This bit, when set, indicates that the

SCTP_NEXT_MSG_ISCOMPLETE - This bit, when set, indicates that the

next message is completely in the receive buffer. The next_length

next message is completely in the receive buffer. The next_length

field thus contains the entire message size. If this flag is set

field thus contains the entire message size. If this flag is set

to 0, then the next_length field only contains part of the message

to 0, then the next_length field only contains part of the message

skipping to change at page 30, line 29

skipping to change at page 28, line 22

next message is completely in the receive buffer. The next_length

next message is completely in the receive buffer. The next_length

field thus contains the entire message size. If this flag is set

field thus contains the entire message size. If this flag is set

to 0, then the next_length field only contains part of the message

to 0, then the next_length field only contains part of the message

size since the message is still being received (it is being

size since the message is still being received (it is being

partially delivered).

partially delivered).

SCTP_NEXT_MSG_IS_UNORDERED - This bit, when set, indicates that the

SCTP_NEXT_MSG_IS_UNORDERED - This bit, when set, indicates that the

next message to be received was sent by the peer as unordered. If

next message to be received was sent by the peer as unordered. If

this bit is not set (i.e the bit is 0) the next message to be read

this bit is not set (i.e the bit is 0) the next message to be read

is an ordered message in the stream specified.

is an ordered message in the stream specified.

SCTP_NEXT_MSG_IS_NOTIFICATION - This bit, when set, indicates that

the next message to be received is not a message from the peer,

but instead is a MSG_NOTIFICATION from the local SCTP stack.

next_stream: 16 bit (unsigned integer)

serinfo_next_stream: 16 bit (unsigned integer)

This value, when valid (see next_flags), contains the next stream

This value, when valid (see sreinfo_next_flags), contains the next

number that will be received on a subsequent call to one of the

stream number that will be received on a subsequent call to one of

receive message functions.

the receive message functions.

next_asocid: 32 bit (unsigned integer)

serinfo_next_aid: 32 bit (unsigned integer)

This value, when valid (see next_flags), contains the next

This value, when valid (see next_flags), contains the next

association identification that will be received on a subsequent call

association identification that will be received on a subsequent call

to one of the receive message functions.

to one of the receive message functions.

next_length: 32 bit (unsigned integer)

sreinfo_next_length: 32 bit (unsigned integer)

This value, when valid (see next_flags), contains the length of the

This value, when valid (see sreinfo_next_flags), contains the length

next message that will be received on a subsequent call to one of the

of the next message that will be received on a subsequent call to one

receive message functions. Note that this length may be a partial

of the receive message functions. Note that this length may be a

length depending on the settings of next_flags.

partial length depending on the settings of next_flags.

next_ppid: 32 bit (unsigned integer)

sreinfo_next_ppid: 32 bit (unsigned integer)

This value, when valid (see next_flags), contains the ppid of the

This value, when valid (see sreinfo_next_flags), contains the ppid of

next message that will be received on a subsequent call to one of the

the next message that will be received on a subsequent call to one of

receive message functions.

the receive message functions.

5.3. SCTP Events and Notifications

5.3. SCTP Events and Notifications

An SCTP application may need to understand and process events and

An SCTP application may need to understand and process events and

errors that happen on the SCTP stack. These events include network

errors that happen on the SCTP stack. These events include network

status changes, association startups, remote operational errors and

status changes, association startups, remote operational errors and

undeliverable messages. All of these can be essential for the

undeliverable messages. All of these can be essential for the

application.

application.

When an SCTP application layer does a recvmsg() the message read is

When an SCTP application layer does a recvmsg() the message read is

skipping to change at page 40, line 29

skipping to change at page 38, line 10

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

notification will be used to indicate various events.

notification will be used to indicate various events.

struct sctp_pdapi_event {

struct sctp_pdapi_event {

uint16_t pdapi_type;

uint16_t pdapi_type;

uint16_t pdapi_flags;

uint16_t pdapi_flags;

uint32_t pdapi_length;

uint32_t pdapi_length;

uint32_t pdapi_indication;

uint32_t pdapi_indication;

uint32_t pdapi_stream;

uint32_t pdapi_seq;

sctp_assoc_t pdapi_assoc_id;

sctp_assoc_t pdapi_assoc_id;

};

};

pdapi_type

pdapi_type

It should be SCTP_PARTIAL_DELIVERY_EVENT

It should be SCTP_PARTIAL_DELIVERY_EVENT

pdapi_flags: 16 bits (unsigned integer)

pdapi_flags: 16 bits (unsigned integer)

Currently unused.

Currently unused.

skipping to change at page 41, line 4

skipping to change at page 38, line 35

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_pdapi_event).

sctp_pdapi_event).

pdapi_indication: 32 bits (unsigned integer)

pdapi_indication: 32 bits (unsigned integer)

This field holds the indication being sent to the application

This field holds the indication being sent to the application

possible values include:

possible values include:

SCTP_PARTIAL_DELIVERY_ABORTED

SCTP_PARTIAL_DELIVERY_ABORTED

pdapi_stream: 16 bits (unsigned integer)

This field holds the stream on which the partial delivery event

happened.

pdapi_seq: 16 bits (unsigned integer)

This field holds the stream sequence number which was being partially

delivered.

pdapi_assoc_id: sizeof (sctp_assoc_t)

pdapi_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.8. SCTP_AUTHENTICATION_EVENT

5.3.1.8. SCTP_AUTHENTICATION_EVENT

When a receiver is using authentication this message will provide

When a receiver is using authentication this message will provide

notifications regarding new keys being made active as well as errors.

notifications regarding new keys being made active as well as errors.

skipping to change at page 49, line 34

skipping to change at page 47, line 34

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 [RFC2960] for more information on how this parameter is

See RFC2960 [RFC2960] for more information on how this parameter is

used. The peer address parameter is ignored for one-to-one style

used. The sasoc_assoc_id parameter is ignored for one-to-one style

socket.

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;

uint32_t sasoc_sack_delay;

uint32_t sasoc_sack_freq;

};

};

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 rwnd

sasoc_peer_rwnd - This holds the current value of the peers rwnd

(reported in the last SACK) minus any outstanding data (i.e. data

(reported in the last SACK) minus any outstanding data (i.e. data

inflight).

inflight).

sasoc_local_rwnd - This holds the last reported rwnd that was sent

sasoc_local_rwnd - This holds the last reported rwnd that was sent

to the peer.

to the peer.

sasoc_cookie_life - This is the associations cookie life value used

sasoc_cookie_life - This is the associations cookie life value used

when issuing cookies.

when issuing cookies.

sasoc_assoc_id - This is filled in the application, and identifies

sasoc_assoc_id - This is filled in the application, and identifies

skipping to change at page 50, line 16

skipping to change at page 48, line 17

addresses that the peer has.

addresses that the peer has.

sasoc_peer_rwnd - This holds the current value of the peers rwnd

sasoc_peer_rwnd - This holds the current value of the peers rwnd

(reported in the last SACK) minus any outstanding data (i.e. data

(reported in the last SACK) minus any outstanding data (i.e. data

inflight).

inflight).

sasoc_local_rwnd - This holds the last reported rwnd that was sent

sasoc_local_rwnd - This holds the last reported rwnd that was sent

to the peer.

to the peer.

sasoc_cookie_life - This is the associations cookie life value used

sasoc_cookie_life - This is the associations cookie life value used

when issuing cookies.

when issuing cookies.

sasoc_assoc_id - This is filled in the application, and identifies

sasoc_assoc_id - This is filled in the application, and identifies

the association for this query.

the association for this query.

sasoc_sack_delay - This field holds the delayed sack timer value in

milliseconds. If the value is 0, then the delayed sack algorithm

is disabled.

sasoc_sack_freq - This field holds the number of packets that must

be received before a sack is transmitted when delayed sack is

enabled.

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 54, line 20

skipping to change at page 52, line 21

number of retransmissions sent before an address is considered

number of retransmissions sent before an address is considered

unreachable. The following structure is used to access and modify an

unreachable. The following structure is used to access and modify an

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_flags;

uint32_t spp_flags;

uint32_t spp_ipv6_flowlabel;

uint32_t spp_ipv6_flowlabel;

uint8_t spp_ipv4_tos;

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 this query.

application, and identifies the association for 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. Note that unless the spp_flag is set to

in milliseconds. Note that unless the spp_flag is set to

skipping to change at page 54, line 47

skipping to change at page 52, line 47

unless the spp_flag is set to SPP_PMTUD_ENABLE the value of this

unless the spp_flag is set to SPP_PMTUD_ENABLE the value of this

field is ignored. Note also that a value of zero indicates the

field is ignored. Note also that a value of zero indicates the

current setting should be left unchanged.

current setting should be left unchanged.

spp_pathmtu - When Path MTU discovery is disabled the value

spp_pathmtu - When Path MTU discovery is disabled the value

specified here will be the "fixed" path mtu (i.e. the value of the

specified here will be the "fixed" path mtu (i.e. the value of the

spp_flags field must include the flag SPP_PMTUD_DISABLE for this

spp_flags field must include the flag SPP_PMTUD_DISABLE for this

field to have any effect). Note that if the spp_address field is

field to have any effect). Note that if the spp_address field is

empty then all associations on this address will have this fixed

empty then all associations on this address will have this fixed

path mtu set upon them. If an address is specified, then only

path mtu set upon them. If an address is specified, then only

that address will be effected.

that address will be effected.

spp_sackdelay - When delayed sack is enabled, this value specifies

the number of milliseconds that sacks will be delayed for. This

value will apply to all addresses of an association if the

spp_address field is empty. Note that unless the spp_flag is set

to SPP_SACKDELAY_ENABLE the value of this field is ignored. Note

also that a value of zero indicates the current setting should be

left unchanged.

spp_ipv6_flowlabel- This field is used in conjunction with the

spp_ipv6_flowlabel- This field is used in conjunction with the

SPP_IPV4_FLOWLABEL flag.

SPP_IPV4_FLOWLABEL flag.

spp_ipv4_tos- This field is used in conjunction with the

spp_ipv4_tos- This field is used in conjunction with the

SPP_IPV4_TOS flag.

SPP_IPV4_TOS flag.

spp_flags- These flags are used to control various features on an

spp_flags- These flags are used to control various features on an

association. The flag field is a bit mask which may contain zero

association. The flag field is a bit mask which may contain zero

or more of the following options:

or more of the following options:

SPP_HB_ENABLE - Enable heartbeats on the specified address. Note

SPP_HB_ENABLE - Enable heartbeats on the specified address. Note

that if the address field is empty all addresses for the

that if the address field is empty all addresses for the

association have heartbeats enabled upon them.

association have heartbeats enabled upon them.

SPP_HB_DISABLE - Disable heartbeats on the specified address.

SPP_HB_DISABLE - Disable heartbeats on the specified address.

Note that if the address field is empty all addresses for the

Note that if the address field is empty all addresses for the

skipping to change at page 55, line 33

skipping to change at page 53, line 31

SPP_HB_TIME_IS_ZERO - Specify's that the time for heartbeat delay

SPP_HB_TIME_IS_ZERO - Specify's that the time for heartbeat delay

is to be set to the value of 0 milliseconds.

is to be set to the value of 0 milliseconds.

SPP_PMTUD_ENABLE - This field will enable PMTU discovery upon the

SPP_PMTUD_ENABLE - This field will enable PMTU discovery upon the

specified address. Note that if the address field is empty

specified address. Note that if the address field is empty

then all addresses on the association are effected.

then all addresses on the association are effected.

SPP_PMTUD_DISABLE - This field will disable PMTU discovery upon

SPP_PMTUD_DISABLE - This field will disable PMTU discovery upon

the specified address. Note that if the address field is empty

the specified address. Note that if the address field is empty

then all addresses on the association are effected. Not also

then all addresses on the association are effected. Not also

that SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually

that SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually

exclusive. Enabling both will have undetermined results.

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

SPP_IPV6_FLOWLABEL - Setting this flag enables setting of the

IPV6 flowlabel value associated with either the association or

IPV6 flowlabel value associated with either the association or

the specific address. If the address field is filled in, then

the specific address. If the address field is filled in, then

the specific destination address has this value set upon it.

the specific destination address has this value set upon it.

If the association is specified, but not the address, then the

If the association is specified, but not the address, then the

flowlabel value is set for any future destination addresses

flowlabel value is set for any future destination addresses

that may be added. The value is obtained in the

that may be added. The value is obtained in the

spp_ipv6_flowlabel field.

spp_ipv6_flowlabel field.

Upon retrieval, this flag will be set to indicate that the

Upon retrieval, this flag will be set to indicate that the

skipping to change at page 57, line 16

skipping to change at page 55, line 4

This socket option is used to specify various notifications and

This socket option is used to specify various notifications and

ancillary data the user wishes to receive. Please see Section 7.3)

ancillary data the user wishes to receive. Please see Section 7.3)

for a full description of this option and its usage.

for a full description of this option and its usage.

7.1.16. Set/clear IPv4 mapped addresses (SCTP_I_WANT_MAPPED_V4_ADDR)

7.1.16. Set/clear IPv4 mapped addresses (SCTP_I_WANT_MAPPED_V4_ADDR)

This socket option is a boolean flag which turns on or off mapped V4

This socket option is a boolean flag which turns on or off mapped V4

addresses. If this option is turned on and the socket is type

addresses. If this option is turned on and the socket is type

PF_INET6, then IPv4 addresses will be mapped to V6 representation.

PF_INET6, then IPv4 addresses will be mapped to V6 representation.

If this option is turned off, then no mapping will be done of V4

If this option is turned off, then no mapping will be done of V4

addresses and a user will receive both PF_INET6 and PF_INET type

addresses and a user will receive both PF_INET6 and PF_INET type

addresses on the socket.

addresses on the socket.

By default this option is turned on and expects an integer to be

By default this option is turned on and expects an integer to be

passed where non-zero turns on the option and zero turns off the

passed where non-zero turns on the option and zero turns off the

option.

option.

7.1.17. Set the maximum fragmentation size (SCTP_MAXSEG)

7.1.17. Get or set the maximum fragmentation size (SCTP_MAXSEG)

This socket option specifies the maximum size to put in any outgoing

This options will get or set the maximum size to put in any outgoing

SCTP DATA chunk. If a message is larger than this size it will be

SCTP DATA chunk. If a message is larger than this size it will be

fragmented by SCTP into the specified size. Note that the underlying

fragmented by SCTP into the specified size. Note that the underlying

SCTP implementation may fragment into smaller sized chunks when the

SCTP implementation may fragment into smaller sized chunks when the

PMTU of the underlying association is smaller than the value set by

PMTU of the underlying association is smaller than the value set by

the user. The option expects an integer.

the user. The default value for this option is '0' which indicates

the user is NOT limiting fragmentation and only the PMTU will effect

SCTP's choice of DATA chunk size.

The default value for this option is '0' which indicates the user is

struct sctp_assoc_value {

NOT limiting fragmentation and only the PMTU will effect SCTP's

sctp_assoc_t assoc_id;

choice of DATA chunk size.

uint32_t assoc_value;

};

assoc_id - This parameter, indicates which association the user is

performing an action upon. Note that if this field's value is

zero then the endpoints default value is changed (effecting future

associations only).

assoc_value - This parameter specifies the maximum size in bytes.

7.1.18. Add a chunk that must be authenticated (SCTP_AUTH_CHUNK)

7.1.18. Add a chunk that must be authenticated (SCTP_AUTH_CHUNK)

This option adds a chunk type that the user is requesting to be

This option adds a chunk type that the user is requesting to be

received only in an authenticated way. Changes to the list of chunks

received only in an authenticated way. Changes to the list of chunks

will only effect future associations on the socket.

will only effect future associations on the socket.

struct sctp_authchunk {

struct sctp_authchunk {

uint8_t sauth_chunk;

uint8_t sauth_chunk;

};

};

skipping to change at page 60, line 37

skipping to change at page 58, line 37

performing an action upon. Note that if this field's value is

performing an action upon. Note that if this field's value is

zero then the endpoints default value is changed (effecting future

zero then the endpoints default value is changed (effecting future

associations only).

associations only).

assoc_value - This parameter contains the number of milliseconds

assoc_value - This parameter contains the number of milliseconds

that the user is requesting the delayed ACK timer be set to. Note

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

that this value is defined in the standard to be between 200 and

500 milliseconds.

500 milliseconds.

7.1.24. Get or set fragmented interleave (SCTP_FRAGMENT_INTERLEAVE)

7.1.24. Get or set fragmented interleave (SCTP_FRAGMENT_INTERLEAVE)

This options will at a minimum specify if the implementation is doing

Fragmented interleave controls how the presentation of messages

fragmented interleave. Fragmented interleave, for a one to many

occurs for the message receiver. There are three levels of fragment

socket, is when subsequent calls to receive a message may return

interleave defined. Two of the levels effect the one-to-one model,

parts of messages from different associations. Some implementations

while the one-to-many model is effected by all three levels.

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

This option takes an integer value. It can be set to a value of 0, 1

fragmented interleave is on. A value of zero indicates that

or 2. Attempting to set this level to other values will return an

fragmented interleave is off.

error.

Note that it is important that an implementation that allows this

Setting the three levels provides the following receiver

option to be turned on, have it off by default. Otherwise an unaware

interactions:

application using the one to many model may become confused and act

incorrectly.

level 0 - Prevents the interleaving of any messages. This means

that when a partial delivery begins, no other messages will be

received except the message being partially delivered. If another

message arrives on a different stream (or association) that could

be delivered, it will be blocked waiting for the user to read all

of the partially delivered message.

level 1 - Allows interleaving of messages that are of differing

association identifications. For the one-to-one model, level 0

and level 1 thus have the same meaning since a one-to-one socket

always receives messages from the same association. Note that

setting the one-to-many model to this level may cause multiple

partial delivers from different associations but for any given

association, only one message will be delivered until all parts of

a message have been delivered. This means that one large message,

being read with an association identification of "X", will block

other messages from association "X" from being delivered.

level 2 - Allows complete interleaving of messages. This level

requires that the sender carefully observe not only the peer

association identification (or address) but also must pay careful

attention to the stream number. With this option enabled a

partially delivered message may begin being delivered for

association "X" stream "Y" and the next subsequent receive may

return a message from association "X" stream "Z". Note that no

other messages would be delivered for association "X" stream "Y"

until all of stream "Y"'s partially delivered message was read.

Note that this option also effects the one-to-one model. Also

note that for the one-to-many model not only may another streams

message from the same association be delivered from the next

receive, some other associations message may be delivered upon the

next receive.

An implementation should default the one-to-many model to level 1.

The reason for this is that otherwise it is possible that a peer

could begin sending a partial message and thus block all other peers

from sending data. However a setting of level 2 requires the

application to not only be aware of the association (via the

association id or peers address) but also the stream number. The

stream number is NOT present unless the user has subscribed to the

sctp_data_io_events (see Section 7.3). This is also why we recommend

that the one-to-one model be defaulted to level 0 (level 1 for the

one-to-one model has no effect). Note that an implementation should

return an error if a application attempts to set the level to 2 and

has NOT subscribed to the sctp_data_io_events.

7.1.25. Set or Get the sctp partial delivery point

7.1.25. Set or Get the sctp partial delivery point

(SCTP_PARTIAL_DELIVERY_POINT)

(SCTP_PARTIAL_DELIVERY_POINT)

This option will set or get the SCTP partial delivery point. This

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

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

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

lower value will cause partial deliveries to happen more often. The

calls argument is an integer that sets or gets the partial delivery

calls argument is an integer that sets or gets the partial delivery

point.

point. Note also that the call will fail if the user attempts to set

this value larger than the socket receive buffer size.

Note that any single message smaller than the SCTP partial delivery

will be delivered in one single read return call as long as the user

provided buffer is large enough to hold the message.

7.1.26. Set or Get the use of extended receive info

7.1.26. Set or Get the use of extended receive info

(SCTP_USE_EXT_RCVINFO)

(SCTP_USE_EXT_RCVINFO)

This option will enable or disable the use of the extended version of

This option will enable or disable the use of the extended version of

the sctp_sndrcvinfo structure. If this option is disabled, then the

the sctp_sndrcvinfo structure. If this option is disabled, then the

normal sctp_sndrcvinfo structure is returned in all receive message

normal sctp_sndrcvinfo structure is returned in all receive message

calls. If this option is enabled then the sctp_extrcvinfo structure

calls. If this option is enabled then the sctp_extrcvinfo structure

is returned in all receive message calls.

is returned in all receive message calls.

skipping to change at page 87, line 7

skipping to change at page 86, line 7

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: [email-masked]

Email: [email-masked]

Full Copyright Statement

Full Copyright Statement

Copyright (C) The IETF Trust (2006).

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions

This document is subject to the rights, licenses and restrictions

contained in BCP 78, and except as set forth therein, the authors

contained in BCP 78, and except as set forth therein, the authors

retain all their rights.

retain all their rights.

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, THE IETF TRUST AND

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

End of changes.

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

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 21 Apr 2007 15:05:19 +0200

Hi Randy,

I just changed the text for the SCTP_PARTIAL_DELIVERY_POINT from]

to

    Note that any single message having a length smaller than or  
equal to
    the SCTP partial delivery point will be delivered in one single read
    call as long as the user provided buffer is large enough to hold the
    message.

Just a change of wording...

Best regards
Michael

On Apr 21, 2007, at 1:47 PM, Randall Stewart wrote:

>  draft-ietf-tsvwg-sctpsocket-14.txt   draft-ietf-tsvwg- 
> sctpsocket-15.txt
> Network Working Group R. Stewart Network Working Group R. Stewart
> Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
> Expires: June 14, 2007 Q. Xie Expires: October 23, 2007 Q. Xie
> Motorola, Inc. Motorola, Inc.
> L. Yarroll L. Yarroll
> TimeSys Corp TimeSys Corp
> K. Poon K. Poon
> Sun Microsystems, Inc. Sun Microsystems, Inc.
> M. Tuexen M. Tuexen
> Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
> December 11, 2006 April 21, 2007
> Sockets API Extensions for Stream Control Transmission Protocol  
> (SCTP) Sockets API Extensions for Stream Control Transmission  
> Protocol (SCTP)
> draft-ietf-tsvwg-sctpsocket-14.txt draft-ietf-tsvwg-sctpsocket-15.txt
> Status of this Memo Status of this Memo
> skipping to change at page 1, line 41 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.
> http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
> This Internet-Draft will expire on June 14, 2007. This Internet- 
> Draft will expire on October 23, 2007.
> Copyright Notice Copyright Notice
> Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust  
> (2007).
> Abstract Abstract
> This document describes a mapping of the Stream Control  
> Transmission This document describes a mapping of the Stream  
> Control Transmission
> Table of Contents Table of Contents
> skipping to change at page 2, line 42 skipping to change at page 2,  
> line 42
> 5.2.3. Extended SCTP Header Information Structure 5.2.3. Extended  
> SCTP Header Information Structure
> 7. Socket Options . . . . . . . . . . . . . . . . . . . . . . . .  
> 47 7. Socket  
> Options . . . . . . . . . . . . . . . . . . . . . . . . 45
> 7.1.9. Set Peer Primary Address 7.1.9. Set Peer Primary Address
> 7.1.11. Set Adaptation Layer Indicator 7.1.11. Set Adaptation Layer  
> Indicator
> 7.1.12. Enable/Disable message fragmentation 7.1.12. Enable/Disable  
> message fragmentation
> 7.1.14. Set default send parameters 7.1.14. Set default send  
> parameters
> 7.1.16. Set/clear IPv4 mapped addresses 7.1.16. Set/clear IPv4  
> mapped addresses
> 7.1.18. Add a chunk that must be authenticated 7.1.18. Add a chunk  
> that must be authenticated
> 7.1.19. Get or set the list of supported HMAC Identifiers 7.1.19.  
> Get or set the list of supported HMAC Identifiers
> 7.1.21. Get or set the active shared key 7.1.21. Get or set the  
> active shared key
> 7.1.23. Get or set delayed ack timer 7.1.23. Get or set delayed ack  
> timer
> 7.1.24. Get or set fragmented interleave 7.1.24. Get or set  
> fragmented interleave
> 7.1.25. Set or Get the sctp partial delivery point 7.1.25. Set or  
> Get the sctp partial delivery point
> 7.1.26. Set or Get the use of extended receive info 7.1.26. Set or  
> Get the use of extended receive info
> 7.1.30. Enable or disable explicit EOR marking 7.1.30. Enable or  
> disable explicit EOR marking
> 7.2.3. Get the list of chunks the peer requires to be 7.2.3. Get  
> the list of chunks the peer requires to be
> 7.2.4. Get the list of chunks the local endpoint requires 7.2.4.  
> Get the list of chunks the local endpoint requires
> to be authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . . 65 to be  
> authenticated (SCTP_LOCAL_AUTH_CHUNKS) . . . . . 64
> 7.2.5. Get the list of current associations 7.2.5. Get the list of  
> current associations
> 8. New Interfaces . . . . . . . . . . . . . . . . . . . . . . . .  
> 68 8. New  
> Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 67
> 9. Preprocessor Constants . . . . . . . . . . . . . . . . . . . .  
> 76 9. Preprocessor  
> Constants . . . . . . . . . . . . . . . . . . . . 75
> 10. IANA considerations . . . . . . . . . . . . . . . . . . . . .  
> 77 10. IANA  
> considerations . . . . . . . . . . . . . . . . . . . . . 76
> 11. Security Considerations . . . . . . . . . . . . . . . . . . .  
> 77 11. Security  
> Considerations . . . . . . . . . . . . . . . . . . . 76
> 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  
> 77 12.  
> Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
> 13. Normative references . . . . . . . . . . . . . . . . . . . . .  
> 78 13. Normative  
> references . . . . . . . . . . . . . . . . . . . . . 77
> Appendix A. one-to-one style Code Example . . . . . . . . . . . .  
> 78 Appendix A. one-to-one style Code  
> Example . . . . . . . . . . . . 77
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  
> 85 Authors'  
> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
> Intellectual Property and Copyright Statements . . . . . . . . . .  
> 87 Intellectual Property and Copyright  
> Statements . . . . . . . . . . 86
> 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
> and UDP RFC768 [RFC0768] have benefited from this standard and UDP  
> RFC768 [RFC0768] have benefited from this standard
> representation and access method across many diverse platforms.  
> SCTP representation and access method across many diverse  
> platforms. SCTP
> but also incorporates semantics more akin to UDP. This document but  
> also incorporates semantics more akin to UDP. This document
> skipping to change at page 11, line 11 skipping to change at page  
> 11, line 11
> If the application does not provide enough buffer space to  
> completely If the application does not provide enough buffer space  
> to completely
> 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
> one message at a time per stream can be partially delivered. one  
> message at a time can be partially delivered in any stream. The
> 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
> 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
> in Section 10.1 of RFC2960 [RFC2960]) on ALL the associations in  
> Section 10.1 of RFC2960 [RFC2960]) on ALL the associations
> currently represented by a one-to-many style socket. currently  
> represented by a one-to-many style socket.
> skipping to change at page 27, line 21 skipping to change at page  
> 27, line 21
> Ignored for one-to-one style sockets. Ignored for one-to-one style  
> sockets.
> A sctp_sndrcvinfo item always corresponds to the data in msg_iov. A  
> sctp_sndrcvinfo item always corresponds to the data in msg_iov.
> This cmsghdr structure specifies SCTP options for SCTP header This  
> cmsghdr structure specifies SCTP options for SCTP header
> ancillary data.. needed to receive ancillary data. Note that next  
> message data is not
> cmsg_level cmsg_type cmsg_data[] cmsg_level cmsg_type cmsg_data[]
> ------------ ------------ ---------------------- ------------  
> ------------ ----------------------
> IPPROTO_SCTP SCTP_SNDRCV struct sctp_sndrcvinfo IPPROTO_SCTP  
> SCTP_EXTRCV struct sctp_extrcvinfo
> Here is the definition of sctp_sndrcvinfo: Here is the definition  
> of sctp_extrcvinfo
> struct sctp_extrcvinfo { struct sctp_extrcvinfo {
> uint16_t sinfo_stream; struct sctp_sndrcvinfo serinfo_sinfo;
> uint16_t sinfo_ssn; uint16_t serinfo_next_flags;
> uint16_t sinfo_flags; uint16_t serinfo_next_stream;
> uint32_t sinfo_ppid; uint32_t serinfo_next_aid;
> uint32_t sinfo_context; uint32_t serinfo_next_length;
> uint32_t sinfo_timetolive; uint32_t serinfo_next_ppid;
> uint32_t sinfo_tsn;
> uint32_t sinfo_cumtsn;
> }; };
> sinfo_stream: 16 bits (unsigned integer) serinfo_sinfo: structure
> next_flags: 16 bit (unsigned integer) serinfo_next_flags: 16 bit  
> (unsigned integer)
> This bitmask will hold one or more of the following values: This  
> bitmask will hold one or more of the following values:
> bit is set to 0, then these fields are not valid and should be bit  
> is set to 0, then these fields are not valid and should be
> ignored. ignored.
> skipping to change at page 30, line 29 skipping to change at page  
> 28, line 22
> size since the message is still being received (it is being size  
> since the message is still being received (it is being
> partially delivered). partially delivered).
> is an ordered message in the stream specified. is an ordered  
> message in the stream specified.
> next_stream: 16 bit (unsigned integer) serinfo_next_stream: 16 bit  
> (unsigned integer)
> receive message functions. the receive message functions.
> next_asocid: 32 bit (unsigned integer) serinfo_next_aid: 32 bit  
> (unsigned integer)
> This value, when valid (see next_flags), contains the next This  
> value, when valid (see next_flags), contains the next
> association identification that will be received on a subsequent  
> call association identification that will be received on a  
> subsequent call
> to one of the receive message functions. to one of the receive  
> message functions.
> next_length: 32 bit (unsigned integer) sreinfo_next_length: 32 bit  
> (unsigned integer)
> next message that will be received on a subsequent call to one of  
> the of the next message that will be received on a subsequent call  
> to one
> length depending on the settings of next_flags. partial length  
> depending on the settings of next_flags.
> next_ppid: 32 bit (unsigned integer) sreinfo_next_ppid: 32 bit  
> (unsigned integer)
> next message that will be received on a subsequent call to one of  
> the the next message that will be received on a subsequent call to  
> one of
> receive message functions. the receive message functions.
> 5.3. SCTP Events and Notifications 5.3. SCTP Events and Notifications
> application. application.
> skipping to change at page 40, line 29 skipping to change at page  
> 38, line 10
> 5.3.1.7. SCTP_PARTIAL_DELIVERY_EVENT 5.3.1.7.  
> SCTP_PARTIAL_DELIVERY_EVENT
> notification will be used to indicate various events. notification  
> will be used to indicate various events.
> struct sctp_pdapi_event { struct sctp_pdapi_event {
> uint16_t pdapi_type; uint16_t pdapi_type;
> uint16_t pdapi_flags; uint16_t pdapi_flags;
> uint32_t pdapi_length; uint32_t pdapi_length;
> uint32_t pdapi_indication; uint32_t pdapi_indication;
> uint32_t pdapi_stream;
> uint32_t pdapi_seq;
> sctp_assoc_t pdapi_assoc_id; sctp_assoc_t pdapi_assoc_id;
> }; };
> pdapi_type pdapi_type
> It should be SCTP_PARTIAL_DELIVERY_EVENT It should be  
> SCTP_PARTIAL_DELIVERY_EVENT
> pdapi_flags: 16 bits (unsigned integer) pdapi_flags: 16 bits  
> (unsigned integer)
> Currently unused. Currently unused.
> skipping to change at page 41, line 4 skipping to change at page  
> 38, line 35
> the notification header. It will generally be sizeof (struct the  
> notification header. It will generally be sizeof (struct
> sctp_pdapi_event). sctp_pdapi_event).
> pdapi_indication: 32 bits (unsigned integer) pdapi_indication: 32  
> bits (unsigned integer)
> This field holds the indication being sent to the application This  
> field holds the indication being sent to the application
> possible values include: possible values include:
> SCTP_PARTIAL_DELIVERY_ABORTED SCTP_PARTIAL_DELIVERY_ABORTED
> pdapi_assoc_id: sizeof (sctp_assoc_t) pdapi_assoc_id: sizeof  
> (sctp_assoc_t)
> 5.3.1.8. SCTP_AUTHENTICATION_EVENT 5.3.1.8. SCTP_AUTHENTICATION_EVENT
> notifications regarding new keys being made active as well as  
> errors. notifications regarding new keys being made active as well  
> as errors.
> skipping to change at page 49, line 34 skipping to change at page  
> 47, line 34
> SCTP_RTOINFO. SCTP_RTOINFO.
> 7.1.2. Association Parameters (SCTP_ASSOCINFO) 7.1.2. Association  
> Parameters (SCTP_ASSOCINFO)
> endpoint parameters. endpoint parameters.
> socket. 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;
> }; };
> 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.
> addresses that the peer has. addresses that the peer has.
> inflight). inflight).
> to the peer. to the peer.
> when issuing cookies. when issuing cookies.
> skipping to change at page 50, line 16 skipping to change at page  
> 48, line 17
> addresses that the peer has. addresses that the peer has.
> inflight). inflight).
> to the peer. to the peer.
> when issuing cookies. when issuing cookies.
> the association 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
> 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.
> 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 54, line 20 skipping to change at page  
> 52, line 21
> unreachable. The following structure is used to access and modify  
> an unreachable. The following structure is used to access and  
> modify an
> 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_flags; uint32_t spp_flags;
> uint32_t spp_ipv6_flowlabel; uint32_t spp_ipv6_flowlabel;
> uint8_t spp_ipv4_tos; uint8_t spp_ipv4_tos;
> }; };
> in milliseconds. Note that unless the spp_flag is set to in  
> milliseconds. Note that unless the spp_flag is set to
> skipping to change at page 54, line 47 skipping to change at page  
> 52, line 47
> current setting should be left unchanged. current setting should be  
> left unchanged.
> path mtu set upon them. If an address is specified, then only path  
> mtu set upon them. If an address is specified, then only
> that address will be effected. that address will be effected.
> SPP_IPV4_FLOWLABEL flag. SPP_IPV4_FLOWLABEL flag.
> SPP_IPV4_TOS flag. SPP_IPV4_TOS flag.
> or more of the following options: or more of the following options:
> that if the address field is empty all addresses for the that if  
> the address field is empty all addresses for the
> association have heartbeats enabled upon them. association have  
> heartbeats enabled upon them.
> Note that if the address field is empty all addresses for the Note  
> skipping to change at page 55, line 33 skipping to change at page  
> 53, line 31
> is to be set to the value of 0 milliseconds. is to be set to the  
> value of 0 milliseconds.
> then all addresses on the association are effected. then all  
> addresses on the association are effected.
> the specified address. Note that if the address field is empty the  
> then all addresses on the association are effected. Not also then  
> all addresses on the association are effected. Not also
> that SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually that  
> SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE are mutually
> exclusive. Enabling both will have undetermined results. exclusive.  
> Enabling both will have undetermined results.
> IPV6 flowlabel value associated with either the association or IPV6  
> flowlabel value associated with either the association or
> the specific address. If the address field is filled in, then the  
> specific address. If the address field is filled in, then
> the specific destination address has this value set upon it. the  
> specific destination address has this value set upon it.
> If the association is specified, but not the address, then the If  
> the association is specified, but not the address, then the
> that may be added. The value is obtained in the that may be added.  
> The value is obtained in the
> spp_ipv6_flowlabel field. spp_ipv6_flowlabel field.
> Upon retrieval, this flag will be set to indicate that the Upon  
> retrieval, this flag will be set to indicate that the
> skipping to change at page 57, line 16 skipping to change at page  
> 55, line 4
> for a full description of this option and its usage. for a full  
> description of this option and its usage.
> (SCTP_I_WANT_MAPPED_V4_ADDR) 7.1.16. Set/clear IPv4 mapped  
> addresses (SCTP_I_WANT_MAPPED_V4_ADDR)
> This socket option is a boolean flag which turns on or off mapped  
> V4 This socket option is a boolean flag which turns on or off  
> mapped V4
> If this option is turned off, then no mapping will be done of V4 If  
> this option is turned off, then no mapping will be done of V4
> addresses on the socket. addresses on the socket.
> By default this option is turned on and expects an integer to be By  
> default this option is turned on and expects an integer to be
> option. option.
> 7.1.17. Set the maximum fragmentation size (SCTP_MAXSEG) 7.1.17.  
> Get or set the maximum fragmentation size (SCTP_MAXSEG)
> This socket option specifies the maximum size to put in any  
> outgoing This options will get or set the maximum size to put in  
> any outgoing
> fragmented by SCTP into the specified size. Note that the  
> underlying fragmented by SCTP into the specified size. Note that  
> the underlying
> the user. The option expects an integer. the user. The default  
> value for this option is '0' which indicates
> The default value for this option is '0' which indicates the user  
> is struct sctp_assoc_value {
> choice of DATA chunk size. uint32_t assoc_value;
> };
> received only in an authenticated way. Changes to the list of  
> chunks received only in an authenticated way.  Changes to the list  
> of chunks
> will only effect future associations on the socket. will only  
> effect future associations on the socket.
> struct sctp_authchunk { struct sctp_authchunk {
> uint8_t sauth_chunk; uint8_t sauth_chunk;
> }; };
> skipping to change at page 60, line 37 skipping to change at page  
> 58, line 37
> associations only). associations only).
> 500 milliseconds. 500 milliseconds.
> This options will at a minimum specify if the implementation is  
> doing Fragmented interleave controls how the presentation of messages
> fragmented interleave is on. A value of zero indicates that or 2.  
> Attempting to set this level to other values will return an
> fragmented interleave is off. error.
> option to be turned on, have it off by default. Otherwise an  
> unaware interactions:
> incorrectly. level 0 - Prevents the interleaving of any messages.  
> This means
> 7.1.25. Set or Get the sctp partial delivery point 7.1.25. Set or  
> Get the sctp partial delivery point
> (SCTP_PARTIAL_DELIVERY_POINT) (SCTP_PARTIAL_DELIVERY_POINT)
> point is the size of a message where the partial delivery API will  
> be point is the size of a message where the partial delivery API  
> will be
> point. point. Note also that the call will fail if the user  
> attempts to set
> 7.1.26. Set or Get the use of extended receive info 7.1.26. Set or  
> Get the use of extended receive info
> (SCTP_USE_EXT_RCVINFO) (SCTP_USE_EXT_RCVINFO)
> This option will enable or disable the use of the extended version  
> of This option will enable or disable the use of the extended  
> version of
> is returned in all receive message calls. is returned in all  
> receive message calls.
> skipping to change at page 87, line 7 skipping to change at page  
> 86, line 7
> 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: [email-masked] Email: [email-masked]
> Full Copyright Statement Full Copyright Statement
> Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust  
> (2007).
> retain all their rights. retain all their rights.
> 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, THE IETF TRUST  
> AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF  
> TRUST AND
> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,  
> EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL  
> WARRANTIES, EXPRESS
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE  
> OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE  
> USE OF
>  End of changes.
>

---

From: Anders Torger <[email-masked]>
Date: Sat, 21 Apr 2007 17:15:34 +0200

Randall,

I don't agree with the d)-restriction. The only case when I find 
SCTP_EXTRCV really useful is actually when *in* partial delivery, and 
thus do not have the MSG_EOR flag set.

If I'm about to read a new message into a buffer, I generally don't need 
to know which association/stream/order(on|off) it belongs to. My 
receive buffer is just a generic message buffer, and after reading it I 
put the association/stream/order(on|off) 'stamp' on it, and pass it 
along to the upper layers. I guess one can come up with a case where it 
indeed is useful, say if one would have static buffers one per 
associotian/stream/order(on|off) or something so one needs to know into 
which buffer the message should be put in advance.

This is what happens when in partial delivery -- I think it is a very 
common case that the application wants to put an SCTP message in 
contiguous memory. When continuing on the message, I would want to 
point out the proper offset into my receive buffer with the half-read 
message to recvmsg(), such that recvmsg() will put the rest of the 
message there without having to copy memory around. If I have 
SCTP_FRAGMENT_INTERLEAVE on 2 (the new option), which I would because I 
don't like head-of-line blocking, the next data I get may belong to 
another stream, and I would have to move the data to the appropriate 
buffer. If SCTP_EXTRCV provides next info for all reads, I could 
minimize these wrong guesses and thus improve performance.

Even with the MSG_EOR restriction, I guess that if unordered data is 
received by the stack before I do the next recvmsg() call, I could get 
that unordered data instead of what SCTP_EXTRCV said I would. As long 
as the programmer knows that it is not an absolute guarantee, but 
something to improve the guess of which buffer that should be provided 
to recvmsg(), I think it is ok.

/Anders Torger

---

From: Randall Stewart <[email-masked]>
Date: Sat, 21 Apr 2007 13:23:40 -0400

Michael:

Wasn't there also a change to SCTP_MAXSEG to take
an assoc/value pair?

R

Michael Tuexen wrote:
>    Note that any single message having a length smaller than or equal to

---

From: Randall Stewart <[email-masked]>
Date: Sat, 21 Apr 2007 13:31:33 -0400

> thus do not have the MSG_EOR flag set.

It was added at the suggestion of Preethi Natarajan at U-D.. I believe
she was doing web over SCTP.. and she wanted to know where the
next read msg was coming from to sync her rendering engine ..

And I don't believe the msg unit she sent was ever in PD-API at all.

> along to the upper layers.

Which means you would never need the extended rcv-info structure .. at
least not for what it was intended.. aka a pre-look at what is coming.

  I guess one can come up with a case where it
> which buffer the message should be put in advance.

Preethi? How are you using this with your web work?

> message there without having to copy memory around. 

So then why would you be:

a) either setting the PD-API point down to a low value so you
    get partially delivered messages.
<or>
b) Not supplying a big enough buffer to read into..

Since if you don't change the PD-API point unless you are
dealing with msg's that are well over 1/2 your socket read
buffer size, you won't get PD-API msgs.. and if you are reading
contiguous msgs' why would you not supply a whole msg buffer to
read into?

If I have
> minimize these wrong guesses and thus improve performance.

Hmm I see your point.. but it seems to me you would rarely
get partial delivery points anyway.. :-D

> to recvmsg(), I think it is ok.

ok

R

---

From: Mark Butler <[email-masked]>
Date: Sat, 21 Apr 2007 14:48:21 -0600

>    call as long as the user provided buffer is large enough to hold the

I do not recall the discussion on this point, but I don't think this is 
a promise that can be kept in all cases.  Atomic read semantics are 
attractive, but I don't think they can be provided for relatively 
arbitrary message sizes without risking deadlock.  And even if deadlock 
can be avoided, this type of guarantee greatly complicates buffer 
management on the implementation side of things, so code that depends on 
it is not likely to be portable in any case.

So I suggest that this paragraph be deleted.   Does anyone have an 
argument for why this guarantee should remain?

 - Mark B.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 22 Apr 2007 09:51:48 +0200

Hi Mark,

we discussed this a while ago. I do see the case that a kernel can not
guarantee this. But the kernel can always fail the setsockopt() call.

It is intended for writing applications, where you know that all
messages are small and that you have, for instance, the 1-to-1
socket API. Then you do not have to write code to reassemble
messages in the user application.

Best regards
Michael

On Apr 21, 2007, at 10:48 PM, Mark Butler wrote:

> I do not recall the discussion on this point, but I don't think  
> this is a promise that can be kept in all cases.  Atomic read  
> semantics are attractive, but I don't think they can be provided  
> for relatively arbitrary message sizes without risking deadlock.   
> And even if deadlock can be avoided, this type of guarantee greatly  
> complicates buffer management on the implementation side of things,  
> so code that depends on it is not likely to be portable in any case.
>

---

From: Mark Butler <[email-masked]>
Date: Sun, 22 Apr 2007 23:53:30 -0600

Hello Michael,

Comments inline.

> messages in the user application.

My problem is that this option as specified is trying to accomplish 
three different things.  SCTP_PARTIAL_DELIVERY_POINT naturally tells the 
SCTP implementation that the application wants streaming data at a 
typical minimum granualarity, i.e. return whenever at least this much 
data is available.

However, a notification that the application is not prepared to handle 
partial deliveries under any circumstances should logically be handled 
by a couple of different options.  One would disable partial reads, and 
the other would set the maximum message size, to prevent denial of 
service attacks.  I suggest that the former be called SCTP_PARTIAL_READ, 
and the latter be called SCTP_MAX_MESSAGE_SIZE.

If you set SCTP_PARTIAL_READ to zero, it would indicate to the stack 
that the application will only issue one read per message in all cases, 
and any message longer than the read buffer should be truncated and 
tagged with MSG_TRUNC according to POSIX convention.

Then SCTP_MAX_MESSAGE_SIZE would simply indicate that any message larger 
than the specified size is an application level error condition, and the 
message should likewise be truncated to the specified size and reported 
immediately to the application to prevent large message based denial of 
service attacks.

And SCTP_PARTIAL_DELIVERY_POINT would be an advisory delivery point and 
nothing else. Three logically distinct options.

Comments?

 - Mark B.

>> I do not recall the discussion on this point, but I don't think  this 
>> is a promise that can be kept in all cases.  Atomic read  semantics 
>> are attractive, but I don't think they can be provided  for 
>> relatively arbitrary message sizes without risking deadlock.   And 
>> even if deadlock can be avoided, this type of guarantee greatly

---

From: Anders Torger <[email-masked]>
Date: Mon, 23 Apr 2007 09:24:25 +0200

I know it may seem that I come up with some rather strange use cases, 
but what I'm doing here is seeing how you can write fool-proof SCTP 
code, without having to make a lot of ULP adaptions and assumptions.

Some (many?) ULPs that have run over say TCP or UDP before and have 
adapted SCTP as an option, does not well specify how SCTP should be 
used. So in these cases an interoperable server would have to expect 
and work with any kind of mappings, in the worst case no mapping 
between SCTP user messages and ULP messages at all.

In the case of Diameter, messages can also be quite large, so if the 
client choose one Diameter message = one SCTP user message (the RFC 
does not specify), the PD-API would surely be triggered now and then 
for some applications.

To summarize, since SCTP support any size of its user messages, I think 
one should demand from the API that it properly supports these 
situations although rare.

Thus, I withhold that SCTP_EXTRCV should be delivered with every 
recvmsg() to better support partial deliveries.

/Anders Torger

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Apr 2007 05:14:17 -0400

Anders:

Just curious.. how large is quite large?

For BSD, the default socket buffer is 233k.. and assuming
a naive app that does not change the PD-API point.. a
message would need to be over 100k before you would get
a PD-API.. If Diameter uses 100k message.. then you are
right... they are quite large.. :-D

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Apr 2007 05:19:37 -0400

> and the latter be called SCTP_MAX_MESSAGE_SIZE.

I don't see why an app that is aware of this can't just abort
if it sees a message without MSG_EOR...

> tagged with MSG_TRUNC according to POSIX convention.

I think this is a PR_ATOMIC type behavior, and is best gotten by
using SOCK_DGRAM which is by definition PR_ATOMIC..

> immediately to the application to prevent large message based denial of 

I don't see how this is good unless you have PR_ATOMIC type behavior
which is a different socket open..

> nothing else. Three logically distinct options.

If folks wanted to go down this path I would rather see
you open a different socket type.. since PR_ATOMIC
is a much different behavior.

R

---

From: Anders Torger <[email-masked]>
Date: Mon, 23 Apr 2007 11:33:41 +0200

Randall,

Diameter is a an extensible protocol which you can build all sorts of 
applications on top of it. The maximum message size is 16 megabytes, 
but I don't think any application uses that today. I don't have good 
enough knowledge about Diameter use today to give any good examples 
unfortunately.

But when the approach is "don't receive any large messages then", then I 
have to set a specific limit, and then I have to know or make 
assumption about how large messages I will get, and the code will be 
specific for just that use case, and I don't like that. A generic 
Diameter server/stack will not know which type of Diameter messages 
that will be transported and cannot make such assumptions.

Due to that some/many protocols change from TCP to SCTP and are not 
adapted for SCTP transport from the start, I think that we may see more 
situations where mapping is more or less sketchy and a quality server 
thus must be flexible on what it accepts.

(On Linux and Solaris the default socket buffer is ~100k)

/Anders Torger

On Monday 23 April 2007 11:14, Randall Stewart wrote:
> > I know it may seem that I come up with some rather strange use
> > cases, but what I'm doing here is seeing how you can write
> > fool-proof SCTP code, without having to make a lot of ULP adaptions
> > and assumptions.
> >
> > used. So in these cases an interoperable server would have to
> > expect and work with any kind of mappings, in the worst case no
> > mapping between SCTP user messages and ULP messages at all.
> >
> > In the case of Diameter, messages can also be quite large, so if
> > the client choose one Diameter message = one SCTP user message (the
> > RFC does not specify), the PD-API would surely be triggered now and
> > then for some applications.
> >
> > To summarize, since SCTP support any size of its user messages, I
> > think one should demand from the API that it properly supports
> > these situations although rare.
> >

---

From: Mark Butler <[email-masked]>
Date: Mon, 23 Apr 2007 11:04:00 -0600

Comments inline.

Randall Stewart wrote:

>> three different things.  SCTP_PARTIAL_DELIVERY_POINT naturally tells 
>> the SCTP implementation that the application wants streaming data at 
>> a typical minimum granualarity, i.e. return whenever at least this 
>> much data is available.
>>
>> However, a notification that the application is not prepared to 
>> handle partial deliveries under any circumstances should logically be 
>> handled by a couple of different options.  One would disable partial 
>> reads, and the other would set the maximum message size, to prevent 
>> denial of service attacks.  I suggest that the former be called 
>> SCTP_PARTIAL_READ, and the latter be called SCTP_MAX_MESSAGE_SIZE.
>
>

The problem is that it is unnatural and unnecessary for 
SCTP_PARTIAL_DELIVERY_POINT to come with an atomicity guarantee.   In 
particular, as specified, once you set it to a certain value, you can 
never turn it off, because read atomicity is then enabled no matter what 
value you set it to after that. 

In addition, there are many applications of a delivery point that do not 
need atomicity of any kind, and it adds unnecessary complication and 
memory pressure on the stack to have it trying to provide atomic 
delivery when it has no idea whether the application needs it or not, or 
worse declining the option or failing unnecessarily trying to do so.

That is why the delivery point and read atomicity should be specified 
with different options.  The read atomicity option is the natural 
inverse of SCTP_EXPLICIT_EOR.   That is why I suggested 
SCTP_PARTIAL_READ and SCTP_PARTIAL_WRITE as a matched pair.

Currently the name SCTP_EXPLICIT_EOR is misleading because it only 
applies to one half of the conversation. One might think it should be 
set to zero to get read atomicity, and there will be no such effect.  To 
prevent confusion, it would be best to replace it with a pair of 
options, one for read and one for write.  Either that or have it take a 
structure as an argument.where both are specified independently.

>> that the application will only issue one read per message in all 
>> cases, and any message longer than the read buffer should be 
>> truncated and tagged with MSG_TRUNC according to POSIX convention.
>
>

..

> is a much different behavior.

I agree, that is why it is unnatural to make such behavior a side effect 
of setting the partial delivery point (see above).

SOCK_DGRAM would be great, although we would need a way to get similar 
behavior on a one-to-one style socket as well.  I suppose since 
SOCK_SEQPACKET is taken, we could co-opt SOCK_RDM for the 1-1 case.

 - Mark B.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Apr 2007 13:37:04 -0400

> value you set it to after that.

I don't grok the above.. there is always a PD-API point the stack
holds.. This does not mean when you read you will get more than
the size requested.. if it all fits before you read, guess what, you
get it all. And changing the value to say 100 bytes.. (not what I would
advise but lets go for it).. does not mean that when you read you
won't get more than 100 bytes.. since the message will surely have
more by the time you read.. add to that I can later change it to
100,000 bytes.. and now the stack will try to avoid PD-API until you
have 100,000 bytes in queue...

Your statement makes no sense to me...

> worse declining the option or failing unnecessarily trying to do so.

so turn you msg boundaries off if you don't care or want them..

The reality of many applications is they are dealing in msgs
that are a 100 bytes to a few kbytes.. and thus they are never
going to see the PD-API unless they want to tweak the stack, for
example as Michael illustrated to prevent someone sending a
large message that they don't want..

> structure as an argument.where both are specified independently.

Can't say I agree with you :-)

EOR specify's that the sender is explictily telling when the EOR
boundaries are.. if you want to do a stream of bytes you can
just set this.. and never specify it .. and close the connection.
You thus get TCP emulation..

> ...
There is no such side effect.. setting the PD-API point just tells
the stack to start the PD-API ahead of where it normally would have.

It is more of a protection OR a way to emulate TCP if you so desire..

aka set PD-API to 1 byte.. with the other side doing a EOR mode and
NOT ever ending the message..

R

---

From: Mark Butler <[email-masked]>
Date: Mon, 23 Apr 2007 14:15:22 -0600

Randall Stewart wrote:

>> never turn it off, because read atomicity is then enabled no matter 
>> what value you set it to after that.
>

You say "try".  The rfc-diff says "will".  One is advisory.  The other 
is a promise.  Hence the issue.

This is a significant change in semantics. The 
SCTP_PARTIAL_DELIVERY_POINT section in draft 14 reads:

    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 calls argument is an integer that sets or gets the partial
    delivery point. 

  However, in the rfc-diff you recently posted (on 5/21), it now reads:

    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 calls argument is an integer that sets or gets the partial
    delivery point. Note also that the call will fail if the user
    attempts to set this value larger than the socket receive buffer
    size.   

I refer to the added last sentence of the first paragraph and the second 
paragraph.  They completely change the semantics of the option from an 
advisory value to one that makes a atomicity promise.

Without this text, the partial delivery point is merely advisory.  And 
presumably it defaults to a maximum value such that deliveries (and the 
corresponding context switch overhead, etc) occur no more often than 
necessary.  And an application may very well set it to some other value 
greater than the available resources with no effect, because it is 
merely advisory.

But with the text, the semantics are atomic for messages smaller than 
the partial delivery point no matter what it is, up to and including the 
socket buffer size.  That promise cannot be portably kept on M:M style 
sockets, nor if the OS uses total overhead based accounting instead of 
counting data bytes only. (Of course if it doesn't use overhead based 
accounting it is vulnerable to a small fragment based denial of service 
attack).

These are different requirements with different default behavior.  The 
default for an advisory value is unlimited or "only when you have to".  
Whereas, a mandatory value implies a completely different socket type, 
one where if you deliver early you will break the application.  
Essentially a SOCK_DGRAM style socket.

It seems to me that advisory behavior is much more robust, and an atomic 
"delivery point" equivalent to the socket buffer size all but impossible 
to guarantee.  That is why I believe that atomic behavior should be 
specifically requested.

- Mark B.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Apr 2007 19:45:49 -0400

>     provided buffer is large enough to hold the message.

A couple of things... maybe more.

a) I did not add these.. Michael did, and I believe he posted
    his reasons why.

b) I can't see how failing the call if the user tries to set it
    bigger than the rwnd makes any sort of commitment..  thats just
    a sanity check..

c) And the last paragraph is a statement of what the stack will
    do if it has a single message smaller than the PD-API point..

d) Add to that this is an informational rfc.. which means, as many
    have pointed out often, it has no binding... whatsoever :-0

> advisory value to one that makes a atomicity promise.

Promises only come in standards track RFC's and they say things like
MUST and SHOULD..

> greater than the available resources with no effect, because it is 

I disagree.. just because the stack sanity checks your value you
DO NOT get a commitment from the stack. Set your stack's recv
socket buffer to the largest you can.. there is no 100% assurance
that you have that much data reserved..

> accounting it is vulnerable to a small fragment based denial of service 
I don't read it that way..

R

---

From: Mark Butler <[email-masked]>
Date: Mon, 23 Apr 2007 21:04:28 -0600

> that you have that much data reserved..

I agree, that is why I am suggesting that the language be clarified.  
That could be done by inserting a single word in the last paragraph.  A 
change from "will" to "will attempt" would be sufficient. 

I am not suggesting that the language is binding.  But at least it 
should not be misleading. 

Michael, does that make sense to you?

 - Mark B.