This chapter analyzes the problems involved in choosing which standardized protocol to adopt between a management system and its network elements. It covers factors to be considered when making such a choice. Readers familiar with telecom networks and standardized management protocols can skip this chapter. 

Telecom networks consist of the infrastructure providing the transfer of voice and data between peer applications. The end applications will be connected through an access network. Fixed systems are referred to as wireline access networks and include standards providing services such as analogue telephony (PSTN), telephony and data transfer (ISDN) and packet based broadband services (ADSL). Radio access networks will provide the infrastructure to handle analogue and digital telephony such as NMT, GSM, CDMA alongside packet based GPRS and UMTS services.  Connecting the various access networks together is a backbone transport network consisting of routers and switches transporting data using protocols such as IP, Frame Relay and ATM. Connected to the backbone and the access networks are a set of centralized servers providing services to the applications. The wireline and radio access systems, the switches and routers in the backbone, and all the servers supporting these services are referred to as network elements (NE). Network elements are controlled through remote network management systems, using management protocols to manage and supervise this infrastructure. This thesis will go in depth with the application level of the management protocols, and only briefly look at the transportation level.

Management protocols provide standardized means of describing management specific aspects of telecom applications. They contain syntax and semantic rules, or references to such, which allow a detailed description of the network element being managed. The Interface Definition Language (IDL) is for example used for defining objects managed through Common Object Request Broker Architecture (CORBA). A subset of the Abstract Syntax Notation 1 (ASN.1) is used to define elements used in the Simple Network Management Protocol (SNMP). Alongside with a standard of describing these objects, often called Management Information Bases (MIBs), other models define the communication properties and the supported functionality of the protocol.

There is no one ideal standardized management protocol. Had this been the case, there wouldn’t be any need for the great efforts and large resources set-aside by the industry to develop these protocols. These efforts and resources have resulted in a vast choice of standardized protocols, with vendors offering a wide range of tools and platforms based on them. These tools and platforms greatly facilitate the development and integration of the management systems and network elements based on these protocols.

The choice of protocol is usually a trade off between complexity and simplicity. On one end of the scale, there are protocols whose aim is simplicity. They were developed to ensure easy agent implementation and short turn around time in software development. These protocols are better structured and easy to understand. Their simplicity, however, often requires extra functionality having to be inserted in the mapping of the information model, thus increasing its complexity.

On the other hand, there are protocols developed explicitly for the operation, administration, maintenance and provisioning of telecommunication systems. They contain a wide range of operations resulting in complex but powerful agents. The trades off in using these protocols are simpler applications that are easier to develop, shifting the complexity on to the agents.

An assessment of the strengths and weaknesses of each protocol candidate has to be made within the domain of the application. There may be scenarios where different management protocols should be combined within the same network element yielding the most powerful solution.

Management paradigms are under constant evolution. Early management systems were simple ASCII based ones, where a lot of the logic was placed in the network element. As this logic was slowly moved to the management system, proprietary management protocols were used for communication between the peers. They were later replaced by simple standardized management protocols such as SNMP, where more of the complexity and processing was moved to the manager. SNMP was intended as a transient protocol, and there were plans to replace it by the Common Management Information Protocol (CMIP), based on the work by the International Standardization Organization on Open System Interconnection (ISO/OSI). After a slow start, when products and tool kits finally had become available, so much had been invested in SNMP that migration plans had to be abandoned. Furthermore, CMIP proved to be far too complex both as regards to agents and management systems. Resources were instead concentrated on the coexistence of the two.

After CMIP, CORBA gained popularity. This popularity was due to its abstraction, hiding CMIP’s complexity and introducing communication transparency. SNMP has also continued to grow, and there seems to be a tendency in network management to migrate back to simpler protocols and managers. Proprietary web based management has for example gained wide acceptance, opening for a comparison to the early ASCII based systems. 

Efforts were originally placed on developing new management paradigms. They have now shifted to facilitating the coexistence of these paradigms. This provides a uniform integration of old and new management systems and NEs.

When discussing open network management, two vendor independent approaches are taken. They are referred to as Open System Interconnection (OSI) based management and the Internet Protocol (IP) based management. Both approaches describe the inter-process communication models, which in turn affect several aspects of the standardized management protocol definitions.

The OSI reference model defines 7 layers that serve as a basis for the specification of services and protocols. The layers include the physical, data link, network, transport, session, presentation and application layers. Interaction between entities of adjacent layers is strictly controlled, being based on interfaces, but horizontal communication between layers of the same level is open. All errors are for example handled horizontally among the peers, not involving the other levels.

The OSI model achieved wide relevance when the International Communication Union (ITU-T) started using the concepts as a basis for the Telecommunication Management Network (TMN) architecture. This acceptance was however greatly delayed due to political reasons (see [Rose, 1994]), giving IP based network management a new renaissance.

The IP based protocols originated in the 1970s with the ARPA network. Their breakthrough came when they made a component of Berkeley UNIX. Standards are agreed on by the Internet Activities Board (IAB) through request for comments (RFCs), which are agreed or rejected by the committee. Layers 1 – 4 map to the OSI model, while layers 5 – 6 are encapsulated by application specific protocols based on Transmission Control Protocol (TCP) for connection based protocols and the User Datagram Protocol (UDP) for connectionless based protocols.  TCP and UDP are in turn based on IP. Examples of TCP and UDP based protocols described in RFCs include TELNET (RFC 854), the Simple Mail Transport Protocol (SMTP), SNMP and HTTP. For a complete list, see [WEB].

The main difference between OSI and IP is that every RFC has to be submitted together with a prototype implementation. This ensures that the RFC specifications will not specify hard to implement features. This does not apply to OSI, resulting in the concourse often being true for such standards.

When comparing management protocols, [Hegering and Abeck, 1994] divided up their properties into four types of features. They include the communicational, informational, functional, and organizational models. The properties of these models should be considered alongside the acceptance of the protocol in the domain of the application, and the availability of tools and platforms supporting it.

The communication model deals with the exchange of information across the network. It looks at issues such as scope, reliability and encoding. Reliability can for example include facilities for detection of lost datagrams, and issues on where this functionality is to be inserted if it is not available through the protocol. What is the size of the datagrams in relation to the data exchanged, and is the protocol using a connection based or a connectionless underlying protocol? What type of encoding is used, and how does it affect efficiency are other issues of major importance which should be considered.

The information model deals with the description of the resources to be managed. What type of methodology is connected to the protocol? Is it intended to be used within an object oriented paradigm, a variable based one, or none at all? It looks at the state model for the entities represented how they can be described, and what functions may be applied on them. Most important in the information model is how the physical and logical abstraction is achieved.

The functional model specifies the functionality supported by the protocol. It includes means to handle the lifetime cycle of the managed entity as well as functionality to support specifications for testing, administration and maintenance of the entity. Some protocols have a minimal functional model, where the complexity is instead relocated to the logical description of the managed entity in the information model. The major areas covered within the telecom world include the provisioning, performance and fault management, accounting and billing, as well as security aspects.

The organizational model describes the different roles of the systems involved, namely the manager agent paradigms together with the variations allowed by the protocols. The model may include proxies and agents acting as managers, and the hierarchy created thereof.

There is a growing tendency to use simple protocols in systems which until recently were managed by more complex ones. This also applies to applications where existing network elements already support these protocols. Mapping technologies between protocols have been developed and reached the maturity of allowing management systems to handle a diversity of network elements using a variety of protocols. [Clemm, 1996], when referring to SNMP, believes that another reason is the rich variety of generic tools available for simpler protocols. Such tools would be too hard to develop for more complex protocols should their generic properties be maintained. 

The choice of protocol is directly correlated to the choice of information model. Some protocols have no explicit information models. The information model is integrated in their function, representation and communication models. Other models represent the managed entity in terms of variables grouped together, abstracting away from the physical world. Object oriented paradigms are also used to logically abstract the network element, specifying inheritance and containment properties between the managed objects.  

There are two types of information models. The proprietary models are vendor specific interfaces. The standardized models are agreed on and adapted by the industry. In early stages of development, and possibly in the first versions of the product, information models have not been standardized, and are under constant evolution. Inconsistencies can be found and fixed or functionality not supported by the protocol may be added.

The software has to be designed in a way that easily allows these changes. Whenever possible, the information model should as closely as possible relate to the internal state and data representation of the managed entities in the software. Attempts, however, are often made at early stages of the development to create abstractions and local optimizations of the model, thus affecting the software architecture. Abstractions and protocol specific optimizations should occur only when the product evolution has stabilized, or when the information model is replaced with a standardized one.

The need of standardization is expressed by the effort made by the industry to define the management information to be exchanged. Standardized information models relating to specific protocol leads to openness, allowing products developed by different vendors to be combined or interchanged with each other. All commonly used standardized management protocols have standardized MIBs, but it is common that MIBs that are standardized for one protocol have not been standardized for another. In order to use tools developed for standardized MIBs within the area of the product, the product might have to support more than one protocol.

The Internet Activities Board has several working groups providing standardized MIBs on network technologies and components. These MIBs are often based on other existing standards derived by organizations such as IEEE or ETSI.  There are also specific organizations such as the ATM forum, which define MIB definitions for devices supporting the Asynchronous Transfer Modes, or the ADSL forum, which, define MIBs for devices supporting Asymmetric Digital Subscriber Lines.

Whenever a standard appears in the area of the application of the managed entity, it should be supported on the network element side in order to allow the usage of tools and management systems based on these standards.  This is however not the same as saying that the management system being developed for this particular resource must be adapted to follow the standard. It is possible that the proprietary information model available is more effective towards the specific network element implementation, and as long as there are no plans on using the management system on managed entities developed by other vendors, there should be no reason to change it.  

The choice of tools available for a specific standardized protocol plays a major role in the choice of the protocol to deploy within the system. According to [Hegering and Abeck, 1994], tools written to coexist with standardized management protocols support three tasks. They are data collection, data reduction and analysis, and performance prediction. The wide range of tools available for network elements supporting SNMP was one of the major factors contributing to SNMP’s success. If a network device supports a standardized SNMP MIBs, there will almost certainly be a ready built management system to handle them. Would the same apply to other management protocols?

It is possible that customers have a legacy system for accounting and billing and want to continue using it with newly acquired products offering new services. It is also possible that they have other tools for performance monitoring and statistical analysis that can be reused if the new device supports the specific protocol. Often, these tools provide a base on which the proprietary aspects of the management system can be developed and used alongside the already provided standardized one. Another factor influencing are the existing tools providing functionality in the requirements that would be cheaper to buy or license than to develop from scratch. Tools are also temporarily used awaiting more complex ones that are developed within the project.

General system requirements contain issues that are often referred to and solved in the requirement specification of the product being developed. If the technology being implemented is young and on the rise, requirements are bound to change during the development phase. Customer requirements might affect the system specification as well. Would it in that case be wise to wait with the insertion of the standardized management protocol until the requirements can be considered stable, replacing it with a proprietary interface? Or is there a protocol which when used and changed minimizes impacts to the already developed software, and possibly provide the designers with the needed flexibility?

There are cases where a new product has to be adapted to the individual needs of a readily existing management system. This would thus involve the ability of implementing the NE specifics in accordance with proprietary information models supplied by the customer or provide a mapping with the protocol and information model used. Is the standardized protocol being chosen the right one to provide this flexibility?

What are the typical requirements of a management system? Just like in standardized protocols, they can be divided into communicational, informational, functional, and organizational requirements. These requirements, however, do not implicitly deal with the underlying implementation. They focus more on how the management system is perceived by the operator using it. The choice of standardized protocol will directly affect the implementation of these requirements.

The communicational requirements consider response time, security on open networks, and ease and reliability to communicate with the managed entities. Functional requirements deal with what operations are available, and the ease of applying these operations. Will the system automatically attempt to fill in default values or derive values not entered, or must every parameter be specified?  Informational requirements involves the needs of how feedback on the system is displayed, how performance monitoring graphs are set up, or on how detailed the information on the states of the managed entity has to be. The organizational model concerns how the whole system is displayed to the user, either in its physical or logical representations.