Managing the communications resources of a computer network is critical to the successful operation of the network. A network manage- ment system is ...
A Network Management Language for OS1 Networks Unnikrishnan S. Wanier* Unisys Corporation, Santa Monica, CA 90406 Peter A. Relan Hewlett-Packard, Cupertino, CA 95014 Oma Berry IBM Science and Technology, Technion City, Haifa 32C00, Israel Joseph Bannister UCLA and The Aerospace Corporation, El Segundo, CA 90245 *Authors
are listed in reverse alphabetical
ABSTRACT
The general problem of monitoring distributed systems has been studied by others. The Jade system WGEIS] incorporates monitoring primitives that allow one to observe interactions between Jade processes. This capability is provided primarily for the debugging of distributed applications and must be specified at compile time. Moreover, the mechanisms available to the user for specifying monitor operations are limited in that the events being monitored must be described in a static manner. This constraint would be unacceptable in a network management system, which requires very dynamic monitoring and control capabilities. The work of Snodgrass [SNOD88] is a thoughtful approach to monitoring complex systems. Sondgrass proposes a comprehensive design for monitoring based on embedding software sensors in the system under observation and activating them by means of a relational query language that has been enhanced to capture the notion of time. Although our approach to managing a network has similarities to Snodgrass’s work (both designs are based on the premise that monitored information may be modeled as a collection of relations incorporating historical attributes), our design proceeds under different assumptions and constraints. The agent software in a network management system typically will be wriuen by a number of independent organizations or enterprises. Thus it is unreasonable to expect the agents to implement the sensor design called for in Snodgmss’s monitoring architecture. A basic assumption in network management is conformance to a set of standards governing the exchange of management information. Such standards constrain the design of the network manager in a way that appears to be incompatible with Snodgrass’s monitoring architecture. We find also that a network management system requires more powerful temporal control than is provided by Snodgrass’s query language.
Managing the communications resources of a computer network is critical to the successful operation of the network. A network management system is expected to manage a large collection of network nodes remotely. There is an obvious need for sophisticated network management application software in this process. Previous network management systems have been designed without particular regard for the application programmer’s interface requirements. We propose that such software be written in a specialized Network Management Language (NML) that provides the programmer with high-level abstractions rather than low-level communication primitives. The NML would help reduce development costs, promote portability and accommodate multiple standards. We propose an NML which is an extension to the SQL database standard. An implementation of the NML within the Open Systems Interconnection (0%) systems management framework is discussed, and examples of its functionality and expressiveness are presented. 1. Introduction The size and complexity of computer communication networks have been growing steadily. Along with this growth has come the recognition of network management as an important aspect of computer networking. Network management is the process of monitoring, analyzing, and controlling the communications resources of the network in order to ensure the efficient and error-free operation of network functions [TERP87]. A goal of network management is to monitor, record, and control the dynamically evolving global network state. Although network management has been largely a manual activity, computer-assisted network management is beginning to produce more automated, inteIligent, and responsive tools and techniques for management mST85, FER188, BRID86].
The issue of system control is as crucial to network management as system monitoring, yet it has been largely ignored. The NML will provide appropriate mechanisms for both monitoring and con&o1 of the state of the network. The paper will in Section 2 describe the architecture and protocols of a typical network management system. Section 3 will analyze the requirements of an NML. Section 4 presents an NML, describing both its syntax and semantics. Section 5 discusses a particular implementation of the NML. Section 6 will show a number of examples of management functions specified in Nh%L.
Network management is the responsibility of a staff dedicated to maintaining the services of the network. The network administrator is usually a computer or telecommunications professional who will use computer-based tools to carry out her or his management duties. These tools will be built by a network management application programmer who requires an appropriate language interface with which to program applications. It is the purpose of this paper to point out the importance of such a language interface, which we call the Network Management Language (NML). The need for human interfaces for network administrators or network applications programmers is well understood. Vendors currently provide command languages or shells for network management [DEC86, SYTE83]. Many of these languages are useful from the network administrator’s vantage point, but not well suited for programming network management applications.
2. Network Management Framework 2.1 Architecture The network is assumed to consist of end systems (e.g. user nodes) and intermediate systems (e.g. routers, bridges) that communicate according to a set of common protocols. These systems may be interconnected by local and wide area networks. The network may have one or more Nenvork Managers (NMs), which are end systems from which management functions are performed. Thus the NM is a focal point for the collection and processing of management information. The use of multiple NMs generally depends upon the magnitude of the management task.
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/ or specific permission.
o
1988 ACM O-8979 l-279-9/88/008/0098
order
The NM is thought of as a set of Applicadon Units (AUs) that provide an interface between the (human) network administrator and the network management system. For instance, an AU might be an application that graphically displays the network topological map. These AUs include NML commands which are interpreted by the NML interpreter. NML
$1 SO
98
NML is immediately apparent. This argument also applies to MIXPs that are not fully mature (like CMIP). By writing applications in a wellspeciticd language like NML, one can insulate oneself from the vagaries and vicissitudes of the standards-making process.
commands are translated by the intcrprcter into primitive commands understood by the communication system. The interrelationship of the AUs, NML interpreter, and communication system is illustrated in Figure 1. The communication system allows nodes to exchange information by means of specific protocols. In order to communicate management information and commands to managed nodes, the NM uses a Management Information Exchange Protocol (MIXP). The MIXP uses, in turn, other protocols to transmit and receive data, e.g. remote operations protocol, presentation protocol, etc. Examples of MlXPs abound, including the Organization for International Standardization’s (ISO) Common Management Information Protocol (CMIP) [OSI87bl, the High-Level Entity Management Protocol [PARTSS], the Simple Gateway Monitoring Protocol [CDFS88], and numerous other proprietary protocols [BERN83. BRID86, HIND831.
Promofe standardization. It may be mutually beneEcial for a number of organizations to adopt a common NML interface. The major benefits would be reusability and transportability of application software. This may also encourage the adoption of widely accepted programming conventions for network management applications.
The disadvantage of NML is that it inserts another layer (the NML interpreter) into an already heavily layered system. Preliminary analysis leads us to believe that the performance penalty will not be substantial. We believe that the penahy of using an NML will be offset by the advantages outlined earlier. The decision to employ an NML is clearly a design tradeoff that must be made by the system designer. Two of the objectives of our research are to explore the impact of NML on system performance and to study techniques for providing acceptable levels of performance.
2.2 Rationale for NML Referring to Figure 1, we observe that there is no absolute need for an NML intcrpretcr. AU programs could be written to provide a direct interface to the MIXP (which is part of the communication system). In fact, such a direct interface is desirable in certain situations. A major thesis of this paper is that a well-dcsigncd network management system will offer the network management application programmer a view of the network that sits at a significantly higher lcvcl than the MIXP.
3. NML Requirements and Principles of Operation The NML will perform certain high-level operations at the network management application programmer’s request. The requirements for NML are based on what we feel are proper abstractions to export to the network management application programmer, given that such a programmer would wish to perform a number of well-known network management applications such as down-line load, network initialization, and the setting and getting of attributes.
Vendors of communication hardware and software will make substantial investment in delivering network management products. Such a product offering entails modifying managed nodes to support agen? functions (which act at the managed node on behalf of the NM) and incorporating Layer Management Entities (LMEs) for local node management. In addition to the effort of putting into place all these network management hooks and underlying communication services. there will be high recurring and nonrecurring engineering costs associated with building network management applications incorporating sophisticated graphics, database and expert system packages. Vendors will certainly wish to protect their investments in network managcmcnt applications. We believe that an NML will allow network management applications to be constructed in an economical way.
The principal need of the Network Manager is to be able to communicate with, and manage, the devices in the network. This requires some means in the NML system to be able to issue management commands which will identify and operate on a network resource or a set of resources. Another important need is for the Network Manager to access data in the Mananement Information Base (MIB). The MIB is an abstraction that represents the state of the network’s many managed objects. The MIB is central to network management, and the network administrator must have capabilities to review the data and perform complex manipulations on it. Thus there should be a way in the NML to be able to issue MIB manipulation commands.
NML is seen as a canonical interface between the network managcmcnt application programmer and the MIXP. The following advantages are to bc derived from the USCof NML. Reduce the semantic gap between MIXP
and applicarion
pro-
grammer. The MIXP is a low-level communication protocol from the application programmer’s point of view’. The primitives provided by an MIXP are inappropriate for use by a network management application programmer. Higher-level primitives arc necdcd for writing AUs. For example, CMIP offers service elements like M-confirmedget, M-confirmed-set, M-event-report and M-action. Such primitives have a very elementary model of opemtion, calling for the immediate tiring of the underlying state machine, requiring long lists of parameters, and applying only to single entities of tbc network, to name but a few. Thus it is reasonable to expect an interface with more expressive power for the network management application programmer.
A number of explicit requirements CarNML may be derived. In analyzing the requirements for NML we have attempted to make choices that do not restrict the pohcies that a network management system would wish to enforce. Our point of departure is to view network management as the manipulation of the MIB where the MIB is understood to be a database that somehow reflects the past, present, and future states of the network. Almost all control and monitoring functions will be then directed through the MIB. The MIB is a logical concept and its design and implementation are outside the scope of this paper. NML will include linguistic support for the following requirements. MIB-oriented network mangement. The MIB provides a comprehensive state description of the network. Implicit in a MIBoriented paradigm of network management is the assumption that the MIB is a temporal database that incorporates time as a primitive attribute of any record. Most, if not all, NML mechanisms should therefore be based upon the querying and modifying of the MIB as the fundamental model for monitoring and controlling all network resources.
As notcd previously. several MIXPs are currently in USC.Vendors may wish to support proprictary protocols and make smooth transitions to internationally recognized standards. Changing AUs whenever a new MIXP is used could be costly. If one were to build m different AUs on top of n diffcrcnt MIXPs, then m x n implementations would be required for full connectivity. If there is a single canonical NML, then only n different NML interprctcrs are necessary. As m is typically huge and n is small in a given network, the advantage of Cope with multiple MfXPs.
Symbolic naming. The network administrator will refer to network resources and entities by symbolic names. There will be a need to address groups of resources via a single name. There may also be a need to call objects by nicknames or aliases. Symbolic naming is therefore
‘This is true even though such protocols, e.g. CMIP, are considered upper layer protocols in the OS1Reference Model.
99
essential in the NML.
4.2 Syntax
Grouping of operands. Management of a large network entails applying perhaps several distinct operations to each end or intermediate system. It is unreasonable to ask that the network management application programmer perform each of these individual operations. Therefore the NML should enable the network management application programmer to perform operations on groups of devices.
Rather than define an entirely new language for network management, it was decided that the NML would be an extension of some existing command language. SQL was chosen, since it has been accepted widely in industry, and has been standardized by the American National Standards Institute [ANSI86]. In addition, SQL is also a Military Standard. Thus the network management database could be considered an SQL standard database.
Procedural mechanisms. The ability to specify modules that irnplement a given function is fundamental to nearly every higher level language. Invoking procedures or macros by symbolic reference aids in the development and sharing of programs. The network management application programmer will certainly benefit from such a facility.
The NML imports all the fcaturcs of SQL. In particular, the Schema Definition Language and the Module Language are identical to those of SQL, and will not be treated here. However, we note that user needs for creation of schemas, redefinitions of schemas, creation of modules, can be met via these Languages. The Data Manipulation Language (DML) is extended to include a network management specific concept of time (or versions). Here we concentrate on the NML extensions to the SQL DML, and will assume regular SQL functions to be given.
Temporal control. The NML must allow operations to be specified as occurring at specilic time points. This requires being able to schedule operations with a great deal of control. The desired mechanisms include deferring operations to later times, spccilying repeated operations with a given periodicity, or in general laying out any reasonable schedule for a sequence of operations.
It was decided that, in the network management context, three types of DML extensions made sense in accessing versions of the SQL database. The AT clause supports tbe notion of data having a specific time context (roughly, from a specific version of the data items). The FOR clause supports the need for periodic access of data over a certain duration (i.e. from consequent versions of the si~mc data items). The EVERY clause supports the need for a specific granularity for the FOR clause, (i.e. periodic, perhaps non-consequent versions would be needed). These clauses will be illusuated in the sub-section on semantics.
Error handling. Devices frequently fail and data transmission is inherently unreliable. These errors cause problems for network management and must therefore be detected and possibly counteracted. The logging of errors and anomalous conditions should be provided by the NML.
4. NML definition 4.1 The NML Interface Network management is the manipulation of the global network state. One possible representation of the global network state is as a collection of tables in a relational durabase. Thus the state variable bf the network would be the conceptual schema, which would be fairly static over time. The advantage of this reprcscntation of the state is that wellunderstood relational algebra [ASTR86] can bc used for accessing state variables.
4.2.1 NML statements and procedures
The syntax for the NML given here is an extension of the SQL syntax. >From the ANSI SQL standard definition [ANSI86]. recall that the SQL statement is defined as: ::= 1 1 1 Jerc.)
This can be extended to provide the generic NML statement:
Obviously, this global network state is not static, but changes over time. Hence the network management system has to provide the means of storing the history of network state changes somewhere in the system. It should also provide the means of manipulating this historical data. One method of such organization is by postulating versions of the information in the schema. There are differing concepts of versions in the literature [CHOU86, KIM87, DADA84]. The concept we use here is that at the time that a single data item in the database changes, a new version of that item has become available from that particular point of time. We assume a gle bal sense of time, and will not deal with issues of global clock synchronization here (although, see [LAMP781 for example). One way of keeping time is to introduce, with every data column in the schema, a corresponding time column. However, there arc more sophisticated techniques available in database systems incorporating versions [KIM87].
cNML statement> :I= FORCE [AT ][FOR
]
The Appendix provides a fuller defmition of the NML syntax. In keeping with the SQL standard, we now dcline:
::= PROCEDURE ...; CNML stalement> ;
This allows us to use definitions of NML proccdwes, NML modules and calling conventions identical to the respective SQL syntax and semantics for these functions. 4.2.2 Embedded NML In parallel with embedded SQL, we can define an embedded NML that will let NML be invoked from standard programming languages. Although embedded SQL is not strictly part of the ANSI standard, the Annexes to the standard give a complete treatment of embedded SQL for some standard programming languages. The uanslation of this treatment to NML is obvious. For example, the new becomes:
Thus the interface presented to the applications by the NML is a versioned relational darabase. The task of the NML, then, is to accept commands in a versioned relational query language, interpret these commands into specific MIXP function invocations, collate the results of these invocations, and translate them into relational terms before providing these results to the user processes.
::= { 1 1cNML statement>] l*replacing ][FOR
The Management Information Base (Ml3) [OSI87a] stores data that reflects the global state of the network, as well as some of its recorded history. The MIB is defined to consist of all attributes of all protocol entities within the network. These attributes include information essential to the correct and efficient operation of the entity (e.g. timer values, service access point identifiers, supported options, and other protocol parameters) as well as statistics related to the historical state of the entity (e.g. packet counts, error logs, timing data, CIC.). The MIB has no a priori structure, but for our purposes it will be viewed as a collection of relations indexed by end and intermediate system identification keys.
]
While the system described above collectively provides adeauate functionality to the Network Manager to perform management opera&on% it is clear that the management function is distributed between several entitics, interfaces are too low-level, and there is no single abstract view of the network provided to the Network Manager.
4.3.3 Grouping of operands and operalions
As in SQL, the is made available for the purpose of grouping NML operations through programming language control stmctures into powerful procedures. The grouping of operands is available from SQL semantics, through the use of cursors and tables.
Figure 3 shows the relationship of the NML architecture and its components (the NML System, or NMLS) to the overall IS0 Network Management architecture.
101
The NMLS will generally bc present at manager nodes only. If the system allows the partitioning of the network management functions between multiple managers, or hierarchical managers, more than one system may behave as manager as well as agent. This type of system (a manager) would be responsible for management of some “pure agents”, and simultaneously bc acccssiblc for qucrics by other managers. NMLS would be present in this type of a sub-manager.
5.2.4 The Time-Schema Translator The Time-Schema Translator (TST) offers a timed database view of all historical data in the MMIB to the Kernel. The TST decomposes each NML command with a into several sub-commands using only the AT clause. Each such command is treated separately, although the TST will, on completion of all the sub-commands, collate all subresponses into a single response before returning back to the Kernel. If any sub-command is destined for a future time, (based on the value in the AT clause), it is sent to the Kernel’s background timer daemon. The TST provides the mechanisms for partitioning the MMIB into versioned tables. It is important to remember that the MMIB simply provides a relational model in which time is an attribute, just like all other data items. It is the TST which provides the special handling of the time attribute as versions in the NML system. It is possible that the MMIB may allow versioning, in which case some of the functionality of the TST will move to the MMIB. The TST translates NML commands with the AT clause into WHERE clauses as SQL database qucrics for the appropriate time-stamped data.
NMLS is a user of SMAP and MIB services at the application layer, and a provider of a high level command service to network management applications. In the OS1 architccturc, NML is viewed as the application entity, in conjunction with SMAP and the MIS. Since NML is viewed as an OS1 application, it is entirely feasible that other applications that provide interfaces to alternative MIXPs will coexist with the NMLS. In fact, NML interfaces to MIXP’s other than CMIP are also envisioned, since the NML definition is indcpcndcnt of the MIXP interface. Similarly, the issue of Proxy Management, whereby a Proxy Manager acts as an agent for a collection of nodes that do not talk CMIP, is also possible with our architecture of NML. For example, a Proxy Manager can be constructed from an implementation of NML with two MIXP interfaces, one interfacing to CMIP and the other to the Intcrnct standard Simple Network Management Protocol (SNMP). Such a manager will be able to manage SGMP devices on behalf of another manager that has only a CMIP interface.
5.2.5 The SMAP Control Unit The SMAP Control Unit (SW) receives NML commands from the Kernel as well as M-cvcnt-rcpott commands and M-action commands from the SMAP. Only NML commands which specify remote tables are sent to the SCU. The SCU maps NhJL commands into appropriate sels of SMAP primitives. If an NML command is for accessing a table at a remote agent, an appropriate Get command is created. If the command is for accessing data from a remote manager, an appropriate M-action command, with action parameter as M-get, is created. One of the examples below gives details of how remote manager access is accomplished.
The interface of NMLS to the Manager resident part of the MIB (MMIB),is simply the SQL interface. Thus all commands coming into MMIB from the NLMS will be in SQL, and SQL responsesarc expected in rctum. We assume that SMAP provides functions like M_get. M-set, M-action, and M-event-report for managcmcnt operations. 5.2 NML Components
SM-event-reports arriving from the SMAP may request updates of the MMIB, i.e. they are commands from agent SMAPs. Such messages go through an involved translation. The “managed object list” has to be translated into a database field name via NMLS control tables. The “managed object id” has to be translated into a database table name via Directory Services and/or NMLS control tables. The end result of the translation is a command in NML syntax that is forwarded to the Kernel.
The internal architecture of the NML System can be formulated to have following components. 5.2.1 The Lexical Analyzer ‘l’l~c Lexical Analyzer (LA) provides the NMLS user with a highlevel command interface in the network management language. This interface is exercised both through standard input and through a programming language interface (cmbcddcd Nh4L). The LA parses NML commands for syntax corrcctncss. Any commands or calls that do not parse correctly are passed back to the user with an error code. Commands that do parse corrccdy are passed on to the Kemcl.
M-action commands would bc mostly Nh4L command requests from remote managers. These commands will be in the data fields of the M-action command, and are passed along in NML command format to the Kernel. 6. Examples
5.2.2 The Kernel
The following simple scheme is used to illustrate the examples below: We assume there is a network of gateways. Thus there is a table in the manager manager1 which has control information on the location of IP data tables for each of these gateways, and who their managers are. This table is not visible to AUs at managerl, only to the NMLS, as:
The Kernel is rcsponsiblc for directing the flow of information within the NMLS. The Kernel maintains controi tables in the MMIB. invisible via NMYL.,where it keeps information like location and replication of spccitic database tables, and translation of parameter-name trees (“managed object lists” for CMIP) to database names. The Kcmcl receives commands from the Lexical Analyzer (LA) or the SMAP Control Unit (SCU). Commands from the SCU arc NML commands that have been invoked through the CMIP M-action mechanism from a remote NMLS (see cxamplc 6.4). If the command is destined for a future time, (based on the value in the AT clause), it is sent to a background timer dacmon that will queue this command back at that time Kemcl dcmultiplexes all commands into two queues based on the semantics of the command. The Kernel checks whether the rcquestcd tables arc all rcsidcnt in the MMIB. If the tables are resident in the MMIB, the command is routed to the TimeSchema Translator (TST). If the tables arc not locally resident, the Kernel checks if the tables are at agents that this manager manages. If so, the Kernel passes the commands to the SMAP Control Unit (SClJ). If not, the tables must bc managed by some other manager. In that case, the Kernel finds the information on the appropriate manager. and passesthe command and information on to the SCU.
Control Table name : gateways
name . arpal milnet3 Santa maria
physical-address 1 2 3 4
I
ip-table-location manager1 milnet3 manager1 manager1
manager manager 1 manaeerl 1 manager1 1 manager1
The ip-data-table for arpal is replicated at managerl, as are those for Santa and maria. The similar table for milnet3 is available only at that agent, and is not available at managerl. Thus each gateway maintains its ip-data-table at the specified location. Some form of consistency (outside the scope of NML) is used to keep the replicated topics consistent. The table has entries for the name of the gateway, its manager’s name, a packet count, and a reassembly
102
WHERE name = profile-mblc.name AND time = 300:00
timeout. The ip-data-tables for these gateways, at tbcir respective locatiohs, look like: ip-data-table
name arpal
manager 1 manager1
ip-data-table
name milnet3
manager I manaeerl
name 1 manager Santa manager1
1 reassemblyTimeout 5
(at milnet3 for milnet3)
1 totalInputPackets I 89
ip-data-fable
The remote (agent) copy of the table for miInet3 is updated by Kernel handing over the update command to the SCU. The SCU will, in turn, parse this command and send an M-set command to the manager SMAP, manager SMAP commands the agent SMAP, and the agent SM.@ pcrforms the remote update, rctuming a confirm to the manager SMAP. The return of M-set.conlirm from SMAP will now cause an NML confirm to go to the system administrator.
(at manager1 for arpal)
) totalInputPackets 1 0
1 reassemblyTimeout I 6
6.3 Event reporting
(a~ manager1 .for sanfa)
1 tot.alInputPackets 1 reassemblyTimeout 6 3
These tables can bc thought of as parts of one big ip-data-table. We assume this table has versions at time = O:O, l:O, 2:0,.....200:0, and the current time is 200:0. These versions are maintained by the TST at the respective location, which keeps an extra column “time” in the table, with the appropriate values (Thus each sub-table will be visible (at least conceptually) to TST as 201 rows, with each row having a different value in the time column). All the gateways are agent nodes to the manager node managerl.
Suppose that the rcmotc agent arpa needs to report an event (alarm) like its total1nputPacket.scounter changing values, back to the manager managerl. This unsolicited (by the manager) event report comes into managerl’s SMAP as an M-event-report, which in turn comes into the SCU from the SMAP. The SCU is able to access NILS control information for translating object-ids and manged-object-lists into MMIBspecfic table and column names. It thus translates the event report into an NML command like: UPDATE ip-data-table SET totaIInputPackcts = 93 WHERE name = arpal which is sent to the Kcrncl. Kemcl in turn passes the command to TST, which then applies the command to the MIB via a related SQL command as in 6.2. The conlirm for this command then moves from MMIB to TST to Kernel to SMAP to manager CMIP and thence to the agent CMIP.
6.1 Creating a database entry
6.4 Manager-to-manager
The manager can use SQL commands to create or edit entries in the database, independent of the NMLS system. Thus, if she needed to create a profile table from which the network devices are to be initialized, she would use the following SQL command: CREATE TABLE profile-table (name CHAR ( 16) , PI.50 Directory Standard 16 chars*/ reassemblyTimeout NUMBER) /*32 bits IS0 standard*/ which creates the (empty) table projile-fable. Now four SQL commands like: INSERT INTO prolile-table VALUES (arpaI.10) will put values into four rows (one for each gateway) of the table profiletable.
Now assume that the tables for the totalInputPackets counter for santa and maria arc available only through an intermediate manager manager2, i.e. their tables are no longer rcplicatcd at managerl. NMLS will know this from the fact that the “manager” column in the table “gateways” will show manager2 as the value. Then the same command from the system administrator as in 6.1 causes a different action on the part of Kernel. Instead of updating the local copy via TST as before, the Kernel recognizes that the manager of thcsc dcviccs is not itself, breaks the query into four subqucrics, and qucucs. the arpal query towards TST (local table), the milnet3 query towards SCU to bc translated into an M-get (agent table at milnct3). and queues the other two sub-queries for Santa and maria towards SCU to be uanslatcd into M-action commands with destination manager2. The SCU rccognizcs that [he Santa query, for instance, is a manager-to-manager command from flags set by Kernel, and queues a SM-action command towards manager2. The action parameter is M-get, and the action-type is “send-to_NML”, and the data wilI be the NML UPDATE command. Upon receiving this action command, manager2’s SCU will queue the NML command toward Kernel. Kernel will get the command executed via managert’s TST, and send the result to SCU. The result then gets packaged as an M-action.resuIt and reaches back to managerl’s SCU, which in turn passesit on to the user via Kemei.
ip-data-table
name maria
manager ( manager1
(al arpal)
1 totalInputPackcts I 3
1 reassemblyTimeout 8
6.2 Initialization of the network from a profile Now, initializing the network at a future time is performed via the following NML command: UPDATE ip-data-table SET reasscmblyTimeout = profile-tablc.rcassemblyTimeout WHERE ip-data-table.name = prolilc-tablename AT 300:00
Commands
7. Conclusion
The NML LA parses this command correctly, and passesit on to the Kernel. The Kernel recognizes that the AT parameter is at a future time (300:0), and sends the command to the dacmon queue. At time 3OO:OO. the daemon requeucs the command back to the Kernel. Now the Kernel breaks up the command into four diffcrcnt update operations (three to be performed on local data, the other at remote data on milneo. This information is in the control table “gateways”). The local copies of arpal, Santa and maria’s tables are updated via passing the command to TST. (Note that it is possible to impose explicit consistency with the remote copies at these gateways by also simultaneously queueing the same update commands to the SCU as below. But other mechanisms for consistency maintenance could be in effect. too). TST will chop off the AT extension and make it part of the WHERE clause thus: UPDATE,~~-data-table SET reassemblyTimeout = prolilc-table.reassemblyTimeout
This paper has introduced the concept of the NML, which provides the network managcmcnt application programmer with powerful constructs for building network management applications. The NML provides its user with an integrated view of all network resourcesby allowing the programmer to specify queries on the MIB and propagating operations on the MIB to corresponding physical entities in the network. We have presented arguments in favor of NML based on its expressiveness, potential cost savings, and versatility in adapting to changes in underlying communication services. We have defined an NML that is an extension of the widely accepted SQL standard, resulting in a relationally complete language. ‘This idea was suggested by Anne Lam
103
The NML is being implcmcnted as part of Unisys Corporation’s Heterogeneous Network Management Project. Scvcral network management prototype applications are planned for implementation in NML. These implementations will offer us the opportunity to evaluate NML in an operational sating. Issues such as pcrformancc, ease of programming, and security will be stud&l closely. Security and performance are of particular interest, as it has been diflicult to cvaluatc these.characteristics in the paper design. The lessons lcamcd from these efforts will allow a more objective assessmentof NML. Acknowledgement
We wish to thank many of our colleagues at Unisys who have helped in bringing this work to fruition. In particular, we wish to thank Carl Sunshine, Anita Skelton, and Margie Templeton for their encouragement of this work, Anne Lam for critical appraisals at all stages of this paper, and several others who have revicwcd and commented on the contents of the paper. In addition, the feedback of the NctMan working group of the Internet Engineering Task Force has been cxucmely helpful.
[BERN831
Mary Bcrnstcin, &-I Sunshine, and David Kaufman, “A Network Control Ccntcr For Broadband Local (SepArca Networks,” Proceedings of LOCALNET tember 28-30.1983).
[BRID86]
“Network Control Scrvcr/lSO Installation and Operation Guide,” 09-007 l-00, Bridge Communications (April 1986).
[CDFS88]
Jeffrey D. Cast, James R. Davin, Mark S. Fedor, and Martin L. Schoffstall, “Introduction to the Simple Gateway Monitoring Protocol,” IEEE Networks 2(2), pp.4349 (March 1988).
[CHOU86]
H.T.Chou and W. Kim, “A Unifying Framework for Version Control in a CAD environment,” Proc. Ind. Conf. on Very Large Dafabases (August 1986).
[DADA841
P. Dadam, V. Lum, and H. Werner, “Integration of Time Versions into a Relational Database System,” Proc. Ind. Conf. on Very Large Databases, pp.509-522 (August 1984).
[DEC86]
“VAX/VMS Network Control Program Reference Manual,” AA-2425C-TE, Digital Equipment Corp. (April 1986).
[FERI88]
M. Feridun, M. Lcib, M. Nodine, and J. Ong, “ANM: Automated Network Management System,” IEEE Networks 2(2), pp.13-19 (March 1988).
[HIND831
Robert M. Hindcn, “A Host Monitoring Protocol,” Arpanct RFC 869, BBN Communications Corp. (Deccmbcr 1983).
[KIM871
W. Kim and H.T. Chou, “Versions of Objects and Schema in an Object-Oriented Database System,” MCC Technical Report DB-077-87 (Feb 1987).
LAMP781
L. Lamport. “Time, Clocks, and the Ordering of Events in a Distributed System,” Communicarions of lhe ACM 21(7), pp.558-565 (July, 1978).
[OSI86d]
“Information Processing Systems - .Opcn Systems Interconnection - Service Dclinition for Common Application-service -clcmcnts-Part 2: Association Control,” IS0 8649, International Organization for Standardization (1986).
[OSI86c]
“Information Processing Systems - Open Systems Intcrconncction - Protocol Definition for Common Application-scrvicc -elcmcnts-Pat 2: Association Control,” IS0 8650, Intcmational Organization for Standardization (1986).
[OSI87a]
“Management Information Service Definition - Part 2: Common Management Information Service Definition,” DP 9595/2. International Organization for Standardization (June 1987).
[OSI87b]
“Management Information Protocol Specification Part 2: Common Management Information Protocol.” DP 9596/2. International Organization for Standardization (June 1987).
Appendix NML statements and procedures
From the ANSI SQL standard definition, the SQL statement is defined as: ::=
( I I ...(elc.)
From this, we define: ::= 1 :I= Here cunsianed infeaer> is defined in the SOL standard. In keeaing . I with
the SQL standard, we now define:
::= PROCEDURE . cparamefer declaraGon>...; ;
to give us the definition of NML syntactic cntitics. References
[ANSI861
ANSI X3.135-1986, American National Informalion
Systems - Database
Standard for Language - SQL,
American National Standards Institute, New York. N.Y. (October 1986). [ASTR861
M.M. Astrahan, M.W. Blasgen, D.D. Chamberlin, and et al, “System R: Relational Approach to Database Management,” ACM Trans. Database Sysrems l(2). pp.97-137 (1976).
104
[OSI87e]
[OSI87f]
“Information Processing Systems - Open Systems Intcrconncction - Managcmcnt Information Protocol Spccilicalion - Rcmotc Operations Service Definition,” IS0 9072, International Organization for Standardization (July 1987).
... ’
“Information Processing Systems - Open Systems Inlerconncction - Management Information Protocol Spccilication - The Directory - Ovcrvicw of Concepts, Mod& and Scrviccs,” ISO 9594-1, Intcmational Organization for Standardization (November 1987).
[PART881
Craig Partridge and Glenn Trewitt, “The High-Level Entity Managcmcnt System (HEMS),” IEEE Nerworks 2(2), pp.37-42 (March 1988).
[SNOD88]
Richard Snodgrass, “A Relational Approach to Monitoring Complex Systems,” ACM Transactions on Computer Sysfems6(2), pp.157-196 (May 1988).
[SYTE831
“LocalNct 50/100 Network Control Center Reference Manual,” RlOOO.l/l-03A, Sytck (1983).
[TERP87]
Korncl Tcrplan, Communica(ion Nerworks Management. Prentice-Hall, Englcwood Cliffs, NJ (1987).
[UNGE851
B. Unger, G. Lomow, and others, Jude Project Report, Computer Science Dcpartmcnt, University of Calgary (1985).
PRESENTATION
Layer 7 APPLICATION JEE! ROSq PM’S1 ACSE Layer 6 LME PRESNTrb S%:N LME Layer 4 TRANSPOl+~
MANAGER
AGENT
Figure 2. Manager and Agent in OS1 Management NML STATEMENTS
[WEST851
RESPONSES
K MANAGEMENT
LANGUAGE
NML LEXICAL
JiI Wcstcott, John Burruss, and Vivicnne Bcgg, “Automated Nawork Managcmcnt,” Proceedings of IEEE INFOCOM ‘85, pp.43-51 (March 1985).
ANALYZER
5 NMLS KERNEL
I
TIMESCIIEMA TRANSL.
ShtAP CONTROL UNIT
.._....._.._.. .._... .... .. . . .. . . .. “” .,.......^.....,,_” .,.,.,,, I,._,,.,,,,,.,.,” ..___._.,_.._._ SMAP MANAGER RESIDENT PARTOF hQB
CMlP I OhI OS1 IAYCrS
/
Figure 3. The Network Management Language System COMMUNICATIONS SYSTEM
Figure 1. Network Manager
105
