Understanding the Classic Network Management Architectures
Working Smarter, Part Two: Understanding where existing network management architectures originated helps you get a handle on the diversity of choices you'll face when you choose your tools.
Our previous tutorial began our series on enterprise network management, and looked at the five functional areas of network management defined by the ISO as part of its research into the seven-layer Open Systems Interconnection (OSI) model. To review, these five areas are:
- fault management
- accounting management
- configuration management
- performance management
- security management
But let’s take a step back for a moment, and recognize that the typical enterprise network manager has many subsystems that he or she is responsible for. You are likely dealing with some type of centralized or distributed computing system, local and wide area data networks (LANs and WANs), Internet access, and possibly a video conferencing network. You many also have deployed integrated applications, such as VoIP, call centers or unified messaging, which depend on a mix of voice and data elements. There are likely desktop workstations, perhaps running under Windows, Mac OS and/or UNIX/Linux, plus all of the applications that run on those workstations. In addition, you probably have some backup systems, protecting the data storage, power, and possibly WAN access, which are also part of the mix. So when we consider these five network management areas, we need to discuss them in the context of the integrated enterprise network, not as a singular function.
If we look at this enterprise challenge from a historical perspective, the network management business of a decade or two ago was dominated by two industries: the mainframe computer vendors and the telecommunications providers. You may have heard of IBM’s NetView, Digital Equipment Corporation’s Enterprise Management Architecture (EMA), and AT&T’s Unified Network Management Architecture (UNMA), that fit the mold of a centralized management system that would allow input from distributed elements such as a minicomputer (in DEC’s case) or a PBX (in AT&T’s case). But as networking architectures became more distributed, network management systems evolved as well. Instead of a centralized system, where all of system performance information was associated with a large system, such as the mainframe or a PBX, distributed models, based upon client/server networking were developed.
With this shift toward distributed computing, the 1990s also brought about the development of two different architectures and protocols for distributed systems management. First, the ITU-T furthered the ISO’s network management efforts, publishing a network management framework defined in ITU-T document X.700. Also defined was a network management protocol that would facilitate communication between the managed elements and the management console, called the Common Management Information Protocol, or CMIP, which is defined in other X.700-series recommendations (of which there are many). Management of telecommunications networks in particular is addressed in an architecture called the Telecommunications Management Network, or TMN, which is defined in the M.3000-series of recommendations, and http://www.itu.int/rec/T-REC-M.3010-200002-I/en). This architecture provides a framework for connecting dissimilar systems and networks, and allows managed elements from different manufacturers to be incorporated into a single management system. This architecture has been most popular with the telcos, likely owing to their allegiance to the ITU-T, and its emphasis on telephony-related research and standards.
The 1990s also brought about the Internet surge, and with that came a friendly rivalry between some of the incumbent standards bodies (such as the ISO and ITU-T) that many considered slow and bureaucratic, and the Internet Engineering Task Force (IETF), that was more likely to be on the cutting edge and therefore quicker to respond to new innovations. Also at that time, the networking community was patiently waiting for computing and communications vendors to embrace the seven-layer OSI model in their products, and after a few years, grew impatient. That environment gave rise to the development of the IETF’s own network management architecture, called the Internet Network Management Framework, and an accompanying protocol, the Simple Network Management Protocol, or SNMP. This network management system embeds simple agents inside networking devices, such as workstations, gateways and servers, which report operational status and exception conditions to the network manager, which provides oversight for the enterprise or a portion of that enterprise. Communication between agents and manager is handled by the SNMP. Further work defined a concept called RMON, short for Remote Monitoring, documented in RFC 2819t , which allow agents on remote networking segments to report back to a centralized manager. Sun Microsystem’s Solstice Enterprise Manager (formerly named SunNet Manager), and Hewlett-Packard’s OpenView were two systems developed during this era that relied heavily on SNMP and RMON technology.
But as you might expect, Microsoft is always up for a good challenge (especially when the names IBM and Sun are part of the discussion), and developed a network management platform of its own called the Systems Management Server. Currently in its 2003 release (see http://www.microsoft.com/smserver/evaluation/default.mspx), this package includes components for software inventory, software update compliance testing, publishing and integrating new applications, assessments of system vulnerability and security, and more.
But no matter how large your enterprise, and the breadth of existing network management systems that you have deployed to support mainframe, WAN, or LAN environments, it’s not likely that a single system can adequately manage your entire networking infrastructure. And the reason is pretty simple – traditional networking management focuses on the systems, making sure that disk storage is adequate, the CPU is not over-utilized, a WAN link has sufficient capacity, or the number of collisions on the Ethernet LAN is not excessive. But the other key area is the domain of the end users, and their applications – which can run the spectrum from a server-resident database to desktop video conferencing. In other words, the performance management, since it directly impacts the productivity of your end users (and occurs in real time), is a crucial factor.
Our next tutorial will drill down a little deeper, and consider some of the real time management challenges that occur at each layer of the OSI Reference Model.
Copyright Acknowledgement: ©2009 DigiNet Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.