Patent Grant
7555743
This application is related to Zhao et al., Ser. No. 10/868,408, entitled “Run-Time Tool for Network Management Application,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Sridner et al., Ser. No. 10/868,375, entitled “Resource Definition Language for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Brunell et al., Ser. No. 10/868,239, entitled “View Definition Language for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Brunell et al., Ser. No. 10/868,656, entitled “Distribution Adaptor for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Zhao et al., Ser. No. 10/868.250. entitled “Event Management Framework for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Sridner et al., Ser. No. 10/868,327, entitled “Man aged Object Framework for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
This application is related to Shen et al., Ser. No. 10/868,217, entitled “Data Management and Persistence Frameworks for Network Management Application Development,” filed Jun. 15, 2004, commonly assigned to Lucent Technologies, Inc. and incorporated by reference herein.
The invention generally relates to a reusable asset center (RAC) framework in a development environment for network management applications and, more particularly, to a simple network management protocol (SNMP) agent code generation within the development environment and an SNMP agent framework (SAF) within the RAC framework that together provide network management applications with SNMP functionalities between one or more network elements and a network management station (NMS).
While the invention is particularly directed to the art of network management application development, and will be thus described with specific reference thereto, it will be appreciated that the invention may have usefulness in other fields and applications.
By way of background, Guidelines for Definition of Managed Objects (GDMO) and Structure for Management Information (SMI) are existing standards for defining objects in a network. Managed objects that are defined can be accessed via a network management protocol, such as the existing Simple Network Management Protocol (SNMP). Various standards, recommendations, and guidelines associated with GDMO, SMI, and SNMP have been published. GDMO is specified in ISO/IEC Standard 10165/x.722. Version 1 of SMI (SMIv1) is specified in Network Working Group (NWG) Standard 16 and includes Request for Comments (RFCs) 1155 and 1212. Version 2 of SMI (SMIv2) is specified in NWG Standard 58 and includes RFCs 2578 through 2580. The latest version of SNMP (SNMPv3) is specified in NWG Standard 62 and includes RFCs 3411 through 3418.
ISO/IEC Standard 10165/x.722, GDMO, identifies: a) relationships between relevant open systems interconnection (OSI) management Recommendations/International Standards and the definition of managed object classes, and how those Recommendations/International Standards should be used by managed object class definitions; b) appropriate methods to be adopted for the definition of managed object classes and their attributes, notifications, actions and behavior, including: 1) a summary of aspects that shall be addressed in the definition; 2) the notational tools that are recommended to be used in the definition; 3) consistency guidelines that the definition may follow; c) relationship of managed object class definitions to management protocol, and what protocol-related definitions are required; and d) recommended documentation structure for managed object class definitions. X.722 is applicable to the development of any Recommendation/International Standard which defines a) management information which is to be transferred or manipulated by means of OSI management protocol and b) the managed objects to which that information relates.
RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets, describes the common structures and identification scheme for the definition of management information used in managing TCP/IP-based internets. Included are descriptions of an object information model for network management along with a set of generic types used to describe management information. Formal descriptions of the structure are given using Abstract Syntax Notation One (ASN.1).
RFC 1212, Concise Management Information Base (MIB) Definitions, describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. It is intended that all future MIB modules be written in this format. The Internet-standard SMI employs a two-level approach towards object definition. An MIB definition consists of two parts: a textual part, in which objects are placed into groups, and an MIB module, in which objects are described solely in terms of the ASN.1 macro OBJECT-TYPE, which is defined by the SMI.
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the MIB. Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's ASN.1. RFC 2578, SMI Version 2 (SMIv2), defines that adapted subset and assigns a set of associated administrative values.
The SMI defined in RFC 2578 is divided into three parts: module definitions, object definitions, and, notification definitions. Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification.
RFC 2579, Textual Conventions for SMIv2, defines an initial set of textual conventions available to all MIB modules. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the MIB. Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's ASN.1, termed the SMI defined in RFC 2578. When designing an MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. Objects defined using a textual convention are always encoded by means of the rules that define their primitive type. However, textual conventions often have special semantics associated with them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the syntax and semantics of a textual convention.
RFC 2580, Conformance Statements for SMIv2, defines the notation used to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved, for management information associated with the managed objects.
Network elements need a way to define managed resources and access/manage those resources in a consistent and transparent way. GDMO does not provide a straight forward approach to defining resources. SMI does not provide for an object-oriented design of network management applications. Neither standard provides sufficient complexity of hierarchy or sufficient complexity of control for management of today's complex networks, particular today's telecommunication networks.
The present invention contemplates an SNMP agent code generator and a RAC framework with an SAF for generation of SNMP agent code in a development environment for network management applications that resolves the above-referenced difficulties and others.
A method of developing one or more application programs that cooperate to manage a distributed system comprising one or more servers is provided. At least one application program is associated with each server. In one aspect, the method includes: a) defining one or more managed objects associated with the distributed system in an object-oriented resource definition language and storing the definition of the one or more managed objects in one or more resource definition language files, wherein the definition of the one or more managed objects is based on an existing design and hierarchical structure of the distributed system, wherein parent-child relationships between the one or more managed objects are identified in the one or more resource definition language files using the object-oriented resource definition language to define the one or more managed objects in relation to the hierarchical structure of the distributed system, b) parsing the one or more resource definition language files to ensure conformity with the object-oriented resource definition language and creating an intermediate representation of the distributed system from the one or more conforming resource definition language files, c) processing the intermediate representation of the distributed system to form one or more programming language classes, one or more database definition files, and one or more script files, d) providing a reusable asset center framework to facilitate development of the one or more application programs, the reusable asset center including an SNMP agent framework that provides SNMP interface functionality to at least one of the one or more application programs, and e) building the one or more application programs from at least the one or more programming language classes, one or more database definition files, one or more script files, and the reusable asset framework.
A method of developing one or more application programs in operative communication to manage a network including one or more servers is provided. At least one application program is associated with each server. The method includes: a) defining one or more managed objects associated with the network in an object-oriented resource definition language and storing the definition of the one or more managed objects in one or more resource definition language files, wherein the definition of the one or more managed objects is based on an existing design and hierarchical structure of the network, wherein parent-child relationships between the one or more managed objects are identified in the one or more resource definition language files using the object-oriented resource definition language to define the one or more managed objects in relation to the hierarchical structure of the network, b) providing one or more data models with information associated with the one or more managed objects, c) creating one or more network management forum definition files with mapping information between the one or more data models and the one or more managed objects, d) converting the one or more data models into the object-oriented resource definition language and storing the converted information in the one or more resource definition language files, e) parsing the one or more resource definition language files to ensure conformity with the object-oriented resource definition language and creating an intermediate representation of the network from the one or more conforming resource definition language files, wherein the intermediate representation of the network created in the parsing step includes a parse tree, and f) processing the parse tree to form one or more programming language classes, wherein the one or more programming language classes formed include at least one of one or more system classes, one or more module classes, one or more managed object classes, and one or more composite attribute classes.
A method of developing an application program to manage a network is provided. The method including the steps: a) defining one or more managed objects associated with the network in an object-oriented resource definition language and storing the definition of the one or more managed objects in one or more resource definition language files, wherein the definition of the one or more managed objects is based on an existing design and hierarchical structure of the network, wherein parent-child relationships between the one or more managed objects are identified in the one or more resource definition language files using the object-oriented resource definition language to define the one or more managed objects in relation to the hierarchical structure of the network, b) providing one or more data models with information associated with the one or more managed objects, c) creating one or more network management forum definition files with mapping information between the one or more data models and the one or more managed objects, d) converting the one or more data models into the object-oriented resource definition language and storing the converted information in the one or more resource definition language files, e) parsing the one or more resource definition language files to ensure conformity with the object-oriented resource definition language and creating an intermediate representation of the network from the one or more conforming resource definition language files, wherein the intermediate representation of the network includes object meta-data, f) processing the object meta-data to form one or more programming language classes, one or more database definition files, and one or more script files, wherein the one or more programming language classes formed include at least one of an index class and a query class, g) providing a reusable asset center framework to facilitate development of the application program, the reusable asset center including an SNMP agent framework that provides SNMP interface functionality to at least one of the one or more application programs, and h) building the application program from at least the one or more programming language classes, one or more database definition files, one or more script files, and the reusable asset framework.
Benefits and advantages of the invention will become apparent to those of ordinary skill in the art upon reading and understanding the description of the invention provided herein.
The present invention exists in the construction, arrangement, and combination of the various parts of the device, and steps of the method, whereby the objects contemplated are attained as hereinafter more fully set forth, specifically pointed out in the claims, and illustrated in the accompanying drawings in which:
Referring now to the drawings wherein the showings are for purposes of illustrating the preferred embodiments of the invention only and not for purposes of limiting same.
In general, a reusable asset center (RAC) development environment for network management application development is provided. RAC, as used herein, generically refers to a reusable set of frameworks for network management application development. The set of frameworks is referred to as the RAC management framework. Network, as used herein, generically refers to a system having a set of resources arranged in a distributed architecture. For example, the RAC development environment may be used to develop network management applications for a TCP/IP-based network or any other type of communication network. For example, the RAC development environment may be used to develop network management applications for landline and/or wireless telecommunication networks. Likewise, the RAC development environment may be used to develop management applications for any type of system having a distributed architecture. Defined as such, the RAC framework is inherently reusable in other networks (i.e., systems). Moreover, major portions of code used to build management applications in the RAC development environment are inherently reusable.
The RAC development environment includes a Managed Object Definition Language (MODL) to specify managed objects in a network or system design and management information associated with the managed objects. The syntax for MODL is object-oriented and the semantics are similar to GDMO. This provides a simplified language for defining data models and acts as a single point translation mechanism to support interacting with different schema types. In essence, MODL provides a protocol-independent mechanism for accessing management information for managed objects within the network design. MODL can be used to define data models describing the managed resources of the network design in terms of managed resources having managed objects, define data types (attributes) representing various resources and objects, and define relationships among the managed resources and objects.
MODL allows network management applications to specify the resources to be managed in a given network design. The RAC development environment also includes MODL code generation from MODL files defining the managed objects and information. This provides automatically generated code to access these resources. Network management application developers can choose to make these resources persistent or transient. Developers can choose among various options to customize the code generation to suit the needs of the operators/maintainers (i.e., providers) of the network. MODL is object-oriented and allows applications to capture complex resources in a systematic way.
The RAC management framework provides an operation, administration, and maintenance (OAM) management framework catering to common OAM needs of the network and its managed resources and objects. The services offered by the RAC management framework range from standard system management functions to generic functions, such as event management, SNMP proxy interface, persistency services, and view management. These services are offered in a protocol-independent and operating system-independent manner.
Most of the common OAM needs of network elements are described in the ITU-T specifications X-730 through X-739 and are known as system management functions. The process leading to development of a RAC management framework provides for systematic and consistent reuse of code. In addition to requirements prescribed by applicable standards, the RAC management framework also provides, for example, functionalities such as persistence, view management and SNMP interface capabilities.
The following requirements of ITU-T X.730 (ISO/IEC 10164-1: 1993(E)) associated with Object Management Function (OMF) services are fully supported in the RAC management framework: 1) creation and deletion of managed objects; 2) performing actions upon managed objects; 3) attribute changing; 4) attribute reading; and 5) event reporting. The RAC management framework also provides, for example, ITU-T X.731-like state management functionality through effective use of callbacks and event reporting.
The RAC management framework provides, for example, a minimal subset of attributes for representing relations as described in ITU-T X.732 (ISO/IEC 10164-3). Certain attributes in the RAC management framework provide, for example, ways to define and create parent and child relationships between managed resources. This enables developers to specify hierarchical structures in the data model representing the network design.
The RAC management framework includes a standalone event management framework to implement event-handling services as described by ITU-T X.734 (ISO/IEC 10164-5). Regarding event-handling services, the RAC management framework, for example, permits: 1) definition of a flexible event report control service that allows systems to select which event reports are to be sent to a particular managing system, 2) specification of destinations (e.g. the identities of managing systems) to which event reports are to be sent, and 3) specification of a mechanism to control the forwarding of event reports, for example, by suspending and resuming the forwarding.
In addition to standard services, the RAC management framework provides additional capabilities associated with the functionality of various potential network elements. The RAC management framework also provides facilities to maintain data integrity in terms of default values and range checks and persistency of managed resources. For example, managed objects can be made persistent and all the OMF services are supported on these persistent managed objects. The managed objects can be manipulated from the back-end using standard Java database connectivity (JDBC) interfaces and synchronization is maintained so as to retain data integrity. This enables developers to manipulate data from multiple interfaces.
The RAC management framework provides a concept of views and view management services. Many network management applications, especially client applications, do not want to access or store the information about all the objects in the data model. The concept of views in the RAC management framework allows developers to create network management applications with access to a subset of the data model. Network management application developers can specify a view using a View Definition Language (VDL) that is included in the RAC development environment. View management services can be used to manage a cross-section of managed objects and associated resources in a single unit called a View. Most of the OMF services are also provided through the views.
The RAC management framework allows transparent distribution of the network management application. This decouples the network management application from changes in platforms and middleware environments. The network management application can be deployed in agent clients and agent servers servicing operation and maintenance centers (OMCs) (i.e., managers). The interface to the OMC can be Common Object Request Broker Architecture (CORBA), SNMP, JDBC, or another standard communication protocol for network management. For example, by simple inheritance, the agent server interface to the OMC can be extended to support other network management protocols, such as common management information protocol (CMIP), extensible markup language (XML), etc.
One of the key advantages for developers is that the RAC development environment automates development of portions of code with respect to the overall network management application. The RAC development environment generates the code based on the data model defined in MODL. The objects in the model get translated into subclasses in MODL code and access to the objects is generated using a build process in the RAC development environment. If the data model changes, corresponding MODL files can be revised and corresponding MODL code can be re-generated. Thus, streamlining change management of the network management application. The revised network management application is provided in a consistent and controlled manner through the object-oriented programming characteristics of MODL and the RAC management framework.
With reference to
If the network design 12 includes one or more MIBs, the MIB converter 14 converts the information in the MIBs to resource definition language file(s) 16. The developers use the network design 12 as source data for representing the remaining network resources and objects to be managed in the resource definition language file(s) block 16. The developers may also use the network design 12 to integrate the file(s) created by the MIB converter 14 with the other file(s) in the resource definition language file(s) block 18. Thus, the resource definition language file(s) block 16 includes one or more files defining the resources and objects within constructs and in appropriate syntax for one or more resource definition languages associated with the RAC development environment 10. Additional files may be included in the resource definition language file(s) block 18 defining one or more views of the resources and/or objects.
Files from the resource definition language file(s) block 18 are provided to an appropriate parser in the parser(s) block 18 to check for construct and syntax compliance and to build a parse tree. The parse tree is provided to the code generator(s) block 23. The options block 20 specifies certain options related to code generation by the code generator(s) block 23. The code generation options are customized by the developers based on the network design, parse tree, developer preferences, and/or network management application customer/user preferences.
The code generator(s) block 23 generates code for each managed resource and object defined in the resource definition language file(s) 16. The generated code provides various hooks and callbacks, which can be used by the developers to customize the flow of operations and behavior of the network management applications. The generated code primarily includes extensions of RAC management framework classes and eases the burden of coding and maintaining repeated functionality. The RAC management framework block 24 includes code organized in a group of subordinate frameworks. The RAC management framework 24 is implemented as a set of interrelated patterns (i.e., frameworks) that provide common functionality which can be selectively associated with the managed resources/objects and included in the generated code. The other code block 22 includes, for example, user-specific code and main methods which perform the initialization to get the final network management application.
The generated code from the code generator(s) block 23 is compiled and linked with code from the other code block 22 and the RAC management framework block 24 in the build process 25 to create a client network management application 27 and one or more server network management applications 28. At any stage in the application development, developers can add, delete or modify the managed resources/objects in the resource definition language files, re-generate the resource definition language code with new and/or revised managed resources/objects, and re-build the network management applications.
With reference to
Each of the data servers 32′, 32″, 32′″ includes one or more objects to be managed. For example, if any two network resources 32 are the same and the objects to be managed for both resources are also the same, the corresponding server network management application 28 may be the same on both resources. Otherwise, the application programs 34 and management databases 35 in the client network management applications are different based on the type of resource and/or type of objects to be managed.
The run-time tool 26′ controls and monitors the data servers 32′, 32″, 32′″ through communications with the client network management application 27′. The client network management application 27′ passes communications from the run-time tool 26′ to the appropriate server network management application 34. The client network management application 27′ also passes communications from the server network management applications 34′, 34″, 34′″ to the run-time tool 26′.
With reference to
With reference to
With reference to
With reference to
With reference to
DMF 56 is used to make certain managed objects persistent and makes these persistent managed objects accessible to network management stations (NMSs). The DMF 56 also maintains consistency of the persistent data and permits various servers within the network design to share the data, for example, in real-time. PF 58 provides a portable persistent database interface to network management applications. This permits MODL and other coding for the applications to be developed transparent of any underlying database implementation.
EMF 60 includes a centralized event management server that performs event management routing and broadcasting. The EMF 60 unifies various system event generations and handling schemes into one uniform event processing model. SAF 62 provides network management applications with a gateway between MOF and SNMP protocols. SAF 62 acts as a proxy for SNMP protocol. SAF 62 also provides an interface definition language (IDL) interface through which other system elements can communicate using CORBA.
The tracing framework 64 provides network management applications with an option to emit tracing information that can be saved to a log file for subsequent problem analysis. The tracing framework 64 provides developers and users with multiple tracing levels. DA 66 is an adaptation layer framework for transparent distributed programming. DA 66 provides a pattern for utilizing client and server object proxies to allow code for distributed applications to be written without having to explicitly deal with distribution issues.
The stream framework 68 supports the encoding of objects into a stream and the complementary reconstruction of objects from the stream. The stream framework 68 permits objects to be passed by value from the client to the server through various communication mechanisms. The common framework 70 includes a set of utility classes that are used across the RAC management framework 24. The common framework 70 reduces redundancy across the RAC management framework 24, thereby reducing code for network management applications.
With reference to
The SAF code generator 53 (
The SAF code generator 53 (
SafGen [-o outfile] [-oid] [-oid.h] [-moftable] [-modl] [-modoc] mibfile1 [mibfile2 . . . ]
The SAF code generator 53 (
The -moftable command line option generates SnmpTableMof subclass C++ definition and implementation files. This option is compliant with code generated by the MODL code generator 48 (
The -modl command line option generates an MODL interface for an SNMP application MIB. The MODL code generator 48 (
A configuration file (e.g., NMF definition file(s) 39 (
Flags are available in the NMF definition file(s) 39 (
APPLICATION is a parameter that may be used in the NMF definition file(s) 39 (
The format of the mapping between MIB table and the managed objects is as given in the mnf.cfg file. An example of this mapping is provided below:
With reference to
The SAF 62 provides an object-oriented interface to SNMP protocol and an SNMP interface to managed object resources stored in a containment tree representing the hierarchy of the network. The SAF 62 acts as a proxy for SNMP protocol and provides a conversion mechanism to MOF protocol. The SAF 62 supports “get,” “get next,” “set,” and “trap” commands in conjunction with manipulation of MIB variables. Additionally, the SAF 62 provides an IDL interface through which users can communicate with network elements using CORBA.
The SNMP table MOF class 74 is a class providing the representation for MIB tables and converting the SNMP requests to MOF. This class works with the data servers 32 (
The OID converter class 78 translates SNMP object identifiers into MOF representations (e.g., distinguished names and attribute names) and vice-versa. The SNMP table MOF class 74 uses this class for instrumentation. For each MIB table and managed object pair there is a corresponding OID converter. The SNMP object ID class 80 is an object oriented representation of SNMP MIB object identifiers. This class stores object IDs in an array and provides a length of the array. For example, OID=1.3.4.5.6.1542 is stored as {1, 3, 4, 5, 6, 1542}, 6. The SNMP object ID class 80 is used by the OID converter class 78 to translate back and forth between the MOF and SNMP protocols.
The SNMP object stream class 82 specializes the abstract base class object stream to externalize and internalize SNMP packets to a data stream compatible with the network application programs 27, 28 (
The SNMP engine class 86 encapsulates an SNMP engine associated with Wind River's SNMP agent toolkit and provides utility methods to set the properties of the SNMP agent. The SNMP agent class 88 extends the basic SNMP engine class 86 and supports TMN alarms and state change reports. This class also provides instrumentation of agent data. More specifically, agent port information, community names, and trap destinations are provided by the SNMP agent class 88. The SNMP V3 agent class 90 extends the basic SNMP agent class 88 to support features of SNMP, version 3. This class implements the user security model (USM) and provides the ability to populate the user table MIB.
The SNMP user class 92 is an abstract base class encapsulating the characteristics of the user. The SNMP engine Id class 94 provides support for creating an engine ID for the SNMP agents. The SNMP V3 target class 96 provides an abstract base class for encapsulating SNMP target characteristics. The SNMP V3 target parameter class 98 provides an abstract base class for encapsulating characteristics of the SNMP target parameter. The SNMP V3 notify class 100 provides an abstract base class for encapsulating characteristics of notify MIB tables.
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
As shown in
With reference to
The basic SNMP protocol handling and MIB hooking capabilities in the SNMP agent code 126 are provided by Emissary 128 from Wind River's SNMP agent toolkit. Interdependencies between the RAC framework 24 and Emissary 126 are provided through extensions to Emissary 126 associated with the SAF code generator 53. The SAF code generator 53 is operated through command line options 44 and the extensions are introduced through the extension option -moftable.
As in any SNMP development, the entry point for developing the SNMP agent code 126 is defining the MIB. Emissary 128 is used as the SNMP engine. Hence, hence keywords associated with Emissary 128 (e.g., FORCE INCLUDE, DEFAULT etc.) should be defined. For the meaning and use of Emissary keywords, refer to the Emissary user's guide.
The NMF definition file(s) 39 (e.g., nmf.cfg) act as an input for generating the data server access classes 130 required to access the managed objects and their attributes corresponding to each table. Before writing the NMP definition file(s) 39, a developer should have information about the managed objects. The NMF definition file(s) 39 supply information to the SAF code generator 53 through the SNMP agent framework parser 43. The information includes mapping information between MIB tables and managed object classes with distinguished names. For example, an nmf.cfg (i.e., NMF definition file 39) may include the following information:
The -moftable command line option causes the SAF code generator 53 to generate a table name MOF class for each table name mentioned in the nmf.cfg. The table name MOF classes are inherited from the SNMP table MOF class 74 (
The following provides exemplary application class definitions, for example, for configuration data and agent instantiation. Initially, a user class inheriting from the SNMP V3 agent class 90 (
Next, the user security model (USM) is configured by extending the SNMP user class 92 (pure virtual) and providing the necessary configuration details. An example of code configuring the USM is provided below:
Next, traps and notifications associated with SNMP, version 3 are set up. The SAF 62 provides three classes for configuring target and notify MIBs (i.e., SNMP V3 target class 96 (
Next, the SAF code generator 53 is operated to generate classes and function definitions. The commands and command line options provided below are an exemplary sequence of commands to operate the SAF code generator 53. The output file can be given any name. Accordingly, the developer may have to change the file names of include files in some of the generated files.
Emissary 128 generates the MIB access functions 132 based in conjunction with the -skel, -skel.h, -mib, -oid, -trap, and -Leaf command line options. The SAF code generator 53 generates the data server access classes 130 (i.e., the backend) in conjunction with the -moftable command line option. The files generated from the -skel and -mofTable command line options may be customized.
The -skel command line option generates a user hook (e.g., get, set, next, and test) skeleton for the MIB variables. This is where the user provides links to the actual information associated with, for example, the data servers 32 (
As mentioned above, the -mofTable command line option generates a subclass of the SNMP table MOF class 74 (
At this stage, the developer has all the components to implement the SNMP agent 112 (
Note that the steps above should be taken as guidelines rather than diktats. The first three steps above are common to most network designs 12 (
The build process 25 compiles and links the generated files along with libraries associated with Emissary 128, SAF 62, and other RAC frameworks 24. Typically, the SNMP agent framework server 140 needs to be linked with mib.o, oid.o, AgentInstr.o, TableNameMofo, and other application class objects.
The following paragraphs describe an exemplary process for building an SNMP agent. An SNMP agent 112 (
An example of code that defines the MIB, as described above in step 1), is provided below:
As shown in the exemplary code above, there need not be any one-to-one mapping in the names of MIB variables.
The code below provides an exemplary configuration file (i.e., nmf.cfg) associated with step 2) above with the module name (i.e., application tag) followed by the SNMP table name-to-managed object name mapping:
The commands and command line options 44 (
Except for the -moftable command line option, the command line options shown above are associated with Emissary and generate code associated with the SNMP engine 114 (
Instantiating and linking the SNMP agent, as discussed above in step 4), includes writing a user class. The user class is defined to inherit from the SNMP agent class 88 (
At this stage, the developer has all the components to implement the SNMP agent 112 (
The above description merely provides a disclosure of particular embodiments of the invention and is not intended for the purposes of limiting the same thereto. As such, the invention is not limited to only the above-described embodiments. Rather, it is recognized that one skilled in the art could conceive alternate embodiments that fall within the scope of the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4484264 | Friedli et al. | Nov 1984 | A |
| 4879758 | DeLuca et al. | Nov 1989 | A |
| 5130983 | Heffner, III | Jul 1992 | A |
| 5175818 | Kunimoto et al. | Dec 1992 | A |
| 5257371 | Anezaki | Oct 1993 | A |
| 5293619 | Dean | Mar 1994 | A |
| 5295256 | Bapat | Mar 1994 | A |
| 5517662 | Coleman et al. | May 1996 | A |
| 5519868 | Allen et al. | May 1996 | A |
| 5557744 | Kobayakawa et al. | Sep 1996 | A |
| 5632035 | Goodwin | May 1997 | A |
| 5726979 | Henderson et al. | Mar 1998 | A |
| 5737518 | Grover et al. | Apr 1998 | A |
| 5742762 | Scholl et al. | Apr 1998 | A |
| 5745897 | Perkins et al. | Apr 1998 | A |
| 5751962 | Fanshier et al. | May 1998 | A |
| 5768529 | Nikel et al. | Jun 1998 | A |
| 5809235 | Sharma et al. | Sep 1998 | A |
| 5892950 | Rigori et al. | Apr 1999 | A |
| 5909681 | Passera et al. | Jun 1999 | A |
| 6003077 | Bawden et al. | Dec 1999 | A |
| 6018625 | Hayball et al. | Jan 2000 | A |
| 6052382 | Burke et al. | Apr 2000 | A |
| 6052526 | Chatt | Apr 2000 | A |
| 6110226 | Bothner | Aug 2000 | A |
| 6138272 | Tonouchi | Oct 2000 | A |
| 6141701 | Whitney | Oct 2000 | A |
| 6182153 | Hollberg et al. | Jan 2001 | B1 |
| 6201862 | Mercouroff et al. | Mar 2001 | B1 |
| 6219703 | Nguyen et al. | Apr 2001 | B1 |
| 6226788 | Schoening et al. | May 2001 | B1 |
| 6249821 | Agatone et al. | Jun 2001 | B1 |
| 6269396 | Shah et al. | Jul 2001 | B1 |
| 6298476 | Misheski et al. | Oct 2001 | B1 |
| 6324576 | Newcombe et al. | Nov 2001 | B1 |
| 6330601 | French et al. | Dec 2001 | B1 |
| 6345302 | Bennett et al. | Feb 2002 | B1 |
| 6360258 | LeBlanc | Mar 2002 | B1 |
| 6360262 | Guenthner et al. | Mar 2002 | B1 |
| 6363421 | Barker et al. | Mar 2002 | B2 |
| 6366583 | Rowett et al. | Apr 2002 | B2 |
| 6381599 | Jones et al. | Apr 2002 | B1 |
| 6405364 | Bowman-Amuah | Jun 2002 | B1 |
| 6427171 | Craft et al. | Jul 2002 | B1 |
| 6427173 | Boucher et al. | Jul 2002 | B1 |
| 6430602 | Kay et al. | Aug 2002 | B1 |
| 6434620 | Boucher et al. | Aug 2002 | B1 |
| 6467085 | Larsson | Oct 2002 | B2 |
| 6490631 | Teich et al. | Dec 2002 | B1 |
| 6519635 | Champlin et al. | Feb 2003 | B1 |
| 6549943 | Spring | Apr 2003 | B1 |
| 6550024 | Pagurek et al. | Apr 2003 | B1 |
| 6553404 | Stern | Apr 2003 | B2 |
| 6601233 | Underwood | Jul 2003 | B1 |
| 6618852 | van Elkeren et al. | Sep 2003 | B1 |
| 6681386 | Amin et al. | Jan 2004 | B1 |
| 6751676 | Fukuhara | Jun 2004 | B2 |
| 6754703 | Spring | Jun 2004 | B1 |
| 6757725 | Frantz et al. | Jun 2004 | B1 |
| 6813770 | Allavarpu et al. | Nov 2004 | B1 |
| 6857020 | Chaar et al. | Feb 2005 | B1 |
| 6891802 | Hubbard | May 2005 | B1 |
| 6928471 | Pabari et al. | Aug 2005 | B2 |
| 6981266 | An et al. | Dec 2005 | B1 |
| 6990636 | Beauchamp et al. | Jan 2006 | B2 |
| 7047518 | Little et al. | May 2006 | B2 |
| 7076766 | Wirts et al. | Jul 2006 | B2 |
| 7085851 | Nusbickel et al. | Aug 2006 | B2 |
| 7117504 | Smith et al. | Oct 2006 | B2 |
| 7127721 | Chaudhuri et al. | Oct 2006 | B2 |
| 7174533 | Boucher | Feb 2007 | B2 |
| 7249359 | McCloghrie et al. | Jul 2007 | B1 |
| 7275236 | Kabe | Sep 2007 | B1 |
| 7293257 | Czerwonka | Nov 2007 | B2 |
| 20010037389 | Fujimori et al. | Nov 2001 | A1 |
| 20010044822 | Nishio | Nov 2001 | A1 |
| 20020035626 | Higuchi | Mar 2002 | A1 |
| 20020103890 | Chaudhuri et al. | Aug 2002 | A1 |
| 20020111213 | McEntee et al. | Aug 2002 | A1 |
| 20030177477 | Fuchs | Sep 2003 | A1 |
| 20040088304 | Wang et al. | May 2004 | A1 |
| 20050278709 | Sridhar et al. | Dec 2005 | A1 |
| 20070100967 | Smith et al. | May 2007 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20050278692 A1 | Dec 2005 | US |
