Implementation of SNMP Agent by Inferno

Abstract

Joonho Park
Inferno Network Software Solutions
(joonhopark@lucent.com)
Lucent Technologies
Bell Labs Innovations
600 Mountain Ave.
Murray Hill, NJ 07974

Inferno is a new operating system developed at Bell Labs. It provides a powerful platform for distributed processing through the use of namespace and it minimizes the memory footprint by using dynamically loadable modules. This paper presents how Inferno can support a distributed MIB without requiring additional protocol as well as the capability to dynamically update the MIB in non-disruptive way.

Acknowledgment: Edward V. Bacher, Steve Y. Wang

1. Introduction

Inferno is a new operating system developed at Bell Labs. It is small, portable, secure and network independent [1]. Inferno provides a powerful platform for distributed processing through representation of resources as files and the use of namespace. It is also memory efficient, supported by dynamically loadable modules.

As part of an on-going effort to apply Inferno to existing applications, a study was conducted on Inferno's applicability in network management systems. One of the first applications targeted was the Simple Network Management Protocol [2] (SNMP) agent. The result was that an SNMP agent implemented by Inferno does not require additional protocol (SNMP DPI [3] or SMUX [4]) to support distributed Management Information Base [5] (MIB). The major benefits include:


Other benefits include Inferno's portability through its byte-code compiled Limbo language, and built-in security at the kernel layer of Inferno.

The rest of the paper is organized as follows. Section two gives an overview of Inferno as it relates to the implementation of an SNMP agent. Section three describes Inferno's SNMP agent methodology. Section four is a summary.

2. Inferno Overview

The Inferno system is a distributed operating system based on the application of three basic principles


Resources as Files: File systems are central to the Inferno system. In general, Inferno device interfaces are written in such a way that they consist of a set of dynamic files that an application can manipulate as required. The file systems are used to represent storage devices, processes, services, networks, and network connections. The interface to all resources is file-oriented and involves the following actions: resolving names in a hierarchical tree, attaching to them by name, and accessing their contents by read and write calls. The advantage of the file model is the simplicity of the interface (open, read, write), which is known to all programmers. Reliance on file systems reduces the amount of interface code and keeps the Inferno system small, reliable and highly portable.
Here is a simple example of how a device is represented as a file. An audio device (a speaker) is represented as a file named /dev/audio. An application that needs to play the data (let's say music.wav) on a speaker, will open the file, /dev/audio, and write the data, music.wav, to it (e.g., cat music.wav > /dev/audio in a Unix style command). The data will be played on a speaker attached to the system.

Namespaces: The second key principle of the Inferno system is the computable namespace, by which an application builds a unique private view of the resources and services that it needs to access. Each set of resources and services is represented as a hierarchy of files and is accessible via the familiar file access operations. The various resources and services being used by a process are combined into a single rooted hierarchy of file names, called a namespace. The resources accessible to an individual namespace can be located on a single resource or on multiple resources throughout the network. Thus, file systems provided by different servers can be combined into a single, unique namespace which becomes the application's view of the world.

Figure 1 illustrates an example of the namespace. Figure 1 (a) shows the namespace of System A, which has all the resources residing locally. Typing a command, cat music.wav > /dev/audio, on System A, will play the data on System A's speaker (shown in previous example). If the speaker malfunctions, however, the System A can augment its namespace by mounting /dev/audio file from the System B and replacing its /dev/audio file, the broken speaker, as shown in Figure 1 (b). Now typing, cat music.wav > /dev/audio, on System A will play the data on System B's speaker. The change in the namespace is transparent to applications.



Figure 1

Figure 1 was a simple example but shows a fundamental concept of distributed processing in Inferno; the location transparency of resources. A large application divided among multiple modules can spread its modules over several systems through the namespace. Then, a system with limited memory resource can execute the application by locating modules through its namespace as if all the modules exist locally. The namespace provides a new paradigm in distributed processing; running a large application on a memory constrained system, easy sharing of devices (e.g., MPEG card), utilizing other system's network protocol (e.g, TCP/IP, ATM,..), etc.

Standard Communications Protocol: The third key principle of the Inferno system is the use of a standard communications protocol called Styx. This protocol represents network transports, network devices and network connections as file systems. The protocol supports remote access to files and permits a remote machine to use these interfaces as gateways. Using the same set of files to represent different devices permits the creation of common tools to serve several networks. Network connections represented by these files behave the same way for all networks and thus allow applications to contain no network-specific code.

3. Inferno and SNMP Agent

The study concentrated on ways to exploit the Inferno file metaphor and Inferno namespace, to support the SNMP MIB, which is a major part of the SNMP agent. The result was that the SNMP MIB implemented by Inferno can eliminate the use of SNMP DPI or SMUX protocol required to provide distributed MIB capability. The following subsections describe the methodology used in implementation of the SNMP agent and advantages from it.

3.1 Implementing SNMP MIB through Namespace
To maximize the intrinsic benefits of the namespace, the SNMP MIB should be represented in a file system. The SNMP MIB is organized based on the object identifier naming tree. Leaf nodes (object classes) in the tree define values, and the rest of the nodes organize the leaf nodes (like directories in a file system) so that the related nodes can be grouped together. Since the file structure is essentially a tree, representing the MIB into a file system is basically one-to-one mapping: leaf nodes to files, and other nodes to directories. The dot-separated numerals in object identifier naming tree are used as the names of the mapped directories and files (Figure 2).



Figure 2

3.2 Details of Processing Requests
When a thread of the SNMP agent receives a request from the network manager, it extracts the object identifier of the MIB, maps it to a corresponding file, opens the file, writes the request, reads the result, and sends the result to the manager. The files, however, conceptually hold the value. In reality, the files are interfaces to processes. Each file has a process associated with it. The process is read-blocked on the file. When an application (i.e., a thread of the SNMP agent that received the request) opens and writes the request to the file, the process wakes up, reads the request, executes the request, writes the result to the file, and read-blocks on the file again.

3.3 Advantages
The major benefit of an Inferno implemented MIB is its capability to distribute the MIB. In practice, there are many cases where the MIB will consists of several smaller sub-MIBs supported over multiple systems. Such distributed MIB requires extra protocol to register/deregister the remote MIB to the master agent, and to exchange the data between them. Currently, two prominent protocols, SNMP DPI and SMUX, have been used. Supporting the distributed MIB in Inferno implemented MIB means simply extending its namespace to include the remote MIB. Then, an agent can access any remote MIB as if it exists on the local system (Figure 3) effectively eliminating the use of SNMP DPI or SMUX protocol.


Figure 3

Another advantage of Inferno implemented MIB is that modifying MIB code (bug-fix, code update, etc.) can be done in non-disruptive way. Since many independent processes provide the MIB value, only affected processes have to be recompiled, which does not stop the service of the SNMP agent. In non-Inferno SNMP agents, often the agent and the MIB code belong to one big module, which then have to be recompiled altogether to accommodate any code change. This will temporarily stop the agent service, which may not be tolerable in some environments.

Other advantages come from the Inferno operating system itself. First, Inferno supports dynamically loadable modules, to efficiently use memory space by loading only modules required at the time of execution. Thus, it reduces the memory requirements. Second, Limbo (Inferno's programming language) written code (e.g., the SNMP agent) is portable since the Limbo code is byte-compiled. This code can run, without recompilation, on any system that Inferno supports. Third, Inferno provides Secure Socket Layer (SSL) protocol to protect the privacy of data.

3.4 CORBA and JAVA RMI

CORBA [6] and JAVA RMI [7], or any technologies with Remote Procedure Call (RPC) can support a distributed MIB in a way similar to the namespace. However, often their overhead is so substantial that their efficiency and suitability for resource-limited network elements will be issues. In contrast, the namespace is integrated into the Inferno kernel layer, yielding distributed computing efficient, fast, and comes with no extra overhead.

4. Summary
This paper introduced Inferno and how the SNMP agent can benefit from it. Specifically, it showed how to implement the SNMP MIB through Inferno namespace and what the advantages are. Summarizing those are:

Future studies will focus on Inferno's support on CMISE [8], its MIB, and mediation device (proxy agent) in CMISE-based network elements.

References

[1] Inferno Reference Manual, Lucent Technologies, 1997

[2] Simple Network Management Protocol, RFC 1157, May 1990

[3] Simple Network Management Protocol Distributed Program Interface,
RFC 1592, March 1994

[4] Simple Network Management Protocol Multiplexing, RFC 1227, May 1991

[5] Management Information Base for Network Management of TCP/IP-based
internets: MIB-II, May 1990

[6] CORBA: Architecture and Specification, OMG, 1996

[7] Java Remote Method Invocation, Sun Microsystems, 1997

[8] Common Management Information Service Elements, ISO/IEC 9595, 1991