Data Link Provider Interface (DLPI)

Data Link Provider Interface (DLPI)
Copyright © 1997 The Open Group

DLPI Primitives

The kernel-level interface to the data link layer defines a STREAMS-based message interface between the provider of the data link service (DLS provider) and the consumer of the data link service (DLS user). STREAMS provides the mechanism in which DLPI primitives may be passed between the DLS user and DLS provider.

Before DLPI primitives can be passed between the DLS user and the DLS provider, the DLS user must establish a stream to the DLS provider using open(). The DLS provider must therefore be configured as a STREAMS driver. When interactions between the DLS user and DLS provider have completed, the stream may be closed.

The STREAMS messages used to transport data link service primitives across the interface have one of the following formats:

One M_PROTO message block followed by zero or more M_DATA blocks. The M_PROTO message block contains the data link layer service primitive type and all relevant parameters associated with the primitive. The M_DATA block(s) contain any DLS user data that might be associated with the service primitive.
One M_PCPROTO message block containing the data link layer service primitive type and all relevant parameters associated with the service primitive.
One or more M_DATA message blocks conveying user data.

The information contained in the M_PROTO or M_PCPROTO message blocks must begin on a byte boundary that is appropriate for structure alignment (for example, word-aligned on the AT&T 3B2 Computer). STREAMS will allocate buffers that begin on such a boundary. However, these message blocks may contain information whose representation is described by a length and an offset within the block. An example is the DLSAP address (dl_addr_length and dl_addr_offset) in the DL_BIND_ACK primitive. The offset of such information within the message block is not guaranteed to be properly aligned for casting the appropriate data type (such as an int or a struct). Allowable Sequence of DLPI Primitives defines the sequence in which DLPI primitives can be passed between DLS user and DLS provider, and Precedence of DLPI Primitives summarizes the precedence rules associated with each primitive for ordering the primitives on the DLS provider and DLS user queues.

The following sections describe the format of the primitives that support the services described in the previous chapter. The primitives are grouped into four general categories for presentation:

Local Management Service Primitives
Connection-mode Service Primitives
Connectionless-mode Service Primitives
Acknowledged Connectionless-mode Service Primitives

Three types are used to build the DLPI primitives. The normative definitions of t_scalar_t and t_uscalar_t are to be found in the Networking Services Specification (see the referenced XNS specification), but are repeated here for informational purposes. uint16_t is one of the fixed width types defined in <sys/inttypes.h>.

t_scalar_t and t_uscalar_t are, respectively, a signed and an unsigned opaque integral type of equal length of at least 32 bits¹.

Local Management Service Primitives

This section describes the local management service primitives that are common to the connection, connectionless and acknowledged connectionless service modes. These primitives support the Information Reporting, Attach, Bind, Enabling/Disabling of multicast addresses, and Turning On/Off the promiscuous mode. Once a stream has been opened by a DLS user, these primitives initialize the stream, preparing it for use.

PPA Initialization/De-initialization

The PPA associated with each stream must be initialized before the DLS provider can transfer data over the medium. The initialization and de-initialization of the PPA is a network management issue, but DLPI must address the issue because of the impact such actions will have on a DLS user. More specifically, DLPI requires the DLS provider to initialize the PPA associated with a stream at some point before it completes the processing of the DL_BIND_REQ. Guidelines for initialization and de-initialization of a PPA by a DLS provider are presented here.

A DLS provider may initialize a PPA using either of the following methods:

pre-initialized by some network management mechanism before the DL_BIND_REQ is received
automatic initialization on receipt of a DL_BIND_REQ or DL_ATTACH_REQ.

A specific DLS provider may support either of these methods, or possibly some combination of the two, but the method implemented has no impact on the DLS user. From the DLS user's viewpoint, the PPA is guaranteed to be initialized on receipt of a DL_BIND_ACK. For automatic initialization, this implies that the DL_BIND_ACK may not be issued until the initialization has completed.

If pre-initialization has not been performed and/or automatic initialization fails, the DLS provider will fail the DL_BIND_REQ. Two errors, DL_INITFAILED and DL_NOTINIT, may be returned in the DL_ERROR_ACK response to a DL_BIND_REQ if PPAinitialization fails. DL_INITFAILED is returned when a DLS provider supports automatic PPA initialization, but the initialization attempt failed. DL_NOTINIT is returned when the DLS provider requires pre-initialization, but the PPA is not initialized before the DL_BIND_REQ is received.

A DLS provider may handle PPA de-initialization using one of the following methods:

automatic de-initialization upon receipt of the final DL_DETACH_REQ (for style 2 providers) or DL_UNBIND_REQ (for style 1 providers), or upon closing of the last stream associated with the PPA
automatic de-initialization after expiration of a timer following the last DL_DETACH_REQ, DL_UNBIND_REQ, or close as appropriate
no automatic de-initialization;administrative intervention is required to de-initialize the PPA at some point after it is no longer being accessed.

A specific DLS provider may support any of these methods, or possibly some combination of them, but the method implemented has no impact on the DLS user. From the DLS user's viewpoint, the PPA is guaranteed to be initialized and available for transmission until it closes or unbinds the stream associated with the PPA. DLS provider-specific addendum documentation should describe the method chosen for PPA initialization and de-initialization.

List of Local Management Service Primitives

The local management service primitives are listed below and are defined in the following man-pages:

 

DL_INFO_REQ
DL_INFO_ACK
DL_ATTACH_REQ
DL_DETACH_REQ
DL_BIND_REQ
DL_BIND_ACK
DL_UNBIND_REQ
DL_SUBS_BIND_REQ
DL_SUBS_BIND_ACK
DL_SUBS_UNBIND_REQ
DL_ENABMULTI_REQ
DL_DISABMULTI_REQ
DL_PROMISCON_REQ
DL_PROMISCOFF_REQ
DL_OK_ACK
DL_ERROR_ACK

Data Link Provider Interface (DLPI) - DL_INFO_REQ Previous section.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

NAME

DL_INFO_REQ (dl_info_req_t) - request 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.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure:
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_info_req_t;

PARAMETERS

dl_primitive

conveys DL_INFO_REQ.

STATE

The message is valid in any state in which a local acknowledgement is not pending, as described in Allowable Sequence of DLPI Primitives .

NEW STATE

The resulting state is unchanged.

RESPONSE

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

Data Link Provider Interface (DLPI) - DL_INFO_ACK Previous section.

NAME

DL_INFO_ACK (dl_info_ack_t) - this message is sent in response to DL_INFO_REQ; it conveys information about the DLPI stream to the DLS user.

SYNOPSIS

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

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

PARAMETERS

dl_primitive

conveys DL_INFO_ACK.

dl_max_sdu

conveys 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.

dl_min_sdu

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

dl_addr_length

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

dl_mac_type

conveys the type of medium supported by this DLPI stream². Possible values include:

DL_CSMACD

The medium is Carrier Sense Multiple Access with Collision Detection (ISO 8802/3).

DL_TPB

The medium is Token-Passing Bus (ISO 8802/4).

DL_TPR

The medium is Token-Passing Ring (ISO 8802/5).

DL_METRO

The medium is Metro Net (ISO 8802/6).

DL_ETHER

The medium is Ethernet Bus.

DL_HDLC

The medium is a bit synchronous communication line.

DL_CHAR

The medium is a character synchronous communication line (for example, BISYNC).

DL_CTCA

The medium is a channel-to-channel adapter.

DL_FDDI

The medium is a Fiber Distributed Data Interface.

DL_FC

The medium is Fiber Channel.

DL_ATM

The medium is Asynchronous Transfer Mode.

DL_IPATM

The medium is Internet IP over Asynchronous Transfer Mode, RFC 1577.

DL_X25

The medium is X.25 LAPB.

DL_IPX25

The medium is Internet IP over X.25, RFC 1356.

DL_ISDN

The medium is ISDN.

DL_HIPPI

The medium is High Performance Parallel Interface.

DL_100VG

The medium is 100 Based VG Ethernet.

DL_100VGTPR

The medium is 100 Based VG Token Ring.

DL_ETH_CSMA

The medium is capable of both ISO 8802/3 and Ethernet.

DL_100BT

The medium is 100 Base T Ethernet.

DL_FRAME

The medium is Frame Relay LAPF.

DL_MPFRAME

The medium is Multi-Protocol over Frame Relay encapsulation, RFC 1490.

DL_ASYNC

The medium is a bit asynchronous communication line.

DL_LOOP

The medium is a software loopback.

DL_OTHER

Any other medium that is not listed above.

dl_mac_type values above 0x80000000 are available for private or experimental use and will not be defined by this Specification.

dl_reserved

is a reserved field whose value must be set to zero.

dl_current_state

conveys the state of the DLPI interface for the stream when the DLS provider issued this acknowledgement. See Allowable Sequence of DLPI Primitives for a list of DLPI states and an explanation of each.

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 comibination 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 field returns that specific service mode.

dl_qos_length

conveys the length, in bytes, of the negotiated/selected values of the quality of service (QOS) parameters. Section 5, Quality of Data Link Service , describes quality of service and its associated parameters completely. 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.
The QOS values are conveyed in the structures defined in QOS Data Structures . 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 field will be set to zero.

dl_qos_offset

conveys the offset from the beginning of the M_PCPROTO block where the current quality of service parameters begin.

dl_qos_range_length

conveys the length, in bytes, of the available range of QOS parameter values supported by the DLS provider. Forconnection-mode service, this is the range available to the calling DLS user in a connect request. Forconnectionless-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.
The range of available QOS values is conveyed in the structures defined in QOS Data Structures . 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 field will be set to zero.

dl_qos_range_offset

conveys the offset from the beginning of the M_PCPROTO block where the available range of quality of service parameters begins.

dl_provider_style

conveys the style of DLS provider associated with the DLPI stream (see Physical Attachment Identification ). 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.

dl_addr_offset

conveys 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 version of the dlpi 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 PCPROTO block.

dl_growth

conveys a growth field for future use. The value of this field will be zero.

STATE

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

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_ATTACH_REQ Previous section.

NAME

DL_ATTACH_REQ (dl_attach_req_t) - requests the DLS provider associate a physical point of attachment (PPA) with astream. DL_ATTACH_REQ is needed for style 2 DLS providers to identify the physical medium over which communication will transpire. The request may not be issued to a style 1 DLS provider; doing so may cause errors.
The DLS provider may initialize the physical line on receipt of this primitive or the DL_BIND_REQ. Otherwise, the line must be initialized through some management mechanism before this request is issued by the DLS user. Either way, the physical link must be initialized and ready for use on successful completion of the DL_BIND_REQ.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_ppa;
} dl_attach_req_t;

PARAMETERS

dl_primitive

conveys DL_ATTACH_REQ.

dl_ppa

conveys the identifier of the physical point of attachment to be associated with the stream. The format of the identifier is provider-specific, and it must contain sufficient information to distinguish the desired PPA from all possible PPAs on a system. At a minimum, this must include identification of the physical medium over which communication will transpire. For media that multiplex multiple channels over a single physical medium, this identifier should also specify a specific channel to be used for communication (where each channel on a physical medium is associated with a separate PPA).
Because of the provider-specific nature of this value, DLS user software that is to be protocol independent should avoid hard-coding the PPA identifier. The DLS user should retrieve the necessary PPA identifier from some other entity (such as a management entity) and insert it without inspection into the DL_ATTACH_REQ.

STATE

The message is valid in state DL_UNATTACHED.

NEW STATE

The resulting state is DL_ATTACH_PENDING.

RESPONSE

If the attach 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.

ERRORS

DL_ACCESS

The DLS user did not have proper permission to use the requested PPA.

DL_BADPPA

The specified PPA is invalid.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_DETACH_REQ Previous section.

NAME

DL_DETACH_REQ (dl_detach_req_t) - for style 2 DLS providers, this requests the DLS provider detach a physical point of attachment (PPA) from a stream. The request may not be issued to a style 1 DLS provider; doing so may cause errors.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_detach_req_t;

PARAMETERS

dl_primitive

conveys DL_DETACH_REQ.

STATE

The message is valid in state DL_UNBOUND.

NEW STATE

The resulting state is DL_DETACH_PENDING.

RESPONSE

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

ERRORS

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_BIND_REQ Previous section.

NAME

DL_BIND_REQ (dl_bind_req_t) - requests the DLS provider bind a DLSAP to the stream. The DLS user must identify the address of the DLSAP to be bound to the stream. Forconnection-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 PPA associated with each stream must be initialized upon completion of the processing of the DL_BIND_REQ (see PPA Initialization/De-initialization ). 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 (see Connection Management Stream ). In this case, the dl_sap will be ignored.

SYNOPSIS

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

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

PARAMETERS

dl_primitive

conveys DL_BIND_REQ.

dl_sap

conveys sufficient information to identify the DLSAP that will be bound to the DLPI stream (see DLPI Addressing for a description of DLSAP addresses). 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.

The DLS provider may not be able to bind the specified DLSAP address for one of the following reasons:

the DLS provider may statically associate a specific DLSAP with each stream

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 case of reason 1, 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 case of reason 2, 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.

dl_max_conind

conveys 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 (see Multi-threaded Connection Establishment for details on how this value is used to support multi-threaded connect processing). 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 adl_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 field is ignored in connectionless-mode service.

dl_service_mode

conveys 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.

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 l_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.

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.

STATE

The message is valid in state DL_UNBOUND.

NEW STATE

The resulting state is DL_BIND_PENDING.

RESPONSE

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.

ERRORS

DL_ACCESS

The DLS user did not have proper permission to use the requested DLSAP address.

DL_BADADDR

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

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 "connectionmanagement" stream to a PPA.

DL_INITFAILED

Automatic initialization of the PPAfailed.

DL_NOTINIT

The PPA had not been initialized prior to this request.

DL_NOADDR

The DLS provider could not allocate a DLSAP address for this stream.

DL_NOAUTO

Automatic handling of XID and TEST responses not supported.

DL_NOTESTAUTO

Automatic handling of TEST response not supported.

DL_NOXIDAUTO

Automatic handling of XID response not supported.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

DL_UNSUPPORTED

The DLS provider does not support requested service mode on this stream. A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_BIND_ACK Previous section.

NAME

DL_BIND_ACK (dl_bind_ack_t) - reports the successful bind of a 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.

SYNOPSIS

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

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

PARAMETERS

dl_primitive

conveys DL_BIND_ACK.

dl_sap

conveys the DLSAP address information associated with the bound DLSAP. It corresponds to the dl_sap field 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 field contains the corresponding portion of the address for the DLSAP that was actually bound.

dl_addr_length

conveys the length of the complete DLSAP address that was bound to the DLPI stream (see DLPI Addressing for a description of DLSAP addresses). The bound DLSAP is chosen according to the guidelines presented under the description of DL_BIND_REQ.

dl_addr_offset

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

dl_max_conind

conveys 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.

dl_xidtest_flg

conveys 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.

STATE

The message is valid in state DL_BIND_PENDING.

NEW STATE

The resulting state is DL_IDLE.

Data Link Provider Interface (DLPI) - DL_UNBIND_REQ Previous section.

NAME

DL_UNBIND_REQ (dl_unbind_req_t) - requests the DLS provider to unbind the DLSAP that had been bound by a previous DL_BIND_REQ from this stream. If one or more DLSAPs were bound to the stream using a DL_SUBS_BIND_REQ, and have not been unbound using a DL_SUBS_UNBIND_REQ, the DL_UNBIND_REQ will unbind all the subesquent DLSAPs for that stream along with the DLSAP bound using the previous DL_BIND_REQ.
At the successful completion of the request, the DLS user may issue a new DL_BIND_REQ for a potentially new DLSAP.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_unbind_req_t;

PARAMETERS

dl_primitive

conveys DL_UNBIND_REQ.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is DL_UNBIND_PENDING.

RESPONSE

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.

ERRORS

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_SUBS_BIND_REQ Previous section.

NAME

DL_SUBS_BIND_REQ (dl_subs_bind_req_t) - 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.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_subs_sap_offset;
    t_uscalar_t  dl_subs_sap_length;
    t_uscalar_t  dl_subs_bind_class;
} dl_subs_bind_req_t;

PARAMETERS

dl_primitive

conveys DL_SUBS_BIND_REQ.

dl_subs_sap_offset

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

dl_subs_sap_length

conveys the length of the specified DLSAP.

dl_subs_bind_class

specifies either peer or hierarchical addressing:

DL_PEER_BIND

specifies peer addressing. The DLSAP specified is used in lieu of the DLSAP bound in the BIND request.

DL_HIERARCHICAL_BIND

specifies hierarchical addressing. The DLSAP specified is used in addition to the DLSAP specified using the BIND request.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is DL_SUBS_BIND_PND.

RESPONSE

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.

ERRORS

DL_ACCESS

The DLS user did not have proper permission to use the requested DLSAP address.

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 and the UNIX system error is indicated in the DL_ERROR_ACK.

DL_TOOMANY

Limit exceeded on the maximum number of DLSAPs per stream.

DL_UNSUPPORTED

Requested addressing class not supported.

Data Link Provider Interface (DLPI) - DL_SUBS_BIND_ACK Previous section.

NAME

DL_SUBS_BIND_ACK (dl_subs_bind_ack_t) - reports the succesful 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_SUBS_BIND_REQ.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_subs_sap_offset;
    t_uscalar_t  dl_subs_sap_length;
} dl_subs_bind_ack_t;

PARAMETERS

dl_primitive

conveys DL_SUBS_BIND_ACK.

dl_subs_sap_offset

conveys the offset of the DLSAP from the beginning of the M_PCPROTO block.

dl_subs_sap_length

conveys the length of the specified DLSAP.

STATE

The message is valid in state DL_SUBS_BIND_PND

NEW STATE

The resulting state is DL_IDLE.

Data Link Provider Interface (DLPI) - DL_SUBS_UNBIND_REQ Previous section.

NAME

DL_SUBS_UNBIND_REQ (dl_subs_unbind_req_t) - requests the DLS Provider to unbind the DLSAP that had been bound by aprevious DL_SUBS_BIND_REQ from this stream.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure:
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_subs_sap_offset;
    t_uscalar_t  dl_subs_sap_length;
} dl_subs_unbind_req_t;

PARAMETERS

dl_primitive

conveys DL_SUBS_UNBIND_REQ.

dl_subs_sap_offset

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

dl_subs_sap_length

conveys the length of the specified DLSAP.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is DL_SUBS_UNBIND_PND.

RESPONSE

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.

ERRORS

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 and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_ENABMULTI_REQ Previous section.

NAME

DL_ENABMULTI_REQ (dl_enabmulti_req_t) - 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.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure:
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_addr_length;
    t_uscalar_t  dl_addr_offset;
} dl_enabmulti_req_t;

PARAMETERS

dl_primitive

conveys DL_ENABMULTI_REQ

dl_addr_length

conveys the length of the multicast address

dl_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the multicast address begins

STATE

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

NEW STATE

The resulting state is unchanged.

RESPONSE

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.

ERRORS

DL_BADADDR

Address information was invalid or was in an incorrect format.

DL_NOTSUPPORTED

The primitive is known, but not supported by the DLS Provider.

DL_OUTSTATE

The primitive was issued from an invalid state

DL_TOOMANY

Too many multicast address enable attempts. Limit exceeded.

Data Link Provider Interface (DLPI) - DL_DISABMULTI_REQ Previous section.

NAME

DL_DISABMULTI_REQ (dl_disabmulti_req_t) - requests the DLS Provider to disable specific multicast addresses on a per Stream basis.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure:
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_addr_length;
    t_uscalar_t  dl_addr_offset;
} dl_disabmulti_req_t;

PARAMETERS

dl_primitive

conveys DL_DISABMULTI_REQ

dl_addr_length

conveys the length of the physical address

dl_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the multicast address begins

STATE

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

NEW STATE

The resulting state is unchanged.

RESPONSE

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.

ERRORS

DL_BADADDR

Address information was invalid or in an incorrect format.

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.

Data Link Provider Interface (DLPI) - DL_PROMISCON_REQ Previous section.

NAME

DL_PROMISCON_REQ (dl_promiscon_req_t) - this primitive requests the DLS Provider to enable promiscuous mode on a per Stream basis, either at the physical level or at the SAP level.
The DL Provider will route all received messages on the media to the DLS User until either a DL_DETACH_REQ or a DL_PROMISCOFF_REQ is received or the Stream is closed.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_level;
} dl_promiscon_req_t;

PARAMETERS

dl_primitive

conveys DL_PROMISCON_REQ

dl_level

indicates promiscuous mode at the physical or SAP level:

DL_PROMISC_PHYS

indicates promiscuous mode at the physical level

DL_PROMISC_SAP

indicates promiscuous mode at the SAP level

DL_PROMISC_MULTI

indicates promiscuous mode for all multicast addresses.

STATE

The message is valid in any state when there is no pending acknowledgement.

NEW STATE

The resulting state is unchanged.

RESPONSE

If enabling of promiscuous mode is successful, a DL_OK_ACK is returned. Otherwise, a DL_ERROR_ACK is returned.

ERRORS

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 and the UNIX System error is indicated in the DL_ERROR_ACK.

DL_UNSUPPORTED

Requested service is not supplied by the provider.

Data Link Provider Interface (DLPI) - DL_PROMISCOFF_REQ Previous section.

NAME

DL_PROMISCOFF_REQ (dl_promiscoff_req_t) - this primitive requests the DLS Provider to disable promiscuous mode on a per Stream basis, either at the physical level or at the SAP level.

SYNOPSIS

The message consists of one M_PROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_level;
} dl_promiscoff_req_t;

PARAMETERS

dl_primitive

conveys DL_PROMISCOFF_REQ

dl_level

indicates promiscuous mode at the physical or SAP level:

DL_PROMISC_PHYS

indicates promiscuous mode at the physical level

DL_PROMISC_SAP

indicates promiscuous mode at the SAP level

DL_PROMISC_MULTI

indicates promiscuous mode for all multicast addresses.

STATE

The message is valid in any state in which the promiscuous mode is enabled and there is no pending acknowledgement.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the promiscuous mode disabling is successful, a DL_OK_ACK is returned. Otherwise, a DL_ERROR_ACK is returned.

ERRORS

DL_NOTENAB

Mode 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 and the UNIX System error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_OK_ACK Previous section.

NAME

DL_OK_ACK (dl_ok_ack_t) - 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.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correct_primitive;
} dl_ok_ack_t;

PARAMETERS

dl_primitive

conveys DL_OK_ACK.

dl_correct_primitive

identifies the successfully received primitive that is being acknowledged.

STATE

The message is valid in response to any of the following:
 

DL_ATTACH_REQ
DL_DETACH_REQ
DL_UNBIND_REQ,
DL_CONNECT_RES
DL_RESET_RES
DL_DISCON_REQ
DL_SUBS_UNBIND_REQ
DL_PROMISCON_REQ
DL_ENABMULTI_REQ
DL_DISABMULTI_REQ or 
DL_PROMISCOFF_REQ 
from any of several states as defined in Allowable Sequence of DLPI Primitives .

NEW STATE

The resulting state depends on the current state and is defined fully in Allowable Sequence of DLPI Primitives .

Data Link Provider Interface (DLPI) - DL_ERROR_ACK Previous section.

NAME

DL_ERROR_ACK (dl_error_ack_t) - 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.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_error_primitive;
    t_uscalar_t  dl_errno;
    t_uscalar_t  dl_unix_errno;
} dl_error_ack_t;

PARAMETERS

dl_primitive

conveys DL_ERROR_ACK.

dl_error_prim

identifies the primitive in error.

dl_errno

conveys 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:

DL_BADPRIM

error is returned if an unrecognized primitive is issued by the DLS user.

DL_NOTSUPPORTED

error is returned if an unsupported primitive is issued by the DLS user.

dl_unix_errno

conveys 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.

STATE

The message is valid in every state where an acknowledgement or confirmation of a previous request or response is pending.

NEW STATE

The resulting state is that from which the acknowledged request or response was generated.

Connection-mode Service Primitives

Scope

This section describes the service primitives that support the connection-mode service of the data link layer. These primitives support the connection establishment,connection-mode data transfer, and connection release services described earlier.

Multi-threaded Connection Establishment

In the connection establishment model, the calling DLS user initiates a request for a connection, and the called DLS user receives each request and either accepts or rejects it. In the simplest form (single-threaded), the called DLS user is passed a connect indication and the DLS provider holds any subsequent indications until a response for the current outstanding indication is received. At most one connect indication is outstanding at any time.

DLPI also enables a called DLS user to multi-thread connect indications and responses. This capability is desirable, for example, when imposing a priority scheme on all DLS users attempting to establish a connection. The DLS provider will pass all connect indications to the called DLS user (up to some preestablished limit as set by DL_BIND_REQ and DL_BIND_ACK). The called DLS user may then respond to the requests in any order.

To support multi-threading,a correlation value is needed to associate responses with the appropriate connect indication. A correlation value is contained in each DL_CONNECT_IND, and the DLS user must use this value in the DL_CONNECT_RES or DL_DISCONNECT_REQ primitive used to accept or reject the connect request. The DLS user can also receive a DL_DISCONNECT_IND with a correlation value when the calling DLS user or the DLS provider abort a connect request.

Once a connection has been accepted or rejected, the correlation value has no meaning to a DLS user. The DLS provider may reuse the correlation value in another DL_CONNECT_IND. Thus, the lifetime of a correlation value is the duration of the connection establishment phase, and as good programming practice it should not be used for any other purpose by the DLS provider.

The DLS provider assigns the correlation value for each connect indication. Correlation values must be unique among all outstanding connect indications on a given stream. The values may, but need not, be unique across all streams to the DLS provider. The correlation value must be a positive, non-zero value. There is no implied sequencing of connect indications using the correlation value; the values do not have to increase sequentially for each new connect indication.

List of Connection-mode Service Primitives

The connection-mode service primitives are listed below and are defined in the following man-pages:

 

DL_CONNECT_REQ
DL_CONNECT_IND
DL_CONNECT_RES
DL_CONNECT_CON
DL_TOKEN_REQ
DL_TOKEN_ACK
DL_DATA_REQ
DL_DATA_IND
DL_DISCONNECT_REQ
DL_DISCONNECT_IND
DL_RESET_REQ
DL_RESET_IND
DL_RESET_RES
DL_RESET_CON

Data Link Provider Interface (DLPI) - DL_CONNECT_REQ Previous section.

NAME

DL_CONNECT_REQ (dl_connect_req_t) - requests the DLS provider establish a data link connection with a remote DLS user. The request contains the DLSAP address of the remote (called) DLS user and quality of service parameters to be negotiated during connection establishment.

SYNOPSIS

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

typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_qos_length;
    t_uscalar_t  dl_qos_offset;
    t_uscalar_t  dl_growth;
} dl_connect_req_t;

PARAMETERS

LI dl_primitive
conveys DL_CONNECT_REQ.

dl_dest_addr_length

conveys the length of the DLSAP address that identifies the DLS user with whom a connection is to be established. If the called 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_qos_length

conveys the length of the quality of service (QOS) parameter values desired by the DLS user initiating a connection. The desired QOS values are conveyed in the appropriate structure defined in QOS Data Structures . A full specification of these QOS parameters and rules for negotiating their values is presented in Quality of Data Link Service .
If the DLS user does not wish to specify a particular QOS value, the value DL_QOS_DONT_CARE may be specified. If the DLS user does not care to specify any QOS parameter values, this field may be set to zero.

dl_qos_offset

conveys the offset from the beginning of the M_PROTO message block where the quality of service parameters begin.

dl_growth

defines a growth field for future enhancements to this primitive. Its value must be set to zero.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is DL_OUTCON_PENDING.

RESPONSE

There is no immediate response to the connect request. However, if the connect request is accepted by the called DLS user, DL_CONNECT_CON is sent to the calling DLS user, resulting in state DL_DATAXFER. If the connect request is rejected by the called DLS user, the called DLS user cannot be reached, or the DLS provider and/or called DLS user do not agree on the specified quality of service, a DL_DISCONNECT_IND is sent to the calling DLS user, resulting in state DL_IDLE. If the request is erroneous, message DL_ERROR_ACK is returned and the resulting state is unchanged.

ERRORS

DL_ACCESS

The DLS user did not have proper permission to use the requested DLSAP address.

DL_BADADDR

The destination DLSAP address was in an incorrect format or contained invalid information.

DL_BADQOSPARAM

The quality of service parameters contained invalid values.

DL_BADQOSTYPE

The quality of service structure type was not supported by the DLS provider.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_CONNECT_IND Previous section.

NAME

DL_CONNECT_IND (dl_connect_ind_t) - conveys to the local DLS user that a remote (calling) DLS user wishes to establish a data link connection. The indication contains the DLSAP address of the calling and called DLS user, and the quality of service parameters as specified by the calling DLS user and negotiated by the DLS provider.
The DL_CONNECT_IND also contains a number that allows the DLS user to correlate a subsequent DL_CONNECT_RES,DL_DISCONNECT_REQ, or DL_DISCONNECT_IND with the indication (see Multi-threaded Connection Establishment ).
The number of outstanding DL_CONNECT_IND primitives issued by the DLS provider must not exceed the value of dl_max_conind as returned on the DL_BIND_ACK. If this limit is reached and an additional connect request arrives, the DLS provider must not pass the corresponding connect indication to the DLS user until a response is received for an already outstanding indication.

SYNOPSIS

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

typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_called_addr_length;
    t_uscalar_t  dl_called_addr_offset;
    t_uscalar_t  dl_calling_addr_length;
    t_uscalar_t  dl_calling_addr_offset;
    t_uscalar_t  dl_qos_length;
    t_uscalar_t  dl_qos_offset;
    t_uscalar_t  dl_growth;
} dl_connect_ind_t;

PARAMETERS

dl_primitive

conveys DL_CONNECT_IND.

dl_correlation

conveys the correlation number to be used by the DLS user to associate this message with the DL_CONNECT_RES,DL_DISCONNECT_REQ, or DL_DISCONNECT_IND that is to follow. This value, then, enables the DLS user to multi-thread connect indications and responses. All outstanding connect indications must have a distinct, non-zero correlation value set by the DLS provider.

dl_called_addr_length

conveys the length of the address of the DLSAP for which this DL_CONNECT_IND primitive is intended. This address is the full DLSAP address specified by the calling DLS user and is typically the value returned on the DL_BIND_ACK associated with the given stream.

dl_called_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the called DLSAP address begins.

dl_calling_addr_length

conveys the length of the address of the DLSAP from which the DL_CONNECT_REQ primitive was sent.

dl_calling_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the calling DLSAP address begins.

dl_qos_length

conveys the range of quality of service parameter values desired by the calling DLS user and negotiated by the DLS provider. The range of QOS values is conveyed in the appropriate structure defined in QOS Data Structures . A full specification of these QOS parameters and rules for negotiating their values is presented in Quality of Data Link Service . For any parameter the DLS provider does not support or cannot determine, the corresponding parameter values will be set to DL_UNKNOWN. If the DLS provider does not support any QOS parameters, this length field will be set to zero.

dl_qos_offset

conveys the offset from the beginning of the M_PROTO message block where the quality of service parameters begin.

dl_growth

defines a growth field for future enhancements to this primitive. Its value will be set to zero.

STATE

The message is valid in state DL_IDLE, or state DL_INCON_PENDING when the maximum number of outstanding DL_CONNECT_IND primitives has not been reached on this stream.

NEW STATE

The resulting state is DL_INCON_PENDING, regardless of the current state.

RESPONSE

The DLS user must eventually send either DL_CONNECT_RES to accept the connect request or DL_DISCONNECT_REQ to reject the connect request. In either case, the responding message must convey the correlation number received in the DL_CONNECT_IND. The DLS provider will use the correlation number to identify the connect request to which the DLS user is responding.

Data Link Provider Interface (DLPI) - DL_CONNECT_RES Previous section.

NAME

DL_CONNECT_RES (dl_connect_res_t) - directs the DLS provider to accept a connect request from a remote (calling) DLS user on adesignated stream. The DLS user may accept the connection on the same stream where the connect indication arrived, or on a different stream that has been previously bound. The response contains the correlation number from the corresponding DL_CONNECT_IND, selected quality of service parameters, and an indication of the stream on which to accept the connection.
After issuing this primitive, the DLS user may immediately begin transferring data using the DL_DATA_REQ primitive. If the DLS provider receives one or more DL_DATA_REQ primitives from the local DLS user before it has completed connection establishment, however, it must queue the data transfer requests internally until the connection is successfully established.

SYNOPSIS

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

typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_resp_token;
    t_uscalar_t  dl_qos_length;
    t_uscalar_t  dl_qos_offset;
    t_uscalar_t  dl_growth;
} dl_connect_res_t;

PARAMETERS

dl_primitive

conveys DL_CONNECT_RES.

dl_correlation

conveys the correlation number that was received with the DL_CONNECT_IND associated with the connection request. The DLS provider will use the correlation number to identify the connect indication to which the DLS user is responding.

dl_resp_token

if non-zero, conveys the token associated with the responding stream on which the DLS provider is to establish the connection; this stream must be in the state DL_IDLE. The token value for a stream can be obtained by issuing a DL_TOKEN_REQ on that stream. If the DLS user is accepting the connection on the stream where the connect indication arrived, this value must be zero. See Connection Establishment for a description of the connection response model.

dl_qos_length

conveys the length of the quality of service parameter values selected by the called DLS user. The selected QOS values are conveyed in the appropriate structure as defined in QOS Data Structures . A full specification of these QOS parameters and rules for negotiating their values is presented in Quality of Data Link Service . If the DLS user does not care which value is selected for a particular QOS parameter, the value DL_QOS_DONT_CARE may be specified. If the DLS user does not care which values are selected for all QOS parameters, this field may be set to zero.

dl_qos_offset

conveys the offset from the beginning of the M_PROTO message block where the quality of service parameters begin.

dl_growth

defines a growth field for future enhancements to this primitive. Its value must be set to zero.

STATE

The primitive is valid in state DL_INCON_PENDING.

NEW STATE

The resulting state is DL_CONN_RES_PENDING.

RESPONSE

If the connect response is successful, DL_OK_ACK is sent to the DLS user. If no outstanding connect indications remain, the resulting state for the current stream is DL_IDLE; otherwise it remains DL_INCON_PENDING. For the responding stream (designated by the parameter dl_resp_token), the resulting state is DL_DATAXFER. If the current stream and responding stream are the same, the resulting state of that stream is DL_DATAXFER. These streams may only be the same when the response corresponds to the only outstanding connect indication. If the request fails, DL_ERROR_ACK is returned on the stream where the DL_CONNECT_RES primitive was received, and the resulting state of that stream and the responding stream is unchanged.

ERRORS

DL_ACCESS

The DLS user did not have proper permission to use the responding stream.

DL_BADCORR

The correlation number specified in this primitive did not correspond to apending connect indication.

DL_BADTOKEN

The token for the responding stream was not associated with a currently open stream.

DL_BADQOSPARAM

The quality of service parameters contained invalid values.

DL_BADQOSTYPE

The quality of service structure type was not supported by the DLS provider.

DL_OUTSTATE

The primitive was issued from an invalid state, or the responding stream was not in a valid state for establishing aconnection.

DL_PENDING

Current stream and responding stream is the same and there is more than one outstanding connect indication.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_CONNECT_CON Previous section.

NAME

DL_CONNECT_CON (dl_connect_con_t) - informs the local DLS user that the requested data link connection has been established. The primitive contains the DLSAP address of the responding DLS user and the quality of service parameters as selected by the responding DLS user.

SYNOPSIS

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

typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_resp_addr_length;
    t_uscalar_t  dl_resp_addr_offset;
    t_uscalar_t  dl_qos_length;
    t_uscalar_t  dl_qos_offset;
    t_uscalar_t  dl_growth;
} dl_connect_con_t;

PARAMETERS

dl_primitive

conveys DL_CONNECT_CON.

dl_resp_addr_length

conveys the length of the address of the responding DLSAP associated with the newly established data link connection.

dl_resp_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the responding DLSAP address begins.

dl_qos_length

conveys the length of the quality of service parameter values selected by the responding DLS user. The selected QOS values are conveyed in the appropriate structure defined in QOS Data Structures . A full specification of these QOS parameters and rules for negotiating their values is presented in Quality of Data Link Service . For any parameter the DLS provider does not support or cannot determine, the corresponding parameter value will be set to DL_UNKNOWN. If the DLS provider does not support any QOS parameters, this length field will be set to zero.

dl_qos_offset

conveys the offset from the beginning of the M_PROTO message block where the quality of service parameters begin.

dl_growth

defines a growth field for future enhancements to this primitive. Its value will be set to zero.

STATE

The message is valid in state DL_OUTCON_PENDING.

NEW STATE

The resulting state is DL_DATAXFER.

Data Link Provider Interface (DLPI) - DL_TOKEN_REQ Previous section.

NAME

DL_TOKEN_REQ (dl_token_req_t) - requests that a connection response token be assigned to the stream and returned to the DLS user. This token can be supplied in the DL_CONNECT_RES primitive to indicate the stream on which a connection will be established.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_token_req_t;

PARAMETERS

dl_primitive

conveys DL_TOKEN_REQ.

STATE

The message is valid in any state in which a local acknowledgement is not pending, as described in Allowable Sequence of DLPI Primitives .

RESPONSE

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

Data Link Provider Interface (DLPI) - DL_TOKEN_ACK Previous section.

NAME

DL_TOKEN_ACK (dl_token_ack_t) - this message is sent in response to DL_TOKEN_REQ; it conveys the connection response token assigned to the stream.

SYNOPSIS

The message consists of one M_PCPROTO message block, which contains the following structure.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_token;
} dl_token_ack_t;

PARAMETERS

dl_primitive

conveys DL_TOKEN_ACK.

dl_token

conveys the connection response token associated with the stream. This value must be a non-zero value. The DLS provider will generate a token value for each stream upon receipt of the first DL_TOKEN_REQ primitive issued on that stream. The same token value will be returned in response to all subsequent DL_TOKEN_REQ primitives issued on a stream.

STATE

The message is valid in any state in response to a DL_TOKEN_REQ.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_DATA_REQ Previous section.

NAME

DL_DATA_REQ - conveys a complete DLSDU from the DLS user to the DLS provider for transmission over the data link connection.
The DLS provider guarantees to deliver each DLSDU to the remote DLS user in the same order as received from the local DLS user. If the DLS provider detects unrecoverable data loss during data transfer, this may be indicated to the DLS user by a DL_RESET_IND, or by a DL_DISCONNECT_IND (if the connection is lost).

SYNOPSIS

The message consists of one or more M_DATA message blocks containing at least one byte of data.
To simplify support of a read/write interface to the data link layer, the DLS provider must recognize and process messages that consist of one or more M_DATA message blocks with no preceding M_PROTO message block. This message type may originate from the write() system call³.

STATE

The message is valid in state DL_DATAXFER. If it is received in state DL_IDLE or DL_PROV_RESET_PENDING, it should be discarded without generating an error.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the request is valid, no response is generated. If the request is erroneous, a STREAMS M_ERROR message should be issued to the DLS user specifying an errno value of EPROTO. This action should be interpreted as a fatal, unrecoverable, protocol error. A request is considered erroneous under the following conditions:

The primitive was issued from an invalid state. If the request is issued in state DL_IDLE or DL_PROV_RESET_PENDING, however, it is silently discarded with no fatal error generated.

The amount of data in the current DLSDU is not within the DLS provider's acceptable bounds as specified by dl_min_sdu and dl_max_sdu in the DL_INFO_ACK.

NOTE

Support of Direct User-Level Access

A STREAMS module would implement "more" field processing itself to support direct user-level access. This module could collect messages and send them in one larger message to the DLS provider, or break large DLSDUs passed to the DLS user into smaller messages. The module would only be pushed if the DLS user was a user-level process.

Data Link Provider Interface (DLPI) - DL_DATA_IND Previous section.

NAME

DL_DATA_IND - conveys a DLSDU from the DLS provider to the DLS user. The DLS provider guarantees to deliver each DLSDU to the local DLS user in the same order as received from the remote DLS user. If the DLS provider detects unrecoverable data loss during data transfer, this may be indicated to the DLS user by a DL_RESET_IND, or by a DL_DISCONNECT_IND (if the connection is lost).

SYNOPSIS

The message consists of one or more M_DATA blocks containing at least one byte of data.

STATE

The message is valid in state DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_DISCONNECT_REQ Previous section.

NAME

DL_DISCONNECT_REQ (dl_disconnect_req_t) - requests the DLS provider to disconnect an active data link connection or one that was in the process of activation, either outgoing or incoming, as a result of an earlier DL_CONNECT_IND or DL_CONNECT_REQ. If an incoming DL_CONNECT_IND is being refused, the correlation number associated with that connect indication must be supplied. The message indicates the reason for the disconnect.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_reason;
    t_uscalar_t  dl_correlation;
} dl_disconnect_req_t;

PARAMETERS

dl_primitive

conveys DL_DISCONNECT_REQ.

dl_reason

conveys the reason for the disconnect:
Reason for Disconnect:

DL_DISC_NORMAL_CONDITION

normal release of a data link connection

DL_DISC_ABNORMAL_CONDITION

abnormal release of a data link connection

DL_CONREJ_PERMANENT_COND

a permanent condition caused the rejection of a connect request

DL_CONREJ_TRANSIENT_COND

a transient condition caused the rejection of a connect request

DL_DISC_UNSPECIFIED

reason unspecified.

dl_correlation

if non-zero, conveys the correlation number that was contained in the DL_CONNECT_IND being rejected (see Multi-threaded Connection Establishment ). This value permits the DLS provider to associate the primitive with the proper DL_CONNECT_IND when rejecting an incoming connection. If the disconnect request is releasing a connection that is already established, or is aborting a previously sent DL_CONNECT_REQ, the value of dl_correlation should be zero.

STATE

The message is valid in any of the states DL_DATAXFER, DL_INCON_PENDING, DL_OUTCON_PENDING, DL_PROV_RESET_PENDING, DL_USER_RESET_PENDING.

NEW STATE

The resulting state is one of the disconnect pending states, as defined in Allowable Sequence of DLPI Primitives .

RESPONSE

If the disconnect is successful, DL_OK_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.

ERRORS

DL_BADCORR

The correlation number specified in this primitive did not correspond to apending connect indication.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_DISCONNECT_IND Previous section.

NAME

DL_DISCONNECT_IND (dl_disconnect_ind_t) - informs the DLS user that the data link connection on this stream has been disconnected, or that apending connection (either DL_CONNECT_REQ or DL_CONNECT_IND ) has been aborted. The primitive indicates the origin and the cause of the disconnect.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_originator;
    t_uscalar_t  dl_reason;
    t_uscalar_t  dl_correlation;
} dl_disconnect_ind_t;

PARAMETERS

dl_primitive

conveys DL_DISCONNECT_IND.

dl_originator

conveys whether the disconnect was DLS user or DLS provider originated (DL_USER or DL_PROVIDER, respectively ) .

dl_reason

conveys the reason for the disconnect:
Reason for Disconnect

DL_DISC_PERMANENT_CONDITION

connection released due to permanent condition

DL_DISC_TRANSIENT_CONDITION

connection released due to transient condition

DL_CONREJ_DEST_UNKNOWN

unknown destination for connect request

DL_CONREJ_DEST_UNREACH_PERMANENT

could not reach destination for connect request - permanent condition

DL_CONREJ_DEST_UNREACH_TRANSIENT

could not reach destination for connect request - transient condition

DL_CONREJ_QOS_UNAVAIL_PERMANENT

requested quality of service parameters permanently unavailable during connection establishment

DL_CONREJ_QOS_UNAVAIL_TRANSIENT

requested quality of service parameters temporarily unavailable during connection establishment

DL_DISC_UNSPECIFIED

reason unspecified

dl_correlation

if non-zero, conveys the correlation number that was contained in the DL_CONNECT_IND that is being aborted (see Multi-threaded Connection Establishment ). This value permits the DLS user to associate the message with the proper DL_CONNECT_IND. If the disconnect indication is indicating the release of a connection that is already established, or is indicating the rejection of a previously sent DL_CONNECT_REQ, the value of dl_correlation will be zero.

STATE

The message is valid in any of the states: DL_DATAXFER,DL_INCON_PENDING, DL_OUTCON_PENDING,DL_PROV_RESET_PENDING,DL_USER_RESET_PENDING.

NEW STATE

The resulting state is DL_IDLE.

Data Link Provider Interface (DLPI) - DL_RESET_REQ Previous section.

NAME

DL_RESET_REQ (dl_reset_req_t) - requests that the DLS provider initiate the resynchronization of a data link connection. This service is abortive, so no guarantee of delivery can be assumed about data that is in transit when the reset request is initiated.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_reset_req_t;

PARAMETERS

dl_primitive

conveys DL_RESET_REQ.

STATE

The message is valid in state DL_DATAXFER.

NEW STATE

The resulting state is DL_USER_RESET_PENDING.

RESPONSE

There is no immediate response to the reset request. However, as resynchronizationcompletes, DL_RESET_CON is sent to the initiating DLS user, resulting in state DL_DATAXFER. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

ERRORS

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_RESET_IND Previous section.

NAME

DL_RESET_IND (dl_reset_ind_t) - informs the DLS user that either the remote DLS user is resynchronizing the data link connection, or the DLS provider is reporting loss of data for which it can not recover. The indication conveys the reason for the reset.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_originator;
    t_uscalar_t  dl_reason;
} dl_reset_ind_t;

PARAMETERS

dl_primitive

conveys DL_RESET_IND.

dl_originator

conveys whether the reset was originated by the DLS user or DLS provider (DL_USER or DL_PROVIDER, respectively ) .

dl_reason

conveys the reason for the reset.
Reason for Reset

DL_RESET_FLOW_CONTROL

indicates flow control congestion

DL_RESET_LINK_ERROR

indicates a data link error situation

DL_RESET_RESYNCH

indicates a request for resynchronization of a data link connection.

STATE

The message is valid in state DL_DATAXFER.

NEW STATE

The resulting state is DL_PROV_RESET_PENDING.

RESPONSE

The DLS user should issue a DL_RESET_RES primitive to continue the resynchronization procedure.

Data Link Provider Interface (DLPI) - DL_RESET_RES Previous section.

NAME

DL_RESET_RES (dl_reset_res_t) - directs the DLS provider to complete resynchronizing the data link connection.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_reset_res_t;

PARAMETERS

dl_primitive

conveys DL_RESET_RES.

STATE

The primitive is valid in state DL_PROV_RESET_PENDING.

NEW STATE

The resulting state is DL_RESET_RES_PENDING.

RESPONSE

If the reset response is successful, DL_OK_ACK is sent to the DLS user resulting in state DL_DATAXFER. If the reset response is erroneous, DL_ERROR_ACK is returned and the resulting state is unchanged.

ERRORS

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the UNIX system error is indicated in the DL_ERROR_ACK.

Data Link Provider Interface (DLPI) - DL_RESET_CON Previous section.

NAME

DL_RESET_CON (dl_reset_con_t) - informs the reset-initiating DLS user that the reset has completed.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
} dl_reset_con_t;

PARAMETERS

dl_primitive

conveys DL_RESET_CON.

STATE

The message is valid in state DL_USER_RESET_PENDING.

NEW STATE

The resulting state is DL_DATAXFER.

Connectionless-mode Service Primitives

Scope

This section describes the primitives that support the connectionless-mode service of the data link layer. These primitives support the connectionless data transfer service described earlier.

List of Connectionless-mode Service Primitives

The connectionless-mode service primitives are listed below and are defined in the following man-pages:

 

DL_UNITDATA_REQ
DL_UNITDATA_IND
DL_UDERROR_IND
DL_UDQOS_REQ

Data Link Provider Interface (DLPI) - DL_UNITDATA_REQ Previous section.

NAME

DL_UNITDATA_REQ (dl_unitdata_req_t) - 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.

SYNOPSIS

The 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 {
    t_uscalar_t         dl_primitive;
    t_uscalar_t         dl_dest_addr_length;
    t_uscalar_t         dl_dest_addr_offset;
    dl_priority_t       dl_priority;
} dl_unitdata_req_t;

PARAMETERS

dl_primitive

conveys DL_UNITDATA_REQ.

dl_dest_addr_length

conveys 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_priority

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

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

RESPONSE

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.

ERRORS

DL_BADADDR

The destination DLSAP address was in an incorrect format or contained invalid information.

DL_BADDATA

The amount of data in the current DLSDU exceeded the DLS provider's DLSDU limit.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_UNSUPPORTED

Requested priority not supplied by provider.

Data Link Provider Interface (DLPI) - DL_UNITDATA_IND Previous section.

NAME

DL_UNITDATA_IND (dl_unitdata_ind_t) - conveys one DLSDU from the DLS provider to the DLS user.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
    t_uscalar_t  dl_group_address;
} dl_unitdata_ind_t;

PARAMETERS

dl_primitive

conveys DL_UNITDATA_IND.

dl_dest_addr_length

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

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 DLSAP address of the sending DLS user.

dl_src_addr_offset

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

dl_group_address

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

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_UDERROR_IND Previous section.

NAME

DL_UDERROR_IND (dl_uderror_ind_t) - 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.

SYNOPSIS

The message consists of either one M_PROTO message block or one M_PCPROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_unix_errno;
    t_uscalar_t  dl_errno;
} dl_uderror_ind_t;

PARAMETERS

dl_primitive

conveys DL_UDERROR_IND.

dl_dest_addr_length

conveys the length of the DLSAP address of the destination DLS user.

dl_dest_addr_offset

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

dl_unix_errno

conveys 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.

dl_errno

conveys the DLPI error code associated with the failure. See ERRORS in the description of DL_UNITDATA_REQ for the error codes that apply to an erroneous DL_UNITDATA_REQ. 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, due to 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.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_UDQOS_REQ Previous section.

NAME

DL_UDQOS_REQ (dl_udqos_req_t) - requests the DLS provider to apply the specified quality of service parameter values to subsequent data unit transmissions. These new values will remain in effect until another DL_UDQOS_REQ is issued.

SYNOPSIS

The message consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_qos_length;
    t_uscalar_t  dl_qos_offset;
} dl_udqos_req_t;

PARAMETERS

dl_primitive

conveys DL_UDQOS_REQ.

dl_qos_length

conveys the length, in bytes, of the requested quality of service parameter values. The values are conveyed in the appropriate structure defined in QOS Data Structures . The available range of QOS values that may be selected is specified by the dl_qos_range_length and dl_qos_range_offset parameters in the DL_INFO_ACK primitive. For any parameter whose value the DLS user does not wish to select, the value DL_QOS_DONT_CARE may be set and the DLS provider will maintain the current value for that parameter. See Quality of Data Link Service . for a full description of the quality of service parameters.

dl_qos_offset

conveys the offset from the beginning of the M_PROTO message block where the quality of service parameters begin.

STATE

The message is valid in state DL_IDLE.

NEW STATE

The resulting state is DL_UDQOS_PENDING.

RESPONSE

If the quality of service request is successful, DL_OK_ACK is sent to the DLS user and the resulting state is DL_IDLE. If the request fails, message DL_ERROR_ACK is returned and the resulting state is unchanged.

ERRORS

DL_BADQOSPARAM

The quality of service parameters contained values outside the range of those supported by the DLS provider.

DL_BADQOSTYPE

The quality of service structure type was not supported by the DLS provider.

DL_OUTSTATE

The primitive was issued from an invalid state.

Primitives to handle XID and TEST operations

Scope

This section describes the service primitives that support the XID and TEST operations. The DLS User can issue these primitives to the DLS Provider requesting the provider to send an XID or a TEST frame. On receipt of an XID or TEST frame from the remote side, the DLS Provider can send the appropriate indication to the User.

List of Primitives Handling XID and TEST operations

The primitives which handle XID and TEST operations are listed below and are defined in the following man-pages:

 

DL_TEST_REQ
DL_TEST_IND
DL_TEST_RES
DL_TEST_CON
DL_XID_REQ
DL_XID_IND
DL_XID_RES
DL_XID_CON

Data Link Provider Interface (DLPI) - DL_TEST_REQ Previous section.

NAME

DL_TEST_REQ (dl_test_req_t) - conveys one TEST command DLSDU from the DLS User to the DLS Provider for transmission to a peer DLS Provider.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
} dl_test_req_t;

PARAMETERS

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

conveys 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

RESPONSE

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.

ERRORS

DL_BADADDR

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

DL_SYSERR

A System error has occurred and the UNIX System error is indicated in the DL_ERROR_ACK.

DL_NOTSUPPORTED

Primitive is known but not supported by the DLS Provider

DL_OUTSTATE

The primitive was issued from an invalid state

DL_TESTAUTO

Previous bind request specified automatic handling of TEST responses.

DL_UNSUPPORTED

Requested service not supplied by provider.

Data Link Provider Interface (DLPI) - DL_TEST_IND Previous section.

NAME

DL_TEST_IND (dl_test_ind_t) - conveys the TEST response/indication DLSDU from the DLS Provider to the DLS User.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
} dl_test_ind_t;

PARAMETERS

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

conveys 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_TEST_RES Previous section.

NAME

DL_TEST_RES (dl_test_res_t) - conveys the TEST response DLSDU from the DLS User to the DLS Provider in response to a DL_TEST_IND.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
} dl_test_res_t;

PARAMETERS

dl_primitive

conveys DL_TEST_RES

dl_flag

indicates the flag values for the response as follows:

DL_POLL_FINAL

indicates if the poll/final bit is set.

dl_dest_addr_length

conveys 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_TEST_CON Previous section.

NAME

DL_TEST_CON (dl_test_con_t) - conveys the TEST response DLSDU from the DLS Provider to the DLS User in response to a DL_TEST_REQ.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
} dl_test_con_t;

PARAMETERS

dl_primitive

conveys DL_TEST_RES

dl_flag

indicates the flag values for the request as follows:

DL_POLL_FINAL

indicates if the poll/final bit is set.

dl_dest_addr_length

conveys 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 is 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_XID_REQ Previous section.

NAME

DL_XID_REQ (dl_xid_req_t) - conveys one XID DLSDU from the DLS User to the DLS Provider for transmission to a peer DLS User.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
} dl_xid_req_t;

PARAMETERS

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

conveys 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.

STATE

The message is valid in state DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

RESPONSE

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.

ERRORS

DL_BADADDR

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

DL_BADDATA

The amount of data in the current DLSDU exceeded the DLS Provider's DLSDU limit.

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 and the UNIX System error is indicated in the DL_ERROR_ACK.

DL_XIDAUTO

Previous bind request specified Provider would handle XID.

Data Link Provider Interface (DLPI) - DL_XID_IND Previous section.

NAME

DL_XID_IND (dl_xid_ind_t) - conveys an XID DLSDU from the DLS Provider to the DLS User.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
} dl_xid_ind_t;

PARAMETERS

dl_primitive

conveys DL_XID_IND

dl_flag

conveys 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

conveys 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.

STATE

The message is valid in state DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

RESPONSE

The DLS User must respond with a DL_XID_RES.

Data Link Provider Interface (DLPI) - DL_XID_RES Previous section.

NAME

DL_XID_RES (dl_xid_res_t) - conveys an XID DLSDU from the DLS User to the DLS Provider in response to a DL_XID_IND.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
} dl_xid_res_t;

PARAMETERS

dl_primitive

conveys DL_XID_RES

dl_flag

conveys the flag values associated with the received XID frame.

DL_POLL_FINAL

indicates if the poll/final bit is set.

dl_dest_addr_length

conveys 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_XID_CON Previous section.

NAME

DL_XID_CON (dl_xid_con_t) - conveys an XID DLSDU from the DLS Provider to the DLS User in response to a DL_XID_REQ.

SYNOPSIS

The 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_flag;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
} dl_xid_con_t;

PARAMETERS

dl_primitive

conveys DL_XID_CON

dl_flag

conveys the flag values associated with the received XID frame.

DL_POLL_FINAL

indicates if the poll/final bit is set.

dl_dest_addr_length

conveys 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 is 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.

STATE

The message is valid in states DL_IDLE and DL_DATAXFER.

NEW STATE

The resulting state is unchanged.

Acknowledged Connectionless-mode Service Primitives

Scope

This section describes the primitives that support the acknowledged connectionless-mode service of the data link layer. These primitives support the acknowledged connectionless data transfer service described earlier.

List of Acknowledged Connectionless-mode Service Primitives

The acknowledged connectionless-mode service primitives are listed below and are defined in the following man-pages:

 

DL_DATA_ACK_REQ
DL_DATA_ACK_IND
DL_DATA_ACK_STATUS_IND
DL_REPLY_REQ
DL_REPLY_IND
DL_REPLY_STATUS_IND
DL_REPLY_UPDATE_REQ
DL_REPLY_UPDATE_STATUS_IND

Data Link Provider Interface (DLPI) - DL_DATA_ACK_REQ Previous section.

NAME

DL_DATA_ACK_REQ (dl_data_ack_req_t) - this request is passed to the Data Link Provider to request that a DLSDU be sent to a peer DLS User using acknowledged connectionless mode data unit transmission procedures.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks containing one or more bytes 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
    t_uscalar_t  dl_priority;
    t_uscalar_t  dl_service_class;
} dl_data_ack_req_t;

PARAMETERS

dl_primitive

conveys DL_DATA_ACK_REQ

dl_correlation

conveys a unique identifier which will be returned in the DL_DATA_ACK_STATUS_IND primitive to allow the DLS User to correlate the status to the appropriate DL_DATA_ACK_REQ primitive.

dl_dest_addr_length

conveys 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 DLSAP address of the source DLS User.

dl_src_addr_offset

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

dl_priority

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

dl_service_class

specifies whether or not an acknowledge capability in the medium access control sublayer is to be used for the data unit transmission.

DL_RQST_RSP

request acknowledgement service from the medium access control sublayer if supported

DL_RQST_NORSP

no acknowledgement service requested from the medium access control sublayer.

STATE

This message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the request is erroneous, message DL_ERROR_ACK is returned, and the resulting state is unchanged. If the DLS Provider accepts the data for transmission,a DL_DATA_ACK_STATUS_IND is returned. This indication will indicate the success or failure of the data transmission. Although the exchange service is connectionless, in-sequence delivery is guaranteed for data sent by the initiating station.

ERRORS

DL_BADADDR

The destination DLSAP address was in an incorrect format or contained invalid information.

DL_BADDATA

The amount of data in the current DLSDU exceeded the DLS provider's DLSDU limit.

DL_NOTSUPPORTED

Primitive is valid, but not supported.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_UNSUPPORTED

Requested service or priority not supported by Provider (Request with response at the Medium Access Control sublayer).

Data Link Provider Interface (DLPI) - DL_DATA_ACK_IND Previous section.

NAME

DL_DATA_ACK_IND (dl_data_ack_ind_t) - conveys one DLSDU from the DLS Provider to the DLS User. This primitive indicates the arrival of a non-null, non-duplicate DLSDU from a peer Data Link User entity.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks containing one or more bytes 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 {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
    t_uscalar_t  dl_priority;
    t_uscalar_t  dl_service_class;
} dl_data_ack_ind_t;

PARAMETERS

dl_primitive

conveys DL_DATA_ACK_IND

dl_dest_addr_length

conveys 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

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 DLSAP address of the source DLS User.

dl_src_addr_offset

conveys the offset from the beginning of the M_PROTO message block where the source DLSAP address begins. address returned on the DL_BIND_ACK.

dl_priority

priority provided for the data unit transmission.

dl_service_class

specifies whether or not an acknowledge capability in the medium access control sublayer is to be used for the data unit transmission.

DL_RQST_RSP

use acknowledgement service in the medium access control sublayer.

DL_RQST_NORSP

no acknowledgement service to be used in the medium access control sublayer.

STATE

This message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_DATA_ACK_STATUS_IND Previous section.

NAME

DL_DATA_ACK_STATUS_IND (dl_data_ack_status_ind_t) - conveys the results of the previous associated DL_DATA_ACK_REQ from the DLS Provider to the DLS User.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_status;
} dl_data_ack_status_ind_t;

PARAMETERS

dl_primitive

conveys DL_DATA_ACK_STATUS_IND

dl_correlation

conveys the unique identifier passed with the DL_DATA_ACK_REQ primitive, to allow the DLS User correlate the status to the appropriate DL_DATA_ACK_REQ.

dl_status

indicates the success or failure of the previous associated acknowledged connectionless-mode data unit transmission request.

DL_CMD_OK

command accepted.

DL_CMD_RS

unimplemented or inactivated service.

DL_CMD_UE

LLC User Interface error

DL_CMD_PE

protocol error

DL_CMD_IP

permanent implementation dependent error

DL_CMD_UN

resources temporarily unavailable.

DL_CMD_IT

temporary implementation dependent error.

STATE

This message is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_REPLY_REQ Previous section.

NAME

DL_REPLY_REQ (dl_reply_req_t) - this request primitive is passed to the DLS Provider by the DLS User to request that a DLSDU be returned from a peer DLS Provider or that DLSDUs be exchanged between stations using acknowledged connectionless mode data unit exchange procedures.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks with one or more bytes of data.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
    t_uscalar_t  dl_priority;
    t_uscalar_t  dl_service_class;
} dl_reply_req_t;

PARAMETERS

dl_primitive

conveys DL_REPLY_REQ

dl_correlation

conveys a unique identifier which will be returned in the DL_REPLY_STATUS_IND primitive to allow the DLS User to correlate the status to the appropriate DL_REPLY_REQ primitive.

dl_dest_addr_length

conveys 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 DLSAP address of the source DLS User.

dl_src_addr_offset

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

dl_priority

priority provided for the data unit transmission.

dl_service_class

specifies whether or not an acknowledge capability in the medium access control sublayer is to be used for the data unit transmission.

STATE

This primitive is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the request is erroneous, message DL_ERROR_ACK is returned, and the resulting state is unchanged. If the message is valid, a DL_REPLY_STATUS_IND is returned. This will indicate the success or failure of the previous associated acknowledged connectionless-mode data unit exchange.

ERRORS

DL_BADADDR

The destination DLSAP address was in an incorrect format or contained invalid information.

DL_BADDATA

The amount of data in the current DLSDU exceeded the DLS provider's DLSDU limit.

DL_NOTSUPPORTED

Primitive is valid, but not supported.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_UNSUPPORTED

Requested service not supported by Provider (Request with response at the Medium Access Control sublayer).

Data Link Provider Interface (DLPI) - DL_REPLY_IND Previous section.

NAME

DL_REPLY_IND (dl_reply_ind_t) - this primitive is the service indication primitive for the acknowledged connectionless-mode data unit exchange service. It is passed from the DLS Provider to the DLS User to indicate either asuccessful request of a DLSDU from the peer data link user entity, or exchange of DLSDUs with a peer data link user entity.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by zero or more M_DATA blocks.

typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_dest_addr_length;
    t_uscalar_t  dl_dest_addr_offset;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
    t_uscalar_t  dl_priority;
    t_uscalar_t  dl_service_class;
} dl_reply_ind_t;

PARAMETERS

dl_primitive

conveys DL_REPLY_IND

dl_dest_addr_length

conveys 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 DLSAP address of the source DLS User.

dl_src_addr_offset

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

dl_priority

priority provided for the data unit transmission.

dl_service_class

specifies whether or not an acknowledge capability in the medium access control sublayer is to be used for the data unit transmission.

STATE

This primitive is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_REPLY_STATUS_IND Previous section.

NAME

DL_REPLY_STATUS_IND (dl_reply_status_ind_t) - this indication primitive is passed from the DLS Provider to the DLS User to indicate the success or failure of the previous associated acknowledged connectionless mode data unit exchange request.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by zero or more M_DATA blocks.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_status;
} dl_reply_status_ind_t;

PARAMETERS

dl_primitive

conveys DL_REPLY_STATUS_IND

dl_correlation

conveys the unique identifier passed with the DL_REPLY_REQ primitive, to allow the DLS User correlate the status to the appropriate DL_REPLY_REQ.

dl_status

Indicates the success or failure of the previous associated acknowledged connectionless-mode data unit exchange request.

DL_CMD_OK

command accepted.

DL_CMD_RS

unimplemented or inactivated service.

DL_CMD_UE

LLC User Interface error

DL_CMD_PE

protocol error

DL_CMD_IP

permanentimplementation dependent error

DL_CMD_UN

resources temporarily available.

DL_CMD_IT

temporary implementation dependent error.

DL_RSP_OK

response DLSDU present.

DL_RSP_RS

unimplemented or inactivated service.

DL_RSP_NE

response DLSDU never submitted.

DL_RSP_NR

response DLSDU not requested.

DL_RSP_UE

LLC User interface error.

DL_RSP_IP

permanent implementation dependent error.

DL_RSP_UN

resources temporarily unavailable.

DL_RSP_IT

temporary implementation dependent error.

STATE

This primitive is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Data Link Provider Interface (DLPI) - DL_REPLY_UPDATE_REQ Previous section.

NAME

DL_REPLY_UPDATE_REQ (dl_reply_update_req_t) - conveys a DLSDU to the DLS Provider from the DLS User to be held by the DLS Provider and sent out at a later time when requested to do so by the peer DLS Provider.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below, followed by one or more M_DATA blocks.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_src_addr_length;
    t_uscalar_t  dl_src_addr_offset;
} dl_reply_update_req_t;

PARAMETERS

dl_primitive

conveys DL_REPLY_UPDATE_REQ

dl_correlation

conveys context specific information to be returned in the DL_REPLY_UPDATE_STATUS_IND primitive to allow the DLS User correlate the status to the appropriate previous request.

dl_src_addr_length

conveys the length of the DLSAP address of the source DLS User.

dl_src_addr_offset

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

STATE

This primitive is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

RESPONSE

If the request is erroneous, a DL_ERROR_ACK is returned with the appropriate error code. Otherwise, a DL_REPLY_UPDATE_STATUS_IND is returned, which indicates the success or failure of the DL_REPLY_UPDATE_REQ.

ERRORS

DL_BADDATA

The amount of data in the DLSDU exceeded the DLS Provider's DLSDU limit.

DL_NOTSUPPORTED

Primitive is known, but not supported.

DL_OUTSTATE

The primitive was issued from an invalid state.

Data Link Provider Interface (DLPI) - DL_REPLY_UPDATE_STATUS_IND Previous section.

NAME

DL_REPLY_UPDATE_STATUS_IND (dl_reply_update_status_ind_t) - this primitive is the service confirmation primitive for the reply data unit preparation service. This primitive is sent to the DL User from the DLS Provider to indicate the success or failure of the previous associated data unit preparation request.

SYNOPSIS

Consists of one M_PROTO message block containing the structure shown below.
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_correlation;
    t_uscalar_t  dl_status;
} dl_reply_update_req_t;

PARAMETERS

dl_primitive

conveys DL_UPDATE_STATUS_IND

dl_correlation

Indicates the context information passed with the DL_REPLY_UPDATE_REQ to allow the DLS User correlate the status with the appropriate previous request.

dl_status

indicates the success or failure of the previous associated data unit preparation request.

DL_CMD_OK

command accepted.

DL_CMD_RS

unimplemented or inactivated service.

DL_CMD_UE

LLC User Interface error

DL_CMD_PE

protocol error

DL_CMD_IP

permanentimplementation dependent error

DL_CMD_UN

resources temporarily available.

DL_CMD_IT

temporary implementation dependent error.

DL_RSP_OK

response DLSDU present.

DL_RSP_RS

unimplemented or inactivated service.

DL_RSP_NE

response DLSDU never submitted.

DL_RSP_NR

response DLSDU not requested.

DL_RSP_UE

LLC User interface error.

DL_RSP_IP

permanent implementation dependent error.

DL_RSP_UN

resources temporarily unavailable.

DL_RSP_IT

temporaryimplementation dependent error.

STATE

This primitive is valid in state DL_IDLE.

NEW STATE

The resulting state is unchanged.

Footnotes

1.: To forestall portability problems, it is recommended that applications should not use values larger than 2³² - 1.
2.: Readers should note that the list of data links supported by the interface may be augmented and is published on the World-Wide Web in U019 at http://www.xopen.org (under Sales and Ordering). This Corrigendum will contain relevant additional information such as recognised implementors' agreements/guidelines for common data link providers.
3.: This does not imply that DLPI will directly support a pure read/write. If such an interface is desired, a STREAMS module could be implemented to be pushed above the DLS provider.

Contents

Next section

Index