Difference between revisions of "XML Management Protocol"

Revision as of 15:30, 6 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 impacting the others. This change is essentially what we have done with XMP as we have borrowed heavily from the Internet Management Framework's SMI and defined body of management information but have changed the management protocol.

Basic Architecture

Overall communication in XMP, and the layers of encapsulation, are depicted in the following figure.

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.

XML Data Description and Transfer Syntax

First, XML is used for both data description and transfer syntax. 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.

SMI Type Enhancements

Second, we did away with numeric object-identifiers (OIDS) and instance-identifiers (e.g. 1.3.6). 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 network interface is 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.

Third, we added several data types and promoted several textual-conventions. All numbers are potentially 64-bit. With BER in the IMF, changing a number from 32-bits to 64-bits causes a huge impact because both the SMI and protocol implementations much change. With XML, a longer number is simply transmitted with the implementation being the only component that is potentially impacted.

In the Internet Management Framework, additional semantics are added to base data types through the use of textual conventions which are then treated as quasi-types by MIB specifications and implementors. Textual conventions post several problems. First, they are specified in natural languages (e.g. English) so they are difficult for computers to process on the fly. Second, they are not technically part of the standard unless they are included in the specification (for example, vendor textual conventions are thus not covered). Third, they add semantics through overloading which usually results in poor engineering. One may correctly argue that it is a semantic shell game -- whether semantics are specified by types or by type overloading still requires human involvement to understand the specific semantics. However, specifying the semantics via types (as opposed to textual conventions) results in a specification that is easier to understand and code. For the XMP SMI, we promoted several textual conventions to standard type. Textual-conventions for boolean, IPv6, physical addresses, MAC addresses and date/time stamps were all promoted from textual-convention to standard type.

We added types for IPv6 addresses, and floating points. Further, we added a nullSyntax type meant to specify no value or no syntax for a given MIB object thus eliminating confusion over the validity of an object value. We aalso dded an extendedBoolean type which lets the agent communicate the values true, false, and unknown. We also added the type unsupportedVariable so that an agent could communicate that a particular MIB object was not supported yet could still answer queries about it. Adding these last two types allows an XMP agent to avoid the cardinal sin of network management which is returning a value for a MIB object that it either does not support or for which it really does not know the value of.

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

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.