home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / o / odi.tec < prev    next >
Text File  |  1993-03-21  |  24KB  |  522 lines
  1. ID: OD An Overview of ODI
  2. Quarterdeck Technical Bulletin #167
  3. By Novell Labs Marketing
  4. Revision 1.4
  5.  
  6.  
  7. A discussion on why Novell is promoting the transition to the ODI
  8. specification:
  9.  
  10. A comparision between Novell's Dedicated IPX and ODI, an ODI architectural
  11. overview, and a comparison between ODI and Microsoft's NDIS.
  12.  
  13. Introduction
  14. This paper provides an overview of ODI from several vantage points.  The first
  15. section will compare ODI with Dedicated IPX.  The second section contains an
  16. architectural overview of ODI and explains the different components and how
  17. they interact.  The third section is a comparison of ODI with Microsoft's
  18. NDIS.  The focus of this paper will be in helping to understand the advantages
  19. of ODI and explain why ODI is Novell's recommended specification.
  20.  
  21. Dedicated IPX drivers have been used for most NetWare installations since
  22. NetWare version 2.0A, and still has the largest installed base of any type of
  23. LAN driver. As with any technology, it was created to serve a distinct purpose
  24. -- act as a bridge between adapter boards and the network communication
  25. protocol, connecting hardware with the network operating system.  However,
  26. many companies have now moved to larger and more complex systems where
  27. dedicated IPX drivers have limitations.  This growing need for added
  28. flexibility in network communication spawned the development of Open Data-Link
  29. Interface (ODI).
  30.  
  31. ODI is a data-link specification jointly developed by Apple Computer and
  32. Novell and published to the networking industry in 1989.  The strategic goal
  33. of ODI is to provide seamless network integration at the transport, network,
  34. and data-link levels.  ODI simplifies the development of network drivers for a
  35. wide variety of network adapters and network transport protocol stacks.  The
  36. result is easier access to a wide variety of networked resources without
  37. requiring multiple network connections or additional investments in hardware
  38. and software.
  39.  
  40.  
  41. Section I: Comparing Dedicated IPX and ODI
  42.  
  43. IPX: The way things were
  44.  
  45. To fully understand the improved functionality offered by ODI drivers, you
  46. must first understand how dedicated IPX works and what it's limitations are.
  47.  
  48. Dedicated IPX on a DOS workstation allows network clients to communicate with
  49. NetWare servers via a single protocol.
  50.  
  51. In a typical DOS IPX installation, a client uses a LAN adapter and a dedicated
  52. IPX driver to connect to the network, employing the IPX protocol to
  53. communicate with the NetWare server. On the server side, another LAN adapter
  54. receives the data, configured for the IPX protocol, and processes the incoming
  55. information.  Communication goes back and forth between these two entities
  56. along this single channel using only the IPX protocol.
  57.  
  58. This works well if all the server has to handle are DOS and OS/2 clients using
  59. only the IPX protocol. But networks are getting more and more complex, network
  60. managers now need to tie in more and more disparate client types and protocol
  61. stacks on one server. What if you need to network DOS, AppleTalk and UNIX?
  62. This could not be done under the old Dedicated IPX architecture.
  63.  
  64.  
  65. ODI: How it addresses the need for flexible protocol support
  66.  
  67. ODI's architecture is designed to radically simplify support for multiple
  68. protocols on a single network. Rather than installing a separate driver and
  69. adapter for each client type that needs to be supported on the network, ODI
  70. consolidates the support for multiple protocols under one driver. This means
  71. that one adapter in the server can support various clients on the network.
  72.  
  73. ODI provides transport support so a Apple Macintosh (using the AFP protocol)
  74. can use a NetWare server to queue and print documents and save data files that
  75. are shareable with other types of workstations. UNIX, OS/2, TCP/IP and other
  76. clients can be supported in a similar manner.
  77.  
  78. ODI allows a network to support many different protocols (such as IPX/SPX,
  79. TCP/IP and AppleTalk) with ease.  ODI also allows network managers to
  80. integrate new protocols (or enhancements to existing protocols) into existing
  81. networks as they become available.
  82.  
  83. ODI consolidates services on the client side as well. Using the right ODI
  84. adapter/driver combination, a  workstation can access services from a NetWare
  85. server and a UNIX host without rebooting the client. And only one client card
  86. is needed to support both IPX and TCP/IP.
  87.  
  88. Thus, ODI allows for multiple types of workstations to communicate
  89. transparently with network services through a single server.  Furthermore, ODI
  90. lets a single protocol stack communicate with multiple LAN cards, (for
  91. example, an IPX router) which was not previously possible with Dedicated IPX.
  92.  
  93. ODI drivers are also much easier to install and upgrade than Dedicated IPX
  94. drivers: under Dedicated IPX the driver had to be bound to the operating
  95. system through NETGEN or SHGEN. If a customer wanted to upgrade the driver, he
  96. or she had to re-install (re-gen) the operating system. This can be a time
  97. consuming process, especially when considering that the operating system must
  98. be re-installed exactly as it was set up before -- whoever does the
  99. installation has to know all of the defaults and settings that were set on the
  100. original file system, otherwise the system won't be completly functional when
  101. it is re-intalled.
  102.  
  103. ODI alleviates this problem entirely by allowing new and updated drivers to be
  104. loaded on the fly. Simply unload the existing driver and load the new one, and
  105. the underlying file system remains uneffected.
  106.  
  107. ODI has many advantages over Dedicated IPX.  Because of these advantages, OS/2
  108. has always been ODI and DOS ODI was shipped with v3.10 and v2.2 Netware and
  109. later.  A comparison of some of the features and capabilities between the two
  110. are listed below.
  111.  
  112.  
  113. A Comparison of Dedicated IPX and ODI
  114.  
  115. Frame type support
  116.  
  117.     DEDICATED IPX:
  118.         Ethernet Frame types Supported:
  119.                802.3
  120.                Ethernet II
  121.              Token Ring
  122.  
  123.     ODI:
  124.         Ethernet Frame types Supported:
  125.              802.2
  126.                 802.3
  127.                 Ethernet II
  128.                 Snap 
  129.         Token Ring:
  130.                 802.5
  131.                 802.2 Snap
  132.  
  133.     BENEFITS OF ODI:
  134.  
  135.         One driver allows the customer to easily support multiple 
  136.         frame types on the same network.  This opens the network up 
  137.         to more products and platforms.
  138.  
  139.  
  140. Protocol support
  141.  
  142.     DEDICATED IPX:
  143.  
  144.         Supports a single protocol stack:
  145.                 IPX
  146.                 Appletalk (on the server)
  147.  
  148.     ODI:
  149.  
  150.         Supports multiple protocol stacks simultaneously:
  151.                 IPX
  152.                 TCP/IP
  153.                 AppleTalk
  154.                 OSI
  155.                 ...etc...
  156.  
  157.     BENEFITS OF ODI:
  158.  
  159.         Allows for multiple protocol support under a single card 
  160.         and driver.  This provides easier maintenance for hooking 
  161.         up multiple clients to a single server and accessing 
  162.         resources from host servers.
  163.  
  164.  
  165. Physical board support
  166.  
  167.     DEDICATED IPX:
  168.  
  169.         Supports up to 4 physical boards in server
  170.  
  171.     ODI:
  172.  
  173.         Supports up to 255 logical boards in server or as many 
  174.         physical boards as will fit in the machine
  175.  
  176.     BENEFITS OF ODI:
  177.  
  178.         Provides support for a larger number of LAN boards.  Allows 
  179.         for balancing of network load over multiple cards. 
  180.  
  181.  
  182. Throughput capacity
  183.  
  184.     DEDICATED IPX:
  185.  
  186.         Max packet size = Up to 4k
  187.         only in powers of 2 (512, 1k, 2k, 4k)
  188.  
  189.     ODI:
  190.     
  191.         Max packet size = Up to 24k depending on media and board
  192.         limitations
  193.  
  194.     BENEFITS OF ODI:
  195.  
  196.         Substantially increases total network throughput.
  197.  
  198.  
  199. Ease of maintenance
  200.  
  201.     DEDICATED IPX:
  202.  
  203.         Drivers may not be unloaded
  204.  
  205.     ODI:
  206.  
  207.         Drivers can be loaded on the fly.
  208.  
  209.  
  210.     BENEFITS OF ODI:
  211.  
  212.         Allows you to upgrade LAN drivers with minimal interruption 
  213.         to network services.  No need to re-install operating system.
  214.  
  215.  
  216. Additional Features
  217.  
  218.     ODI:
  219.     
  220.         Also supports:
  221.                Lanalyzer for NetWare
  222.                Packet Burst
  223.                Locally administered node addresses
  224.  
  225.  
  226.     BENEFITS OF ODI:
  227.  
  228.         ODI supports network services that Dedicated IPX currently 
  229.         does not support.  Additional network services will be 
  230.         compatible with ODI as they are provided.
  231.  
  232.  
  233.  
  234. Section II: Architectural Overview
  235.  
  236. With ODI, any LAN driver can communicate with any ODI protocol stack.  The 
  237. diagram below shows the modular structure of ODI.  The three components of 
  238. ODI technology are:
  239.     Multi-Link Interface Driver (MLID)
  240.     Link Support Layer (LSL)
  241.     Protocol Stacks
  242.  
  243. Multi-Link Interface Driver (MLID)
  244. The Multi-Link Interface Driver (MLID) is a network interface card driver
  245. developed to the ODI MLI specifications. The MLID controls communication
  246. between the LAN board and the Link Support Layer.  There are two parts to the
  247. MLID: the Media Support Module (MSM) and the Hardware-Specific Module (HSM).
  248. The MSM is source code provided by Novell that implements the standard
  249. functions of LAN drivers into ODI for each of the standard media types.  The
  250. HSM is the code written by the developer to handle the LAN board details.
  251.  
  252. When the MLID receives a packet of data, it removes the media access
  253. information (MAC header) and passes the packet to the Link Support Layer.
  254. Since the media details are invisible to the LSL, this modular design provides
  255. true media independence.
  256.  
  257. Link Support Layer (LSL) 
  258. The Link Support Layer (LSL) is the technological factor that allows a single
  259. driver to support multiple protocols and for a protocol to use multiple
  260. drivers. When the LSL receives a packet of data from the MLID, the LSL acts as
  261. a switchboard by determining which protocol stack should receive the packet.
  262. This "traffic cop" functionality eliminates the need to write separate drivers
  263. for each frame/protocol combination, thereby dramatically reducing the number
  264. of drivers a developer has to write and a customer has to install.
  265.  
  266. Protocol stacks
  267. The protocol stack receives packets of information from the LSL and is unaware
  268. of the media or LAN board type through which it passed.  It then removes the
  269. protocol specific header information and passes the packets on to other
  270. higher-layer protocols or applications.  The most popular types of protocol
  271. stacks are IPX/SPX, TCP/IP, AppleTalk, and OSI.
  272.  
  273. The modular design of ODI is the key to its flexibility.  This modularity is
  274. created by making sure that the protocol stacks are unaware of media knowledge
  275. and that the MLIDs are unaware of protocol knowledge. The drivers and the
  276. protocol stacks operate independent of each other making it possible to add
  277. new media or new protocols to the file system easily.
  278.  
  279.  
  280. Section III: Comparing NDIS and ODI
  281.  
  282. NDIS was co-developed by 3COM and Microsoft.  A  drawing is included below to
  283. compare the conceptual architectural models of NDIS and ODI.  This will
  284. provide a basis for understanding the differences between the two
  285. specifications. (Note: this discussion is not meant to be an engineering-
  286. level comparison of the two specifications, but rather provide a basic working
  287. knowledge of the important differences between NDIS and ODI.)
  288.  
  289. There are several distinct differences between ODI and NDIS that end up
  290. affecting the value of products written to the different specifications. While
  291. both specifications promote schemes to support multiple protocols on an
  292. internetwork, their different approaches to enabling this functionality result
  293. in dramatically different customer implementations.
  294.  
  295. Novell's orientation on driver support is that it should be as invisible as
  296. possible to the customer. There are many issues to consider when trying to
  297. make driver support invisible to customers:
  298.  
  299. *   Technical competence: Does the driver actually do what it is supposed to
  300. do: support multiple protocols? Does it do so efficiently and gracefully?
  301.  
  302. *   Flexibility: Can additional protocols be supported as they are developed?
  303. What about additional media, such as FDDI or ATM?  How difficult is it to
  304. integrate support for these new products as they emerge? Will products based
  305. on new media or protocols work with products developed to the existing
  306. architectural specs?
  307.  
  308. *   Backward compatibility: If you are a customer and have invested in
  309. products that support ODI, will future versions of ODI continue to support
  310. these products or will you have to replace drivers? What about NDIS?
  311.  
  312. *   Reliability: How can a customer determine if a third party product really
  313. conforms to a spec, whether it be ODI or NDIS? What difference does this make
  314. to a customer? How well will different products from different vendors,
  315. written to the same spec, interoperate?
  316.  
  317. *   Development issues: How long does it take to develop ODI drivers? What is
  318. being done to reduce development time even further? How does this affect
  319. driver availability to the customer? What advantages does a "modular" approach
  320. offer over a "media-dependent" approach? How does the ODINSUP shim (available
  321. through ODI) make NDIS driver development practically unnecessary?
  322.  
  323. Flexibility
  324.  
  325. NDIS protocol stacks are media aware --they contain media knowledge in the
  326. protocol stack.  Almost all NDIS stacks will recognize and support Ethernet
  327. 802.3 or TokenRing 802.5 or both.  This means that drivers for other media
  328. such as Arcnet or ATM must shim this media to make it look like 802.3 or
  329. 802.5.  As a result NDIS drivers have been much more difficult to write to any
  330. media other than Ethernet and TokenRing.
  331.  
  332. This is not so with ODI.  ODI was designed to transparently support any
  333. network transport regardless of the underlying media.  For instance, ODI will
  334. integrate FDDI, wireless technology or other media types into your present
  335. network without the need to rewrite or change the protocol stacks.
  336.  
  337. The method NDIS employs to support multiple protocol stacks can also be an
  338. issue, especially in cases where true multiprotocol support is needed. When a
  339. system uses multiple protocol stacks, NDIS is set up to daisy chain the
  340. packets from stack to stack (through the Protocol Manager) until the packet is
  341. recognized and received.  This works well as long as the data packet always
  342. needs to go to the first protocol stack in the chain, but if the traffic is
  343. evenly spread across several stacks, or a new stack is added in later, then
  344. the Protocol Manager will spend a lot of time toggling between stacks looking
  345. for the right route for data transmission and the protocol stacks at the front
  346. of the chain will get higher performance than those at the back.
  347.  
  348. Microsoft suggests that the protocols should be loaded in order of network
  349. traffic use so as to speed up the throughput.  But when a new protocol is
  350. added to the network, it is the last protocol to get passed the packet of
  351. information.  If this new protocol is going to be used for most of the network
  352. transportation, then to get optimal speed under NDIS, you would be required to
  353. reload all of the protocol stacks, making sure that the new stack was loaded
  354. first.  In any case, the customer must have knowledge of NDIS and tweak the
  355. NDIS system to get good performance from the system.
  356.  
  357. Again, the philosophy behind ODI is to minimize customer involvement with the
  358. system -- set the system up so that the system takes care of all of the
  359. transport details. Under ODI, the LSL determines which protocol stack should
  360. receive each packet of information and the loading order is irrelevant. A
  361. stack can be added into the system and ODI automatically supports it.  And
  362. loading and unloading drivers with ODI is much easier than with NDIS: NDIS
  363. driver loading is done in the config.sys file, while ODI is a TSR and, under
  364. DOS, provides more flexibility for loading and unloading drivers.
  365.  
  366.  
  367. Reliability
  368.  
  369. Another important comparison to make between ODI and NDIS is how to gauge the
  370. reliability of drivers written to each specification.  Currently Microsoft
  371. provides test tools to developers so that they can test their own drivers
  372. after they write them.  No outside testing or verification is required for the
  373. drivers, so a customer really has no way of knowing how well tested or
  374. reliable an NDIS driver is.
  375.  
  376. This is more risky when compared to the standards Novell has set for ODI.
  377. Novell has established a department specifically designed to test and certify
  378. drivers written by developers.  This is done to assure that the drivers meet
  379. specifications and run in various configurations. In a sense, Novell Labs has
  380. established a watermark that developers must meet in order to call a product
  381. an ODI driver.
  382.  
  383. Furthermore, once an ODI driver is certified, Novell Services treats it as if
  384. it were one of Novell's drivers. If a customer running NetWare encounters a
  385. driver-related problem, Novell assumes a role in getting the problem solved.
  386. If, however, the driver is NDIS, then Services has no documentation to refer
  387. to solve the problem and cannot do much to help the customer.
  388.  
  389. Considered from a customer's standpoint, this is an important distinction. If
  390. customers base their systems on ODI drivers, they know that the products they
  391. are using have already demonstrated a significant level of compatibility with
  392. NetWare and can be supported if something should go wrong. If they go with
  393. NDIS, they are taking their own chances.  In large part because of these
  394. reliability issues, we have heard of many large accounts that have
  395. standardized on ODI drivers.
  396.  
  397. ODI drivers are certified by Novell Labs; other drivers do not have to meet 
  398. this requirement.
  399.  
  400. Backward compatibility
  401.  
  402. Another important distinction between the two specifications has to do with
  403. backward compatibility.  For example, consider a customer running with NDIS
  404. v2.0 drivers that wants to upgrade to Windows NT.  NT requires v3.0 drivers.
  405. This presents a problem if the board vendor hasn't released a v3.0 driver for
  406. the customer's board when he/she wants to install NT.
  407.  
  408. Ironically, because ODI supports any protocol stack, an ODI driver for the
  409. same board can be used to connect into NT through a shim called ODINSUP. This
  410. module allows the customer to talk to the NDIS protocol stacks unmodified over
  411. the ODI driver. ODINSUP is discussed in more detail in the following section.
  412.  
  413. Because of Novell's customer focus ODI provides complete backwards
  414. compatibility, making upgrading much simpler.  Again, once an ODI driver is
  415. installed, changes to the system, whether they be new protocol stacks, new
  416. media, or products that support a new ODI spec have no impact on the driver's
  417. compatibility. This dramatically reduces the customer' s support and
  418. maintenance burden.
  419.  
  420. Development Issues
  421.  
  422. Time to market
  423.  
  424. LAN drivers used to take six to eight to develop before ODI was introduced.  
  425. Because of ODI's modular architecture, development time to market has been 
  426. significantly reduced. 
  427.  
  428. As we have previously outlined, ODI drivers are comprised of two parts: the
  429. Media Support Module (MSM) and the Hardware-Specific Module (HSM).  In the
  430. past when developers wrote drivers they had to create code to access the
  431. protocol, service the board, and access the media. In order to simplify driver
  432. development, Novell now provides source code to interface with various media
  433. (the MSM) as part of the Novell LAN Driver Development Kit. This reduces the
  434. developer's coding burden: now they can focus on creating the
  435. hardware-specific portions of the driver and adding any optional functions.
  436. ODI's MSM/HSM drivers can be developed in 2-3 weeks.
  437.  
  438. Chipset developers have also helped to make driver development much simpler
  439. than it was in the past. Major silicon developers (including National, Intel
  440. Texas Instruments and AMD) have sample designs, software source code, bills of
  441. materials and other materials needed to build products that support ODI. These
  442. materials are available to developers that use their chipsets.
  443.  
  444. This simplification of the development process benefits customers in two ways:
  445.  
  446. *   Drivers become more standardized, easier to create, and easier to test.
  447. Ultimately, this means that they will become less expensive to produce,
  448. resulting in lower-priced products that are available sooner to customers.
  449.  
  450. *   As more of the coding related to the network interfaces becomes
  451. standardized, developers can focus their attention on building greater
  452. functionality and performance into their products. Greater speed to market
  453. means that bug fixes and patches that increase performance (such as the packet
  454. burst NLM) will be integrated more quickly and with less downtime than was
  455. previously possible.
  456.  
  457.  
  458. ODINSUP
  459.  
  460. As part of Novell's commitment to be interoperable, ODI supports NDIS. ODI's
  461. modular architecture allows users to support NDIS protocol stacks.  A module
  462. called ODINSUP allows NDIS protocol stacks to run unmodified over the ODI LSL
  463. and talk to an ODI LAN driver (please refer to the figure on the following
  464. page).  Now, multi-vendor network transports like IBM's NetBEUI, DEC's LAT or
  465. 3COM's XNS can be run over a common Data-Link (driver) specification.  This
  466. feature provides two significant benefits:
  467.  
  468. *   It allows customers to integrate, and preserve investments in,
  469. multi-vendor networking services.  Because ODI supports NDIS stacks, customers
  470. can standardize on ODI drivers, knowing that these drivers will support all of
  471. their networking needs, whether they depend on NDIS or another network
  472. transport protocol.
  473.  
  474. *   The ability to access NDIS through ODINSUP also means that developers can
  475. develop products to the ODI specification knowing that these drivers will be
  476. able to support NDIS protocol stacks. This feature significantly reduces a LAN
  477. driver developer's coding burden.
  478.  
  479. Modular architecture of ODI allows integration of new technologies without 
  480. disrupting current services, including support for NDIS stacks and FDDI.
  481.  
  482. Summary
  483.  
  484. ODI was developed with a modular architecture that makes it truly media and
  485. protocol independent.  ODI provides  greater flexibility in configuring the
  486. network interface, uses resources more effectively and preserves investments
  487. in hardware and other network resources.  With ODI, integration of new
  488. technologies can be done easily and without interrupting current services.
  489. ODI drivers are certified by Novell Labs and are therefore very reliable, and
  490. are compatible with previous versions of the ODI spec. Driver development time
  491. has been reduced due to the source code provided by Novell; this means better
  492. products get to customers more quickly.  ODI drivers can talk to NDIS stacks
  493. through ODINSUP, allowing customers to standardize on one type of drivers.
  494. Because of these advantages, Novell recommends products written to ODI.
  495.  
  496. How to Switch to ODI
  497.  
  498. Because of these advantages, Novell is including only ODI drivers with the
  499. NetWare v4.0 operating system.  Older dedicated IPX drivers are being phased
  500. out -- Novell Labs discontinued the certification of dedicated DOS IPX drivers
  501. June 1992. There are now ODI drivers available for all popular LAN adapters.
  502. See the attached appendix for a listing of tested drivers.
  503.  
  504. In order to assist in upgrading DOS workstations from dedicated IPX drivers to
  505. ODI, Novell is supplying a utility, (available in upcoming client workstation
  506. kits) called WSUPGRD, which is intended to be used by a system administrator
  507. to upgrade many workstations which are all similarly configured.  This utility
  508. is intended to be executed from the system login script.  It will scan the
  509. dedicated IPX.COM file on the workstation, determine which driver was linked
  510. in with the SHGEN utility and what hardware options were selected.  It will
  511. then reference an installation file created by the system administrator to
  512. select the appropriate ODI driver, and will install it along with the ODI Link
  513. Support Layer (LSL) module and an appropriate NET.CFG file (all of which may
  514. be configured or defined by the system administrator).  This utility is
  515. intended for use in upgrading large sites where workstations with similar
  516. brands of LAN adapters are also similar in configuration (usually under the
  517. control of a system administrator).  For example, when the command lines in
  518. the autoexec.bat files are similar, this utility will easily upgrade all the
  519. similar adapters.
  520.  
  521. This document (C) Copyright 1993 Novell
  522.