OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Mon, 28 Apr 2008 22:52:05 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> Man Pages -> Manpage of XTI-SCTP
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

Man Pages

Applications

SS7 Stack

ISDN Stack

SIGTRAN Stack

VoIP Stack

MG Stack

SS7/ISDN Devices

IP Transport

Embedded Systems

OS

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

Manpage of XTI-SCTP

Description: Manual Page

Keywords: ss7 ss7/ip ss7 over ip ss7 mtp ss7 sccp ss7 tcap sigtran mtp sccp tcap openss7 acb56 linux telephony pstn linux telephony linux nebs linux compactpci


XTI-SCTP

Section: X/Open Transport Interface (XTI) (3)
Updated: Wed, 23 Aug 2017 21:18:49 GMT
Index Return to Main Contents

NAME

xti_sctp - X/Open Transport Interface - Corrigendum for Stream Control Transmission Protocol (SCTP) Conformance

SYNOPSIS

#include <xti.h>
#include <xti_ip.h>
#include <xti_sctp.h>

int sctp_xtistr = t_open(``/dev/sctp'', flags);
int sctp_xtistr = t_open(``/dev/sctp_t'', flags);

OVERVIEW


This manual page describes the XTI interface for SCTP in accordance with XNS 5.2[1].

The X/Open Transport Interface[1] specifies addressing and options for Stream Control Transmission Protocol (SCTP). Although this interface is always exposed by including the <xti.h> header file, it is provided by the <xti_sctp.h> header file included by the former.

DESCRIPTION

This manual section describes the protocol-specific information that is relevant for SCTP transport providers. This section also describes the protocol-specific information that is relevant when SCTP services are provided over an IP network using SCTP.

This section also defines the data structures and constants required for SCTP transport providers that are exposed through the <xti_sctp.h> header file.

ADDRESS FORMAT

For convenience and traditionally, the transport interface address used by XTI for protocols in the TCP/IP protocol family use BSD-style socket addresses (also described in XNS 5.2[1]) for addresses.

The socket address, defined in <sys/socket.h>, is structured as follows:

struct sockaddr {
    uint16_t sa_family;
    char sa_data[14];
};

The Internet Protocol family socket address, defined in <netinet/in.h>, is structured as follows:

typedef unsigned int in_addr_t;
struct in_addr {
    in_addr_t  s_addr;
};
struct sockaddr_in {
    sa_family_t         sin_family;  /* Address family */
    unsigned short int  sin_port;    /* Port number */
    struct in_addr      sin_addr;    /* Internet address */
    /* padding */
};

The sockaddr_in structure contains the following members:

sin_family
The address family. Always set to AF_INET or AF_UNSPEC.
sin_port
The port number of the transport endpoint.
sin_addr
The IP address of the transport endpoint.
(padding)
Padding to pad the size of the sockaddr_in structure to the size of a sockaddr structure.

The structure is padded to the size of a sockaddr structure.

OPTIONS

Options are formatted according to the t_opthdr structure as described in xti(3). An SCTP transport provider compliant to this specification supports none, all or any subset of the options defined here. An implementation may restrict the use of any of these options by offering them only in a privileged read-only mode.

Options can be absolute requirements and can also be of end-to-end significance, as follows:

Absolute Requirements
Options that are absolute requirements, mean the when the option is negotiated with the transport service provider, the transport service provider is not permitted to negotiate the option to a value with differing quality of service. Either the proposed value is accepted or it is rejected. Options that are not absolute requirements, can be negotiated by the transport provider to a different quality of service level and it is the responsibility of the transport service user to determine whether the negotitated value is sufficient.
End-to-End Significance
Options that are of end-to-end significance are options that require negotiation with, or are communicated to, the peer transport provider or user. For example, options that are requested in a connection request, T_CONN_REQ(7), primitive will be indicated at the peer in a connection indication, T_CONN_IND(7), primitive. Options that are not of end-to-end significance are of local significance only and can be negotiated directly between the local transport service user and the local transport service provider.

An SCTP transport provider supports three levels of options. These three levels are described below.

XTI_GENERIC

Options with this level are specific to the X/Open Transport Interface (XTI/TLI)[2] and are common to all transport providers. For more information see xti(3).

The options defined with the option level XTI_GENERIC are as follows:

XTI_DEBUG
Sets debugging flags for the stream. This option is formatted as an array of t_uscalar_t. Legal values are implementation defined. For more information, see xti(3).
XTI_LINGER
Sets whether, and the amount of time if, the stream will linger waiting for unsent data to be delivered. This option is formatted as a t_linger structure as follows:

struct t_linger {
    t_scalar_t l_onoff;   /* option on/off */
    t_scalar_t l_linger;  /* linger time */
};

l_onoff
Specifies whether to linger (T_YES) or not (T_NO). Legal values are T_YES and T_NO.
l_linger
Specifies the amount of time (in seconds) to linger. Legal values are T_INFINITE, T_UNSPEC and all positive numbers including zero.

For more information, see xti(3).

XTI_RCVBUF
Specifies the size, in bytes, of the receive buffer. This option is formatted as a t_uscalar_t. Legal values are all positive, non-zero numbers. For more information, see xti(3).
XTI_RCVLOWAT
Specifies the low water mark above which received data will be indicated and delivered to the user. This option is formatted as a t_uscalar_t. Legal values are all positive, non-zero numbers. For more information, see xti(3).
XTI_SNDBUF
Specifies the size, in bytes, of the transmit buffer. This option is formatted as a t_uscalar_t. Legal values are all positive, non-zero numbers. For more information, see xti(3).
XTI_SNDLOWAT
Specifies the low water mark above which queued data will be transmitted to the peer. This option is formatted as a t_uscalar_t. Legal values are all positive, non-zero numbers. For more information, see xti(3).

T_INET_IP

Options within this level are specific to the Internet Protocol (IP) and are common to all the protocol levels in the TCP/IP suite. For more information, see xti_ip(3).

The options defined with the option level T_INET_IP are as follows:

T_IP_OPTIONS
This option determines the IP options to be sent with every packet from this transport endpoint. See xti_ip(3) for additional information.
T_IP_PKTINFO
Determines whether a T_IP_PKTINFO option indicating additional packet information associated with the received packet will be included in a T_OPTDATA_IND(7) messge as well as reflected in the response to the current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3)

T_IP_RECVTOS
Determine whether a T_IP_TOS option indicating the type of service field for the received packet will be included in a T_OPTDATA_IND(7) messge as well as reflected in the response to the current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) See T_IP_TOS.

T_IP_RECVTTL
Determine whether a T_IP_TTL option indicating the time to live for the received packet will be included in a T_OPTDATA_IND(7) messge as well as reflected in the response to the current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) See T_IP_TTL.

T_IP_RECVOPTS
Determine whether a T_IP_OPTIONS option indicating the IP options for the received packet will be included in a T_OPTDATA_IND(7) messge as well as reflected in the response to the current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) See T_IP_OPTIONS.

T_IP_RETOPTS
Determine whether a T_IP_RETOPTS option indicating the IP options for the received packet will be included in a T_OPTDATA_IND(7) messge as well as reflected in the response to the current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) For additional information, see xti_ip(3).

T_IP_TOS
This option determines the type of service to be used in IP packets associated with a subsequent data transmission. The option value is formatted as a t_scalar_t that contains the type of service value. This option is used with t_optmgmt(3). The current value that is set will be used on all packets went with t_snd(3), t_sndv(3), write(2) or writev(2). T_IP_RECVTOS is set, the current value, when read, using t_optmgmt(3), will return the value that was contained in the last IP packet read (or partially read) with t_rcv(3), t_rcvv(3), read(2) or readv(2). See xti_ip(3) for additional information.
T_IP_TTL
This option determines the time to live to be used in IP packets associated with a subsequent data transmission. The option value is formatted as a t_scalar_t that contains the time to live value. This option is used with t_optmgmt(3). The current value that is set will be used on all packets went with t_snd(3), t_sndv(3), write(2) or writev(2). T_IP_RECVTOS is set, the current value, when read, using t_optmgmt(3), will return the value that was contained in the last IP packet read (or partially read) with t_rcv(3), t_rcvv(3), read(2) or readv(2). See xti_ip(3) for additional information.
T_IP_MTU
This option is a read-only option that returns the value of the Path MTU for the SCTP association. See SCTP level options for a mechanism for obtaining MTU on a per-destination basis. When the peer is not multi-homed, this option returns the same value as would be obtained on a per-destination basis (because there is only one destination). See xti_ip(3) for additional information.
T_IP_RECVERR
Not supported.
T_IP_PMTU_DISCOVER
Supported for SCTP transport service providers without modification. See xti_ip(3) for additional information.

T_INET_SCTP

Options within this level are specific to the Stream Control Transmission Protocol (SCTP) yet are used by protocol levels using SCTP transport.

The options defined with the option level T_INET_SCTP are as follows:

T_SCTP_NODELAY
This option determines whether to delay transmission of data to attempt to coalesce smaller packets into larger packets. The option value is formatted as a t_uscalar_t that can have the values T_YES or T_NO. When set to T_YES, it conveys that packets are not to be delayed to coalesce smaller packets. When set to T_NO, it conveys that packets are being delayed to coalesce smaller packets. This option is used with t_optmgmt(3).

This option parallels the T_TCP_NODELAY option for compatibility with xti_tcp(3). T_SCTP_NODELAY and T_TCP_NODELAY can be used interchangeably.

When Nagle is enabled, SCTP uses the Nagle algorithm[3] for bundling DATA chunks into a packet. This results in far fewer short packets in the network. The algorithm is that described in RFC 896[3] ane RFC 1122[4] with the Minshall modifications to accommodate delayed SACK as described in draft-minshall-nagle-01.txt[5]. (Note: later version of tcp(7) also include the Minshall modification).

T_SCTP_MAXSEG
This option determines the maximum segment size for outgoing packets. Values greater thatn the association MTU are ignored and have no effect. This parallels the T_TCP_MAXSEG option for compatibility with xti_tcp(3). T_SCTP_MAXSEG and T_TCP_MAXSEG can be used interchangeably.

This value determines the maximum size (in bytes) above which SCTP will fragment larger DATA chunks into smaller DATA chunks, and beneath which SCTP will bundle DATA chunks into a single packet or combined smaller DATA chunks into larger DATA chunks. Normally this value is the association MTU value minus the size of the current IP and SCTP headers, minus the size of one DATA chunk header. If the user sets this to a lower value, the lower value will be used.

This option is formatted as a t_scalar_t indicating the maximum size in bytes. This option is used with t_optmgmt(3).

T_SCTP_CORK
This option determines whether to cork the transmission stream waiting for subsequent packets. When set, this option permits a number of t_snd(3) operations to be performed without sending the data subsequent to the cork. When the cork is released, all subsequent data will be permitted to proceed. The option is formatted as a t_scalar_t that can have the values T_YES, conveying that transmission is corked, or T_NO, conveying that transmission is uncorked. THis option is used with t_optmgmt(3).
T_SCTP_SID
This option determines the SCTP Stream Identifier that is to be associated with a given data transmission. The option value is formatted as a t_scalar_t that contains the numeric value of the SCTP Stream Identifier. This options is used with t_optmgmt(3). The current value that is set will be used on all packets sent with t_snd(3), t_sndv(3), write(2) or writev(2). When option T_SCTP_RECVSID is set, the current value, when read, using t_optmgmt(3), will return the value that was contained in the last packet read with t_rcv(3), t_rcvv(3), read(2) or readv(2). See T_SCTP_RECVSID.
T_SCTP_PPI
This option determines the SCTP Payload Protocol Identifier that is to be associated with a given data transmission. The option value is formatted as a t_scalar_t that contains the numeric value of the SCTP Payload Protocol Identifier. This option is used with t_optmgmt(3). The current value that is set will be used on all packets sent with t_snd(3), t_sndv(3), write(2) or writev(2). When option T_SCTP_RECVPPI is set, the current value, when read, using t_optmgmt(3), will return the value that was contained in the last packet read with t_rcv(3), t_rcvv(3), read(2) or readv(2). See T_SCTP_RECVPPI.
T_SCTP_RECVSID
Determine whether a T_SCTP_SID option indicating the SCTP Stream Identifier of the received data will be included in a T_OPTDATA_IND(7) message as well as reflected in the response to a current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) See T_SCTP_SID.

T_SCTP_RECVPPI
Determine whether a T_SCTP_PPI option indicating the SCTP Payload Protocol Identifier of the received data will be included in a T_OPTDATA_IND(7) message as well as reflected in the response to a current value T_GET operation to t_optmgmt(3). The option value is a t_scalar_t with valid values T_YES or T_NO. This option is for use with t_optmgmt(3).

This option is for use with the sockets(3) library. For xti(3) it changes the semantics of the value returned to a T_GET operation to t_optmgmt(3). When set to T_YES, the current value obtained with a T_GET operation to t_optmgmt(3) will be the value of the last received message. When set to T_NO, the current value obtains with a T_GET operation to t_optmgmt(3) will be the default value or the value last set with a T_NEGOTIATE operation to t_optmgmt(3) See T_SCTP_PPI.

T_SCTP_HEARTBEAT_ITVL
This option determines the time interval (in seconds) between successive HEARTBEAT messages used to probe destination transport addresses for RTT calculation and activity. This option is formatted as a t_scalar_t. Valud values are zero (0), indicating do not heartbeat, or a value of 1 second or greater indicating the heartbeat interval. This options is used with t_optmgmt(3), t_connect(3) or t_accept(3).

The value set with t_optmgmt(3) is the value that will be assigned to new destinations. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). Active destinations can be controlled with the option T_SCTP_HB, below.

T_SCTP_HB
This option determines the heartbeat activation and interval associated with a specific destination address. The option value is a t_sctp_hb structure. This option will return an error if it is attempted on a stream in the unconnected state. The t_sctp_hb structure is formatted as follows:

typedef struct t_sctp_hb {
    uint32_t hb_dest;        /* destination address */
    t_uscalar_t hb_onoff;    /* activation flag */
    t_uscalar_t hb_itvl;     /* interval in milliseconds */
} t_sctp_hb_t;

The t_sctp_hb structure has the following fields:

hb_dest
is the sockaddr_in structure that contains the destination address to which the heartbeat setting applies.
hb_onoff
is an integer boolean activation flag indicating whether heartbeat is active on the destination.
hb_itvl
is the integer heartbeat interval in milliseconds.

This option is intended to be used with t_optmgmt(3). dest must be one of the valid addresses associated with the connection. Note that heartbeat activity can also be set on an association basis using the option T_SCTP_HEARTBEAT_ITVL.

T_SCTP_RTO_INITIAL
This option determines the time interval (in milliseconds) that will be used as an initial RTO (Retransmission Time Out) value when sending packets to a destination for the first time. This option if formatted as a t_scalar_t. Valid values are zero or greater and must be within the range from T_SCTP_RTO_MIN to T_SCTP_RTO_MAX. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). Active destinations can be controlled with the option T_SCTP_RTO, below.
T_SCTP_RTO_MIN
Determine the time interval (in milliseconds) that will be used as a minimum RTO (Retransmission Time Out) value when sending packets. This option if formatted as a t_scalar_t. Value values are zero or greater and must be less than or equal to the value T_SCTP_RTO_MAX. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). Active destinations can be controlled with the option T_SCTP_RTO, below.
T_SCTP_RTO_MAX
Determine the time interval (in milliseconds) that will be used as a maximum RTO (Retransmission Time Out) value when sending packets. This option if formatted as a t_scalar_t. Value values are zero or greater and must be greater than or equal to the value T_SCTP_RTO_MIN. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). Active destinations can be controlled with the option T_SCTP_RTO, below.
T_SCTP_PATH_MAX_RETRANS
This option determines the number of times that the sending endpoint will attempt retransmitting a packet to a given destination transport address before it considers that destination transport address inactive. This option is formatted as a t_scalar_t. Value values include zero. This options is used with t_optmgmt(3), t_connect(3) or t_accept(3).

The value set with t_optmgmt(3) is the value that will be assigned to new destinations. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). Active destinations can be controlled with the option T_SCTP_RTO, below.

T_SCTP_RTO
This option determines the retransmission timeout parameters associated with a specific destination address. The option value is formatted as a t_sctp_rto structure, formatted as follows:

typedef struct t_sctp_rto {
    uint32_t rto_dest;       /* destination address */
    t_uscalar_t rto_initial; /* RTO.Initial (millisec) */
    t_uscalar_t rto_min;     /* RTO.Min (millisec) */
    t_uscalar_t rto_max;     /* RTO.Max (millisec) */
    t_uscalar_t max_retrans; /* Path.Max.Retrans (retries) */
} t_sctp_rto_t;

The t_sctp_rto structure has the following fields:

rto_dest
is a sockaddr_in structure that contains the destination address to which the rto parameter settings apply.
rto_initial
is the t_uscalar_t initial retransmission timeout value in milliseconds. For valid values, see T_SCTP_RTO_INITIAL.
rto_min
is the t_uscalar_t minimum retransmission timeout value in milliseconds. For valid values, see T_SCTP_RTO_MIN.
rto_max
is the t_uscalar_t maximum retransmission timeout value in milliseconds. For valid values, see T_SCTP_RTO_MAX.
max_retrans
is the t_uscalar_t maximum number of retransmissions. For valid values, see T_SCTP_PATH_MAX_RETRANS.

For use with t_optmgmt(3), dest must be one of the valid destination addresses associated with the transport connection.

T_SCTP_CKSUM_TYPE
This option determines the checksum type that will be used to checksum SCTP packets. The option value is formatted as a t_scalar_t, and can have on of the following values:
T_SCTP_CSUM_ADLER_32
use the older RFC 2960[6] Adler 32 checksum to checksum SCTP packets.
T_SCTP_CSUM_CRC_32C
use the newer RFC 3309[7] CRC32 checksum to checksum SCTP packets.

To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3).

T_SCTP_MAC_TYPE
This option determines the MAC (Message Authentication Code) type that will be used with signing cookies in INIT-ACK messages. The option value is formatted as a t_scalar_t, and can have one of the following values:
T_SCTP_HMAC_NONE
No message authentication code will be used. The MAC field will be populated with all ones. This completely disables the MAC features of SCTP, and should be used with caution.
T_SCTP_HMAC_SHA_1
The message authentication code will use SHA-1 message digest.
T_SCTP_HMAC_MD5
The message authentication code will use MD5 message digest.

To be effective, this option must be set before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). The option can be read at any time and reflects the current setting.

T_SCTP_COOKIE_LIFE
Determines the cookie lifetime associated with a transport endpoint. This is the amount of time that cookies sent to the peer endpoint in an INIT-ACK message will be valid. For SCTP this also limits the maximum for which the HMAC secret key for the cookie will be valid. The option value is formatted as a t_scalar_t that contains the time interval in milliseconds. Valid values are zero (0) or greater. The default value is that proscribed by RFC 2960[6]. This options is used with t_optmgmt(3), t_connect(3) or t_accept(3).

The value set with t_optmgmt(3) is the value assigned to the transport endpoint. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3).

Reducing this value will increase the changes that passive connection attempts will fail due to expired cookies. Increasing the value will reduce the overall security of the system by permitting attackers an increased interval to crack HMACs and guess verification tags. This value may be adjusted in conjunction with the T_SCTP_COOKIE_INC to meet most objected for successful passive connection attempts with the best security afforded by smaller values of T_SCTP_COOKIE_LIFE.

Unfortunately the T_SCTP_COOKIE_LIFE and T_SCTP_COOKIE_INC must be adjusted to accommodate the slowest peer on the slowest connection. The default setting is adequate for Internet applications.

T_SCTP_COOKIE_INC
This option determines the time increment (in milliseconds) that will be added to the lifespan of the cookie in an INIT-ACK if the sender of the INIT requested cookie preservation to lengthen the lifespan of the cookie. The option value is formatted as a t_scalar_t. Valid values include zero. To be effective, this option must be set before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). The option can be read at any time and reflects the current setting.
T_SCTP_THROTTLE_ITVL
Determines the interval (in milliseconds) within which the receiver will not accept more than one INIT or COOKIE-ECHO. The option value is formatted as a t_scalar_t. Zero (don't throttle) is a valid value. To be effective, this option must be set before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). The option can be read at any time and reflects the current setting.
T_SCTP_ISTREAMS
Sets the maximum number of inbound streams or gets the actual number of inbound streams associated with the transport connection. The option value is formatted as a t_scalar_t. Valid values are from 1 to 16,736. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). For active transport connections, setting this option has no effect on the current transport connection.
T_SCTP_OSTREAMS
Sets the maximum number of outbound streams or gets the actual number of outbound streams associated with the transport connection. The option value is formatted as a t_scalar_t. Valid values are from 1 to 16,736. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). For active transport connections, setting this option has no effect on the current transport connection.
T_SCTP_SSN
This option determines the SCTP Stream Sequence Number that is to be associated with a given data transmission. The option value is formatted as a t_scalar_t that contains the numeric value of the SCTP Stream Sequence Number. This options is used with t_optmgmt(3). The SCTP transport provider determines which values will be used on all packets sent with t_snd(3), t_sndv(3), write(2) or writev(2). The current value, when read, using t_optmgmt(3), will return the value that was contained in the last packet read with t_rcv(3), t_rcvv(3), read(2) or readv(2).
T_SCTP_ECN
This option determines whether the Explicit Congestion Notification (ECN) capability of RFC 3168[8] and Appendix A of RFC 2960[6] is used on the transport connection. The option value is formatted as a t_scalar_t and have have valid values T_YES or T_NO.

When set to T_YES, explicit congestion notification is enabled on the transport connection. When set to T_NO, explicit congestion notification is disabled on the transport connection. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3). For active transport connections, setting this option has no effect on the current transport connection.

T_SCTP_ALI
This option determines the adaptation layer information (described in draft-ietf-tsvwg-addip-sctp-08.txt)[9] to be used in the INIT or INIT-ACK on all passive or active connection attempts on the transport endpoint, or gets the adaptation layer information provided by the transport peer on a connected transport endpoint. The option value is formatted as a t_scalar_t that contains the adaptation layer information.

When set to zero (0), no adaptation layer information will be included in the INIT or INIT-ACK; when non-zero, it contains the flag bits that will be sent in the adaptation layer information in the INIT or INIT-ACK. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3).

If the transport endpoint is in a disconnected state (and has never been connected), getting this option returns zero (0). If the transport endpoint has been in a connected state, getting this option returns zero (0) if no adaptation layer information was present during the connection, or returns the adaptation layer information bits if provided by the peer.

This option supports the adaptation layer information features described in draft-ietf-tsvwg-addip-sctp-08.txt[9].

T_SCTP_PR
This option determines whether partial reliability (described in RFC 3758)[10] will be supported or required on transport connection establishment, or gets the indication of support for partial reliability provided by the peer on a connected transport endpoint. The option value is formatted as a t_scalar_t and can contain one of the following values:
T_SCTP_PR_NONE
do not place or response with a Forward TSN parameter in an INIT or INIT-ACK indicating to the peer that we do not support partial reliability for this transport connection.
T_SCTP_PR_PREFERRED
place and response with a Forward TSN parameter in an INIT or INIT-ACK indicating to the peer that we support partial reliability, but do no require the peer to support partial reliability.
T_SCTP_PR_REQUIRED
place and response with a Forward TSN parameter in an INIT or INIT-ACK indicating to the peer that we support partial reliability and require the peer to do the same.

For a connected transport endpoint, when this options is set to T_SCTP_PR_PREFERRED or T_SCTP_PR_REQUIRED, it indicates that the peer supports partial reliability. When set to T_SCTP_PR_NONE, it indicates that the peer does not support partial reliability.

T_SCTP_MAX_INIT_RETRIES
This option determines the number of times that an INIT or COOKIE-ECHO will be resent before abandoning the transport connection initialization. This option value is formatted as a t_scalar_t. To be effective, this option must be set with the call to t_connect(3) or before the call to t_listen(3), or when a passive connection indication is accepted with t_accept(3).
T_SCTP_MAX_BURST
This option determines the number of MTUs of data that will be sent in a single burst, as defined in SCTP Errata[11]. The option value is formatted as a t_scalar_t. Valid values are one (1) or greater. This option may be changed at any time during the transport connection lifetime. This option is of local significance only.
T_SCTP_ASSOC_MAX_RETRANS
Determines the number of times that the sending endpoint will attempt retransmitting a packet on a given transport connection before it aborts the connection. This option is formatted as a t_scalar_t. Value values include zero. This value should be larger than the sum of all the T_SCTP_PATH_MAX_RETRANS values of each of the destinations. This option may be changed on the stream at any time during the life of the transport connection.
T_SCTP_SACK_DELAY
This option determines the maximum SACK delay as the interval of time (in milliseconds) that the sending endpoint will delay an acknowledgment of a received DATA chunk. The option value is formatted as a t_scalar_t. Valid values are zero (0) or greater, however, the maximum SACK delay should not exceed 500 milliseconds (setting this value to greater than 500 milliseconds is forbidden by RFC 2960)[6] for Internet Applications. This option may be changed at any time during the life of the transport connection.
T_SCTP_DISPOSITION
This option determines whether SCTP will retain and deliver messages that were not successfully acknowledged by the peer for retrieval, or will deliver confirmation of acknowledgment for message successfully acknowledged by the peer. The option value is formatted as a t_scalar_t, and can have one of the following values:
T_SCTP_DISPOSITION_NONE
Messages will not be retained for retrieval and acknowledgments will not be provided for messages.
T_SCTP_DISPOSITION_UNSENT
Messages that were unsent will be retained for retrieval.
T_SCTP_DISPOSITION_SENT
Messages that were sent and unacknowledged, or that were unsent, will be retained for retrieval.
T_SCTP_DISPOSITION_GAP_ACKED
Messages that were sent and gap acknowledged as well as messages that were sent and unacknowledged and messages that were unsent, will be retained for retrieval.
T_SCTP_DISPOSITION_ACKED
Messages that were sent and acknowledged (but unconfirmed), messages that were sent and gap acknowledged, messages that were sent and unacknowledged, and messages that were unsent, will be retained for retrieval.

This option permits messages that are unsent, sent but not acknowledged or sent and gap acknowledged, to be retrieved from the transport endpoint before close. This is accomplished by setting the T_SCTP_DISPOSITION option before shutdown or abort of the transport connection, and then calling t_rcv(3) or t_rcvv(3) after POLLHUP, SIGPIPE or EPIPE indicating a shutdown or abort of the transport connection. Messages then read will set the T_SCTP_DISPOSITION option on the transport endpoint to indicate whether they were T_SCTP_DISPOSITION_UNSENT, T_SCTP_DISPOSITION_SENT, T_SCTP_DISPOSITION_GAP_ACKED or T_SCTP_DISPOSITION_ACKED.

If the transport endpoint has option T_SCTP_PR set and the peer supports partial reliability (see T_SCTP_PR), message which have failed partial reliability delivery (were dropped) will also be retrieved by t_rcv(3) or t_rcvv(3).

Alternatively, if the socket option T_SCTP_DISPOSITION is set to T_SCTP_DISPOSITION_ACKED, t_rcv(3) or t_rcvv(3) will also return acknowledgments for messages not acknowledged sent at the time of the transport connection disconnection.

This option is intended for use with the sockets(3) library, is extremely non-portable, and has little use for xti(3).

T_SCTP_LIFETIME
This option determines the SCTP lifetime[6] or the partial reliability timed reliability lifetime[10] associated with message that are sent on this transport endpoint. The option value is formatted as a t_scalar_t that contains the lifetime (in milliseconds).
T_SCTP_ADD
This option determines whether the transport endpoint will support the add IP extension (ADD-IP and DEL-IP) described in draft-ietf-tsvwg-addip-sctp-08.txt[9]. The option value is formatted as a t_scalar_t that can have values T_YES or T_NO.

When set to T_YES, this option request that SCTP respond to ASCONF chunks with ADD-IP or DEL-IP requests. When set to T_NO, SCTP will refuse these requests for the transport connection. This option can be set or read at any time during the transport connection lifetime.

T_SCTP_ADD_IP
This option adds a IP address to an existing transport endpoint. The option value is formatted as a sockaddr_in structure that contains the local IP address to add. Option T_SCTP_ADD must be set to T_YES for this option to be valid.

If the transport stream is in a connected or connecting state, this invokes the ASCONF procedure to add the IP address to the existing transport connection. If the transport stream is in a disconnected state, setting this option will add the local IP address to the addresses bound with t_bind(3), and acts as a hierarchal subsequent binding operation.

Note that if a transport endpoint was initially bound to INADDR_ANY, IP addresses may be automatically added to the transport connection if new network interfaces are added to the system, or if existing network interfaces are configured using ifconfig(8) or equivalent commands.

T_SCTP_DEL_IP
This option deletes an IP address from an existing transport endpoint. The option value is formatted as a sockaddr_in structure that contains the local IP address to delete. Option T_SCTP_ADD must be set to T_YES for this option to be valid.

If the transport stream is in a connected or connecting state, this invokes the ASCONF procedure to remove the IP address from the transport connection. If the transport stream is in a disconnected state, setting this option will remove the local IP address from the addresses bound with t_bind(3), and acts as a hierarchal subsequent unbinding operation.

Note that if the transport endpoint was initially bound to INADDR_ANY, IP addresses may be automatically removed from the transport connection if existing network interfaces are removed from the system, or if network interfaces are reconfigured with ifconfig(8) or equivalent commands.

T_SCTP_SET
This option determines whether the transport endpoint will support the add IP extensions (SET-PRIMARY) described in draft-ietf-tsvwg-addip-sctp-08.txt[9]. The option value is formatted as a t_scalar_t that can have values T_YES or T_NO.

When set to T_YES, this option request that SCTP respond to ASCONF chunks with SET-PRIMARY requests. When set to T_NO, SCTP will refuse these requests for the transport connection. This option can be set or read at any time during the transport connection lifetime.

T_SCTP_STATUS
This option conveys the association status and the status associated with each of the destination transport addresses forming the transport connection. This is a read-only option. The returned value is formatted as a t_sctp_status structure containing one t_sctp_dest_status structure for each destination transport address, formatted as follows:

typedef struct t_sctp_status {
    t_uscalar_t curr_rwnd;   /* receive window */
    t_uscalar_t curr_rbuf;   /* receive buffer */
    t_uscalar_t curr_nrep;   /* dests reported */
    t_sctp_dest_status_t curr_dest[0]; /* primary dest */
} t_sctp_status_t;
typedef struct t_sctp_dest_status {
    t_uscalar_t dest_addr;   /* address */
    t_uscalar_t dest_cwnd;   /* congestion window */
    t_uscalar_t dest_unack;  /* unacknowledged chunks */
    t_uscalar_t dest_srtt;   /* smooth round trip time */
    t_uscalar_t dest_rvar;   /* rtt variance */
    t_uscalar_t dest_rto;    /* current rto */
    t_uscalar_t dest_sst;    /* slow start threshold */
} t_sctp_dest_status_t;

The t_sctp_status structure has the following fields:

curr_rwnd
is the current advertised receive window in bytes.
curr_rbuf
is the current receive buffer size in bytes.
curr_nrep
is the number of t_sctp_dest_status structure that follow this structure.

The t_sctp_dest_status structure has the following fields:

dest_addr
is the address associated with this specific t_sctp_dest_status structure.
dest_cwnd
is the congestion window for the given destination transport address in bytes.
dest_unack
is the number of unacknowledged DATA chunks outstanding to the given destination transport address in chunks.
dest_srtt
is the smoothed round trip time for the destination transport address in milliseconds.
dest_rvar
is the round trip time variance for the destination transport address in milliseconds.
dest_rto
is the current value of the round trip timeout for the destination transport address in milliseconds.
dest_sst
is the current value of the slow start threshold for the destination transport address in bytes.
T_SCTP_TSN
This option determines the SCTP Transmit Sequence Number that is to be associated with a given data transmission. The option value is formatted as a t_scalar_t that contains the numeric value of the SCTP Transmit Sequence Number. This options is used with t_optmgmt(3). The SCTP transport provider determines which values will be used on all packets sent with t_snd(3), t_sndv(3), write(2) or writev(2). The current value, when read, using t_optmgmt(3), will return the value that was contained in the last packet read with t_rcv(3), t_rcvv(3), read(2) or readv(2).
T_SCTP_DEBUG
This option determines implementation specific debugging features. The option value is formatted as a t_scalar_t, that can be one of the following values:
T_SCTP_OPTION_DROPPING
the stream will drop packets at the software level for debugging purposes.
T_SCTP_OPTION_BREAK
the stream will break the first destination address at intervals for debugging purposes.
T_SCTP_OPTION_DBREAK
the stream will break destination addresses in both directions at intervals for debugging purposes.
T_SCTP_OPTION_RANDOM
the stream will drop packets at random at the software level for debugging purposes.

FUNCTIONS

XTI-SCTP supports the XTI/TLI library functions as described in this section. All connection-oriented XTI/TLI library calls are supported for SCTP; however, some features of the connection-oriented XTI/TLI library calls are supported by the underlying transport service provider and some are not.

t_accept(3)

XTI-SCTP supports this XTI/TLI library call as described in t_accept(3), with the additional considerations described here.

When the XTI/TLI user provides a transport endpoint address in call->addr, the address can be an array of sockaddr_in structures, each indicating a local address for the responding endpoint. If this list of addresses does not include the destination address of the connection indication, the set of addresses will be expanded by the SCTP provider to include the destination address of the connection indication.

Issuing t_accept(3) assigns an already established connection to resfd.

Since user data cannot be exchanged during the connection establishment phase, call->udata.len must be set to zero.

When (resfd != fd), the function t_accept(3) is recommended to be called with resfd in the T_UNBND state, though an endpoint which is bound to any local address (in the T_IDLE state) can also be used.

After t_accept(3) completes, the endpoint resfd will represent a connected SCTP endpoint whose complete binding essentially has both local and remote address components.

If file descriptor resfd was unbound before calling t_accept(3), after the call completes its local address binding would be to the same protocol address bound to fd. If the file descriptor resfd was bound to a local address before calling t_accept(3), that local address binding is dissolved and the local address part of the binding after t_accept(3) completes would become the same as the address bound to fd.

If options with end-to-end significance (T_IP_OPTIONS, T_IP_TOS, T_SCTP_OSTREAMS, T_SCTP_ISTREAMS, T_SCTP_ECN and T_SCTP_ALI) are to be sent with the connection confirmation, the values of these options must be set with t_optmgmt(3) prior to the T_LISTEN event occurs. When the transport user detects a T_LISTEN event, SCTP has already established the connection. Association-related options passed with t_accept(3) become effective at once, but since the connection is already established, they are transmitted with subsequent IP datagrams sent out in the T_DATAXFER state.

XTI-SCTP provides a number of options, described in ``OPTIONS'', above, that may be included in this XTI/TLI call in the call->opt parameter to change local and end-to-end characteristics of the transport endpoint accepting the connection. The options of end-to-end significance that can be included in this XTI/TLI library call are:

T_IP_OPTIONS
T_IP_TOS
T_SCTP_ISTREAMS
sets the number of incoming streams for the transport connection. This value is only significant if it is lower than the value requested by the peer in the options returned from the call to t_listen(3).
T_SCTP_OSTREAMS
sets the number of outgoing streams for the transport connection. This value is only significant if it is lower than the value required by the peer in the options returned from the call to t_listen(3).
T_SCTP_ECN
sets whether explicit congestion notification is supported on the transport connection. This value is only significant if the peer indicates that it supports explicit congestion notification in the options returned from the call to t_listen(3).
T_SCTP_ALI
sets the adaptation layer information specifying the local endpoint capabilities that are available on the transport connection.

The association-related options that can be included in this XTI/TLI call include (other association-related options may also be included):

The options of local significance that can be included in this XTI/TLI call include (other options of local significance may also be included):

XTI_DEBUG
XTI_LINGER
XTI_RCVBUF
XTI_RCVLOWAT
XTI_SNDBUF
XTI_SNDLOWAT
T_IP_TTL
T_IP_REUSEADDR
T_IP_DONTROUTE
T_IP_BROADCAST
T_SCTP_HEARTBEAT_ITVL
sets the heartbeat interval to be used on all destination addresses during the connection. This value can be changed for specific connection by providing this option to the t_accept(3). This value may be changed during the transport connection using the T_SCTP_HB option to t_optmgmt(3).
T_SCTP_RTO_INITIAL
sets the initial retransmission timeout for all destinations. This value can be changed for specific connection by providing this option to the t_accept(3). This value may be changed during the transport connection using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_RTO_MIN
sets the minimum retransmission timeout interval for all destinations. This value can be changed for specific connection by providing this option to the t_accept(3). This value may be changed during the transport connection using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_RTO_MAX
sets the maximum retransmission timeout interval for all destinations. This value can be changed for specific connection by providing this option to the t_accept(3). This value may be changed during the transport connection using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_PATH_MAX_RETRANS
sets the maximum number of times that a retransmission will be directed at a destination address until the destination address is deemed inactive. This value can be changed for specific connection by providing this option to the t_accept(3). This value may be changed during the transport connection using the T_SCTP_RTO option to t_optmgmt(3). T_SCTP_MAX_INIT_RETRIES sets the maximum number of COOKIE-ACK retransmissions that will be performed until the destination transport address is abandoned. This value is read-only in other than the T_IDLE or T_OUTCON states. This value can be changed for specific connection by providing this option to the t_accept(3).

If the provider indicates that connect data can be included in the response to t_getinfo(3), the XTI/TLI user can provide connection data in the call->udata parameter.

t_bind(3)

XTI-SCTP supports this XTI/TLI library call as described in t_bind(3), with the additional considerations described here.

When the XTI/TLI user provides a transport endpoint address in req->addr, the address to bind can contain multiple sockaddr_in structures, each representing a local IP address to which to bind a multi-homed SCTP transport endpoint. Each address in the array must have the same req->addr[i].sin_family and req->addr[i].sin_port value.

When the SCTP transport service provider returns the bound address in ret->addr, the address bound can contain multiple sockaddr_in structures, each representing a bound local IP address. The SCTP conforming transport service provider will return the same values in each ret->addr[i].sin_family and ret->addr[i].sin_port fields.

The INET(4) implementation treats port number zero (0) as a request to bind to any unused port. Other than that value, the req->addr.sin_port part of the binding is specific. The req->addr.sin_addr.in_addr part of the binding can represent a single IP address or a wildcard binding to an address that could represent multiple IP addresses that are legal for the host (INADDR_ANY).

Under recent versions of INET(4), t_bind(3) called with a NULL req argument is equivalent to binding to a wildcard port number with a wildcard IP address.

Under INET(4), when bound to a wildcard port or IP address, assignment of a specific port number and IP address can be deferred until an incoming or outgoing connection is initiated. Under these situations, any address returned in the ret argument to t_bind(3) or the loc argument to t_getprotaddr(3) will return the wildcard address and port number instead of an assigned list of addresses and port number. Only once a connection has been established will the local address returned by t_getprotaddr(3) be assured to be an assigned address list rather than a wildcard address.

t_close(3)

XTI-SCTP supports this XTI/TLI library call as described in t_close(3) without modification.

The t_close(3) call will result in a close(2) call on the descriptor of this XTI/TLI communication endpoint. If there are no other descriptors in this process which reference the communications endpoint, the close(2) call will perform an orderly connection termination according to the rules of a TCP CLOSE call on this transport endpoint as specified in the standards RFC 793[12] and RFC 1122[4]. If the XTI_LINGER option is supported and is used to enable the linger option, the linger time will affect the time an implementation lingers in the execution of t_close(3) or close(2). A linger time of zero (0) specified with the XTI_LINGER option may cause an abortive release of a TCP connection, resulting in lost data.

t_connect(3)

XTI-SCTP supports this XTI/TLI library call as described in t_connect(3), with the additional considerations described here.

The sndcall->addr structure specifies the remote socket. In the present version, the returned address set in rcvcall->addr will have the same value. Note that the peer SCTP, and not the peer transport user, confirms the connection.

When the XTI/TLI user provides a transport endpoint address to which to connect in sndcall->addr, the address can be an array of sockaddr_in structures, each indicating a remote address for the endpoint to which to connect. Only one address is necessary to successfully form a multi-homed transport connection; however, if additional addresses are provided, the transport connection is initialized in a more secure and reliable fashion.

XTI-SCTP provides a number of options, described in ``OPTIONS'', above, that may be included in this XTI/TLI call in the sndcall->opt parameter to change local and end-to-end characteristics of the transport endpoint accepting the connection. The options of end-to-end significance that can be included in this XTI/TLI library call are:

T_SCTP_CKSUM_TYPE
set the type of checksum to be performed on all packets for the connection. This option is useful if the connecting XTI/TLI user is aware that the destination transport endpoint only supports the older Adler 32 checksum.
T_SCTP_ISTREAMS
set the maximum number of incoming streams for the connection. The peer must respect this value and negotiate the number of incoming streams to be less than or equal to this value or the transport connection will fail.
T_SCTP_OSTREAMS
set the requested number of outgoing streams for the connection. The peer may negotiate a smaller number of outgoing streams depending on its maximum incoming stream requirements. It is the XTI/TLI user's responsibility to check the number of outgoing streams in the rcvcall->opt response or in the call->opt response from a call to t_rcvconnect(3). If the negotiated number of outgoing streams is not acceptable, it is the responsibility of the XTI/TLI user to disconnect the transport connection.
T_SCTP_ECN
sets whether explicit congestion notification is to be supported for the transport connection.
T_SCTP_ALI
sets which adaptation layer information is to be communicated and negotiated for the connection. If the negotiated adaptation layer information is less than the capabilities sent on connection request, it is the XTI/TLI user's responsibility to check the adaptation layer information returned in the rcvcall->opt response or in the call->opt response from a call to t_rcvconnect(3). If the negotiated capabilities is not acceptable, it is the responsibility of the XTI/TLI user to disconnect the transport connection.

The options of local significance that can be included in this XTI/TLI call include (other options of local significance may also be included):

T_SCTP_HEARTBEAT_ITVL
sets the heartbeat interval to be used on all destination addresses during the connection. This value can be changed during the transport connection for specific destinations using the T_SCTP_HB option to t_optmgmt(3).
T_SCTP_RTO_INITIAL
sets the initial retransmission timeout for all destinations. This value can be changed during the transport connection for specific destinations using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_RTO_MIN
sets the minimum retransmission timeout interval for all destinations. This value can be changed during the transport connection for specific destinations using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_RTO_MAX
sets the maximum retransmission timeout interval for all destinations. This value can be changed during the transport connection for specific destinations using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_PATH_MAX_RETRANS
sets the maximum number of times that a retransmission will be directed at a destination adress until the destination address is deemed inactive. This value can be changed during the transport connection for specific destinations using the T_SCTP_RTO option to t_optmgmt(3).
T_SCTP_MAX_INIT_RETRIES
sets the maximum number of INIT retransmissions that will be performed until the destination transport address is abandoned. When multiple transport endpoint addresses are provided to t_connect(3), each destination transport address will be tried this many times in turn.

If the provider indicates that connection data can be included in the response to t_getinfo(3), the XTI/TLI user can provide connection data in the sndcall->udata parameter.

For information that may be returned in the rcvcall argument to t_connect(3), see the considerations for the call argument to t_rcvconnect XTI/TLI library call, below.

t_getinfo(3)

XTI-SCTP supports this XTI/TLI library call as described in t_connect(3) with the additional considerations described here.

addr
For compatibility with the sockets(3) library, SCTP uses a sockaddr_in structured address (see ``ADDRESS FORMAT'', above). However, a number of XTI/TLI library calls support multiple sockaddr_in address to be specified in a single call. This size will be an integer multiple of the size of the sockaddr_in structure size, indicating how many sockaddr_in structures can be included in a single address specification.
options
The maximum size of options is provider specific. The OpenSS7 SCTP implementation (sctp(4)) returns the maximum size of an option structure containing all SCTP options.
tsdu
The maximum size of a transport service data unit. For SCTP this is the maximum size of a message, considering that it may be segmented and sent in multiple DATA chunks. For SCTP this value could be T_INFINITE. SCTP[6] has some limitations resulting from stream blockage due to large messages that need to be fragmented and sent in multiple chunks. Some implementations may want to restrict the maximum size of a TSDU to something smaller for this purpose.
etsdu
SCTP supports the concept of expedited data as data that is sent unordered. SCTP conforming transport provides will not return T_INVALID for this field. The maximum ETSDU size is subject to the same considerations as the TSDU size above. Some implementations may wish to restrict the size of the ETSDU to smaller than the TSDU because unordered data causes more problems with stream blocking due to fragmentation in SCTP[6].
connect
XTI-SCTP supports the concept of connection data. Although SCTP also supports sending the first fragments of a TSDU or ETSDU with the COOKIE-ECHO or COOKIE-ACK chunks, and subsequent fragements later, this value represents the maximum size of a TSDU that can be completely contained in the COOKIE-ECHO or COOKIE-ACK chunks. This value will typically be substantially less than the TSDU size above. Implementations that do not support sending of DATA chunks bundled with the COOKIE-ECHO or COOKIE-ACK may return T_INVALID for this field.

(Note that there is no way in TPI[13] to send a T_CONNECT_REQ(7) indicated expedited data. Therefore, it is only possible to send a TSDU with t_connect(3) in xti(3).

discon
Although SCTP supports orderly release, SCTP does not support the concept of disconnection data. SCTP conforming transport providers will always return T_INVALID in this field.
servtype
XTI-SCTP supports only connection-oriented modes with orderly release. SCTP conforming transport service providers will return T_COTS_ORD whenever the SCTP implementation supports orderly release (i.e. SHUTDOWN and SHUTDOWN-ACK). SCTP conforming transport service providers may return T_COTS if the SCTP implementation does not support orderly release. SCTP conforming transport service providers will not return T_CLTS.
flags
XTI-SCTP supports orderly release but does not support orderly release data and does not support sending null data. SCTP conforming transport service providers will not return T_ORDRELDATA or T_SNDZERO flags. SCTP conforming transport service providers may return the XPG4_1 flag.

t_listen(3)

XTI-SCTP supports this XTI/TLI library call as described in t_listen(3) with the additional considerations described here.

Upon successful return t_listen(3) indicates an existing connection and not a connection indication. Since user data cannot be exchanged during the connection establishment phase, call->udata.maxlen must be set to zero (0) before the call to t_listen(3). The call->addr structure contains the remote calling socket.

XTI-SCTP does not support the same semantics with regard to indication of connections, acceptance of indicated connections, and negotiation of options during connection establishment. This is because the connection can be internally accepted before an indication is given to the XTI/TLI user. To be able to establish proposed values of options of end-to-end significance before a connection is accepted, the proposed values of options must be set on the transport endpoint upon which the XTI/TLI user is listening with t_listen(3) rather than being responded to at the time that the connection is accepted with t_accept(3). This makes the semantics of these XTI/TLI functions somewhat different than is experienced for ISO/OSI conforming protocols. This characteristic of using XTI/TLI for internet protocols is described in XNS 5.2[1].

Some SCTP options of end-to-end significance should be set before a call to t_listen(3), using t_optmgmt(3), are as follows:

T_SCTP_CKSUM_TYPE
set the type of checksum to be performed on all packets for all connections indicated on this transport endpoint. This option is useful if the listening XTI/TLI user is aware that the connecting transport endpoints only support the older Adler 32 checksum.
T_SCTP_MAC_TYPE
sets the message authentication digest algorithm that will be used when signing cookies that are returned to transport endpoints generating connection indications on this transport endpoint. This option is useful if the listening XTI/TLI user wishes to forego or select the security/performance trade-off associated with the generation of cookies on the transport endpoint.
T_SCTP_COOKIE_LIFE
sets the lifetime of cookies generated by the listening transport endpoint. This also sets the interval of re-keying of message authentication digests. This is useful if the listening transport endpoint is aware of the transit delays associated with forming connections to the listening transport endpoint and wishes to tighten or loosen the security associated with cookie lifetimes and re-keying of message authentication digests.
T_SCTP_COOKIE_INC
sets the cookie increment that will be applied to connecting transport endpoints requesting cookie preservation.
T_SCTP_THROTTLE_ITVL
sets the throttle interval for throttling connection attempts on the listening transport endpoint.

In addition, any of the options described under t_accept(3), above, may be set with t_optmgmt(3) before the call to t_listen(3).

When an incoming connection is indicated, the calling address indicated in the call->addr argument can contain multiple sockaddr_in structures, each representing a multi-homed IP transport address from which the connection is requested. This first address in the list is always the source address of the COOKIE-ECHO packet. Each address in the array will have the same call->addr[i].sin_family and call->addr[i].sin_port fields.

When an incoming connection is indicated, the options indicated in the call->opt argument that are of end-to-end significance are as follows:

T_SCTP_CKSUM_TYPE
indicates the checksum type that was used for the COOKIE-ECHO packet. This value is auto-detected. If this checksum type is unacceptable to the XTI/TLI user, the XTI/TLI user should refuse the connection indication using t_snddis(3), with the indicated sequence number.
T_SCTP_ISTREAMS
indicates the number of incoming streams requested by the peer. If this value is too high, it may be adjusted using this option to the t_accept(3) call. This value cannot be adjusted upward. If the value is too low, the XTI/TLI user should refuse the connection indication using t_snddis(3), with the indicated sequence number.
T_SCTP_OSTREAMS
indicates the maximum number of outgoing streams supported by the peer. If this value is too high, it may be adjusted downward using this option to the t_accept(3) call. This value cannot be adjusted upward. If the value is too low, the XTI/TLI user should refuse the connection indication using t_snddis(3), with the indicated sequence number.
T_SCTP_ECN
indicates whether the peer supports explicit congestion notification. The peer cannot be compelled to use explicit congestion notification. If explicit congestion notification is required but not indicated, it is the XTI/TLI user's responsibility to refuse the transport connection using t_snddis(3) with the indicated sequence number. Whether this transport endpoint supports explicit congestion notification or not can be specified using this option to the t_accept(3) call accepting the connection indication.
T_SCTP_ALI
indicates whether the peer supports adaptation layer information and extension capabilities to the SCTP protocol. If capabilities are required that are not indicated, it is the XTI/TLI user's responsibility to refuse the transport connection using t_snddis(3) with the indicated sequence number. Whether this transport endpoint supports adaptation layer information and which capabilities it supports can be specified using this option to the t_accept(3) call accepting the connection indication.

If the SCTP peer provided connection data bundled with the COOKIE-ECHO, the data will be indicated in the call->udata parameter.

t_look(3)

XTI-SCTP supports this XTI/TLI library call as described in t_open(3) with the additional considerations described here.

As soon as an unordered DATA CHUNK enters the SCTP receive buffer, the event T_EXDATA in indicated. T_EXDATA remains set until all data in the unordered DATA CHUNK has been received.

t_open(3)

XTI-SCTP supports this XTI/TLI library call as described in t_open(3) with the additional considerations described here.

t_open(3) is called as the first step in the initialization of a transport endpoint. This function returns various default characteristics of the underlying transport protocol by setting fields in the t_info structure. The following should be the values returned by the call to t_open(3) and t_getinfo(3) with the SCTP transport provider.


ParametersBefore callAfter call

namex/
oflagx/
info->addr/8 * sizeof(struct sockaddr_in)
info->options/x
info->tsdu/T_INFINITE
info->etsdu/T_INFINITE
info->connect/x
info->discon/T_INVALID
info->servtype/T_COTS_ORD
info->flags/0

The information returned in the info parameter to this XTI/TLI call has the same considerations as the info parameter returned in the call to t_getinfo(3), described above.

t_optmgmt(3)

XTI-SCTP supports this XTI/TLI library call as described in t_optmgmt(3) with the additional considerations described here.

The options that may be set, retrieved or negotiated using this XTI/TLI library call are described under ``OPTIONS'', above.

t_rcvconnect(3)

XTI-SCTP supports this XTI/TLI library call as described in t_rcvconnect(3) with the additional considerations described here.

Since user data cannot be exchanged during the connection establishment phase, call->udata.maxlen must be set to zero (0) before the call to t_rcvconnect(3). On return, the call->addr structure contains the address of the remote calling endpoint.

Multiple addresses.

T_SCTP_HEARTBEAT_ITVL, T_SCTP_RTO_INITIAL, T_SCTP_RTO_MIN, T_SCTP_RTO_MAX, T_SCTP_PATH_MAX_RETRANS, T_SCTP_CKSUM_TYPE, T_SCTP_MAC_TYPE, T_SCTP_COOKIE_LIFE, T_SCTP_COOKIE_INC, T_SCTP_THROTTLE_ITVL, T_SCTP_ISTREAMS, T_SCTP_OSTREAMS, T_SCTP_ECN, T_SCTP_ALI, T_SCTP_MAX_INIT_RETRIES,

t_rcvdis(3)

XTI-SCTP supports this XTI/TLI library call as described in t_rcvdis(3) with the additional considerations described here.

Since data cannot be sent with a disconnect, call->udata.len must be set to zero (0).

XTI-SCTP does not support disconnection data and the dis->udata parameter must always be empty.

dis->reason will either be a negative UNIX® error code, or an SCTP protocol-specific error code as follows:

T_SCTP_CAUSE_INVALID_STR
a DATA chunk was received that contained an invalid stream identifier.
T_SCTP_CAUSE_MISSING_PARM
a control chunk was missing a mandatory parameter.
T_SCTP_CAUSE_STALE_COOKIE
the cookie went stale before a transport connection could be formed.
T_SCTP_CAUSE_NO_RESOURCE
there was insufficient resource to form the transport connection.
T_SCTP_CAUSE_BAD_ADDRESS
a provided destination transport address was invalid.
T_SCTP_CAUSE_BAD_CHUNK_TYPE
an unrecognized chunk type was received.
T_SCTP_CAUSE_INVALID_PARM
an invalid parameter type was received.
T_SCTP_CAUSE_BAD_PARM
a parameter containing an invalid value was received.
T_SCTP_CAUSE_NO_DATA
a DATA chunk was received that contained no data.
T_SCTP_CAUSE_SHUTDOWN
a cookie was received while shutting down.
T_SCTP_CAUSE_NEW_ADDR
restart of an association with a new address.
T_SCTP_CAUSE_USER_INITIATED
user initiated abort.
T_SCTP_CAUSE_PROTO_VIOLATION
protocol violation.
T_SCTP_CAUSE_LAST_ADDR
request to delete last IP address for the transport connection.
T_SCTP_CAUSE_RES_SHORTAGE
operation was refused due to resource shortage.
T_SCTP_CAUSE_SOURCE_ADDR
request to delete a source IP address.
T_SCTP_CAUSE_ILLEGAL_ASCONF
association aborted due to illegal ASCONF-ACK.

For SCTP, a disconnect indication may be received associated with a connection indication before the connection indication is accepted or refused. In this case, dis->sequence will be set appropriately.

dis->reason can also return the following negative error numbers:

[ECONNABORTED]
software related connection abort.
[ECONNRESET]
connection was reset by peer.
[ECONNREFUSED]
connection was refused by the peer.
[ETIMEDOUT]
connection timed out.
[EPROTO]
connection aborted due to protocol error.
[ENETDOWN]
network is down.
[ENETUNREACH]
network is unreachable.
[ENETRESET]
network dropped connection because of reset.
[EHOSTDOWN]
the destination host is down.
[EHOSTUNREACH]
no route to destination host.
[ESHUTDOWN]
COOKIE received while shutting down.

t_rcv(3), t_rcvv(3)

XTI-SCTP supports these XTI/TLI library calls as described in t_rcv(3) and t_rcvv(3), with the additional considerations described here.

When data is received using these XTI/TLI library calls, the flags parameter will have the T_MORE bit set if a subsequent t_rcv(3), t_rcvv(3), read(2) or readv(2) operation will read additional data belonging to the same [E]TSDU. The flags parameter will have the T_EXPEDITED bit set if the data was sent unordered. Because of this, reads using read(2) or readv(2) must be complete TSDU reads of normal (ordered) data.

Data received with these XTI/TLI library calls, or using read(2) or readv(2), will set the T_SCTP_SID, T_SCTP_PPI, T_SCTP_SSN and T_SCTP_TSN to the option values associated with the read data if the T_SCTP_RECVSID and T_SCTP_RECVPPI local options are set for the transport endpoint. These option values must be read using a T_GET operation to t_optmgmt(3) before reading more data belonging to another [E]TSDU.

t_rcvreldata(3)

XTI-SCTP does not support orderly release with data and this XTI/TLI library call will fail, return -1 and set t_errno(3) to a value of [TNOTSUPPORT].

t_rcvrel(3)

XTI-SCTP supports this XTI/TLI library call as described in t_rcvrel(3) without modification. t_rcvrel(3) is preferred over t_snddis(3) for disconnecting an established connection (i.e. a connection in the T_DATAXFER state.

t_rcvudata(3), t_rcvvudata(3)

XTI-SCTP does not support a connection-less mode and these XTI/TLI library calls will fail, return -1 and set t_errno(3) to a value of [TNOTSUPPORT]. For a connection-less mode service, see xti_udp(3).

t_rcvuderr(3)

XTI-SCTP does not support a connection-less mode and these XTI/TLI library calls will fail, return -1 and set t_errno(3) to a value of [TNOTSUPPORT]. For a connection-less mode service, see xti_udp(3).

t_snddis(3)

XTI-SCTP supports this XTI/TLI library call as described in t_snddis(3) with the additional considerations described here.

Since data may not be sent with a disconnect, call->udata.len must be set to zero (0).

XTI-SCTP does not support disconnection from specified responding addresses. Therefore, the call->addr parameter should be empty and will always be ignored. SCTP does not support disconnect data or disconnect options. The parameters call->udata and call->opt must always be empty. XTI-SCTP does support refusal of connection indications, and the call->sequence parameter is populated as described in t_snddis(3).

t_snd(3), t_sndv(3)

XTI-SCTP supports this XTI/TLI library call as described in t_snd(3) and t_sndv(3), with the additional considerations described here.

When data is sent using these XTI/TLI library calls, the flags parameter will have the T_MORE bit set if a subsequent t_snd(3), t_sndv(3), write(2) or writev(2) operation will write additional data belonging to the same [E]TSDU. The flags parameter will have the T_EXPEDITED bit set if the data is to be sent unordered. Because of this, writes using write(2) or writev(2) must be complete TSDU writes of normal (ordered) data.

When data is sent using these XTI/TLI library calls, or using write(2) or writev(2), the values previously set with the T_SCTP_SID and T_SCTP_PPI options will be assigned to the data for transmission. These option values must be written using a T_NEGOTIATE operation to t_optmgmt(3) before writing more data belonging to another [E]TSDU.

t_sndreldata(3)

XTI-SCTP does not support orderly release with data and this XTI/TLI library call will fail, return -1 and set t_errno(3) to a value of [TNOTSUPPORT].

t_sndrel(3)

XTI-SCTP supports this XTI/TLI library call as described in t_sndrel(3) without modification.

t_sndudata(3), t_sndvudata(3)

SCTP does not support a connection-less mode and these XTI/TLI library calls will fail, return -1 and set t_errno(3) to a value of [TNOTSUPPORT]. For a connection-less mode service, see xti_udp(3).

t_unbind(3)

XTI-SCTP supports this XTI/TLI library call as described in t_unbind(3) with the additional considerations described here.

Any local addresses added with the option T_SCTP_ADD_IP, or automatically added by the system with the addition or reconfiguration of a network interface, will also be unbound from the local transport endpoint with this XTI/TLI library call.

BUGS

XTI-SCTP has no known bugs. The INET(4) implementation of XTI-SCTP has been conformance tested and validated using the test-inet_sctp(8) test case executable and the OpenSS7 autotest conformance and validation test suite.

NOTICES

In support of the sockets(3) library for tpi(7) transport providers, the options described here have been made compatible with the socket options described in sctp(7). As a result, depending on the release of INET(4), the XTI/TLI options described might not be compatible with the options described here.

The OpenSS7 socket version of SCTP described in sctp(7), accessed using the TPI interface of the OpenSS7 package described in INET(4), supports all of the options described here.

Earlier version of the INET(4) driver did not support wildcard binds. If an attempt was made to bind to a wildcard address or port number, the bind would fail with [TNOADDR]. While this is correct behavior, it was not consistent with other XTI-TCP implemetnations. Recent versions of the INET(4) driver include the ability to bind to wildcards or to request that the transport service provider asign a suitable address.

Including the <xti.h> header file may include the <xti_inet.h> header file. Including the <xti_inet.h> header file may include the <xti_ip.h> and <xti_sctp.h> header file.

SEE ALSO

INET(4), read(2), readv(2), sctp(4), sctp(7), sockets(3), t_accept(3), t_connect(3), T_CONN_REQ(7), t_errno(3), t_getinfo(3), timod(4), tirdwr(4), t_listen(3), T_OPTDATA_IND(7), t_optmgmt(3), t_rcvconnect(3), t_snddis(3), write(2), writev(2), xnet(3), xti(3), xti_ip(3), xti_udp(3), xti_tcp(3), xti_sctp(3), test-inet_sctp(8).

DEVICES

There are a number of SCTP devices providing the Transport Provider Interface that provide SCTP conforming TPI devices as follows:

/dev/sctp, /dev/inet/sctp

These devices are provided by the The OpenSS7 Project(OpenSS7-0.9.2) package. For more information on the TPI SCTP device, see sctp(4).

COMPATIBILITY

This interface is compatible with XNS 5.2[1], and implementations based on XNS 5.2, with the following portability considerations:

---
Internet Protocol (IP) options were not standardized until XPG4[14].
---
The format of options for the Transport Provider Interface (TPI) differ from those for the AT&T Transport Layer Interface (TLI). This interface follows the TPI.
---
The precise values of some options and formats of primitives may differ from implementation to implementation. Binary compatibility is not guaranteed.

See xti(3), for additional compatibility information.

CONFORMANCE

The OpenGroup XNS Issue 5.2[1]. Conformance is validated using the test-inet_sctp(8) test case executable and the OpenSS7 autotest validation test suite.

HISTORY

The Transport Provider Interface (TPI)[13] was first created by AT&T as the Transport Layer Interface (TLI) and was subsequently standardized by UNIX International and later by The OpenGroup in XPG4[15] and XNS 5.2[1].

The SCTP-TPI driver is specific to the OpenSS7 stack. This is an unofficial Corrigendum to XNS 5.2 Revision 2[1].

REFERENCES

[1]
XNS, Open Group CAE Specification: Technical Standard: Network Services (XNS), Issue 5.2, Draft 2, 1999, (Berkshire, UK), OpenGroup, Open Group Publication. [ISBN 1-85912-241-8] <http://www.opengroup.org/onlinepubs/>
[2]
XTI/TLI Revision 1.0, Open Group CAE Specification: XOpen Transport Interface, Revision 1, n.d., (Berkshire, UK), XPG, X Programmer's Group. <http://www.opengroup.org/onlinepubs/>
[3]
RFC 896, Congestion control in IP/TCP Internetworks, January 6, 1984, J. Nagle, The Internet Society. <http://www.ietf.org/rfc/rfc0896.txt>
[4]
RFC 1122, Requirements for Internet Hosts -- Communication Layers, October 1989, Robert Braden, ed., The Internet Society. <http://www.ietf.org/rfc/rfc1122.txt>
[5]
draft-minshall-nagle-01.txt, A Proposed Modification to Nagle's Algorithm, June 17, 1999, G. Minshall, Internet Engineering Task Force --- Transport Area Working Group. Work In Progress <http://www.ietf.org/internet-drafts/draft-minshall-nagle-01.txt>
[6]
RFC 2960, Stream Control Transmission Protocol (SCTP), October 2000, Randall R. Stewart, ed., The Internet Society. (Obsoleted by RFC 4960) (Updated by RFC 3309) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc2960.txt>
[7]
RFC 3309, Stream Control Transmission Protocol (SCTP) Checksum Change, September 2002, Jonathan Stone, ed., The Internet Society. (Obsoleted by RFC 4960) (Updates RFC 2960) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc3309.txt>
[8]
RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, September 2001, K. K. Ramakrishnan, ed., The Internet Society. (Obsoletes RFC 2481) (Updates RFC 2474, RFC 2401, RFC 793) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc3168.txt>
[9]
draft-ietf-tsvwg-addip-sctp-08.txt, Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, September 24, 2003, Randall R. Stewart, ed., Internet Engineering Task Force - Signalling Transport Working Group. Work In Progress. <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-08.txt>
[10]
RFC 3758, Stream Control Transmission Protocol (SCTP) Partial Reliability Extension, May 2004, Randall R. Stewart, ed., The Internet Society. (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc3758.txt>
[11]
RFC 4460, Stream Control Transmission Protocol (SCTP) Specification Errata and Issues, April 2006, R. Stewart, I. Aria-Rodriguez, K. Poon, A. Caro and M. Tuexen, The Internet Society. (Status: INFORMATIONAL) <http://www.ietf.org/rfc/rfc4460.txt>
[12]
RFC 793/STD 7, Transmission Control Protocol, DARPA Internet Program, Protocol Specification, September 1981, J. Postel, ed., The Internet Society. (Also STD0007) (Updated by RFC 3168) (Status: STANDARD) <http://www.ietf.org/rfc/rfc0793.txt>
[13]
TPI Revision 2.0.0, Open Group CAE Specification: Transport Provider Interface (TPI) Specification, Revision 2.0.0, Draft 2, 1999, (Berkshire, UK), OpenGroup, Open Group Publication. <http://www.opengroup.org/onlinepubs/>
[14]
[15]

TRADEMARKS

OpenSS7tm
is a trademark of OpenSS7 Corporation.
Linux®
is a registered trademark of Linus Torvalds.
UNIX®
is a registered trademark of The Open Group.
Solaris®
is a registered trademark of Sun Microsystems.

Other trademarks are the property of their respective owners.

IDENTIFICATION

The OpenSS7 Project: Package OpenSS7 version 0.9.2 released Wed, 23 Aug 2017 21:18:49 GMT.

Copyright©1997-2008OpenSS7 Corp.
All Rights Reserved.
(See roff source for permission notice.)



Index

NAME
SYNOPSIS
OVERVIEW
DESCRIPTION
ADDRESS FORMAT
OPTIONS
XTI_GENERIC
T_INET_IP
T_INET_SCTP
FUNCTIONS
t_accept(3)
t_bind(3)
t_close(3)
t_connect(3)
t_getinfo(3)
t_listen(3)
t_look(3)
t_open(3)
t_optmgmt(3)
t_rcvconnect(3)
t_rcvdis(3)
t_rcv(3), t_rcvv(3)
t_rcvreldata(3)
t_rcvrel(3)
t_rcvudata(3), t_rcvvudata(3)
t_rcvuderr(3)
t_snddis(3)
t_snd(3), t_sndv(3)
t_sndreldata(3)
t_sndrel(3)
t_sndudata(3), t_sndvudata(3)
t_unbind(3)
BUGS
NOTICES
SEE ALSO
DEVICES
COMPATIBILITY
CONFORMANCE
HISTORY
REFERENCES
TRADEMARKS
IDENTIFICATION

This document was created by man2html, using the manual pages.
Time: 21:18:48 GMT, August 23, 2017
OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> Man Pages -> Manpage of XTI-SCTP
Last modified: Mon, 28 Apr 2008 22:52:05 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.