Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QWHITE13.ZIP
Filename : ODI.TEC

Output of file : ODI.TEC contained in archive : QWHITE13.ZIP

ID:OD An Overview of ODI
Quarterdeck Technical Note #167 Filename: ODI.TEC
by Novell Labs Marketing CompuServe:
Last revised: 2/03/92 Category: NW

Subject: A comparison of Novell's Dedicated IPX and ODI, an ODI architectural
overview, and a comparison between ODI and Microsoft's NDIS. Supplied
by Novell Labs Marketing.

Revision 1.4

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

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

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

Ethernet Frame types Supported:
Ethernet II
Token Ring

Ethernet Frame types Supported:
Ethernet II
Token Ring:
802.2 Snap


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


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


Supports multiple protocol stacks simultaneously:


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


Supports up to 4 physical boards in server


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


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

Throughput capacity


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


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


Substantially increases total network throughput.

Ease of maintenance


Drivers may not be unloaded


Drivers can be loaded on the fly.


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

Additional Features


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


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?


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.


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.


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.


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.

This document (C) Copyright 1993 Novell