The AIX Data Link Provider Interface (DLPI) implementation is designed to follow AT&T's "UNIX International OSI Work Group Data Link Provider Interface" Version 2 (DRAFT) specification. You can obtain a copy electronically if you have Internet access. Refer to "Obtaining Copies of the DLPI Specifications" for information about obtaining the DLPI specification.
It is assumed that you are familiar with the DLPI Version 2 specification published by UNIX International, RFC1042, and the various IEEE 802.x documents.
Note: In the text below, the term dlpi refers to the driver, while DLPI refers to the specification.
The dlpi driver is implemented as a style 2 provider and supports both the connectionless and connection-oriented modes of communication. For a list of the primitives supported by the dlpi driver, see "DLPI Primitives".
Information pertinent to specific primitives implemented in the dlpi driver is documented in the man page for that primitive.
The dlpi driver supports generic Common Data Link Interface (CDLI) network interfaces by allowing the user to specify the particular packet format necessary for the transmission media over which the stream is created. Using the M_IOCTL or M_CTL streams message, the user can specify the packet format. If no packet format is specified, the default is NS_PROTO.
The DLPI user specifies the packet format through the STREAMS I_STR ioctl. For example, to change the address format to one compatible with AIX Version 3.2.5:
int
fixaddr(int fd) {
int old=NS_PROTO_DL_COMPAT;
return istr(fd, DL_PKT_FORMAT, (char *)&old, sizeof(int));
}
To select a raw stream, enter:
int
beraw(int fd) {
int raw=NS_INCLUDE_MAC;
return istr(fd, DL_PKT_FORMAT, (char *)&raw, sizeof(int));
}
The DLPI user is allowed one packet format specification per stream. This packet format must be specified after the attach and before the bind. Otherwise, an error is generated.
The packet formats defined in /usr/include/sys/cdli.h follow:
The packet formats defined in the /usr/include/sys/dlpi_aix.h file are:
| NS_PROTO_DL_COMPAT | Use the AIX Version 3.2.5 DLPI address format. |
| NS_PROTO_DL_DONTCARE | No addresses present in DL_UNITDATA_IND. For the DL_UNITDATA_IND primitive, DLPI provides the header information in the dl_unitdata_ind_t structure. |
All packet formats except NS_INCLUDE_MAC accept downstream addresses in the following form:
mac_addr.dsap[.snap].
Individually, packet formats have the following requirements:
The dlpi driver can support all generic interface types. DLPI is implemented to allow the user to specify address resolution routines for input and output using the STREAMS I_STR ioctl or to rely on the system default routines. AIX provides default address resolution routines (stored in the /usr/include/sys/ndd.h file) that are interface specific.
The default input address resolution routine is:
ndd->ndd_demuxer->nd_address_input
The dlpi driver calls the input address resolution routine with a pointer to the MAC header (and, optionally, the LLC header) and a pointer to a memory buffer (mbuf) structure containing data. The actual contents of the data area depend on which type of packet format was specified. (See "Packet Format Registration Specifics".)
The default output address resolution routine is:
ndd->ndd_demuxer->nd_address_resolve
The dlpi driver calls the output address resolution routine with a pointer to an output_bundle structure (described in /usr/include/net/nd_lan.h), an mbuf structure, and an ndd structure. The driver assigns the destination address to key_to_find and copies the pkt_format and bind time llc into helpers. If the user has provided a different DSAP than what was set at bind time, the driver also copies the DSAP values into helpers.The output resolution routine completes the MAC header and calls the ndd_output subroutine.
If you choose to specify an input and/or output address resolution routine, use the following sample code:
noinres(int fd) {
return istr(fd, DL_INPUT_RESOLVE, 0);
}
The dlpi driver supports the following ioctl operations:
These commands and their associated data structures are described in the /usr/include/sys/dlpi_aix.h header file.
Note: The ioctl commands that require an argument longer than one long word, or that specify a pointer for either reading or writing, must use the I_STR format, as in the following example:
int
istr(int fd, int cmd, char *data, int len) {
struct strioctl ic;
ic.cmd = cmd;
ic.timout = -1;
ic.dp = data;
ic.dp = data;
ic.len = len;
return ioctl(fd, I_STR, &ic);
}
| DL_ROUTE | Disables the source routing on the current stream, queries the Dynamic Route Discovery (DRD) for a source route, or statically assigns a source route to this stream. It is only accepted when the stream is idle (DL_IDLE).
As an example, the following code can be used to discover the source route for an arbitrary address: char * getroute(int fd, char *addr, int len) { static char route[MAXROUTE_LEN]; bcopy(addr, route, len); if (istr(fd, DL_ROUTE, route, len)) return 0; return route; } |
| DL_TUNE_LLC | Allows the DLS user to alter the default LLC tunable parameters. The argument must point to an llctune_t data structure.
The flags field is examined to determine which, if any, parameters should be changed. Each bit in the flags field corresponds to a similarly named field in the llctune_t; if the bit is set, the corresponding parameter is set to the value in llctune_t. Only the current stream is affected, and changes are discarded when the stream is closed. If the F_LLC_SET flag is set and the user has root authority, the altered parameters are saved as the new default parameters for all new streams. This command returns as its argument an update of the current tunable parameters. For example, to double the t1 value, the following code might be used: int more_t1(int fd) { llctune_t t; t.flags = 0; if (istr(fd, DL_TUNE_LLC, &t, sizeof(t))) return -1; t.flags = F_LLC_T1; t.t1 *= 2; return istr(fd, DL_TUNE_LLC, &t, sizeof(t)); } To query the tunables, issue DL_TUNE_LLC with the flags field set to zero. This will alter no parameters and return the current tunable values. |
| DL_ZERO_STATS | Resets the statistics counters to zero. The driver maintains two independent sets of statistics, one for each stream (local), and another that is the cumulative statistics for all streams (global).
This command accepts a simple boolean argument. If the argument is True (nonzero), the global statistics are zeroed. Otherwise, only the current stream's statistics are zeroed. For example, to zero the statistics counters on the current stream, the following code might be used: int zero_stats(int fd) { return ioctl(fd, DL_ZERO_STATS, 0); } |
| DL_SET_REMADDR | Allows XID/TEST exchange on connection-oriented streams while still in the DL_IDLE state.
The dlpi driver uses both the source (remote) address and the dl_sap to determine where to route incoming messages for connection-oriented streams. The remote address is ordinarily specified in DL_CONNECT_REQ. If the DLS user needs to exchange XID or TEST messages before connecting to the remote station, DL_SET_REMADDR must be used. Note: Note that this command is not necessary if XID and TEST messages are to be exchanged only when the state is DL_DATAXFER. The argument to this command is the remote MAC address. One possible code fragment might be: int setaddr(int fd, char *addr, int len) { return istr(fd, DL_SET_REMADDR, addr, len); } |
Dynamic Route Discovery (DRD) is an algorithm used to automatically discover the proper source route that reaches a remote station on either a token ring or a Fiber Distributed Data Interface (FDDI) network. It relieves the DLS user from discovering and maintaining source routes. The algorithm implements the spanning tree, as recommended by 802.5.
When the DLS user issues a transmission request (for example, DL_CONNECT_REQ or DL_UNITDATA_REQ) on a medium supporting source routing, the DRD algorithm consults a local cache of source routes. If there is a hit, the cached source route is used immediately. Otherwise, the DRD queues the transmission request and starts the discovery algorithm. If the algorithm finds a source route, the new route is cached, and the queued requests are transmitted using this new route. If the algorithm times out with no replies (approximately 10 seconds), the queued requests are rejected.
The cache is periodically flushed of stale entries. An entry becomes stale after 5 minutes of no new requests.
Note: After a connection is established, the source route discovered during the connection setup is used to the exclusion of the DRD. This has two effects:
The DRD is selectable on a per-media basis when the dlpi driver is first loaded into the kernel. By default, the DRD is disabled for all media types. It can be enabled by appending the string ",r" (uses routing) to the argument field in /etc/dlpi.conf. Once selected, it is used by all physical points of attachment (PPAs) for that media type. The following example configurations both show token ring and FDDI configured, first in a default configuration and then with DRD enabled.
d+ dlpi tr /dev/dlpi/tr d+ dlpi fi /dev/dlpi/fi
d+ dlpi tr,r /dev/dlpi/tr d+ dlpi fi,r /dev/dlpi/fi
The following sample code fragment works with the 4.1 and later versions of DLPI:
if (raw_mode) { if (mp->b_datap->db_type == M_PROTO) { union DL_primitives *p; p = (union DL_primitives *)mp->b_rptr; if (p->dl_primitive == DL_UNITDATA_IND) { mblk_t *mpl = mp->b_cont; freeb(mp); mp = mpl; } } }The above code fragment discards the DL_UNITDATA_IND header. For compatibility with future releases, it is recommended that you parse the frame yourself. The MAC and LLC headers are presented in the M_DATA message for both promiscuous mode and raw mode.
Raw mode currently accepts, but does not require, a DL_UNITDATA_REQ. In a future release of AIX, raw mode will not accept a DL_UNITDATA_REQ; only M_DATA will be accepted.
The dlpi driver supports the 802.2 connection-oriented service over the CDLI-based media 802.3, token ring, and FDDI. Other CDLI-based media can be supported provided the media implementation follows the IEEE 802.x recommendations.
The DL_BIND_REQ primitive accepts values for some fields (refer to the DL_BIND_REQ primitive in AIX Version 4.3 Technical Reference: Communications Volume 1).
The DL_OUTPUT_RESOLVE and DL_INPUT_RESOLVE ioctl commands replace the default address resolution routines for the current stream. They are no longer accepted from user space; the message type must be M_CTL (not M_IOCTL), and they are only accepted before the stream is bound. DL_INPUT_RESOLVE is accepted as an M_IOCTL message only if its argument is zero; this allows the user to disable input address resolution. Output address resolution cannot be disabled--use the raw mode if transparent access to the medium is required.
The DL_PKT_FORMAT ioctl command now recognizes and handles the following packet formats: NS_PROTO, NS_PROTO_SNAP, NS_PROTO_DL_DONTCARE, NS_PROTO_DL_COMPAT, NS_INCLUDE_LLC, and NS_INCLUDE_MAC.
New ioctl commands are now supported: DL_ROUTE, DL_TUNE_LLC, DL_ZERO_STATS, and DL_SET_REMADDR. Refer to "ioctl Specifics.
The following primitives are supported by DLPI:
The following connection-oriented service primitives are supported:
The following primitives are not supported:
The following acknowledged connectionless-mode primitives are not supported:
Note: If any unsupported primitive is issued to the provider, the provider will return the DL_ERROR_ACK primitive with the DL_NOTSUPPORTED error code.
You can obtain copies of the Data Link Provider Interface (DLPI) specifications electronically using File Transfer Protocol (FTP) commands. A postscript version of the DLPI specifications may be retrieved electronically by anonymous ftp from any of the following list of Internet hosts.
To retrieve the postscript DLPI specifications through anonymous ftp, use the following example:
ftp ftp.eu.net Connected to eunet.EU.net. 220- 220-Welcome to the central EUnet Archive, 220- 220 eunet.EU.net FTP server (Version wu-2.4(2) Jul 09 1993) ready. Name (ftp.eu.net:jhaug):anonymous ftp> user anonymous 331 Guest login ok, send your complete e-mail address as password. Password: ftp> cd /network/netman/dlpi 250 CWD command successful. ftp> bin 200 Type set to I. ftp> get dlpi.ps.Z 200 PORT command successful. 150 Opening BINARY mode data connection for dlpi.ps.Z (479345 bytes). 226 Transfer complete. 1476915 bytes received in 39.12 seconds (11.97 Kbyte/s) ftp> quit 221 Goodbye.
There is no guarantee that a public Internet server will always be available. If the above public Internet server host is not available, you might try using one of the Internet archive server listing services, such as Archie, to search for a public server that has the DLPI specifications.