XML Management Protocol

From Krupczak.org
(Redirected from XMP)
Jump to: navigation, search
Download Now



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 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 implementers. Textual conventions pose 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 also added 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.

The XMP SMI continues to have both scalar and tabular MIB objects. However, inheritance and other complexities (ala Common Information Model) are strictly avoided.

Management Protocol

Message Types

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 of today's computer and networking hardware.

In order to make XML parsing more deterministic, each XMP message is prepended with a 32-byte wire header which consists of a 4 ASCII-character XMP version field, a 12 ASCII-character field containing a base-10 length, and 16 ASCII-character authenUser field. The length field tells the receiver how long the following XMP PDU is in octets while the version field future-proofs the protocol, and the authenUser field provides for protocol-engine processing of coarse-grained MIB views and access-control.

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

Message types borrowed from the SNMP include:

  • Response sent in response to both scalar and tabular queries.
  • GetRequest sent by a manager to obtain the values of scalar variables.
  • SetRequest sent by a manager to modify the values of scalar variables.
  • Trap sent by an agent to notify a manager of the occurrence of some event.
  • Information sent by an agent to a peer or manager to convey un-solicited information.

We have introduced new message types for table operations:

  • SelectTableRequest sent by a manager to perform a Select operation on a MIB table. Using this operation with key * is roughly equivalent to walking a MIB table in the Internet Management Framework. Using SelectTableRequest, however, will result in a consistent view of the table because the agent will lock the table during message processing. With SNMP MIB table walks, the manager is not guaranteed to get a single, consistent view of the MIB table. That is, by the time the SNMP manager is done walking a table, rows obtained during the walk are not guaranteed to have ever simultaneously coexisted in the table.
  • InsertTableRequest sent by a manager to perform an Insert operation on a MIB table. Using this operation avoids the whole RowStatus textual-convention fiasco associated with creating MIB table entries using SNMP.
  • DeleteTableRequest sent by a manager to perform a Delete operation on a MIB table. Again, using this operation avoids deleting rows as a side-effect of an SNMP Set operation using the RowStatus textual convention.
  • UpdateTableRequest sent by a manager to perform an Update operation on a MIB table.

As one can see, 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? Still another major difference from the SNMP is the complete lack of GetNext operation. In XMP, a GetNext operation is simply not needed -- performing SNMP GetNext operations yields very little additional information and no additional semantics.

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.

Instance Identifiers

For scalar MIB objects, no real instance identifier is needed. Since MIB tables are modeled as relations in the XMP, 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.

Management Information

The third component of any management framework is the definition of management information. For XMP, we again borrowed heavily from the Internet Management Framework.

We eliminated the use of numeric object identifiers (e.g. and have flattened out the global management object naming tree. Management objects are denoted using the tuple MIB-name, object-name, instance-name -- an object name is thus denoted as the concatenation of each element in the tuple separated by a period '.' For example, the MIB-2 object ifInOctets for interface eth1 would be denoted as mib2.ifInOctets.eth1. When referencing scalar MIB objects, one can drop the instance name thus the MIB-2 object sysDescr becomes simply mib2.sysDescr.

Within the global management information naming tree, MIB names must be unique. Within a single MIB, MIB object names must be unique. Beyond that, there are no other restrictions.

Re-use of Existing MIBs

We re-use many Internet MIBs including standard MIBs (e.g. MIB-2 and Interfaces Group MIB) and the private-enterprise MIB construct (e.g. Krupczak.org is assigned enterprise ID 16050). We utilize the Internet Management Framework's enterprise-ID naming schema merely to preserve co-existence and the ability to implement a MIB in both the SNMP and XMP frameworks. In XMP, however, private-enterprise MIBs are not referenced via their enterprise-OID but rather their MIB name. For example, MIB objects in the Krupczak.org private-enterprise MIB are not referenced via an OID but by the MIB name cartographer concatenated with the object-name and optional instance name (e.g. cartographer.pluginVersion)

XMP-specific MIBs

There are no real XMP-specific MIBs per se. There is, however, a base core MIB for XMP protocol engines which defines MIB objects specific to the XMP protocol. However, there is nothing about these MIB objects that is incompatible with SNMP. For example, the core MIB defines a series of protocol counters much like the SNMP group does in MIB-2.

Encapsulation in SSL/TCP

XMP utilizes SSL (more specifically SSLv3 and/or TLSv1) for privacy and authentication. Cartographer utilizes its own certificate authority to create and sign X509v3 certificates. Each Cartographer agent and query tool embeds a certificate authority for the creation of its own certificate thus obviating the administrative overhead of managing certificates. That is, the first time a Cartographer agent is started, it creates and signs its own certificate for use when communicating with other XMP entities. All XMP entities validate X509v3 certificates using the Cartographer CA cert, but only agents must present valid X509v3 certs. Managers, de-emphasized in the Cartographer model, may present certificates but are not required to. All agent-agent communication requires authentication thus both must present valid, signed Cartographer certificates.

SSL certificates are stored in PEM format in the installation directory with the filename xmpd.pem for agents. The Cartographer certificate authority private/public keys and certificate are stored in the file cartographer.pem. Command-line tools store their certificates in a file toolname.pem. If an XMP entity is unable to find its certificate authority information, it will not run.

XMP has been assigned an reserved TCP port and has been assigned TCP/UDP port 5270.

XMP PDUs are pre-pended with the (previously-defined) wire header prior to transmission via SSL and TCP.


XMP has been implemented in C and Java. The protocol has been implemented on Windows NT 5+, various Linux distributions, and Solaris 64-bit/Sparc and 32-bit/i386.

An XMP adapter has also been written for use with MRTG.

Integration with OpenNMS is ongoing and included in their current release. The first revision includes a data collector for XMP.

See Distributions for source code and binary distributions for the various platforms and releases.

Example PDUs

Simple GetRequest:

  <?xml version="1.0" encoding='US-ASCII' ?>
  <xmp xmlns="http://xmlns.krupczak.org/xsd/xmp-1.0" message-id="1234">
         <varvalue vartype="nullSyntax"/>


  <?xml version="1.0" encoding='US-ASCII' ?>
  <xmp xmlns="http://xmlns.krupczak.org/xsd/xmp-1.0" message-id="1234">
        <varvalue vartype="displayString">Linux 2.4.20-28.9 i686</varvalue>


  <?xml version="1.0" encoding='US-ASCII' ?>
  <xmp xmlns="http://xmlns.krupczak.org/xsd/xmp-1.0" message-id="123456">
          <varvalue vartype="nullSyntax"/>

Example Wireshark and Tcpdump filter expressions to capture XMP packets.

  • tcp port 5270 - capture all XMP traffic that is seen.
  • host w.x.y.z and tcp and port 5270 - capture all XMP traffic to/from host w.x.y.z.


Personal tools