The Architecture of the Q-Adapter Function

 

By introducing a QAF into the management environment, an additional hierarchical level is inserted between the managing system and the managed system. Recall from section 1.1 that from the perspective of an OSF, a QAF is considered as an agent. In fact, this is the reason why we were able to use a TMN agent development toolkit (see section 3.1) for the implementation of the Q-adapter.
The OSF interacts with the QAF by means of the Q3-interface; the QAF itself is perceived as managing system by the SNMP managed devices and communicates with them through the m-interface (here: SNMP). As obviously no SNMP-API is shipped with the TMN development environment, we had to encapsulate an already existing C-API for SNMP (the ucd-snmp API) in order to trigger SNMP-PDUs in the C++ callbacks.

During runtime the agent executable consists of four distinct processes (shaded areas in the above figure):

• The Infratop process consists of the components Infrastructure and Naming and Replication. The process is crucial for the function of the QAF since it implements CMISE and ACSE, maintains the containment hierarchy and checks the name binding restrictions in case of M-CREATE and M-DELETE requests. Furthermore, it provides the scoping and filtering functionality by replicating the requests to the concerned MOIs.
• Discr is the event handling component which is compliant to the Event Report Management Function [10].
• Logr maintains the log records according to the Log Control Function [11].
• The Agent, finally, contains the managed object instances (MOI), the core agent and facilities for resource access. It may be either single- or multithreaded.