B. Waiters, 15 May, 1996

0. Introduction

This document describes the minimum requirements for Prototype II of the Distributed Network Manager (DNM). These minimum requirements where established on May 14th, 1996 as the result of a class meeting during lab period. At this meeting it was decided to concentrate on a limited set of functionality in order to have a simple, working prototype ready for demonstration at the end of week 10. This specification is an extremely small subset of the Distributed Network Manager Functional Specification Version 1.0 by S. Ron Oliver. Any variation from Version 1.0 will be made only for the sake of having a working prototype by the established milestone date of June 6, 1996. Any such variation will be duly noted in this document.

0.1 Prototype II Description

Prototype II will demonstrate the use of OSF/DCE to communicate between the privileged user interface (UI), the stats module, and the node-discovery module. All messages between the UI and stats will be encrypted. The stats module will eventually become part of the limited user-interface for a distributed process component. The stats module will receive the request from the UI for statistics from a user-chosen node. Stats will then read any raw data for the given node from the stats-database and use this information to compute the requested statistics for that node. For this prototype the node will be cobra, and the requested statistic will be link utilization. The protocol module for this prototype will be an SNMP module. It will read from a configuration file to determine which SNMP agents to poll and record information to the stats-database. A rudimentary node discovery module will also be part of prototype II.


---

0.2 Notes on expandability

Since prototype II is a very limited subset of the overall functional specifications, and because we know exactly what statistic and node we will be working with, it is tempting to design and code prototype II with these two parameters "hardwired" into the prototype. This would be a serious mistake, and would hinder the classes that follow us in the production of future prototypes and the final product. Therefore, it is required that all design and code be easily expandable and reusable. All functions should be written in such a way as to keep these "known" parameters as variable and avoid the hardwired issue. This will result in a much easier transition between classes, and adds very little extra work for our class.

0.2.1 Requirement

• All code and design for prototype II shall have high cohesion, low coupling.

1.0 User Interface (UI) Module

1.1 Functional Description

For prototype II, the user interface will be a simple, character-based interface. It will be menu driven and contain only a limited subset of the specifications laid out in the DNM functional specifications.

The UI will communicate to a process component via DCE. For prototype II the process component will be the stats module. One specification of major importance is security, and as a result, it is imperative that all communications be secure from outside influences. The encryption of all communications will alleviate much of this problem.

For prototype II, the information available to the UI will be severely limited. In the prototype the only statistic which will be requested will be utilization. This utilization will only be requested for Cobra.

One other report will be available in prototype II. The UI will be able to give a list of nodes discovered via the node discovery module.

1.2 Requirements

The UI shall:

1. be a character-based, menu-driven interface.
2. be the sole interface for the privileged user.
3. authenticate the privileged user
   1. at the UI initilization
   2. after each request to the statistics module
   3. using the security module.
4. communicate with the statistics module
   1. via OSF/DCE's Remote Procedure Calls
   2. by encrypting all communication to the statistics module
   3. by decrypting all communication from statistics module
   4. using the security module.
5. request the utilization of the cobra cluster from the statistics module
6. print the utilization of the cobra cluster upon request to the screen.
7. communicate with the node-discovery module
   1. via OSF/DCE's Remote Procedure Calls
   2. by encrypting all communication to the statistics module
   3. by decrypting all communication from statistics module
   4. using the security module.
8. request a list of nodes discovered from the node-discovery module
9. print the list of nodes upon request to the screen.