SVR5 and SCO OpenServer 5

Intro(D7dlpi)

Intro -- introduction to Data Link Provider Interface message formats

Synopsis

#include <sys/types.h>
#include <sys/scodlpi.h> /* Extensions to DLPI 2.0 in   */
#include <sys/sr.h>      /* OpenServer 5 and UnixWare 7 */

Description

This manual page defines the message formats used by DLPI service primitives in SCO OpenServer 5 (TM)

and UnixWare^® 7.

The following table summarizes the DLPI 2.0 and SCO value-added message formats that are supported in SVR5 Release 2.1 (UW2.1), SCO OpenServer 5 (OSR5), and SVR5 (UW7).

Message format support by release

Primitive DLPI 2.0 UW2.1 OSR5 UW7

DL_ATTACH_REQ Y -- -- --

DL_BIND_ACK Y Y Y! Y!

DL_BIND_REQ Y Y Y! Y!

DL_CLR_SR_REQ -- -- Y Y

DL_CLR_STATISTICS_REQ -- -- Y Y

DL_CONNECT_CON Y -- -- --

DL_CONNECT_IND Y -- -- --

DL_CONNECT_REQ Y IC -- --

DL_CONNECT_RES Y -- -- --

DL_DATA_ACK_REQ Y -- -- --

DL_DATA_ACK_IND Y -- -- --

DL_DATA_ACK_STATUS_IND Y -- -- --

DL_DATA_IND Y -- -- --

DL_DATA_REQ Y -- -- --

DL_DETACH_REQ Y -- -- --

Primitive	DLPI 2.0	UW2.1	OSR5	UW7
DL_ATTACH_REQ	Y	--	--	--
DL_BIND_ACK	Y	Y	Y!	Y!
DL_BIND_REQ	Y	Y	Y!	Y!
DL_CLR_SR_REQ	--	--	Y	Y
DL_CLR_STATISTICS_REQ	--	--	Y	Y
DL_CONNECT_CON	Y	--	--	--
DL_CONNECT_IND	Y	--	--	--
DL_CONNECT_REQ	Y	IC	--	--
DL_CONNECT_RES	Y	--	--	--
DL_DATA_ACK_REQ	Y	--	--	--
DL_DATA_ACK_IND	Y	--	--	--
DL_DATA_ACK_STATUS_IND	Y	--	--	--
DL_DATA_IND	Y	--	--	--
DL_DATA_REQ	Y	--	--	--
DL_DETACH_REQ	Y	--	--	--

DL_DISABALLMULTI_REQ -- -- -- Y

DL_DISABMULTI_REQ Y I Y Y

DL_DISCONNECT_IND Y -- -- --

DL_DISCONNECT_REQ Y IC -- --

DL_DLPI_BILOOPMODE -- -- Y Y

DL_ENABALLMULTI_REQ -- -- -- Y

DL_ENABMULTI_REQ Y I Y! Y!

DL_ERROR_ACK Y Y Y Y

DL_GET_STATISTICS_ACK Y -- Y! Y!

DL_GET_STATISTICS_REQ Y -- Y Y

DL_INFO_ACK Y Y Y! Y!

DL_INFO_REQ Y Y Y Y

DL_ISDN_MSG -- -- -- Y

DL_MCTABLE_ACK -- -- Y Y

DL_MCTABLE_REQ -- -- Y Y

DL_OK_ACK Y Y Y Y

DL_PHYS_ADDR_ACK Y I Y Y

DL_PHYS_ADDR_REQ Y I Y! Y!

DL_PROMISCOFF_REQ Y I -- --

DL_PROMISCON_REQ Y I -- --

DL_REPLY_REQ Y -- -- --

DL_REPLY_IND Y -- -- --

DL_REPLY_STATUS_IND Y -- -- --

DL_REPLY_UPDATE_REQ Y -- -- --

DL_REPLY_UPDATE_STATUS_IND Y -- -- --

DL_RESET_CON Y -- -- --

DL_RESET_IND Y -- -- --

DL_RESET_REQ Y -- -- --

DL_RESET_RES Y -- -- --

DL_SAP_STATISTICS_ACK -- -- Y Y

DL_SAP_STATISTICS_REQ -- -- Y Y

DL_SET_PHYS_ADDR_REQ Y I -- Y

DL_SET_SRMODE_REQ -- -- Y Y

DL_SET_SRPARMS_REQ -- -- Y Y

DL_SRTABLE_ACK -- -- Y Y

DL_SRTABLE_REQ -- -- Y Y

DL_SUBS_BIND_ACK Y Y Y Y

DL_SUBS_BIND_REQ Y Y Y! Y!

DL_SUBS_UNBIND_REQ Y Y Y Y

DL_TEST_CON Y Y Y! Y!

DL_TEST_IND Y Y Y! Y!

DL_TEST_REQ Y Y Y! Y!

DL_TEST_RES Y -- Y! Y!

DL_TOKEN_ACK Y -- -- --

DL_TOKEN_REQ Y -- -- --

DL_UDERROR_IND Y Y Y Y

DL_UDQOS_REQ Y -- -- --

DL_UNBIND_REQ Y Y Y Y

DL_UNITDATA_IND Y Y Y! Y!

DL_UNITDATA_REQ Y Y Y! Y!

DL_XID_CON Y -- Y! Y!

DL_XID_IND Y -- Y! Y!

DL_XID_REQ Y C Y! Y!

DL_XID_RES Y C Y! Y!

The symbols have the following meaning:

``--'': The message format is not supported. If displayed for DLPI, the message format is SCO value-added if supported in other columns.
``C'': The message format is only supported by the Token-Ring driver (cet) in SCO UnixWare Release 2.1.
``I'': The message format is only supported by an ioctl call in SCO UnixWare Release 2.1. Typically, requests are supported by the ioctl call, acknowledgments are supported by the data that the call returns.
``L'': The message format is only supported by the Ethernet driver (lsl) in SCO UnixWare Release 2.1.
``Y'': The message format is supported.
``Y!'': The message format is supported but there are caveats with regard to its usage when compared with what is specified in DLPI 2.0.

DLPI in both SCO OpenServer 5 and SVR5 do not support the following features defined in the DLPI 2.0 specification:

acknowledged connectionless LLC
connection-oriented LLC
quality of service

UnixWare 2.1 ioctl command equivalents

The ioctl commands that provided DLPI 2.0 functionality in SVR5 Release 2.1 are not supported in SCO OpenServer 5 and SVR5. The following table shows the DLPI (both DLPI 2.0 and SCO added value) primitives and MDI ioctl commands that provide equivalent functionality.

UnixWare 2.1 ioctl DLPI primitives or MDI ioctl commands Description

DLIOCADDMULTI DL_ENABMULTI_REQ Add multicast address

DLIOCCSMACDMODE Not supported Switch SAP type to RAW

DLIOCDELMULTI DL_DISABMULTI_REQ Delete multicast address

DLIOCDISABLE Not supported Disable controller -- nearest equivalent is DL_UNBIND_REQ

DLIOCENABLE Not supported Enable controller -- nearest equivalent is DL_BIND_REQ

UnixWare 2.1 ioctl	DLPI primitives or MDI ioctl commands	Description
DLIOCADDMULTI	DL_ENABMULTI_REQ	Add multicast address
DLIOCCSMACDMODE	Not supported	Switch SAP type to RAW
DLIOCDELMULTI	DL_DISABMULTI_REQ	Delete multicast address
DLIOCDISABLE	Not supported	Disable controller -- nearest equivalent is DL_UNBIND_REQ
DLIOCENABLE	Not supported	Enable controller -- nearest equivalent is DL_BIND_REQ

DLIOCGENADDR DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK Return Ethernet (MAC) address

DLIOCGETMULTI DL_MCTABLE_REQ, DL_MCTABLE_ACK Return list of multicast addresses

DLIOCGLPCFLG Not supported Get local copy packet flag (send local packets on wire)

DLIOCGMIB DL_GET_STATISTICS_REQ, DL_GET_STATISTICS_ACK Get MIB statistics (DL_mib_t)

DLIOCGPROMISC Not supported Get promiscuous mode flag

DLIOCLLC2MODE Not supported Toggle LLC2 mode (Token-Ring adapters)

DLIOCRAWMODE Not supported Toggle RAW mode (Token-Ring adapters)

DLIOCRESET Not supported Reset controller -- nearest equivalent is to close and open driver

DLIOCSENADDR DL_SET_PHYS_ADDR_REQ

DLIOCSLPCFLG Not supported Set local copy packet flag (send local packets on wire)

DLIOCSMIB DL_CLR_STATISTICS_REQ, MACIOC_SETSTAT Set MIB statistics (DL_mib_t)

DLIOCSPROMISC MACIOC_PROMISC Set promiscuous mode flag

DLGADDR DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK Return Ethernet (MAC) address

DLGBROAD Not supported Get broadcast address

DLSLLC2 Not supported Toggle LLC2 mode (Token-Ring adapters)

DLSRAW Not supported Toggle RAW mode (Token-Ring adapters)

MACIOC_GETADDR DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK Return Ethernet (MAC) address

SIOCGIFDEBUG Not supported Get debug level

SIOCGIFFLAGS Not supported Socket I/O control to get interface flags (acknowledged and ignored)

DL_BIND_ACK

The DL_BIND_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_sap;
   	ulong		dl_addr_length;
   	ulong		dl_addr_offset;
   	ulong		dl_max_conind;
   	ulong		dl_xidtest_flg;
   } dl_bind_ack_t;

DL_BIND_ACK reports the successful bind of a data link service access point (DLSAP) to a stream, and returns the bound DLSAP address to the DLS user. This primitive is generated in response to a DL_BIND_REQ.

The members of the structure are:

dl_primitive

Conveys DL_BIND_ACK.

dl_sap

The DLSAP address information associated with the bound DLSAP. It corresponds to the dl_sap member of the associated DL_BIND_REQ, which contains either part or all of the DLSAP address. For that portion of the DLSAP address conveyed in the DL_BIND_REQ, this member contains the corresponding portion of the address for the DLSAP that was actually bound.

dl_addr_length

The length of the complete DLSAP address that was bound to the DLPI stream. The bound DLSAP is chosen according to the guidelines presented under the description of DL_BIND_REQ.

dl_addr_offset

The offset from the beginning of the M_PCPROTO block where the DLSAP address begins.

dl_max_conind

The allowed, maximum number of outstanding DL_CONNECT_IND messages to be supported on the DLPI stream. If the value is zero, the stream cannot accept any DL_CONNECT_IND messages. If greater than zero, the DLS user will accept DL_CONNECT_IND messages up to the given value before having to respond with a DL_CONNECT_RES or a DL_DISCONNECT_REQ. The rules for negotiating this value are presented under the description of DL_BIND_REQ.

NOTE: This member must be set to 0.

dl_xidtest_flg

The XID and TEST responses supported by the provider.

DL_AUTO_XID: XID response handled automatically.
DL_AUTO_TEST: TEST response handled automatically.

If no value is specified in dl_xidtest_flg, it indicates that automatic handling of XID and TEST responses is not supported by the provider.

The message is valid in state DL_BIND_PENDING. The resulting state is DL_IDLE.

This message's category is Local Management.

DL_BIND_REQ

The DL_BIND_REQ message consists of one M_PROTO message block, which contains the following structure.

   typedef struct {
   	ulong          dl_primitive;
   	ulong          dl_sap;
   	ulong          dl_max_conind;
   	ushort         dl_service_mode;
   	ushort         dl_conn_mgmt;
   	ulong          dl_xidtest_flg;
   } dl_bind_req_t;

DL_BIND_REQ requests the DLS provider to bind a DLSAP to the stream. The DLS user must identify the address of the DLSAP to be bound to the stream. For connection-mode service, the DLS user also indicates whether it will accept incoming connection requests on the stream. Finally, the request directs the DLS provider to activate the stream associated with the DLSAP.

A stream is viewed as active when the DLS provider may 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 on completion of the processing of the DL_BIND_REQ. More specifically, the DLS user is ensured that the PPA is initialized when the DL_BIND_ACK is received. If the PPA cannot be initialized, the DL_BIND_REQ will fail.

A stream may be bound as a connection management stream, such that it will receive all connect requests that arrive through a given PPA. In this example, the DLSAP address will be ignored.

The members of the structure are:

dl_primitive

Conveys DL_BIND_REQ.

dl_sap

Supplies sufficient information to identify the DLSAP that will be bound to the DLPI stream. The format of this information is specific to a given DLS provider, and may contain the full DLSAP address or some portion of that address sufficient to uniquely identify the DLSAP in question. The full address of the bound DLSAP will be returned in the DL_BIND_ACK.

The following rules are used by the DLS provider when binding a DLSAP address.

The DLS provider must define and manage its DLSAP address space.
DLPI allows the same DLSAP to be bound to multiple streams, but a given DLS provider may need to restrict its address space to allow one stream per DLSAP.
NOTE: The SCO implementation of DLPI allows only one stream per DLSAP.
The DLS provider may not be able to bind the specified DLSAP address for the following reasons:
- the DLS provider may statically associate a specific DLSAP with each stream; or
- the DLS provider may only support one stream per DLSAP and the DLS user attempted to bind a DLSAP that was already bound to another stream.

In the first item, the value of dl_sap is ignored by the DLS provider and the DL_BIND_ACK returns the DLSAP address that is already associated with the stream. In the second item, if the DLS provider cannot bind the given DLSAP to the stream, it may attempt to choose an alternate DLSAP and return that on the DL_BIND_ACK. If an alternate DLSAP cannot be chosen, the DLS provider will return a DL_ERROR_ACK and set dl_errno to DL_NOADDR.

Because of the provider-specific nature of the DLSAP address, DLS user software that is to be protocol independent should avoid hard-coding this value. The DLS user should retrieve the necessary DLSAP address from some other entity (such as a management entity or higher layer protocol entity) and insert it without inspection into the DL_BIND_REQ.

NOTE: Many data framing formats are supported so dl_sap must specify which is to be used.

dl_max_conind

The maximum number of outstanding DL_CONNECT_IND messages allowed on the DLPI stream. If the value is zero, the stream cannot accept any DL_CONNECT_IND messages. If greater than zero, the DLS user will accept DL_CONNECT_IND messages up to the given value before having to respond with a DL_CONNECT_RES or a DL_DISCONNECT_REQ. The DLS provider may not be able to support the value supplied in dl_max_conind, as specified by the following rules.

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 may have an allowed number of maximum outstanding connect indications greater than zero. If a DL_BIND_REQ specifies a value greater than zero, but another stream has already bound itself to the DLSAP with a value greater than zero, the DLS provider will fail the request, setting dl_errno to DL_BOUND on the DL_ERROR_ACK.
If a stream with dl_max_conind greater than zero is used to accept a connection, the stream will be found busy during the duration of the connection, and no other streams may be bound to the same DLSAP with a value of dl_max_conind greater than zero. This restriction prevents more than one stream bound to the same DLSAP from receiving connect indications and accepting connections. Accepting a connection on such a stream is only allowed if there is just a single outstanding connect indication being processed.
A DLS user should always be able to request a dl_max_conind value of zero, since this indicates to the DLS provider that the stream will only be used to originate connect requests.
A stream with a negotiated value of dl_max_conind that is greater than zero may not originate connect requests. This member is ignored in connectionless-mode service.

NOTE: This member must be set to 0.

dl_service_mode

The desired mode of service for this stream, and may contain one of the following:

DL_CODLS: connection-oriented data link service
DL_CLDLS: connectionless data link service
DL_ACLDLS: acknowledged connectionless data link service.

If the DLS provider does not support the requested service mode, a DL_ERROR_ACK will be generated, specifying DL_UNSUPPORTED.

NOTE: This member is only valid for IEEE 802.2 data framing formats. It may take one of the following values:

0: The DLPI module will not generate or strip any IEEE 802.2 headers.
DL_CLDLS: The DLPI module will provide LLC-1 framing for connectionless data link service.

dl_conn_mgmt

If non-zero, indicates that the stream is the connection management stream for the PPA to which the stream is attached. When an incoming connect request arrives, the DLS provider will first look for a stream bound with dl_max_conind greater than zero that is associated with the destination DLSAP. If such a stream is found, the connect indication will be issued on that stream. Otherwise, the DLS provider will issue the connect indication on the connection management stream for that PPA, if one exists. Only one connection management stream is allowed per PPA, so an attempt to bind a second connection management stream on a PPA will fail with the DLPI error set to DL_BOUND. When dl_conn_mgmt is non-zero, the value of dl_sap will be ignored. In connectionless-mode service, dl_conn_mgmt is ignored by the DLS provider.

NOTE: This member must be set to 0.

dl_xidtest_flg

Indicates to the DLS provider that XID and/or TEST responses for this stream are to be automatically generated by the DLS provider. The DLS provider will not generate DL_XID_IND and/or DL_TEST_IND, and will error a DL_XID_REQ and/or DL_TEST_REQ. If the DLS provider does not support automatic handling of XID and/or TEST responses, a DL_ERROR_ACK will be generated, specifying DL_NOAUTO, DL_NOXIDAUTO or DL_NOTESTAUTO. If the Provider receives an XID or TEST request from the DLS user, a DL_ERROR_ACK will be generated specifying DL_XIDAUTO or DL_TESTAUTO respectively.

The dl_xidtest_flg contains a bit-mask specifying zero or more of the following values:

DL_AUTO_XID: Automatically respond to XID commands.
DL_AUTO_TEST: Automatically respond to TEST commands.

The message is valid in state DL_UNBOUND. The resulting state is DL_BIND_PENDING.

If the bind request is successful, DL_BIND_ACK is sent to the DLS user resulting in state DL_IDLE.

If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged. The following are reasons for failure:

DL_BADADDR: The DLSAP address information was invalid or was in an incorrect format.
DL_INITFAILED: Automatic initialization of the PPA failed.
DL_NOTINIT: The PPA had not been initialized before this request.
DL_ACCESS: The DLS user did not have proper permission to use the requested DLSAP address.
DL_BOUND: The DLS user attempted to bind a second stream to a DLSAP with dl_max_conind greater than zero, or the DLS user attempted to bind a second connection management stream to a PPA.
DL_OUTSTATE: The primitive was issued from an invalid state.
DL_NOADDR: The DLS provider could not allocate a DLSAP address for this stream.
DL_UNSUPPORTED: The DLS provider does not support requested service mode on this stream.
DL_SYSERR: A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.
DL_NOAUTO: Automatic handling of XID and TEST responses not supported.
DL_NOXIDAUTO: Automatic of XID response not supported.
DL_NOTESTAUTO: Automatic of TEST response not supported.

This message's category is Local Management.

DL_CLR_SR_REQ

The DL_CLR_SR_REQ message consists of one M_PROTO message block containing the structure shown below.

   typedef struct {
   	ulong	dl_primitive;
   } dl_clr_sr_req_t;

This message requests that the DLS provider delete all source routing table entries.

The members of the structure are:

dl_primitive: Conveys DL_CLR_SR_REQ.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to this request with DL_OK_ACK if the request is successful. Otherwise, DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.

DL_CLR_STATISTICS_REQ

The DL_CLR_STATISTICS_REQ message consists of one M_PROTO message block containing the structure shown below.

   typedef struct {
   	ulong dl_primitive;
   } dl_clr_statistics_req_t;

This message requests that the DLS provider reset all statistics counters such that the next DL_GET_STATISTICS_REQ returns the activity for the period between the issuing of DL_CLR_STATISTICS_REQ and DL_GET_STATISTICS_REQ.

The members of the structure are:

dl_primitive: Conveys DL_CLR_STATISTICS_REQ.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to this request with DL_OK_ACK if the request is successful. Otherwise, DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.

DL_DISABALLMULTI_REQ

The DL_DISABALLMULTI_REQ message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
       ulong   dl_primitive;
   } dl_disaballmulti_req_t;

DL_DISABALLMULTI_REQ requests the DLS provider to disable all multicast addresses on a per stream basis.

The members of the structure are:

dl_primitive: Conveys DL_DISABMULTI_REQ.

This message is valid in any state in which a local acknowledgement is not pending with the exception of DL_UNATTACH. The resulting state is unchanged.

If the disable request is successful, a DL_OK_ACK is sent to the DLS user. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_OUTSTATE: The primitive was issued from an invalid state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management.

DL_DISABMULTI_REQ

The DL_DISABMULTI_REQ message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_addr_length;
   	ulong dl_addr_offset;
   } dl_disabmulti_req_t;

DL_DISABMULTI_REQ requests the DLS provider to disable specific multicast addresses on a per stream basis.

The members of the structure are:

dl_primitive: Conveys DL_DISABMULTI_REQ.
dl_addr_length: The length of the physical address.
dl_addr_offset: The offset from the beginning of the M_PROTO message block where the multicast address begins.

This message is valid in any state in which a local acknowledgement is not pending with the exception of DL_UNATTACH. The resulting state is unchanged.

If the disable request is successful, a DL_OK_ACK is sent to the DLS user. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_NOTENAB: Address specified is not enabled.
DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.
DL_OUTSTATE: The primitive was issued from an invalid state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management.

DL_DLPI_BILOOPMODE

The DL_DLPI_BILOOPMODE message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
           ulong   dl_primitive;
           ulong   dl_biloopmode;
   } dl_set_biloopmode_req_t;

DL_DLPI_BILOOPMODE is a special primitive which is used for testing. You must define dlpi_frame_test in order to use it.

DL_ENABALLMULTI_REQ

The DL_ENABALLMULTI_REQ message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
       ulong   dl_primitive;
   } dl_enaballmulti_req_t;

DL_ENABALLMULTI_REQ requests the DLS provider to enable all multicast addresses on a per stream basis. It is invalid for a DLS provider to pass upstream messages that are destined for any address other than those explicitly enabled on that stream by the DLS user.

The members of the structure are:

dl_primitive: Conveys DL_ENABALLMULTI_REQ.

This message is valid in any state in which a local acknowledgement is not pending with the exception of DL_UNATTACH. The resulting state is unchanged.

If the enable request is successful, a DL_OK_ACK is sent to the DLS user. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management.

DL_ENABMULTI_REQ

The DL_ENABMULTI_REQ message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_addr_length;
   	ulong dl_addr_offset;
   } dl_enabmulti_req_t;

DL_ENABMULTI_REQ requests the DLS provider to enable specific multicast addresses on a per stream basis. It is invalid for a DLS provider to pass upstream messages that are destined for any address other than those explicitly enabled on that stream by the DLS user.

The members of the structure are:

dl_primitive: Conveys DL_ENABMULTI_REQ.
dl_addr_length: The length of the multicast address.
dl_addr_offset: The offset from the beginning of the M_PROTO message block where the multicast address begins.

This message is valid in any state in which a local acknowledgement is not pending with the exception of DL_UNATTACH. The resulting state is unchanged.

If the enable request is successful, a DL_OK_ACK is sent to the DLS user. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management.

NOTE: A multicast address enabled using DL_ENABMULTI_REQ is not cleared when the DLS provider is closed. It persists until a DL_DISABMULTI_REQ is issued for the address.

DL_ERROR_ACK

The DL_ERROR_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_error_primitive;
   	ulong		dl_errno;
   	ulong		dl_unix_errno;
   } dl_error_ack_t;

DL_ERROR_ACK informs the DLS user that a previously issued request or response was invalid. It conveys the identity of the primitive in error, a DLPI error code, and if appropriate, a UNIX system error code.

Whenever this primitive is generated, it indicates that the DLPI state is identical to what it was before the erroneous request or response.

The members of the structure are:

dl_primitive

Conveys DL_ERROR_ACK.

dl_error_prim

Identifies the primitive in error.

dl_errno

The DLPI error code associated with the failure. See the individual request or response for the error codes that are applicable. In addition to those errors:

A DL_BADPRIM error is returned if an unrecognized primitive is issued by the DLS user.
A DL_NOTSUPPORTED error is returned if an unsupported primitive is issued by the DLS user.

dl_unix_errno

The UNIX system error code associated with the failure. This value should be non-zero only when dl_errno is set to DL_SYSERR. It is used to report UNIX system failures that prevent the processing of a given request or response.

The message is valid in every state where an acknowledgement or confirmation of a previous request or response is pending. The resulting state is that from which the acknowledged request or response was generated.

This message's category is Local Management.

DL_GET_STATISTICS_ACK

The DL_GET_STATISTICS_ACK message consists of one M_PCPROTO message block containing the structure shown below:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_stat_length;
   	ulong 	dl_stat_offset;
   } dl_get_statistics_ack_t;

DL_GET_STATISTICS_ACK returns statistics in response to the DL_GET_STATISTICS_REQ.

The members of the structure are:

dl_primitive

Conveys DL_GET_STATISTICS_ACK.

dl_stat_length

The length of the statistics structure.

NOTE: This only refers to the size of the media-independent structure (sizeof(dlpi_stats)).

dl_stat_offset

The offset from the beginning of the M_PCROTO message block where the statistics information resides.

The message is valid in any state in which a local acknowledgement is not pending. The resulting state is unchanged.

This message's category is Local Management -- Optional.

NOTE: DLPI 2.0 does not define the form of the statistics structure that is returned. The SCO implementation returns a media-independent structure (dlpi_stats) and a media-dependent structure. These structures are returned in two STREAMS messages chained to the DL_GET_STATISTICS_ACK by the b_cont member. The size and contents of the media-dependent structures are defined in the Section D4mdi manual pages in Section D4mdi manual pages.

The dlpi_stats structure is defined as follows:

struct dlpi_stats {
        /* DLPI module info */
        ulong   dl_nsaps;               /* #SAPs currently bound to DLPI */
        ulong   dl_maxsaps;             /* Max. #SAPs usable */
        ulong   dl_rxunbound;           /* #frames received not delivered */
        /* Source Routing info */
        ulong   dl_nroutes;             /* #Source Routes currently in use */
        ulong   dl_maxroutes;           /* Max #Source Routes usable */
        /* MAC Driver info */
        ulong   mac_driver_version;
        ulong   mac_media_type;         /* Ethernet/T-R/FDDI */
        ulong   mac_max_sdu;            /* SDU MAX at MDI layer */
        ulong   mac_min_sdu;            /* SDU MIN at MDI layer */
        ulong   mac_addr_length;        /* ADDR SIZE at MDI layer */
        ulong   mac_stats_len;          /* Size of h/w dep. stats struct */
        ulong   mac_ifspeed;            /* Speed of interface in bits/sec */
        struct  mac_counters mac_tx;    /* Data collected for sends */
        struct  mac_counters mac_rx;    /* Data collected for receives */
	/* UnixWare 7 only */
        ulong   mac_suspended;          /* is ddi8 driver suspended? */
        ulong   mac_suspenddrops;       /* # of data frames dropped that
                                         * were sent from stack while driver
                                         * was suspended */
        ulong   mac_reserved[6];        /* reserved */
};

The members of this structure are:

dl_nsaps

The number of SAPs currently bound to the DLPI provider. This approximates the number of protocol stacks that are currently using DLPI.

dl_maxsaps

The maximum number of times that the DLPI provider can be bound to by SAPs.

dl_rxunbound

The number of received frames that have not been delivered because no suitable protocol stack to process them was bound to the DLPI provider.

dl_nroutes

The number of source route table entries currently in use. If autorouting is in use, this approximates to the number of stations with which the local machine is communicating across bridges.

dl_maxroutes

The maximum number of source route table entries.

mac_driver_version

The version number of the MDI driver.

mac_media_type

The media type in use by the MDI driver. This is usually, but not necessarily, the same as the value of the dl_mac_type member returned by DL_INFO_ACK.

mac_max_sdu

The maximum SDU that the MDI driver will accept. This will be slightly larger than the value of the dl_max_sdu member in DL_INFO_ACK because MAC layer headers are added to the data sent by the DLPI user.

mac_min_sdu

The minimum SDU that the MDI driver will accept. This may not be the same as the value of the dl_min_sdu member in DL_INFO_ACK.

mac_addr_length

The MAC address size. This is 6 octets for CSMA/CD, Token-Passing Ring and FDDI.

mac_stats_len

The size of the media-dependent statistics structure.

mac_ifspeed

The speed of the MAC interface in bits per second.

mac_tx

mac_rx

Counters of the number of frames and octets of data that have been transmitted/received by the MDI driver. The mac_counters structure is defined as follows:

struct mac_counters {
        ulong   mac_bcast;
        ulong   mac_mcast;
        ulong   mac_ucast;
        ulong   mac_error;
        ulong   mac_octets;
        ulong   mac_queue_len;
};

The members of the structure are:

mac_bcast

The number of broadcast frames that have been transmitted/received.

mac_mcast

The number of multicast frames that have been transmitted/received.

NOTE: DL_ENABMULTI_REQ must be used to register the multicast address before multicast frames can be transmitted or received.

mac_ucast

The number of unicast frames that have been transmitted/received.

mac_error

The number of frames that caused an error of some kind. Further details of the nature of the errors is obtainable from the media-dependent data structure.

mac_octets

The number of octets that have been transmitted/received by the MAC layer.

mac_queue_len

The number of STREAMS messages that are on the send/receive queues between DLPI and the MDI driver.

The following members of dlpi_stats apply only to SVR5:

mac_suspended: Whether the DDI 8 driver is suspended.
mac_suspenddrops: Number of data frames that have been dropped having been sent from the stack while the driver was suspended.
mac_reserved: Reserved for future use.

DL_GET_STATISTICS_REQ

The DL_GET_STATISTICS_REQ message consists of one M_PROTO message block containing the structure shown below:

   typedef struct {
   	ulong 	dl_primitive;
   } dl_get_statistics_req_t;

DL_GET_STATISTICS_REQ directs the DLS provider to return statistics.

The members of the structure are:

dl_primitive: Conveys DL_GET_STATISTICS_REQ.

The message is valid in any state in which a local acknowledgement is not pending. The resulting state is unchanged.

The DLS provider responds to this request with a DL_GET_STATISTICS_ACK if the primitive is supported. Otherwise, a DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known but not supported by the DLS provider.

This message's category is Local Management -- Optional.

DL_INFO_ACK

The DL_INFO_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_max_sdu;
   	ulong		dl_min_sdu;
   	ulong		dl_addr_length;
   	ulong		dl_mac_type;
   	ulong		dl_reserved;
   	ulong		dl_current_state;
   	long		dl_sap_length;
   	ulong		dl_service_mode;
   	ulong		dl_qos_length;
   	ulong		dl_qos_offset;
   	ulong		dl_qos_range_length;
   	ulong		dl_qos_range_offset;
   	ulong		dl_provider_style;
   	ulong		dl_addr_offset;
   	ulong		dl_version;
   	ulong		dl_brdcst_addr_length;
   	ulong		dl_brdcst_addr_offset;
   	ulong		dl_growth;
   } dl_info_ack_t;

The DL_INFO_ACK message is sent in response to DL_INFO_REQ; it conveys information about the DLPI stream to the DLS user.

The members of the structure are:

dl_primitive

Conveys DL_INFO_ACK.

dl_max_sdu

The maximum number of bytes that may be transmitted in a DLSDU. This value must be a positive integer that is greater than or equal to the value of dl_min_sdu.

NOTE: The actual value of this member depends on the data framing format being used. Stack-generated IEEE 802.2 data framing will be assumed until the DLPI user issues a DL_BIND_REQ.

dl_min_sdu

The minimum number of bytes that may be transmitted in a DLSDU. The value is never less than one.

dl_addr_length

The length, in bytes, of the provider's DLSAP address. In the case of a hierarchical subsequent bind, the length returned is the total length, that is, Physical address + SAP + subsequent address length.

NOTE: This member does not account for the possibility that the address may contain source routing information.

dl_mac_type

The type of medium supported by this DLPI stream. Possible values include:

DL_CSMACD: Carrier Sense Multiple Access with Collision Detection (ISO 8802/3)
DL_TPB: Token-Passing Bus (ISO 8802/4)
DL_TPR: Token-Passing Ring (ISO 8802/5)
DL_METRO: Metro Net (ISO 8802/6)
DL_ETHER: Ethernet Bus
DL_HDLC: Bit synchronous communication line
DL_CHAR: Character synchronous communication line (such as BISYNC)
DL_CTCA: Channel-to-channel adapter
DL_FDDI: Fiber Distributed Data Interface (FDDI)
DL_OTHER: Any other medium not listed above

NOTE: Only DL_CSMACD, DL_TPR, and DL_FDDI are supported.

dl_reserved

A reserved member whose value must be set to zero.

dl_current_state

The state of the DLPI interface for the stream when the DLS provider issued this acknowledgement.

dl_sap_length

Indicates the current length of the SAP component of the DLSAP address. It may have a negative, zero or positive value. A positive value indicates the ordering of the SAP and PHYSICAL component within the DLSAP address as SAP component followed by PHYSICAL component. A negative value indicates PHYSICAL followed by the SAP. A zero value indicates that no SAP has yet been bound. The absolute value of the dl_sap_length provides the length of the SAP component within the DLSAP address.

dl_service_mode

If returned before the DL_BIND_REQ is processed, this conveys which service modes (connection-mode, connectionless-mode or acknowledged connectionless-mode, or any combination of these modes) the DLS provider can support. It contains a bit-mask specifying one or more than one of the following values:

DL_CODLS: connection-oriented data link service
DL_CLDLS: connectionless data link service
DL_ACLDLS: acknowledged connectionless data link service

Once a specific service mode has been bound to the stream, this member returns that specific service mode.

NOTE: Only DL_CLDLS is returned.

dl_qos_length

The length, in bytes, of the negotiated/selected values of the quality of service (QOS) parameters. For connection-mode service, the returned values are those agreed during negotiation. For connectionless-mode service, the values are those currently selected by the DLS user. If quality of service has not yet been negotiated, default values will be returned; these values correspond to those that will be applied by the DLS provider on a connect request in connection-mode service, or those that will be applied to each data unit transmission in connectionless-mode service. If the DLS provider supports both connection-mode and connectionless-mode services but the DLS user has not yet bound a specific service mode, the DLS provider may return either connection-mode or connectionless-mode QOS parameter values.

For any parameter the DLS provider does not support or cannot determine, the corresponding entry will be set to DL_UNKNOWN. If the DLS provider does not support any QOS parameters, this length member will be set to zero.

NOTE: Always returns 0 (QOS not supported).

dl_qos_offset

The offset (from the beginning of the M_PCPROTO block) where the current quality of service parameters begin.

dl_qos_range_length

The length, in bytes, of the available range of QOS parameter values supported by the DLS provider. For connection-mode service, this is the range available to the calling DLS user in a connect request. For connectionless-mode, this is the range available for each data unit transmission. If the DLS provider supports both connection-mode and connectionless-mode services but the DLS user has not yet bound a specific service mode, the DLS provider may return either connection-mode or connectionless-mode QOS parameter values.

dl_qos_range_offset

The offset (from the beginning of the M_PCPROTO block) where the available range of quality of service parameters begins.

dl_provider_style

The style of DLS provider associated with the DLPI stream. The following provider classes are defined:

DL_STYLE1: The PPA is implicitly attached to the DLPI stream by opening the appropriate major/minor device number.
DL_STYLE2: The DLS user must explicitly attach a PPA to the DLPI stream using DL_ATTACH_REQ.

DLS users implemented in a protocol-independent manner must access this parameter to determine whether the DLS attach service must be invoked explicitly.

NOTE: Always returns DL_STYLE1.

dl_addr_offset

The offset of the address that is bound to the associated stream. If the DLS user issues a DL_INFO_REQ prior to binding a DLSAP, the value of dl_addr_len will be 0 and consequently indicate that there has been no address bound.

dl_version

Indicates the current DLPI version that is supported.

dl_brdcst_addr_length

Indicates the length of the physical broadcast address.

dl_brdcst_addr_offset

Indicates the offset of the physical broadcast address from the beginning of the M_PCPROTO block.

dl_growth

A growth member for future use. The value of this member will be zero.

The message is valid in any state in response to a DL_INFO_REQ. The resulting state is unchanged.

This message's category is Local Management.

See Intro(D7dlpi) for the range of available QOS values conveyed in these structures.

DL_INFO_REQ

The DL_INFO_REQ message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   } dl_info_req_t;

DL_INFO_REQ requests information of the DLS provider about the DLPI stream. This information includes a set of provider-specific parameters, as well as the current state of the interface.

The members of the structure are:

dl_primitive: Conveys DL_INFO_REQ.

The message is valid in any state in which a local acknowledgement is not pending. The resulting state is unchanged.

The DLS provider responds to the information request with a DL_INFO_ACK.

This message's category is Local Management.

DL_ISDN_MSG

The DL_ISDN_MSG message is the ISDN media primitive. For more information, see isdn_msg_hdr(D4isdn).

DL_MCTABLE_ACK

The DL_MCTABLE_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
           ulong   dl_primitive;
           ulong   dl_mctable_len;
           ulong   dl_mctable_offset;
   } dl_mctable_ack_t;

DL_MCTABLE_ACK is generated by the DLS provider in response to a DL_MCTABLE_REQ message.

The members of the structure are:

dl_primitive: Conveys DL_MCTABLE_REQ.
dl_mctable_len: The length of returned multicast address table (an array of MAC addresses). The number of multicast addresses in the table may be found by dividing dl_mctable_len by the size of a MAC address (MAC_ADDR_SZ).
dl_mctable_offset: The offset in bytes of the start of the multicast address table from the beginning of the DL_MCTABLE_ACK message.

DL_MCTABLE_REQ

The DL_MCTABLE_REQ message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
           ulong           dl_primitive;
   } dl_mctable_req_t;

DL_MCTABLE_REQ requests that the DLS provider return a DL_MCTABLE_ACK containing a table of all currently registered multicast addresses.

The members of the structure are:

dl_primitive: Conveys DL_MCTABLE_REQ.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to this request with DL_MCTABLE_ACK if the request is successful. Otherwise, DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.

DL_OK_ACK

The DL_OK_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_correct_primitive;
   } dl_ok_ack_t;

DL_OK_ACK acknowledges to the DLS user that a previously issued request primitive was received successfully. It is only initiated for those primitives that require a positive acknowledgement.

The members of the structure are:

dl_primitive: Conveys DL_OK_ACK.
dl_correct_primitive: identifies the successfully received primitive that is being acknowledged.

The message is valid in response to a DL_CLR_SR_REQ, DL_CLR_STATISTICS_REQ, DL_DISABALLMULTI_REQ, DL_DISABMULTI_REQ, DL_ENABALLMULTI_REQ, DL_ENABMULTI_REQ, DL_SET_PHYS_ADDR_REQ, DL_SET_SRMODE_REQ, DL_SET_SRPARMS_REQ, DL_SUBS_UNBIND_REQ, or DL_UNBIND_REQ request. The resulting state depends on the current state.

This message's category is Local Management.

DL_PHYS_ADDR_ACK

The DL_PHYS_ADDR_ACK message consists of one M_PCPROTO message block containing the structure shown below:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_addr_length;
   	ulong dl_addr_offset;
   } dl_phys_addr_ack_t;

DL_PHYS_ADDR_ACK returns the value for the physical address to the link user in response to a DL_PHYS_ADDR_REQ.

The members of the structure are:

dl_primitive: Conveys DL_PHYS_ADDR_ACK
dl_addr_length: The length of the physical address.
dl_addr_offset: The offset from the beginning of the M_PCPROTO message block.

The message is valid in any state in response to a DL_PHYS_ADDR_REQ. The resulting state is unchanged.

This message's category is Local Management -- Optional.

DL_PHYS_ADDR_REQ

The DL_PHYS_ADDR_REQ message consists of one M_PROTO message block containing the structure shown below:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_addr_type;
   } dl_phys_addr_req_t;

DL_PHYS_ADDR_REQ requests the DLS provider to return either the default (factory) or the current value of the physical address associated with the stream depending upon the value of the address type selected in the request.

The members of the structure are:

dl_primitive

Conveys DL_PHYS_ADDR_REQ.

dl_addr_type

The type of address requested:

DL_FACT_PHYS_ADDR: factory physical address
DL_CURR_PHYS_ADDR: current physical address

The message is valid in any attached state in which a local acknowledgement is not pending.

For a Style 2 provider, this would be after a PPA is attached using the DL_ATTACH_REQ.
For a Style 1 provider, the PPA is implicitly attached after the stream is opened.

The resulting state is unchanged.

The provider responds to the request with a DL_PHYS_ADDR_ACK if the request is supported. Otherwise, a DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.
DL_OUTSTATE: The primitive was issued from an invalid state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management -- Optional.

DL_SAP_STATISTICS_ACK

The DL_SAP_STATISTICS_ACK message consists of one M_PROTO message block containing the structure shown below:

   typedef struct {
           ulong dl_primitive;
           ulong dl_sapstats_len;
           ulong dl_sapstats_offset;
   } dl_sap_statistics_ack_t;

This message returns statistics in response to DL_SAP_STATISTICS_REQ.

The members of the structure are:

dl_primitive: Conveys DL_SAP_STATISTICS_REQ.
dl_sapstats_len: The offset from the beginning of the M_PROTO message block.
dl_sapstats_offset: The length of the requested statistics.

This message is valid in any state. The resulting state is unchanged.

The following structure is returned:

   dlpi_sapstats {
           ulong   dl_saptype;
           ulong   dl_sap;
           char    dl_user[DL_USER_SZ];
           ulong   dl_llcmode;
           struct  dlpi_counters dl_tx;
           struct  dlpi_counters dl_rx;
           ulong   dl_srmode;
   };

The members of this structure have the following meanings:

dl_saptype

dl_llcmode

Taken together, these members show the data framing format in use:

dl_saptype dl_llcmode Data framing format

FR_ETHER_II LLC_OFF Ethernet II

FR_XNS LLC_OFF XNS

FR_LLC LLC_1 IEEE 802.2

FR_LLC LLC_OFF Stack-generated IEEE 802.2

FR_SNAP LLC_SNAP SNAP

dl_sap

dl_saptype	dl_llcmode	Data framing format
FR_ETHER_II	LLC_OFF	Ethernet II
FR_XNS	LLC_OFF	XNS
FR_LLC	LLC_1	IEEE 802.2
FR_LLC	LLC_OFF	Stack-generated IEEE 802.2
FR_SNAP	LLC_SNAP	SNAP

The SAP in use on the network. This depends on the value in dl_saptype as follows:

dl_saptype dl_sap description

FR_ETHER_II Ethernet

FR_XNS Always 0

FR_LLC LLC DSAP

FR_SNAP SNAP

dl_user

dl_saptype	dl_sap description
FR_ETHER_II	Ethernet
FR_XNS	Always 0
FR_LLC	LLC DSAP
FR_SNAP	SNAP

The name of the STREAMS module using the SAP. This is obtained from the STREAMS module_info structure.

dl_tx

dl_rx

Statistics containing information anout the number of frames and octets that have been transmitted on (dl_tx) or received by (dl_rx) the SAP. The structure used is shown below:

struct dlpi_counters {
        ulong   dl_bcast;
        ulong   dl_mcast;
        ulong   dl_ucast_xid;
        ulong   dl_ucast_test;
        ulong   dl_ucast;
        ulong   dl_error;
        ulong   dl_octets;
        ulong   dl_queue_len;
};

The members of this structure are:

dl_bcast

The number of broadcast frames that have been sent/received by the SAP.

dl_mcast

The number of multicast frames that have been sent/received by the SAP.

dl_ucast_xid

The number of LLC XID frames that have been sent/received by the SAP.

dl_ucast_test

The number of LLC TEST frames that have been sent/received by the SAP.

dl_ucast

The number of unicast frames that have been sent/received by the SAP.

dl_error

The number of frames sent/received by the SAP that caused an error for one of the following reasons:

STREAMS allocb failure
Attempting to send XID or TEST frames when not using IEEE 802.2 data framing format
Using the wrong size destination address when sending frames
Attempting to send XID or TEST frames which are being handled by the DLS provider

dl_octets

The number of octets that have been sent/received.

dl_queue_len

The length of the STREAMS queues between the network protocol stack and the DLS provider.

dl_srmode

The source routing in use on the SAP:

dl_srmode Description

SR_NON No source routing

SR_STACK Source routing being processed in protocol stack

SR_AUTO Source routing being processed in DLPI module

dl_srmode	Description
SR_NON	No source routing
SR_STACK	Source routing being processed in protocol stack
SR_AUTO	Source routing being processed in DLPI module

DL_SAP_STATISTICS_REQ

The DL_SAP_STATISTICS_REQ message consists of one M_PROTO message block containing the structure shown below:

   typedef struct {
   	ulong dl_primitive;
   } dl_sap_statistics_req_t;

This message requests that the DLS provider return statistics about each stream.

The members of the structure are:

dl_primitive: Conveys DL_SAP_STATISTICS_REQ.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to this request with DL_SAP_STATISTICS_ACK if the request is successful. Otherwise, DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_NOTSUPPORTED: Primitive is known, but not supported by the DLS provider.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

DL_SET_PHYS_ADDR_REQ

The DL_SET_PHYS_ADDR_REQ message consists of one M_PROTO message block containing the structure shown below:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_addr_length;
   	ulong dl_addr_offset;
   } dl_set_phys_addr_req_t;

DL_SET_PHYS_ADDR_REQ sets the physical address value for all streams for that provider for a particular PPA.

The members of the structure are:

dl_primitive: Conveys DL_SET_PHYS_ADDR_REQ.
dl_addr_length: The length of the requested hardware address.
dl_addr_offset: The offset from the beginning of the M_PROTO message block.

The message is valid in any attached state in which a local acknowledgement is not pending.

For a Style 2 provider, this would be after a PPA is attached using the DL_ATTACH_REQ.
For a Style 1 provider, the PPA is implicitly attached after the stream is opened.

The resulting state is unchanged

The provider responds to the request with a DL_OK_ACK on successful completion. Otherwise, a DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_BUSY: One or more streams for that particular PPA are in the DL_BOUND state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management -- Optional.

DL_SET_SRMODE_REQ

The DL_SET_SRMODE_REQ message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
           ulong   dl_primitive;
           ulong   dl_srmode;
   } dl_set_srmode_req_t;

This message directs the DLS provider to perform one of several different algorithms to process source routing.

The members of the structure are:

dl_primitive

Conveys DL_SET_SRMODE_REQ.

dl_srmode

The source routing mode being used on the SAP:

SR_NON: no source routing
SR_STACK: source routing being processed in the protocol stack
SR_AUTO: source routing being processed in the DLPI module

The message is valid in state DL_UNBOUND. The resulting state is unchanged.

The DLS provider responds to the request with a DL_OK_ACK on successful completion. Otherwise, a DL_ERROR_ACK is returned.

The following are reasons for failure:

DL_BADPRIM: The value of dl_srmode is not legal.
DL_NOTSUPPORTED: Source routing is not supported on this media type.
DL_OUTSTATE: The state is not DL_UNBOUND.

DL_SET_SRPARMS_REQ

The DL_SET_SRPARMS_REQ message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
           ulong   dl_primitive;
           ulong   dl_parms_len;
           ulong   dl_parms_offset;
   } dl_set_srparms_req_t;

This message directs the DLS provider to perform one of several different algorithms to process source routing.

The members of the structure are:

dl_primitive

Conveys DL_SET_SRPARMS_REQ.

dl_parms_len

The length of the parameter structure which is defined as follows:

struct route_param {
        int tx_resp;
        int rx_ARE;
        int rx_STE_bcs;
        int rx_STE_ucs;
        int max_tx;
        int min_tx;
        int tx_recur;
        int ARE_disa;
};

The members of this structure are:

tx_resp: The time in ticks of the transmit response timer.
rx_ARE: The time in ticks of the ARE receive timer.
rx_STE_bcs: The maximum ARP monitor value at which the route entry is invalidated.
rx_STE_ucs: The maximum STE unicast monitor value at which the route entry is invalidated.
max_tx: The upper time limit in ticks of the frame transmit monitor.
min_tx: The lower time limit in ticks of the frame transmit monitor.
tx_recur: The maximum number of frame transmissions which may occur within the dl_min_tx and dl_max_tx timing window.
ARE_disa: Whether the sending of ARE frames is disabled or not.

dl_parms_offset

The offset of the parameter structure within the DL_SET_SRPARMS_REQ message.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to the request with a DL_OK_ACK on successful completion. Otherwise, a DL_ERROR_ACK is returned.

DL_SRTABLE_ACK

The DL_SRTABLE_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
           ulong   dl_primitive;
           ulong   dl_srtable_len;
           time_t  dl_time_now;
           ulong   dl_route_table_sz;
           ulong   dl_routes_in_use;
           int     dl_tx_resp;
           int     dl_rx_ARE;
           int     dl_rx_STE_bcs;
           int     dl_rx_STE_ucs;
           int     dl_max_tx;
           int     dl_min_tx;
           int     dl_tx_recur;
           int     dl_ARE_disa;
   } dl_srtable_ack_t;

This message is generated by the DLS provider in response to a DL_SRTABLE_REQ. It conveys source routing statistics and information in addition to the source routing table itself. The information returned in this message is only useful if one or more DLS users are using the SR_AUTO source routing mode.

The members of the structure are:

dl_primitive: Conveys DL_SRTABLE_ACK.
dl_srtable_len: The length of the source routing table.
dl_time_now: The lbolt value that programs can use to calculate how long it will take the timer on an entry in the source route table to expire.
dl_route_table_sz: The maximum number of entries in the source route table. This value is determined at kernel link-time by a variable in the DLPI module's space.h file. The default value is 1024 entries.
dl_routes_in_use: The number of source route entries currently in use.
dl_tx_resp: The time in ticks since an STE broadcast or multicast frame was last received.
dl_rx_ARE: The time in ticks since an ARE frame was last received.
dl_rx_STE_bcs: The number of STE broadcast frames that must be received or frames that must be transmitted before a route entry will be invalidated.
dl_rx_STE_ucs: The number of STE unicast frames that must be received before a route entry will be invalidated.
dl_max_tx: The upper time limit in ticks since the last frame was transmitted.
dl_min_tx: The lower time limit in ticks since the last frame was transmitted.
dl_tx_recur: The number of frame transitions that have occurred within the dl_min_tx and dl_max_tx timing window.
dl_ARE_disa: Whether the sending of ARE frames is disabled or not.

The source routing table is an array of sr_table_entry structures. This structure is defined as follows:

   struct sr_table_entry {
           unchar  sr_remote_mac[MAC_ADDR_SZ];
           unchar  sr_state;
           unchar  sr_route_len;
           time_t  sr_timeout;
           ulong   sr_max_pdu;
           ushort  sr_route[SR_ROUTE_SZ];
   };

The members of this structure are:

sr_remote_mac: The remote MAC address.
sr_state: The state of the state machine.
sr_route_len: The number of valid hops to sr_remote_mac in sr_route.
sr_timeout: The time at the next timeout.
sr_max_pdu: The maximum PDU size allowed to sr_remote_mac.
sr_route: The best route to sr_remote_mac.

DL_SRTABLE_REQ

The DL_SRTABLE_REQ message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong          dl_primitive;
   } dl_srtable_req_t;

DL_SRTABLE_REQ requests that the DLS provider return a DL_SRTABLE_ACK message containing the entire source routing table.

The members of the structure are:

dl_primitive: Conveys DL_SRTABLE_REQ.

This message is valid in any state. The resulting state is unchanged.

The DLS provider responds to the request with a DL_SRTABLE_ACK if the request is known. Otherwise, a DL_ERROR_ACK is returned.

DL_SUBS_BIND_ACK

The DL_SUBS_BIND_ACK message consists of one M_PCPROTO message block, which contains the following structure.

   typedef struct {
   	ulong          dl_primitive;
   	ulong          dl_subs_sap_offset;
   	ulong          dl_subs_sap_len;
   } dl_subs_bind_ack_t;

DL_SUBS_BIND_ACK reports the successful bind of a subsequent DLSAP to a stream, and returns the bound DLSAP address to the DLS user. This primitive is generated in response to a DL_BIND_REQ.

The members of the structure are:

dl_primitive: Conveys DL_SUBS_BIND_ACK.
dl_subs_sap_offset: The offset of the DLSAP from the beginning of the M_PROTO block.
dl_subs_sap_len: The length of the specified DLSAP.

The message is valid in state DL_SUBS_BIND_PND The resulting state is DL_IDLE.

This message's category is Local Management.

DL_SUBS_BIND_REQ

The DL_SUBS_BIND_REQ message consists of one M_PROTO message block, which contains the following structure.

   typedef struct {
   	ulong          dl_primitive;
   	ulong          dl_subs_sap_offset;
   	ulong          dl_subs_sap_len;
   } dl_subs_bind_req_t;

DL_SUBS_BIND_REQ requests the DLS provider bind a subsequent DLSAP to the stream. The DLS user must identify the address of the subsequent DLSAP to be bound to the stream.

The members of the structure are:

dl_primitive

Conveys DL_SUBS_BIND_REQ.

dl_subs_sap_offset

The offset of the DLSAP from the beginning of the M_PROTO block.

dl_subs_sap_len

The length of the specified DLSAP.

NOTE: The size of the DLSAP depends on the data framing format being used.

The message is valid in state DL_IDLE. The resulting state is DL_SUBS_BIND_PND.

If the subsequent bind request is successful, DL_SUBS_BIND_ACK is sent to the DLS user resulting in state DL_IDLE.

If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_BADADDR: The DLSAP address information was invalid or was in an incorrect format.
DL_OUTSTATE: The primitive was issued from an invalid state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.

This message's category is Local Management.

DL_SUBS_UNBIND_REQ

The DL_SUBS_UNBIND_REQ message consists of one M_PROTO message block, which contains the following structure:

   typedef struct {
   	ulong          dl_primitive;
   	ulong          dl_subs_sap_offset;
   	ulong          dl_subs_sap_length;
   } dl_subs_unbind_req_t;

DL_SUBS_UNBIND_REQ requests the DLS provider to unbind the DLSAP that had been bound by a previous DL_SUBS_BIND_REQ from this stream.

The members of the structure are:

dl_primitive: Conveys DL_SUBS_UNBIND_REQ.
dl_subs_sap_offset: The offset of the DLSAP from the beginning of the M_PROTO block.
dl_subs_sap_length: The length of the specified DLSAP.

The message is valid in state DL_IDLE. The resulting state is DL_SUBS_UNBIND_PND.

If the unbind request is successful, a DL_OK_ACK is sent to the DLS user. The resulting state is DL_IDLE. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

The following are reasons for failure:

DL_BADADDR: The DLSAP address information was invalid or was in an incorrect format.

This message's category is Local Management.

DL_TEST_CON

The DL_TEST_CON message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   	ulong	dl_src_addr_length;
   	ulong	dl_src_addr_offset;
   } dl_test_con_t;

DL_TEST_CON conveys the TEST response DLSDU from the DLS provider to the DLS user in response to a DL_TEST_REQ.

The members of the structure are:

dl_primitive

Conveys DL_TEST_CON

dl_flag

Indicates the flag values for the request as follows:

DL_POLL_FINAL: whether the poll/final bit is set

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_src_addr_length

The length of the source DLSAP address. If the source user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_src_addr_offset

The offset from the beginning of the M_PROTO message block where the source DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

This message's category is TEST.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_TEST_IND

The DL_TEST_IND message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   	ulong 	dl_src_addr_length;
   	ulong 	dl_src_addr_offset;
   } dl_test_ind_t;

DL_TEST_IND conveys the TEST response/indication DLSDU from the DLS provider to the DLS user.

The members of the structure are:

dl_primitive

Conveys DL_TEST_IND

dl_flag

Indicates the flag values associated with the received TEST frame:

DL_POLL_FINAL: Indicates if the poll/final bit is set.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

Conveys the offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_src_addr_length

Conveys the length of the source DLSAP address. If the source user is implemented using DLPI, this address if the full DLSAP address returned on the DL_BIND_ACK.

dl_src_addr_offset

Conveys the offset from the beginning of the M_PROTO message block where the source DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

This message's category is TEST.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_TEST_REQ

The DL_TEST_REQ message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   } dl_test_req_t;

DL_TEST_REQ conveys one TEST command DLSDU from the DLS user to the DLS provider for transmission to a peer DLS provider.

The members of the structure are:

dl_primitive

Conveys DL_TEST_REQ

dl_flag

Indicates flag values for the request as follows:

DL_POLL_FINAL: Indicates if the poll/final bit is set.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

On an invalid TEST command request, a DL_ERROR_ACK is issued to the user. If the DLS provider receives a response from the remote side, a DL_TEST_CON is issued to the DLS user. It is recommended that the DLS user use a timeout procedure to recover from a situation when there is no response from the peer DLS user.

The following are reasons for failure:

DL_BADADDR: The DLSAP address information was invalid or was in an incorrect format.
DL_NOTSUPPORTED: Requested service not supplied by provider.
DL_OUTSTATE: The primitive was issued from an invalid state
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.
DL_TESTAUTO: Previous bind request specified automatic handling of TEST responses.

This message's category is TEST.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_TEST_RES

The DL_TEST_RES message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   } dl_test_res_t;

DL_TEST_RES conveys the TEST response DLSDU from the DLS user to the DLS provider in response to a DL_TEST_IND.

The members of the structure are:

dl_primitive

Conveys DL_TEST_RES.

dl_flag

Indicates the flag values for the response as follows:

DL_POLL_FINAL: whether the poll/final bit is set

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

This message's category is TEST.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_UDERROR_IND

The DL_UDERROR_IND message consists of either one M_PROTO message block or one M_PCPROTO message block containing the structure shown below.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_dest_addr_length;
   	ulong		dl_dest_addr_offset;
   	ulong		dl_unix_errno;
   	ulong		dl_errno;
   } dl_uderror_ind_t;

DL_UDERROR_IND informs the DLS user that a previously sent DL_UNITDATA_REQ produced an error or could not be delivered. The primitive indicates the destination DLSAP address associated with the failed request, and conveys an error value that specifies the reason for failure.

The members of the structure are:

dl_primitive: Conveys DL_UDERROR_IND.
dl_dest_addr_length: The length of the DLSAP address of the destination DLS user.
dl_dest_addr_offset: The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.
dl_unix_errno: The UNIX system error code associated with the failure. This value should be non-zero only when dl_errno is set to DL_SYSERR. It is used to report UNIX system failures that prevent the processing of the given request.
dl_errno: The DLPI error code associated with the failure. In addition, the error value DL_UNDELIVERABLE may be returned if the request was valid but for some reason the DLS provider could not deliver the data unit, for example, because of lack of sufficient local buffering to store the data unit. There is, however, no guarantee that such an error report will be generated for all undeliverable data units, since connectionless data transfer is not a confirmed service.

The message is valid in state DL_IDLE. The resulting state is unchanged.

This message is applicable in connectionless-mode.

DL_UNBIND_REQ

The DL_UNBIND_REQ message consists of one M_PROTO message block, which contains the following structure.

   typedef struct {
   	ulong		dl_primitive;
   } dl_unbind_req_t;

DL_UNBIND_REQ requests the DLS provider to unbind the DLSAP that had been bound by a previous DL_BIND_REQ from this stream. At the successful completion of the request, the DLS user may issue a new DL_BIND_REQ for a potentially new DLSAP.

The members of the structure are:

dl_primitive: Conveys DL_UNBIND_REQ.

The message is valid in state DL_IDLE. The resulting state is DL_UNBIND_PENDING.

If the unbind request is successful, DL_OK_ACK is sent to the DLS user resulting in state DL_UNBOUND.

If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

This message's category is Local Management.

DL_UNITDATA_IND

The DL_UNITDATA_IND message consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks containing at least one byte of data. The amount of user data that may be transferred in a single DLSDU is limited. This limit is conveyed by the parameter dl_max_sdu in the DL_INFO_ACK primitive.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_dest_addr_length;
   	ulong		dl_dest_addr_offset;
   	ulong		dl_src_addr_length;
   	ulong		dl_src_addr_offset;
   	ulong		dl_group_address;
   } dl_unitdata_ind_t;

DL_UNITDATA_IND conveys one DLSDU from the DLS provider to the DLS user.

The members of the structure are:

dl_primitive

Conveys DL_UNITDATA_IND.

dl_dest_addr_length

The length of the address of the DLSAP where this DL_UNITDATA_IND is intended to be delivered.

NOTE: The size of the destination address depends on the data framing format being used.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_src_addr_length

The length of the DLSAP address of the sending DLS user.

NOTE: The size of the source address depends on the data framing format being used and on whether the protocol stack is consuming source routing information.

dl_src_addr_offset

The offset from the beginning of the M_PROTO message block where the source DLSAP address begins.

dl_group_address

Set by the DLS provider upon receiving and passing upstream a data message when the destination address of the data messages is a multicast or broadcast address.

The message is valid in state DL_IDLE. The resulting state is unchanged.

This message is applicable in connectionless-mode.

DL_UNITDATA_REQ

The DL_UNITDATA_REQ message consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks containing at least one byte of data. The amount of user data that may be transferred in a single DLSDU is limited. This limit is conveyed by the parameter dl_max_sdu in the DL_INFO_ACK primitive.

   typedef struct {
   	ulong		dl_primitive;
   	ulong		dl_dest_addr_length;
   	ulong		dl_dest_addr_offset;
   	dl_priority_t	dl_priority;
   } dl_unitdata_req_t;

DL_UNITDATA_REQ conveys one DLSDU from the DLS user to the DLS provider for transmission to a peer DLS user.

Because connectionless data transfer is an unacknowledged service, the DLS provider makes no guarantees of delivery of connectionless DLSDUs. It is the responsibility of the DLS user to do any necessary sequencing or retransmission of DLSDUs in the event of a presumed loss.

The members of the structure are:

dl_primitive

Conveys DL_UNITDATA_REQ.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

NOTE: The size of the destination address depends on the data framing format being used and on whether the protocol stack is producing source routing information.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_priority

Indicates the priority value within the supported range for this particular DLSDU.

NOTE: This member is ignored.

The message is valid in state DL_IDLE. The resulting state is unchanged.

If the DLS provider accepts the data for transmission, there is no response. This does not, however, guarantee that the data will be delivered to the destination DLS user, since the connectionless data transfer is not a confirmed service.

If the request is erroneous, message DL_UDERROR_IND is returned, and the resulting state is unchanged.

If for some reason the request cannot be processed, the DLS provider may generate a DL_UDERROR_IND to report the problem. There is, however, no guarantee that such an error report will be generated for all undeliverable data units, since connectionless data transfer is not a confirmed service.

The following are reasons for failure:

DL_BADADDR: The destination DLSAP address was in an incorrect format or contained invalid information.
DL_OUTSTATE: The primitive was issued from an invalid state.

This message is applicable in connectionless-mode.

DL_XID_CON

The DL_XID_CON message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   	ulong 	dl_src_addr_length;
   	ulong 	dl_src_addr_offset;
   } dl_xid_con_t;

DL_XID_CON conveys an XID DLSDU from the DLS provider to the DLS user in response to a DL_XID_REQ.

The members of the structure are:

dl_primitive

Conveys DL_XID_CON

dl_flag

The flag values associated with the received XID frame.

DL_POLL_FINAL: Indicates status of the poll/final bit in the XID frame.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_src_addr_length

The length of the source DLSAP address. If the source user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_src_addr_offset

The offset from the beginning of the M_PROTO message block where the source DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

This message's category is XID.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_XID_IND

The DL_XID_IND message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   	ulong 	dl_src_addr_length;
   	ulong 	dl_src_addr_offset;
   } dl_xid_ind_t;

DL_XID_IND conveys an XID DLSDU from the DLS provider to the DLS user.

The members of the structure are:

dl_primitive

Conveys DL_XID_IND

dl_flag

The flag values associated with the received XID frame.

DL_POLL_FINAL: Indicates if the received XID frame had the poll/final bit set.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

dl_src_addr_length

The length of the source DLSAP address. If the source user is implemented using DLPI, this address if the full DLSAP address returned on the DL_BIND_ACK.

dl_src_addr_offset

The offset from the beginning of the M_PROTO message block where the source DLSAP address begins.

The message is valid in state DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

The DLS user must respond with a DL_XID_RES.

This message's category is XID.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_XID_REQ

The DL_XID_REQ message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong dl_primitive;
   	ulong dl_flag;
   	ulong dl_dest_addr_length;
   	ulong dl_dest_addr_offset;
   } dl_xid_req_t;

DL_XID_REQ conveys one XID DLSDU from the DLS user to the DLS provider for transmission to a peer DLS user.

The members of the structure are:

dl_primitive

Conveys DL_XID_REQ

dl_flag

Indicates the flag values for the response as follows:

DL_POLL_FINAL: Indicates status of the poll/final bit in the xid frame.

dl_dest_addr_length

The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.

dl_dest_addr_offset

The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

The message is valid in state DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

On an invalid XID request, a DL_ERROR_ACK is issued to the user. If the remote side responds to the XID request, a DL_XID_CON will be sent to the user. It is recommended that the DLS user use a timeout procedure on an XID_REQ. The timeout may be used if the remote side does not respond to the XID request.

The following are reasons for failure:

DL_BADADDR: The DLSAP address information was invalid or was in an incorrect format.
DL_NOTSUPPORTED: Primitive is known but not supported by the DLS provider.
DL_OUTSTATE: The primitive was issued from an invalid state.
DL_SYSERR: A system error has occurred as indicated in the DL_ERROR_ACK.
DL_XIDAUTO: Previous bind request specified Provider would handle XID.

This message's category is XID.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

DL_XID_RES

The DL_XID_RES message consists of one M_PROTO message block, followed by zero or more M_DATA blocks containing zero or more bytes of data. The message structure is as follows:

   typedef struct {
   	ulong 	dl_primitive;
   	ulong 	dl_flag;
   	ulong 	dl_dest_addr_length;
   	ulong 	dl_dest_addr_offset;
   } dl_xid_res_t;

DL_XID_RES conveys an XID DLSDU from the DLS user to the DLS provider in response to a DL_XID_IND.

The members of the structure are:

dl_primitive: Conveys DL_XID_RES
dl_flag: The flag values associated with the received XID frame.
dl_dest_addr_length: The length of the DLSAP address of the destination DLS user. If the destination user is implemented using DLPI, this address is the full DLSAP address returned on the DL_BIND_ACK.
dl_dest_addr_offset: The offset from the beginning of the M_PROTO message block where the destination DLSAP address begins.

The message is valid in states DL_IDLE and DL_DATAXFER. The resulting state is unchanged.

This message's category is XID.

NOTE: This primitive can only be issued when using the IEEE 802.2 data framing format.

ioctl commands handled by DLPI in SCO OpenServer 5 and SVR5

The DLPI module in SCO OpenServer 5 and SVR5 handles the DLPID_REGISTER ioctl command that dlpid uses to register with the module before linking it with an MDI driver. It also handles the I_LINK, I_PLINK, I_UNLINK, and I_PUNLINK ioctl commands described in streamio.

The DLPI module responds to the MACIOC_CLRMCA, MACIOC_DIAG, MACIOC_GETADDR , MACIOC_GETIFSTAT, MACIOC_GETRADDR, MACIOC_GETSTAT, MACIOC_LOCALSTAT, MACIOC_PROMISC, MACIOC_SETADDR, and MACIOC_UNITSEL ioctl commands on behalf of the MDI driver below it. It passes all other MACIOC_ ioctl commands to the MDI driver.

References

Intro(D4dlpi), Intro(D4mdi), Intro(D7mdi)

DL_DISABALLMULTI_REQ	--	--	--	Y
DL_DISABMULTI_REQ	Y	I	Y	Y
DL_DISCONNECT_IND	Y	--	--	--
DL_DISCONNECT_REQ	Y	IC	--	--
DL_DLPI_BILOOPMODE	--	--	Y	Y
DL_ENABALLMULTI_REQ	--	--	--	Y
DL_ENABMULTI_REQ	Y	I	Y!	Y!
DL_ERROR_ACK	Y	Y	Y	Y
DL_GET_STATISTICS_ACK	Y	--	Y!	Y!
DL_GET_STATISTICS_REQ	Y	--	Y	Y

DL_PROMISCOFF_REQ	Y	I	--	--
DL_PROMISCON_REQ	Y	I	--	--
DL_REPLY_REQ	Y	--	--	--
DL_REPLY_IND	Y	--	--	--
DL_REPLY_STATUS_IND	Y	--	--	--
DL_REPLY_UPDATE_REQ	Y	--	--	--
DL_REPLY_UPDATE_STATUS_IND	Y	--	--	--
DL_RESET_CON	Y	--	--	--
DL_RESET_IND	Y	--	--	--
DL_RESET_REQ	Y	--	--	--
DL_RESET_RES	Y	--	--	--

DL_UDERROR_IND	Y	Y	Y	Y
DL_UDQOS_REQ	Y	--	--	--
DL_UNBIND_REQ	Y	Y	Y	Y
DL_UNITDATA_IND	Y	Y	Y!	Y!
DL_UNITDATA_REQ	Y	Y	Y!	Y!
DL_XID_CON	Y	--	Y!	Y!
DL_XID_IND	Y	--	Y!	Y!
DL_XID_REQ	Y	C	Y!	Y!
DL_XID_RES	Y	C	Y!	Y!

DLIOCGENADDR	DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK	Return Ethernet (MAC) address
DLIOCGETMULTI	DL_MCTABLE_REQ, DL_MCTABLE_ACK	Return list of multicast addresses
DLIOCGLPCFLG	Not supported	Get local copy packet flag (send local packets on wire)
DLIOCGMIB	DL_GET_STATISTICS_REQ, DL_GET_STATISTICS_ACK	Get MIB statistics (DL_mib_t)

DLIOCGPROMISC	Not supported	Get promiscuous mode flag
DLIOCLLC2MODE	Not supported	Toggle LLC2 mode (Token-Ring adapters)
DLIOCRAWMODE	Not supported	Toggle RAW mode (Token-Ring adapters)
DLIOCRESET	Not supported	Reset controller -- nearest equivalent is to close and open driver
DLIOCSENADDR	DL_SET_PHYS_ADDR_REQ
DLIOCSLPCFLG	Not supported	Set local copy packet flag (send local packets on wire)
DLIOCSMIB	DL_CLR_STATISTICS_REQ, MACIOC_SETSTAT	Set MIB statistics (DL_mib_t)

DLIOCSPROMISC	MACIOC_PROMISC	Set promiscuous mode flag
DLGADDR	DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK	Return Ethernet (MAC) address
DLGBROAD	Not supported	Get broadcast address
DLSLLC2	Not supported	Toggle LLC2 mode (Token-Ring adapters)
DLSRAW	Not supported	Toggle RAW mode (Token-Ring adapters)

MACIOC_GETADDR	DL_PHYS_ADDR_REQ, DL_PHYS_ADDR_ACK	Return Ethernet (MAC) address
SIOCGIFDEBUG	Not supported	Get debug level
SIOCGIFFLAGS	Not supported	Socket I/O control to get interface flags (acknowledged and ignored)