Previous section.

Book 2: Inter-Domain Management: Interaction Translation (JIDM_IT)
Copyright © 1999 The Open Group

SNMP Management Facilities

Overview

The SNMP Management Facilities chapter addresses the bidirectional mapping of names, messages and events in SNMP domain to names, operation invocation and events in CORBA domain, by providing a set of SNMP specific CORBA object services and extensions.

This is done by extending the JIDM Facilities specification by providing SNMP specific extensions to the generic JIDM manager-agent framework. Those facilities support functionality that is specific to SNMP Management:

In order to support the inter-operability between CORBA and SNMP domains, we have to develop a set of service interfaces, called SNMP Management facilities as an extension of some of the CORBA Object services specification. In addition, we take advantage of the generic manager-agent framework provided by the JIDM facilities, to initialize and find the services defined for the SNMP Management facilities.

The main purpose of the SNMP management facilities is to extend the CORBA object services to support SNMP protocol specific behavior of MIB entries/objects. For example, the SNMP MIB entries have to be named whenever they are created whereas CORBA objects need not be named when they are created. So, we have to standardize on the way objects are created and named.

The goal of the service interfaces to provide a uniform way to find MIB entries, retrieve information from MIB entries and handle events from CORBA and SNMP domains.

In the SNMP domain the MIB entries are named based on a set of well defined policies about the order and the types of the index variables associated with the MIB entries. The SNMP Naming service interface encapsulate SNMP specific naming behavior. The SNMP specific Life-cycle services interfaces extends the COSS generic factory to support the behavior of the MIB module specific factories generated during SMI->IDL translation. The SNMP specific Lifecycle would also take care of the naming of the MIB entries when a MIB entry is created.

There is some information loss during the mapping of SNMP MIB to IDL and we have to get it back through some mechanism. For example, OIDs of the table-entries/groups and variables are not mapped to IDL but they are needed at the gateway. So we need to extend the CORBA interface repository to provide OID information.

The SNMP Management Information Repository (also known as SMI repository service) is optional. It defines a set of interfaces that provide information about the SNMP specific IDL modules and interfaces in the InterfaceRepository (IR) in a SNMP specific way. For example, one can obtain information about SNMP specific IDL module names, SNMP specific IDL interfaces and SNMP specific variables among all IDL interfaces in the IFR. The view one get from the SMI repository is a SNMP specific view based on the information in the IFR. One can use the SMI repository to query about OID of a variable.

SNMPMgmt Module

The SNMPMgmt module (see SNMPMgmt Module) comprises a collection of interfaces that together define a basic set of services for developing SNMP Management Applications based on CORBA. This module contains the following interfaces:


Table: SNMPMgmt Module





#ifndef _SNMPMGMT_IDL_
#define _SNMPMGMT_IDL_
 
#include <orb.idl>
#include <CosPropertyService.idl>
#include <ASN1Types.idl>
#include <JIDM.idl>
 
module SNMPMgmt {
 
const string ManagementDomainKeyId = Internet Management;
const string ManagementDomainKeyKind = XSM environment;
const string ProtocolVer = Protocol Version;
const string TransportProtocol = Transport Protocol;
const string DomainTitle = Domain Title;
const string TransportAddress = Transport Address;
const string TransportPort = Transport Port;
const string CommunityName = Community Name;
const string ContextEngineID = Context EngineID;
const string ContextName = Context Name;
 
// Redefinition of types
typedef CORBA::ScopedName ScopedName;
typedef CosLifeCycle::Criteria Criteria;
typedef CosPropertyService::PropertyName VarName;
typedef CosPropertyService::PropertyNames VarNameList;
typedef CosPropertyService::Property NameValuePair;
typedef CosPropertyService::Properties NVPairList;
 
typedef ASN1_ObjectIdentifier EntryIndex;
typedef sequence < EntryIndex > EntryIndexList;
 
typedef string TAddress; // Transport address of an agent
 
enum ProtocolVersion { snmpV1, snmpV2c, snmpV3 };






// SNMP Protocol specific exceptions
exception ProtocolError {
ASN1_Integer error_status;
ASN1_Integer error_index;
};
exception MultVarProtocolError {
ASN1_Integer error_status;
VarNameList error_var_list;
NVPairList result_var_list;
};
 
// SMI information module specific exceptions.
exception NoSuchSmiModule { };
exception NoSuchSmiEntry { };
exception NoSuchVariable { };
 
// MIB entry specific exceptions
exception NoSuchHost { };
exception NoSuchObject { };
exception EndOfMibView { };
 
exception AlreadyExists { };
 
interface SmiEntry : CosLifeCycle::LifeCycleObject, CosPropertyService::PropertySet {
// the value of entry_name is always 0 for the groups.
readonly attribute ASN1_ObjectIdentifier entry_name;
};
typedef sequence < SmiEntry > SmiEntryList;
 
interface SmiTableIterator {
boolean next_one_entry( out SmiEntry smi_entry );
boolean next_n_entries (
in unsigned long how_many,
out SmiEntryList smi_entry_list
);
void destroy();
};
 
interface GenericFactory : CosLifeCycle::GenericFactory {
SmiEntry create_mib_entry (
in ScopedName t_entry_type,
in ASN1_ObjectIdentifier entry_index,
in Criteria create_criteria
) raises ( NoSuchSmiEntry, AlreadyExists );
 
SmiEntry create_mib_entry_with_auto_name (
in ScopedName t_entry_type,
in Criteria create_criteria
) raises ( NoSuchSmiEntry, AlreadyExists );
};






interface GetNextEntryIterator {
// Get the next entry index accroding to lexical ordering rule
// of SNMP OIDs -- follows SNMP get-next traversal rule
boolean next_one_entry ( out EntryIndex entry_index );
boolean next_n_entries (
in unsigned long how_many,
out EntryIndexList entry_index_list
);
void destroy();
};
 
// NamingContext extends CosNaming::NamingContext to provide
// navigating the SNMP name space in the lexicographic order
// and SNMP specific name and context resolution
 
interface NamingContext : CosNaming::NamingContext {
string get_next_entry(
in string entry_name
) raises ( InvalidName, NotFound, CannotProceed );
 
GetNextEntryIterator get_next_entry_iterator(
in string initial_entry_name
) raises ( InvalidName, NotFound );
};
 
interface NamingDirectory : NamingContext {
NamingContext resolve_domain_context(
in TAddress p_host_name
) raises ( NoSuchHost, CannotProceed, InvalidName, NotFound );
 
NamingContext resolve_smi_module(
in TAddress p_host_name,
in string p_smi_module_name
) raises ( NoSuchHost, NoSuchSmiModule, InvalidName, NotFound );
 
NamingContext resolve_smi_entry(
in TAddress p_host_name,
in ScopedName p_entry_type
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );
 
SmiEntry resolve_mib_entry(
in TAddress p_host_name,
in ScopedName p_entry_type,
in string p_entry_index
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );






void list_smi_entries(
in TAddress p_host_name,
in ScopedName p_entry_type,
in unsigned long how_many,
out SmiEntryList out_list,
out SmiTableIterator table_iterator
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );
};
// ProxyAgent
 
interface ProxyAgent : JIDM::ProxyAgent {
 
readonly attribute TAddress host_name;
 
ASN1_Any get_a_variable (
in TAddress p_host_name,
in ScopedName p_var_scoped_name,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchVariable, NoSuchObject, ProtocolError );
 
NVPairList get_variables (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in VarNameList p_var_name_list,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, MultVarProtocolError );
 
void set_a_variable (
in TAddress p_host_name,
in ScopedName p_var_scoped_name,
in EntryIndex p_var_index,
in ASN1_Any p_var_new_value
) raises ( NoSuchHost, NoSuchVariable, NoSuchObject, ProtocolError );
 
void set_variables (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in NVPairList p_var_nvp_list,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, MultVarProtocolError );
 
void list_mib_entries(
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in long p_how_many,
out EntryIndexList p_entry_index_list,
out GetNextEntryIterator p_entry_name_list_itr
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, ProtocolError );






boolean mib_entry_exists (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name
) raises ( NoSuchHost, NoSuchSmiEntry, ProtocolError );
 
boolean is_mib_module_supported (
in TAddress p_host_name,
in string p_smi_module_name
) raises ( NoSuchHost, NoSuchSmiModule, ProtocolError );
 
};
 
struct EntryVarBind {
ScopedName entry_name; // IDL scoped name of the interface for table-entry
string entry_index; // row index of an entry in the form of ObjectId string
CosPropertyService::Properties nvp_list;
};
typedef sequence<EntryVarBind> EntryVarBindList;
typedef EntryVarBindList NotificationVariableList;
typedef EntryVarBindList InformVariableList;
 
struct NotificationInfo { // to be sent when using untyped event channel
CosNaming::Name src_entry_name;
ScopedName event_type;
ASN1_GeneralizedTime event_time;
any notification_info;
};
struct InformInfo { // to be sent when using untyped event channel
CosNaming::Name src_obj_name;
InformVariableList inform_info;
};
 
interface Notifications {
void snmp_notification (
in CosNaming::Name src_entry_name,
in ScopedName event_type,
in ASN1_GeneralizedTime event_time,
in any notification_info
);
void snmp_inform (
in CosNaming::Name src_entry_name,
in InformVariableList inform_variables
);
void snmp_report (
in CosNaming::Name src_entry_name,
in InformVariableList report_variables
);
};






interface PullNotifications {
boolean try_snmp_notification (
out CosNaming::Name src_entry_name,
out ScopedName event_type,
out ASN1_GeneralizedTime event_time,
out any notification_info
);
 
void pull_snmp_notification (
out CosNaming::Name src_entry_name,
out ScopedName event_type,
out ASN1_GeneralizedTime event_time,
out any notification_info
);
 
boolean try_snmp_inform (
out CosNaming::Name src_entry_name,
out InformVariableList inform_variables
);
 
void pull_snmp_inform (
out CosNaming::Name src_entry_name,
out InformVariableList inform_variables
);
 
boolean try_snmp_report (
out CosNaming::Name src_entry_name,
out InformVariableList report_variables
);
 
void pull_snmp_report (
out CosNaming::Name src_entry_name,
out InformVariableList report_variables
);
};
 
};
 
#endif /* _SNMPMGMT_IDL_ */


SNMPMgmt::ProxyAgent Interface

CORBA manager objects that require to get access to managed objects that are members of some given SNMP managed object domain must establish a connection with that domain.

As a result of establishing the connection, an SNMPMgmt::ProxyAgent object is created. SNMP::ProxyAgent objects export the JIDM::ProxyAgent interface and support additional operational that are specific to SNMP Management.

The SNMPMgmt::ProxyAgent provides a generic and version independent SNMP MIB based query interface, that encapsulates the SNMP protocol specific behavior.

Table: SNMPMgmt::ProxyAgent Interface





// ProxyAgent
interface ProxyAgent : JIDM::ProxyAgent {
readonly attribute TAddress host_name;
 
ASN1_Any get_a_variable (
in TAddress p_host_name,
in ScopedName p_var_scoped_name,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchVariable, NoSuchObject, ProtocolError );
 
NVPairList get_variables (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in VarNameList p_var_name_list,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, MultVarProtocolError );
 
void set_a_variable (
in TAddress p_host_name,
in ScopedName p_var_scoped_name,
in EntryIndex p_var_index,
in ASN1_Any p_var_new_value
) raises ( NoSuchHost, NoSuchVariable, NoSuchObject, ProtocolError );
 
void set_variables (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in NVPairList p_var_nvp_list,
in EntryIndex p_var_index
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, MultVarProtocolError );
 
void list_mib_entries(
in TAddress p_host_name,
in ScopedName p_entry_scoped_name,
in long p_how_many,
out EntryIndexList p_entry_index_list,
out GetNextEntryIterator p_entry_name_list_itr
) raises ( NoSuchHost, NoSuchSmiEntry, NoSuchObject, ProtocolError );
 
boolean is_mib_entry_exist (
in TAddress p_host_name,
in ScopedName p_entry_scoped_name
) raises ( NoSuchHost, NoSuchSmiEntry, ProtocolError );
 
boolean is_mib_module_supported (
in TAddress p_host_name,
in string p_smi_module_name
) raises ( NoSuchHost, NoSuchSmiModule, ProtocolError );
};


Connections are established by means of invoking the access_domain operation exposed by a root JIDM::ProxyAgentFinder object as explained in JIDM::ProxyAgentFinder Interface. The value associated with the XSM environment Key parameter passed to the access_domain operation shall be Internet Management. Note that the access_domain operation returns a reference to a JIDM::ProxyAgent interface. If the client wants to have visibility of the specific operations defined for the SNMPMgmt::ProxyAgent interface, this reference must be narrowed.

SNMPMgmt Conventions for Proxy Agent Finding Criteria presents the names and meaning for criteria that can be passed in the invocation to the access_domain operation when trying to access an SNMP managed domain. While the domain title criterion is mandatory, the rest of criteria components are optional.

Table: SNMPMgmt Conventions for Proxy Agent Finding Criteria

Criterion Name Type of Value Meaning
domain title TAddress Transport Address associated to the managed object domain for which access is requested. The wildcard address (*) is allowed.
transport protocol string Transport protocol used to access the managed domain. Possible values are UDP, IPX, etc. If not present, UDP is used as default. The value of this criterion determines the format of the TAddress used for the domain title criterion
transport port any Transport protocol dependent access point. If not present, (unsigned short)161 is used as default (corresponding to the default UDP port for SNMP)
protocol version SNMPMgmt::ProtocolVersion SNMP protocol version to be used to access the managed domain. If not specified, snmpV1 is used as default.
controller object JIDM::ProxyAgentController reference associated to a JIDM::ProxyAgentController object registered by the manager (OPTIONAL)
community name string Information to be used as the community name to be sent in the SNMP PDUs. Only valid for snmpV1 and snmpV2c. If not present, public is used (OPTIONAL)
context engine id string Only valid for snmpV3. Consult SNMP v3 documentation for more information (OPTIONAL)
context name string Only valid for snmpV3. Consult SNMP v3 documentation for more information (OPTIONAL)

The TAddress type used as domain title follows the TAddress Textual-Convention for transport service addresses defined in the SNMPv2-TC module. For the UDP domain (default case), the TAddress follows the 4+2 octets format. The format of the TAddress string for UDP domain is as follows: 



 

<IP-Address>[:<Udp-port>].

The <IP-Address> represent the stringified value of first 4 octets in DNS format or dotted number format. The <Udp-port> represents the integer value of last 2 bytes.

Semantics of the domain title and controller object parameters were specified in JIDM::ProxyAgentFinder Interface. If the domain title specified is the wildcard (*), then a generic SNMPMgmt::ProxyAgent object is returned, that would be able to interact with multiple SNMP agents.

The criteria, in the case of SNMP Systems Management Reference model, may include additional parameters, namely:

Since SNMPMgmt::ProxyAgent objects are JIDM::ProxyAgent objects, they provide the means by which CORBA manager objects are able to obtain references to:

Invoking the find_factories() operation exposed by the initial CosLifeCycle::FactoryFinder object, CORBA manager objects may find factories that enable creation of new table entries in the SNMP managed object domain.

Invoking the resolve() operation exposed by the initial CosNaming::NamingContext object, CORBA manager objects may obtain CORBA object references to existing members of the SNMPI managed object domain.

Once a CORBA manager object obtains a CORBA object reference associated to an SNMP managed object, it can invoke operations exposed by the object. It will do so by using the standard ORB services defined in reference CORBA:

The get_domain_factory_finder Operation
The get_domain_factory_finder() operation enables obtaining a reference to the initial CosLifeCycle::FactoryFinder object located at the domain being accessed through a given SNMPMgmt::Proxy-Agent object. As described in The JIDM::ProxyAgent Interface, CORBA manager objects can locate appropriate managed object factories by means of invoking the find_factories() operation exposed by this initial CosLifeCycle::FactoryFinder object.

The space of keys established for SNMP Management environments is described in SNMPMgmt Conventions for Factory Finder Keys.

Table: SNMPMgmt Conventions for Factory Finder Keys

id field kind field meaning
fully scoped name of object interface object interface Find factories that create objects supporting the named interface
fully scoped name of factory interface factory interface Find factories supporting the named factory interface

CORBA Managers can create managed objects either using operations exposed by specific factories whose interfaces are derived from specific SMI modules or by using operations exposed by generic factories.

In respect to generic factories, one (or several) of the three following scenarios may be supported:

In any case, the factory object would be responsible for checking if the new managed object can be contained in the designated domain.

With these considerations in mind, the alternatives for finding factories in SNMP Systems Management environments are more precisely described as follows:

If objects are created through CosLifeCycle::GenericFactory objects, the Key value passed in the invocation to the create_object() operation is the name of the interface exported by the new MIB table entry. The Criteria value would be a sequence of <name, value> pairs which would correspond to the rest of arguments needed for creation of the SMI entry as specified in SNMPMgmt Conventions for Managed Object Creation Criteria (name of the SMI entry in string or name-value-pair list format, initial attribute list, etc).

Table: SNMPMgmt Conventions for Managed Object Creation Criteria

Criterion Name Type of Value Interpretation
managed object interface CORBA::ScopedName Name of interface exported by the new SMI entry.
managed object name string Naming parameter based on index part of objectID of a variable, given as a string. Conctenated index values in dotted number form. The information in name and index variables are interchangeable.
index variables CosPropertyService::Properties Naming parameter based on index variables, given as a sequence of name-value pairs. Alternative to managed object name criterion.
initialization CosPropertyService::Properties When this parameter is supplied, it contains a set of attribute identifiers and values to be assigned to the new SMI entry.

The get_domain_naming_context Operation
The get_domain_naming_context() operation enables obtaining a reference to the initial CosNam-ing::NamingContext object located at the domain being accessed through a given SNMP-Mgmt::ProxyAgent object. The returned CosNaming::NamingContext reference can be narrowed to the SNMPMgmt::NamingContext interface, or even to the SNMPMgmt::NamingDirectory interface for wildcard SNMPMgmt::ProxyAgent objects.

As described in The JIDM::ProxyAgent Interface, CORBA manager objects can obtain CORBA object references to members of a managed object domain as a result of invoking the resolve() operation exposed by the initial CosNaming::NamingContext object located at the domain. The resolve() operation may also be used to obtain reference to CosNaming::NamingContext objects subordinated to the initial CosNaming::NamingContext object.

Managed objects will be named according to the SNMP Naming Principles.

The type of SNMPMgmt::ProxyAgent created depends on the criteria used when access to the domain was solicited. In particular, if access to a wildcard ProxyAgent was granted, then the initial CosNaming::NamingContext object in the managed domain must support resolution using the TAddress host_name parameters. However, if the ProxyAgent was not generic, then the use of this parameter with a value other than the empty string (" ") will raise the standard NO_PERMISSION exception.

The destroy Operation
Any SNMPMgmt::ProxyAgent object exposes the destroy() operation which enables disposing of the object. Disposing of an SNMPMgmt::ProxyAgent object means freeing resources used to maintain the associated connection.

Destruction of an SNMPMgmt::ProxyAgent object can take place either gracefully or non-gracefully, as described in The JIDM::ProxyAgent Interface. A reference to a JIDM::ProxyAgentController object may be passed at the manager side, as described in The JIDM::ProxyAgentController interface.

SNMP Operations
The SNMP protocol version independent SNMPMgmt::ProxyAgent provides a set of operations that are convenient to use in CORBA domain in order to browse SNMP MIB in variable specific as well as table oriented ways. In addition, it extends the JIDM::ProxyAgent interface to support SNMP specific managment operations.

All SNMP operations carry a p_host_name parameter of type TAddress. This parameter may only be used in wildcard ProxyAgents, and contains the transport specific address of the agent to be contacted for this particular management operation. In case of non-wildcard ProxyAgents, the agent is specified at the time of creation of the ProxyAgent object (specified in the criteria passed to the access_domain() call), and therefore this parameter must be the empty string (" "); if a different value is used, then the standard NO_PERMISSION exception is raised.

Type Definitions and Exceptions
VarNameList and NameValuePair type redefine the CosPropertyService::PropertyNames and CosProperty-Service::Property respectively, such that type name reflects the variable centric approach of SNMP.

The EntryIndex type represents the string for instance information of a conceptual row of a table. The EntryIndex string represents the string-ified (in dotted number form) version of sequence of oids that represents the instance information. EntryIndexList type represents a set of entry indexes.

The ProtocolError exception is raised to inform the client application about the SNMP protocol related errors. SNMP errors are indicated by the ProtocolError.error_status field. An application will map the SNMP related error to the corresponding CORBA Exception as shown in Mapping of SNMP Errors to IDL Exceptions.


Table: Mapping of SNMP Errors to IDL Exceptions







SNMP Error IDL Exception

noError NO_EXCEPTION
tooBig IMP_LIMIT
noSuchName NO_IMPLEMENT
badValue BAD_PARAM
readonly BAD_OPERATION
genErr INTERNAL
noAccess NO_PERMISSION
wrongType BAD_TYPECODE
wrongLength MARSHAL
wrongEncoding MARSHAL
wrongValue BAD_PARAM
noCreation CosLifeCycle::InvalidCriteria
inconsistentValue BAD_PARAM
resourceUnavilable NO_RESOURCE
commitFailed INTERNAL
undoFailed INTERNAL



The MultVarProtocolError exception is raised during multiple value get-set method. The error_status field follows the same mapping used for ProtocolError. The result_var_list field contains the returned variable list. The error_var_list field contains the names of the variables that are not part of the result_var_list.

The NoSuchSmiModule exception is raised if an SNMP agent does not support the associated MIB module. The NoSuchSmiEntry exception is raised if an SNMP agent does not support an specific MIB table or a group. The NoSuchVariable exception is raised if the an SNMP agent does not support the specific SMI variable. The NoSuchHost exception is raised if the host cannot be found in the host database. The NoSuchObject exception is raised if the noSuchObject element is selected in the value part of the VarBind returned result. The NoSuchInstance exception is raised if the noSuchInstance element is selected in the value part of the VarBind returned result.

The get_a_variable Operation
The ProxyAgent::get_a_variable() operation returns the value of an SNMP variable (tabular or non-tabular) given the name of the variable in IDL scoped format (M::I::A, where M is the SMI information module, I is the interface identifier of the table-entry/group for the variable and A is the identifier of the attribute for the variable), and the index information in ASN.1 ObjectIdentifier format.

The p_var_scoped_name is the IDL scoped name of the variable in the form of M::I::A, where M is the SMI information module, I is the interface identifier of the table-entry/group for the variable and A is the identifier of the attribute for the variable.

The p_var_index is the row index of the variable in the string form.

The returned value is of type ASN1_Any (typedef of CORBA::Any) and the TypeCode of the returned value is set according to the Specification Translation mapped IDL type of the attribute. In other words, the TypeCode of the returned value is equal to the value returned by the type() operation of the AttributeDef for M::I::A.

The operation raises NoSuchVariable exception if the variable name in p_var_scoped_name does not exists. The operation raises NoSuchObject exception if the variable with given instance information does not exists at the remote host. For all other cases the operation raises SNMP specific protocol error using ProtocolError exception.

The get_variables Operation
The ProxyAgent::get_variables() operation returns a list of values of a SNMP variables (tabular or non-tabular) given the IDL scoped name of the SMI table-entry/group (in the form of M::I, where M is the SMI information module, I is the interface identifier of the table-entry/group), IDL identifier of the variables, and the index information of a specific entry in ASN.1 Objec-tIdentifier format.

The returned value is in the form of Name-Value pair list, where names are the identifiers of the variables and values are of type any. The TypeCode of the values of the variables are set according to the mapped IDL type of the corresponding attributes.

The operation raises NoSuchSmiEntry exception if the interface name in p_entry_scoped_name does not exists in the interface repository. For all other cases the operation raises MultVarProto-colError exception by assigning the SNMP specific protocol error to the error_status field.

The set_a_variable and set_variables Operations
The ProxyAgent::set_a_variable() and ProxyAgent::set_variables() operations are defined to modify the values of variables within MIB entries. The parameters are similar to the corresponding get operations except that the new value is also provided as a parameter.
The list_mib_entries Operation
The ProxyAgent::list_mib_entries interface provides access to the instance names of the entries of a certain table. This operation is designed to handle very large tables through the use of an iterator interface, called GetNextEntryIterator (see The SNMPMgmt::GetNextEntryIterator Interface).

The GetNextEntryIterator interface is defined to provide information about the indexes (names) of each row of a table. The ProxyAgentt::list_mib_entries() operation may be implemented using GET-BULK (GET-NEXT for SNMPv1). The GetNextEntryIterator interface provides the indexes of the entries of the MIB tables in lexicographical order.

The p_entry_scoped_name is the IDL scoped name of the variable in the form of M::I, where M is the SMI information module, and I is the interface identifier of the table-entry/group. p_how_many specifies the maximum number of entry indexes to be returned in p_entry_index_list.

If there are more entry indexes to be returned then a reference to a GetNextEntryIterator object is returned otherwise a null reference is returned. The operation raises NoSuchSmiEntry exception if the interface name in p_entry_scoped_name does not exists. For all other cases the operation raises ProtocolError exception.

The mib_entry_exists Operation
The mib_entry_exists() operation checks if there exists any entry for a specific (p_entry_scoped_name) group/table at the remote agent. It returns TRUE if there is at least one entry of p_entry_scoped_name table-entry/group and returns FALSE if there is none. The p_entry_scoped_name is the IDL scoped name of the table-entry/group in the form M::I.
The is_mib_module_supported Operation
The is_mib_module_supported() operation returns true if any group or table in the module specified by p_smi_module_name exists in the remote host. The p_smi_module_name provides the identi-fier of the SMI module in IDL.

The SNMPMgmt::SmiEntry Interface

The SNMPMgmt::SmiEntry interface is the base IDL interface for all IDL interfaces of SMI groups and table-entries (possibly generated via the JIDM Specification Translation algorithm for SNMP to IDL translation).


Table: The SmiEntry Interface





interface SmiEntry : CosLifeCycle::LifeCycleObject, CosPropertyService::PropertySet {
// the value of entry_name is always 0 for the groups.
readonly attribute ASN1_ObjectIdentifier entry_name;
};
typedef sequence < SmiEntry > SmiEntryList;


The SmiEntry interface inherits from CosLifeCycle::LifeCycleObject and CosPropertyService::PropertySet interfaces. The SNMPMgmt::SmiEntry interface has a read-only attribute called entry_name which contains the value of the index(es) (the instance information part of the object-id of the group or table entry) of the corresponding variable or table entry. The entry_name attribute always contains 0 for SMI entries related to groups. The entry_name of a table-entry is known during the create time and set by the factory objects.

LifeCycle Operations
The SNMPMgmt::SmiEntry interface inherits from the standard CosLifeCycle::LifeCycleObject interface. This means that every SMI entry exposes the operations defined in the CosLifeCycle::Life-CycleObject interface. Specifically, the following semantics for the operations are specified:
PropertySet Operations
For SNMP management, each SNMP variable within a group or a table entry is always represented as an IDL attribute. In order to manipulate these attributes in groups, the CORBA Property Service is used.

The CosPropertyService::PropertySet interface is used to get the values of one or more variables in a group or in a row of a table with a single method invocation.

The property names to be used when invoking PropertySet operations are the simple unscoped names of the attributes that are to be accessed. The behaviour of all operations is the same as specified in the Property Service Specification. Specifically, it is possible to:

Note that this allows manipulation of multiple properties within a single SNMP group or table entry. It is not possible to access multiple table entries and/or groups with a single method invocation.

Since the properties based on SNMP variables are statically defined, the dynamic deletion of property is not allowed, so all the delete operations of the PropertySet interface ( delete_property(), delete_properties() and delete_all_properties()) should return the standard NO_PERMISSION exception.

The SNMPMgmt::SmiTableIterator Interface

For each SMI table within an SMI group, there is an operation to retrieve the information contained in the table. These operations return an SNMPMgmt::SmiTableIterator object reference, to allow the traversal of the information within the table.


Table: The SmiTableIterator Interface





Interface SmiTableIterator {
boolean next_one_entry( out SmiEntry smi_entry );
boolean next_n_entries (
in unsigned long how_many,
out SmiEntryList smi_entry_list
);
void destroy();
};


The SmiTableIterator interface lets a client application to traverse a MIB table in the lexicographic order of the names (as defined in SNMP GET-NEXT) of its entries, and returns the reference to each table entry. A reference to an SmiTableIterator is obtained as result of the invocation of the <M>::<G>::get_<T>() operation, where <M>::<G> represents the IDL scoped name of a group and <T> represents the identifier of the table.

The In next_one_entry operation retrieves the object reference to the next entry of a specific table following the SNMP get-next traversal order. The returned reference is put in the smi_entry output parameter. If there are no more entries then the operation returns false otherwise it returns true.

The next_n_entries() operation retrieves the references to a set of entries of a specific table following the SNMP get-next traversal order. The number of entries to be retrieved is specified by the how_many parameter, and the returned entries are placed in the smi_entry_list output parameter. If there are no more entries then the operation returns false otherwise it returns true.

The destroy() operation destroys the iterator object associated with the reference.

The SNMPMgmt::GenericFactory Interface

In SNMPv2, there is a data type (Textual Convention), called RowStatus, for creation of a row whose value define various stages of life-cycle of an entry in a table. A table which support entry creation by managers must include a variable of type RowStatus.

When a manager wants to create a table entry, it must pass the proper value of RowStatus variable in addition to all the variables with read-create access and the index variables in the SNMPv2 SET message (see the section 7.1.12.1. in RFC1902).

These operations are mapped to create operations in a factory interface in the CORBA domain. A factory interface can be defined for each module and there will be one create_<smi_entry_type> operation per IDL interface generated for group/table-entry from the SNMP MIB module.


Table: The SNMPMgmt::GenericFactory Interface





interface GenericFactory : CosLifeCycle::GenericFactory {
SmiEntry create_mib_entry (
in ScopedName t_entry_type,
in ASN1_ObjectIdentifier entry_index,
in Criteria create_criteria
) raises ( NoSuchSmiEntry, AlreadyExists );
 
SmiEntry create_mib_entry_with_auto_name (
in ScopedName t_entry_type,
in Criteria create_criteria
) raises ( NoSuchSmiEntry, AlreadyExists );
};


The GenericFactory is an extension of the CosLifeCycle::GenericFactory interface defined in the CORBA LifeCycle service specification, that provides SNMP SMI specific generic life-cycle operations.

The create_mib_entry() operation creates a MIB entry that supports the interface specified in the t_entry_type parameter, and binds the name (given by the entry_ins_name parameter) with the reference to the object within the scope of the naming-context for the given interface type (t_entry_type). The operation returns the object reference of the newly created object. The t_entry_type parameter specifies the scoped name (in the form of M::I) of the IDL interface for an SMI based group or table-entry.

The entry_ins_name parameter specifies the instance information of the given MIB entry. The instance information is the string form of concatenated values of the index variables of the given entry. The create_criteria parameter specifies the values of a set of criteria, in the form of a name-value-pair list. The allowed criteria are as defined in Criteria for SNMP specific LifeCycle service, and only the initialization criterion is used with this operation.

Table: Criteria for SNMP specific LifeCycle service

Criterion Name Type of Value Meaning
entry name string Naming parameter based on index part of objectID of a variable, given as a string. Concatenated index values in dotted number form. Alternative to index variables criterion.
index variables CosPropertyService::Properties Naming parameter based on index variables, given as a sequence of name-value pairs. Alternative to entry name criterion.
initialization CosPropertyService::Properties When this parameter is supplied, it contains a set of attribute identifiers and values to be assigned to the new SMI entry.
domain title SNMPMgmt::TAddress Agent location where new entry is to be created (cannot be wildcard).

The create_mib_entry() operation raises NoFactory exception if a type-specific factory cannot be found. The operation raise InvalidCriteria if the any of the criteria in the create_criteria parameter is not a valid one. The operation raises CannotMeetCriteria exception if any one of the criteria cannot be met. The operation raises CosNaming::NamingContext::Already-Bound exception if the given name in entry_ins_name is already bound within the scope of the naming-context for interface type in t_entry_type.

The create_mib_entry_with_auto_name() is similar to create_mib_entry(), but the name of the newly created object is assigned by the factory object.

The SNMPMgmt::NamingContext Interface

The main goal of mapping names in SNMP domain to names in CORBA domain is to standardize the SNMP naming hierarchy (host, variable, index) based on the NamingConext interfaces of the CORBA naming service. This goal is achieved in two ways: by standardizing the MIB tree hierarchy, and by extending the NamingContext interface to list its entries in the lexicographic order of the names.


Table: The SNMPMgmt::NamingContext Interface





// NamingContext extends CosNaming::NamingContext to provide
// navigating the SNMP name space in the lexicographic order
// and SNMP specific name and context resolution
 
interface NamingContext : CosNaming::NamingContext {
string get_next_entry(
in string entry_name
) raises ( InvalidName, NotFound, CannotProceed );
 
GetNextEntryIterator get_next_entry_iterator(
in string initial_entry_name
) raises ( InvalidName, NotFound );
};


The SNMPMgmt::NamingContext extends CosNaming::NamingContext in order to provide the navigation capability of the SNMP name space in the lexicographic order, as expected by the GET-NEXT command.

The get_next_entry() operation returns the name of the lexicographically next entry of that given by entry_name. If entry_name is a zero-length string then the first entry is returned. If there are no more entries after the entry_name, then the CannotProceed exception is raised. InvalidName and NotFound exceptions are raised based on the response from the resolve() operation using entry_name.

The get_next_entry_iterator() returns an Iterator (of type SNMPMgmt::GetNextEntryIterator) that conforms to the SNMP get-next lexicographic ordering. The returned iterator is set to point to the entry given by initial_entry_name. A zero-length string (" ") for initial_entry_name will set the returned iterator at the beginning of list of entries in the naming context.

Naming MIB Entries Using SNMP Names in CORBA Domain
This section describes how to name entries of SNMP MIB in the CORBA domain using the INDEX variables, and how to access the MIB entries based on their corresponding SNMP names, and finally retrieve the values of SNMP variables.

Overview of Naming of Variables in SNMP Domains
In the SNMP domain, the names are associated with the instances of variables, and the instances of tabular/non-tabular variables are uniquely addressable within the scope of a host IP address. The notion of table-entries is conceptualized by assigning the same index information to all the instances of variables of the same table entry. From a manager's perspective, entries of the SNMP MIBs are implicitly arranged in the following naming hierarchy:

Host
variable OID
row index

Since SNMP MIBs are agent location dependent, the SNMP names are also location dependent. For non-tabular variables of group, the name is always zero, and for rows of tabular variable the instance information depends on the INDEX clause of the corresponding table.

Building of Global Name Tree of SNMP MIBs
In order to map names of variable instances in SNMP domain to attributes of MIB entries CORBA domain, we need to map the names of variable within the scope of a host to hierar-chical name tree by using the CORBA naming service (see reference CORBAservices).

The hierarchy of the nodes of the name tree is as follows:

The nodes for root. host, module and the table support the SNMPMgmt::NamingContext interface. The references to MIB entries are bound with the nodes for table-entries/groups using their names (row indices).

The SNMP names in string form are always mapped to the id part of a CosNaming::NameCompo-nent. The kind part of a NameComponent is always initialized with a zero-length string.

The root of the global MIB tree is registered with a well defined name, SNMP-MIB-ROOT, within the scope of some naming-context in the CORBA name space.

The nodes for the hosts (domains) of SNMP MIBs are represented by a naming-context (within the scope of the root MIB node, SNMP-MIB-ROOT). Since a host name can be represented in many ways (ip-address, DNS name, many aliases of host name), we need to define one name that can be used to unambiguously identify the nodes for the host under MIB. The default scheme for naming a node for host is DNS based name.





Figure: SNMP Naming Hierarchy


If the DNS-based naming is not supported then an IP address (e.g., 135.180.160.16) can be used. Since the CORBA naming service allows name aliasing, a compliant implementation can support both DNS based naming and IP-address based naming by registering the reference of nodes for a host naming-context using both names. Since CORBA name-component has two parts ( id and kind), the id part is initialized by the host name and the kind part is initialized with zero-length string.

A compliant implementation of the SNMP Name-Tree can add more nodes between the root (SNMP-MIB-ROOT) node and hosts based on the DNS domain hierarchy or IP subnet, so long as name resolution based on full DNS name or IP address returns the reference to the same naming-context node. The JIDM::ProxyAgent::get_domain_naming_context() operation will return a reference to the naming-context at the host-name level for non-wildcard Proxy-Agents, while it will return a reference to the root NamingContext for wildcard Proxy-Agents.

Within the scope of each host (domain), there will be a naming-context for each of the MIB information modules that are implemented at the host. The naming context associated with the node for the MIB module is named using the IDL SMI module identifier.

Within the scope of each MIB information module, there will be a naming-context based node for each of the IDL interfaces for group, and table entry defined within the scope of the IDL module. The naming context associated with the nodes for groups/table-entries are named using the identifier of the corresponding IDL interface.

The entries (instances that support the IDL interfaces obtained by mapping SNMP MIB) of the MIB implementation are bound within the naming-context for the corresponding IDL interface. The names of the bounded MIB entries are the instance information needed to identify all the variables of row of conceptual table.

For non-tabular variables of group, the name is always zero, and for rows of tabular variables, the instance information depends on the INDEX clause of the corresponding table. The bounded objects are the leaf-object of the SNMP name tree.

In order to support get-next traversal, the naming-contexts SNMP names is extended in order to retrieve of the objects in the SNMP lexicography order.

Resolving SNMP Names to Obtain Object References
Mapping of Non-tabular Variable Name describes how to map the SNMP name of an instance of non-tabular variable of a group to name of the corresponding MIB entry and IDL attribute in the CORBA domain. Given a non-tabular name in OID form, first we have to separate the instance information from the variable OID using the largest variable OID prefix match, as shown in the second line. Next, we derive the OID of the group by dropping the right-most identifier for the variable (as shown in third line).


Example: Mapping of Non-tabular Variable Name





evalSlot.0 ( => 1.3.6.1.3.555.2.1.0)
=> 1.3.6.1.3.555.2.1, 0
=> 1.3.6.1.3.555.2, 0, 1.3.6.1.3.555.2.1
=> FIZ_MIB::eval, 0, FIZ_MIB::eval::evalSlot
=> FIZ_MIB, eval, 0, FIZ_MIB::eval::evalSlot
=> <FIZ_MIB, eval, 0> , evalSlot
=> host_nc->resolve(<FIZ_MIB, eval, 0>)->get_property(evalSlot)


The OIDs of the group and the variable are then converted to corresponding IDL scoped names (possibly using the SNMPMIR::Repository interface). Then the IDL scoped name for the group is split into its module and interface name. Finally, we use the ordered sequence of module name, interface name and instance information to derive a compound name of the MIB entry for the group within the scope of a naming context for a host. If we know the name of the host in DNS or IP address form, we know the complete path name of the group within the scope of the well defined root node, called MIB.

In Mapping of Non-tabular Variable Name, we show how to access the value an instance of evalSlot.0 (which is actually represented by 1.3.6.1.3.555.2.1.0) to the IDL scoped name of the corresponding group interface (FIZ_MIB::eval) and attribute (FIZ_MIB::eval::evalSlot) of the interface.

The compound name of the object (within the scope of a host) that supports eval is derived by mapping the fully scoped name of the interface and the instance information (0) to id part of name-components of the compound name.

Given the compound name, we can get the reference to the MIB entry that represents the eval group by using resolve() operation of the host naming context. Then we can use the resolved object reference to retrieve the value of the variable by invoking get operation associated with the attribute evalSlot.

Mapping of Tabular Variable Name describes how to map the SNMP name of an instance of tabular variable of a conceptual table to naming service based names of a MIB entry and the attribute of the corresponding interface. In Mapping of Tabular Variable Name, we first split the object-id (1.3.6.1.3.555.2.2.1.4.2) into the OID of the variable (1.3.6.1.3.555.2.2.1.4) and its instance information (2) by using largest prefix match. Then, we derive the OID (1.3.6.1.3.555.2.2.1) of the corresponding table-entry by dropping the last number of the variable OID. Then we obtain the OIDs of table entry and the variable to corresponding IDL Scoped name of the interface (FIZ_MIB::evalEntry) and attribute (FIZ_MIB::evalEntry::evalStatus), respectively. Then we split the IDL scoped name of the table-entry into module name and interface name. Then we use the ordered sequence of the module name, interface name and the instance information to derive the compound name (<FIZ_MIB, evalEntry, 2>), within the scope of a host context. This compound name represent the name of the MIB entry representing the row in the table.


Example: Mapping of Tabular Variable Name





evalStatus.2 ( => 1.3.6.1.3.555.2.2.1.4.2)
=> 1.3.6.1.3.555.2.2.1.4, 2
=> 1.3.6.1.3.555.2.2.1, 2, 1.3.6.1.3.555.2.2.1.4
=> FIZ_MIB::evalEntry, 2, FIZ_MIB::evalEntry::evalStatus
=> <FIZ_MIB, evalEntry, 2>, evalStatus
=> host_nc->resolve(<FIZ_MIB, evalEntry, 2>)->get_property(evalStatus)


Given the compound name, we can get the reference to the MIB entry by using the resolve() operation of the host naming context. Then we use the resolved object reference to retrieve the value of the variable by invoking the get operation associated with the attribute evalStatus.

SNMPMgmt::NamingDirectory Interface

The SNMPMgmt::NamingDirectory interface extends SNMPMgmt::NamingContext in order to provide the global navigating capability of the SNMP name space.


Table: SNMPMgmt::NamingDirectory Interface





interface NamingDirectory : NamingContext {
NamingContext resolve_domain_context(
in TAddress p_host_name
) raises ( NoSuchHost, CannotProceed, InvalidName, NotFound );
 
NamingContext resolve_smi_module(
in TAddress p_host_name,
in string p_smi_module_name
) raises ( NoSuchHost, NoSuchSmiModule, InvalidName, NotFound );
 
NamingContext resolve_smi_entry(
in TAddress p_host_name,
in ScopedName p_entry_type
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );
 
SmiEntry resolve_mib_entry(
in TAddress p_host_name,
in ScopedName p_entry_type,
in string p_entry_index
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );
 
void list_smi_entries(
in TAddress p_host_name,
in ScopedName p_entry_type,
in unsigned long how_many,
out SmiEntryList out_list,
out SmiTableIterator table_iterator
) raises ( NoSuchHost, NoSuchSmiEntry, CannotProceed, InvalidName, NotFound );
};


The resolve_domain_context() returns the reference to the naming context for the domain specified by the p_host_name.

The resolve_smi_module() returns the reference to the naming context for p_smi_module_name within the scope of naming-context for the domain specified by p_host_name. The p_host_name follows the format defined in the TAddress type. The p_smi_module_name is the MIB module name.

The resolve_smi_entry_context() returns the reference to the naming context for p_entry_type (which has to be in scoped-name format) within the scope of the naming-context for p_host_name. p_host_name follows the format defined in the TAddress type. p_entry_type is in the form of M::I scoped name.

The resolve_mib_entry() operation returns the reference to the MIB entry for the row with index specified by p_entry_name with the scope of naming contexts for p_host_name and p_entry_type. p_host_name follows the format defined in the TAddress type. The p_entry_type parameter is in the form of M::I scoped name; p_entry_index is the instance part of the variables of a conceptual row of a table. For groups, p_entry_index is always 0. The returned reference is a reference to the base SNMP interface, SNMPMgmt::SmiEntry, and may be narrow casted to the specific IDL interface for the table entry.

The list_mib_entries() operation returns the reference to a list of MIB entries of a table specified by p_entry_name with the scope of naming contexts for p_host_name. The p_host_name follows the format defined in the TAddress type. The p_entry_type parameter is in the form of M::I scoped name; the number of entries to be retrieved is specified by the how_many parameter and the returned entries are placed in the ol. If there are more entries in the table than specified by how_many parameter, then a SNMPMgmt::SmiTableIterator reference is placed in the table_iterator parameter.

The SNMPMgmt::GetNextEntryIterator Interface

The GetNextEntryIterator interface lets a client application to traverse a MIB table in the lexicographic order followed by SNMP GET-NEXT message requirements and returns the index information of each entry. A reference to GetNextEntryIterator is obtained as result of the invocation of the SNMPMgmt::ProxyAgent::list_mib_entries() and SNMPMgmt::NamingCon-text::get_next_entry_iterator() operations.


Table: SNMPMgmt::GetNextEntryIterator Interface





interface GetNextEntryIterator {
// Get the next entry index accroding to lexical ordering rule
// of SNMP OIDs -- follows SNMP get-next traversal rule
boolean next_one_entry ( out EntryIndex entry_index );
boolean next_n_entries (
in unsigned long how_many,
out EntryIndexList entry_index_list
);
void destroy();
};


The next_one_entry() operation retrieves the instance information of the next entry of a specific table following the SNMP get-next traversal rule. If there are no more entries then the operation returns false, otherwise it returns true.

The next_n_entries() operation retrieves the instance information of the a set of entries of a specific table following the SNMP get-next traversal rule. The number of entries to be retrieved is specified by the how_many parameter and the returned entries are placed in the entry_index_list. If there is no more entries then the operation returns false, otherwise it returns true.

The destroy() operation destroys the object associated with the iterator reference.

Event Communication

Data Types for Untyped Event Communication
IDL Types of Untyped Event Communication describes the data types for untyped event communications between MIB objects and the manager objects.


Table: IDL Types of Untyped Event Communication





struct EntryVarBind {
ScopedName entry_name; // IDL scoped name of the interface for table-entry
string entry_index; // row index of an entry in the form of ObjectId string
CosPropertyService::Properties nvp_list;
};
typedef sequence<EntryVarBind> EntryVarBindList;
typedef EntryVarBindList NotificationVariableList;
typedef EntryVarBindList InformVariableList;
 
struct NotificationInfo { // to be sent when using untyped event channel
CosNaming::Name src_entry_name;
ScopedName event_type;
ASN1_GeneralizedTime event_time;
any notification_info;
};
struct InformInfo { // to be sent when using untyped event channel
CosNaming::Name src_obj_name;
InformVariableList inform_info;
};


The SNMPMgmt::EntryVarBind type is defined to map variables in VarBindList of SNMP PDU to IDL in a convenient form for objects in CORBA domain. The variables of each row of the same table are grouped together by their index values and mapped to EntryVarBind. The name of the table-entry is mapped to entry_name, the common row index is mapped to entry_index. The textual names and the values of the variable in each VarBind are mapped to CosPropertyService::PropertyType based nvp_list field. Since the variables in VarBindList may span multiple rows of different tables, a single VarBindList may result in multiple EntryVarBind instances. The Entry-VarBindList type is defined to handle such cases.

The NotificationVariableList and the InformVariableList types redefines the EntryVarBindList for SNMP message specific information.

The NotificationInfo type is defined as the data type to be sent as event data for untyped event communication. The NotificationInfo type has two parts: header and body. The header part consists of three elements: name of the object generating the event (src_entry_name), the type of the event (event_type), and the time of the event generation (event_time).

The body part is in the form any, and the structure of the data depends on the type of the event being sent. The IDL type of the event body is generated based on the OBJECTS clause in the associated SNMP SMI based TRAP-TYPE or NOTIFICATION-TYPE macros. The actual event data based on the OBJECTS clause is to be mapped to data of type generated for typed event communication and then put into notification_info field as any.

The InformInfo type is defined to support the InformRequest and Report PDU based messages in SNMPv2. It consists of two parts: name of the object sending the inform-request or report message, and the body of the inform or report data.

SNMPMgmt::Notifications Interface
The SNMPMgmt::Notifications interface is defined to support push model of typed event communication described in the Typed Event Service specification.


Table: SNMPMgmt::Notifications Interface





interface Notifications {
void snmp_notification (
in CosNaming::Name src_entry_name,
in ScopedName event_type,
in ASN1_GeneralizedTime event_time,
in any notification_info
);
void snmp_inform (
in CosNaming::Name src_entry_name,
in InformVariableList inform_variables
);
void snmp_report (
in CosNaming::Name src_entry_name,
in InformVariableList report_variables
);
};


The snmp_notification() operation is invoked to send event data using a typed event channel. The parameters of the snmp_notification() operation are defined based on the fields of the Notification-Info data type for untyped event communication.

The snmp_inform() operation is invoked to send inform-request messages using a typed event channel. The parameters of the snmp_inform() operation are defined based on the fileds of the InformInfo data type.

The snmp_report() operation is invoked to send report messages using a typed event channel. The parameters of the snmp_inform() operation are defined based on the fields of the InformInfo data type.

SNMPMgmt::PullNotifications Interface
The SNMPMgmt::PullNotifications interface is derived from the SNMPMgmt::Notifications interface based on the design pattern defined for pull-style typed interface in the typed event service specification. The interface name is defined as Pull<I>, where <I> is name of the typed interface for push model.

For each operation (<op>) in <I> interface, a try_<op>() operation and a pull_<op>() operation are defined.

The in parameters of the corresponding push operation in the Notifications interface is converted to an out parameter. The return value of try_<op>() and pull_<op>() are boolean and void, respectively.


Table: SNMPMgmt::PullNotiifcations Interface





interface PullNotifications {
boolean try_snmp_notification (
out CosNaming::Name src_entry_name,
out ScopedName event_type,
out ASN1_GeneralizedTime event_time,
out any notification_info
);
 
void pull_snmp_notification (
out CosNaming::Name src_entry_name,
out ScopedName event_type,
out ASN1_GeneralizedTime event_time,
out any notification_info
);
 
boolean try_snmp_inform (
out CosNaming::Name src_entry_name,
out InformVariableList inform_variables
);
 
void pull_snmp_inform (
out CosNaming::Name src_entry_name,
out InformVariableList inform_variables
);
 
boolean try_snmp_report (
out CosNaming::Name src_entry_name,
out InformVariableList report_variables
);
 
void pull_snmp_report (
out CosNaming::Name src_entry_name,
out InformVariableList report_variables
);
};


All descriptions are exactly as described in SNMPMgmt::Notifications Interface.

SNMP Management Information Repository

This section describes the SNMP Management Information Repository service, also known as the SNMP SMI repository service. This service is optional; it is not required in order to provide the full functionality of the model.

During the specification translation of SMI based information module to CORBA IDL, not all of the information is mapped to IDL. Some of the information is lost, for example OID information. Also the way SMI related meta information is available through the CORBA Interface Repository (IFR) is not very convenient. For example, index variables of table entries are available as string, in contrast to sequence of variables. Also the usage of the IDL interface repository interfaces are quite tedious. For all tese reasons, a SMI specific repository interface on top of CORBA IFR has been defined.

The SMI Repository service consists of two components: OID Repository, and SMI macro repository. The OID repository provides the information about OID hierarchy and the textual names associated with each oid node in the OID hierarchy tree. The SMI macro repository provides meta-information about SMI modules and macros for groups, table-entry and variables.


Table: SNMP SMI Repository Module





#ifndef _SNMPMIR_IDL_
#define _SNMPMIR_IDL_
 
#include <orb.idl>
#include <ASN1Types.idl>
 
module SNMPMIR {
 
// Snmpv1GenericTrapId defines the identfiers for generic trap
// types in SNMPv1.
 
enum Snmpv1GenericTrapId {
TRAP_COLDSTART, TRAP_WARMSTART, TRAP_LINKDOWN, TRAP_LINKUP,
TRAP_AUTHFAIL, TRAP_EGPNEIGHBORLOSS, TRAP_ENTERPRISESPECIFIC
};
 
// GENERIC_TRAP_ENTERPRISE_OID defines the enterprise OID for
// generic traps.
 
const ASN1_ObjectIdentifier GENERIC_TRAP_ENTERPRISE_OID = 1.3.6.1.4.1.3.1.1;
 
// SmiAccessMode defines the enumerated values of the SMI based
// acces - mode defined for a specific variables.
 
enum SmiAccessMode {
read_only, read_write, read_create, write_only, inaccessible
};






// Basic and Application specific SMI types.
enum SmiValueType {
smi_null_value, smi_integer_value, smi_string_value, smi_objectID_value,
smi_bit_value, smi_ipAddress_value, smi_counter_value, smi_gauge_value,
smi_timeticks_value, smi_arbitary_value, smi_nsapAddress_value,
smi_big_counter_value, smi_unsigned_integer_value, smi_unknown_type
};
 
typedef CORBA::ScopedName ScopedName;
typedef sequence < ScopedName > ScopedNameList;
typedef sequence < string > VarNameList;

typedef sequence < string > ModuleNameList;
typedef sequence < ASN1_ObjectIdentifier > OIDList;
 
interface OidRepository {
 
ScopedName get_scoped_name ( in ASN1_ObjectIdentifier in_oid );
 
string get_name ( in ASN1_ObjectIdentifier in_oid );
ASN1_ObjectIdentifier get_oid ( in ScopedName in_scoped_name );
ASN1_ObjectIdentifier get_var_oid (
in ScopedName iface_scoped_name,
in string var_name
);
 
string get_textual_obj_id ( in ASN1_ObjectIdentifier obj_id );
 
void split_var_object_id (
in ASN1_ObjectIdentifier var_obj_id,
out ASN1_ObjectIdentifier var_oid,
out ASN1_ObjectIdentifier obj_index
);
 
ASN1_ObjectIdentifier get_next_oid ( in ASN1_ObjectIdentifier oid );
 
ScopedName get_next_scoped_name ( in ScopedName scoped_name );
ScopedName get_next_entry_type ( in ScopedName scoped_name );
 
};
 
interface VariableDef : CORBA::AttributeDef {
readonly attribute ASN1_ObjectIdentifier oid;
readonly attribute SmiValueType smi_type;
 
readonly attribute SmiAccessMode smi_access_mode;
 
readonly attribute any default_value;
};
typedef sequence < VariableDef > VariableDefList;






 
interface SmiEntryDef : CORBA::InterfaceDef {
readonly attribute ASN1_ObjectIdentifier oid;
readonly attribute unsigned long total_no_of_variables;
readonly attribute VariableDefList var_def_list;
readonly attribute VarNameList var_name_list;
readonly attribute ScopedNameList var_scoped_name_list;
readonly attribute OIDList var_oid_list;
readonly attribute VarNameList index_var_names;
readonly attribute ScopedName next_group_or_table;
VariableDef lookup_variable( in string var_name );
};
 
typedef sequence < SmiEntryDef > SmiEntryDefList;
interface GroupDef : SmiEntryDef {
readonly attribute SmiEntryDefList table_entry_list;
};
typedef sequence < GroupDef > GroupDefList;
 
interface ModuleDef : CORBA::ModuleDef {
readonly attribute GroupDefList smi_group_def_list;
readonly attribute SmiEntryDefList smi_entry_def_list;
readonly attribute CORBA::InterfaceDef push_notification_def;
readonly attribute CORBA::InterfaceDef pull_notification_def;
readonly attribute CORBA::InterfaceDef default_value_def;
SmiEntryDef lookup_smi_entry( in string smi_entry_name );
};
typedef sequence < ModuleDef > ModuleDefList;
 
interface Repository : CORBA::Repository, OidRepository {
readonly attribute ModuleNameList module_name_list;
readonly attribute ModuleDefList module_def_list;
boolean is_smi_module( in CORBA::Identifier module_name );
ModuleDef lookup_smi_module( in string a_module_name );
SmiEntryDef lookup_smi_entry( in ScopedName entry_scoped_name );
ScopedNameList get_entry_var_list( in ScopedName entry_scoped_name );
ScopedNameList get_entry_index_var_list( in ScopedName entry_scoped_name );
any get_var_default_value( in ScopedName var_scoped_name );
string get_generic_trap_desc( in ASN1_Integer trap_type );
};
 
};
 
#endif /* _SNMPMIR_IDL_ */


The SMI Repository provides information in a SMI specific way. You can get the names of only those modules in IFR that are generated according to the Specification Translation rules. You can also get the names of SMI specific IDL interfaces. You can get the default value of a variable (if defined) given its IDL scoped name. The SMI Macro Repository is built on top of the CORBA interface repository (IFR). Similar to CORBA IFR, the SMI Macro Repository follows the SMI containment and extends the corresponding IDL interfaces defined for CORBA IFR.


Table: Containment Hierarchy of IDL Interfaces in SMI Repository







SNMPMIR::Repository CORBA::Repository

ModuleDef ModuleDef
GroupDef InterfaceDef
SmiEntryDef InterfaceDef
VariableDef AttributeDef


Containment Hierarchy of IDL Interfaces in SMI Repository describes the IDL interfaces defined to capture the meta information of SMI macros and their relationship with the interfaces defined in the CORBA IFR. The relationship between interfaces for SMI repository and IFR is based on the SMI to IDL Specification Translation mapping rules.

The SMI related information about the variables are obtained using VariableDef interface. VariableDef extends the CORBA::AttributeDef interface because according to the Specification Translation we have mapped SMI variables as IDL attributes. The attributes oid, smi_type and default_value, of the VariableDef interface can be used to obtain the SMI information. The name, IDL scoped name. access-mode and syntax information of the variable can be obtained from the name, id, mode and TypeCode information of the CORBA::AttributeDef interface.

The SMI related information about the table entries is obtained using the SmiEntryDef interface. The SmiEntryDef interface extends the CORBA::InterfaceDef because during the specification translation, SMI table entries are mapped as IDL interface. In addition to information provided by CORBA::InterfaceDef, SmiEntryDef interface provides a set of convenience operation optimized for SMI related operation. The var_name_list and var_scoped_name_list attributes of the SmiEntryDef interface can be used to get the names and IDL scoped names of the variables of a table/group in the lexicographic order of their OID. The oid attribute can be used to obtained the OID of a table-entry.





Figure: Interface Inheritance Hierarchy for SMI Repository Service


The SMI related information about the groups are obtained using the GroupDef interface. The GroupDef interface extends the SNMPMIR::SmiEntryDef because during the specification translation, SMI groups are mapped as if they are SMI table entry with single entry. In addition to information provided by SNMPMIR::SmiEntryDef, the GroupDef interface provides a convenience operation to obtain the list of table-entries in the group. The inherited SNMPMIR::SmiEntry-Def::names attribute can be used to obtain the names of the non-tabular variables of the group.

The SMI related information about the modules are obtained using the ModuleDef interface. The ModuleDef interface extends the CORBA::ModuleDef because during the specification translation, SMI modules are mapped as IDL modules. In addition to information provided by CORBA::ModuleDef, the SNMPMIR::ModuleDef interface provides a set of convenience operations optimized for SMI related operation. The smi_group_def_list attribute of the SNMPMIR::ModuleDef interface can be used to get the lists of references of the groups within the scope of the module. The smi_entry_def_list attributes can be used get the references of both the SmiEntryDef and GroupDef interface within the scope of the module. The push_notif_interface and pull_notif_interface attributes can be used to obtain the information about the Notification type macros.

Finally, the SMI Macro Repository interface (SNMPMIR::Repository) is a specialization of the CORBA information repository (CORBA::Repository). The SNMPMIR::Repository also inherits the OidRepository interface so that an application need not keep track of references to two repositories. The SNMPMIR::Repository interface is used to define a set of convenience operations to get the SMI related information from the repository.

The SNMPMIR::Repository is a container for all the SMI related modules that are registered with the CORBA IFR. According to the Specification Translation rules, the SMI related IDL module would not contain nested modules. So the name of a SMI based IDL module is sufficient to uniquely identify it in the repository. The SNMPMIR::Repository interface can be used to obtain the SmiEntryDef reference for a table-entry/group by providing the fully scoped name.

SNMPMIR Module

The SNMPMIR module contains the IDL types and interfaces needed to build the SNMP SMI repository extension of the CORBA interface repository.


Table: IDL types of SNMPMIR Module for SMI Information Repository





module SNMPMIR {
// Snmpv1GenericTrapId defines the identfiers for generic trap types in SNMPv1.
enum Snmpv1GenericTrapId {
TRAP_COLDSTART, TRAP_WARMSTART, TRAP_LINKDOWN, TRAP_LINKUP,
TRAP_AUTHFAIL,
TRAP_EGPNEIGHBORLOSS, TRAP_ENTERPRISESPECIFIC
};
// GENERIC_TRAP_ENTERPRISE_OID defines the enterprise OID for generic traps.
const ASN1_ObjectIdentifier GENERIC_TRAP_ENTERPRISE_OID = 1.3.6.1.4.1.3.1.1;
 
enum SmiAccessMode {
read_only, read_write, read_create, write_only, inaccessible };
 
enum SmiValueType {
smi_null_value, smi_integer_value, smi_string_value, smi_objectID_value,
smi_bit_value, smi_ipAddress_value, smi_counter_value, smi_gauge_value,
smi_timeticks_value, smi_arbitary_value, smi_nsapAddress_value,
smi_big_counter_value, smi_unsigned_integer_value, smi_unknown_type
};
 
typedef string FileName;
typedef CORBA::ScopedName ScopedName;
typedef sequence<ScopedName> ScopedNameList;
typedef sequence<string> VarNameList;
typedef sequence<string> ModuleNameList;
typedef sequence<ASN1_ObjectIdentifier> OIDList;

};


The SmiAccessMode type defines the enumerated values of the SMI based access-mode defined for a specific variables. The SmiValueType defines the enumerated values of the basic and application specific SMI types. The FileName type is used to specify the name of a file and it is defined for readability purpose. The OIDList type is a list of OID in dotted number form.

OIDRepository Interface

The IDL files generated for each SMI modules do not contain any OID information (in dotted number form) of variables, table-entries, groups and object identifiers. The OidRepository interface (as shown in SNMPMIR::OidRepository Interface) is defined to support operations for mapping OIDs in dotted number to textual names and textual names to OIDs. The OidRepository interface can also be used to query information about the OID tree hierarchy.


Table: SNMPMIR::OidRepository Interface





module SNMPMIR {

interface OidRepository {
ScopedName get_scoped_name( in ASN1_ObjectIdentifier in_oid );
string get_name( in ASN1_ObjectIdentifier in_oid );
 
ASN1_ObjectIdentifier get_oid( in ScopedName in_scoped_name );
ASN1_ObjectIdentifier get_var_oid(
in ScopedName iface_scoped_name, in string var_name );
 
string get_textual_obj_id( in ASN1_ObjectIdentifier obj_id );
void split_var_object_id(
in ASN1_ObjectIdentifier var_obj_id,
out ASN1_ObjectIdentifier var_oid, out ASN1_ObjectIdentifier obj_index
);
ASN1_ObjectIdentifier get_next_oid( in ASN1_ObjectIdentifier oid );
 
ScopedName get_next_scoped_name( in ScopedName scoped_name );
ScopedName get_next_entry_type( in ScopedName scoped_name );
 
boolean read_oid_file( in FileName file_name );
};

};


The OID Repository is initialized by reading in the OID files generated during specification translation of SNMP MIB information modules. During the initialization, SNMP module names are identified in the IFR and the corresponding OID files are read in. The OID files generated according to the Specification Translation mapping rules provide mapping between IDL scoped name and OID in dotted number form and SMI type information for variables.

This interface also supports operations for loading OID file for a specific MIB module. The read_oid() operation is defined to load OID information related to a new SNMP information module.

The get_name() and get_scoped_name() of SNMPMIR::OidRepository can be used to obtain the name and scoped-name respectively of a variable, group, table-entry or ObjectIdentifier constants, given its oid in dotted number form. The SNMPMIR::OidRepository can also be used to get the oid given a scoped name.

The SNMPMIR::OidRepository interface also provides operation to support SNMP get-next message. The OID Repository can be used to get the next OID for a given OID using the get_next_oid() operation. The get_next_scoped_name() operation returns the IDL scoped name given a IDL scoped name.

Note:
The OID Repository is only useful at the CORBA/SNMP gateway. In most MIB implementation and management applications, it would not be needed.

The get_scoped_name_by_oid() operation returns IDL scoped name of an item in Interface Repository (IFR) given the OID (in the dotted number form) of the item. For example,


oidRepoRef->get_scoped_name(1.3.6.1.2.1.1)
would return

RFC1213_MIB::system,
and

oidRepoRef->get_scoped_name(1.3.6.1.2.1.2.2.1.3)
would return

RFC1213_MIB::ifEntry::ifType.
If the OID does not exist in the repository then CORBA::OBJECT_NOT_EXIST exception is raised.

The get_name() operation returns the identifier of an item in IFR given the OID (in the dotted number form) of the item. For example,


oidRepoRef->get_name(1.3.6.1.2.1.1)
would return

system,
and

oidRepoRef->get_name(1.3.6.1.2.1.2.2.1.3)
would return

ifType.
If the OID does not exist in the repository then CORBA::OBJECT_NOT_EXIST exception is raised.

The get_oid() operation returns the OID of an item in the IFR given the IDL scoped name of the corresponding item. For example,


oidRepoRef->get_oid(RFC1213_MIB::system)
would return

1.3.6.1.2.1.1,
and

oidRepoRef->get_oid (RFC1213_MIB::ifEntry::ifType)
would return

1.3.6.1.2.1.2.2.1.3.
If the OID does not exist in the repository then CORBA::OBJECT_NOT_EXIST exception is raised.

The get_var_oid() operation returns the OID of a variable given the scoped name of the table-entry/group and textual name of the variable. For example,


oidRepoRef->get_oid(RFC1213_MIB::system, sysDescr)
would return

1.3.6.1.2.1.1,
and

oidRepoRef->get_oid(RFC1213_MIB::ifEntry, ifType)
would return

1.3.6.1.2.1.2.2.1.3.
If the var_name does not exist in the repository then CORBA::OBJECT_NOT_EXIST exception is raised.

The get_textual_obj_id() operation converts an obj_id in dotted number form into scoped name using largest prefix match, and returns a string by concatenating the scoped name for the matched obj_id and the unmatched part of the obj_id. For example,


oidRepoRef->get_scoped_name(1.3.6.1.2.1.1.1.0)
would return

RFC1213_MIB::system::sysDescr.0,
and

oidRepoRef->get_scoped_name(1.3.6.1.2.1.2.2.1.3.1)
would return

RFC1213_MIB::ifEntry::ifType.1.
If there is no such prefix match then a copy of the input OID is returned.

The split_var_object_id() operation splits an ObjectId into OID form using longest prefix match into two parts: var_oid and index-values. For example,


oidRepoRef->get_scoped_name(1.3.6.1.2.1.1.1.0)
would return

RFC1213_MIB::system::sysDescr
in var_oid and 0 in obj_index; and

oidRepoRef->get_scoped_name(1.3.6.1.2.1.2.2.1.3.1)
would return

RFC1213_MIB::ifEntry::ifType
in var_oid and 1 in obj_index. If there is no index information in the var_obj_id then a zero-length string is returned in obj_index. For example,

oidRepoRef->get_scoped_name(1.3.6.1.2.1.1.1)
would return

RFC1213_MIB::system::sysDescr
in var_oid and in obj_index.

The get_next_oid() operation returns the next OID in the OID hierarchy, given the input OID. Both input and returned OIDs are in dotted number form, the next being based on the lexicographic ordering of the OID as per GET-NEXT message. If there is no such OID in the OID hierarchy, then OBJECT_NOT_EXIST exception is raised. For example,


oidRepoRef->get_next_oid(1.3.6.1.2.1.1.1)
would return

1.3.6.1.2.1.1.2,
and

oidRepoRef->get_next_oid(1.3.6.1.2.1.2.1)
would return

1.3.6.1.2.1.2.2.

The get_next_scoped_name() operation is similar to get_next_oid(). but the input and output parameters in the corresponding IDL scoped name form. For example,


oidRepoRef->get_next_scoped_name(RFC1213_MIB::system::sysDescr)
would return

RFC1213_MIB::system::sysObjectID,
and

oidRepoRef->get_next_scoped_name(RFC1213_MIB::inter-faces::ifNumber)
would return .I "RFC1213_MIB::ifTable" .

oidRepoRef->get_next_scoped_name(s)
is equivalent to

oidRepoRef->get_scoped_name(oidRepoRef->get_next_oid(oidRepoRef->get_oid(s))).

The get_next_entry_type() operation returns the IDL scoped name of the next IDL interface for a group/table-entry. This get_next_entry_type() operation will always return IDL scoped name for a SMI group/table-entry that corresponds to a Specification Translation generated IDL interface name.

For example,


oidRepoRef->get_next_entry_type(RFC1213_MIB::mib_2)
would return

RFC1213_MIB::system;


oidRepoRef->get_next_entry_type(RFC1213_MIB::interfaces::ifNumber)

would return

RFC1213_MIB::ifEntry;
and

oidRepoRef->get_next_entry_type(RFC1213_MIB::ifEntry::ifIndex)
would return

RFC1213_MIB::ip
(RFC1213_MIB::at is inaccessible). If there is no such next entry in the repository then CORBA::OBJECT_NOT_EXIST exception is raised.

For each SNMP SMI module, an OID file is generated during specification translation. The name of the OID file for SMI information module is <smi-module-name>.oid where <smi-module-name> is the IDL identifier of the SMI module in ASN.1. The read_oid_file() operation reads the ScopedName/OID mapping table from the given input file. The file_name could be name of the file, or complete path name of the file.

VariableDef Interface

The VariableDef interface is defined to retrieve SMI specific information of a SMI variable. The VariableDef interface extends the CORBA::AttributeDef interface in order to provide information that is not available through CORBA::AttributeDef.


Table: SNMPMIR::VariableDef Interface.





module SNMPMIR {

interface VariableDef : CORBA::AttributeDef {
readonly attribute ASN1_ObjectIdentifier oid;
readonly attribute SmiValueType smi_type;
readonly attribute SmiAccessMode smi_access_mode;
readonly attribute any default_value;
};
typedef sequence<VariableDef> VariableDefList;

};


The attribute oid represent the ObjectIdentifier of the SMI variable. During specifictaion translation, the OID of a variable with scoped name M::I::V is mapped in M.oid file and this value is obtained using the repository interface.

The smi_type attribute represents the basic and application specific SMI type defined for the variable. During specification translation, the smi_type of a variable with scoped name M::I::V is mapped in M.oid file.

The smi_access_mode attribute represent the value of the MAX-ACCESS clause in the OBJECT-TYPE macro for the variable. According to the Specification Translation rules, the smi_access_mode of a variable with scoped name M::I::V is mapped in M.oid file.

During specification translation, the DEFVAL clause (if present) is mapped as <M>::DefaultVal-ues::<V>() operation for a variable with <M>::I::<V> scoped name. The default_value attribute can be obtained by invoking the <M>::DefaultValues::<V>() operation, where the scoped name of the variable is <M>::I::<V>. If the default value is not defined then CORBA::OBJECT_NOT_EXIST exception is returned.

VariableDefList type represents a list of VariableDef interfaces.

SmiEntryDef Interface

The SmiEntryDef interface represents SMI specific information associated with an IDL interface generated from an SMI module. The SmiEntryDef interface extends CORBA::InterfaceDef and provides information in an SMI centric way.


Table: SNMPMIR::SmiEntryDef Interface





module SNMPMIR {
....
interface SmiEntryDef : CORBA::InterfaceDef {
readonly attribute ASN1_ObjectIdentifier oid;
readonly attribute unsigned long total_no_of_variables;
readonly attribute VariableDefList var_def_list;
readonly attribute VarNameList var_name_list;
readonly attribute ScopedNameList var_scoped_name_list;
readonly attribute OIDList var_oid_list;
readonly attribute VarNameList index_var_names;
readonly attribute ScopedName next_group_or_table;
VariableDef lookup_variable( in string var_name );
};
typedef sequence<SmiEntryDef> SmiEntryDefList;

};


The oid attribute repreents the OID of this interface. According to the Specification Translation rules, the OID of a table-entry/group with scoped name M::I is mapped in the M.oid file.

The total_no_of_variables attribute represents the total number of SMI based variables in this interface.

The var_def_list attribute maintains the list of the VariableDef interfaces of the variables of this table-entry/group. It can be derived from the list of attributes of the interface. The list is ordered accroding to the lexicographic order of the OIDs of the variables.

The var_name_list attribute maintains the list of the names of the variables of this table-entry/group. It can be derived from the list of attributes of the interface. The list is ordered according to the lexicographic order of the OIDs of the variables.

The var_scoped_name_list attribute maintains the list of the IDL scoped names of the variables of this interface. IDL scoped name of the variable V is M::I::V where M::I is the scoped name of the interface for table-entry/group. The list is ordered according to the lexicographic order of the OIDs of the variables.

The var_oid_list attribute maintains the list of the OID of the variables of this interface. The list is ordered according to the lexicographic order of the OIDs.

The index_var_names attributes maintains the index variables of this interface. According to the Specification Translation rules, the INDEX clause of a table-entry is mapped as IDL string constant, called IndexVarList, within the scope of the IDL interface for the table-entry. Index var names are obtained by converting the value of M::I::IndexVarList of a table entry with scoped name M::I, into a sequence of strings (of individual index variables). If there is no IndexVarList (e.g. for IDL interface for groups) then a zero-length sequence is returned.

The next_group_or_table attribute represents the information about the next IDL interface for a group/table-entry according to the lexicographic OID order.

The lookup_variable() operation is a convenience operation that returns reference to VariableDef of a variable of this interface. s The SmiEntryDefList type represent a list of SmiEntryDef interfaces.

SmiGroupDef Interface

A group in SNMP SMI is a collection of tables and non-tabular variables. The GroupDef interface represents those IDL SmiEntry interfaces that are generated from SMI based groups. The SmiGroupDef interface extends SmiEntryDef and acts as a collection entity of table-entry interfaces.

The list of non-tabular variables can be obtained from the inherited var_def_list attribute.


Table: SNMPMIR::Groupdef Interface





module SNMPMIR {
....
interface GroupDef : SmiEntryDef {
readonly attribute SmiEntryDefList table_entry_list;
};
typedef sequence<GroupDef> GroupDefList;
....
};


The table_entry_list attribute maintains the list of the SmiEntryDef for the table-entries of this group.

SmiModuleDef Interface

SnmpModuleDef extends the CORBA::ModuleDef interface and provides SNMP SMI specific attributes and functions. An SNMPModuleDef contains a list of SNMP interfaces, and an interface object for push and pull notification interfaces.


Table: SNMPMIR::ModuleDef Interface





module SNMPMIR {
....
interface ModuleDef : CORBA::ModuleDef {
readonly attribute GroupDefList smi_group_def_list;
readonly attribute SmiEntryDefList smi_entry_def_list;
readonly attribute CORBA::InterfaceDef push_notification_def;
readonly attribute CORBA::InterfaceDef pull_notification_def;
readonly attribute CORBA::InterfaceDef default_value_def;
SmiEntryDef lookup_smi_entry( in string smi_entry_name );
};
typedef sequence<ModuleDef> ModuleDefList;
....
};


The smi_group_def_list attribute maintains the list of SMI specific groups in a SMI ionformation module.

The entry_interface_list attribute maintains the list of interfaces which are subtype of SNMP-Mgmt::SmiEntry defined within the scope of this module. This list includes SmiEntryDef interfaces for all the groups and table-entries of this module.

According to the Specification Translation rules, a push notification interface is defined with IDL scoped name M::Notifications for SMI MIB module with name M. The push_notification_def attribute maintains the reference to InterfaceDef for the M::Notifications interface. If no such interface is defined then a nil object-reference is returned.

According to the Specification Translation rules, a pull notification interface is defined with IDL scoped name M::PullNotifications for SMI MIB module with name M. The pull_notification_def attribute maintains the reference to InterfaceDef for M::PullNotifications interface. If no such interface is defined then a nil object-reference is returned.

According to the Specification Translation rules, a Default value interface is defined with IDL scoped name M::DefaultValues for SMI MIB module with name M. The default_value_def attribute maintains the reference to InterfaceDef for M::DefaultValues interface. If no such interface is defined then a nil object-reference is returned.

The lookup_smi_entry() operation returns the SmiEntryDef for the specified group/table-entry interface within the scope this SMI module.

The ModuleDefList type represents a list of ModuleDef interfaces.

Repository Interface

The SNMPMIR::Repository interface extends the CORBA::Repository interface. It provides SNMP SMI specific specialization of CORBA Interface Repository (IFR) interface. The SNMPMIR::Repository interface inherits the CORBA::Repository and the SNMPMIR::OidRepository interfaces.


Table: SNMPMIR::Repository Interface





module SNMPMIR {
....
interface Repository : CORBA::Repository, OidRepository {
readonly attribute ModuleNameList module_name_list;
readonly attribute ModuleDefList module_def_list;
boolean is_smi_module( in CORBA::Identifier module_name );
ModuleDef lookup_smi_module( in string a_module_name );
SmiEntryDef lookup_smi_entry( in ScopedName entry_scoped_name );
ScopedNameList get_entry_var_list( in ScopedName entry_scoped_name );
ScopedNameList get_entry_index_var_list( in ScopedName
entry_scoped_name );
any get_var_default_value( in ScopedName var_scoped_name );
string get_generic_trap_desc( in ASN1_Integer trap_type );
};

};


The module_name_list attribute maintains the list SNMP SMI specific IDL module names in the IFR.

The module_def_list attribute maintains the list SNMPMIR::ModuleDef interfaces for the SNMP SMI specific IDL module names in the IFR.

The lookup_smi_entry operation returns the interface def of a specific SNMP table-entry/group. The entry_scoped_name attribute is specified as M::I.

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