Nancy R. La PeUejMarkJ. Segerb:fark W. SylorIThe Evolution of NetworkAlanagent ProducThe management of data networks bas evolved at <strong>Digital</strong> since 1978,although the management of voice networks bas been a more recent phe·nomenon. <strong>Digital</strong>'s first data network management products mnagednetworks of DECnet nodes. Our capabilities now include the managementof diverse data network components by means of several different prod·ucts described in this paper. The integration of these data network man·agement capabilities through a common architecture, user interfaces,management databases, and protocols is a major short-term gal. Theintegration of voice and data network management is a much longertermgoal. The voice management product presented here wiU be 'part ofthat future integration.The size and complexity of networks have beengrowing at an accelerating rate. For example,over the last ten years the size of <strong>Digital</strong>'s internalnetwork has grown from a few communicatingsystems to over 10,000 computer nodes, distributedthroughout 250 sites in 37 countries.We are currently adding about a hundred newsystems per week to this private network. Thisrapid growth has led to a need for more-sophisticatednetwork management capabilities to controlsuch networks. This paper describes thechanging needs of network management, how<strong>Digital</strong>'s products and capabilities have evolvedto meet those needs, and some directions forfuture evolution.Traditionally, networks have come in two categories:data and voice. <strong>Digital</strong> supports manydata network architectures, including BISYNCH,SNA; X.25, Ethernet, and OSI. However, theprimary one supported is the <strong>Digital</strong> NetworkArchitecture, or DNA, which defines our DECnetproducts.The Network EvolutionSome basic network management capabilitieswere added to the DNA architecture early in itsevolution (1978) . These capabilities includedthe manual on-line observation and control ofboth local and remote network nodes. Includedin the DNA design was a network control programthat was to be implemented consistently<strong>Digital</strong> <strong>Technical</strong> JournalNo. 3 <strong>September</strong> 1986across all DECnet produCts.1 That programwould allow a network mahager to control theoperation and configuration of the network bymanipulating operational parameters. The programwould also allow him to observe how wellthe network operated by providing current statusinformation, and network traffic and error data.IBasic Management Capabilities fo r theWhole NetworkAs other architectures and protocols emerged,new products, such as X.2,5 and SNA gateways,and local area network (LAN) bridges, neededthe same capabilities to b managed as did theDECnet products. This requirement broughtabout the first major evolutionary trend in networkmanagement. It became clear that DNA hadto be extended to accommodate the managementof connections to these non-DECnet products.Adding Intelligence tO Management·FunctionsThe second evolutionary trend was driven by theincreased size and complexity of DECnet networksand the difficulty in finding qualified peopleto manage them and the: systems within them.This trend led to the need for more-intelligentnetwork management functions to support a centralizedstaff dedicated to managing the network.To partially meet this need, we developed a productthat automates the rponitoring of trafficiIII117
The Evolution of Network Management Productsand other events in the network. This productalso contains many event evaluation functions,which produce statistics made available throughboth interactive and hard-copy reports.Other products have also added intelligence tothe basic network control capabilities of theearly DNA architecture . These products performIAN testing and diagnosis, and X.25 accountingand enhanced protocol-tracing.Vo ice Network IntegrationAn evolutionary trend similar to that in data networkswas also happening in voice networks .Vo ice network users were becoming moresophisticated, requesting capabilities similar tothose seen in data networks. For example, liketheir data network counterparts, voice networkmanagers need the ability to control, optimize,configure, and monitor the network. In additionto collecting management data, users alsorequested its processing to provide managementinformation.At the present time, telecommunications networkmanagement has evolved beyond the scopeof the DNA design. Because of this rapid advance,product strategies have been adopted for telecommunicationsmanagement that identify anumber of directions data network managementproducts could pursue in the future . Specifically,we are expanding our management architectureto allow for the inclusion of additionalnetwork components. We also see the need tointegrate management user interfaces and informationwith other network applications. Thisintegration will support all the business-data andresource-management needs of users.The remainder of this paper covers the evolutionof network management in more detail as itrelates to the development of specific managementproducts. The fo llowing section discussesdata network management as a distributedapplication that provides operational controland observation of a variety of data networkproducts.Management as a DistributedApplicationNetwork management within <strong>Digital</strong> EquipmentCorporation began as the management of networksof DECnet nodes. These networks consistedof peer computer nodes with peer managementcapabilities; that is, each node had remoteaccess to the management capabilities of everyother node, subject only to access control. Eachnode also provided access to its own managementfunctions and data for its own local users.A common user-interface program, called thenetwork control program (NCP) , is implementedacross all DECnet products. This programis not simply a remote console interface tonetwork products. In addition, it allows remoteaccess to network management functions via apublished, proprietary protocol.The character of <strong>Digital</strong> 's networks haschanged significantly over the last ten years.They now have components that are neitherDECnet nodes nor peers, such as IAN bridges,gateways, and other servers of various kinds. Theapproach we used to integrate the managementof these products was based on the DNA managementstrategy. That is, the level of function andthe general presentation to the user were similarto those originally in DNA network management.A number of initial strategies were tried toextend the architecture in various ways toinclude the management of these products.For X.25 connections, our initial strategy wasto extend the arch itecture by adding X.25-specific capabilities. Unfortunately, this strategytightly coupled the management of the X.25product to that of the DECnet product by addingX. 25 management to NCP. That coupling madeupgrading the management implementation foreither product more difficult since it createdinterdependencies between product developmentschedules. We have found these interdependenciesto be difficult to manage with onlythese two products. This strategy would be completelyunworkable if we pursued it for the managementof all the different network products.Nothing would come to market if we had to coordinatethe development and release schedulesfor dozens of interrelated items.For SNA gateways, our temporary strategy wasto derive a parallel management architecture forSNA, based on the DNA management capabilities.Wh ile decoupling the two architectures andimplementations, this strategy only postponedthe integration of network management for SNAgateways. It also resulted in multiple managementprotocols and user interfaces, although theparallels between these were obvious. We couldreadily see that this approach would not workwell in the long term as the number of productsto be managed increased. We also knew that integrationof network management for all our net-118<strong>Digital</strong> TecbnicalJournalNo. 3 <strong>September</strong> 1986