DTJ Number 3 September 1987 - Digital Technical Journals

The DECnetjSNA Gateway Productcommunicate, provided that naming and securityconstraints have been satisfied. DNA has onlytwo node types: end and routing. The nature ofapplication process communication is determinedby using either Digital-defined protocolsat the network application layer or protocolsdefined by end users. A communication instancebetween two partners is called a logical link,with partners being identified via a networknode name (associated with a network-uniquenode address) and a particular object typeidentifier. 5Interconnection Issues betweenDNA and SNA NetworksAn interconnection between DNA and SNA networksinvolves a number of the questions raisedearlier in this paper about network interconnection.Some effective answers to these questionsare provided by a product called the DECnetjSNA Gateway. This product was developed byDigital Equipment Corporation to address thesemany issues. Other issues, such as the nature ofhardware interconnection used, the extent towhich common services are shared, the architecturalinterface of each network (and its associatedusers) to the other, the cross-network certificationof products, and installation factors,were all addressed as pan of the development ofthis product.6·7The remaining sections of this paper addressthe DECnetjSNA Gateway from two perspectives.The first examines the architectural philosophyand protocols upon which the gateway is based.The second examines the actual components ofthe gateway in terms of both the hardware packagingand software modules used to give thedesired degree of interconnection. In both sectionsattention is given to the question of howeffectively the design approach addressed manyof the aforesaid issues.The Need fo r a DNAjSNA GatewayA fundamental decision in attempting to bridgethe gap between two different network architecturesis whether to simply incorporate one architectureinto the other or to employ some form ofgateway. In the case of a DNAjSNA bridge, reproducingall of SNA into each DNA implementationwas not feasible, given SNA's size and complexity.On the other hand, implementing the DNAarchitecture into the confines of an SNA nodewas an attractive technical alternative. This con-cept was rejected, however, due to dauntingmaintenance and support considerations. Basedon these factors, we adopted the gatewayapproach.Building this gateway was a tricky businessbecause the two architectures differ not only intheir detailed protocol specifications but also inthe services provided at layer boundaries.Despite superficial similarities (both architectureshave seven layers, both support meshtopologies, and so forth) , SNA and DNA are aboutas dissimilar as can be.For example, at the network layer, DNA routingprovides a connectionless service using anadaptive routing algorithm; conversely, SNApath control provides a connection-oriented serviceusing quasi-fixed routing. At the transportlayer, the DNA structure uses a standard, symmetric,three-way handshake to establish connection;whereas SNA uses an asymmetric, threepartynegotiation. At the session layer, the DNAarchitecture provides simple process-bindingand access-control functions; whereas SNAprovides complex data-phase services, suchas chains, brackets, and multiple acknowledgmentschemes. At the application layer, the differencesare even more pronounced. A centralDNA application service is file transfer andaccess, which SNA does not support at all.Conversely, a widely used SNA application serviceis remote job entry, for which DNA has nocounterpart.Possible Gateway ArchitecturesThere were three possible architecturalapproaches to bridging this gap. First, a protocoltranslation gateway could be used to find a sufficientlysimilar pair (or pairs) of protocols andprovide a deterministic mapping between theirmessages. Second, a one-way encapsulation gatewaycould be used to select one protocol of onearchitecture and encapsulate all higher-layerprotocols of the other architecture. Third, a twoway,or mutual, encapsulation gateway could beused to operate as two one-way gateways to carrythe higher-layer protocols of each architectureover the lower-layer protocols of the other.Now, protocol translation gateways have the(at least theoretical) advantage of providingtransparent communication between two incompatiblenetwork architectures. They do that byhiding the differences inside the gateway box.Our initial attempts at designing an SNA gateway40Digital TecbnlcalJournalNo. 3 September I 986