Management information to object mapping and correlator6317748Abstract A method and system to provide management information of network devices by mapping between SNMP MIB module schema and Common Information Model (CIM) schema. MIB modules are tree-structured lists of objects for describing SNMP network device information, whereas CIM schema employs user-intuitive, object-oriented classes to model such information. A mapping process enumerates the MIB objects and then maps the objects into CIM Managed Object Format (MOF) classes using defined mapping tables. A correlation mechanism is further provided to efficiently determine in real time which MIBs (or portions thereof) and corresponding CIM classes a network device supports. Claims What is claimed is: Description FIELD OF THE INVENTION
Class Disk
{
string Volume;
string FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace;
};
This class models a disk wherein the four property fields describe individual aspects of a disk. While most classes are representation objects for real-world devices, there is no restriction on the content, or the application of the class to a particular managed object, although a particular CIM implementation may place limits on the number of properties in a class, the types of properties, or other similar limits. As in object-oriented paradigms, classes can be derived from superclasses. A derived class implicitly inherits or contains the entire contents of the superclass. For purposes of simplicity, the present CIM meta-model supports single inheritance only, although more complex inheritance models are feasible. As used with respect to CIM, the terms base class and superclass may be used interchangeably to indicate a parent, while the terms derived class or subclass may be used to indicate a child class. The fields of a class definition are called properties, and are named values subject to naming guidelines in a CIM implementation. A wide range of sized integer types are supported (both signed and unsigned), along with IEEE four and eight byte floating point values, UNICODE strings, dates and times, and other known types. Further refinement of the semantics of property values is achieved through the use of qualifiers. By way of example, qualifiers applied to properties may give additional semantics of properties, such as whether a 32-bit integer is actually a `counter` or a `gauge` property type. A class defines a template for describing managed objects. Based on a class definition, specific managed objects are defined using one or more instances of that class. If a class uniquely describes only one instance, it is referred to as a singleton class. Where the class models the real-world device or component in the general sense, each instance represents a specific occurrence of the class. Continuing with the above example in which a general (singleton) class called Disk was described, an instance of this previously described Disk class might appear in the MOF syntax as in the table below:
Instance of Disk
{
Volume = "DISKC";
FileSystem = "XFS";
TotalCapacity = 240000000;
FreeSpace = external;// Dynamically supplied by instrumentation
};
Note that since the FreeSpace parameter is highly volatile, in a typical implementation the value would be supplied by a provider 72, rather than being a stored or static value. As described in more detail below, the CIMOM 70 is capable of retrieving both the static and dynamic information from various sources including the CIM database 74 and/or appropriate providers 72, and returning the object instance to the application 58. In keeping with CIM, the database 74 and/or providers 72 provide their portion of the information without knowledge of its final destination, i.e., the identity of the client process, and the application 58 receives this information transparently, i.e., as instances of the class disk without knowledge of its actual source or sources. A Qualifier is a modifier applied to a class definition, an instance, or a property. Qualifiers constitute meta-data, and are generally, though not necessarily, non-essential modifiers, in that removal of the qualifier should not substantially change the meaning of what was being modified. In MOF syntax, qualifiers are indicated by preceding a list of declarations, delimited by square brackets, as shown in the table below:
[description("This class models a disk")]
class Disk
{
string Volume;
[description("The name of the filesystem")] string FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace; };
While the above qualifiers give additional information, their removal does not invalidate the definition of Disk. The presence and values of qualifiers may vary between CIM installations, even for the same class definitions. In general, if removal of a qualifier would seriously alter a class or instance definition, then that qualifier should be re-implemented as a property. Any number of user-defined qualifiers may be applied to class definitions, instances, or any of the properties. As in relational database models, instance identification for a class capable of describing multiple instances (i.e., a keyed class) is done through the use of keys. Using the table and column model common to relation databases, the table corresponds to a CIM class, and the rows correspond to CIM instances. The column or columns which uniquely identify the row are designated as keys. Key properties are designated by attaching a qualifier named `key` to each property that constitutes the key for the class. Key qualifiers can be attached to more than one property to create a compound key. Using the MOF Syntax as an illustration, the Volume property has been designated as the key for the Disk class as shown in the table below:
Class Disk
{
[key] string Volume;
string FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace;
};
The above definition of Disk specifies that the Volume property is used to distinguish instances within the class Disk (and its derived classes), and that there is one unique value of Volume for each real disk on the machine. The other property values can be duplicated across instances. For example, many volumes could support the same FileSystem or TotalCapacity values, and thus such properties would be poor choices for instance discrimination. Certain rules for selecting and using keys apply. For any given class hierarchy, once a key has been introduced it may not be overridden or supplemented by any derived classes. For example, an abstract class SystemElement could be introduced which defines no properties at all, so it would be legal to derive several other classes from it, each introducing their own particular key values. However, no derived classes of each of those subclasses could in turn introduce their own keys. In sum, classes inherit the key of any superclass, if there is one, and only if there is not a key value in the superclass chain is a class permitted to introduce its own key. Since CIM instances belong to a class and reside in a particular namespace on a particular host, some method of locating or referring to a particular object is required. This takes the form of an Object Path, which is conceptually similar to a URL (Uniform Resource Locator). Object paths come in several varieties. They can be relative to a particular server, relative to the entire network, or relative to a particular namespace, just as file paths in a file system may be relative to a particular sub-directory or volume. As an illustration, a full network-relative object path might appear as //myhost/root/default:disk.volume="C", wherein the first field after the leading double-slash is the server address (network address or host name, i.e., "myhost"). This is followed by the relevant namespace ("root/default") within that server, and the class ("disk") of the desired object. Finally the key values (the property "volume" whose value is "C"), which uniquely designate that instance within the class, are specified. A Namespace is a fundamental grouping unit for sets of classes and instances. A namespace has an effect on the scoping of classes within it. By default, the instances of a class are private to a particular namespace, i.e., instances with the same key may exist in another namespace, but two instances of a class with matching keys are considered to be the same instance within a namespace. By default, a class definition is private to each namespace. However, any given class, while present in more than one namespace, may not have a definition which is at variance from its definition in another namespace. A system is permitted to have single copies of class definitions for its supported namespaces and use reference counting or other mechanisms for the sake of efficiency. Namespaces can be nested in a manner similar to a hierarchical file system. In relational database terminology, a Namespace is similar to a database, except that nesting is possible. The base namespace for all CIM implementations comprises the classes and instances constituting the representation objects for the local host device or machine. Namespaces can be manipulated through the use of the standard system class _Namespace. Creation of an instance of class _Namespace results in the creation of a real logical namespace within the CIM implementation. Note that there are two objects involved, the representation object and the actual namespace itself. Thus, an instance of _Namespace is a representation object for a real database namespace. Deletion of the _Namespace object results in deletion of all the classes and instances within that Namespace as well as deletion of the Namespace itself. Querying for instances of _Namespace is equivalent to querying for the actual list of namespaces supported by the CIM installation. A special type of property called a reference is supported within CIM. This property is a "pointer" to another class or instance within the schema. A reference takes the form of a string which contains an object path. A special type of class which contains a pair of references is called an Association. Instances of association classes are used to set up a binding relationship between two other objects. For example, while it is possible for each of objects A and B to contain reference fields which point to each other, this would entail designing the class to contain a reference property from the outset. In many cases, it may not be known at class design-time which objects may require references to each other. Instead, classes are ordinarily designed to contain no assumptions about relationships in which they may participate. Instead, an association class C can be created after classes A and B are created, wherein C can contain two reference property fields, one which is designated as pointing to instances of A, and the other as pointing to instances of B. In this manner, associations can be used to create object relationships without the knowledge or participation of the objects themselves. Likewise, relationships can be removed without affecting the objects. In a more specific example, it may sometimes be useful to associate a NetworkCard object with a NetworkProtocol object using a dedicated association class called NetCardToProtocolBinding. This is a desirable model, since a card may support more than one protocol, and the same protocol may be running over more than one network card on the host machine. The association objects describe the complex relationships without the more primitive objects being aware of it. In order to deal with queries in a uniform manner, the CIMOM 70 supports the Execute Query protocol operation and preferably supports at least a minimal subset of ANSI SQL. Of course, additional query languages may be supported. In general, SQL specifies the syntax for a simple form of `select` statements for executing read-only queries. Using this syntax, CIM classes (which may be stored in the CIM repository or retrieved from some source on the network) are represented as tables and CIM properties as columns, resulting in a natural SQL-like mapping. The result set of such a query is always a set of CIM instances. By way of example, assume an administrator wants to locate all network disk drives that are running low on free disk space. As shown in FIG. 4, through a management application 58, the administrator submits to the CIMOM 70 an SQL query 80, --"select*from LogicalDisk where FreeSpace<20000000"--. The CIMOM 70 works in conjunction with one or more providers 76 and (as necessary) complements the capabilities of the providers to return a result set 82 comprising uniformly rendered managed objects. For example, the provider may not be capable of processing queries in high-level languages such as SQL, but may only be able to return a list of all the instances it supports. In this case, CIMOM 70 may transparently translate the user's high-level query into a series of simple retrievals and then perform the query internally on behalf of the user, giving the user the impression that the provider directly supported the query. Thus, the above-query results in a set of CIM objects (instances) of class LogicalDisk where the property value for FreeSpace is less than twenty million bytes. Each operation within the CIM schema is modeled as a separate protocol operation. For example, most servers acting as CIMOMs will support class creation and update, class retrieval, class deletion, and instance creation and update, instance retrieval, instance deletion, and query execution. Each of these has a corresponding protocol operation. Servers acting as providers may only support one or two operations, such as "Get Instance" and "Put Instance." For example, to retrieve an instance of a particular class, the protocol operation "Get Instance" is used. Once the instance is obtained, it may be necessary to consult the class definition itself, and so a "Get Class" operation is executed. Lastly, in a distributed environment, a client will construct a request packet for the desired protocol operation and send it to the server using an underlying network transport protocol, such as TCP. The reply packet or stream typically contains the result of the operation, or an error packet detailing why the operation could not be completed. Common Information Model SNMP Mapping As shown in FIGS. 2-4, each network device provides information according to the SNMP standard for managing devices and for representing management data, i.e., via MIBs. As described above, MIBs are complex, tree-based structures, while the CIMOM 70 is set up to ideally operate with CIM objects. In accordance with one aspect of the present invention, there is provided a system and method that maps MIB information to CIM classes. FIG. 5 shows the general components for accomplishing the mapping. As shown in FIG. 5, the set of MIBs in a CIM installation are maintained in a repository known as an SNMB MIB repository (SMIR) 86. In a CIM installation, each MIB such as the MIB 66.sub.3 is extracted from the SMIR 86 and translated by a SMI (Structure of Management Information) compiler 88 into a CIM object class 90, which is then provided to the CIMOM 70 and stored in the CIM repository 74. To this end, the SMI compiler references a number of mapping tables 92 to facilitate the translation. As dynamic information comes in from the SNMP device through the class provider 72.sub.3 and instance provider 72.sub.4, the CIMOM 70 is able to combine the dynamic information with the static MIB information now in the form of CIM classes to produce some desired instance output. In general, in addition to a name, (module identity), a MIB contains two types of structures for describing dynamic device data, scalar collections and table collections. Scalar collections are collections of device properties having one unique value. Table collections can be thought of as having rows that describe multiple instances of a given type definition. A MIB object type macro defines the structure of a given property and uses OIDs to define the namespace in the MIB tree structure wherein this information is stored. For example, a MIB might include the macro set forth in the following table:
myDescr OBJECT-TYPE
SYNTAX OCTET STRING ( SIZE ( 0 . . . 255 ) )
ACCESS read-only
STATUS mandatory
DESCRIPTION "My Scalar Description"
::= { 1.3.6.1.4.1.311.1 }
This identifies a scalar property "myDescr" of type string having read only access located at 1.3.6.1.4.1.311.1. Any number of such scalars may be in a MIB module. Similarly, a MIB may include one or more table collections, as set forth below:
myTable OBJECT-TYPE
SYNTAX SEQUENCE OF MyEntry
ACCESS not-accessible
STATUS MANDATORY
DESCRIPTION "My Table Description"
::= { 1.3.6.1.4.1.311.2 }
myEntry OBJECT-TYPE
SYNTAX MyEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "My Entry Description"
::= { 1.3.6.1.4.1.311.2.1 }
MyEntry ::= SEQUENCE {
INTEGER myKeyProperty ,
OCTET STRING myValueProperty
}
myKeyProperty OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "My Key Property"
::= { 1.3.6.1.4.1.311.2.1.1 }
myValueProperty OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION "My Value Property"
::= { 1.3.6.1.4.1.311.2.1.2 }
In accordance with one aspect of the present invention, objects present within a table collection will map to properties of a CIM (which may be textually represented by MOF) keyed class definition (described above), while objects present within a scalar definition will map to properties of a singleton CIM class definition. For keyed CIM object classes, the keys are taken from the `INDEX` clause of the table collection. Note that an index may be an SMI type (i.e., the table is accessed by an integer) or a property as shown above (i.e., the table is accessed by type which is also a property value). FIG. 6 generally represents the mapping process in the SMI compiler 88 for processing the MIB tree structure. First, at step 600, the collections identified in the MIB 66.sub.3 are enumerated. These scalar and table collections are then processed to translate them into CIM classes. To this end, step 602 begins by selecting the first collection, and step 604 determines whether the type is a scalar or table collection. Scalar collections are objects whose direct parent in the MIB tree is a named node. Objects having the same named parent are grouped together so that they will be placed in the same CIM class. In contrast, table collections are identified by a macro whose syntax includes the text "SEQUENCE OF . . . ." In addition, although not necessary to the present invention, the subtrees under a table collection may be examined to ensure that a collection having this sequence is indeed a table collection. If step 604 determines that the MIB object is a scalar collection, the MIB object is mapped to a singleton class at step 606 (note that objects with a common parent share a class definition). This is a relatively straightforward operation, comprising extracting the MIB object name and basing a CIM class name thereon, (e.g., a prefix plus "SNMP" plus the MIB module name plus the name of the common parent), and then extracting the properties from the MIB object. These properties are then placed in the CIM class, by translating the various MIB types, textual conventions and so on to MOF counterparts using predefined mapping tables 92. CIM qualifiers are also used, such as to correspond to the MIB object's object type and access information. For purposes of simplicity, the various tables and other translation information are not set forth in detail herein, since a CIM to SNMP mapping specification, including the actual mapping tables, is attached hereto as Appendix A. If instead step 604 determines that the object is a table collection, the compiling process branches to step 608 wherein the MIB object is mapped to a CIM keyed class that is capable of describing more than one instance. Again, this is a relatively straightforward operation, comprising essentially the same process as for scalar collections, i.e., extracting the MIB object name and basing a CIM class name thereon, and translating the various MIB types, textual conventions and so on to CIM counterparts using predefined mapping tables 92. However, in addition, the keys of the keyed class are extracted from the `INDEX` clause of the table collection, which specifies a list of items, each item in the list being either an SMI type or a property name, that serves as one of the keys of the table. Step 612, which detects the end of the enumerated objects, loops back as necessary to repeat the mapping process for the other enumerated objects of the MIB 663. Lastly, it should be noted that mapping of TRAP-TYPE and NOTIFICATION-TYPE macro definitions is performed in substantially the same manner as for OBJECT-TYPE macros, except that it applies to event notifications. Essentially an event is some notification of a change in configuration or state of a management entity, wherein the semantics associated with that change are reflected in the name of the class and the properties within that class. In SNMP, events are modeled as TRAP-TYPE and NOTIFICATION-TYPE macros, whereas with CIM, events are simply class definitions. Thus, TRAP-TYPE macro and NOTIFICATION macros are mapped to CIM classes using the mapping procedure as set forth Appendix A. The event notification places an instance of the CIM class in the event notification. SNMP MIB Correlator As described above, a particular device supports only a subset of the MIBs (and thus the corresponding CIM classes compiled therefor) out of the (possibly) large set of possible MIBs (and compiled classes). In accordance with another aspect of the present invention, a correlation mechanism 94 (FIG. 7) is provided to determine in real time the subset of SNMP CIM classes that are supported by a particular network device. Correlation is performed on a group basis. An SNMP group is a collection of one or more scalars and/or tables that exist directly under a single named node in the MIB hierarchy. It does not include any other nodes that may also exist under such a node. Note that scalars and tables may exist in the gaps between the direct subgroups of a group. For purposes of simplicity, all aspects of correlation will not be described herein in detail, as a correlation specification is attached hereto as Appendix B. However, it is noted that a group may be the parent of subgroups, and in turn, a subgroup may also be the parent of subgroups. Note that a subgroup has the parent group's object identifier as part of its object identifier root, e.g., 1.2.4.2 may be a subgroup C of the group B (OID of 1.2.4), such as represented in FIG. 8. Groups are relatively straightforward in that the scalars and tables in one group (e.g., group A) that is lexicographically before another group (e.g., group B) appear before the scalars and tables of that other group. However, with subgroups, this is not necessarily true. For example, consider two groups B and C having OIDs of 1.2.4 and 1.2.4.2, respectively. Lexicographically C comes after B, but B can have only one scalar with an object identifier before that of C, namely 1.2.4.1. If this is the only entity belonging to B that is supported, then all of C's tables and scalars will appear after B. However, if B has a scalar with an OID of 1.2.4.3, then the scalars and tables of C will now come before those of B. Furthermore, B can have both of scalars 1.2.4.1 and 1.2.4.3, in which case the scalars and tables of C will appear in between those of B. However, as will be described below, the correlation mechanism of the present invention traverses the groups and subgroups in a manner that builds a list of lexicographically ordered ranges that are used to efficiently determine the objects supported by a device. As shown in FIG. 7, the correlation mechanism comprises two parts, including a process 96 for creating a range table 98 and a process 100 which uses the range table 98 to efficiently query the device determine which groups (and thus which classes) are supported by a given device. A range table 98 is an ordered table of OID ranges corresponding to the MIB groups and subgroups stored in the SMIR 86. To create a range table 98, it is first noted that SNMP group object identifiers in the SMIR 86 are ordered lexicographically according to their OID, i.e., each component is essentially considered to be a single `character` having that component's numerical value. In other words, groups are sorted on a logical representation of the object identifier rather than on the string representation. For example, the group OIDs are ordered such that OID 1.1<1.2<1.2.1<1.2.1.5<1.3. From the MIB groups, a set of mutually exclusive ranges is created for each group (a group may have several other groups contained within its range). These ranges are ordered lexicographically, the result being the range table 98. By way of example, a small tree of groups and subgroups is shown in FIG. 8, a range table 98 created therefrom is shown in FIG. 9, and FIG. 10 exemplifies steps which may be taken by the range construction process 96 to construct the range table 98. Note that the groups and subgroups for the MIBs in a typical SMIR will construct a tree having many thousands of groups and subgroups, however the correlation mechanism of the present invention is scalable to handle any number of groups. As represented in FIG. 10, step 1000 begins by selecting the first group in lexicographical order, i.e., using a left to right, top-down, ordering. Thus, as represented in the tree of FIG. 8, the first group selected by the process 96 is the group A. Also at step 1000, since A is a group and not a subgroup, a variable (hereinafter referred to as "MaxUnderGroup") which tracks the maximum range OID under the current group (group A) is set to the group OID of group A, 1.2.2. Then, at step 1002, the tree is essentially examined to determine whether the currently selected group A is a parent of a subgroup that has not yet been handled by the range table construction process 96. In the tree of FIG. 8, group A does not have any subgroup thereunder, and the step 1002 thus branches to step 1004 to add a range to the range table 96. At step 1004, Group A is entered into the table in association with a range having a starting OID equal to the maximum thus far under the group, (as stored in the MaxUnderGroup variable), which is group A's OID of 1.2.2. Next, since Group A has no subgroups, the end OID for the entered range is set based on (i.e., set to just exceed) the highest possible OID for that group, by adding one to the last value, i.e., 1.2.3. As can be readily appreciated, this specifies a range of OIDs into which scalars and tables may possibly fall. Thus, as shown in FIG. 9, the first range entered into the range table 98 identifies group A within a range from 1.2.2 to 1.2.3. As can be readily appreciated, if a network device returns a table or scalar OID in this range, then the network device supports (at least some of) the classes under group A. Step 1006 changes the MaxUnderGroup variable to the end OID that was placed in the range table 98. Step 1008 then tests to determine if all of the selected group (group A) including any subgroups thereunder have been handled by this process 96. In the present example, group A has no subgroups, and thus step 1008 branches to step 1012 to determine if all groups in the tree have been likewise handled, whereby if so, the range table construction process 96 is done (and thus ends). In the present example however, group B has not yet been handled, and thus the process returns to step 1000 where group B is selected. Since group B is a group, (as opposed to a subgroup), the MaxUnderGroup variable is also set at step 1000 to group B's OID of 1.2.4. Step 1002 is next executed, however this time, step 1002 determines that the selected group B has subgroups thereunder that have not yet been handled, starting with subgroup C. As a result, step 1002 branches to step 1014 which writes group B into the range table with an associated starting range OID of 1.2.4, and an end range OID equal to that of the next unhandled subgroup's OID, subgroup C, which has an OID of 1.2.4.2. Next, step 1016 sets the MaxUnderGroup variable equal to that of the highest OID thus far recorded in the table of any group or subgroup under group B, that is, subgroup C's OID of 1.2.4.2. The process 96 then returns to step 1000 where the next subgroup, subgroup C, is selected. At step 1000, the MaxUnderGroup OID variable is not changed since group C is not a group, but rather a subgroup. Then, step 1002 detects that selected group C also has an unhandled subgroup, beginning with subgroup F, whereby step 1002 branches to step 1014. Step 1014 records group C in the range table with a start OID equal to the current MaxUnderGroup value (1.2.4.2) and an end OID equal to the next unhandled subgroup's OID, (i.e., subgroup F, having an OID of 1.2.4.2.4). Step 1016 is next executed, which changes the MaxUnderGroup variable to this end OID, 1.2.4.2.4, before returning to step 1000 to select the next subgroup. The next subgroup at step 1000 is the subgroup F. Since it is not a new group, the OID saved in the MaxUnderGroup variable is not changed, and the process continues to step 1002. Subgroup F does not have any unhandled subgroup(s) thereunder, and as a result, step 1002 branches to step 1004, wherein the start OID of the group F is recorded in the range table as the value stored in the MaxUnderGroup variable, 1.2.4.2.4. Again, since F has no subgroup, the end OID is set based on this value plus by adding one to the last digit, i.e., 1.2.4.2.5 (FIG. 9). At step 1006, the MaxUnderGroup variable is then set to this higher end OID value of 1.2.4.2.5. Step 1008 tests to determine if all of the group B has been handled. More particularly, this occurs when the selected node is a group (not a subgroup) and all subgroups under that group have been handled in the above manner by the range table construction process 96. Since subgroup F is not a group, nor have all subgroups under B been handled, step 1008 branches to step 1010 wherein the parent of the subgroup F, subgroups C, is again selected as the selected node. Step 1010 returns to step 1002 where it is determined that subgroup C has another subgroup that has not been handled, subgroup G. Thus, step 1002 branches to step 1014 wherein group C is again entered into the range table 98 (FIG. 9) with a start OID equal to 1.2.4.2.5 (from the MaxUnderGroup variable) and an end OID of 1.2.4.2.8 (from the OID of Group G). At step 1016, the MaxUnderGroup variable is set to this end OID of 1.2.4.2.8, and the process returns to steps 1000 wherein subgroup G is selected as the current node. As can be appreciated by following the above examples, subgroup G is entered into the range table at step 1004 with a start OID of 1.2.4.2.8 and an end OID of 1.2.4.2.9. Note that when step 1010 is later executed, subgroup C is again selected as the selected node. However, when subgroup C is next evaluated at step 1002, it will not have an unhandled subgroup, since its subgroups F and G have previously been handled as described above. Thus, subgroup C again will be entered into the table, however this time via step 1004, and thus will have a range from 1.2.4.2.9 to 1.2.4.3 (based on subgroup C's OID plus one). Then, at step 1010, the parent of subgroup C, i.e., group B, is again selected, and the process returns to step 1002. For purposes of simplicity, a description of these steps will not be repeated in detail for the remaining groups and subgroups. As can be readily appreciated from following the steps of FIG. 10 in conjunction with the tree of FIG. 8, the table will be completed as shown in FIG. 9. Note, however, that via this process, a range for group B is again entered the next time through the steps, followed by a range for group D, then for group B again, then for group E, and lastly for group B again. Traversing the tree in this manner solves the lexicographical complications (described above) with respect to subgroups. At this time, a range table has now been created which may be used to determine which MIBs a device supports. Of course, the range table may be constructed once and persistently stored to avoid having to recreate it for each device, (and thereafter recreated such as only when new MIBs are added). Once the range table 98 (FIG. 9) has been constructed, the ranges therein are used to determine which MIBs (and thus correspondingly mapped classes) a given device supports. To this end, the second part of the correlation mechanism 94 comprises the process 100 which applies the range values in a logical fashion to the device via a SNMP GetNext function. GetNext provides an OID to a device, and requests the device to return its next OID that lexicographically follows the provided OID. Using the returned OID, the supported classes may be rapidly and efficiently determined. More particularly, as shown in FIG. 11, the process 100 begins at step 1100 by selecting the OID at the start of the next range, which at this time is the start OID of the first range, 1.2.2. At step 1102, this OID is used with the SNMP GetNext function to receive an OID from the device. For example, the device may return a scalar or table OID of 1.2.4.2.5.1, which, as determined by step 1104, falls into the second C range in the table, i.e., the range associated with the subgroup C entry that ranges from 1.2.4.2.5 to 1.2.4.2.8. Since this OID is beyond any of the first four ranges in the table (as entered for groups A, first B, first C and F), the device does not support the classes under this part of these groups and thus these lower ranges may be eliminated (step 1106). Next, since the returned OID fell into a group C range, it is known that group C is supported, and is thus marked accordingly at step 1108. For example, a bit mask may be maintained which has a bit for each group, and when a group is supported, the bit corresponding thereto is set in the bitmask. Moreover, because group C is already known to be supported, any further ranges associated with group C need not be tested and are thus eliminated from the range table at step 1110, i.e., a check for range entry (C, 1.2.4.9.1) is unnecessary. As can be readily appreciated, each such GetNext operation can significantly reduce the number of entries remaining in the range table. Further, it should be noted that groups A and F are absent as all of their range entries have been skipped, however, while a range entry for B has been skipped, its other range entry has not yet been reached, and thus group B may still be supported. Step 1112 causes the process to repeat until no more entries and associated ranges remain in the range table. Thus, the next range to be tested will select (G, 1.2.4.2.8) for the SNMP GetNext operation. As described above, subsequent GetNext operations will use the lexicographically lowest object identifier of a group not already identified that has as an object identifier lexicographically larger than the result of the previous GetNext. Once completed, the marked subgroups identify those MIB objects and corresponding CIM classes supported. The correlation mechanism provides a generic and scaleable method of determining the set of groups supported by an arbitrary SNMP agent. Indeed, the mechanism is still practical when the SMIR contains information from a very large number of MIBs and/or when the device being correlated supports a large number of groups. As can be readily appreciated, the correlation mechanism is highly efficient in that most of the overhead is done prior to transmitting request packets to the device. Then, for each OID is returned, it is possible to eliminate many of the possible ranges based on the value, yet without skipping any potential groups. Moreover, as an optimization, a single request packet may include multiple GetNext requests. This returns multiple OIDs with less transmission overhead, from which additional group information may be deduced. For example, if a device is not able to return an OID above some upper value sent, but instead returns an appropriate errorcode, then entries in the range table may be simultaneously reduced from both the low end and high end to narrow in on the supported groups. While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||