draft-bidulock-tsvwg-sctptpi-00.me

No7信令,我需要交换类似的代码, 请店长审核,谢谢了,急着交换,谢谢

The size of CDATA (Connection Data) should be set to -1 to indicate that the
provider supports the transfer of data with connect primitives and that there
is no limit on the maximum amount of data sent with the connect primitives.
.ip "\fIDDATA_size\fR"
The size of DDATA (Disconnect Data) should be set to -1 to indicate that the
provider supports the transfer of data with disconnect primitives and that
there is no limit on the maximum amount of data sent with the disconnect
primitives.  (Note: this only really has practical use with orderly release
primitives \fBT_ORDREL_REQ\fR and \fBT_ORDREL_IND\fR.)
.ip "\fIADDR_size\fR"
If the provider has a restriction on the maximum number of IP addresses which
can be provided in an SCTP endpoint address, this size should be set to
reflect that value.  Otherwise, this value should be set to -1 to indicate
that there is no limit on the number of IP addresses which are provided with
any primitive.
.ip "\fIOPT_size\fR"
If the provider has a restriction on the maximum number of options which can
be provided in an operation, this size should be set to reflect that value.
Otherwise, this value should be set to -1 to indicate that there is no limit
on the number of options which are provided with any primitive.
.ip "\fITIDU_size\fR"
This should be set to the system-tunable system limit on the maximum size of a
STREAMS message.  It might be possible to set this value to the current
maximum size of the data in a DATA chunk which will currently fit within the
path MTU, however, the provider cannot reject TIDUs which are larger than this
dynamic value but which are smaller than the value first advertized when the
STREAM was opened.
.ip "\fISERV_type\fR"
This field should be set to \fBT_COTS_ORD\fR to indicate that the SCTP
provider is connection oriented with orderly release support.
.ip "\fICURRENT_state\fR"
This field should be set to the TPI provider state.
.ip "\fIPROVIDER_flag\fR"
This field should NOT have \fBSENDZERO\fR set (because SCTP does not support
the sending of zero-length TSDUs in general) and should have \fBXPG4_1\fR set
to indicate support for XPG4 semantics (\fBT_ADDR_REQ\fR and
\fBT_ADDR_ACK\fR).
.ba -4

.sh 3 "Binding and Listening"
.lp
Once a STREAM is opened the provider places the STREAM in the \fBTS_UNBND\fR
state and the STREAM is available for binding with the \fBT_BIND_REQ\fR
primitive and will be placed in the \fBTS_BIND\fR state.  A STREAM which is in
the \fBTS_BIND\fR state may be unbound again using the \fBT_UNBIND_REQ\fR
primitive and returned to the \fBTS_UNBND\fR state.  Unlike BSD sockets, this
permits a STREAM to be reused for another connection without closing and
reopening another STREAM.
.sh 4 "T_BIND_REQ, T_BIND_ACK"
.lp
STREAMS must be bound to a local protocol address before they can become
involved in a connection and used for data transfer.  The semantics for
binding and unbinding STREAMS are identical to those provided in the Transport
Provider Interface.  The only specifics of the SCTP implementation lie in the
format and interpretation of the transport address.  The \fBT_BIND_REQ\fR
primtive provides an opaque protocol address as indicated by \fIADDR_length\fR
and \fIADDR_offset\fR which in the SCTP implementation has the following
format:
.(l
\fCtypedef struct sctp_addr {
	uint16_t    port;
	uint32_t    addr[0];
} sctp_addr_t;
.)l
Where
.ba +4
.ip "\fIport\fR"
indicates the 16-bit (host order) port number to which to bind; and,
.ip "\fIaddr\fR"
indicates an array of 32-bit IPv4 addresses (host order) to which to bind.
.ba -4
.lp
The transport address will be interpreted according to the following rules by
the SCTP Transport Provider:
.np
If the transport address is not provided (i.e. \fIADDR_length\fR is zero), the
SCTP provider will assign an available port number from the range of port
numbers available to SCTP and will bind the STREAM to any and all IPv4
addresses which are available to the SCTP Transport Provider.
.np
If the transport address is provided, but does not contain any IPv4 addresses,
the SCTP Transport Provider will bind the STREAM to any and all IPv4 addresses
which are available to the SCTP Transport Provider.
.np
If the transport address is provided with the \fIport\fR set to zero, and the
\fICONIND_number\fR is also set to zero, the SCTP TP will assign a port
number.
.np
If the transport address is provided with the \fIport\fR set to zero, and the
\fICONIND_number\fR is non-zero, the SCTP TP will treat the STREAM as a
"default listener."  This \fIdefault listener\fR will receive indications for
any port number on the bound IPv4 addresses which are not otherwise bound.

One and only one STREAM may be bound as a \fIdefault listener\fR to any given
IPv4 address.  If the STREAM is bound as a \fIdefault listener\fR and no IPv4
addresses are provided in the transport address, the STREAM will receive all
SCTP messages to which no other STREAM is bound.
.np
All valid IPv4 addresses may be bound to a SCTP Transport Provider STREAM.
This includes \fIbroadcast\fR and \fImulticast\fR addresses; however, to bind
to a \fIbroadcast\fR or \fImulticast\fR address may require that the STREAM
was opened with sufficient access permissions to allow binding of these
addresses.  \fIBroadcast\fR and \fImulticast\fR addresses will only be used by
the SCTP Transport Provider for establishment of an SCTP association (INIT
chunks) and will not be used for normal transmission or retransmission of
chunks.
.lp
Other than the above rules, the TPI semantics of the \fBT_BIND_REQ\fR and
\fBT_BIND_ACK\fR primitives are preserved, particularly with regards to the
treatment of the \fICONIND_number\fR field.

Considering the SCTP Transport Provider interpretation of the transport
address, the following errors may be returned in a \fBT_ERROR_ACK\fR primitive
in response to a problematic \fBT_BIND_REQ\fR primitive:
.ba +4
.ip "\fBTACCES\fR"
This indicates that the user did not have proper permissions for the use of
the requested address.  This includes the following reasons:
.ba +4
.np
The user attempted to bind to a port number within the UNIX protected port
number range (1-1024) and did not have sufficient priviledge.
.np
The user attempted to bind to a \fIbroadcast\fR or \fImulticast\fR address and
did not have sufficient priviledge.
.np
The user attempted to bind a \fIdefault listener\fR (i.e. to bind to port 0)
and did not have sufficient priviledge.
.ba -4
.ip "\fBTADDRBUSY\fR"
This indicates that the requested address was in use.  This includes the
following reasons:
.ba +4
.lp
.np
The SCTP TP only permits one STREAM to be a "listener" (i.e. with a non-zero
\fICONIND_number\fR) for a given port number IPv4 address combination.

The
\fBT_BIND_REQ\fR will be rejected it the user attempts to bind a second STREAM
with a non-zero \fICONIND_number\fR to the same port number and IPv4 address
combination to which another STREAM is already bound with a non-zero
\fICONIND_number\fR.
.np
The SCTP TP only permits one STREAM to be a "default listener" (i.e. listening
on all ports) for a given IPv4 address.

The \fBT_BIND_REQ\fR will be rejected if the user attempts to bind a second
"default listener" with a zero \fIport\fR number and a non-zero
\fICONIND_number\fR to the same IPv4 address to which another STREAM is
already bound with a zero \fIport\fR number and a non-zero
\fICONIND_number\fR.
.ba -4
.ip "\fBTBADADDR\fR"
This indicates that the protocol address was in an incorrect format or the
address contained invalid information.  It is not intended to indicate
protocol errors.  This may include the following reasons:
.ba +4
.lp
.np
The size of the address as given by \fIADDR_length\fR is not the size of the
\fBsctp_addr\fR structure plus a positive integer number of 4-byte IPv4
addresses.
.np
The format of the \fBsctp_addr\fR structure is correct, but one or more of the
IPv4 addresses provided are not valid IPv4 addresses (e.g. 0.1.1.1 or 0.0.0.0).

(Note: the SCTP TP does not permit binding to address 0.0.0.0)
.ba -4
.ip "\fBTNOADDR\fR"
This indicates that the transport provider could not allocate an address.
This may include the following reasons:
.ba +4
.lp
.np
The user has requested that the SCTP Transport Provider provide a transport
address with \fICONIND_number\fR equal to zero, and the SCTP TP is unable to
assign a port number because all the port numbers within the assignable range
are in use.
.ba -4
.ip "\fBTOUTSTATE\fR"
The primitive would place the transport interface out of state.
.ip "\fBTSYSERR\fR"
A system error occurred and the UNIX system error is indicated in the
primitive.  This may include the following errors:
.ba +4
.ip "\fBENOMEM\fR"
There was insufficient memory resources to complete the operation.
.ip "\fBEFAULT\fR"
A recoverable internal software error has occured.
.ba -4
.ba -4

.sh 4 "T_UNBIND_REQ"
.lp
STREAMS which are in the \fBTS_IDLE\fR state (i.e. those which are not
currently involved in an SCTP association) can be unbound at any time using
the \fBT_UNBIND_REQ\fR primitive.  As provided for the TPI specification, this
primitive permits the unbinding, or reversal of the bind operation.
.lp
There are no SCTP Transport Provider specifics concerning this primitive.
.sh 3 "Options Management"
.sh 4 "T_OPTMGMT_REQ, T_OPTMGMT_ACK"

.sh 2 "STREAM Connection"
.sh 3 "Client"
.sh 4 "T_CONN_REQ, T_CONN_CON, T_DISCON_IND"
.sh 3 "Server"
.sh 4 "T_CONN_IND, T_CONN_REQ, T_DISCON_REQ"

.sh 2 "STREAM Data Transfer"
.sh 3 "Sending Data"
.sh 4 "T_DATA_REQ, T_EXDATA_REQ, T_OPTDATA_REQ"
.sh 3 "Receiving Data"
.sh 4 "T_DATA_IND, T_EXDATA_IND, T_OPTDATA_IND"

.sh 2 "STREAM Release"
.sh 3 "Disconnection"
.sh 4 "T_DISCON_REQ, T_DISCON_IND"
.sh 3 "Orderly Release"
.sh 4 "T_ORDREL_REQ, T_ORDREL_IND"

.sh 1 "Mapping of SCTP states to TPI states"

.(l
.(c
\fC+----------------+---------------------------------+
|   TPI State    |            SCTP State           |
+----------------+---------------------------------+
| TS_UNBND       | SCTP_CLOSED                     |
| TS_WACK_BREQ   | SCTP_CLOSED                     |
| TS_WACK_UREQ   | SCTP_CLOSED or SCTP_LISTEN      |
| TS_IDLE        | SCTP_CLOSED or SCTP_LISTEN      |
| TS_WACK_OPTREQ | SCTP_CLOSED or SCTP_LISTEN      |
| TS_WACK_CREQ   | SCTP_COOKIE_WAIT                |
|                | SCTP_COOKIE_ECHOED              |
| TS_WCON_CREQ   | SCTP_COOKIE_WAIT                |
|                | SCTP_COOKIE_ECHOED              |
| TS_WRES_CIND   | SCTP_LISTEN                     |
| TS_WACK_CRES   | SCTP_ESTABLISHED                |
| TS_DATA_XFER   | SCTP_ESTABLISHED                |
| TS_WIND_ORDREL | SCTP_SHUTDOWN_PENDING           |
|                | SCTP_SHUTDOWN_SENT              |
| TS_WREQ_ORDREL | SCTP_SHUTDOWN_RECEIVED          |
| TS_WACK_DREQ6  | SCTP_CLOSED or SCTP_LISTEN      |
| TS_WACK_DREQ7  | SCTP_LISTEN                     |
| TS_WACK_DREQ9  | SCTP_ESTABLISHED                |
| TS_WACK_DREQ10 | SCTP_SHUTDOWN_PENDING           |
|                | SCTP_SHUTDOWN_SENT              |
| TS_WACK_DREQ11 | SCTP_SHUTDOWN_RECEIVED          |
| TS_NOSTATES    | SCTP_UNREACHABLE                |
+----------------+---------------------------------+
.)c
.ce 2
\fBFigure 3.\fR  Mapping of SCTP States
to TPI States

.sh 1 "Use of XTI with SCTP protocol"
.sh 2 "Introduction"
.lp
This section describes the protocol-specific information that is relevant for
SCTP transport providers.  It also defines data structures and constants
required for SCTP transport providers which are exposed through the
<xti_sctp.h> header file.
.sh 2 "Protocol Features"
.ip "\fIT_MORE Flag and TSDUs\fR"
The notion of TSDU is supported by SCTP transport provider, so the T_MORE flag
is interpreted correctly by the SCTP transport provider.
.ip "\fIExpedited Data\fR"
SCTP does not have a notion of expedited data in a sense comparable to ISO
expedited data.  SCTP defines an out-of-order delivery mechanism which can
be implemented similar to TCP's urgent mechanism, by which DATA chunks which
are marked for out-of-order delivery could be transmitted in advance of normal
in-order deliver DATA chunks on a given stream.  See the SCTP Draft Standard
for more detailed information.
.ip "\fIOrderly Release\fR"
The orderly release functions \fBt_sndrel()\fR and \fBt_rcvrel()\fR which were
defined to support the orderly release facility of TCP will also be used for
the orderly release facility of SCTP.  The specification states that only
established connections may be closed with orderly release: that is, on an
endpoint in T_DATAXFER or T_INREL state.
.ip "\fIAbortive Release\fR"
Functions \fBt_sdnddis()\fR and \fBt_rcvdis()\fR may be used to perform
abortive release over SCTP transport.  However, their use is not recommended
as the abortive release primitive (ABORT chunk) is not transmitted reliably by
the SCTP protocol.
.ip "\fIConnection Establishment\fR"
Unlike TCP, SCTP partially allows the possibility of refusing a connection
indication.  This is peformed by sending an ABORT chunk instead of a
COOKIE-ACK chunk in response to a COOKIE-ECHO.  Therfore, unlike TCP,
\fBt_listen()\fR and \fBt_accept()\fR have similar semantics to that for ISO
providers.
.ip "\fIConnection Release\fR"
After a connection has been released, the local address(es) bound to the