The following chapter shows there is a mapping from the Managed Resource Interface to the most commonly used management protocols. SNMP is the most important and is thus covered in detail. CMIP, HTTP and CORBA are discussed from a general perspective.

SNMP based Management

The Simple Network Management Protocol (SNMPv1) [RFC1157] falls into the category of the Internet Management protocols. It is the product of the Internet Engineering Task Force (IETF) [10] when the need for a standardized means to control large TCP-IP based networks came to light in the mid 1980s. Due to its simplicity, it gained wide acceptance, resulting in its support by many vendors. There were deficiencies and limitations, however, so in 1992, work was initiated on SNMPv2 (RFC1142-1452). This improvement in performance, security and ability to build hierarchical systems quickly made it one of the most commonly used and supported management protocols within IP based networks (telecom networks included). SNMPv2 has however resulted in a more complex protocol than originally thought, and claims have been made that the S in SNMP now stands for sophisticated instead of simple [Berkhout, 1994]. The specification for SNMP v3 and its coexistence with SNMP v1 and v2 has since been developed.

Here follows a brief introduction of SNMP, necessary to understand the mapping to the MRI. This paper concentrates on SNMP v2, as it was the version used to implement the MRI. A special emphasis is placed on the information model. For a complete documentation, see [Rose, 1994] and [McGinns, 1997].

Functional

SNMP has no operations covering issues discussed in the functional models. This is solved through standardized Management Information Bases (MIBs) supported by the managed entities and their agents. These MIBs define common information belonging to the managed heterogeneous resources, allowing them to be monitored and managed in a uniform fashion through the MIB.

The first standardized MIB, also considered the most important one, is the MIB-II [RFC 1213], mainly used for configuration fault and performance management. It has grouped together variables belonging to the major protocols such as IP, TCP, UDP, SNMP and more. Monitoring remote networks as a whole was a problem for SNMP, as it had been built to monitor single nodes. This deficiency was for solved by defining the Remote Network Monitoring MIB (RFC1271). Other standard MIBs include AppleTalk (RFC 1243), Mail monitoring (RFC 1566), ATM (RFC 1695) and more. New standardized MIBs are being developed all the time, and an up to date list of RFCs can be obtained from IETF’s web page (see [WEB]).

Communication

The communication model between the managers and the agents is through Protocol Data Units (PDUs), where messages are sent asynchronously. Different types of messages are sent within different SNMP PDUs. Multiple requests, as long as they are of the same message type, may however be incorporated in a PDU. There is no guarantee that PDUs reach their destination, making the manager responsible for taking necessary precautions and actions. No requirements exist for SNMP’s underlying protocol. The connectionless User Datagram Protocol (UDP) is most commonly used, but there are RFCs defining how to operate it on top of other protocols such as Ethernet, TCP/IP and Apple Talk.

The message types include the get, get-next and set operations. Get-bulk request was introduced in SNMPv2 retrieving large amounts of data through a depth first search. The agent, in reply to the manager requests, sends a PDU containing the response message. Traps are the only message types that agents are able to send spontaneously.

The SNMP agent provided with OTP will handle all the coding and decoding of the PDUs. It will then map the requests to Erlang function call stubs returning data used for the response messages.

Organization

The organizational model is based on the manager agent paradigm. The manager sends requests to the agent receiving a response. Scalability and reliability is achieved by creating hierarchies, where agents can also act as managers towards other agents located at a lower lever of the hierarchy.

This allows lower level managers, referred to as proxies, to handle administrative actions. They are often automated, relieving the load off other already busy high-level managers. The middle managers can in addition distribute work delegated from managers at a higher level of the hierarchy to other agents. Information hiding is also made possible, as is transport protocol independence.

Information

SNMP’s information model consists of MIBs describing the managed objects. They are defined by using a subset of the ASN.1 [X208], an internationally standardized language for defining syntaxes. A MIB contains the description of all its variables and tables, values these variables and tables may take, together with the global names used to access these contents.

MIB variables are scalar variables of which there only exists one instance per MIB. Tables are two-dimensional, where single elements are themselves scalar variables. Values in tables have to be accessed one column at the time, as SNMP’s only processable unit is a scalar variable. Operation on complete rows such as the creation or deletion can be emulated through the use of extra variables.

Defining Managed Objects

A MIB is a module containing managed entities logically grouped together. A unique name is chosen for the module, followed by imports from other modules such as syntax types, object types, and trap types. These imports are followed by the definition of the object identifiers (OID), dependencies of these OIDs to other standardized MIBs, and references to the parent in the naming tree, followed by Manage Object (MO) definitions.

The object type macro allows for three types of objects to be defined. They are tables, rows, and leaf objects. Tables are made up of rows, and rows are in turn made up of leaf objects. Scalar variables, which are unique in every MIB, are also leaf objects. A leaf object is the smallest grouping of information.

Leaf objects are accessed through an OID, where every managed object has a globally unique name in the naming tree. OIDs are a sequence of hierarchically organized non-negative integers. Values are stored in the leaves of this tree. To facilitate usage, a textual name is associated with each sequence element of the OID.

An SNMP MIB would map to a set of MRI record definitions logically grouped together. The tables map to collections of MRI record types, while the table rows will map to instances of these records. The leaves of the naming tree would in turn map to the specific MRI record fields. A scalar variable may either denote a columnar entry of a row or single variables. Single variables could be stored in MRI records with no keys, or derived in an intermittent above the MRI. Finally, OIDs map to a MRI record type and its set of keys, and the column number to a field in the MRI record or record extension.

Example 7: The first two definitions are for normal integers, the second for enumerated types, and the third regards an integer bitstring.

Leafs can be of the type integer, octet string, or null. Based on these basic data types, more complex data types are defined (or imported from other MIBs). The mapping of these data types to Erlang data types is straightforward. Fancier mappings can be achieved by mapping enumerated types to atoms. The OTP MIB compiler will instead create include files with macros. These macros will be replaced with integers by the precompiler.

Octet strings, and all data types derived from them, are lists of bytes. They can easily be mapped to Erlang lists or binaries. They are intended in being binary data chunks. The length may be fixed, variable, and its values could be given upper and lower bounds. Special cases of strings include the octet bitstring used when the size of a bit string is not enough, a display string, consisting of printable ASCII characters and the IP address, a four byte octet string.

All definitions originate from an OCTETSTRING or an integer, and are then mapped to the existing Erlang data types. Erlang references and process identifiers should be avoided in the MRI, but if used, a mapping to a unique integer or octet stream would be possible.

Operations on Managed Objects

As described in the communication model, there are three operations that can be applied on a managed object. They are asynchronous request - response types sent in PDUs by the manager. The agent asynchronously responds to these operations. Traps are also spontaneously sent, and involve a notification of a change in state of a managed object.

The SNMP requests, upon being received by the agent, are mapped to function calls. These function calls may be executed concurrently, and are usually handled by spawning a process for every request. The mapping provided here is simple, and does not take into consideration efficiency aspects. If generic tools such as a key cache or filtering requests are implemented above the MRI, a more efficient mapping than the one described could be achieved. Adding these layers is a necessity in a large system, but can be considered redundant if the mapping is simple.

The get operation takes an Object Identifier as a parameter. The agent will respond by encapsulating the contents of the scalar variable in a response PDU. The scalar variable could be either a column in a row, in a specific table, or a simple variable. If the OID is erroneous, the noSuchName error code is returned. By grouping together several get operations, the retrieval of a whole row in a table can be simulated.

In the MRI, the get operation would have a 1-1 mapping to the get_info call. The SNMP OID is mapped to the MRI record keys, and the column number is mapped to one of the fields in either in the MR record or in the extension record. Some agents support the returning of a whole row in the PDU. The mapping thus can be extended to return several of the MRI record fields.

The get-next operation has by [Rose, 1994] been called the powerful get-next operation. The power lies in its ability to return the next (in lexicographical order) object instance in the MIB tree, together with its OID. The OID is often recursively used in the following get-next request. Tables are traversed vertically, taking one column at the time, and not horizontally, as one might expect. Several get-next operations may be encapsulated in a PDU, allowing different tables to be traversed simultaneously.

The get-next operation is based on the ability to efficiently pick out the next column and key of a scalar variable. As tables are traversed vertically, the SNMP agent would return the same field in all the records in the MRI table, together with the next key and the column number. When this column has been traversed, the column number would be increased, and the field denoting the next entry in the SEQUENCE would be traversed. If the Column value is 0, we are dealing with a scalar variable, and thus map it accordingly, possibly to a MRI record with no keys, returning it together with the first key of the next table in the MRI (mapping to the next table in the MIB). The last case is if there are no more tables defined, to which the get-next operation returns genError. The API provided by OTP’s SNMP agent allow the retrieving of one row at the time, avoiding the inefficient vertical traversing of the tables otherwise required.

The set operation takes an OID and a value that are sent to the agent. The agent replies with a success or failure of the write action in the response PDU. Error types include noSuchName, where the OID is erroneous, badValue, where the type of the value sent is not the type defined in the MIB. If the variable has no read-write access value, readOnly is returned. All other errors are covered by the genErr. Returning the noError type denotes a successful operation. Grouping all the set requests in a PDU simulates setting of a whole table row. The only error types originating from the MRI include noSuchName ({error, instance}) and genErr. genErr stands for all other error types that can occur. Such an error will result in an entry in a SNMP table where the SNMP manager can the specific error type can be read.

Set operations are mapped to MRI actions. If a whole table row is set, the MRI must be able to either provide an atomic operation for setting all the values, or a transaction mechanism that allows roll back in case of some, but not all the necessary actions succeed.

Web Based Management

Web based management is rapidly gaining popularity as expensive platform dependent management systems are quickly being replaced by web browsers. Browsers use HTTP over TCP/IP when sending requests to web servers. These requests are converted to queries and actions executed in the CP. The results are formatted into HTML and sent back to the browser where they are displayed. With the help of Java script, functionality can be moved between the browser and the CP. The most common practice is to check for basic syntax errors in the browsers, pushing the remaining functionality in the CP.

Diagram 7: The MRI using HTTP over TCP/IP.

Web based management has raised the issue of standardization, in that most vendors have developed proprietary protocols. The Web Based Enterprise Management (WBEM) under control of the Desktop Management Task Force (DMTF) [11] , and the Java Management API (JMAPI) [12] are working on new standards. They are however still young, and according to [Oslebo, 1998], a lot of work remains before this new technology is accepted as a standard for network management. Concerns have also been raised over the fact that no work has been made over the integration of web based management standards with other existing protocols.

Communication model - HTTP

The communication model is covered by the Hyper Text Transfer Protocol (HTTP). HTTP provides an IP based connection where strings are exchanged. Most web servers available on the market provide log in security and encryption of the data being transferred.

These strings retrieved from the web server contain tags that often are a dialect of the Standardized General Mark-up Language, (SGML). The most commonly used dialect is the Hyper Text Mark-up Language (HTML), which provides means to graphically display data.

Information Model

No defacto information model exists for HTTP, even if work is on the way. A simple mapping for web-based managers would today require an API, where tagged requests in some proprietary SGML dialect are mapped to instrumentation functions. The AXD 301 ATM switch, as can be seen in diagram 5, maps its HTTP functions to SNMP instrumentation functions. A more effective way, however, could have been mapping directly to the MRI, not having to take into account the SNMP specific behaviors.

Allowing a representation in the html code that is understood by the web server allows for higher-level actions to be mapped to the MRI actions. Representations in the web pages could include CGI-bin scripts, ehtml [13] tags, calling or Erlang functions, or Java applets running threads towards the management system, interfacing Erlang on the CP. Simple type checks can be made using Java scripts or through a layer above the MRI.

HTTP is a connectionless protocol, so spontaneous notification of events from the CP is not possible. The simplest solution is by automatically reloading a frame with the alarm notification every few seconds. The second, and preferred way, is through a Java thread.

The organizational model would be a strict client server one, not allowing hierarchical systems. As the contents of the web pages will be created on the fly, no HTTP proxy servers should be used.

Corba Based Management

The Common Object Request Broker Architecture is a standard derived by the Object Management Group (OMG) [14] consortium . Their mission was to write a specification for an Object Request Broker (ORB) providing a software bus that allowed objects written by different vendors to interact across networks. Corba based management uses an Object Oriented architecture where managed entities are defined in interfaces and accessed through client server relationships. It is more powerful than SNMP and less complex and easier to use than CMIP. Its affiliation with C++ and Java helped spread its popularity as these languages where given properties such as distribution, platform transparency and component based software modules. Corba 1.1 specifications, introduced in the early 1990s, specified the Interface Definition Language (IDL), language bindings and the interface towards the ORB. Programs could be written interfacing different ORBs. ORBs from different vendors, however, were only able to interact after the Corba 2.0 specification was released, as it described the inter-orb operability across networks.

Organization and Communication Model

The organization model is a client server one, where servers can themselves take the role of clients. Clients can be seen as a programs that invoke methods (or requests) on Corba objects (The EM), while servers are programs that implement these objects, performing the operations associated to them (The CP).

The communication model in Corba v 2.0 is based on the Internet Inter-Orb Protocol (IIOP). Different Corba implementations conforming to IIOP guarantee full interoperability with each other, facilitating inter-node communication in a distributed environment. Distribution is transparent, as clients invoking a service on an object do not need to know where on the network this object resides. Client requests on local objects have the same syntax as requests to objects on other nodes. The semantics differ, however, as local requests are handled within the ORB not using IIOP.

Function Model

The CORBA functional model consists of a set of services provided by the ORB. These services are themselves defined as CORBA objects, either by directly providing interfaces accessed by the clients, or by providing interfaces inherited by other object definitions. The most important services include naming, life cycle and event services. The life cycle service deals with the creation, deletion and relocation of Objects.

The naming service allows names within a naming context to be associated to an object. This association can later be used in resolving these names to Corba references, to create contextual object relationships (defining relationships between objects), or just to retrieve a list of objects bound to the naming context.

The event service allows suppliers to provide consumers with events. Suppliers can send spontaneous notifications through the push model. Consumers can otherwise read events directly from the supplier through the pull model. In the push-pull model, suppliers generate the notifications, which are stored in an event channel (a queue) and eventually read by the consumer. In the pull -push model, both the supplier and the consumer are passive. The event channel will pull an event from the supplier and push it to the consumer.

As Corba is more complex than the MRI, the multi protocol management agent could be used to fill in the gap. This would imply that the MRI information model would have to be expanded to cover the functionality. The latter can be easily done for all Corba services not implemented in the ORB, but would defy the purpose of the MRI, as the information model should be developed independently of other management protocols. The best way of mapping Corba services to the MRI would be through bridging, where a software layer implements the extra functionality not existing in the MRI.

In the event service, for example, the push model has a one to one mapping to the MRI notification of events. All other the other models, however, would have to be implemented as an extra layer between the ORB and the MRI. No life cycle or naming service functionality exists in the MRI, but many of the dynamic objects have create and delete actions associated with them.

Information Model

Objects residing on a Corba bus are described as identifiable encapsulated entities providing services to the client. They are defined in a subset of the Interface Definition Language, a specification commonly used to define platform and language independent interfaces. These interfaces consist of unique object names, a set of functions, and the type these parameters and return values can take. They are compiled using a stand-alone IDL compiler, producing client and server code stubs.

The IDL function definitions in the interfaces are mapped to MRI actions and get_info functions. Return values of these functions can be simple or composite IDL data-types extracted from the MRI records. If a direct one to one mapping is to be achieved with the MRI interface, MRI records can at run time be converted to IDL structs. Every field in the MRI record is mapped to the respective field in the IDL struct. Error values returned from the MRI function calls are handled as exceptions on the client side, while actions returning the atom ok can in the MIB be defined to return void.

Table 1 maps the basic IDL data-types to Erlang data-types. Erlang does not support the double value range, so all conversions of a double will be mapped to an Erlang float. The data-type any is used in conjunction with type codes defined in the OMG Corba specification, allowing functions to be dynamically typed.

IDL objects are identifiers referring to other Corba objects. Corba objects are identified by unique references created by the ORB. These references are internal to the ORB, so a table has to be placed in a layer above the MRI storing the mapping of the references to the MRI keys.

The constructed OMG data-types are listed in table 2. They are self-explanatory.

The functions provided in the MRI should also be included in the Corba Object description. Corba requests take a target object, a request and a set of parameters returning an IDL data-type. MRI actions can thus be mapped to separate requests returning void (where the atom ok is otherwise returned) or the struct describing the managed entity for all other ones. Any errors can be raised as exceptions.

There should be a specific get_info function to read the struct, and if needed, a set one for the management data. Other specific requests not affecting the state of the CP can also be mapped to MRI set requests.

An operation similar to the SNMP get-next or get-bulk could be included in the object interface description mapping to the MRI get_keys function. The get_keys function would thus be broken down into several calls ensuring that the size of the data transmitted between the server and the client is manageable.

The Corba naming service can be useful when implementing the get_next or the get-bulk function. By binding the smallest (In lexicographical order) element to a static name, it can be used to retrieve the first Corba reference. This reference is then used to read the remaining references until the end of the table is reached.

Interface inheritance is another property associated with the information model, where one Corba interface may inherit properties from other interfaces. Where defined, it can be assumed that the Corba objects inheriting properties from other Corba objects would in most cases map to MRI managed object hierarchies, which already share these properties in their MRI definitions. The MRI has no inheritance, so these inherited properties have to be defined on a managed object basis in the MRI. If that is not the case, the inherited properties would have to be defined on a managed object basis in the MRI.

OSI Based Management

The OSI management framework was derived by the International Organization for Standardization. Work was started around 1980, and the final publication [ISO 7498/4] was released in 1989. This framework was seen as inadequate, so work on an additional standard, the Systems Management Overview (SMO), was started in 1987. It was finalized in 1992 through the publication of [ISO 10040], which together with [ISO 7498/4] provides the standard for OSI management. When endorsed by ITU as a Telecommunication Management Network (TMN) standard, it achieved wide relevance. It is, however, by many considered to be complex, with many ambiguities remaining unresolved (see [Pras, 1995]).

OSI management uses an object-oriented paradigm, where the managed resources are abstracted and referred to as Managed Objects. Monitoring of MOs takes place through polling on behalf of the EM or through spontaneous events generating from the NE. Management operations deal with delegation of tasks and the distribution of intelligence among the MOs.

Exchange of management information takes place in three ways: systems, application, and layer management. In controlling MOs, however, one is usually able to narrow down the complexity and concentrate on the application layer [15] as well as the information and communication models, both defined in the SMO. The MIBs of the information model are defined using a protocol called the Common Management Information Protocol (CMIP). Exchange of data using CMIP is achieved through the Connection Management Information Service (CMIS), which specifies the services provided.

The organization model consists of the manager-agent paradigm where the system, depending on the MO being handled, can take on any of these two roles during run time.

No Erlang CMIP / CMIS agent implementation exists today, but due to the relevance of the protocol in existing telecommunication systems, and the impact it has had on standardized management systems, it is included in this chapter.

Information and Communication Models – CMIP / CMIS

MO classes are grouped in MIBs, where the properties of the resources being managed are described. Properties include attributes belonging to the MO, notifications deriving from it, and actions that can be applied on it. The semantics of the MOs may be specified in the rules for containment and instantiation or they can be inherited from their super classes. Different levels of the inheritance hierarchy will then correspond to the different levels of abstraction. This abstraction allows for the reuse of these specifications in different application domains. MIBs are defined using ASN.1.

Managed Object Instances are arranged in a management information tree, which is expressed by a naming hierarchy. This naming hierarchy is used for scoping, which is the issuing of management operations to several MOs in the same sub-trees. MO classes, in addition, inherit properties from their super classes. When Inheritance applies to the MO classes, it should not be confused with the naming hierarchies that apply to the specific instances of these MO classes.

A MO description lists a set of attributes that are part of the object, characterizing its state and properties. These attributes will map directly to the fields in the MRI record definitions (possibly including data stored in the management field). The data types are similar to the ones described for SNMP containing both simple and composite data-structures, and thus need not be covered. It is worth noting, however, that there is no limitation to the complexity of the Managed Object Classes as there is with SNMP.

A set of actions is associated to a MO. They can be mapped directly to the ones defined in the MRI. The create and delete actions, handled separately in CMIP, could be mapped to other MRI actions whose execution results in the creation or deletion of the record instance. They could also be called create and delete in the MRI, even if it is not always the case.

Conditional packages are used to describe variants of certain managed objects. A managed object, depending on the value of one of its attributes, may trigger other types of MOs to be created. These variants are activated (or created) when the object is first instantiated. In MRI terms, there is no formal means to describe a variant, other than in the action description. The concepts can however be mapped to the MRI record extensions, which are either defined as a stand alone MRI record, or as a composite data-type stored in one of the MRI record fields.

The last feature belonging to CMIP MO definitions are the references to their super classes. There is no inheritance in the MRI, so the inheritance properties need to be redefined for all derived objects at all levels. It is however possible to see the dependency hierarchy of the system based on the key definitions, where the records on a level will contain at least the same set of keys of the previous level, and possibly an extra one.

CMIS allows clients to access and manipulate not only objects, but also whole containment trees. The primitives M-GET, M-SET, M-CREATE, M-DELETE, M-ACTION, and M-EVENT-REPORT are used to form the CMIP PDUs, which are exchanged among mangers and agents. Using the get operation, it is in addition possible to filter objects in the containment tree, and by using scoping, actions may be applied to the set of filtered MOs which meet certain criteria. Tasks such as filtering and executing on the containment tree could be placed in an abstract layer right above the MRI.

Functional model

The TMN functional model covers areas such as configuration management, fault management, performance management, accounting and security. This model mentions CMIP as the protocol to be used, and includes a set of standardized MIBs containing generic services and uniform management interfaces. These MIBs, just like the SNMP functional model, have to be mapped to existing MRI records and actions. Due to the complexity of CMIP, however, some parts of the functional model could be placed in a layer in-between the CMIP instrumentation functions and the MRI.

One of the services in this model includes the logging of the alarms and events generated by the MOs. The functionality for collecting and logging alarms could be placed under the MRI, as can be seen in Appendix B. Alarm handling is generic, and common to most applications, so it would be natural to have an MRI definition for it.

More complex functionality such as test management, however, could in large part be placed above the MRI, using only MRI primitives. Test management includes functionality for scheduling, starting and stopping tests, calculating and analyzing results. The MRI could export actions for starting and stopping the tests, where the return value of the stopping of a test returns possible results. All other functionality for scheduling and analyzing could then be placed above the MRI.

A similar analogy could be made for the polling of data. If the MRI has a record containing the data to be polled, the server the executes the get_info call at regular intervals (and possibly does the statistical calculations) could easily be placed above the MRI, thus minimizing the software impacts under the MRI.