Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
NATM(4)			 BSD Kernel Interfaces Manual		       NATM(4)

     natm -- Native Mode ATM protocol layer

     The BSD ATM software comes	with a native mode ATM protocol	layer which
     provides socket level access to AAL0 and AAL5 virtual circuits.  To en-
     able this protocol	layer, add
	   options NATM
     to	your kernel configuration file and re-make the kernel (don't forget to
     do	"make clean").

     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;
				  /* 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.

     The NATM protocol support is subject to change as the ATM protocols de-
     velop.  Users should not depend on	details	of the current implementation,
     but rather	the services exported.


     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

NAME | DESCRIPTION | NATM API | Internal NATM operation | Other NATM issues | CAVEAT | SEE ALSO | AUTHORS

Want to link to this manual page? Use this URL:

home | help