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.

The NMCCjDECnet Monitor Design5. Operational , in which the managerobserves a terminal on which informationabout the network is continuously displayedThe NMCC architecture supports all five usagestyles.• Variety of information - The complexity ofthe network is reflected in the variety of informationthat the network's components canpresent to a monitor. It must collect, store,and analyze configuration, status, performance,error, and reference information aboutthe network. Each component in the networkcan supply information about one or more ofthese categories. Moreover, a monitor musthave information to control its own behavior.• Real time and history - A monitor mustprovide information about current conditionsin the network. Of course, "current" is a relativeterm because changes occur in real timeas more recent information is gathered. Amonitor must also provide historical data,needed to compute trends over periods oftime. Network managers must be able to"replay" what occurred in the network, bothfor long-term reporting and for immediateproblem solving.• Ease of use and clarity of presentation - Theefficiency of information presentation is veryimportant, given that the manager interacts soclosely with the monitor. Often, graphics arethe best way to present complex statisticalinformation and topological relationships thatare difficult to display in any other way.• Universality -A typical DECnet network isimplemented across many diverse computerhardware and software systems and supports avariety of communications media. Thus amoitor must be able to collect and presentinformation from each and every one of them.High Level Design of theNMCC SoftwareTo meet the requirements discussed above, wedecided that NMCC had to provide five basicfunctions:• Collect data from the network• Store the data• Distribute that data to users upon request• Evaluate the data into meaningful information• Present that information to the network managerand end users upon requestWe also decided to support two usage modes: a:.1interactive user interface, which supports theroutine, browse, alarm, and operational styles ofusage; and a reporting user interface, which supportsthe batch usage style.These decisions led naturally to the overallMCC design shown in Figure 2. The monitorconsists of three major programs: the kernel, theinteractive user interface, and the reportspackage.The kernel collects data from the componentsin the network and stores that data in an on-linedatabase. The kernel distributes the stored databoth through the NMCC protocol used by theinteractive user interface and through the historyfiles used by the reports package. Running continuously,the kernel supports parallel activitiesfor multiple simultaneous users.The interactive user-interface (UI) programcan be run on demand by the manager or any userwith proper authorization. This program evaluatesthe data and returns the subsequent informa-. tion to the person requesting it. The UI programalso manages the operation of the monitor itself.The programs in the reports package also evaluatethe data, which is presented as hard-copyreports. The kernel periodically writes data fromits on-line database into history files, which arearchived copies of the data collected during eachday of operation.The design of NMCC separates the kernel,which is a management server, from the networkmanager's workstation, the user interfaces, andthe reports package. This separation allows thekernel to be run on one system, while the otherprograms can run on other systems.Common Design ThreadsThree common threads run through much of thedesign of the NMCCjDECnet Monitor system.These threads involve a data model, a request/response operation, and a news function.Data ModelEarly in the design, we focused on modeling thedata being manipulated by the managementfunctions rather than modeling the functionsthemselves. We felt that the organization of thedata was more complex than the functions.130<strong>Digital</strong> <strong>Technical</strong> journalNo. 3 <strong>September</strong> 1986

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

Saved successfully!

Ooh no, something went wrong!