The Data Link Provider Interface (DLPI) enables a data link service
Specifically, the interface is intended to support X.25 LAPB, BX.25
level 2, SDLC, ISDN LAPD, Ethernet, CSMA/CD, FDDI, token ring, token bus,
Bisync, Frame Relay, Native ATM Services, Fiber Channel, and HIPPI.
Among the expected data link service users are
implementations of the OSI network layer and SNA path control.
Readers should note that the list of data links supported by the interface may be augmented in future, so provision is made to publish availability of these, in a Corrigendum, reference U019. This DLPI Corrigendum U019 is available on the World-Wide Web, at http://www.opengroup.org/pubs/catalog/u019. Corrigendum U019 may also be used to publish relevant additional information such as recognised implementors' agreements/guidelines for common data link providers.
This specification assumes the reader is familiar with OSI Reference Model (see referenced documents) terminology, OSI Data Link Services, and STREAMS. Although there are no formal standards for a STREAMS environment, extensive descriptions of STREAMS and STREAMS programming can be found in the referenced document STREAMS.
The model of the data link layer is presented here to describe concepts that are used throughout the specification of DLPI. It is described in terms of an inter face architecture, as well as addressing concepts needed to identify different components of that architecture. The description of the model assumes familiarity with the OSI Reference Model.
DLPI is an implementation of the first type of standard. It specifies
an interfa ce to the services of the data link layer.
The data link interface is the boundary between the network and data link layers of the OSI Reference Model. The network layer entity is the user of the services of the data link interface (DLS user), and the data link layer entity is the provider of those services (DLS provider). This interface consists of a set of primitives which provide access to the data link layer services, plus the rules for using those primitives (state transition rules). A data link interface service primitive might request a particular service or indicate a pending event.
To provide uniformity among the various UNIX system networking
products, service interfaces that map to the Data Link and Transport
Layers of the OSI Reference Model have been developed.
The service primitives that make up
these interfaces are defined as STREAMS messages that are transferred
between the user and provider of the service. DLPI is one such kernel-level
interface, and is
targeted for STREAMS protocol modules that either use or provide
data link services. In addition, user programs that wish to access a
STREAMS-based data link provider directly may do so
Referring to the abstract view of DLPI (see
DLPI is intended to free data link users from specific knowledge of the characteristics of the data link provider. Specifically, the definition of DLPI hopes to achieve the goal of allowing a DLS user to be implemented independently of a specific communications medium. Any data link provider (supporting any communications medium) that conforms to the DLPI specification may be substituted beneath the DLS user to provide the data link services. Support of a new DLS provider should not require any changes to the implementation of the DLS user.
The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. Data may be lost or corrupted in this service mode, however, due to provider-initiated resynchronization or connection aborts.
The connectionless mode is message-oriented and supports data transfer in self-contained units with no logical relationship required between units. Because there is no acknowledgement of each data unit transmission, this service mode can be unreliable in the most general case. However, a specific DLS provider can provide assurance that messages will not be lost, duplicated, or reordered.
The acknowledged connectionless mode provides the means by which a data link user can send data and request the return of data at the same time. Although the exchange service is connectionless, in-sequence delivery is guaranteed for data sent by the initiating station. The data unit transfer is point-to-point.
A called DLS user may either accept or deny a request for a data link connection. If the request is accepted, a connection is established between the DLS users and they enter the data transfer phase. For both the calling and called DLS users, only one connection may be established per stream. Thus, the stream is the communication endpoint for a data link connection.
The called DLS user may choose to accept a connection on the stream where it received the connect request, or it may open a new stream to the DLS provider and accept the connection on this new, responding stream. By accepting the connection on a separate stream, the initial stream can be designated as a listening stream through which all connect requests will be processed.
As each request arrives, a new stream (communication endpoint) can be opened to handle the connection, enabling subsequent requests to be queued on a single stream until they can be processed.
Connectionless data transfer does not guarantee that data units will be delivered to the destination user in the order in which they were sent. Furthermore, it does not guarantee that a given data unit will reach the destination DLS user, although a given DLS provider may provide assurance that data will not be lost.
Acknowledged connectionless data transfer guarantees that data units will be delivered to the destination user in the order in which they were sent. A data link user entity can send a data unit to the destination DLS User, request a previously prepared data unit from the destination DLS User, or exchange data units.
Two styles of DLS provider are defined by DLPI, distinguished by the way they enable a DLS user to choose a particular PPA. The style 1 provider assigns a PPA based on the major/minor device the DLS user opened. One possible implementation of a style 1 driver would reserve a major device for each PPA the data link driver would support. This would allow the STREAMS clone open feature to be used for each PPA configured. This style of provider is appropriate when few PPAs will be supported.
If the number of PPAs a DLS provider will support is large, a
provider implementation is more suitable.
The style 2 provider requires a DLS
user to explicitly identify the desired PPA using a special
service primitive. For a style 2 driver,
DLPI provides a mechanism to get or modify the physical address.
The primitives to handle these functions are described in
The DLS User uses the supported primitives (DL_ATTACH_REQ, DL_BIND_REQ, DL_ENABMULTI_REQ, DL_PROMISCON_REQ) to define a set of enabled physical and SAP address components on a per Stream basis. It is invalid for a DLS Provider to ever send upstream a data message for which the DLS User on that stream has not requested. The burden is on the provider to enforce by any means that it chooses the isolation of SAP and physical address space effects on a per-stream basis.
The DLSAP address identifies a particular data link service access point that is associated with a stream (communication endpoint). A bind service primitive enables a DLS user to either choose a specific DLSAP by specifying its DLSAP address, or to determine the DLSAP associated with a stream by retrieving the bound DLSAP address. This DLSAP address can then be used by other DLS users to access a specific DLS user. The format of the DLSAP address is specific to the DLS provider, and should be described in the provider-specific addendum documentation. However, DLPI provides a mechanism for decomposing the DLSAP address into component pieces. The DL_INFO_ACK primitive returns the length of the SAP component of the DLSAP address, along with the total length of the DLSAP address.
Certain DLS Providers require the capability of binding on multiple DLSAP addresses. This can be achieved through subsequent binding of DLSAP addresses. DLPI supports peer and hierarchical binding of DLSAPs. When the User requests peer addressing, the DLSAP specified in a subsequent bind may be used in lieu of the DLSAP bound in the DL_BIND_REQ. This allows for a choice to be made between a number of DLSAPs on a stream when determining traffic based on DLSAP values. An emample of this would be to specify various ether_type values as DLSAPs. The DL_BIND_REQ, for example, could be issued with ether_type value of IP, and a subsequent bind could be issued with ether_type value of ARP. The Provider may now multiplex off of the ether_type field and allow for either IP or ARP traffic to be sent up this stream.
When the DLS User requests hierarchical binding, the subsequent bind specifies a DLSAP that will be used in addition to the DLSAP bound using a DL_BIND_REQ. This allows additional information to be specified, which will be used in a header or for demultiplexing. An example of this would be to use hierarchical bind to specify the OUI (Organizationally Unique Identifier) to be used by SNAP.
If a DLS Provider supports peer subsequent bind operations, the first SAP that is bound is used as the source SAP when there is ambiguity. DLPI supports the ability to associate several streams with a single DLSAP, where each stream may be a unique data link connection endpoint. However, not all DLS providers can support such configurations because some DLS providers may have no mechanism beyond the DLSAP address for distinguishing multiple connections. In such cases, the provider will restrict the DLS user to one stream per DLSAP.
To obviate the need for tying up system resources for all possible destination DLSAPs, a connection management stream utility is defined in DLPI. A connection management stream is one that receives any connect requests that are not destined for currently bound DLSAPs capable of receiving connect indications. With this mechanism, a special listener can handle incoming connect requests intended for a set of DLSAPs, by opening a connection management stream to the DLS provider which will retrieve all connect requests arriving through a particular PPA. In the model, therefore, there may be a connection management stream per PPA.