Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!asylum!romkey
From: romkey@asylum.SF.CA.US (John Romkey)
Newsgroups: comp.dcom.lans
Subject: Re: Packet Drivers or NDIS Drivers for Netware
Keywords: NDIS,Netware,Drivers
Message-ID: <13782@asylum.SF.CA.US>
Date: 6 Mar 91 16:35:51 GMT
References: <1991Feb22.221957.18674@novell.com>
Organization: The Asylum, Belmont, CA
Lines: 23

keith@ca.excelan.com (Keith Brown) writes:

>Our architecture for running multiple protocols at both the client and
>server side is the Open Datalink Interface (ODI). Many people are under the
>impression that we are in some way "competing" with both NDIS and the
>packet driver spec. We're not! The ODI and it's associated API really
>sits above the simple "send a packet, receive a packet" APIs of both NDIS
>and the packet drivers. The ODI understands medias and encapsulation
>methodologies and shields overlying protocols from having to worry about
>what type of network they are running on. It actually makes perfect sense
>to build ODI drivers for the NDIS "board" and the packet driver "board".
>The ODI adds value atop them!

From what I understand, ODI doesn't provide any logical (IP, for instance) to
physical (MAC) address translation. If it doesn't, then any protocol stacks
running above it still have to do this and know about the physical media they
reside on. In that case, ODI's only real difference is that it builds media
headers. Without the address translation, I don't think you can really claim
that it's media-independent, as some protocols like IP will still have to
provide media dependent code in them.
-- 
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141