Difference between revisions of "XML Management Protocol"
(→Message Formats and Syntax) |
(→Message Formats and Syntax) |
||
| Line 37: | Line 37: | ||
(Compare the above approach with that used when parsing ASN.1/BER to show why this is more efficient.) | (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 ''*''. | ||
== Implementations == | == Implementations == | ||
Revision as of 11:45, 1 April 2007
Contents |
Overview
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.
Data Description and Transfer Syntax
Message Formats and Syntax
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 *.
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.
