Interface and Protocol Modules

Component Interfaces - Protocol Module(s)

1 Component Interface Module

Each process component will support a standard interface to other components and possibly to an interactive user. Since a significant subset of commands to be specified, and data to be retrieved, by another process component are identical to those specified retrieved by the interactive user, it is recommended both functions be served by the same Module. If the combined set of functions becomes large and/or complex, it may be desirable to divide the Module into two separate modules, with access to a common library of capabilities.

Process component and interactive user served by same module

1.2 Privileged User Interface

Any process component that supports an interactive user interface will do so only for properly authorized privileged users. In particular, access to the process will require authentication beyond normal password access. The means of authentication are specified in more detail in Section 1.5. Unless special actions are taken to override the restriction, it shall not be permitted for any user to interact with a process component remotely. That is, only users who have direct physical access to the processor in which the process resides shall even be given the option to be authenticated.

All interactive users must be properly authorized

Authentication more complex then just password access (Check with Tools)

Only access to process component through Big Dog interface

For early implementations the user interface shall be a simplistic, character-oriented interface. This requirement is levied to permit development efforts to focus primarily on the functional aspects of the application, and to avoid the trap of developing a GUI with no capability. Future versions will provide a fully functional GUI that permits the user to effectively use a Mouse, and minimizes the need to type.

Simple command-line interface for easy transport to GUI in later version

The user will be able to set parameters and options that govern the work being done by the application. Some of these may be application-wide, most will be specific to one or more of the process components.

User has ability to set parameters and options mostly dependent upon specific process

Some options selected will cause one or more process components to collect information much in the way SNMP agents currently do. Some options will cause statistical computations to be done using the collected information. The user shall be able to specify when, where, and how collected or computed information is to be displayed or reported. The user may specify certain reports to take place according to an automated cycle, some reports will update in real time, some reports will be available on demand.

Statistical Computation

Information collection>

User defined times/places/type of collection/computation

Reports may be automated or on-demand

Certain functions of the application will cause things to happen automatically. In particular, for instance, node discovery, described in Section 3.1, will automatically determine the network configuration. Under some circumstances it shall be possible for the user to manually override or intervene with such automatic functions.

Automatic Node discovery

Automatic threshold alarms

Manual override/intervention of automatic functions

1.3 Interface with Peer Application Components

All process components will interface with one or more other process components. In some cases this will entail receiving commands from a parent component in the hierarchy precisely like those the user may specify at the privileged process, or sending reports to another process much like the reports generated by the privileged process. All process-to-process interactions will use the OSF DCE/RPC Interprocess Communication capability to achieve such interaction. All interactions will be protected with a TBD EDC capability. Most interactions will be relatively low volume data transfers. Some interactions, such as statistical reports, may become voluminous enough to represent an undesirably high burden on the available network link components. When a transmission threatens to cause a network link component to be over utilized, data compression shall be used to avoid exceeding the threshold. If available data compression techniques do not ensure thresholds will not be exceeded, the compressed transmission shall be partitioned and sent at delayed times to avoid exceeding the threshold. All transmissions shall be sent encrypted, using the method identified in Section 1.5.

Interprocess interfaces using OSF/DCE/RPC

Protected using TBD EDC (tools team)

High volume reports will use data compression scheme or partitioning

All transmissions will be encrypted

1.4 SNMP Manager / Agent Interface

Much of the data collection to be done is already being done in some environments by SNMP Managers and Agents. To the greatest extent feasible, the Network Management Application shall interact with and take advantage of existing SNMP resources to collect information, rather than replicate those functions. The specific alternatives and means by which such interaction shall take place are detailed below.

Data collection (SNMP) TBD - by SNMP Team.
Data Collection (Other Protocols) TBD

1.5 Route Control Agent Interface

Certain key functions to be automated will involve determining link costs more accurately than is normally done by existing Route Control software. To the greatest extent practical the Network Management Application shall interact with Route Control Agents to provide them the service of maintaining the best possible routing information, where 'best possible' means avoiding congestion and/or other problems that might arise. The specific alternatives and means by which such interaction shall take place are further described in Section 4.2.2.

Automatic route control
Interaction with existing Route control agents
Determination of link "cost"

1.6 Security Management

It is critical that the Network Management Application be as secure as possible in its operations. It shall avoid being compromised by unauthorized persons. It shall secure network information from unauthorized access. And it shall detect and report attempted breaches of security whenever possible.

All users must be authorized (Tools Team)
automatic Report of invalid login attempts (log?)
automatic Security Breach alarms

All transmissions between process components shall be protected using Public Key Encryption. The specific means by which this will be done is TBD - by Tools Team.

Encryption of all transmissions (Tool Team)

No interactive user shall be granted access to a process that supports an interactive user, without being authentication. The method of authentication shall be TBD - by Tools Team.

All users will be authenticated using method to be determined by Tools Team

In a future version of the Network Management Application it shall be possible to specify data monitoring and alarm notification requests that detect and indicate possible network trespassing. The mechanisms used to specify and handle security monitoring will be similar to those used to specify and handle data collection and statistical performance conditions that cause alarms, as specified in Chapter 4. The main difference will be that the privileged user will identify specific tell-tale network traffic conditions that cause alarm. These may be much different from simple statistical conditions.

Detection of network trespassing using data monitoring and alarm notification requests

Specific patterns to be determined by privileged user

2 Protocol Module(s)

When necessary to effectively accomplish the objectives of the Network Management Application, it will interact with other processes and capabilities on the network. These include SNMP Managers and Agents, Routers, and Route Control Processes. To affect these interactions, the Network Management Application shall use the appropriate protocol. The process components themselves shall use an abstract set of communication procedures that will be the same for all protocols to be supported. Linkage to procedures that implement the appropriate protocol correctly shall be done at process component build time. In this way, for instance, a process component might originally interact with an SNMP agent via SNMPv1, but later be upgraded to use SNMPv2. To the extent that the new features of SNMPv2 are not to be used, the upgrade shall be possible without recompiling the process component. Simply relink it. The Protocol Module, therefore, is a library or set of libraries. Protocols to be supported are SNMP, SNMPv2, CMIP, RMON, and TBD routing protocols. This module shall be readily extensible to support new protocols as they emerge.

Interaction of Big Dog with other processes/capabilities of network
Abstract set of communication procedures
Protocol Module is a Library or set of Libraries.

For each specific protocol supported, security features provided by that protocol shall be used to the fullest extent possible, and to the extent applicable for the purposes of needed interactions. The Protocol Module(s) shall provide a security submodule that will serve to determine the highest level of security available for a specific interaction, and ensure the interaction takes advantage of that security. This submodule shall provide generic encrypt / decrypt services so that a variety of types of encryption may be used, as dictated by specific protocols or protocol implementations, and the use of different encryption methods shall be transparent to the process components.

Use of existing protocol security features for each protocol (don’t reinvent the wheel)

Security routines will exist as a submodule of the Protocol Module

Submodule will provide encrypt/decrypt services in a transparent manner

Next Section

CSC405, Spring '96
Distributed Network Manager (DNM) Interface and Protocol Modules