2    Data Link Provider Interface

Digital UNIX provides the dlb STREAMS pseudodriver, which is a partial implementation of the Data Link Provider Interface (DLPI).

This chapter describes the dlb STREAMS pseudodriver and the basics of DLPI. A PostScript copy of the DLPI specification ( dlpi.ps) is located in the /usr/share/doclib/dlpi directory.

Note

You must have the OSFPGMK200 subset installed to access the DLPI specification online.

Figure 2-1 highlights the data link interfaces and shows their relationship to the rest of the network programming environment.

Figure 2-1: DLPI Interface

Note

The dlb STREAMS pseudodriver supports a subset of DLPI primitives. See Section 2.4 for a list of the supported primitives.

The data link interface is the boundary between the network and data link layers of the OSI reference model. A network application, or data link service user (DLS user), uses the services of the data link interface. A driver, pseudodriver, or data link service provider (DLS provider), provides the services to the data link layer.

DLPI specifies a STREAMS kernel-level service interface that maps to the OSI reference model. It defines an interface to the services of the data link layer and provides a definition of service primitives that make up the interface.

Figure 2-2 shows the components of DLPI. The DLS user communicates with the DLS provider using request/response primitives; the DLS provider communicates with the DLS user with indication/confirmation primitives.

Figure 2-2: DLPI Service Interface

The primitives that Digital UNIX supports are listed in Section 2.4.

2.1    Modes of Communication

DLPI supports three modes of communication:

• Connection

  Enables a DLS user to establish a data link connection, transfer data over that connection, reset the link, and release the connection when the conversation has terminated.

  The connection service establishes a data link connection between a local DLS user and a remote DLS user for the purpose of sending data. Only one data link connection is allowed on each Stream.

• Connectionless

  Enables a DLS user to transfer units of data to peer DLS users without incurring the overhead of establishing and releasing a connection. The connectionless service does not, however, guarantee reliable delivery of data units between peer DLS users (for instance, lack of flow control may cause buffer resource shortages that result in data being discarded).

  Once a Stream has been initialized using the local management services, it may be used to send and receive connectionless data units.

  Note

  Digital UNIX supports only the connectionless mode of communication.

• Acknowledged connectionless

  Designed for general use for the reliable transfer of information between peer DLS users. These services are intended for applications that require acknowledgement of cross-LAN data unit transfer, but wish to avoid the complexity associated with the connection-mode services. Although the exchange service is connectionless, in-sequence delivery is guaranteed for data sent by the initiating station.

2.2    Types of Service

This section describes the types of service, or phases of communication, supported by DLPI. Note that the types of service available depend on the mode of communication (connection, connectionless, acknowledged connectionless) between the DLS provider and the DLS user.

DLPI supports the following types of service:

• Local management services

  • Information reporting service

  • Attach service

  • Bind service

• Connection-mode services

  • Connection establishment

  • Data transfer

  • Connection release

  • Reset service

• Connectionless-mode services

  • Connectionless data transfer

  • Quality of Service (QOS) management

  • Error reporting

• Acknowledged connectionless-mode services

  • Acknowledged connectionless-mode data transfer

  • Quality of service (QOS) management

  • Error reporting

2.2.1    Local Managment Services

The local management services apply to all three modes of communication supported by DLPI. They enable a DLS user to initialize a Stream that is connected to a DLS provider and to establish an identity with that provider. The local management services support the following:

• Information reporting service

  Provides information about the DLPI Stream to the DLS user.

• Attach service

  Assigns a physical point of attachment (PPA) to a Stream. See Section 2.3 for more information.

• Bind service

  Associates a data link service access point (DLSAP) with a Stream.

2.2.2    Connection-Mode Services

The connection-mode services allow two DLS users to establish a data link connection between them to exchange data, and to reset the link and release the connection when the conversation is through. The connection-mode services support the following:

• Connection establishment service

  Establishes a data link connection between a local DLS user and a remote DLS user for the purposes of sending data.

• Data transfer service

  Provides for the exchange of user data in either direction or both directions simultaneously. Data is sent in logical groups called data link service data units (DLSDUs) and is guaranteed to be delivered in the order in which it was sent.

• Connection release service

  Enables either the DLS user or DLS provider to break an established connection.

• Reset service

  Allows a DLS user to resynchronize the use of a data link connection, or a DLS provider to report detected loss of data unrecoverable within the data link service.

2.2.3    Connectionless-Mode Services

The connectionless-mode services allow DLS users to exchange data without incurring the overhead of establishing and releasing a connection. The connectionless-mode services support the following:

• Connectionless data transfer service

  Provides for the exchange of user data (DLSDU) in either direction or in both directions simultaneously.

• Quality of service (QOS) management service

  Enables a DLS user to specify the quality of service it can expect for each invocation of the connectionless data transfer service.

• Error reporting service

  Provides a means to notify a DLS user that a previously sent data unit either produced an error or could not be delivered. However, the error reporting service does not guarantee that an error indication will be issued for every undeliverable data unit.

2.2.4    Acknowledged Connectionless-Mode Data Transfer

The acknowledged connectionless-mode data transfer services are designed for general use for the reliable transfer of data between peer DLS users. These services are intended for applications that require acknowledgment of data transfer between local area networks, but wish to avoid using the connection mode services. In-sequence delivery is guaranteed for data sent by the initiating station. The following services are supported:

• Acknowledged connectionless-mode data transfer service

  Provides for the exchange of DLSDUs which are acknowledged at the LLC sublayer.

• Quality of service (QOS) management service

  Enables a DLS user to specify the quality of service it can expect for each invocation of the connectionless data transfer service.

• Error reporting service

  Provides a means to notify a DLS user that a previously sent data unit either produced an error or could not be delivered. However, the error reporting service does not guarantee that an error indication will be issued for every undeliverable data unit.

2.3     DLPI Addressing

Each DLPI user must establish an identity to communicate with other data link users. This identity consists of the following pieces of information:

• Physical attachment identification

  This identifies the physical medium over which the DLS user communicates. The importance of identifying the physical medium is particularly evident on systems that are attached to multiple physical media. See Section 2.5 for information about identifying the available physical points of attachment (PPAs) on your system.

• Data link user identification

  The DLS user must register with the DLS provider so that the provider can deliver protocol data units destined for that user.

The format of the DLSAP address is an unsigned character array containing the Medium Access Control (MAC) addresses followed by the bound Service Access Point (SAP). The SAP is usually two bytes in the case of Ethernet, or one byte in the case of ISO 8802-2 (IEEE 802.2). The one exception is when a HIERACHICAL DL_SUBS_BIND_REQ is processed. In that case, the DLSAP address consists of the MAC address, the SNAP SAP (0xAA), and a five-byte SNAP.

Figure 2-3 illustrates the components of this identification approach.

Figure 2-3: Identifying Components of a DLPI Address

The PPA is the point at which a system attaches itself to a physical communications medium. All communication on that physical medium funnels through the PPA. On systems where a DLS provider supports more than one physical medium, the DLS user must identify the medium through which it will communicate. A PPA is identified by a unique PPA identifier.

DLPI defines the following two styles of DLS provider, which are 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. A style 1 driver can be implemented so that it reserves a major device for each PPA the data link driver would support.

  This implementation of a style 1 driver allows the STREAMS clone open feature to be used for each PPA configured. Style 1 providers are appropriate when few PPAs are supported.

• The style 2 provider requires a DLS user to identify a PPA explicitly, using a special attach service primitive. For a style 2 driver, the open system call creates a Stream between the DLS user and DLS provider. Then, the attach primitive associates a particular PPA with that Stream. The format of the PPA identifier is specific to the DLS provider.

  Digital UNIX supports only the style 2 provider because it is more suitable for supporting large numbers of PPAs.

2.4     DLPI Primitives

Table 2-1 lists and describes the DLPI primitives that Digital UNIX supports in the dlb STREAMS pseudodriver. For a complete list of DLPI primitives see the DLPI specification in the /usr/share/doclib/dlpi/dlpi.ps file.

Table 2-1: DLPI Primitives Supported in Digital UNIX

2.5    Identifying Available PPAs

When compiled and run as root on a Digital UNIX system, the following program opens the STREAMS device /dev/streams/dlb and prints to the screen the PPAs available on the system. The PPA number should be passed in using the dl_ppa field of the DL_ATTACH_REQ DLPI primitive.

#include <sys/ioctl.h>
#include <stropts.h>
#include <errno.h>
#include <fcntl.h>

 

#define ND_GET ('N' << 8 + 0)
#define BUFSIZE 256

 

main()
{
        int i;
        int fd;
        char buf [BUFSIZE];
        struct strioctl stri;

 

        fd = open("/dev/streams/dlb", O_RDWR, 0);
        if (fd < 0) {
                perror("open");
                exit(1);
        }

 

        sprintf(buf, "dl_ifnames");
        stri.ic_cmd = ND_GET;
        stri.ic_timout = -1;
        stri.ic_len = BUFSIZE;
        stri.ic_dp = buf;

 

        if (ioctl(fd, I_STR, &stri) < 0) {
                perror("ioctl");
                exit(1);
        }

 

        printf("Valid PPA names on this system are:\n");
        for (i=0; i<stri.ic_len; i++)  {
                if (buf[i] == 0)
                        printf(" ");
                else
                        printf("%c",buf[i]);
        }
        printf("\n");
}