Difference between revisions of "XML Management Protocol"

Revision as of 08:23, 4 April 2007

Overview

While XMP is technically the name of Cartographer's management protocol, the acronym is usually used to describe the overall management framework. A management framework usually consists of several parts including:

• A structure of management information or SMI
• A management protocol
• Management information

In theory, if a management framework has been properly designed, any one of the three components can be changed without unduly breaking the others. This changing is essentially what we have done with XMP as we have borrowed heavily from the Internet Management Framework but changed the management protocol.

Basic Architecture

Entities acting as managers initiate communication with agents. Manager closes session when finished.

Structure of Management Information

The Structure of Management Information or SMI defines the syntax and semantics of management exchanges. For XMP, we borrowed heavily from the Internet Management Framework SMI and only modified it in a few places. The Internet Management Framework's SMI is defined in several documents including SMIv1 and SMIv2.

We enhanced the Internet Management Framework SMI in several ways.

First, we did away with object-identifiers (OIDS) and instance-identifiers. We use the tuple of MIB-name, object-name, and instance-name to uniquely identify an item of management information. For example, the MIB-2 object ifInOctets for the first interface is can be represented by the rather obtuse OID 1.3.6.1.2.1.2.2.1.10.1. In the XMP SMI, the same MIB object would be represented by the object name mib2.ifTable.ifInOctets.if0.

We added several data types.

Object model changes -- XML used for both data description and transfer syntax. (See next section.)

Continue to have both scalar and tabular MIB objects. Inheritance and other complexities (ala Common Information Model) are strictly avoided.

Data Description

We use XML for both data description and transfer syntax thus simplifying the job of MIB design and implementation. What you see is all you got might be an appropriate quote to use.

In the Internet Management Framework SMI, ASN.1 is used for data description and BER is used for transfer syntax. In reality, XML probably offers little real advantage over ASN.1, but using XML for both data description and transfer syntax simplifies the interaction between an SMI and management protocol. Further, there are a plethora of tools, both commercial and open source, available for parsing and manipulating XML documents.

Message Formats and Syntax

XMP is connection-oriented and thus does not suffer many of the intricacies of the SNMP. The original arguments for the architecture of the SNMP were valid and appropriate for the time frame it was developed. However, today's computer systems (and even embedded networking equipement) have far more powerful processors, have more memory, and are cheaper than those devices of yesterday. Rather than continue to contort oneself to the economics of the 1980s, we decided to take advantage of the explosion in performance-to-price ratio.

Each XMP message is prepended with a wire header which currently consists of a 10 ASCII-character field containing a base-10 length. This length field tells the receiver how long the following XMP PDU is in octets. Prepending a wire-header allows the XMP receiver to more easily parse the XMP message using a single XML function call.

(Compare the above approach with that used when parsing ASN.1/BER to show why this is more efficient.)

Message types include:

• Response
• GetRequest
• SetRequest
• SelectTableRequest
• InsertTableRequest
• DeleteTableRequest
• UpdateTableRequest
• Trap

The most notable changes, from SNMP, include the addition of SQL-like table operations. SNMP table operations are cumbersome, confusing, difficult to implement, and error-prone. Since tables are modeled as relations in the SNMP, why not apply relational database table operations?

Another major difference from the SNMP is the complete lack of GetNext operation. In XMP, a GetNext operation is simply not needed. For scalar MIB objects, no real instance identifier is needed. Since MIB tables are modeled as relations, it makes sense that their instance identifiers are their respective relation keys. Keys may be numbers (e.g. an index), strings, etc. Finally, since there is no implicit ordering of MIB objects (because numeric object identifiers are not used), there is no use for a GetNext operator. In practice, not having a GetNext operator greatly simplifies table implementation.

How does one walk a table then? A management application can obtain all rows in a table by simply performing a SelectTableRequest with key *.

How does one walk a MIB then like one does with SNMP? The XMP does not support this. In practice, walking a MIB gave only syntactic information, not semantic. Without semantic information, the results of a MIB walk are of dubious value anyway. Intelligent management applications have to know the semantics of the management information they are dealing with thus they must know the semantics a prior. Finally, MIB walks were useful for discovering the contents of SNMP tables. However, those SNMP MIB walks can introduce race conditions since a table may change while its being walked. In XMP table implementations, the table is locked while SelectTableRequest, InsertTableRequest, DeleteTableRequest, and UpdateTableRequest operations are being performed thus the they return a consistent view of tables.

Implementations

XMP has been implemented in C and Java. Bindings for Perl are in the works. An XMP adapter has also been written for use with MRTG.

The acronym XMP and protocol should not be confused with the IETF XMPP Extensible Messaging and Presence Protocol.