DTJ Number 3 September 1987 - Digital Technical Journals

The DECnetjSNA Gateway Product• One must clearly understand the properties ofall architectures to be interconnected to determinethe most effective level of interconnectionbetween them from a base services standpoint.• In implementing the interconnect, one musttake consistent approaches that take intoaccount both the turnkey functions to beimplemented as well as end-user requirementsconcerning those functions. (For example, is iteffective to split functions across multiple systems,and if so, what are the benefits?)A modular approach that uses effectively bothhardware and software "building blocks" is alsoimportant for reliability, maintainability, andreusability considerations. Thus it is as importantto provide a modular implementation consistingof known, proven software segments as it is touse a framework that allows "mixing and matching"pieces to facilitate the development of newfunctions for various base systems. Once a structurehas been defined, the turnkey functionsthemselves must be of a bidirectional nature,allowing users in one environment equal accessto the resources 'of the other (provided, ofcourse, they are authorized to do so) .Coincident with all this functionality is theneed to manage it effectively, either from a centralizedpoint in the network or at the distributedpoints closest to the actual work being done. Aninterconnect structure must be chosen thatallows the continuing use of existing mechanismswith convenient "hooks" to access otherenvironments, if needs so dictate. Finally, theapproach chosen must be flexible enough toallow existing structures to migrate convenientlyto more cost-effective technologies as theybecome available, all without disrupting the userinterface. The preservation of existing userinvestment must always be a key concern.All these goals were met in the existingDECnetjSNA Gateway product set. Our approachis the.result of a carefully considered structure,not of an ad-hoc collection of functionality. Thatstructure facilitates the rapid development ofnew functionality today and preserves existingapplication investments for the increasingly distributedprocessing world of tomorrow. Weexpect these products to be key components ofthe network that eventually becomes thesystem. ·AcknowledgmentsThe authors would like to acknowledge the contributionsof the following members of Digital'sIBM Interconnect Engineering team, withoutwhose diligent effort much of our successwould not have been possible: Scott Davidson,Dave Garrod, Bob Fleming, and LadanPooroshani of the Littleton team; Bob Ellis fromColorado Springs; Richard Benwell, Carol Charlton,and Chris Chapman of the Reading, U.K.,team; and Craig Dudley of Systems and CommunicationsSciences. Their , leadership efforts havetruly resulted in leadership products.References1. V. Cerf and P. Kirstein, "Issues in Packet­Network Interconnection,'' Proceedingsof the IEEE , vol. 66, no. 11 (November1978) : 1386-1408.2. Systems Network Architecture: TechnicalOverview (Armonk: IBM Corporation,Order No. GC30-3073, March 1982).3. Systems Network Architecture: TransactionProgrammer's Reference Manualfo r Logical Unit Type 6. 2 (Armonk: IBMCorporation, Order No. GC30-3084, May1983).4.Systems Network Architecture: Sessionsbetween Logical Units (Armonk: IBM Corporation,Order No. GC20-1868, April1981).5. Digital Network Architecture Phase IVGeneral Description (Maynard: DigitalEquipment Corporation', Order No. AA­N149A-TC, May 1982) .6. J. Morency, "The SNA Gateway-The Foundationfor the Information Bridge," Proceedingsof INTERFA CE '83 (March1983): 146-154.7. ]. Morency and R. Flakes, "Gateways: AVital Link to SNA Network Environments,''Data Communications Oanuary 1984):159-166.8. DECnet Digital Network ArchitecturePhase IV Network Management FunctionalSpecification (Maynard: DigitalEquipment Corporation, Order No. AA­X437A-TK, December 1983).52Digital TecbnlcalJournalNo. 3 September 1986