DNM: Design Specifications

Distributed Network Manager
Design Specifications
v1.0

May 21, 1996

Goal

On Thursday, May 30, the Distributed Network Manager, will be demoed on the Snake Cluster of the CSL as a proof of what we learned and accomplished in CSC405 for Spring Quarter, 1996. The demo will consist of logging into our program as a priviledged user, performing a node discovery, and finding the link utilization of Cobra.

In order to assure that the Distributed Network Manager (DNM) meets some of the principal requirements outlined at the beginning of the quarter, we have designed a simple distributed application architecture that will combine efforts from each of the six groups, based on the class discussion that took place on Tuesday, May 14 in Rm 303. Each group and a simple overview of their contribution is listed below:

Application Development - User interface, Process Component API
OSF/DCE - Remote Procedure Calls (RPC) between Process Components
SNMP - Provide interaction with SNMP agents on the network
Tools and Security - User authentication, encryption, statistics DB
QA & Integration - Overall quality assurance and adherence to development process
Modeling and Simulation - Node discovery and reporting

Architecture

The Distributed Network Manager (DNM), as the name implies, is meant to run on multiple machines as individual Process Components that work together to provide the full functionality of a single network manager. Although our version of the DNM cannot manage a production network, we believe its modularity will provide much flexibility as features are added in future versions.

To demonstrate our architecture design, we will run a simple node discovery to report the names of the nodes on the local network followed by a statistical query from a database updated at regular intervals by SNMP queries.All of this will be done using DCE between each Process Component (PC) and the Priviledged User Interface (PUI) to emphasize the distributed nature of our network manager.

Conceptually, our architecture design consists of several Process Components working under one priviledged user interface:

Priviledged User Interface (PUI) - used by the network manager to monitor the network and communicate to all surrogate nodes
Node Discovery Process Component (NDPC) - the Process Component that handles the initial network and node discovery when the DNM is started.
Statistics Process Component (SPC) - the Process Component responsible for summarizing all statistics collected by the protocol module and reporting them to the PUI as requested.
Protocol Process Component (PPC) - the Process Component that queries managed nodes for their status and various statistics

Each Process Component (PC) runs as a separate process on its host and commmunicates to the others via DCE Remote Procedure Calls. The exception to this is the Protocol Process Component (PPC) which does not communicate with any other PC's. Instead, at startup, the PPC reads a configuration file to find what statistics to gather then it goes off and simply writes those statistics into the database.

A better, fully distributed implementation would be for the PPC to call a db_write() function via DCE that is running on the Statistics Process Component (SPC). It would then be the SPC's job to accept, reject, or log the data to the database. In addition, the PPC should be able to either accept a ppc_config_write() or call a ppc_config_read() from some other process component. To maintain the fully distributed approach, the configuration should be stored in local memory.

Design Specification

To aid in the design and development of the Distributed Network Manager (DNM), a step-by-step guide is given below that explains what happens in each process component of the DNM for the demonstration to work properly. Adhering to this design and coding to its specifications will enable all teams of the DNM project to understand what is required of them and how they must communicate with the others for a successful integration of the entire system.

Note: all of the function call names used below are prefaced with an abbreviation of the process component name or group name responsible for the function:

pui - User Interface
spc - Statistics
ndpc - Node Discovery
ppc - Protocol module (SNMP)
dce - OSF/DCE
sec - Security

Bring up the system
1. Execute the Priviledged User Interface (PUI) on one machine in the Snake Cluster
```
	> pui
```
2. Execute the Node Discovery Process Component (NDPC) on a second machine
```
	> ndpc
```
3. Execute the Protocol Process Component (PPC) on a third machine
```
	> ppc
```
4. Execute the Statistics Process Component (SPC) on the third machine
```
	> spc
```
Note: the PPC and the SPC must reside on the same machine because the SNMP group doesn't want to make DCE calls, requiring the two process components to access the same file locally. This could be overcome with the proper DCE interface.
User Authentication

The Priviledged User Interface may only be accessed after a proper user authentication to ensure security at the user level.
1. The PUI will prompt the user for a login name and password
2. After the user types his username and password, they will be verified using the function
```
	int sec_authenticate_user( username, password );
```
  which will return either a 0 for a successful login or a 1 for an invalid login.
3. An invalid login will bring up an Invalid Login error which the user must acknowledge by pressing Return.
  A enhancement to this login function would be to log any unsuccessful login attempts. After a valid login, it should inform the validated, priviledged user of the number of invalid login since the last valid login.
4. A valid login will display the DNM's Main Menu:
  1. Discover Nodes
  2. Node Link Utilization
  3. Lock the DNM
  4. Exit
Discover Nodes
1. Selecting Discover Nodes from the PUI's Main Menu will encrypt the necessary parameters of the OSF/DCE call using
```
	sendpkt = sec_encrypt( sendpkt );
```
2. The PUI will then use the OSF/DCE send call
```
	void dce_send( send_buf* sendpkt );
```
  to remotely activate node discovery on the NDPC, wherever it may reside
3. The NDPC will receive the request from the PUI using
```
	recv_buf* recvpkt dce_receive( ndpc );
```
4. The functions parameters will then be decoded using
```
	recvpkt = sec_decrypt( recvpkt );
```
5. With the information provided in the DCE call, the NDPC should know to execute the function
```
	nodes = ndpc_nodelist( );
```
  to go out and find all of the active nodes on the local network and return a list of their node names to the PUI.
6. The NDPC will then encrypt the list of node names with
```
	sendpkt = sec_encrypt( sendpkt );
```
  to ensure a secure transmission back to the PUI.
7. The PC will send the list of node names back to the PUI with
```
	void dce_send( send_buf* sendpkt );
```
8. The list will be received from the NDPC using
```
	MsgBuf* dce_receive( int my_component_no );
```
9. The PUI must then decrypt the list using
```
	recvpkt = sec_decrypt( recvpkt )
```
10. Finally, the list of node names can be displayed in on the PUI using
```
	pui_display_nodes( nodes );
```
11. After viewing the node names, the user should press Return to exit back to the DNM Main Menu.
Collect Cobra Link Utilization
1. When the PPC is initialized, it will find out what it needs to keep track of by reading the hard-coded Protocol Configuration File.
```
	ppc_read_config( filename );
```
2. With the information from the Protocol Configuration File, the PPC can begin querying all nodes specified for their respective statistics using the SNMP query functions:
  1. Needed SNMP functions
3. Each time the PPC receives a response from an SNMP agent on the network, it will write the statistic to the database
```
	ppc_write_stat( timestamp, hostname, statistic, value );
```
4. The PPC will continue to do this until the program is terminated on the host machine or the file system is full.
Display Link Utilization Statistic
1. Selecting Node Link Utilization from the PUI's Main Menu will encrypt the sendpktparameters string node_name, string trend_utilization, long begin_time, int interval using
```
	sendpkt = sec_encrypt( sendpkt );
```
2. The PUI will then use the OSF/DCE send call
```
	void dce_send( send_buf* sendpkt );
```
  to query the SPC for a the link utilization of Cobra.
3. The SPC will receive the request from the PUI using
```
	MsgBuf* dce_receive( int my_component_no );
```
4. The functions parameters will then be decoded using
```
	recvpkt = sec_decrypt( recvpkt )
```
5. With the information provided in the DCE call, the SPC will read the database with
```
	char* spc_read( filename );
```
  to gather the necessary statistics from the databases history for making an accurate calculation.
6. Once it has read all of the appropriate data, the SPC will calculate the link utilization for the appropriate interval
```
	float spc_calc_link_util( hostname, interval, data );
```
7. The SPC will then encrypt the statistic with
```
	sendpkt = sec_encrypt( sendpkt );
```
  to ensure a secure transmission back to the PUI.
8. The SPC will send the statistic back to the PUI with
```
	void dce_send( send_buf* sendpkt );
```
9. The list will be received on the PUI using
```
	recv_buf* mesg dce_receive( int my_component_no );
```
10. The PUI must then decrypt the statistic using
```
	recvpkt = sec_decrypt( recvpkt )
```
11. The statistic can finally be displayed in on the PUI using
```
	pui_display_stat( hostname, statistic, value );
```
12. After viewing the node names, the user should press Return to exit back to the DNM Main Menu.

Function Specifications

Function Headers

The functions used to make the DNM work are broken up by group. Each function is to be specified with
1. Procedure Name
2. Written by Author/Group
3. Last Date Modified
4. Version
5. Has this passed a peer review? (Yes/No)
6. Description
7. Parameter Definition
  1. IN - Data is not changed
  2. OUT - Data coming in is ignored and changed before
  3. IN OUT - Data is useful and can be changed.
Specifications

Each group should review the functions below and send any additions, suggestions and comments to me for updating.
1. Application Development / UI
  1. pui_display_nodes( nodes );
  2. pui_display_stat( hostname, statistic, value );
2. OSF/DCE
  1. char* data dce_send_and_recv_mesg( send_buf* sendpkt );
    
    void dce_send( send_buf* sendpkt );
    
    recv_buf* recvpkt dce_receive( int my_component_no );
3. SNMP / Data Collection
  1. ppc_read_config( filename );
  2. spc_write_stat( timestamp, hostname, statistic, value );
  3. ppc_get_???();
4. Tools & Security
  1. int InitSec ( char * server );
    This procedure accepts the name of the managing host as an argument and returns zero on success and -1 upon receiving an error. If "server" is NULL, then we are running as the server and configuration proceeds in the appropriate manner. InitSec() be called when the client or server software begins operation.
  2. int sec_authenticate_user( username, password );
  3. struct Edata* sec_encrypt ( struct Edata* mesg )
    The sec_encrypt() operation be called before transmitting data via DCE RPC to another host on the network. It takes an Edata structure as an argument and returns the same structure. The argument it takes contains a pointer to the block of data to be encrypted, the length of that data, and the name of the host to whom the data is to be sent. It uses the host name to look it up the host's key in the DCE database service. It then encrypts the data with an algorithm appropriate for the host's security level (also found in the database) and returns a pointer to an Edata structure which contains the encrypted data, the length, and a NULL for "host". If "host" is not NULL, then there was an error and "host" contains the error message.
  4. struct Edata* sec_decrypt ( struct Edata* mesg )
    The procedure to call upon receipt of data. It chooses the appropriate algorithm due to its security level and then decrypts the message. If no encryption was used, then it just strips the message out of the packet.
  5. nodes = ndpc_nodelist( );
5. Statistics
  1. char* spc_read( filename );
  2. float spc_calc_link_util( hostname, interval, data );

Data Type Specifications

Each group should review the data types below and send any additions, suggestions and comments to me for updating.

hostname - string that specifies which host to contact
pc - process component number, specified as an enumeration in the dnmconst.h file. Used to identify a Process Component with DCE calls.
function - the number of the function being called via DCE as specified in the enumeration in the dnmconst.h file.
statistic
value
data
mesg
interval - the time, in seconds, between querying an agent.

Data Encryption Structure


struct Edata {
	char* data;
	unsigned long length;
	char *host;
};

DCE Send Structure


struct send_buf {
	long from_component_no;
	char to_hostname[30];
	int  to_component_no;
	int  function_no;
	char arg[512];
};

DCE Receive Structure


struct recv_buf {
	char to_hostname[30];
	long to_component_no;
	char result[512];
};

SNMP Configuration File Structure
Statistics Database Structure

Distributed Network Manager (DNM)
CSC405, Spring '96

Distributed Network Manager Design Specifications v1.0

Goal

Architecture

Design Specification

Bring up the system

User Authentication

Discover Nodes

Collect Cobra Link Utilization

Display Link Utilization Statistic

Function Specifications

Function Headers

Specifications

Data Type Specifications

Distributed Network Manager
Design Specifications
v1.0