The chapter examines how the choice of standardized management protocols can influence and limit the evolution of the system by negatively impacting the software architecture. The concept of a Managed Resource Interface in the network element, eliminating the influence and design flaws caused by the protocols, is introduced.

Introduction

If the standardized protocol is badly separated from the rest of the system, there is a risk that it will heavily influence the software architecture on both in the network element and the manager.

This influence in the architecture often occurs when attempts to optimize the application to a specific protocol are made. These optimizations consist in the attempting to reduce the size of the application and increase its efficiency. Other influences are created when inconsistencies are found and fixed in the wrong subsystem, creating a work around instead of solving the problem at its root. The standardized protocols should be placed on top of the managed entities, and not be incorporated into them. In nearly all cases, modeling an application around a management protocol results in an inefficient system.

An example of standardized management protocols influencing the software architecture is a set of counters found in the UNIX BSD kernel. These counters keep track of sent IP packets, and have thus little to do with the kernel’s central functionality. They were inserted in the kernel after the SNMP-V2 MIB was standardized, as the MIB required these counters. Placing them in the kernel was probably the easiest way of complying with the standard, thus resulting in non-core functionality being inserted in a core subsystem.

This independence in the software architecture should be achieved by adding a generic layer in the network element and in the manager. The goal of this layer is to separate the software architecture from the specifics of standardized protocols. Should requirements demand that a standardized protocol be added or removed, this can be done by changing this additional layer and not influencing the other parts of the system.

Protocol evolution

New standardized protocols are being developed all the time. Some become popular and are used in a wide range of areas, while others are used only within the specific niche they were originally created for. When is it acceptable to choose a new standardized protocol instead of some older proven one when both can handle the same requirements?

What tools can be used to facilitate the development of the manager and network agent for a specific application if the new protocol is used? What extra functionality can be offered to the end user which is not included in the requirements, but which is integrated with little or no extra work due to the protocol choice?

Common sense and extensive prototyping should prevail in the choice of a new paradigm instead of just following the flow and fashion of the moment. It is possible that requirements can be met and fulfilled with older models where tools and competence is readily available, resulting in the same effort. This alternative protocol might contain functionality that is needed due to changing market requirements, or be hard to implement in the framework of the existing implementation.

Whatever such a decision is based on, it is important to be able to backtrack and change or add standardized management protocols. This implies that the network element and manager software have to be implemented in such a way that a change of protocol, at any one time of the development stage, will minimize impacts on the system.

Protocol Additions and Changes

There are several solutions to the problem of having to introduce a new protocol in a network element. The most inflexible method, called a multi-protocol management agent, is adding one protocol’s capabilities to another. Such a method is rarely used, and not recommended due to its complexity and need to re-implement large parts of the information model.

Another possibility is a multi-protocol manager, where the actual standardized protocol used is hidden in a layer within the manager. This layer offers an internal homogeneous model to the management applications, hiding the standardized management protocol differences. This requires management platforms equipped with the possibility of adding these internal extensions.

The most commonly used solution consists of a management gateway, also called bridging. This gateway can be placed in the management system, in the network element, or in a mediation device between the two. It maps one protocol to another. This method poses the question of being able to use the full capability of the agents provided. When mapping a less powerful protocol to a powerful one, little effort is needed, as the gateway does not need to fill any functional gap between the two. It is enough keeping track of the addressing schemes. It is however harder when a powerful protocol is to be mapped towards a less powerful one. When mapping a powerful protocol towards a less powerful one, the functionality has to be implemented in the gateway.

This paper introduces a fourth method that builds on the idea of the multi-protocol managers, with the difference being that the generic layer is placed in the network element instead of in the management system. This layer is achieved through a generic interface, treated as a proprietary information model. Through a simple gateway, the standardized management protocol agents use the interface to create, populate and manipulate their information models. This allows new standardized protocol and information models to be implemented and inserted alongside other existing management protocols and agents resulting in multi-protocol network elements. The interface can be further expanded with the communication, functional and organizational models so as to be used as a proprietary protocol towards management systems being developed alongside the network element.

The Managed Resource Interface

The Managed Resource Interface (MRI) portrays the network element as a relational database consisting of a set of predefined tables. The function calls provided are primitive and atomic, not allowing any implementation specific knowledge of the system to be used above this interface. Included is a set of generic function calls. They can be used to retrieve all the keys belonging to a specific table, or given a table name and a key, they retrieve just a single element. No function calls are provided to write in these tables. The only way to change the state of the network element, thus changing the values of the entries in these tables, is through a function call executing actions defined in the information model.

The managed resource interface allows clients to subscribe to alarm and events from the network element. This is the only means of spontaneous communication from the network element towards the management system. Additional functionality for the subscribing and unsubscribing of events is provided.

By using the primitive functions in the managed resource interface, a set of generic tools can be built. These tools can export the needed functionality for a specific protocol bridging, and contain local optimizations. If built generically, these tools can be used regardless of the network element and the type of data exchanged.

An example of exported functions would be the implementation of the SNMP get-next operation, which is not exported in the MRI. Another operation could include the filtering of certain objects in relation to some defined attributes passed in the function call. These generic utilities should be developed once to facilitate bridging to standardized protocols in any network element, and should not be connected to any specific model.