NATM(4) BSD Kernel Interfaces Manual NATM(4)NAMEnatm — Native Mode ATM protocol layer
SYNOPSIS
options NATM
DESCRIPTION
The BSD ATM software comes with a native mode ATM protocol layer which
provides socket level access to AAL0 and AAL5 virtual circuits.
NATM API
The NATM layer uses a struct sockaddr_natm to specify a virtual circuit:
struct sockaddr_natm {
u_int8_t snatm_len; /* length */
u_int8_t snatm_family; /* AF_NATM */
char snatm_if[IFNAMSIZ]; /* interface name */
u_int16_t snatm_vci; /* vci */
u_int8_t snatm_vpi; /* vpi */
};
To create an AAL5 connection to a virtual circuit with VPI 0, VCI 201 one
would use the following:
struct sockaddr_natm snatm;
int s, r;
s = socket(AF_NATM, SOCK_STREAM, PROTO_NATMAAL5);
/* note: PROTO_NATMAAL0 is AAL0 */
if (s < 0) { perror("socket"); exit(1); }
bzero(&snatm, sizeof(snatm));
snatm.snatm_len = sizeof(snatm);
snatm.snatm_family = AF_NATM;
sprintf(snatm.snatm_if, "en0");
snatm.snatm_vci = 201;
snatm.snatm_vpi = 0;
r = connect(s, (struct sockaddr *)&snatm, sizeof(snatm));
if (r < 0) { perror("connect"); exit(1); }
/* s now connected to ATM! */
The socket() call simply creates an unconnected NATM socket. The
connect() call associates an unconnected NATM socket with a virtual cir‐
cuit and tells the driver to enable that virtual circuit for receiving
data. After the connect() call one can read() or write() to the socket
to perform ATM I/O.
Internal NATM operation
Internally, the NATM protocol layer keeps a list of all active virtual
circuits on the system in natm_pcbs. This includes circuits currently
being used for IP to prevent NATM and IP from clashing over virtual cir‐
cuit usage.
When a virtual circuit is enabled for receiving data, the NATM protocol
layer passes the address of the protocol control block down to the driver
as a receive “handle”. When inbound data arrives, the driver passes the
data back with the appropriate receive handle. The NATM layer uses this
to avoid the overhead of a protocol control block lookup. This allows
us to take advantage of the fact that ATM has already demultiplexed the
data for us.
Other NATM issues
We are currently involved with a video server project and are using this
driver as part of it. We have a device we build called an MMX. You can
connect a video camera to an MMX and have it send you a stream of AAL0
cells with the video output in it. Of course this stream is pretty rapid
(in fact, it is massive!), and the normal AAL0 handling of the driver is
unable to handle it (you end up with a cell per small mbuf trying to make
it to the application ... it turns out the socket layer can't keep up
with that sort of data stream). To solve this problem we have imple‐
mented a “raw” mode which batches unprocessed AAL0 info from the card
into larger data chunks blocks. We can save this data to disk in real-
time without the socket layer freaking out. Unfortunately, the data
has RBD (receive buffer descriptors) and cells headers in it, and this
has to be filtered out after capture. To enable “raw” mode one does the
following ioctl:
int size = 4000; /* bytes */
ret = ioctl(s, SIOCRAWATM, (caddr_t)&size);
This tells the driver to batch AAL0 data into 4000 bytes chunks, rather
than the usual 48 bytes chunks. Admittedly this is somewhat gross,
but our current application requires it. In the future we hope that
video sources send data in nice large AAL5 frames.
CAVEAT
The NATM protocol support is subject to change as the ATM protocols
develop. Users should not depend on details of the current implementa‐
tion, but rather the services exported.
SEE ALSOen(4)AUTHORS
Chuck Cranor of Washington University implemented the NATM protocol layer
along with the EN ATM driver in 1996 for NetBSD.
BSD December 29, 1997 BSD
