When the SNMP Master Agent receives a request it determines whether the object is within the subtree registered the mapper. If it is, it then sends the mapper an SNMP request. Upon receiving a packet, the mapper parses the packet according to the following types:
GET
GETNEXT
SET
Conversion of an SNMP request to DMI is shown in Table 6-1.
Table 6-1 SNMP Request to DMI Conversion
SNMP |
Object |
DMI |
Data |
---|---|---|---|
{verb} |
{noun} |
{verb} |
{noun} |
get |
OID |
MI_cmds |
ID and Key |
getnext |
|
|
comp ID/group ID/attr ID |
set/commit/undo |
|
|
|
Access to the MIF database is enabled through a set of MI commands used to query for lists of components, groups or attributes, and to Get or Set the individual attributes.
When the mapper receives a GET request from the Master Agent, the mapper:
Determines whether the request is for the MIF or MIB, depending on whether it finds an entry in the translation table.
Parses the remainder of the OID, checking for validity.
Searches the translation table for presence of the specified group and component.
Translates the DMI table index (if specified) in the OID into a DMI key format.
Attempts to retrieve the object value from the DMI. The subagent then gives the object value returned to the agent.
In processing GETNEXT requests, the subagent must make certain that lexicographical ordering is maintained. The MIF database may undergo considerable searching before arriving at the attribute returned as an SMI object. If the value of the target attribute is unavailable because of a minor error (for example, specific to that attribute), a genErr prescribed by /RFC1448/ is returned. If the next object is not in the subagent's tree, the same object instance as in the request is returned and the value noSuchName is returned.
DMI attribute identifiers are encoded into unique OIDs. The INDEX clause is used to access DMI table objects and identifies a DMI table row. When DMI table attributes are examined during a GETNEXT, all row identifiers (key values) are examined to insure lexicographic order.
Handling of the SET request by the Master Agent is a bit more involved than the GET request. The normal command sequence is a GET followed by a SET command from the agent. In the event the agent may not successfully complete all the SETs for a given SNMP PDU, it sends the subagent another SET command with oi.d values obtained from the GET command. When it receives the SET command, the subagent makes some basic checks, such as confirming existence of the object and instance, correct value type, valid contents, and availability of memory needed for the operation. At this point, the call to the DMI with a DmiSetAttribute() to RESERVE the attributes is complete. The RESERVE is used to validate a SET without performing the SET. A RESERVE failure results in a genErr being returned to the Master Agent. Otherwise, the subagent performs DmiSetAttribute() with the SET option, to perform the actual set.
If another subagent has informed the SNMP agent it may not perform the SET of that PDU, the agent then gives a SET to this mapper, with older values.
The Master Agent enables the mapper to report traps to the agent by building a Master Agent trap PDU and sending it to the agent.
The trap is caused by an unsolicited message known as an INDICATION from the DMI SP. If these indications are from the component, they are called events. The mapper receives all indications after it has subscribed to the SP by adding an entry into its subscription table. The mapper also sets the filter conditions for receiving every type of event. Because the mapper is already waiting for requests from the agent, this routine is a separate thread. The subagent determines what OIDs are sent with the trap. The following list describes the different types of indications.
DmiDeliverEvent This indication is generated by the component. The SP passes it to all the MI applications having their valid entries in the subscription and filter tables maintained by the SP. The snmpXdmid mapper matches the OID prefix to the component ID, generating the event for building the TrapOID. The groupId and attributes are also part of the event. The snmpXdmid mapper uses all relevant information in the event (apart from the OID prefix itself) to generate the TrapOID. The snmpXdmid generates a SNMP-specific trap, with specific trapID=14.
DmiComponentAdded This indication is generated by the SP when a new component is registered. New components may be registered for existing .MAP files or for a totally new .MAP file. When this trap is received by snmpXdmid, it unregisters all the registered OIDs in the Master Agent, rereads all the .MAP files, and then goes through the process of reregistering all of the OIDs with the Master Agent. This helps to keep the subagent translation tables in sync with the .MAP files, especially since the .MAP files are generated external to the mapper. The mapper then generates an SNMP-specific trap with trapID = 7.
DmiComponent-Deleted This indication is generated by the SP when an existing component ID is unregistered with the SP. The snmpXdmid mapper modifies the translation tables upon receiving this indication. By default, it generates an SNMP trap with trapID=8.
DmiLanguageAdded This indication is generated by SP. It results in an SNMP trap with trapID=9.
DmiLanguageDeleted This indication is generated by SP, resulting in an SNMP trap with trapID=10.
DmiGroupAdded This indication is generated by SP when a new group is registered with it under a component ID. This results in the updating of translation tables in snmpXdmid. An SNMP trap is generated with trapID=11.
DmiGroupDeleted This indication is generated by the SP when a group is unregistered with it. This results in the updating of translation tables, and an SNMP trap is generated with trapID=12.
DmiSubscriptionNotice This indication is generated by the SP under two circumstances:
When the management application subscription for indication hits the warning timestamp. A flag indicates the warning aspect of the indication. An NMP trap with trapID=15 is generated.
When the management application subscription for indication hits the expiration timestamp. An SNMP trap with trapID=16 is generated.
Normally, the snmpXdmid daemon runs forever, unless explicitly killed or a disastrous situation is encountered (for example, lack of memory).
The mapping of MIF to MIB involves the assignment of an OID from the MIF. A translator (miftomib.EXE) is available to build a file extension of .MAP and a .MIB file from a MIF definition. The translator may be used as a tool to generate the .MIB and the .MAP files. Or, the map file may be generated manually, using a text editor. All .MAP files located in the directory under /var/dmi/map are scanned and included in the subagent translation table.
The map file format is shown in Table 6-2.
Table 6-2 Map File Format
OID Prefix |
Component Name |
---|---|
"1.3.6.1.4.1.42.2000.2" |
"Client Access/400 Family - Base Product" |
The design approach is to map the DMI component ID, group ID, and attribute ID to MIB object IDs. The managing entity must predetermine the MIB definition to be used by the mapper to map to the MIF definition. Using a miftomib translator to produce the MIB mapping file facilitates the mapping.
The map file is generated externally to the mapper. A mechanism is required to notify the mapper of new or updated files on the system in order to enable the new MIF definitions to be dynamically added. This is accomplished by using the DmiGroupAdded indication, delivered by dmispd, when the mapper rereads all the .MAP files.
See Figure 6-3 for examples of the OID prefix and the completed OID layout. The mapping file is used by the mapper to register the OID with the SNMP agent relay and to correlate the OID with the component name. It contains the component ID and the group keys, in case the group contains tabular data.
The mapper puts no restriction on what the OID prefix may be. That is controlled by the network administrator. Any OID may be entered into a .MAP file, provided the SNMP Master Agent allows the subtree registration. In the case of failure, the .MAP file needs to be changed for the OID correction.
Parts of the object identifier are shown below:
Object Identifier: OID-prefix: 1.3.6.1.4.1.42.2000.x
OID for Groups: .1
Object-type for Table: .iGroupID
Object-type for Row: .1
Attribute Identifier: .iAttributeId
Instance Identifier: Indexes: .iComponentId <keys>
The example in Table 6-3 shows OIDs for client access attributes (no keys).
Table 6-3 OIDs for Client Access Attributes
Object Identifier: OID-prefix |
OID for Groups |
Object-type for Table |
Object-type for Row |
Attribute Identifier: Object-type for Column |
Instance Identifier: Indexes |
---|---|---|---|---|---|
1.3.6.1.4.1.42.2000.x |
.1 |
.1 |
.1 |
.1 |
.3 |
Retrieving objects via the GetNext operation must be specially handled, since MIB tables are traversed column-by-column and MIF tables are traversed row-by-row.
The DMI specification has reserved ComponentId=1 for the DMI SP. The specification also defines the MIF file for the SP. The network administrator must take this into consideration when creating the .MAP files or when specifying the OID preference as a command-line parameter to the miftomib utility. Every MIF file must contain a standard group with ID 1.
Table 6-4 ComponentID Group Translated to DMI MIB
MIS Object Identifier and SYNTAX |
MIF Data |
Description |
Notes |
---|---|---|---|
DMIcompindex INTEGER (1...217483647) |
Component ID |
Unique value for component |
Assigned at installation by the SP, it communicates with this component until uninstalled; managing applications record this ID to request attributes later |
DMIcompManufacture DisplayString (0...64) |
Attribute "Manufacture" |
Value assigned by the component provider |
The name of the organization that produced this component |
DMIcompProduct DisplayString (0...64) |
Attribute "Product" |
Value assigned by the component provider |
Name of the component |
DMIcompVersion DisplayString (0...64) |
Attribute "Version" |
Value assigned by the component provider |
Version of the component |
DMIcompSerialnumber DisplayString (0...64) |
Attribute "Serial Number" |
Value assigned by the component provider |
Serial number of component |
DMIcompInstallation Date |
Attribute "Installation" |
Value assigned by the SP at installation time |
28-octet displayable string composed of date and time |
DMIcompVerify Integer (0...7) |
Attribute "Verify" |
Verification level of this component at installation time |
A request for this attribute causes the component to find out if it is still in the system and working properly |
With this mapping, any MIF that is installed with the DMI has at minimum the ComponentID Group visible to management applications. All attributes within this group have read-only access. As MIFs become standard and are translated into MIBs, they become accessible but have additional anchor points in the DmtfGroups tree. For example, if the software MIF were defined, the translation would provide a DMISW MIB and be anchored as follows:
enterprise.sun.DmtfGroups.DMISW(2)
or
1.3.6.1.4.1.42.2000.3
Managing applications must be prepared for the same component to be visible in two different branches of the DmtfGroups tree.
Additional OID prefixes: