next up previous
Next: Implementation Issues Up: Tools and Architecture Previous: Tool Environment

The Architecture of the Q-Adapter Function

 


\begin{figure}
\epsfxsize 0.9\hsize 
\begin{center}
\mbox{ \epsffile{32_agentarch.eps} } \end{center}\end{figure}

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):


next up previous
Next: Implementation Issues Up: Tools and Architecture Previous: Tool Environment
Copyright Munich Network Management Team