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 Productswork products was very desirable to customersand would allow us to eliminate duplication ondevelopment projects.For IAN bridges, our strategy was to use a nonproprietaryprotocol based on the evolving IEEE80 2 .1 management protocol. This strategy wasthe first step in an evolution toward the adoptionof emerging international standards for networkmanagement. 2 Since the development of managementprotocol standards had q.ot been completed,using such protocols amounted toworking with prototypes. However, the needto evolve the strategy in this direction wasclear.NCP and other similar products developed forSNA gateway and IAN bridge management providethe network manager with various simplefunctions. Among these are configuration control, low-level testing, and snapshot views ofstate information and various traffic and errorcounters.While integrating these products, both thearchitecture and the subsequent implementationstrategy must be enhanced to allow the independentdevelopment of management capabilitiesfor these diverse components. We are currentlyworking on such enhancements, as discussed inthe section "Future Developments."Other factors were also highlighted while wedeveloped management capabilities for bridges,gateways, and servers. These more recent additionsto our network product set do not alwaysprovide local access to their own managementcapabilities or allow the initiation of managementaccess to other network components. Manyhave no locitlly connected device to support alocal management user interface. To allow networkmanagement for these components, sometype of remote management access from anotherstation that does provide a management userinterface is essential.Remote access is also the key for managingDECnet nodes. Without this access, no managercould see more than his own local node information,which is not sufficient to diagnose andsolve overall network problems. Without remoteaccess, service personnel would have to be sentto each node location that was experiencing theproblem in order to collect management information.This problem results in networks that aremuch more expensive to service.Remote access to the management applicationcan be provided in a number of ways. Access canbe centralized, in which one management stationprovides access to the entire network; distributedto a few management stations; or fullydistributed to all nodes, as ·access is in DECnetNCP. In any case remote accrss from one node tothe management functions ahd data from anothernode necessitates designin and implementingthe management application itself as a dis-1tributed function. The architecture for this distributedmanagement must specify a set ofdistributed software and ,database elementsthat will be needed to manage diverse networkcomponents.Distributed Managerrt,ent Architectureand Application ElemmtsThe basic elements that must be included in adistributed management architecture and in theapplications developed within it are• A user interface• A management agent in ech component to bemanaged, providing remote access to its man-•Iagement funcuons and dataII• A communications mechanism between thenode running the user irtterface and the agentsoftware modules in the network componentsbeing managed• A management database ·.• A set of simple managment functions onwhich more intelligent functions can belayered !Figure 1 illustrates the relationships betweenthese elements.The User InterfaceThe user interface and software to invoke managementfunctions genedlly reside on one ormore management stations i (more if distributed,as with NCP; or one if centralized) . The userinterface is the key to developing an integratedmanagement application from a network manager'sperspective. In developing new networkproducts, we have extended the command languagesyntax developed for DECnet managementto X.25 connections and SNA gateway products,as well as to bridge and seer products currentlyIunder development. Thus 1a common commandstyle, resembling English sntences as closely aspossible, has been used to manage our expandingset of network products.I<strong>Digital</strong> TecbnlcaiJournnlNo. 3 <strong>September</strong> 1986119

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

Saved successfully!

Ooh no, something went wrong!