DTJ Number 3 September 1987 - Digital Technical Journals

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 Digital 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 Digital '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-118Digital TecbnicalJournalNo. 3 September 1986