Previous section.

Inter-domain Management: Specification Translation

Inter-domain Management: Specification Translation
Copyright © 1997 The Open Group

Mapping of SNMPv2 Information Modules

Lexical Translation

The lexical translation for the ASN.1 character set and identifiers follow the rules defined in the ASN.1->IDL translation document ( ASN.1 Type to CORBA-IDL Translation ).

The suffix "Type" is added to all types generated from the ASN.1 types and the SYNTAX clause of the OBJECT-TYPE and TEXTUAL-CONVENTION macros defined in a SNMPv2 Information module.

Names and IDL Modules

Standard Files for Specification Translation

The specification translation assumes the existence of the following files:

ASN1Types.idl
contains the base definitions for translating ASN.1 types (see IDL Modules for Builtin ASN.1 Types ).

SNMPMgmt.idl
contains the definition for base IDL interface for SNMP groups or Tables; it also contains the IDL types for untyped event communication and interfaces for generic typed event communication.

Contents of SNMPMgmt.idl file
The SNMPMgmt.idl file contains the definitions for the base interface for the IDL interface for SNMP groups or table-entries. The base interface is called SmiEntry and defined within the module named SNMPMgmt. The IDL interface for SmiEntry is defined in SNMPMgmt.idl File .

This file also defines IDL type for untyped event communication and interfaces generic typed communications (both push and pull style). The structure for untyped event communication is defined from NOTIFICATION PDU format. The parameters of the operations of interfaces for typed communications are also derived from NOTIFICATION PDU format. The types and interfaces are defined in SNMPMgmt.idl File .

Mapping of Module Definition

The DEFINITIONS/BEGIN statement is used to start an SNMPv2 information module in the following format:
<module-identifier> DEFINITIONS ::= BEGIN
    <macro-instances>
END

The DEFINITIONS statement is mapped to IDL as follows:

module <module-name> {
       <idl-mapped-macro-invocations>
};
where <module-identifier> is mapped as an ASN.1 identifier as defined in ASN.1 Type to CORBA-IDL Translation . The END statement at the end of the information module is mapped to the closing brace and semi-colon for the IDL module.

The SNMP->IDL compiler-generated IDL file follows the following rules:

Naming of the IDL File Output

The <module-identifier> is used to name the IDL file generated by the SNMP->IDL compiler. The file name is formed by concatenating .idl to the <module-identifier>.

Mapping of IMPORTing Symbols

In SNMPv2 information modules, the IMPORTS statement is used to reference an external object by identifying both the descriptor and the module defining the descriptor, in the following format:

IMPORTS <descriptor1> [, <descriptor2 ... [, descriptorn] ] FROM <module-name>
Descriptors which are not macro references or macro descriptors in the IMPORTS statement are declared within the scope of the IDL module by way of typedefs as defined in Mapping of Imports , yielding the following IDL:

typedef <module-name>::<descriptor1>Type <descriptor1>Type;
typedef <module-name>::<descriptor2>Type <descriptor2>Type;
 ........
typedef <module-name>::<descriptor1>Type <descriptor1>Type;
Note the addition of the Type suffix to all types that are defined in another module. Since base ASN.1 types are assumed to be globally defined and they are not explicitly imported, the rule is always consistent.

If there are no IMPORTS ... FROM statements in the SNMP module, then the following include directives will be added at the beginning of the file:

#include <ASN1Types.idl>
#include <SNMPMgmt.idl>
in order to include the global ASN.1 types and base IDL interface.

Each FROM <module-name> will map to an include statement at the beginning of the file as follows:

#include <<module-name>.idl>
If there is at least one imported module then it is not necessary to explicitly import the standard IDL files.


Example

By way of example, the following definition in RFC1450:
SNMPv2-MIB DEFINITIONS ::= BEGIN
IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    ObjectName, Integer32, Counter32, snmpModules FROM SNMPv2-SM
    TruthValue, DisplayString, TestAndIncr, TimeStamp FROM SNMPv2-T
    MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CON
    system, ifIndex, egpNeighAddr FROM RFC1213-MIB
    partyEntry FROM SNMPv2-PARTY-MIB;
    ....
END

maps to following definition in a file named SNMPv2_MIB.idl:

#ifndef SNMPv2_MIB_IDL
#define SNMPv2_MIB_IDL
#include <SNMPv2_SMI.idl>
#include <SNMPv2_TC.idl>
#include <SNMPv2_CONF.idl>
#include <RFC1213_MIB.idl>
#include <SNMPv2_PARTY_MIB.idl>

module SNMPv2_MIB {
// MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE are ignored
typedef SNMPv2_SMI::ObjectNameType ObjectNameType;
typedef SNMPv2_SMI::Integer32Type Integer32Type;
typedef SNMPv2_SMI::Counter32Type Counter32Type;
// snmpModules is macro descriptor so it is ignored
typedef SNMPv2_TC::TruthValueType TruthValueType;
typedef SNMPv2_TC::DisplayStringType DisplayStringType;
typedef SNMPv2_TC::TestAndIncrType TestAndIncrType;
typedef SNMPv2_CONF::TimeStampType TimeStampType;
// system, ifIndex, egpNeighAddr are ignored because they are macro-descriptors
// partyEntry is ignored because its is macro-descriptor
 ........
}; /* End of SNMPv2_MIB module */
#endif /* !SNMPv2_MIB_IDL */

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index