Integration of SNMP and CMIP protocol for Mobile Agent in LAN and Cloud Network Management

1. Introduction of Network Management Protocol

In Network management, for better Quality of Services (QOS), system/network administrators should be always aware of the status of the networking devices called agents, including their CPU loads, memory, storage usage etc. Currently, SNMP (Simple Network Management Protocol) has been widely used in remote monitoring of network devices and hosts. The main advantage of SNMP is simplicity in the design. Also, when the communicated messages between manager and agent entities are low. But low security is the main weakness of SNMP that recently is going to be better in the new versions.

On the other hand, to compensate lack of SNMP, CMIP has designed, and it can be used for lager networks. Object-oriented model will use to design and implement SNMP [1, p. 1157-1162]. The main advantage of CMIP is its ability to define the techniques to cover manual control, security, and filtering of the management information. The main weakness of CMIP is resource occupation time which is more than SNMP [2]. Table 1 summarize the list of the CMIP and SNMP services.

Table 1

CMIP and SNMP services

2. Mobile Agent proxy for Network Management

The proposed Mobile Agent (MA) proxy agent provides the emulation of CMIS services by mapping them to the corresponding SNMP messages. It allows management of Internet MIB-II objects by a CMIP manager supporting CMIP network management protocol, and the CMIS services.

The MA proxy emulates services such as scoping and filtering, processing of CMIS operations and translation of SNMP traps to CMIS notifications. Figure 1 shows the context dataflow diagram of the CMIP/SNMP proxy agent.

Fig. 1. Mobile Agent proxy for network management

The MA proxy performs the following functionality:

Manage connection establishment/release with the CMIP manager.

Data transfer between the CMIP manager and Internet agent which consists of:

• transfer of CMIP indication and response protocol data units (PDUs) with the CMIP manager.
• transfer of SNMP request and response messages with the Internet agent.

Proxy service emulation functionality such as:

• CMIS to SNMP mapping.
• SNMP to CMIS mapping.

The MA proxy maintains a configuration file in the common data store to preserve the information during the message transfer. Figure 2 shows the data flow diagram for this service mapping.

Fig. 2. Service mapping CMIP and SNMP through Mobile Agent

2.1. Network Management Protocol Service Mapping

2.1.1. M-GET to GetRequestI GetNextRequest Mapping

On receiving a CMIS M-GET request, the proxy first verifies the existence of the base managed object. If the base object specified in the request does not exist in the Internet agent, then the proxy sends a “NoSuchObjectlnstance” CMIS error response back to the CMIPmanager [3].

The attributeldlist parameter of the CMIP PDU is a service-user option. If it is empty it means the proxy has to retrieve the value of all the attributes that are specified under the base managed object as per the GDMO template definitions [5].

If the CMIS request attribute is not empty, the proxy will verify the specified attributes(s) for the base object class. If it is not defined in the base object class, the proxy returns a “noSuchAttribute” CMIS error and does not send SNMP request to the Internet agent.

Fig. 3. Data flow for mapping the M-GET service to an SNMP GetRequest/ GetNextRequest

After successful validation of the M-GET indication PDU, the proxy constructs a SNMP message format with the PDU type set to SNMP GetRequest or GetNextRequest. Thus, the proxy has mapped an incoming CMIP M-GET indication PDU to a SNMP GetRequest/GetNextRequest message. This message is however partially built as it requires the other fields of the message to be appropriately mapped. This is achieved by the proxy by performing name mapping functionality, which supplies the variable binding list. The Request Id, Source and Destination addresses are extracted from the address translation table [1, p. 1157-1162; 2; 3].

2.1.2. M-SET to SetRequest Mapping

When a CMIS M-SET request is received, the proxy first checks whether the specified base managed object exists. If the base object is not found in the Internet agent, the proxy sends a “NoSuchObjectInstance” CMIS error response to the CMIP manager [3, 4, 5].

For each chosen object instance in the CMIP M-SET indication, the proxy creates one or more SNMP SetRequest messages to update the attributes identified by the CMIS modificationList parameter, following the modify operator specified. The proxy supports only the "replace" modify operator; if no operator is specified in the CMIS request, "replace" is assumed by default. The proxy consults its MIB schema to confirm that the attribute being modified has the REPLACE property necessary for CMIS M-SET emulation. If an unsupported modify operator is included in an M-SET request, the proxy returns a “Setlist error” CMIS error to the CMIP manager [3, 4, 5].

Fig. 4. Data flow for mapping the M-SET service to an SNMP SetRequest

2.1.3. M-CREATE to SetRequest Mapping

The proxy is tasked with validating each incoming CMIS M-CREATE indication. It checks if an instance can be created based on the CREATE clause in the NAME BINDING templates specified for the object class. If creation is not permitted, it returns a “classInstance-Conflict” CMIS error response [5; 6, p. 349-360; 7, p. 17-26].

The proxy further assesses if the instance requested can be created under the superior object instance specified in the M-CREATE request, as defined by the NAME BINDING template. If the NAME BINDING template does not support the specified containment relationship, it returns an “invalidObjectInstance” CMIS error. Additionally, if the object instance already exists, a “duplicate managed object instance” CMIS error is issued [5; 6, p. 349-360; 7, p. 17-26].

If the CMIS M-CREATE indication includes a reference object, the proxy retrieves the referenced instance from the Internet managed agent. To obtain reference object values, it sends an SNMP GetNextRequest. If the reference object is missing, the proxy sends a “No such reference object” CMIS error to the CMIP manager [5; 6, p. 349-360; 7, p. 17-26].

2.1.4. M-DELETE to SetRequest Mapping

The proxy determines from the NAME BINDING templates if the instance specified in the request may be deleted. If the NAME BINDING does not allow the deletion of the identified object, an “Access denied” CMIS error is returned [3, 4, 5].

If the object instance identified in the CMIS M-DELETE request exists, the delete operation is performed. Deletion of an object instance is realized by setting the status columnar object to an invalid value. Object deletion is achieved by sending an SNMP SetRequest to change the rowStatus value to “destroy” [3, 4, 5].

Fig. 5. Data flow for mapping the M-DELETE service to an SNMP

2.1.5. Other CMISE Request Processing

The Proxy agent handles the M-CANCEL-GET and M-ACTION requests as follows:

2.1.5.1. M-CANCEL-GET Service

The proxy agent does not need to send any SNMP request to emulate a CMIS M-CANCEL-GET request. When an M-CANCEL-GET indication is received, the proxy stops sending any further CMIS M-GET responses to the CMIP manager for that particular canceled request. Additionally, upon receipt of an M-CANCEL-GET indication, the proxy ceases all future SNMP GetRequests to the Internet agent related to the canceled M-GET request. If the Internet agent still returns GetResponses for the canceled request, the proxy will discard these responses [3, 4, 5].

The M-CANCEL-GET indication PDU includes the Invoke identifier of the M-GET request to be canceled. If the proxy does not recognize the Invoke identifier, it returns a “no such invoke identifier” CMIS error to the CMIP manager [3, 4, 5].

2.1.5.2. M-ACTIONService

Since Internet MIBs lack defined actions, the CMIS M-ACTION operation does not correspond to any SNMP operation. As a result, the proxy does not handle this operation; upon receiving an M-ACTION indication, it simply returns an “Unrecognized operation” CMIS error response [1, p. 1157-1162; 2; 3].

2.1.6. Registration and Naming

Registration ensures the uniqueness of management information element types, while naming provides a way to distinguish instances of each type and position them correctly within the MIB. Defining managed object classes involves registering globally unique identifiers, called object identifiers, which represent various elements of the managed object class, such as its name, attribute types, and more. These identifiers are essential in management protocols for uniquely identifying different aspects of managed objects, including their attributes, operations, and notifications. All Internet groups and conceptual tables are translated into CMIP managed object classes, with column and scalar objects becoming attributes within these object classes. Additionally, name bindings for positioning object instances within the naming hierarchy must also be registered [3, 4, 5].

Fig. 6. Registration under the joint ISO/CCITT subtree

2.2. Name Translation from ISO/CCITT to Internet

Managed object class selection is used to identify a set of managed object instances in the management information tree on which a CMIS request is applicable. This is accomplished by the CMIS scoping operation. Scoping is used to select candidate object instances in the management information tree (MIT) to which operations may apply. Before object instance OIDs can be translated from the CMIP management information tree, it is necessary to get the set of managed objects that are within the scope [5; 6, p. 349-360; 7, p. 17-26].

On receiving a request from the CMIP manager the proxy first determines the set of object classes that are within the scope. The information regarding the superior and the subordinate object classes contained in the name binding template is used for tree traversal during scoping. If the scope parameter is absent in the request the default scope is the base object itself. The object class also contains the attribute name specified as the filter parameter [3, 4, 5].

The selected scoped object classes and the attribute identifier fist’s that are supplied by the CMIS request are used by the proxy to extract the ISO/CCITT registration OIDs from the GDMO MIBs. As discussed, earlier CMIP object class OIDs and the CMIP attribute OIDs follow the general pattern. Thus, by stripping off the OIDs associated with MOG and ATT in the CMIP registration tree we can get the Internet OIDs. In order to get the Internet object name we need to append internet object OID with the naming attribute associated with it. The naming attribute is extracted from the distinguished name (DN) which is supplied with any CMIS request [5; 6, p. 349-360; 7, p. 17-26].

2.2.1. SNMP to CMIS Error Translation

The proxy agent translates the incoming SNMP error responses to CMIS error responses to be sent to the CMIP manager [4]. Table 2 describes this error mapping.

Table 2

SNMP to CMIS Error Translation

2.2.2. Filter Operation

A filter is a Boolean expression that includes one or more assertions regarding the presence or values of attributes within the scoped managed object. The proxy applies this filter to all object instances received from the managed agent, selecting only those that meet the filter criteria. It then sends the filtered CMIS response PDUs to the CMIP manager [2, 3].

2.3. SNMP Trap to CMIS M-EVENT-REPORT Mapping

The `NOTIFICATION-TYPE` macro defines the data an SNMP agent sends when an exceptional event occurs, packaged as a Trap PDU. Upon receiving a Trap PDU, the proxy agent forwards the information to the CMIP ISO/CCITT manager. It uses the Trap PDU parameters to construct a CMIS `M-EVENT-REPORT` request PDU, where all SNMP traps are mapped to a generic CMIS notification event type named `InternetAlarm` [6, p. 349-360; 7, p. 17-26].

The `Description` clause within the macro becomes the Event Information parameter, providing a detailed description of the event. Additionally, the SNMP Trap PDU includes a variable-bindings list, where the first variable, `sysUpTime.0`, is used to set the Event Time parameter in the `M-EVENT-REPORT` request [5; 6, p. 349-360].

3. Benefits of the Proposed Model

• Reduced Communication Costs: Communication latency and network traffic can greatly affect the performance and coordination of two programs running on separate computers. However, in a Mobile Agent platform, if one program is a mobile agent, it can migrate to the computer where the other program is running and communicate with it locally, effectively turning remote communication into local communication [8].
• Asynchronous Execution: Once a mobile agent migrates to the target computer, it no longer depends on continuous interaction with its original source. This allows the agent to continue processing on the destination computer, even if the source computer is offline or the network connection between them is disrupted. This feature is especially valuable for smart environments or unstable networks, such as wireless communication [9].
• Direct Manipulation: When a mobile agent operates locally on the host computer it visits, it can directly access and control that computer’s hardware and software (provided access permissions are granted). This capability is particularly beneficial in network management, allowing for direct detection and resolution of device failures. Additionally, positioning a mobile agent close to a real-time system can reduce delays from network congestion [9; 10; 11, 25-36].
• Dynamic Deployment: Mobile agents serve as an efficient deployment mechanism, as they can dynamically determine their destination and deploy their code and data only when needed [9; 10; 11, 25-36].
• Simplified Development of Distributed Applications: Traditional distributed applications generally require a client-side program, a server-side program, and additional code for handling communication and exceptions. With Mobile Agents, however, a single program can be designed to handle distributed tasks by carrying its data and instructions directly to the target computer [9; 10; 11, 25-36].
• Enhanced Network Management: Mobile Agent can fully implement the CMIP protocol, providing more advanced commands than the SNMP protocol, such as M-Get, M-Set, M-Action, M-Create, M-Delete, and M-Event-Report and also retain SNMP support for managing and controlling devices that use SNMP-based communication [9].

Conclusions

This paper presents the integration of popular Cloud Network Management at an abstract level, using lab experiments without full implementation. In future research, we aim to provide a more detailed design for each component of the model and develop its full functionality. Moving forward, we will also analyze the use of monitor traffic flows within the cloud and conduct pilot testing in a production environment.