Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!decwrl!ucbvax!ICO.ISC.COM!dougm
From: dougm@ICO.ISC.COM ("Doug McCallum")
Newsgroups: comp.protocols.tcp-ip
Subject: Re(2): TLI, NLI, DLI - Request for information
Message-ID: <9009030307.AA02947@violet.ICO.ISC.COM>
Date: 3 Sep 90 03:07:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 67

In reply to your message of Fri, 31 Aug 90 09:34:13 +0100
-------

> do any of TLI, NLI or DLI contain something with more functionality
> than sockets - like a standard management interface, or a standard
> packet filter or traceer interface - and i dont mean ioctl and nit
> like vaguaries

TLI has been discussed to death.  It is similar to sockets and has adherents
and detractors like sockets do.  4.4BSD sockets pretty much fix the
deficiencies that TLI tried to address.

NLI and DLI don't exist with those names.  There is NPI and DLPI.  They are
interfaces between STREAMS modules and don't really have any relationship to
sockets or anything like that.  They could have programming interfaces
defined for them but there currently aren't any.  Of course, since they are
just STREAMS messages, a user level program can access the interfaces.

To summarize what NPI (Network Provider Interface) and DLPI (Data Link
Provider Interface) are:

NPI:    Provides a common set of primitives that are based on the OSI
	service primitives for network services.  The intent is to have a
	common set of primitives to allow a transport provider to be able to
	communicate with a network service provider.

	While not really necessary, it does provide a way to cleanly
	separate the network provider from the other parts of the stack and
	to allow multiple providers.  One possibility is to have CONS and
	CLNS network providers for OSI under a single stack.

	In reality, it is just a nice way to do something similar to RAW
	sockets but then be able to link the network STREAM under a provider
	module and construct a new stack without having to modify any part
	of the network provider driver.

	NPI provides for connection primitives as well as connectionless.

DLPI:
	This is the STREAMS interface to data link device drivers.  While
	similar to NIT and other mechanisms for gaining access to the device
	driver level, it really is just the mechanism for a network service
	provider to communicate with the device driver.  A STREAM can be
	opened and bound to some service access point (Ethertype, 802.2
	LSAP, whatever) and then be linked under a network provider module.
	It is possible to use it a user level to implement things like RARP
	or other application that uses the data link level directly.
	The V.4 DLPI also includes primitives for connection oriented
	protocols such as 802.2 Class 2 Type 2 LLC.

> if not, i suggest its just more noiseware to make unix less useful,
> designed by manufacturers running scared from real open systems and
> shareware...

TLI may have been that.  It does seem to smack of NIH.  NPI and DLPI
developed to meet a different need - that of getting vendors to write
drivers that would work with other vendors protocol stacks.  Since STREAMS
isn't a protocol or driver implementation itself and is only the framework
to develop protocols and drivers, there needed to be a consistant interface
between the various types of modules.  NPI and DLPI are intended to do that.
The BSD way doesn't fit the STREAMS model very well.  Besides, DLPI at
least, is far more flexible.  The drivers don't have to be modified to allow
a third party vendor's protocol stack take advantage of them.

Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.com