A Higher Level Information Tool for Network Administrators:
A Network Service Information Space

Michele Freed, Arthur Hendricks, Robert Sandusky, & Jian Wang

University of Illinois at Urbana-Champaign


(c) 1995 Michele Freed mfreed@uiuc.edu, Arthur Hendricks hendrick@alexia.lis.uiuc.edu, Robert Sandusky sandusky@alexia.lis.uiuc.edu, & Jian Wang wang@alexia.lis.uiuc.edu University of Illinois at Urbana-Champaign
The Katharine Sharp Review ISSN 1083-5261, No. 1, Summer 1995 [http://edfu.lis.uiuc.edu/review/summer1995/freed/freed.html]

    Abstract

    The authors have developed a prototype design for a higher level information system designed for use by telecommunications network administrators. Current technology-specific, or native, network management systems provide a rich set of functions for the specific piece of technology to be managed. This style of management results in well-managed, but isolated, islands of equipment in the network. Integrated network management architectures, such as OSI (Open Systems Interconnection), SNMP (Simple Network Management Protocol), and SNA (Systems Network Architecture), are intended to build bridges between the isolated islands of networking technology. However, neither the integrated management architectures nor the native network management systems provide a means to situate the technology in an organizational context. The authors, drawing upon theory and evidence from the study of organizational memory, organizational learning, and the management of distributed systems, have developed a prototype design of a higher level information tool for network administrators, systems administrators, and other management organization personnel with varying responsibilities, all with differing information needs. This tool situates a set of technologies in an organizational context, thereby improving the manageability of the network by acknowledging the value of actual work practices (Brown and Duguid 1991) and thereby augmenting the capabilities of the managing organization to (1) remember details about the network configuration and their inter-relationships and (2) learn more effectively about the network and its context. The prototype design has been developed using methods associated with object oriented analysis and design. The authors believe that this design model can be applied in other distributed systems environments such as data processing installations, distributed information systems, and public utility networks.

    Introduction

    The Importance of Networks

  1. It is difficult to find an organization in the industrialized world that does not rely upon computing for conducting its core business. Computers and telecommunications networks are everywhere. Many of the organizations involved in computing are also involved in the management and control of complex telecommunications networks. The types of organizations involved in network management include private corporations, governmental bodies, educational institutions, regulated monopolies, and private not-for-profit organizations. The sizes of the organizations that manage networks, expressed in number of employees, can range from dozens to tens of thousands of people. Few organizations exist that do not rely upon at least personal computers linked together by a local area network. The complexity of telecommunications networks presents several challenges for those who manage these networks. The primary challenges are due to the geographic scope of the networks, the wide range of equipment and service types comprising the networks, the continually evolving configuration of the network, and the demands, by the users paying the fees, that the costs of the network be kept low. Other challenges arise from the importance that networks have to those who rely upon them. As a result, telecommunications networks need to be designed for manageability as well as technical capability and performance. In short, networks are everywhere, they are complex, and they cost money.

  2. Fifteen to twenty years ago, users of networks were often collocated with the computers that they used regularly. The computers were usually mainframes or minicomputers with locally attached dumb terminals or dumb terminals connected to the computer over dedicated or very slow dial lines. Relatively few users connected to computers over remote network links (there were relatively few users of computers at that time). Now, computing power and computer users are often not collocated and rely upon networks for interconnection services. Advances in computing and telecommunications, such as faster, more reliable networks and favorable price performance trends, have also been important contributing factors to the increased use of distributed systems. In today's highly distributed environment, the network becomes a prerequisite for computing.

  3. The user's expectations of networks have changed as well. The user of the computing service doesn't really want to know about, or even notice, the network: the user demands network transparency. A transparent network provides a high level of service characterized by fast service and standardized plug-and-play connections. The user also demands very high reliability, which, to the user, means a network that does not randomly disappear. Ideally, the network is also financially transparent: it does not cost too much.

  4. The costs associated with managing networks can be high, especially if recurring costs for communications lines and personnel are involved. Costs for equipment may also be large, resulting in significant depreciation charges. Due to high costs, those paying for the network demand that costs for service be minimized and that the network management organization demonstrate financial accountability.

  5. The network environment is a set of moving targets. Developmental and organizational priorities typically push the technical capabilities and size of the network upward and relegate issues of manageability to lower priority levels. As a result, large complex networks are typically deployed with management systems that are relatively less capable than the networks themselves.

    Network Management Challenges

  6. The administrators of a network must be able to provide a reliable service to their customers. In order to provide a reliable service, the administrators must address a number of threats to reliability, namely the geographic dispersion of the equipment, the wide range of types of equipment in use, and changes to the network and its associated environment. The geographic dispersion of the network is an important issue because it is not possible to walk around and look at the equipment when it is geographically dispersed. The range of types of equipment is also an important issue because no single person can be an expert on all of the networking equipment in use. The introduction of changes to the network is a key threat to reliability because change always increases the risk of malfunction.

  7. The geographic scope of a network can range from a single relatively small site to scores of sites scattered around the world. A single small site is easier to manage than a geographically dispersed site because much of the network management can be done by personal inspection of the equipment. Complexity increases rapidly as the size increases. (Even a network located in a single large building is a complex management challenge). Networks of moderate to large size can be managed effectively only by using sophisticated distributed management systems.

  8. The second challenge is that these complex systems are usually comprised of components and services provided by a large number of sources and each element of the network is usually managed by a separate tool. (The management tool is typically a workstation class computer with network management applications written and provided by the equipment or service vendor. The management tool is typically connected to the network in order to communicate with the equipment and service providers to be managed.) For example, a telecommunications system may be comprised of equipment, software, and services from separate companies for link signaling equipment (e.g., modems and channel service units), link encryption equipment, channel bank equipment, multiplexer equipment, circuits (e.g., different vendors may be used to provide terrestrial, satellite, microwave, radio, and private fiber circuits), diagnostic and test equipment, high precision clocking equipment, patch panels, matrix switches, channel extenders, video codecs, front end processors, host computers, local area network bridge / routers, wiring hubs, packet switches, frame switches, cell switches, cluster controllers, private branch exchange equipment, and telecommunications network management systems. The preceding list is likely to be incomplete, and, in some instances, multiple vendors may supply major percentages of each type of equipment in a single organization. If each type of equipment in use is managed by a separate tool, and each tool requires specific training on its capabilities and user interface, the network administration is faced with problems associated with training and learning the tools themselves. A further barrier to learning is integrating all of these diverse tools into the management of the network itself as a meaningful entity. The operators responsible for monitoring the network and responding to faults in the network can be overloaded with information from the network itself as well as needing to be able to use a number of different management tools (Stallings 1993a).

  9. The third challenge is that these networks do not remain static. Change is motivated by many factors including user requests for new or modified service, the need to replace or upgrade network hardware, or the need to upgrade or reconfigure network software; virtually every component in the network except cables has administration configurable parameters, firmware, software, or some combination of these. This challenge grows in scale as the size, geographic scope, and variety of installed equipment increases. The network users also expect that changes will be transparent to them (i.e. they will not notice that changes have occurred) and that they will be effected quickly, in a day or two.

  10. Unplanned, unmanaged changes carry a higher than necessary probability that outages will result, which affect the customers and have an adverse effect on the network service levels. Planned, controlled change reduces the risk of change. Access to a wide range of accurate information is required to perform adequate planning and to ensure non-disruptive implementation of change. The higher level information tool is designed to provide augmented information about the network and its environment, which can lead to decreased change cycle time and higher probability of successful change implementation.

  11. The final key challenge is associated with costs. Demand for networks is growing everywhere as evidenced by the increases in modem speeds and the use of distributed hyper- and multi-media software. The cost challenge can be described as the need to manage costs so that the rate of growth in network capacity and network usefulness is greater than the rate of growth in terms of cost. Here again, the provision of more accurate information about the network can help improve the cost picture by increasing productivity (through minimization of outage durations, decreased change cycle times, and reducing the time spent seeking and organizing basic information during the planning of changes) and help control the pressure to increase staff size in order to maintain service levels. Better information can also help in managing inventory, which is a challenge in a distributed environment.

    Network Managers Respond to the Challenges

  12. Telecommunications managers consider the manageability of networks to be one of the highest priority issues they face. Many managers cite manageability of networks as more important to them and their organizations than newacquiring newer, faster technology. Despite the identification of these problems, effective comprehensive solutions have been slow in development and acceptance by the network management community (Feldkhun 1989). Sloman (1994) describes the gap:

    Over the past twenty years there has been considerable research and development effort on techniques for building networks and distributed systems - network architectures, protocols, very large scale integrated circuits for communication devices, distributed programming languages, concurrency control mechanisms, and so on. We now have solutions to most of these problems.... We can build complex interconnected networks and the distributed processing systems to run on them but managing such systems is much more of a problem. (emphasis added)

  13. In general, the goal of current efforts is to develop systems that provide integrated network management as illustrated in Figure 2. An underlying assumption is that each type of equipment in the network is to be managed by a separate workstation-based management system. This results in network management center configurations consisting of a large number of terminals (on the order of N * 2, where N is the total of all manageable equipment and service types).

  14. The vendors of equipment and services are providing management systems with increasing levels of functionality. Most systems include support for integrated network management standards. There are three network management architectures that are contending to become the dominant integrated network management architecture: Simple Network Management Protocol (SNMP), Open Systems Interconnection (OSI), also referred to as Common Management Interface Protocol (CMIP)), and IBM's Systems Network Architecture (SNA). These three architectures will be described briefly below.

  15. A number of proprietary network management architectures have been proposed and put into use to some varying degree. AT&T and Digital Equipment Corporation have introduced integrated network management systems that have failed in the marketplace. IBM, on the other hand, has a rich and widely used networking architecture, Systems Network Architecture (SNA), that includes a rich set of management capabilities. However, SNA's network management capabilities are optimized for networks comprised solely of IBM manufactured products. IBM's attempts at integrating the management of other vendors' equipment have not been viewed favorably by the marketplace. SNA management is always present in organizations using IBM mainframes, and therefore it remains an important force both in the market and in terms of technology and standardization. The large installed base of SNA networks presents a formidable challenge to the ascendancy of competing network management schemes.

  16. The OSI standards for networks include a number of recommendations concerning network management. The OSI model breaks the management task into five major functional subcategories (Black 1995). Fault management, the highest priority function, is concerned with the response to and correction of problems in the network. Configuration management is the control of the physical and logical inventories and control of possible reconfigurations in response to outages or changes in demand. Security management is concerned with authorizing usage, privacy of transmission, and authentication of endpoints, of the network as well as controlling access to the network management systems themselves. Accounting management is concerned with the policies and procedures associated with charging users and paying for expenditures. Performance management is concerned with optimizing for cost and planning for change in response to varying demand for service.

  17. The OSI model is a functionally rich, complex architecture for managing networks. CMIP is based upon the principles of object-oriented design. The development and acceptance of CMIP-based products lags behind the usage of proprietary and SNMP-based products due, in large part, to the complexity of its architecture.

  18. The Internet RFCs (Request for Comments) for network management, known as Simple Network Management Protocol (SNMP), provide a subset of the functions described in the OSI model. SNMP is widely used today, but doesn't provide what network managers really want, which is everything in the OSI scheme.

  19. SNMP was chosen by the Internet Activities Board in 1988 as the short-term solution for management of TCP/IP networks. CMIP running over TCP/IP (also known as CMOT) was identified at the same time as the long-term solution. SNMP was envisioned as a quick-and-dirty' practical solution that would be easier to implement than CMIP and yet provide utility to managers of networks. SNMP has been widely accepted and used despite its recognized limitations. The SNMP management information base (MIB) is a database that contains information about the network elements (i.e., elements such as modems and routers) to be managed (Stallings 1993b).

    Network Management: The Management of Representations

  20. Network management organizations rely upon various representations of the network to perform their job effectively. The most basic network representation is the actual physical representation of the network. This representation is comprised of the cables, connectors, multiplexors, modems, channel service units, link encryptors, routers, etc., that comprise the network. This is an extremely important representation because it is the actual physical network, and that is what is used by the management organization's customers to conduct their business. But this representation is of limited use to the management of the network for the following reasons. First, many parts of the network are impossible to see or touch directly because the components are hidden from view. Within a single building, wiring for the network is usually run under floors, above false ceilings, within walls and within conduit and risers. Circuits external to the building usually run underground and are not the property of the network management organization (they are leased from a telephone company). Second, even the visible parts of the network may not lend themselves to direct physical interaction. Routers, for example, may be dispersed around the building in many locations. Wiring closets may also be dispersed around the building. Some equipment may be located in a central location (mulitiplexors and signaling equipment, for example) but the external circuits that connect the site to other sites may terminate on telephone company equipment located elsewhere in the building, often in a basement. Third, most networks are geographically dispersed over relatively wide areas (larger than a single building). A network at an academic campus may be comprised of equipment located in scores of buildings dispersed over several square miles. Even in such a relatively constricted physical location, reliance upon the direct observation of network components is impractical.

    Figure 1 - Network Management With Dedicated Native Management Systems
    In this figure, the LAN manager manages all of the workstations (boxes marked WS) and the LAN media; the router manager manages all of the routers (boxes marked R); the multiplexor manager (box marked MUX Mgr) manages all of the multiplexors (boxes marked MUX); the modem manager (box marked Modem Mgr) manages the dial server and its attached modem banks.

  21. The next highest level representation is that provided by the network management system native to each network component. To illustrate, consider a network comprised of routers, modems, and multiplexors (see Figure 1). The routers would be managed via one stand-alone workstation, the modems by a second stand-alone workstation, and the multiplexors by a third. Each workstation would allow the systems administrator to see a complete view of that portion of the physical network by providing some mix of configuration management, security management, accounting management, performance management, and fault management. This representational model has many advantages. For example, it scales well to large, widely dispersed networks comprised of many types of equipment. Today, much network management is performed at this level of representation. Instead of walking around the physical network, one walks around a room full of workstations that represent particular pieces of the network.

  22. This representational model also has a number of limitations. First, the reliance upon multiple manager workstations fragments the representation of the network into several pieces. At this level the management systems are designed to manage each network component as a separate, stand-alone entity, or layer, within the network. Second, each manager workstation is likely to have different interfaces, commands, command syntax, capabilities, and perhaps run on different system platforms. Third, the level of manageability may be inconsistent across the management workstations because each network component may be managed well or poorly along any of the six categoriewithin any of the five standard functional areas depending largely upon the capabilities designed into the network elements and the associated management system.

  23. Some of the other disadvantages of managing a network at this representation level are the high level of investment in training personnel on all of the different management workstations required, the overhead involved in maintaining all of the different types of workstations and software sets, the lack of interoperability between the management workstations and their applications, and the inconvenience of this configuration. This inconvenience is manifested in troubleshooting situations when the operations personnel must move between two or more systems in order to address a problem because no single system can provide a comprehensive view of the network. For example, the router manager workstation gives a complete view of the routers; the multiplexor manager workstation gives a complete view of the multiplexors. To understand how the routers and multiplexors work together, for example, in order to solve a router / multiplexor connection problem, one must use both of the manager workstations. This inconvenience is also apparent in planning situations when the design engineer must refer to two or more workstations to accurately determine the current configuration of the network. In this representational model, the information regarding the network is fragmented. The key underlying problem is that each of the management workstations has access to only a portion of the information that is vital to total system management.

    Figure 2 - Network Management With Integrated Network Management System (MOM, SNMP, CMIP, NetView/PC [SNA])
    In this figure, the individual management workstations are all managed, in part or in total, via a single system that is defined to operate one level higher than the management workstations.

  24. The next higher level representation is that provided by some sort of integrated network management system (Figure 2). There are two common types of network management integration systems. The first is often referred to as a Manager of Managers (MOM) and the second is a manager based upon an open management protocol suite such as SNMP or CMIP. MOMs are typically used to manage sets of network equipment that either do not implement open management standards, such as SNMP or CMIP, or implement these standards in a weak or cumbersome manner. A MOM usually focuses only upon the fault management function. The typical MOM implementation consists of alarms feeding into the MOM from some native manager of a portion of the network (such as the modems or multiplexors) as a stream of text data. The MOM has simple alarm parsers built into it to allow translation of the native alarms from a series of native management systems into a single common format. The systems administrators then review and act upon the alarms presented in this common format. (IBM's SNA product, NetView/PC, is based on the MOM model.) While this sounds quite basic, it does provide assistance in managing complex networks comprised of at least four or more important elements. MOMs are not designed to perform any of the other network management subfunctions (security, configuration, accounting, or performance management). Their command interface back through the native management systems is usually via text entry, or command line, rather than the native, more powerful graphical user interface. Standards-based integrated management systems, like SNMP or CMIP-based systems, seek to provide a richer range of integration. The standards-based approaches make use of well-defined MIBs which define the network elements to be managed. CMIP managers are designed to take advantage of the objects (data and methods) defined in the CMIP MIBs.

  25. The advantages to integrated network management approaches include progressing from managing a network by walking around a roomful of workstations to being able to manage the network from a single screen; moving from a plethora of user interfaces and command sets to a single interface and consistent command set; realizing reductions in training and learning time due to the availability of a common user interface. Disadvantages include the limited functionality of the most widely available integration systems, MOMs and SNMP managers, which compel the network management organizations to retain many of the native management systems in order to provide comprehensive management of the network.

  26. All of the above representations focus on specific characteristics of the various parts of the network. In doing this, they provide great value to the organizations managing the networks. Their great failing is not situating the network in the larger organizational context. Network management organizations acquire and manage a set of equipment and services for specific purposes. These purposes relate to the business of the organization (the reasons the network was built), the kinds of services and service levels supported by the network administration (how important the network is to the organization), the particular assortment of equipment installed in the network (the interrelations and interdependencies of the equipment and services comprising the network), and the kinds of equipment attached to the network (the interrelations and interdependencies of the external equipment to the behavior of the network).

  27. The efforts from the vendors and standards communities are useful, but the organization managing the network has a very different view of each vendor's equipment. This organization view could be described as a higher level view. Each vendor's equipment is only a part of a larger network that has a presumably important role to play in the organization. The organization managing the network needs to create and maintain a body of information that describes the inter-relationships between each vendor's equipment from physical and logical points of view. To further complicate the issue, multiple physical and logical points of view may need to be maintained in order to make this vast store of information useful to the organization. For example, it is likely that the organization primarily needs customized views of vendor equipment sorted' by vendor. This view can be useful in planning for and executing equipment or software upgrades. A second required variation might provide separate views of each of the sites comprising the network. This view can be useful in diagnosing problems at a particular site or in planning for physical changes at that site. Third, various logical views, which cut across vendor and geographic boundaries, may be required in order to understand all of the parts of the network that are related to a particular service provided by the organization. In this case, it may be useful to identify all of the users of a particular service who may or may not be present at all sites, and to see', through a logical view, how they are similar and how they differ. Finally, different parts of the management organization may require different views of the network. Financial control personnel may want accurate details of equipment installations for accounting and auditing purposes; engineers and service planners may need up-to-date configuration data in order to plan for incremental or major changes; the operators controlling the system in real-time need to understand the scope and impact of service outages and have views that show how a failure at a site can affect other usage of the network. These varieties of usage illustrate the need to easily reconfigure complex data from multiple sources into new shapes based upon needs and usage.

  28. In addition, the organization managing the system is likely to require procedures for performing maintenance activities at each site within the network, and each site is typically comprised of equipment from multiple sources. The standard procedures for each site must then integrate the relevant information for each type of equipment to ensure that maintenance steps are executed in the proper sequence, and with the appropriate controls, to ensure success of the operation and to minimize adverse impacts on the users of the network.

    Figure 3 - Network Management With Integrated Network Management System and a Higher Level Information Tool (CNIS)
    In this figure, the higher level information tool is pictured augmenting the capability of the integrated network management system.

  29. The next level of representation (Figure 3) should provide methods for organizing the detailed information contained in the lower level representations of the network into useful higher level groupings. These groupings and associations of information should provide a situational context for the management of the network, enabling the network administration to provide a higher level of service more efficiently. If properly designed and constructed, this next level should also provide representations tailored to the needs of the various network management subfunctions, such as configuration management, security management, accounting management, performance management, and fault management. The higher level view should also be dynamic so that the representational model at the higher, organizational level can be modified in response to changes in configurations, policies, organizational structures, and environmental influences.

  30. There are several threads of research influencing this exploratory project. First is the current, expanding body of research in network and distributed systems management (which has been discussed at length above); second is research in organizational memory; third is research in organizational learning.

  31. Past research in organizational memory and organization learning suggest the potential value of a higher level information system to a network management organization.

  32. Walsh and Ungson (1991) provide a theoretical basis for the analysis of organizational memory in terms of its structure and issues of information acquisition, retention, and retrieval. One of the basic motivations for construction of a higher level information tool is to provide effective memory support for the organization. In large networks, information about the network is diffused throughout the native management systems in use and in other forms of information, such as tables, drawings, and procedures that are often produced independently by various members of the organization in response to specific, and sometimes ad hoc, requirements. Walsh and Ungson's work is helpful in indentifying the structural characteristics of an organizational memory system as well as identifying the related acquisition, retention, and retrieval issues.

  33. It is desirable to create an information tool that can encourage an organic, spontaneous form of learning situated in and guided by the organization's work practices (Brown and Duguid 1991). Application of the tool in this manner implies that the tool can support multiple simultaneous representation models, and that these models can be changed in response to new requirements, new ideas for definition of models, and in response to changing organizational or environmental conditions. Allowing multiple simultaneous models of representation demands a willingness on the part of the management hierarchy of the organization to tolerate "... incongruent versions of the organization in what is nominally one ..." organization (Orr 1993). Such tolerance is implicit acknowledgment of the value of the work practices of those directly involved with the work of managing the network (Brown and Duguid 1991).

  34. But how can an organization use network management information to learn? One base of information with likely value for learning is the trouble ticket system which exists in virtually all network management organizations. The trouble ticket system is one of the most basic, highly utilized subsystems within the organization. The trouble ticket system contains relatively rich descriptions of all problem occurrences, the organization's responses, and subsequent customer reaction. Viewed in retrospect, the trouble ticket system contains a history of the actions, culture, and norms of the management organization in terms of its self-perception and in terms of the reactions of others to that self-perception.

  35. The trouble ticket system is a potential source of organizational memories. Network managers express desires to use this information to avoid repeating errors and as a source of historical data to enable proactive network management. In practice, trouble ticket systems are usually not designed in a manner to allow effective use of the historical record (Sandusky 1995). Potential exists, however, to enable the retrieval of these memories and apply them more effectively to the challenges of the present. For example, it could be beneficial to capture and present the historical problems in terms of war stories', whose power in diagnostic situations has been demonstrated by Orr (1987). The value of the trouble ticket database might be enhanced by including more information in the record itself; by applying automatic classification processes to the database; and by utilizing real information retrieval techniques. (Many trouble ticket systems rely upon user-generated keywords occurring in specific database fields rather than effective full text searching.)

    Campus Network Information System (CNIS)

  36. The goal of this project was to design a relatively simple prototype with some of the characteristics alluded to in the discussion above. Key goals in this design included making use of information already existing within the network and the organization, building upon and interoperating with existing, recognized standards, providing flexibility to enable development of customized and specific information for a wide variety of users (ranging from network operators to network planning engineers to budget analysts to senior managers), and providing high utility while shielding the users of the information from the details of CNIS and the network.

  37. For the purpose of this exploratory effort, the authors did not conduct a comprehensive user requirements study. Instead, the authors relied upon their experience working in network management organizations (over a dozen years combined experience). The University of Illinois at Urbana-Champaign data network's physical and administrative structure was used to provide a specific organizational setting for the design.

    CNIS Data Modeling and Schema Building

  38. This system was designed using object-oriented methods to model the data. We chose an object-oriented design approach because these methods "... more accurately reflect the logical essence of real-world applications than do record-based representations" (Hansen and Hansen 1992). Object-oriented methods also transfer some of the semantic meaning of the part of the world being modeled into the model itself. This design approach meshes well with the desire to situate the information system into an organizational context by encouraging thinking in terms of the organization, the organization's vocabulary, and the organization's work practices. The object-oriented model enabled us to represent the logical essence of UIUCnet as a system including physical components, organizations, people, and their situated, social interactions.

  39. In the next phase of the design, we transformed the object-oriented data model using the normalization processes based upon Codd's seminal work (Codd 1970). This work has been extended to allow the normalization of object-oriented data models into a relational model that maps directly to relational database management systems (Hansen and Hansen 1992). The transformation of an object-oriented model into a relational model will work once an accurate (in terms of its representation of the real world) object-oriented model exists.

  40. This schema represent only a subset of the types of information that would be needed to fully describe a complex network. In particular, most of the entity attributes have been left out in order to provide a clearer, general view of the schema. (See Figures 4, 5, and 6)

    Figure 4 - CNIS Database Schema, Part 1

  41. Our design includes some features that are not common in database systems that work only with textual information. For example, we included specialized fields that are pointers to other sorts of electronic documents, such as drawings of network configurations, or procedural documents. Another useful type of document to include in the model would be a trouble ticket archive for tracking and storing active and resolved network problems. The archive of trouble tickets would then be available as a further option for users of CNIS.

  42. We recognized that the data model did not include all of the information that would be useful in operating and administering a network. A great deal of useful information is contained in the network components themselves, in the form of SNMP MIBs (Simple Network Management Protocol Management Information Bases). This information represents a second important set of dynamic information that is primarily useful to network administrators and network operators addressing real time problems in the network. The SNMP MIB and TCP/IP command set is also an example of basing the CNIS design on existing standards. The CNIS design could be extended to include support for CMIP data in the future.

    Figure 5 - CNIS Database Schema, Part 2

  43. Much of the data described by the schema exists already. For example, the diagrams of network closets exist in the form of machine readable line drawings. An historical database of trouble tickets exists within the University's network management organization; the SNMP MIBs exist in the operating network.

    CNIS User Classes

  44. A major design goal for CNIS was to be able to satisfy the information needs of a variety of people performing a variety of roles in the management of the network. In order to verify that the database schema would support this requirement, we identified various types of typical users within the University by means of their ranges of interests in the data from and about the network. We refer to these as the CNIS User Classes. These classes do not exhaustively cover all of the types of users with a legitimate need for access to information about the network. These particular classes were chosen because they represent a variety of information needs, ranging from an emphasis on fault management to an emphasis on financial and inventory management. The authors established the following five user classes:

    Network Administration: The Network Administrators typically maintain and support particular sub-networks within the UIUCNet domain. Their information needs are primarily at the workstation level and include concerns about workstation status and connectivity to other sub-networks.

    Network Operations Center: The Network Operations Center operators monitor the connections between all of the UIUCNet sub-networks and the campus backbone, and all of the connections from the campus backbone to the rest of the world.

    Network Design Engineering: The Network Design Engineer needs access to information about the current network configuration to plan for new installations or modifications to existing equipment. Users here are also interested in performance issues. They may also be involved in resolving some of the more difficult network problems.

    Departmental Administration: Departmental Administrators are usually non-technical budget analysts or managers. They are concerned with tracking assets, depreciation, and costs associated with the network at the academic department level.

    College Administration: College Administrators are concerned with similar issues as Departmental Administrators, but at an aggregate level. The College Administrators also have a long range planning horizon and are responsible for much of the financial and strategic planning that affects the network.

    Figure 6 - CNIS Database Schema, Part 3

  45. Table 1 presents a summary of the CNIS user classes and their primary information sources. The information sources are described in terms of the five network management subfunctions (fault, configuration, performance, accounting, and security management).

    Table 1 - User Classes and Network Management Functional Areas of Interest

    CNIS Applet (Application) Design

  46. In examining the varying needs of the five categories of users, it was decided that there needed to be a combination of archival as well as real-time information about the status of the Internet. Current Relational Databases (RDB) are excellent for accessing historical information and with the inclusion of a SQL language, almost infinite queries are available. Technology is moving towards the integration of electronic mail into current RDB's and it is hoped that email will be included within RDB in the future. This will enable access to historical information on trouble ticket status and resolution. Access to real-time information about the status of the Internet is not possible with current RDB's but rather through accessing current SNMP information in the form of scripts or the traditional TCP/IP commands built into the UNIX environment.

  47. SQL queries and the use of scripts are generally beyond the technical skills of most of the users of CNIS. In order to simplify the system, applets (small programs) were designed. Each category of user will have a windows-based view into the system that includes built-in applets. Due to the underlying design of the system applets can be custom designed for the user with relative ease. With this design we found that CNIS provides the flexibility needed to satisfy the five CNIS user classes.

  48. Applets are small programs with two primary functions. The first function is access (update and retrieval) of archival data from the RDB. These are essentially pre-written queries to access fields in the RDB. The second type of function is access of real-time information regarding the status of the network using TCP/IP get commands. These commands access SNMP information from the MIBs residing in the managed elements themselves.

  49. After the CNIS schema and user classes were defined, and we had decided upon using SNMP MIB data as well, we turned our attention to the design of application programs that would utilize both the information in the relational database and the real-time SNMP data to meet the information needs of the various classes of users. During the applet design phase, we defined seventeen useful functions for various levels in the user classification scheme. Table 2 shows the list of candidate applets, their general purpose, and the class of user who would most likely use that particular applet. Note that variations on each applet could be easily created to provide specific functionality to individual classes of users. Many other applets could be designed based upon the CNIS data model using the RDBMS SQL and the SNMP data from the network. Applets that update the RDB would also be designed.

    Table 2 - CNIS Applets

    CNIS Interface

  50. Each category of user will have a different view into CNIS, depending on the type of applets they need. The view is built by using a windowing based system (Microsoft Windows, Macintosh, or X/Windows).

  51. Figures 7 and 8 show the layout of the CNIS user interface. The CNIS user is presented with a standard screen that provides buttons on the left-hand side which are used to invoke the applets available in the user's view. An applet status window at the top shows the name of the applet chosen. The user enters input values in the text window at the bottom of the window. The output is presented in a large, scrolling window.

    Figure 7 - Applet ARPTable
    Figure 7 shows the proposed design for the ARPTable applet. This applet uses TCP/IP commands to the SNMP MIBs to gather and display the relationships between the IP addresses and the network physical addresses.

    Figure 8 - Applet CurrDNS
    Figure 8 shows the proposed design for the CurrDNS applet. This applet provides the current domain name server information for a particular sub-network.

    Conclusion

  52. The design of the Campus Network Information System is based upon recent research and practice in distributed systems management and recent research results in organizational memory and organizational learning. The authors have made a case for the need for and utility of an information tool for network administrators that situates the technology and the information that describes that technology in a specific organizational context. This exploratory prototype design provides utility beyond what can be found in commercial off-the-shelf network management products. The CNIS design should scale well to wide-spread use on the Internet because Internet network management, at least at the detailed level considered here, occurs primarily at the domain level. It would be possible for many Internet domains to run their own, domain-specific versions of CNIS.

  53. This prototype design also points out several areas for future research. First, research should be done to establish more precisely the level of need among management organizations for this type of tool. In particular, it would be useful to determine what are the break points for such parameters as organization size, geographic scope, etc., beyond which a higher level information tool makes sense. Second, an in-depth user requirements study should be conducted within an organization that is managing a complex network in order to begin to build the object classes needed by a working system based on the work presented here. Third, a working prototype of the system described here should be built in order to conduct a formal evaluation of the capabilities and shortcomings of the current design assumptions, information technology, and methods. Fourth, identify existing organizations that are working to effectively capture the organizational specific information described above using similar or other methods and perform an evaluative study of that organization and its application of technology to these problems. Fifth, survey organizations involved in distributed management to understand the usage and potential for more advanced trouble ticket systems that can function as organizational memory systems. Sixth, look at organizations in related businesses, such as data processing management, public utility management, and distributed systems management, to see if the arguments and ideas presented here in fact apply to other settings. The authors believe that the proposed design will be applicable in a variety of problem domains.


    References

    Black, Uyless. 1995. Network management standards: SNMP, CMIP, TMN, MIBs, and Object Libraries. New York: McGraw Hill.

    Brown, J. S., and Duguid, P. 1991. Organizational learning and communities-of-practice: Toward a unified view of working, learning, and innovation. Organization Science 2(1).

    Codd, E. 1970. A relational model for large shared data banks. Communications of the ACM 13(6).

    Feldkhun, L. 1989. Integrated network management systems: A global perspective on the issue. In Proceedings: First International Symposium on Integrated Network Management, edited by B. Meandzija and J. Westcott, 279-301. New York: North-Holland.

    Hansen, G. W., and J. V. Hansen. 1992. Database management and design. Englewood Cliffs, NJ: Prentice Hall.

    Orr, J. 1987. Talking about machines: Social aspects of expertise. Report for the Intelligent Systems Laboratory. Palo Alto, CA: Xerox Palo Alto Research Center.

    Orr, J. 1993. Ethnography and organizational learning: in pursuit of learning at work. unpublished paper.

    Sandusky, R. 1995. The trouble ticket system as a memory and learning system. unpublished paper.

    Sloman, M., ed. 1994. Network and distributed systems management. Wokingham, England: Addison-Wesley.

    Stallings, W., ed. 1993a. Network Management. Los Alamitos, CA: IEEE Computer Society Press, 1993a, pp. 1-11.

    Stallings, W. 1993b. SNMP, SNMPv2, and CMIP: The practical guide to network-management standards. Reading, MA: Addison-Wesley.

    Walsh, James P., and Gerardo Rivera Ungson. 1991. Organizational memory. Academy of Management Review 16(1).