[ Previous |
AIX Version 4.3 Communications Technical Reference, Volume 1
Requests that the data link service (DLS) provider bind a data link service
access point (DLSAP) to a stream.
The message consists of one M_PROTO message block, which contains the
This structure is defined in /usr/include/sys/dlpi.h.
A stream is active when the DLS provider can transmit and receive protocol data
units destined to or originating from the stream. The physical point of attachment (PPA) associated with each
stream must be initialized when the DL_BIND_REQ primitive has been processed.The PPA is initialized when
the DL_BIND_ACK primitive is received. If the PPA cannot be initialized, the DL_BIND_REQ primitive
|| Specifies the DL_BIND_REQ primitive.|
|| Identifies the DLSAP to be bound to the Data Link Provider Interface (DLPI) stream. This parameter can
contain either the full DLSAP address or a portion of the address sufficient to uniquely identify the DLSAP. The
DL_BIND_ACK primitive returns the full address of the bound DLSAP. The dl_sap parameter is a ulong
containing and ethertype for DL_ETHER, or a single byte SAP for 802.2 networks.
The DLS provider adheres to the following rules when it binds a DLSAP address:
- The DLS provider must define and manage its DLSAP address space.
- The DLS provider allows the same DLSAP to be bound to multiple streams.
The DLS provider may not be able to bind the specified DLSAP address for the
- The DLS provider statically associated a specific DLSAP with each stream.
The value of the dl_sap parameter is ignored by the DLS provider and the DL_BIND_ACK primitive
returns the DLSAP address that is already associated with the stream.
Note: Because of the provider-specific nature of the DLSAP
address, protocol-independent DLS user software should not have this value hard-coded. The DLS user should
retrieve the necessary DLSAP address from the appropriate header file for that protocol and insert it without
inspection into the DL_BIND_REQ primitive.
|| Specifies the maximum number of outstanding DL_CONNECT_IND primitives allowed on the DLPI stream.
This field controls whether a connection-oriented stream will accept incoming connection indications. This
parameter can have one of the following values:
|| The stream cannot accept any DL_CONNECT_IND primitives.|
|| The DLS user accepts the specified number of DL_CONNECT_IND primitives before having to respond
with a DL_CONNECT_RES or DL_DISCONNECT_REQ primitive.|
The DLS provider may not be able to support the value supplied in the
dl_max_conind parameter for the following reasons:
- If the provider cannot support the specified number of outstanding connect
indications, it should set the value down to a number it can support.
- Only one stream that is bound to the indicated DLSAP can have an allowed number
of maximum outstanding connect indications greater than 0. If a DL_BIND_REQ primitive specifies a value
greater than 0, but another stream has already bound itself to the DLSAP with a value greater than 0, the request
fails. The DLS provider then sets the dl_errno parameter of the DL_ERROR_ACK primitive to a value
- A connection cannot be accepted on a stream bound with a
greater than zero.
No other streams in which the value of the dl_max_conind parameter is greater than 0 can be bound to the
same DLSAP. This restriction prevents more than one stream bound to the same DLSAP from receiving connect
indications and accepting connections.
- A DLS user should always be able to request a dl_max_conind parameter
value of 0, since this indicates to the DLS provider that the stream will only be used to originate connect
- A stream in which the dl_max_conind parameter has a negotiated value
greater than 0 cannot originate connect requests.
Note: This field is ignored in connectionless-mode service.
|| Specifies the following modes of service for this stream:
|| Selects the connection-oriented only mode. The connection primitives will be accepted. In addition, an
arbitrary number of streams may bind to the same dl_sap on the same interface, as long as
dl_max_conind is zero. No incoming datagram traffic will be sent up this stream. Such frames will either
be routed to a DL_CLDLS stream, or silently discarded.|
|| Selects the connectionless only mode. The connection primitives will not be accepted. This mode
selects exclusive control of connectionless traffic. All datagrams (DL_UNITDATA_IND) from any remote
station addressed to this dl_sap will be received on this stream, even if another stream is currently
connected on the same dl_sap. Only one stream per interface may bind DL_CLDS.|
|| Selects the connection-oriented service augmented with conectionless traffic. An arbitrary number of
streams may bind to the same dl_sap on the same interface. This mode is mutually exclusive with
If the DLS provider does not support the requested service mode, a
DL_ERROR_ACK primitive is generated. This primitive conveys a value of DL_UNSUPPORTED.
|| This field is ignored.|
|| Indicates to the DLS provider that XID or test responses for this stream are to be automatically
generated by the DLS provider. The xidtest_flg parameter contains a bit mask that can specify either,
both, or neither of the following values:
|| Indicates to the DLS provider that automatic responses to XID commands are to be generated.|
|| Indicates to the DLS provider that automatic responses to test commands are to be generated.|
|| Indicates to the DLS provider that automatic responses to both XID commands and test commands are to
The DLS provider supports automatic handling of XID and test responses. If an
automatic XID or test response has been requested, the DLS provider does not generate DL_XID_IND or
DL_TEST_IND primitives. Therefore, if the provider receives an XID request (DL_XID_REQ) or test
request (DL_TEST_REQ) from the DLS user, the DLS provider returns a DL_ERROR_ACK primitive,
specifying a DL_XIDAUTO or DL_TESTAUTO error code, respectively.
If no value is specified in the dl_xidtest_flg parameter, the DLS provider
does not automatically generate XID and test responses.
The value informs the DLS provider that the DLS user will be handling all XID and
TEST traffic. A nonzero value indicates the DLS provider is responsible for either XID or TEST traffic or both.
If the driver handles XID or TEST, the DLS user will not receive any incoming XID or TEST frames, nor be allowed
to send them.
|| The primitive is valid in the DL_UNBOUND state.|
|| The resulting state is DL_BIND_PENDING.|
|| The DL_BIND_ACK primitive is sent to the DLS user. The resulting state is DL_IDLE.|
|| The DL_ERROR_ACK primitive is returned. The resulting state is unchanged.|
|| Indicates the DLS user does not have proper permission to use the requested DLSAP address.|
|| Indicates the DLSAP address information is invalid or is in an incorrect format.|
|| Indicates the DLS user attempted to bind a second stream to a DLSAP with a dl_max_conind parameter
value greater than 0, or the DLS user attempted to bind a second connection management stream to the PPA.|
|| Indicates the automatic initialization of the PPA failed.|
|| Indicates the DLS provider cannot allocate a DLSAP address for this stream.|
|| Indicates automatic handling of XID and test responses is not supported.|
|| Indicates the PPA was not initialized prior to this request.|
|| Indicates automatic handling of test responses is not supported.|
|| Indicates automatic handling of XID responses is not supported.|
|| Indicates the primitive was issued from an invalid state.|
|| Indicates a system error occurred. The system error is indicated in the DL_ERROR_ACK
|| Indicates the DLS provider does not support the requested service mode on this stream. |
This primitive is part of Base Operating System (BOS) Runtime.
primitive, DL_ERROR_ACK primitive.
[ Previous |