10.07.2015 Views

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

SHOW MORE
SHOW LESS

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

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

New Productsusers. Furthermore, the same management functionmight result in different actions for differentnetwork products. Inconsistency of this typeresults in user confusion and dissatisfaction.Management ProtocolsA management protocol is the vehicle for communicatingmanagement functions and databetween the user interface and the managementagent. The NICE protocol was developed for thispurpose within standard DECnet components.NICE was later extended to include X.25 gatewaymanagement and was also used as the basefor adding extensions to manage DECnetjSNAgateways. As mentioned earlier, for non-DECnetservers and bridges, we are tracking the evolutionof a nonproprietary standard managementprotocol.The communication mechanism between theuser interface and the management agent mustalso provide reliable transmission and end-to-endintegrity of management function requests andmanagement data. These requirements have beensatisfied by the data link and end communication(OSI transport) layers of the <strong>Digital</strong> NetworkArchitecture for DECnet links. These layers havealso been used in the management of the gatewaysbetween DECnet and X.25 or SNA networkssince the layers are available on all componentsimplementing the DECnet standards.For LAN bridges and some other non-DECnetserver implementations, other transport mechanismshave been used with the management protocol.In the case of bridges, no transport mecha"nism is implemented at the bridge; simpledatagram-based management is used. For bridgemanagement, the node running RBMS mustassume total responsibility for the reliable transmissionand integrity of management messageson the LAN . The component being managedassumes no mutual responsibility for these messages.Based on product constraints, the responsibilityfor the reliable communication of managementinformation can thus be distributed in avariety of ways . Therefore, we must extend thenetwork management architecture to specify astandard solution to this problem for non­DECnet products.Management DatabaseThe database needed to support the managementapplication can be distributed in a number ofways. Some data must be maintained by the man-<strong>Digital</strong> <strong>Technical</strong>journalNo. 3 <strong>September</strong> 1986aged components themselve, including componentidentification, state infbrmation, traffic anderror counts, and other operational parameters. Apermanent copy of the operational parametersmust be maintained in nonvolatile storage torecover from human, computer, and networkfailures. This copy could exist either in nonvolatileRAM in the compom nt, on local externalstorage, or on a file at the l: emote managementstation. If the copy exists at ' the management station,then the component must depend on thatstation for correct operation unless the data isalso stored locally.Other data files that might be contained in amanagement database inclure the fo llowing:• Loadable software image 'files for both operationaland diagnostic imges associated withparticular network components• Event log files in which notifications of significantevents for network :components are col·'lected• Reference data files that,] though not essentialfor component operation, give informationrelevant to the physical identification, location,and servicing of network components• Management directoryThe management directqry contains informationneeded to identify and locate data relevantto a particular component and to gain access tonetwOrk addresses for the components themselves.Those addresses are needed for the purposeof remote management access.To provide reliable access to essential directoryinformation, the directory data must eitherbe part of a network-wide : directory (or namingservice) or be kept at the d.anagement station ofthe component. The other 1 files, however, couldreside at the management station or on externalstorage at the component, if such storage exists.(It does not exist for many components · likebridges, gateways, and some servers.) The directorycan be used to access idata no matter whereit resides. The directory ! allows managementdata distribution trade-off to be made to meeti'the needs of the network • products themselvesas we ll as those of the management stationsoftware.Management FunctionsSimple management fu nctions are network con­Itrol functions involving interactions with net-1tI121

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!