Category : Network Files
Archive   : DOSUP9.ZIP
Filename : ODIINFO.DOC

The Open Data-Link Interface (ODI) Overview

A discussion on why Novell is promoting the transition to the
ODI specification:

A comparision between Novell's Dedicated IPX and ODI,
an ODI architectural overview, and
a comparison between ODI and Microsoft's NDIS.

Prepared By Novell Labs Marketing
Revision 1.4


Introduction
This paper provides an overview of ODI from several vantage points. The
first section will compare ODI with Dedicated IPX. The second section
contains an architectural overview of ODI and explains the different
components and how they interact. The third section is a comparison of ODI
with Microsoft's NDIS. The focus of this paper will be in helping to
understand the advantages of ODI and explain why ODI is Novell's
recommended specification.

Dedicated IPX drivers have been used for most NetWare installations since
NetWare version 2.0A, and still has the largest installed base of any type
of LAN driver. As with any technology, it was created to serve a distinct
purpose -- act as a bridge between adapter boards and the network
communication protocol, connecting hardware with the network operating
system. However, many companies have now moved to larger and more complex
systems where dedicated IPX drivers have limitations. This growing need
for added flexibility in network communication spawned the development of
Open Data-Link Interface (ODI).

ODI is a data-link specification jointly developed by Apple Computer and
Novell and published to the networking industry in 1989. The strategic
goal of ODI is to provide seamless network integration at the transport,
network, and data-link levels. ODI simplifies the development of network
drivers for a wide variety of network adapters and network transport
protocol stacks. The result is easier access to a wide variety of
networked resources without requiring multiple network connections or
additional investments in hardware and software.

Section I: Comparing Dedicated IPX and ODI

IPX: The way things were

To fully understand the improved functionality offered by ODI drivers, you
must first understand how dedicated IPX works and what it's limitations
are.

Dedicated IPX on a DOS workstation allows network clients to communicate with
NetWare servers via a single protocol.

In a typical DOS IPX installation, a client uses a LAN adapter and a
dedicated IPX driver to connect to the network, employing the IPX protocol
to communicate with the NetWare server. On the server side, another LAN
adapter receives the data, configured for the IPX protocol, and processes
the incoming information. Communication goes back and forth between these
two entities along this single channel using only the IPX protocol.

This works well if all the server has to handle are DOS and OS/2 clients
using only the IPX protocol. But networks are getting more and more
complex, network managers now need to tie in more and more disparate client
types and protocol stacks on one server. What if you need to network DOS,
AppleTalk and UNIX? This could not be done under the old Dedicated IPX
architecture.

ODI: How it addresses the need for flexible protocol support

ODI's architecture is designed to radically simplify support for multiple
protocols on a single network. Rather than installing a separate driver and
adapter for each client type that needs to be supported on the network, ODI
consolidates the support for multiple protocols under one driver. This
means that one adapter in the server can support various clients on the
network.

ODI provides transport support so a Apple Macintosh (using the AFP
protocol) can use a NetWare server to queue and print documents and save
data files that are shareable with other types of workstations. UNIX,
OS/2, TCP/IP and other clients can be supported in a similar manner.

ODI allows a network to support many different protocols (such as IPX/SPX,
TCP/IP and AppleTalk) with ease. ODI also allows network managers to
integrate new protocols (or enhancements to existing protocols) into
existing networks as they become available.

ODI consolidates services on the client side as well. Using the right
ODI adapter/driver combination, a workstation can access services from a
NetWare server and a UNIX host without rebooting the client. And only one
client card is needed to support both IPX and TCP/IP.

Thus, ODI allows for multiple types of workstations to communicate
transparently with network services through a single server. Furthermore,
ODI lets a single protocol stack communicate with multiple LAN cards, (for
example, an IPX router) which was not previously possible with Dedicated
IPX.

ODI drivers are also much easier to install and upgrade than Dedicated IPX
drivers: under Dedicated IPX the driver had to be bound to the operating
system through NETGEN or SHGEN. If a customer wanted to upgrade the driver,
he or she had to re-install (re-gen) the operating system. This can be a
time consuming process, especially when considering that the operating
system must be re-installed exactly as it was set up before -- whoever does
the installation has to know all of the defaults and settings that were set
on the original file system, otherwise the system won't be completly
functional when it is re-intalled.

ODI alleviates this problem entirely by allowing new and updated drivers to
be loaded on the fly. Simply unload the existing driver and load the new
one, and the underlying file system remains uneffected.

ODI has many advantages over Dedicated IPX. Because of these advantages,
OS/2 has always been ODI and DOS ODI was shipped with v3.10 and v2.2
Netware and later. A comparison of some of the features and capabilities
between the two are listed below.

A Comparison of Dedicated IPX and ODI

Frame type support

DEDICATED IPX:
Ethernet Frame types Supported:
802.3
Ethernet II
Token Ring

ODI:
Ethernet Frame types Supported:
802.2
802.3
Ethernet II
Snap
Token Ring:
802.5
802.2 Snap

BENEFITS OF ODI:

One driver allows the customer to easily support multiple
frame types on the same network. This opens the network up
to more products and platforms.


Protocol support

DEDICATED IPX:

Supports a single protocol stack:
IPX
Appletalk (on the server)

ODI:

Supports multiple protocol stacks simultaneously:
IPX
TCP/IP
AppleTalk
OSI
...etc...

BENEFITS OF ODI:

Allows for multiple protocol support under a single card
and driver. This provides easier maintenance for hooking
up multiple clients to a single server and accessing
resources from host servers.


Physical board support

DEDICATED IPX:

Supports up to 4 physical boards in server

ODI:

Supports up to 255 logical boards in server or as many
physical boards as will fit in the machine

BENEFITS OF ODI:

Provides support for a larger number of LAN boards. Allows
for balancing of network load over multiple cards.


Throughput capacity

DEDICATED IPX:

Max packet size = Up to 4k
only in powers of 2 (512, 1k, 2k, 4k)

ODI:

Max packet size = Up to 24k depending on media and board
limitations

BENEFITS OF ODI:

Substantially increases total network throughput.


Ease of maintenance

DEDICATED IPX:

Drivers may not be unloaded

ODI:

Drivers can be loaded on the fly.


BENEFITS OF ODI:

Allows you to upgrade LAN drivers with minimal interruption
to network services. No need to re-install operating system.


Additional Features

ODI:

Also supports:
Lanalyzer for NetWare
Packet Burst
Locally administered node addresses


BENEFITS OF ODI:

ODI supports network services that Dedicated IPX currently
does not support. Additional network services will be
compatible with ODI as they are provided.



Section II: Architectural Overview

With ODI, any LAN driver can communicate with any ODI protocol stack. The
diagram below shows the modular structure of ODI. The three components of
ODI technology are:
Multi-Link Interface Driver (MLID)
Link Support Layer (LSL)
Protocol Stacks

Multi-Link Interface Driver (MLID)
The Multi-Link Interface Driver (MLID) is a network interface card driver
developed to the ODI MLI specifications. The MLID controls communication
between the LAN board and the Link Support Layer. There are two parts to
the MLID: the Media Support Module (MSM) and the Hardware-Specific Module
(HSM). The MSM is source code provided by Novell that implements the
standard functions of LAN drivers into ODI for each of the standard media
types. The HSM is the code written by the developer to handle the LAN
board details.

When the MLID receives a packet of data, it removes the media access
information (MAC header) and passes the packet to the Link Support Layer.
Since the media details are invisible to the LSL, this modular design
provides true media independence.

Link Support Layer (LSL)
The Link Support Layer (LSL) is the technological factor that allows a
single driver to support multiple protocols and for a protocol to use
multiple drivers. When the LSL receives a packet of data from the MLID, the
LSL acts as a switchboard by determining which protocol stack should
receive the packet. This "traffic cop" functionality eliminates the need
to write separate drivers for each frame/protocol combination, thereby
dramatically reducing the number of drivers a developer has to write and a
customer has to install.

Protocol stacks
The protocol stack receives packets of information from the LSL and is
unaware of the media or LAN board type through which it passed. It then
removes the protocol specific header information and passes the packets on
to other higher-layer protocols or applications. The most popular types of
protocol stacks are IPX/SPX, TCP/IP, AppleTalk, and OSI.

The modular design of ODI is the key to its flexibility. This modularity
is created by making sure that the protocol stacks are unaware of media
knowledge and that the MLIDs are unaware of protocol knowledge. The drivers
and the protocol stacks operate independent of each other making it
possible to add new media or new protocols to the file system easily.


Section III: Comparing NDIS and ODI

NDIS was co-developed by 3COM and Microsoft. A drawing is included below
to compare the conceptual architectural models of NDIS and ODI. This will
provide a basis for understanding the differences between the two
specifications. (Note: this discussion is not meant to be an engineering-
level comparison of the two specifications, but rather provide a basic
working knowledge of the important differences between NDIS and ODI.)

There are several distinct differences between ODI and NDIS that end up
affecting the value of products written to the different specifications.
While both specifications promote schemes to support multiple protocols on
an internetwork, their different approaches to enabling this functionality
result in dramatically different customer implementations.

Novell's orientation on driver support is that it should be as invisible as
possible to the customer. There are many issues to consider when trying to
make driver support invisible to customers:

* Technical competence: Does the driver actually do what it is
supposed to do: support multiple protocols? Does it do so
efficiently and gracefully?

* Flexibility: Can additional protocols be supported as they are
developed? What about additional media, such as FDDI or ATM? How
difficult is it to integrate support for these new products as they
emerge? Will products based on new media or protocols work with
products developed to the existing architectural specs?

* Backward compatibility: If you are a customer and have invested in
products that support ODI, will future versions of ODI continue to
support these products or will you have to replace drivers? What
about NDIS?

* Reliability: How can a customer determine if a third party product
really conforms to a spec, whether it be ODI or NDIS? What
difference does this make to a customer? How well will different
products from different vendors, written to the same spec,
interoperate?

* Development issues: How long does it take to develop ODI drivers?
What is being done to reduce development time even further? How
does this affect driver availability to the customer? What
advantages does a "modular" approach offer over a "media-dependent"
approach? How does the ODINSUP shim (available through ODI) make
NDIS driver development practically unnecessary?

Flexibility

NDIS protocol stacks are media aware --they contain media knowledge in the
protocol stack. Almost all NDIS stacks will recognize and support Ethernet
802.3 or TokenRing 802.5 or both. This means that drivers for other media
such as Arcnet or ATM must shim this media to make it look like 802.3 or
802.5. As a result NDIS drivers have been much more difficult to write to
any media other than Ethernet and TokenRing.

This is not so with ODI. ODI was designed to transparently support any
network transport regardless of the underlying media. For instance, ODI
will integrate FDDI, wireless technology or other media types into your
present network without the need to rewrite or change the protocol stacks.

The method NDIS employs to support multiple protocol stacks can also be an
issue, especially in cases where true multiprotocol support is needed. When
a system uses multiple protocol stacks, NDIS is set up to daisy chain the
packets from stack to stack (through the Protocol Manager) until the packet
is recognized and received. This works well as long as the data packet
always needs to go to the first protocol stack in the chain, but if the
traffic is evenly spread across several stacks, or a new stack is added in
later, then the Protocol Manager will spend a lot of time toggling between
stacks looking for the right route for data transmission and the protocol
stacks at the front of the chain will get higher performance than those at
the back.

Microsoft suggests that the protocols should be loaded in order of network
traffic use so as to speed up the throughput. But when a new protocol is
added to the network, it is the last protocol to get passed the packet of
information. If this new protocol is going to be used for most of the
network transportation, then to get optimal speed under NDIS, you would be
required to reload all of the protocol stacks, making sure that the new
stack was loaded first. In any case, the customer must have knowledge of
NDIS and tweak the NDIS system to get good performance from the system.

Again, the philosophy behind ODI is to minimize customer involvement with
the system -- set the system up so that the system takes care of all of the
transport details. Under ODI, the LSL determines which protocol stack
should receive each packet of information and the loading order is
irrelevant. A stack can be added into the system and ODI automatically
supports it. And loading and unloading drivers with ODI is much easier
than with NDIS: NDIS driver loading is done in the config.sys file, while
ODI is a TSR and, under DOS, provides more flexibility for loading and
unloading drivers.


Reliability

Another important comparison to make between ODI and NDIS is how to gauge
the reliability of drivers written to each specification. Currently
Microsoft provides test tools to developers so that they can test their own
drivers after they write them. No outside testing or verification is
required for the drivers, so a customer really has no way of knowing how
well tested or reliable an NDIS driver is.

This is more risky when compared to the standards Novell has set for ODI.
Novell has established a department specifically designed to test and
certify drivers written by developers. This is done to assure that the
drivers meet specifications and run in various configurations. In a sense,
Novell Labs has established a watermark that developers must meet in order
to call a product an ODI driver.

Furthermore, once an ODI driver is certified, Novell Services treats it as
if it were one of Novell's drivers. If a customer running NetWare
encounters a driver-related problem, Novell assumes a role in getting the
problem solved. If, however, the driver is NDIS, then Services has no
documentation to refer to solve the problem and cannot do much to help the
customer.

Considered from a customer's standpoint, this is an important distinction.
If customers base their systems on ODI drivers, they know that the
products they are using have already demonstrated a significant level of
compatibility with NetWare and can be supported if something should go
wrong. If they go with NDIS, they are taking their own chances. In large
part because of these reliability issues, we have heard of many large
accounts that have standardized on ODI drivers.

ODI drivers are certified by Novell Labs; other drivers do not have to meet
this requirement.

Backward compatibility

Another important distinction between the two specifications has to do with
backward compatibility. For example, consider a customer running with NDIS
v2.0 drivers that wants to upgrade to Windows NT. NT requires v3.0
drivers. This presents a problem if the board vendor hasn't released a
v3.0 driver for the customer's board when he/she wants to install NT.

Ironically, because ODI supports any protocol stack, an ODI driver for the
same board can be used to connect into NT through a shim called ODINSUP.
This module allows the customer to talk to the NDIS protocol stacks
unmodified over the ODI driver. ODINSUP is discussed in more detail in the
following section.

Because of Novell's customer focus ODI provides complete backwards
compatibility, making upgrading much simpler. Again, once an ODI driver is
installed, changes to the system, whether they be new protocol stacks, new
media, or products that support a new ODI spec have no impact on the
driver's compatibility. This dramatically reduces the customer' s support
and maintenance burden.

Development Issues

Time to market

LAN drivers used to take six to eight to develop before ODI was introduced.
Because of ODI's modular architecture, development time to market has been
significantly reduced.

As we have previously outlined, ODI drivers are comprised of two parts: the
Media Support Module (MSM) and the Hardware-Specific Module (HSM). In the
past when developers wrote drivers they had to create code to access the
protocol, service the board, and access the media. In order to simplify
driver development, Novell now provides source code to interface with
various media (the MSM) as part of the Novell LAN Driver Development Kit.
This reduces the developer's coding burden: now they can focus on creating
the hardware-specific portions of the driver and adding any optional
functions. ODI's MSM/HSM drivers can be developed in 2-3 weeks.

Chipset developers have also helped to make driver development much simpler
than it was in the past. Major silicon developers (including National,
Intel Texas Instruments and AMD) have sample designs, software source code,
bills of materials and other materials needed to build products that
support ODI. These materials are available to developers that use their
chipsets.

This simplification of the development process benefits customers in two
ways:

* Drivers become more standardized, easier to create, and easier to
test. Ultimately, this means that they will become less expensive
to produce, resulting in lower-priced products that are available
sooner to customers.

* As more of the coding related to the network interfaces becomes
standardized, developers can focus their attention on building
greater functionality and performance into their products. Greater
speed to market means that bug fixes and patches that increase
performance (such as the packet burst NLM) will be integrated more
quickly and with less downtime than was previously possible.


ODINSUP

As part of Novell's commitment to be interoperable, ODI supports NDIS.
ODI's modular architecture allows users to support NDIS protocol stacks. A
module called ODINSUP allows NDIS protocol stacks to run unmodified over
the ODI LSL and talk to an ODI LAN driver (please refer to the figure on
the following page). Now, multi-vendor network transports like IBM's
NetBEUI, DEC's LAT or 3COM's XNS can be run over a common Data-Link
(driver) specification. This feature provides two significant benefits:

* It allows customers to integrate, and preserve investments in,
multi-vendor networking services. Because ODI supports NDIS
stacks, customers can standardize on ODI drivers, knowing that
these drivers will support all of their networking needs, whether
they depend on NDIS or another network transport protocol.

* The ability to access NDIS through ODINSUP also means that
developers can develop products to the ODI specification knowing
that these drivers will be able to support NDIS protocol stacks.
This feature significantly reduces a LAN driver developer's coding
burden.

Modular architecture of ODI allows integration of new technologies without
disrupting current services, including support for NDIS stacks and FDDI.

Summary

ODI was developed with a modular architecture that makes it truly media and
protocol independent. ODI provides greater flexibility in configuring the
network interface, uses resources more effectively and preserves
investments in hardware and other network resources. With ODI, integration
of new technologies can be done easily and without interrupting current
services. ODI drivers are certified by Novell Labs and are therefore very
reliable, and are compatible with previous versions of the ODI spec.
Driver development time has been reduced due to the source code provided by
Novell; this means better products get to customers more quickly. ODI
drivers can talk to NDIS stacks through ODINSUP, allowing customers to
standardize on one type of drivers. Because of these advantages, Novell
recommends products written to ODI.

How to Switch to ODI

Because of these advantages, Novell is including only ODI drivers with the
NetWare v4.0 operating system. Older dedicated IPX drivers are being
phased out -- Novell Labs discontinued the certification of dedicated DOS
IPX drivers June 1992. There are now ODI drivers available for all popular
LAN adapters. See the attached appendix for a listing of tested drivers.

In order to assist in upgrading DOS workstations from dedicated IPX drivers
to ODI, Novell is supplying a utility, (available in upcoming client
workstation kits) called WSUPGRD, which is intended to be used by a system
administrator to upgrade many workstations which are all similarly
configured. This utility is intended to be executed from the system login
script. It will scan the dedicated IPX.COM file on the workstation,
determine which driver was linked in with the SHGEN utility and what
hardware options were selected. It will then reference an installation
file created by the system administrator to select the appropriate ODI
driver, and will install it along with the ODI Link Support Layer (LSL)
module and an appropriate NET.CFG file (all of which may be configured or
defined by the system administrator). This utility is intended for use in
upgrading large sites where workstations with similar brands of LAN
adapters are also similar in configuration (usually under the control of a
system administrator). For example, when the command lines in the
autoexec.bat files are similar, this utility will easily upgrade all the
similar adapters.