As per Relevance of the word monitoring, we have this rfc below:
Network Working Group C.
Request For Comment: 1021 BBN/
G.
October 1987
THE HIGH-LEVEL ENTITY MANAGEMENT SYSTEM (HEMS
STATUS OF THIS
An overview of the RFCs which comprise the High-Level
Management System is provided. This system is experimental, and
currently being tested in portions of the Internet. It is hoped
this work will help lead to a standard for IP
management. Distribution of this memo is unlimited
Until recently, a majority of critical components in IP networks
such as gateways, have come from a very small set of vendors.
each vendor had their own set of management protocols and mechanisms
the collection was small, and a knowledgeable system
could be expected to learn them all
Now, however, the number of vendors has grown quite large, and
lack of an accepted standard for management of network components
causing severe management problems. Compounding this problem is
explosive growth of the connected IP networks known as the Internet
The combination of increased size and heterogeneity is
internetwork management extremely difficult. This memo discusses
effort to devise a standard protocol for all devices, which
help alleviate the management problem
The RFCs that currently define the High-Level Entity
System are this memo along with RFC-1022, 1024, and 1023. This
is expected to change and grow over time, and readers are
encouraged to check the RFC Index to find the most current versions
MONITORING AND
Historically, the IP community has divided network management
two distinct types of activities: monitoring and control.
is the activity of extracting or collecting data from the network
a part of the network to observe its behavior. Control is
activity of taking actions to effect changes in the behavior of
network or a part of the network in real-time, typically in
attempt to improve the network's performance
Partridge & Trewitt [Page 1]
RFC 1021 HEMS Overview October 1987
Note that the ability to control presupposes the ability to monitor
Changing the behavior of the network without being able to
the effects of the changes is not useful. On the other hand
monitoring without control makes some sense. Simply
what is causing a network to misbehave can be useful
Control is also a more difficult functionality to define.
operations other than the most generic, are usually device-specific
The problem is not just a matter of providing a mechanism
control, but also defining a set of control operations which
generally applicable across a diverse set of devices.
remote applications to exercise control over an entity also
the need for a suite of safeguards to ensure that
applications cannot harm the network
Because monitoring is the key first step, in this initial design
the system, the authors have concentrated more heavily on
problems of effective monitoring. Although the basic
mechanisms are defined, many components need for control, such
strong access control mechanisms, have not been fully defined
OVERVIEW OF THE
The HEMS is made up of three parts: a query processor which
reside on any addressable entity, an event generator which
resides on entities, and applications which know how to send
to the query processor and interpret the replies. The
processor and applications communicate using a message protocol
runs over a standard transport protocol
The Query
The query processor is the key to the management system.
interprets all monitoring and control requests. For optimal
management, we would like to see query processors on most
entities
To encourage the implementations of query processors, one of
primary goals in designing the query processor was to make it
small and simple as possible, consistent with
requirements
Defining the management requirements was no small task, since
networking community has not yet reached a consensus about what
of monitoring information should be available from network entities
nor what control functions are required to properly manage
entities. The standards for HEMS were developed through
with several interest groups, and represent the authors' best
Partridge & Trewitt [Page 2]
RFC 1021 HEMS Overview October 1987
to distill the varying sets of needs
The authors settled on a system which was extensible, robust
host-architecture independent, and as simple as possible,
with the other goals. Extensibility was essential because it
clear that management needs will continue to evolve, and a
system which could not be changed would be obsolete almost as soon
it was defined. Unfortunately, extensibility is also the
least consistent with simplicity since the need to make the
extensible led the authors to use self-describing data formats and
interpreted query language
A robust system is required if the system is to be useful
diagnosing network failures. If the monitoring system cannot
at least moderate network failures, it is not useful
The query processor is designed to be highly extensible.
application sends the query processor instructions about objects
be examined or changed. The query processor locates the objects
its host entity, and performs the requested operations. The
are self-describing, using the binary-encoding scheme defined in
Standard ASN.1. Care has been taken to use a limited set of
ASN.1 coding set, so that query processor's handling of data can
optimized
It is a key feature of HEMS that messages to the query
contain multiple instructions. The authors felt that this would
much higher performance than a remote procedure system which
an application to one operation per message
The set of maintained objects is standardized across all entities
Every entity is required to manage a small set of objects.
addition, entities of a particular type (e.g., a gateway) may
required to manage a larger set of objects, which are optional
other entities. Entities are also permitted to make additional
entity-specific objects available to applications. A method
discovering the existence of additional objects is defined
The combination of self-describing data, the ability to add to
standard data set, and a query language which can be easily
appeared to offer the necessary extensibility
Event
On many network entities, particularly critical network
such as gateways, it is necessary to have a way for the devices
send unsolicited status messages to network management centers.
the IP community, these messages have historically been referred
Partridge & Trewitt [Page 3]
RFC 1021 HEMS Overview October 1987
as "traps", but for compatibility with the ISO nomenclature, in
HEMS system they are called "events".
In the HEMS system, events are handled as slightly
replies to queries, and are sent to one or more management centers
Like all other HEMS messages, events are formatted in ASN.1 format
Each event is given a well-known code, which is standardized
all entities. Provision is also made for entity specific
codes
The HEMS expects that applications will be more intelligent than
query processor. Among other functions, the applications will
to be able to identify and parse entity-specific values which may
returned
The details of applications are largely not discussed in the
specifications because there is very little that needs to
standardized. Applications must send requests using the
discussed in the next section, but the interfaces the
provide for displaying monitoring or control information are
application dependent
Query processors and applications communicate using an application
specific monitoring protocol, the High-Level Entity
Protocol (HEMP). This protocol provides the formatting rules for
queries and their replies
HEMP runs over a standard transport protocol. There was a
amount of debate in the community about what type of
protocol was best suited for monitoring. The key issue was
reliable monitoring interactions needed to be
The authors expect that three types of management activities
predominate: status monitoring, firefighting, and event reporting
Status monitoring is envisioned as occasional retrieval of
information, possibly in response to the receipt of event messages
In these situations, the network is expected to be in good
condition, and monitoring exchanges could probably comfortably
with an unreliable transport protocol. The chance of data loss
small, and probably not a serious problem since the data is
to be so important that it must be reliably delivered. (However,
should be noted that some applications may prefer reliable
Partridge & Trewitt [Page 4]
RFC 1021 HEMS Overview October 1987
because it is more convenient.)
Firefighting is a completely different situation. In this scenario
one or more sites are using management applications to try to
and fix a network problem. Here we must assume that while
network functions (i.e., data can get through), it is not
healthy. We should assume that packets are being lost, that
routes will be non-optimal and that it is essential that
monitoring data (which is presumably diagnostic) get back to
application and that control requests are reliably delivered to
entity. In such circumstances, a reliable protocol is essential
Events provide yet another bit of complexity. Events contain
status information, but experience suggests that this
does not have to be delivered reliably. If the problem is
enough, it will re-occur and the event will be sent again
Furthermore, events will often be sent to more than one
center, which would appear to preclude the use of connection
oriented, reliable protocols such as TCP for events
The current decision has been to establish two possible
options for HEMS. More experimental systems may use the
Message Transaction Protocol (VMTP), an experimental IP
protocol. Near term production systems can use a combination of
Transmission Control Protocol (TCP) and the User Datagram
(UDP), as described in RFC-1022.
Compatibility with Common Management Information Protocol (CMIP
Several groups have expressed interest in being able to
applications which can use both HEMS and the emerging ISO-
Common Management Information Protocol (CMIP). It turns out
such a co-existence is feasible, and the authors have made an
to accomodate it
At the highest level, both CMIP and HEMS perform operations
objects stored in remote entities, and both systems use ASN.1
formatting to represent those objects. This makes it possible
develop a standard set of interface routines which can be used
access either system, even though underlying mechanics of the
are quite different
Partridge & Trewitt [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
