next up previous
Next: Extending the Q-Adapter Function Up: Implementation Issues Previous: Performing scoped and filtered

Containment Hierarchy

 


\begin{figure}
\epsfxsize 0.9\hsize 
\begin{center}
\mbox{ \epsffile{42_contain_mbe_bw.eps} } \end{center}\end{figure}

We will now describe how a user interacts with the QAF and the characteristics of our implementation.

At the current stage, our QAF prototype is able to handle two kinds of SNMP MIBs: Obviously, a QAF for SNMP must support MIB-II [20], the common MIB of all SNMP-capable resources. The second MIB ("lrz-unix") has been developed by our research group and covers the typical administration and maintenance tasks of UNIX workstations: It allows the definition of users and user groups and the assignment of quotas for disk space and printing facilities. Furthermore, different kinds of devices (disk partitions, filesystems, disks, tapes etc.) can be managed; it is also possible to create and delete processes. The emphasis lies in having not only monitoring capabilities, but also facilities for issuing administrative commands via SNMP.

The representation of these two MIBs in the QAF sums up to roughly 60 MOCs; these MOCs contain together about 600 attributes. For the sake of brevity, the screendump shown above depicts only the MIB-II part of a managed system (here: Relative Distinguished Name ibmhegering1; in the center of the figure) as it is perceived by the user on the WSF console. Operations on these MOIs are issued by dragging the icon of the desired MOI on an icon representing the desired operation (M-GET, M-SET, etc.) and by entering the appropriate parameters into a pop-up menu (defining the scope and filters and the type of synchronization). This is equivalent to the mechanism how TMN objects are managed and represented on the WSF, therefore providing seamless integration of SNMP managed objects into the TMN environment.

The second part of interest is the area which contains 3 MOIs ("CMIP/SNMP" and below; on the right side of the figure) that allow the configuration of the QAF itself during runtime through the same mechanism as described above. Management of the QAF is necessary because our QAF implementation performs several tasks itself such as caching of frequently requested MIB attributes. Through these MOCs, a user has, among others, the possibility of configuring the caching lifetime of attributes and their polling intervals. Furthermore, it is also possible to retrieve the values of several counters giving information on protocol errors.


next up previous
Next: Extending the Q-Adapter Function Up: Implementation Issues Previous: Performing scoped and filtered
Copyright Munich Network Management Team