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