 |
Claims  |
|
|
What is claimed is:
1. An apparatus for remotely managing diverse information network
resources, comprising:
a plurality of heterogeneous, remote devices of functionally diverse
classes, each device providing raw information in one of a plurality of
heterogeneous formats, wherein said format is specific to each device and
to each device functional class;
a protocol module located at a network management site and in communication
with said remote devices for scheduling remote device polls to optimize
remote device polling and minimize use of said information network;
a values module located at said network management site for storing data
obtained by polling said remote devices, wherein said data are
representative by events that occur at said remote devices as the events
occur over time, said values module being operable to store, retrieve, and
manipulate said raw information, said values module including a time stamp
for use in connection with recording a time of occurrence of said remote
device events, processing time varying data from said stored remote device
events, and for storing common groupings of said raw information;
a nonprocedural builder module located at said network management site and
operable to generate a data specification module; said data specification
module located at said network management site and operable to store
information that specifies device content and behavior for each of said
heterogeneous, functionally diverse, remote devices in the form of a
device specific representation, wherein said representation appears to a
user in the same format for each device within a device functional class
even though each functional class may include a plurality of heterogeneous
remote devices;
an engine located at said network management site, said engine being
operable to read information stored in said data specification module and
to generate said device specific representation for each of said remote
devices therefrom and, based on the contents of said data specification
module and said raw information from said remote devices, to control
operation of said remote devices, to enable polls of said remote devices
by said protocol module, to process said raw information in accordance
with said information stored in said data specification module, to process
said common groupings of said raw information stored in said values module
from two or more of said remote devices to generate information
characterizing inter-device performance therefrom, and to generate poll
results for each of said remote devices in the form of said device
specific representations; and
a user interface module located at said network management site, and,
responsive to said engine, for displaying said device specific
representations of said remote devices at said network management site as
a user controlled virtual panel.
2. The apparatus of claim 1, wherein said engine allows user configuration
and control of said remote devices while viewing said device specific
representation.
3. The apparatus of claim 2, wherein said protocol module issues simple
network management protocol ("SNMP") requests to said remote devices.
4. The apparatus of claim 1, wherein said engine implements user directed
control of remote device operational parameters.
5. The apparatus of claim 1, wherein said device specific representation is
dynamically updated by said engine to provide current remote device
information.
6. The apparatus of claim 1, wherein said device specific representation
may be interactively updated by a user to display remote device specific
information based on user demand.
7. A method for remotely managing an information network including a
plurality of heterogeneous, remote devices of functionally diverse
classes, each device providing raw information in one of a plurality of
heterogeneous formats, wherein said format is specific to each device and
to each device functional class, said method comprising the steps of:
scheduling remote device polls with a protocol module located at a network
management site and in communication with said remote devices to optimize
remote device polling and minimize use of said information network;
storing data obtained by said remote device polling, wherein said data are
representative of events that occur at said remote devices with a values
module located at said network management site as the events occur over
time, said values module being operable to store, retrieve, and manipulate
said raw information, said values module including a time stamp for
recording a time of occurrence of said remote device events, processing
time varying data from said stored remote device events, and for storing
common groupings of said raw information;
generating a data specification module with a nonprocedural builder module
located at said network management site;
storing information in said data specification module that specifies device
content and behavior for each of said heterogeneous, functionally diverse,
remote devices in the form of a device specific representation, wherein
said representation appears to a user in the same format for each device
within a device functional class even though each functional class may
include a plurality of heterogeneous remote devices;
reading information stored in said data specification module with an engine
located at said network management site;
generating said device specific representation for each of said remote
devices with said engine;
with said engine, controlling operation of said remote devices, enabling
polls of said remote devices by said protocol module, processing said raw
information in accordance with said information stored in said data
specification module, processing said common groupings of said raw
information stored in said values module from two or more of said remote
devices to generate information characterizing inter-device performance
therefrom, and generating poll results for each of said remote devices in
the form of said device specific representations; and
displaying said device specific representations of said remote devices as a
user controlled virtual panel with a user interface module located at said
network management site.
8. The method of claim 7, wherein said engine allows user configuration of
said remote devices.
9. The method of claim 8, further comprising the step of: issuing simple
network management protocol ("SNMP") requests to said remote devices with
said protocol module.
10. The method of claim 7, further comprising the step of: allowing user
setting of remote device operational parameters with said engine.
11. The method of claim 7, further comprising the step of: dynamically
updating said representation with said engine to display current remote
device information.
12. The method of claim 7, further comprising the step of: interactively
updating said representation with said engine to display remote device
information based on user demand. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to data transfer networks. More particularly,
the present invention relates to remote management of network elements in
a data transfer network.
2. Description of the Prior Art
Until recently, data processing meant batch processing using enormous
mainframe computers. Mainframe computers contained all of the system
intelligence and served this intelligence on a time sharing basis to a
variety of dumb peripheral devices, such as terminals, printers, etc.
The centralization of batch processing and mainframe computing is now
giving way to a society of intelligent users, such as workstations,
servers, etc., distributed across a network. Thus, in modern data
processing architecture the mainframe has been turned inside out. That is,
each remote location in a modern network is a powerful individual, while
the network is becoming a highly sophisticated interconnecting nervous
system, akin to an internal mainframe bus in complexity, or perhaps even
more complex.
The advantages of providing considerable computing power to individuals on
their desktops are well recognized. As networks are required to handle
increasing volumes of information, the network itself must become
increasingly intelligent. The network must manage network traffic, network
resources, user and management requests; it must detect failures and
collisions, reroute traffic, and even repair itself. If this task were not
formidable enough, the network must allow for the considerable diversity
of network elements the many vendors of netware provide, in such manner
that each and every network element not only communicates with other
network elements, but so that network management is a straightforward and
relatively simple task.
The state of the art provides many options to a network designer, including
highly intelligent network devices, such as routers, switches, etc., that
use the network to send status information to a net manager, and that may
be configured remotely by commands issued from a network manager. Thus,
the industry recognizes a standard network management protocol, the
`simple network management protocol` ("SNMP"), by which the devices of
different manufacturers may be controlled using a common command set and
data format.
Devices that respond to and communicate with SNMP commands rely on
manufacturer supplied agent management software that is resident in a
network management data base. An example of such device is the AsanteHub
1012 10 BaseT hub and the AsanteView.TM. management software, manufactured
by Asante Technologies of Sunnyvale, California.
The user interlace of each manufacturer's sortware for each agent has its
own `look and feel.` Thus, although the protocols that each agent uses are
the same, there is no commonly accepted user interface. The state of the
art is such that the various proprietary software drivers are, at best,
difficult for a network manager to use and maintain. For example, the user
interface in most such drivers may or may not require the manipulation of
strings of raw data, or the entry of data into crude forms. Thus, highly
skilled personnel are required to perform a tedious and repetitive task.
Accordingly, a network administrator is faced with occupying maintenance
personnel with the many problems attendant with inconsistent equipment
models: redundant manipulation and entry of the same data in different
formats, inconsistent and inaccurate network models, stale data as
information from one piece of equipment does not track that of other
equipment, slow operator response on a network level to equipment changes,
new training is required for administrative personnel when a new piece of
equipment is added to the network, etc., all in the context of many
complex device drivers that are difficult and expensive to use and
maintain.
A network failure carries the potential for significant damage to network
users, e.g. through lost or miscommunicated data. Network administrator
response is less than optimum when the administrator is expected
simultaneously to recognize and respond to many different non-intuitive
data presentations. Thus, present day network management technology does
not reduce the likelihood of injury to a network user in the event of
failure. Accordingly, such technology is at best at a crude state of
development.
A single point of maintenance for network resources, much like a control
tower at an airport, is necessary to assure efficient and secure use of
the network. A consistent, intuitive representation of all network
elements would allow decisions to be made on resource allocation,
maintenance, etc. based on meaningful information.
SUMMARY OF THE INVENTION
The present invention provides a network management system in which various
elements, such as hubs, routers, workstations, etc., distributed across a
data exchange network are remotely controlled from a single point of
maintenance.
The present invention provides a consistent approach for managing the
hardware resources of a network. The present invention provides a set of
consistent displays for remote front panels providing visual management of
remote, heterogeneous devices, while also allowing non-graphical data to
be displayed in a usable form.
At its highest architectural level, the present invention consists of three
components: a compiler that allows the creation of device specification
files (DSFs) from device specification language (DSL) specifications, an
engine that allows remote management of these devices, and network
agent-specific DSFs.
The engine reads a DSF created by the builder and produces a view of the
agent for remote management. Therefore, multiple DSFs may be provided for
the various devices in the network, using the same engine for each agent.
The device specification file defines the graphical view of the agent as
multiple objects or hotspots. Depending on the properties of the hotspot,
certain functions are available. For example, selecting a port allows
additional monitoring and/or configuration to be performed; the agent may
be polled for certain management information base (MIB) attributes which
may be displayed in a table, graph, etc. Additionally, the present
invention allows the abstraction of raw data to present agent information
in otherwise unavailable formats.
System rules provide conventions by which network operational data
representative of real time network activities may be modeled in a virtual
environment. Timestamping and data caching assure that an accurate
representation of the network is provided, while actual use of the network
by the management system is minimized.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a network management system architectural
model according to a preferred embodiment of the present invention;
FIG. 2 is a schematic drawing of a hypothetical front panel view for a hub
according to a preferred embodiment of the present invention;
FIG. 3 is a block schematic representation of a values module architecture
according to a preferred embodiment of the present invention;
FIG. 4 is a block schematic representation of a poll architecture according
to a preferred embodiment of the present invention; and
FIG. 5 is a schematic drawing of a hypothetical report view according to a
preferred embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
The present invention is best understood by referring to the Drawings in
connection with review of this Description. The present invention provides
a network management system that allows control of various network
elements and processes from a single point of maintenance.
The present invention provides a consistent approach for managing the
hardware resources of a network. In one embodiment, the invention is a set
of consistent displays for remote front panels providing visual management
of remote, heterogeneous devices.
As shown in FIG. 1, the present invention consists of three components: a
compiler or builder 10 for producing graphical representations of remotely
located vendor-specific devices (device specification files or "DSFs"), an
engine 14 for the remotely managing these devices, and the DSFs 12a-12n.
The engine 14 reads the agent specification created by the compiler 10 and
produces a view of the agent for remote management at a management
location 11. The invention allows multiple device specification files
12a-12n, using the same engine to drive these files.
The device specification file defines the graphical view of the agent as
multiple objects or `hotspots`. The invention provides certain functions,
depending on the properties of the hotspot. For example, selecting a port
allows additional monitoring and/or configuration of the port.
The agent may be polled for certain MIB attributes which may be displayed
in a table, graph, etc. The polled attributes are static for a given DSF,
but the display mechanism is user-selectable from a fixed set of options.
Thus, information may be represented in otherwise unavailable formats. In
particular, raw agent data may be processed to derive desired information
in a desired format. A version identifier is stored in the DSF to assure
compatibility with future versions of the engine.
Hardware. In the preferred embodiment of the invention, the engine runs on
the Sun SPARCstation platform. There are many different platlorms for
other embodiments of the invention that are possible and within the scope
of the present invention. Such platforms may include, for example SCO,
Int.sub.e l x86, RS6000, and others.
Development Tools. The preferred embodiment of the present invention is
implemented in C++.
Architectural Model
High-Level Description. The present invention provides a consistent
mechanism for managing heterogeneous devices. The engine 14, by supporting
distinct devices through separate device specification files 12a-12n
("DSFs"), allows the user to remotely monitor and control diverse devices
or agents 24a-24n in a consistent way.
The DSF includes powerful building blocks with which a useful management
application for each network agent can be created. Typically, a visual
representation of the front panel of a agent is developed, with certain
pictorial elements, such as LEDs, given special functionality. These
elements can be defined such that they are updated on a regular basis to
give an accurate, visual view of the current state of the agent. Windows
containing agent-specific information in tabular or graphical form can
also be created using these building blocks.
An important feature provided by the present invention is data abstraction.
The DSF can specify that information to be displayed be manipulated using
a set of built-in operations provided by the engine. For example, rather
than displaying the total number of collisions for a port, the present
invention can instead display the percentage of collisions relative to the
total number of packets for a port. This gives the user a significantly
more useful view of the data available.
The present invention also provides poll optimization. If one piece of MIB
data, for example, is displayed in several windows, the present invention
optimizes the generation of polls so that only one poll is sent for that
piece of data, rather than one poll for each window. In addition, the
present invention transparently combines polls for different pieces of
data whenever possible to limit the proliferation of polls, and thus
minimize use of the network for management activities.
The engine also gives the user a form of security by providing two modes of
operation: read-only and read-write, with a visual indicator of the
current mode. The present invention can only be in one mode at any given
time. Placing the present invention in read-only mode helps to prevent
accidental configuration of the agent.
Brief Descriptions of Architectural Elements
Control. The control 16 is responsible for system startup and shutdown; it
also registers "events" of global interest (e.g. reception of SNMP trap);
receives requests from the user interface 18 ("UI") to issue SNMP set
requests; and provides additional functionality, such as logging,
configuration scripts, etc.
User Interface. The user interface 18 defines user interface component
types, instantiating, and updating components; and implements some command
functionality, such as open/close view, switch between read/read-write
mode.
Device Specification Language ("DSL") Compiler. The DSL compiler or builder
10 is responsible for parsing of device specification files; and makes
calls to the user interface and values modules (described in greater
detail below) to set up component types, global values, and histories.
Values Module. The values module 20 is responsible for system internal
storage and manipulation of information received from a remote agent.
Protocol Module. The protocol module 22 is responsible for communication
with management targets 24a-24n (e.g. SNMP items).
The DSL and the User Interface Module
The DSL is used to create files which are compiled by the DSL compiler 10
to provide specifications from which the User Interface Module 18
registers component types defined in the DSF, configure the system
dialogs, and instantiate or abstract specific components.
Type Registration. The DSF contains type definition records. These type
definition records describe the information needed to create a new type.
To register a new type, the record must describe the built-in type from
which the defined type is sub-classed, as well as the name of the new
type. The DSL Module parses this information, and then calls the function
that registers a new type in the UI Module. An identifier is returned that
allows the registration of other information (properties and rules)
described in the type definition record.
Property Registration. During the parsing of a type definition record,
after the new type has been registered, additional properties are defined.
These properties are registered by name for the current type.
Rules Registration. Type definition records contain rules that are unique
to the type they define. These rules define the value of specific
properties and typically contain value expressions. Once the value
expressions are parsed, and the expression is registered, the rule is
registered with the UI Module. For example, a rule can be registered that
sets the color of an LED based on the value of a set of attributes sampled
from a remote agent.
Component Registration. Type definition records refer to other types as
sub-components of the type being defined. This feature of the invention
allows the construction of composite types. These components are referred
to by type name. Geometry and instantiation information are also
described. Given this information, a type may be registered as a
sub-component of the defined type.
Component Instantiation
The construction of component instances from their registered type
definitions is also governed by the rules described above. Thus, the
structure of views can be dependent on the information obtained from the
agent. Components having a dependency of this type are not constructed
until type information is available.
Component Interaction
Component interact by reading the values of other components properties.
Some of this interaction is set up and specified by the DSF, while other
interactions are set up automatically.
DSL and the Values Module
DSL 10 processes information that contains various expressions. These
expressions are supported by the Values Module 20. Thus, there is
considerable use of the Values Module by DSL.
Parsing Expressions. The DSL decode module is responsible for parsing
expressions. As expressions are parsed, the expression builder functions
are called in a bottom-up manner. When the entire expression is parsed and
built, then the expression may be registered with the expression
evaluation module 46 (FIG. 3). The expression does not need to be
registered unless other expressions refer to that expression.
The expression is registered if the function is declared to have a name.
Once the expression is registered, the Values Module can retrieve an
expression identifier by name when references are made in the DSF to that
function name. Thus, the Values Module can function as a simple symbol
table for expressions.
Some component types defined in the DSL have expressions that are used in
some component-specific manner. In general, this expression type is not
given a name. However, depending upon the component, the function name is
registered with the Values Module. This allows the implementation of the
component to refer to an expression by the expression identifier, rather
than require the maintenance of pointers to expression structures. The DSL
decode module supports either method.
Registering Histories. Some values must be collected over time, even when
there are no views displayed that are interested in these values. For
example, it may be necessary to access data that was available during the
lifetime of the current system session to plot the change of a value over
time in a graph. When implementing a DSF, it is possible to specify that
some datum, or expression is kept as a history. Histories must be
explicitly declared in the DSF. A history has an expression, the value of
which is kept in the history. The history also has data indicating the
desired sample rate, storage limits, and technique used for trading
accuracy for storage space in past samples.
Expressions Referencing Component Properties. Properties can be referenced
in expressions. This allows the values of properties to affect the values
of other properties in a manner specified by the DSF. Properties of the
current component are referred to by the property identifier. The DSL
parsing module must map property names to property identifiers for the
type currently being parsed.
User Interface Module
The user interface module 18 is responsible for providing much of the
visible functionality of the present invention. The user interface module
provides routines that create new component types, add properties to a
component type, and add subcomponents to a component type. The DSL module
makes calls to these routines as it reads the information provided in a
device specification file.
The UI Module uses the interface provided by the Values Module. That is,
the UI Module registers callbacks on changes in values maintained by the
Values Module. In some cases, the UI Module acts as a source of data for
the Values Module, e.g. text entered by the user is provided as data for
the Values Module. The Values Module provides routines that perform input
conversion. The Values Module is also responsible for evaluating the
expressions that check the semantic validity of the user supplied
information.
DSF Defined Component Types
New component types are defined in each device specification file. Defined
types are generally instantiated for use in a system session, rather than
built-in types. Defined types are derived directly from a built-in
component type and inherits all functionality of the built-in type.
Device Specification. The DSF contains agent-specific information. It
contains the object identifier (sysObjectlD in SNMP) of the devices that
it supports, as well as the protocol to use to get information from the
primary agent. There must always be a primary or super agent that knows
about additional agents for a device, or additional protocols.
As devices are predefined to use some set of community strings for
reading/writing groups of MIB objects, these groups and their associated
community string identifier must also be defined in the DSF. This enables
the display of a control window, including appropriate prompts when
community strings are specified.
The DSF contains component information that defines the format of the
picture. The actual picture depends on values obtained from the agent. The
components are static upon instantiation; the values of the components
vary. The DSF contains details on how to obtain data from agents (i.e. the
MIB is contained in the DSF). Therefore, updated MIBs necessitate a new
version of the corresponding DSF if support for additional MIB objects is
required.
Compilation. A DSF is distributed for each agent supported by the engine.
It contains all of the information necessary for the present invention to
manage the agent type. Each DSF is translated by a compiler into an agent
specification, which is used by the engine.
Registering Histories. Some values must be collected over time, even when
there are no views displayed that are interested in these values. For
example, a graph may want access to data that was available during the
lifetime of the current session to plot the change of a value over time. A
DSF may specify that some datum or expression is kept as a history.
Histories must be explicitly declared in the DSF. A history has an
expression, the value of which is kept in the history. It also has data
indicating the desired sample rate, storage limits, and technique used for
trading accuracy for storage space in past samples.
Protocol Support
SNMP is supported in the preferred embodiment of the invention. Support for
other protocols, such as CMIP, is considered within the scope of the
present invention.
Initiation. The invention can be invoked from the command line with
optional parameters. When it is invoked without parameters, a control view
is displayed which prompts the user for an agent name. The invention
provides a field for the user to type in the agent name or IP address.
Once the view for an agent has been successfully initiated, a new agent
cannot be specified.
The protocol module 22 uses the host name to obtain the IP address of the
host. An SNMP request is sent to the agent to identify the type of device.
A unique piece of information is retrieved that allows the selection of
the appropriate DSF. In the preferred embodiment of the invention this
information is the System Object Identifier.
The DSFs are located in one or more directories. The system configuration
file, created and/or updated upon installation by a separate utility, is
used to identify the specific DSF.
Community strings may also be provided on the command line, for possible
invocation from a network management platform. The engine assumes all
community strings on SNMP devices are public, if community strings are
provided on the command line, they become the defaults. A control window
is also available from the user interface to modify the community strings
used to communicate with the agent(s).
Configuration Files
In addition to information provided by DSL, the invention requires
additional configuration information to operate. The configuration file
provides mappings from Agent identifier to DSF.
System Oonfiguration. Mapping is satisfied by the system configuration
file. This file is accessible to every user in a network who is running
the invention; it is not customizable on a user-by-user basis. There is a
list of mappings within the file, each of which contains the following:
Agent id to DSL Maps a type of agent to a DSF (SysObject ID in SNMP).
Component Definition
The component control module possesses functionality that supports
component types defined in the DSF. This functionality is defined as
follows:
Type Registration. New types of components must be registered for use in
the system. This registration takes the following information:
name of the component type
identifier of the base type
Once the component type is registered, it can be referenced as a
sub-component of another defined component type. Additional type
parameters, such as additional properties, expressions for property
values. sub-components, and sub-component instantiation rules can also be
declared.
Addition of Properties. Once a component is initially registered,
properties that are not included in the built-in type may be added by
registering the properties. Registration involves the following
information:
component type identifier
property name
Property registration returns a property identifier. The property
identifier is unique for a specific property name across all component
types. This allows property references contained in expressions to be
fixed during the parsing of the expression.
Properties serve as state information for the component. They can be viewed
as local variables for component instances. Properties of built-in types
may have real functionality. The values of built-in properties may be
interpreted by the implementation as information describing display
attributes. For example, TEXT could be a property of a text symbol, and
the value of TEXT could be a string that defines what text is displayed to
the user.
Addition of Rules. Rules are statements of invariance that describe the
value of properties, based upon information that can be referenced in an
expression. A rule is in the form of "<property> is <expression>". Rules
are added by rule registration, which includes the following information:
component type identifier
property identifier
expression identifier
argument bindings
Argument bindings are references to instance properties. These properties
are set at instantiation. Instantiation properties may not change.
Properties other than instantiation properties may not be used as
arguments in rules, although the expression associated with a rule may
reference properties. Argument bindings may also be constraints.
Addition of Sub-Components. A defined type may include sub-components that
are not part of the base component type. The base components of the
defined component must explicitly support the base component types of the
sub-components. For example, a DSF might define a particular type of
dialog with several text and label components, but not picture components.
The base type dialog must explicitly support text and label components,
but need not support picture components.
The addition of sub-components as a parameter of a defined type is done
through sub-component registration. Registration involves the following
information:
component type identifier
type identifier of the sub-component
geometry and positioning information
instantiation information
instance properties
Registration returns the sub-component identifier (note that this is not a
type identifier). This identifier is unique for the defined component.
Properties of the sub-component must be referenced by the sub-component
identifier.
Component Interaction. Defined components interact in two ways. The first
component interaction is by default to built-in behavior. For example, on
the issuance of a configure command from the user, a configuration dialog
interacts with associated sub-component text symbols to get the symbols'
contents.
The second component interaction is by property values, and by interpreting
the values of specific properties in expressions. Components may refer to
the properties of their parents and their children in expressions. Such
reference is accomplished by a built-in Values Module operation. This
operation involves a component instance (only known after instantiation),
a component identifier (sub-component, self, or parent) and a property
identifier. The component instance is passed as an implicit argument to
all expressions.
References to a Child's Properties. A sub-component must be identified to
reference a property of a sub-component. In the invention, a property
value retrieval procedure involves a sub-component identifier and a
property identifier. As the property identifier is constant for all types,
it is not necessary to know the type of the sub-component when
constructing the expression. The expression has access to an implicit pass
of a component instance argument. Thus, the sub-component identifier
functions as a local reference for the object when referencing the child's
property. Reference to a subcomponent property uses the function
`read.sub.-- prop` in an expression (defined below).
References to a Parent's Properties. Parent type is not known until
instantiation occurs. To construct an expression with a reference to a
parent property at the time class definition occurs, it is necessary that
all property identifiers be well known and based upon the property name,
or that the property identifier be passed as an argument to the
expression. The preferred embodiment of the invention employs constant
property identifiers to construct the expression. Reference to a parent
property occurs in an expression, using the function `read.sub.-- prop`
(defined below).
Built-In Components. The engine portion of the invention includes a set of
built-in components, each of which is implemented in a C++ class derived
from a Component type base class. Specific descriptions of these
components follow:
Graphs
Functionality
Properties
Window System Layer Function Calls
Protocol
Graph Server
User Interface Functionality
This section discusses the user inteface ("UI"). Two levels of UI
functionality exist. At one level, the invention supports the definition
and description of user intefaces which are tailored to a particular type
of network agent.
A higher level, the invention provides UI functionality as seen by the end
user. This includes what windows, or views, a user is shown when using the
present invention, and the operations that a user can perform using
invention.
Functionality Overview. The user inteface consists of a set of views (see
FIG. 2, which is a schematic representation of a hypothetical front panel
view for a hub). Each view is displayed as a separate window on the user's
screen. A view provides access to a particular part of the invention's
functionality. The primary functionality associated with a view falls into
one of four categories:
1. Display of Information Retrieved from the Managed Device. This
encompasses the display of raw and derived data, such as packet counts,
error rates, bandwidth utilization, etc., in various forms.
2. Configuration of the Managed Device. The invention supports issuing of
SNMP set requests.
3. Control. This encompasses such operations as setting operational
parameters (e.g. system poll rate and community strings), quitting the
application, etc.
4. Help. Help views contain detailed information describing the displayed
data. They also display information describing possible operations from
the view.
Some views are completely defined by the engine. The functionality and
appearance of these views are independent of the particular type of agent
managed. However, the majority of the views are tailored to a particular
type of agent, and therefore are not completely defined and implemented by
the engine. These agent specific view | | |
