Choosing a Configuration Protocol
Choosing between COBRA, XML, and SNMP is not simple even if you have decided to use a standardized technique rather than one of the proprietary configuration mechanisms built into your equipment. SNMP is well established, with MIB modules designed within the IETF, often by the people who wrote the protocols that are being managed. The MIB modules offer a great deal of detail and fine control, but to some extent this is a downfall since the level of detail increases the apparent complexity of a MIB module for the reader or the implementer. The argument is often made that MIB modules are too complex and are consequently hard to understand. In the end, the amount of information that needs to be managed is static regardless of the protocol used to manage it; there is a constant amount of information needed to control and operate a device no matter how that information is transferred to the device. This means that discussions about the quantity of managed data are bogus and all that remains to be considered are the encodings and protocols.
XML provides an encoding technique that is at once easy to extend, readable by a human, and easy for a program to parse. Its downside is that its very readability makes it verbose, although compression techniques in the transport protocol may help to ameliorate this. XML is unquestionably easy and quick to develop and for this reason it is beginning to gain considerable popularity.
COBRA has an established foothold, especially with the larger service providers where the structured management network shown in previous Figure is popular. Since COBRA is so often a requirement as a northbound interface from EMSs, it may make sense to offer COBRA support on the managed devices. Note that COBRA is also popular with object-oriented programmers because of its inherent objectoriented nature and the ready availability of ORB components in C++ and Java.
SNMP remains the most-deployed network management protocol. Despite fears about security, SNMPv2 is widely used and MIB modules give a well-known and detailed breakdown of the configuration data. Although ASN.1 is initially hard to get into, with familiarity the text representation is easy to read and can be automatically parsed to generate management applications and source code for clients and servers.
Note that it is possible to mix and match. One option that is sometimes used is to maintain the configuration data in MIB format, but to transfer them as bulk data using COBRA or XML. This can avoid some of the security concerns of the earlier SNMP versions while continuing to use the detailed MIB modules.
In this tutorial:
- IP Network Management
- Choosing to Manage your Network
- Choosing a Configuration Method
- Command Line Interfaces
- Graphical User Interfaces
- Standardized Data Representations and Access
- Making the Choice
- Management Information Base
- Representing Managed Objects
- Simple Network Management Protocol
- Requests, Responses, and Notifications
- SNMP Versions and Security
- Choosing an SNMP Version
- Extensible Markup Language
- Extensibility and Domains of Applicability
- XML Remote Procedure Calls
- Simple Object Access Protocol
- XML Applicability to Network Management
- Common Object Request Broker Architecture
- Interface Definition Language
- The Architecture
- CORBA Communications
- Choosing a Configuration Protocol
- Choosing to Collect Statistics
- Policy Control
- Choosing to Apply Policy
- Policy Information Base