New Productson a bigger VAX system, there is now much moreCPU power available for the primary tasks sincethe PjFM software takes a correspondinglysmaller slice. In fact, it's quite feasible torun this software on the same hardware with theALL-IN- I system. The advantage here is that whenrunning P jFM, the user is presented with thesame type of user interface down to the individualkeystrokes. In fact , with simple modifications,a user could actually take P jFM reports andmail them to ALL-IN -I users, thus closing theloop between the telecommunications and MISdepartments.Parallels between Vo ice andData NetworksThere are some interesting parallels betweenmanaging voice networks and data networks.Both management schemes can potentiallyrequire tremendous amounts of storage, andmanipulating that data can require a lot of CPUpower as we ll. It also appears that no matterwhat capabilities are provided in the base package, customers always have additional requirements.The capability has always existed to buildcomplex systems to analyze massive amounts ofdata. However, they have been too expensive forall but a few companies. Hardware capabilitieshave now become large enough and cheapenough to allow the full integration of both typesof network management on a single system.The computers in the new generation of VAXsystems, especially the MicroVAX II system,provide the right amount of CPU power at theright time. As regards software customization, wecan accommodate the need for custom-builtproducts by creating base software that will supportthat strategy. With PjFM, the ALL-IN- I systemwas used as the base on which customerdesignedapplications could easily be added.That is a case study of how management applicationscan fit into a more global structure. As ournetwork management architecture evolves, itwill define the global structure to be used forintegrating and customizing the software forboth data and voice management applications.Future DevelopmentsThe lessons learned from developing the productsdescribed above are helping us to plan thecontinued evolution of <strong>Digital</strong>'s network managementeffort. This effort will address the managementneeds for the complex network environ-<strong>Digital</strong> <strong>Technical</strong>JournalNo. 3 <strong>September</strong> 1986ment now emerging. Developing products likeIthe DECnet monitor and PfFM are the fi rst step inthis direction. However, thy are only the beginningof a long-term commitment to produce anintegrated management arthitecture and managementsoftware based on an integrated model.Future versions of existing products will evolvewithin the framework of this model.Our proprietary management architecture isbeing extended beyond the range of the DECnetsoftware and toward international standardsas they evolve . This architecture will furtherintegrate the management of non-DECnet products,such as Ethernet bridges and SNA gateways,with the existing integrated management capabilitiesof DECnet and X.25 products. This integrationwill extend remote :access to the currentmanagement functions of all products (e.g.,simple network control funbions for all servers,and monitoring for brides , gateways , andIservers) .·While extending our management architecture,we are developing a more loosely coupledmanagement software desikn that will ease theaddition of new network products and managementfunctions. This design will include a unifieduser interface across network products andnetwork management functions and will providea choice of interface styles (e.g., command line,fo rms, graphics) . The design will also allowusers to customize their soare in several ways.A customer should be able to purchase as little oras much network manageqtent capability as hedesires. Customers want to elect which networkproducts are to be managt;d and which higherlevelmanagement functions are needed. Theirgoal is to tailor the managehtent application softwareappropriately for thir network environments.Customers' or Digftal's field personnelshould be easily able to add customized softwareenhancements, such as special reports and newintelligent management functions.Besides extending the architecture and developingan integrated software design, we are evaluatingthe market requirements for the additionof more intelligent management functions andmanagement for emerging technologies. Part ofthis evaluation is understanding the ISDN standardsand future products based on those standards.We need to determine how and when therequirements for integrated voice and data networksand network management will appear inthe customer environme!nt. We also want toIIIIiII27
The Evolution of Network Management Productsunderstand customers' needs for the integrationof network management with system and applicationmanagement.Throughout its evolution, network managementhas become increasingly essential to customerswhose businesses depend on the operationof their networks. One problem has beenthat network management fu nctions have highrequirements for processor power and databasestorage. However, since processing power isbecoming cheaper, customers can now takeadvantage of smaller, less expensive, yet morepowerful processors to fu lfill these needs. Theprimary evolutionary trend for network managementhas always been to make people mon; efficient.The affordability of increased processorpower will contribute enormously to <strong>Digital</strong>'sability to provide integrated, extensible, andmore-intelligent management functions. Theavailability of these functions will make peoplemore efficient and effective in the future.ConclusionSome important goals and guidelines haveemerged from the evolutionary processdescribed in this paper. They will serve as aguide for fu ture network management developmentin <strong>Digital</strong> Equipment Corporation .• New products to be used in DECnet networksshould incorporate basic network managementwhen those products are introduced.• Remote access to management functions isneeded to support both decentralized andcentralized management.• An integrated management architecture isdesirable, yet_ it must allow actual productimplementations that are not tightly coupled.• Commonality in management user interfaces,databases, protocols, and fu nctions reducescomplexity, makes the products easier to use,and reduces the duplication of developmentresources.• More intelligent and automated data-analysisand evaluation fu nctions are needed to facilitatethe network manager's job. These functionsshould address the network managementrequirements of all network products.• Customers should be able to tailor the managementapplication software appropriatelyfor their network environments.• Network management is a distributed applicationthat should be integrated into the overallsystem environment in support of users'businesses.AcknowledgmentsThe authors express their appreciation to JimCritser, Stan Goldfarb, Bernard Harris, Bill Keyworth,John Morency, Louise Potter, and DonnaRitter for their careful review and many suggestionsthat have enhanced the ideas presented inthis paper.References1. DECnet <strong>Digital</strong> Network Architecture(Phase IV) Network Management Fu nctionalSp ecification (Maynard : <strong>Digital</strong>Equipment Corporation, Order No. AAX437A-TK, 1983).2. ]. Heffernan and D. Ritter, "Remote BridgeManagement," DECUS NETwords Newsletter(1986).3. N. La Pelle and K. Chapman, "BuildingBlocks for Remote LAN System Management,"FOCjLAN85 Proceedings (<strong>September</strong>1985): 137- 146.4. D. Thompson, "A Management Standard forLocal Area Networks," IEEE Fo urth InternationalConference on Computers andCommunications (March 1985): 390- 396 .5. N. La Pelle and K. Chapman, "Distribution ofthe Management Function in LAN Systems,"Second Annual ACM Northeast RegionalConference Proceedings (October 1985) :250-267.6. M. Sylor, "The NMCCjDECnet MonitorDesign,'' <strong>Digital</strong> Te chnical journal (<strong>September</strong>1986, this issue) : 129,-141.• The distinction between voice and data networksis becoming less distinct, and networkmanagement must consider both.128<strong>Digital</strong> Tecbnical]ournolNo. 3 <strong>September</strong> 1986