Platform Notes: The SunATM Driver Software

Connecting, Sending, and Receiving Data with the ATM Device Driver

Connecting to the ATM device driver involves several steps, some of which include several ioctl calls. To create a more standardized interface for user space applications, a set of atm_util functions is available to application writers. An overview of those functions is provided in Table A-4. For more detailed information, refer to the atm_util(3) man page. The ba(7) man page contains a more detailed discussion of the driver-supported ioctls.

Table A-4 atm_util Function Overview


Name	Functionality	Kernel Equivalent
`atm_open`	Opens a stream to the ATM device driver	Must be done by a user space setup program
`atm_close`	Closes a stream to the ATM device driver	Must be done by a user space setup program
`atm_attach`	Attaches to a physical interface	Must be done by a user space setup program
`atm_detach`	Detaches from a physical interface	Must be done by a user space setup program
`atm_bind`	Binds to a Service Access Point	send `DL_BIND_REQ`
`atm_unbind`	Unbinds from a Service Access Point	send `DL_UNBIND_REQ`
`atm_setraw`	Sets the encapsulation mode to raw	Send `DLIOCRAW`
`atm_add_vpci`	Associates a vpci with this connection	`A_ADDVC ioctl`
`atm_delete_vpci`	Dissociates a vpci from this connection	`A_DELVC ioctl`
`atm_allocate_bw`	Allocates constant bit rate bandwidth for this connection	`A_ALLOCBW ioctl`
`atm_allocate_cbr_bw`	Allocates constant bit rate bandwidth with more granularity than `atm_allocate_bw`	`A_ALLOCBW_CBR ioctl`
`atm_allocate_vbr_bw`	Allocates variable bit rate bandwidth	`A_ALLOCBW_VBR ioctl`
`atm_release_bw`	Releases previously allocated bandwidth	`A_RELSE_BW ioctl`

Note -

The following discussion uses user space function names. Refer to Table A-4 for the corresponding kernel space function or ioctl.

To establish a data path, the application must first open the ATM driver and attach to a specific physical interface using atm_open() and atm_attach(). Next, the connection is associated with one or more VC(s), using atm_add_vpci(). If a call has been established using Q.2931 signalling, the vpci provided to atm_add_vpci() is the vpci that was included in the Q.2931 signalling messages received while establishing the call.

An encapsulation method must also be selected. The method of encapsulation is selected when the VC is associated with a stream (the atm_add_vpci() call). Currently, null and LLC encapsulation are supported. Null encapsulation implies that a message consists only of data preceded by a four-byte vpci. This type of encapsulation is most commonly used with raw mode. LLC encapsulation implies that an LLC header precedes the data. This header includes the SAP associated with the application's stream (using atm_bind()).

You can also select a mode of operation to determine the format of the message blocks passed to the ATM device driver. DLPI mode is set by default; however, the user can select raw mode with a call to atm_setraw(). DLPI mode implies that two or more mblocks will be sent to the driver. The first, which corresponds to the ctl buffer sent in the putmsg() system call, contains the dlpi message type, which is dl_unitdata_req for transmit and dl_unitdata_ind for receive. The vpci is included in this mblock as well. The dl_unitdata_req and dl_unitdata_ind header formats are defined in the header file <sys/dlpi.h>. The second and subsequent mblocks (corresponding to the data buffer in the putmsg() system call) contain the message.

Raw Mode Connections

Raw mode implies that the four-byte vpci is sent in the first mblock (corresponding to the ctl buffer in the putmsg() system call) followed by data. Any subsequent mblocks (the data buffer in the putmsg() system call) contain only data.

DLPI Mode Connections

Although the encapsulation and operational mode can be chosen independently, typically, DLPI mode is used for LLC-encapsulated traffic and raw mode is used for null encapsulation.

The driver's handling of packets depends on both the encapsulation method and the operational mode. For LLC-encapsulated traffic running in dlpi mode, the driver automatically adds the LLC header on transmit and strips the LLC header on receive before sending the message up the dlpi mode stream. In raw mode, however, the driver does not modify the packets at all. This includes any header included with the packet. Thus, an application using raw mode and LLC encapsulation must include its own headers on transmit and receives data with the LLC header intact.

Received packets are directed to application streams based on the type of encapsulation in use. If a packet is null-encapsulated, it is sent up the stream associated with the vpci on which the packet was received. If a packet is LLC-encapsulated, it is sent to the stream that has bound (using atm_bind()) the SAP found in the LLC header.