DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

New ProductsDigital's SNA Gateway ManagementArchitectureThe problem of network management is probablythe greatest impediment to effective intervendornetworking. By network management wemean configuration, performance monitoring,and fault diagnosis.In the DECnetjSNA Gateway product, wechose to partition the management problem intothree parts: management of the DECnet components,management of the SNA protocol components,and management of individual servers.This division mirrored both the logical andphysical structure of the gateway and made themanagement problem tractable.We did not attempt to implement a managementgateway. It is not possible for a networkmanager on a Digital system to display or modifyoperational parameters of the SNA network. Noris it possible for the manager of an SNA networkto display or modify parameters of the DECnetnetwork or of the DECnetjSNA Gateway itself.(It is possible, however, for either manager tolog in remotely to a system in the other networkand use its management utilities. A briefdescription of this capability is described in thesection Remote Access.)Management of DECnet ComponentsThe management of the DECnet components ofan SNA gateway node is performed according tothe DNA network management model, usingstandard DECnet management utilities from ahost DECnet node. (This paper does not discussDECnet management. See reference 8, theDEC net DNA Phase IV Network ManagementFunctional Specification , for more details.)Gateway Management EntitiesFor the SNA components of the gateway, weher;e define a model that is similar in a generalsense to th e model described in the DECnetDNA Phase IV Network Management FunctionalSpecification. Our model treats the SNAsoftware as a number of named entities, each ofwhich is the focal point fo r some managementoperation. An entity typically has pa rametricinformation that can be read and perhaps writtenand maintains current state information thatcan be read. An entity also maintains a set ofcounters that can be read andjor zeroed andsends event messages to a central logging facileity. The manageable entities are the line, the circuit,the PU, the LU, the access name, and theserver.Not all entities possess all the above properties.For example, the access name is a fairlystatic entity possessing only a name and someassociated parameters. However, the accessname has no state, no counters, and generatesno events. In contrast, a: circuit has a name,Iparameters, and a state anq also maintains countersand generates events. ( ·The line and circuit entities correspond to theidentically named entitie of DECnet management.The line entity represents the physicallayer, the circuit entity th data link layer. ThePU and LU entities represent the SNA physicaland logical units respectively. These have nodirect counterparts in DECnet management.There are certain similarities between the PUand DNA' s ECL, and the LU and DNA's session(both of which are subsued into the managemententity called executor node).An access name entity has no direct counterpanin the IBM environment. This entity is simplya shorthand form for specifying any parametersrequired to establish a session between theDECnet and SNA networks! A user process is ableIto specify an access name instead of providing. Ithe individual connection parameters. A serverentity is one that represents some son of serviceprovided to users. Two eamples of applicationservers in the SNA gateway node itself are theSNA gateway module and the RJ E server module.In a sense, the view of the gateway that resultsfrom these entity definitions is a simplificationof the gateway architecture. This simplified· view is desirable because it lessens the effortneeded to understand and hence to manage thegateway. This idea of having a simplified modelof the network for the purpose of managementis common to both SNA and DNA.Configuration ManagementConfiguration and oper,a ting parameters forthe SNA components in[ the gateway are setor modified by using al management utilityrunning on the DECnet qost node. This utilitycommunicates with the SNA network managementlistener in the gateway node.The general command syntax is derived fromthat of DECnet management but has beenchanged to accommodate the details of SNADigital Tecbnlcal]ournalNo. 3 September 198647
The DECnetjSNA Gateway Productoperation. A few examples of the syntax aregiven as follows:SET LINE DSV-0 DUPLEX FULLSET CIRCUIT SDLC-0 ADDRESS 40STATION 1D OOOOODECSET ACCESS NAME CICS CIRCUIT SNA-0APPLICATION CICS6 LU LIST 1-16In these examples, LINE DSV-0, CIRCUITSDLC-0, and ACCESS NAME CICS identify theentities to which each SET command is to apply.The rest of each SET command string is asequence of parameter names, each followed bythe value to be set. Thus ADDRESS 40 indicatesthat the address parameter (the SDLC secondarystation address) is to be set to the value hexadecimal40.Performance MonitoringSNA gateway management maintains counters,associated with various entities, which recordstatistics. These include the amount of data transmitted,the number of CRC errors occurring on aparticular data link, any buffer availability problems,and so forth. By examining these countersperiodically, the DECnet network manager cansee how well the various components of the gatewayare performing and whether or not any problemsneed to be investigated.Fault DiagnosisThere is considerable overlap between performancemonitoring and fault diagnosis. Frequently,poor performance is the first indicationof a fault; thus counters can be viewed as faultdiagnosisaids. Event-logging messages are alsouseful in diagnosing faults; for example, frequentcircuit-down events could indicate hardwareproblems. Event messages are generated byvarious software components in the gateway andare sent to the DECnet host. Usually the eventsare displayed on the operator console of thehost; they may also be collected in a file for latei:analysis.Gateway management also supports commandsthat allow loopback testing to be performed.The system can isolate failing hardwarecomponents by using loopback at various levels.Management of ServersServer management is perhaps the least welldefined area of the SNA gateway managementarchitecture. The range of different servers thatmay be implemented makes it difficult toinclude sufficient support for all servers. Thus ifnecessary, each server implements its own managementutility.Remote AccessAlthough neither the DECnet network managernor the SNA network manager can directly controlthe other, it is possible to use remote terminalaccess mechanisms to effect some degree ofindirect control. The manager must log in to asystem in the "other" network, and hencebecome a user of that network, in order to gainaccess to the network management programs.The DECnetjSNA VMS 3270 terminal emulator(TE) allows the DECnet network manager to logon to IBM applications, including the SNA networkmanagement utilities, such as NCCF. Hecan thus control the SNA network to the extentthat he has the privilege to do so.The DECnetjSNA distributed host commandfacility (DHCF) allows the SNA network managerto log on to a VMS system through the gateway.Once logged in with sufficient privilege, he canissue NCP commands and hence control theDECnet network.DECnet/SNA Gateway ComponentsThe DECnetjSNA Gateway provides a protocolhandlinginterface between SNA and DECnet networks.The gateway, introduced in 1982, was thefirst product to provide remote functions over anetwork from a closed server system. The gatewayconsists of several software components;Figure 11 provides an overview of its majorparts. The base software is the RSX-1 1S operatingsystem with a communications supervisor calledthe CommExec. These two components providethe environment for both the DECnet-RSX softwareand the RSXjSNA protocol emulator.RSX- 11 S, Communications Executive,and DECnet-RSX SoftwareWe chose the RSX-1 1S software for the followingreasons:• The RSX-11S operating system was well documentedand provided a good developmentbase by means of the RSX- 11 M operating system,a well-tested one.• The RSX- 1 1 S system, being a memory-only system,required no expensive peripherals thatwould add to the cost of the gateway.48Digital TecbnlcaljournalNo. 3 September 1986
Page 1 and 2: Netwo;king ProductsDigital Technica
Page 3 and 4: Editor's IntroductionRichard W. Bea
Page 5 and 6: BiographiesRaj Jain Raj Jain gradua
Page 7: BiographiesDavid R. Oran Dave Oran
Page 10 and 11: increase the sizes of networks, we
Page 12: New Productsmust be able to coexist
Page 15 and 16: A Digital Network Architecture Over
Page 21 and 22: ---A Digital Network Architecture O
Page 27 and 28: Performance Analysis and Modeling o
Page 29 and 30: ---Performance Analysis and Modelin
Page 31 and 32: Performance Analysis and Modeling o
Page 33 and 34: ---Performance Analysis and Modelin
Page 35 and 36: --Performance Analysis and Modeling
Page 37 and 38: The DECnet/SNA Gateway Product• H
Page 39 and 40: The DECnetjSNA Gateway ProductFrom
Page 41 and 42: The DECnetjSNA Gateway Productcommu
Page 43 and 44: The DECnetjSNA Gateway ProductUSER
Page 45 and 46: The DECnetjSNA Gateway ProductThe u
Page 47: The DECnetjSNA Gateway ProductDECne
Page 51 and 52: The DECnetjSNA Gateway ProductSegme
Page 53 and 54: The DECnetjSNA Gateway Product• O
Page 55 and 56: WiUiam R. HaweMark F. KempfAlanJ. K
Page 57 and 58: The Extended Local Area Network Arc
Page 75 and 76: Terminal Servers on Ethernet Local
Page 89 and 90: Paul R. Beckjames A. KryckaThe DECn
Page 91 and 92: The DEC net- VA X Product - An Inte
Page 93 and 94: The DECnet- VA X Product - An Integ
Page 95 and 96: The DECnet- VAX Product - An Integr
Page 97 and 98: The DEC net- VA X Product - An Inte
Page 99 and 100:
The DECnet- VAX Product - An Integr
Page 101 and 102:
john Forecastjames L. jacksonjeffre
Page 103 and 104:
The DECnet,ULTRIX SoftwareComponent
Page 105 and 106:
The DECnet- ULTRIX Softwarehave pro
Page 107 and 108:
The DECnet- ULTRIX Softwaresystems.
Page 109 and 110:
Peter 0. MierswaIDavid J. MittonMar
Page 111 and 112:
The DECnet-DOS Systemthat CCB, whic
Page 113 and 114:
The DECnet-DOS Systemdata link laye
Page 115 and 116:
Tbe DECnet-DOS SystemNDU and the vi
Page 117 and 118:
Th e DECnet-DOS Systemconsole can a
Page 119 and 120:
The Evolution of Network Management
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
The NMCCjDECnet Monitor Design5. Op
Page 133 and 134:
Th e NMCCjDECnet Monitor DesignFigu
Page 135 and 136:
The NMCCjDECnet Monitor DesignKERNE
Page 137 and 138:
The NMCCjDECnet Monitor Designinto
Page 139 and 140:
The NMCCj/JECnet Monitor DesignThe
Page 141 and 142:
The NMCCjDECnet Monitor Designcan s
Page 143 and 144:
Editorial StaffEditor - Richard W.
show all

DTJ Number 3 September 1987 - Digital Technical Journals

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?