As per Relevance of the word required, we have this rfc below:
Network Working Group C.
Request For Comment: 1024 BBN/
G.
October 1987
HEMS VARIABLE
STATUS OF THIS
This memo assigns instruction codes, defines object formats
object semantics for use with the High-Level Monitoring and
Language, defined in RFC-1023.
This memo is provisional and the definitions are subject to change
Readers should confirm that they have the most recent version of
memo
The authors assume a working knowledge of the ISO data
standard, ASN.1, and a general understanding of the IP
suite
Distribution of this memo is unlimited
In other memos [RFC-1021, RFC-1022] the authors have described
general system for monitoring and controlling network entities;
system is called the High-Level Entity Management System (HEMS).
This system permits applications to read and write values in
entities which support a simple query processor
In this memo we standardize the language instruction codes,
objects which can be read or written, and the meanings of
constants stored in the objects. There are three parts to
standardization: (1) the assignment of an ASN.1 tag to each value
(2) the definition of the external representation of the value (e.g.,
INTEGER, OCTETSTRING, etc.), and (3) the definition of the meaning
or semantics of a value (e.g., what types of packets a
packet counter actually tracks).
This definition is provisional, and the authors hope that it will
expanded and improved as the community becomes more experienced
HEMS. Readers with suggestions for additional object definitions,
improved definitions are encouraged to contact the authors
Partridge & Trewitt [Page 1]
RFC 1024 HEMS Definitions October 1987
MESSAGE
All HEMS values are conveyed between applications and entities
the High-Level Entity Management Protocol (HEMP) specified in RFC
1022. All values specified in this memo are passed in the
sections of HEMP messages. For all message types, the data
is a SEQUENCE of objects. For requests, these objects are
and their operands. Replies contain a sequence of objects
by a request. Events contain an initial event object followed by
optional number of objects related to the event
Messages conforming to this memo should set the link field in
HEMP CommonHeader to 1, to indicate version 1 of HEMS.
resourceId field should be set to NULL
CONTROL LANGUAGE
The HEMS Monitoring and Control Language defines a suite
operations which the query processor must be able to perform.
operations and their operands are ASN.1 objects which are passed
the query processor over a network connection. The operations
operands are sent in postfix form (the operation follows
operands). Operands are pushed onto a stack and are processed
the operation is encountered
To ensure that operations are easily recognized in the input stream
they are all encoded in a single application-specific type.
type is shown below
Operation ::= [APPLICATION 1] IMPLICIT INTEGER {
reserved(0), get(1) begin(2), end(3),
get-match(4), get-attributes(5),
get-attributes-match(6), get-range(7),
set(8), set-match(9)
}
When the query processor encounters an Operation object it
the value to determine which operation is to be done (e.g., GET).
GENERAL COMMENTS ON OBJECTS STORED IN
The High-Level Monitoring and Control Language requires the
space to have a tree-shaped type space. Locating a particular
requires identifying that section of the tree in which the
resides. (A more detailed explanation of the scheme is given
RFC-1023).
Partridge & Trewitt [Page 2]
RFC 1024 HEMS Definitions October 1987
This memo defines a universal type space. A subset of this
space is expected to be an appropriate type space for any
(e.g., a gateway or a multi-user host). The type space is
into required and optional portions. Implementors should
the required portion of the type space plus that part of the
type space which is appropriate for their particular entity
One problem with defining a universal type space is that
interesting objects are not universal, but are instead very
specific (for example, status registers on specialized hardware).
allow implementors to retrieve such implementation-specific
using the HEMS system, a special APPLICATION type is reserved
non-standard values
Putting objects in ASN.1 form implies an ability to map to and
ASN.1 format. One of the design goals of this system has been
minimize the amount of ASN.1 compilation required by the
processor to reduce the expense of processing queries at entities
(This implies a certain willingness to force the
querying entities to be more powerful). We expect that most of
complex mapping will be done when objects are read; most
objects have a simple format (e.g., an INTEGER, or OCTETSTRING).
a result, we have made a heavy use of the ASN.1 SET type,
allows values to be presented in any order. Applications
require particular fields in an object may use the template
to specify particular fields to be retrieved, but this still
the query processor to return the fields in whatever order
convenient
In addition to ease the problems of ASN.1 compilation,
processors are not required to reduce an INTEGER to the
number of octets as specified in ASN.1. Applications should
prepared to receive INTEGERs which have leading octets with all
or ones
More generally, a design goal of HEMS was to try to limit the
processing done at the entity, and to place the burden of
reduction on the querying application. As a result, the
presented here are typically counters, or values which the entity
to compute already. Object definitions which require the entity
do data reduction are not supported, although consideration might
given to making them optionally available
Finally, HEMS is required to support access by multiple
management centers or applications. This constraint has
important consequences. First, the SET operation cannot be
to any Counter, since changing the value of a Counter may impair
acquisition by other centers. More generally, there are
Partridge & Trewitt [Page 3]
RFC 1024 HEMS Definitions October 1987
about competing or clashing SET requests from management centers
Currently HEMS does not provide any facilities for protecting
such requests. If such facilities become necessary, the
envision the enhancement of the object definitions to incorporate
idea of "owned" objects
READING THE OBJECT
Most of the rest of this memo is devoted to ennumerating the
managed by the query processor. Many of these objects
dictionaries, objects which reference other objects.
dictionaries requires that we specify the class of objects
reference
Most significant objects, such as packet counts, reside at the
of the object data tree. They need to be carefully defined to
that their meaning is consistent across all HEMS implementations
These values are defined using the following format
OBJECT: This is the name of the object
Type: This is the ASN.1 type of the object
Definition: The meaning of the data the object contains
Implementations should ensure that their instance
the object fulfills this definition since an
feature of HEMS is that objects have consistent
across all machines. It is better not to
an object than to abuse its definition
Notes: An optional section of the definition which is
to discuss issues not covered in other sections
this specification
Object Status: An optional section of the definition
is used to indicate whether the object is required of
HEMS implementations, encouraged of HEMS
or simply considered useful. Currently, there are
levels of status
Required: The object is felt to provide
information and must be included in a
conforming HEMS implementation
Required On Condition: The object is felt
provide critical information about an
Partridge & Trewitt [Page 4]
RFC 1024 HEMS Definitions October 1987
feature of an IP entity (for example, support
the Transmission Control Protocol). The
is required if the feature is implemented in
entity
Encouraged: The object is felt to provide
useful management information and
are encouraged to implement it
Defined: The object may be useful and has
defined so that all implementations of the
are consistent
If the object status is not specified, the object
be considered required. If the parent dictionary is optional
then the object should be considered required if the
dictionary is supported
Operations on Object: The definition of how each
and control operation acts on the object. Many
have the same effect on almost all values, so
default definitions are presented here. In the
of an operation specification, implementors should
the default operations defined here
BEGIN: The default is for BEGIN to be defined
dictionaries, and an error if performed on
objects in the tree
CREATE: The default is that CREATE is undefined
DELETE: The default is that DELETE is undefined
END: END is a stack operation and is defined for all objects
Note that END may fail if there is no object on
stack
GET-ATTRIBUTES: The default is that GET-ATTRIBUTES
defined on the contents of all dictionaries
in this memo. The text description
are optional for values defined in this memo,
are required for implementation-specific objects
Any descriptions of object listed in this memo
cite this memo. GET-ATTRIBUTES must be supported
all entity-specific values. GET-
returns a Attributes object, which is defined
the well-known types section below
Partridge & Trewitt [Page 5]
RFC 1024 HEMS Definitions October 1987
GET-ATTRIBUTES-MATCH: The default is
GET-ATTRIBUTES-MATCH is optionally defined on
object which supports GET-MATCH, and is an
otherwise. The rules for attributes returned
GET-ATTRIBUTES-MATCH are the same as those
GET-ATTRIBUTES
GET: The default definition of GET is to emit the
specified is a leaf object, and if the operand is
dictionary, to recursively GET the entire dictionary
its subdictionaries
GET-MATCH: Unless otherwise specified, GET-MATCH is
supported on an object
GET-RANGE: Unless otherwise specified, GET-RANGE is
supported on an object
SET: Unless otherwise specified, SET is not supported on
object
SET-MATCH: Unless otherwise specified, SET-MATCH is
supported on an object
HEMS requires that remote applications be able to discover
meaning of an object by querying the entity in which the object
stored. This is done through use of the GET-ATTRIBUTES operator
which causes an Attributes object to be returned to the application
The Attributes object is described below
Attributes ::= [APPLICATION 2] IMPLICIT SEQUENCE {
tagASN1 [0] IMPLICIT INTEGER
valueFormat [1] IMPLICIT INTEGER
longDesc [2] IMPLICIT IA5String OPTIONAL
shortDesc [3] IMPLICIT IA5String OPTIONAL
unitsDesc [4] IMPLICIT IA5String OPTIONAL
precision [5] IMPLICIT INTEGER OPTIONAL
properties [6] IMPLICIT BITSTRING OPTIONAL
}
The meanings of the various attributes are given below
tagASN1: The ASN.1 tag for this object
This attribute is required
Partridge & Trewitt [Page 6]
RFC 1024 HEMS Definitions October 1987
valueFormat: The underlying ASN.1 type of the
(e.g., SEQUENCE, or OCTETSTRING). This
is required
longDesc: A potentially lengthy text description
fully defines the object. This attribute is
for objects defined in this memo and required
entity-specific objects
shortDesc: A short mnemonic string of less than 15
which is suitable for labelling the value on a display
This attribute is optional
unitsDesc: A short string used for integer values
indicate the units in which the value is
(e.g. "ms", "sec", "packets", etc). This
is optional
precision: For Counter objects, the value at which
Counter will roll-over. Required for all
objects
properties: A bitstring of boolean properties of
object. If the bit is on, it has the given property
This attribute is optional. The bits
defined are
0 -- If true, the difference between two
of this object is significant. For example
the changes in a packet count is
significant, it always conveys information
In this case, the 0 bit would be set. On
other hand, the difference between two
of a queue length may be meaningless
IMPLEMENTATION SPECIFIC
Each vendor or implementation specific value must be contained
an VendorSpecific object. The format of the VendorSpecific object
shown below
Type:
VendorSpecific ::= [APPLICATION 3] IMPLICIT SET of
Partridge & Trewitt [Page 7]
RFC 1024 HEMS Definitions October 1987
For a detailed discussion of the need for this type, see RFC 1023.
WELL-KNOWN
There are some generally useful types which are defined across
system and are considered well-known. These types support
notions that are frequently used in other definitions
TYPE:
Error ::= [APPLICATION 0] IMPLICIT SEQUENCE {
errorCode INTEGER
errorOffset
errorDescription IA5String
}
The Error type is returned within reply messages when an error
countered. The errorCode is a number specifying a general class
error. The errorOffset is the octet in the query where the error
discovered. Note that the query starts at the first octet (octet 0)
of the HEMP data section. The errorDescription is a text
explaining the error. Note that the definition of this section
the same (except for the start of the offset) as that of the
protocol error structure and the error codes have been selected
keep the code spaces distinct. This is intended to ease
processing of error messages. The defined errorCodes are
100 -- Any error not listed below
101 -- System error. The query processor has
in some way
102 -- Format error. An error has been detected
the input stream
103 -- Stack error. A stack overflow or underflow
occurred
104 -- Instruction error. The instruction is
unknown, or not supported on the object to
it has been applied
105 -- Operand error. The wrong number of operands
inappropriate operands have been given to
instruction
Partridge & Trewitt [Page 8]
RFC 1024 HEMS Definitions October 1987
TYPE:
Counter ::= [APPLICATION 4] IMPLICIT
The Counter type is an unsigned integer which is defined to roll-
to 0 when incremented past a certain value. (The roll-over point
be found by examining the attributes for the particular counter.)
Counter sizes should be chosen such that the counters will not
over more than once every 24 hours
TYPE:
InstructionGroup ::= [APPLICATION 5] IMPLICIT
of
An InstructionGroup is an encapsulated sequence of operands
operations. It allows applications to encode queries as objects
TYPE:
Histogram ::= SET of
HistEntry ::= SEQUENCE {
histValue INTEGER
histCount
}
A Histogram associates a count, histCount, with a numeric value
histValue. No meaning is placed on the count or value by
definition. Each HistEntry may represent a simple map (e.g.,
histCount instances of histValue), or a more complex
(e.g., a count of all values between this histValue and the
lowest histValue in the Histogram). The meaning of the
Histogram is given in the object definition
TYPE:
TrafficMatrix ::= SET of
TrafficEntry ::= SEQUENCE {
src IpAddress
dst IpAddress
count
}
A TrafficMatrix measures traffic observed between two IP addresses
Typically it is used to count packets flowing through a gateway
Partridge & Trewitt [Page 9]
RFC 1024 HEMS Definitions October 1987
TYPE:
IpAddress ::=
The 4 octet IP address. If the length of the string is less than 4
then the missing octets are wildcarded. A zero length string is
default address (e.g., for indicating default routes).
TYPE:
Fraction ::=
A Fraction is an integer representation of a fractional value.
contains the numerator of a value as expressed over 256. (
example dividing the Fraction by 256 gives the fractional value.)
TYPE:
BootClock ::=
The time in milliseconds since the machine was last booted or reset
This value is always defined
TYPE:
LocalClock ::=
The local system clock, measured in milliseconds since 00:00 1
January 1900 UTC. Assumed to be only a local estimate of the time
The value 0 is reserved for an uninitialized clock (For example,
uninitialized time-of-day chip.)
TYPE:
NetClock ::=
A network synchronized clock, which is assumed to be
across some part of a network. The clock value is measured
milliseconds since 00:00 1 January 1900 UTC. Specific
about the synchronization protocol is found in the system
dictionary. The value 0 is used to indicate an uninitialized clock
TYPE:
TimeStamp ::= CHOICE {
[0]
Partridge & Trewitt [Page 10]
RFC 1024 HEMS Definitions October 1987
[1]
[2]
}
A TimeStamp, which was taken from the boot clock, system clock or
synchronized clock. In general, a time of day is preferred to
time since boot, and a synchronized clock is preferred to
unsynchronized clock. It is more useful to know that an
occurred at a particular time, than that it happened so
milliseconds after the machine booted
OBJECT
The Root
In HEMS, all data is stored in dictionaries, where a dictionary
thought to represent a conceptual grouping of values. The top-
dictionary is the root dictionary. The form of the root
for is shown below
RootDictionary ::= [APPLICATION 32] IMPLICIT SET {
SystemVariables
EventControls OPTIONAL
Interfaces
IpNetworkLayer
IpRoutingTable
IpTransportLayer
IpApplications
}
The root dictionary is split into seven general dictionaries
- SystemVariables, which stores general system values
as the system clock, machine memory and system up/
status
- EventControls, which stores all objects necessary
observe and control the event generating mechanism
entities which support events
- interfaces, which contains all information on
the network interfaces and IP to physical
maps (ARP tables, X.25 Standard mappings, etc).
- IpNetworkLayer, which contains information about
workings of the IP layer. This includes information
as routing tables, general packet counts, and host-
Partridge & Trewitt [Page 11]
RFC 1024 HEMS Definitions October 1987
matrices
- IpRoutingTable, which contains information on how
machine routes packets. It proved more useful to
routing information than to keep it stored with the
layer data
- IpTransportLayer, which stores information on the
protocols that the entity supports
- IpApplications, which may store information about
internet applications such as the domain system.
section is not required of HEMS entities
The next several sections define the values stored in the
dictionaries
The SystemVariables
The SystemVariables dictionary stores objects which are not
protocol, network, or application specific. Such objects
values such as the machine load, clocks and the processor status
The form of the dictionary is shown below
SystemVariables ::= [APPLICATION 33] IMPLICIT SET {
referenceClock [0] IMPLICIT TimeStamp
netClockInfo [1] IMPLICIT SET OPTIONAL
processorLoad [2] IMPLICIT INTEGER
entityState [3] IMPLICIT INTEGER
kernelMemory [4] IMPLICIT OCTETSTRING OPTIONAL
pktBuffers [5] IMPLICIT INTEGER OPTIONAL
pktOctets [6] IMPLICIT INTEGER OPTIONAL
pktBuffersFree [7] IMPLICIT INTEGER OPTIONAL
pktOctetsFree [8] IMPLICIT INTEGER
systemID [9] IMPLICIT IA5STRING
}
OBJECT:
Type:
Definition: see
The objects in the dictionary are defined below
OBJECT:
Partridge & Trewitt [Page 12]
RFC 1024 HEMS Definitions October 1987
Type:
Definition: The system clock used for placing timestamps
information. Use of a NetClock is encouraged
Operations on Object: Defaults
Notes: Cross-network clock adjustment is best handled by a
time synchronization protocol, not through the use of SET
OBJECT:
Type:
Definition: Detailed information on the referenceClock if
referenceClock is a NetClock. The format of
information is shown below
netClockInfo ::= [1] IMPLICIT SET {
estError INTEGER
refClockType INTEGER {
unspecified(0), primary-reference(1),
ntp-secondary-reference(2), secondary-reference(3),
wristwatch(4)
}
}
The estError is the estimated error in milliseconds.
refClockType is a value indicating the type of
clock consulted for network time (the values are
directly from the Network Time Protocol specification
RFC-958).
Object Status: Required if the referenceClock is a NetClock
OBJECT:
Type:
Definition: A value, expressed as a Fraction, which
the current processing load on the entity. A value
256 (= 1.0) is defined to be running at capacity.
is recognized that this is an imprecise definition
capacity can be measured in several ways. For example
a multiprocessor may still have plenty of
even if one processor is running at capacity
Partridge & Trewitt [Page 13]
RFC 1024 HEMS Definitions October 1987
or it may be at capacity because that processor is
master processor and handles all context switching
The idea is for remote applications to be able to get
sense of the current workload on the entity. Also
that the time scale of the measurement should be small
A load measure that averages over the past 10
is acceptable but a load measure that averages over
past 10 minutes is not. Implementors should chose
mapping between system load and this scale such that 256
represents a machine under severe strain. (Note that
suggests that values greater than 256 may be returned
rare cases.)
OBJECT:
Type:
Definition: An object which indicates the system state. There
several defined object values. Some values are read-only
can only be read from the object. Over values are write-
and will never be read from the object. Over values
write-only and will never be read from the object.The
are
The read-only values are
(0) -- reserved
(1) -- running. The entity is up and running
(2) -- testing. The entity is running some sort
diagnostics which may affect its
operation
The write-only values are
(0) -- reserved
(1) -- reset the entity
(2) -- reboot the entity. This value is assumed
cause a more aggressive recycling of the
than reset, though this need not be the case
(3) -- halt the entity. This value stops
entity. It assumed to prevent the entity
operating until it is manually restarted. (I.e
the halt takes the machine off the network).
Partridge & Trewitt [Page 14]
RFC 1024 HEMS Definitions October 1987
Note: The ability to change an entity's state requires very
access controls
Operations on Object: The defaults except as noted below
SET: Optionally writes the value into the object
The message requesting the SET must be authenticated
SET-MATCH: Optionally writes the value into the
if the current value is matched
OBJECT:
Type:
Definition: A sequence of octets which represents the image of
kernel software running on the entity. This facility
provided to allow remote network debugging
By kernel software, we mean that software which controls
operations and access to the hardware. In particular, the
is expected to contain all network software up through the
layer
Implementations which use lightweight processes or
images should consider providing some way to map their
representation into a single contiguous stream of octets
Note: Access control is required to read this object
Object Status: Useful
Operations on Object: The defaults except as noted below
GET-RANGE: Emits the section of memory specified
GET: Emits all of memory, but note that a GET on the
dictionary should *not* emit this object
OBJECT:
Type:
Definition: The total number of packet buffers in the entity
Object Status: Required if the entity has a maximum number
buffers. Note that most entities do have a limit (even if
Partridge & Trewitt [Page 15]
RFC 1024 HEMS Definitions October 1987
is for practical purposes, near infinite) and should
that limit
OBJECT:
Type:
Definition: The maximum number of octets that can be buffered in
entity at any one time
Object Status: Required if the entity has a maximum number of
it can buffer. Note that most entities do have a limit
should return that limit
OBJECT:
Type:
Definition: The number of packet buffers currently available
Subtracting pktBuffersFree from pktBuffers should give
number of buffers in use
Object Status: Required if there is a limit on the number
buffers
OBJECT:
Type:
Definition: The number of octets currently available including
not used in allocated buffers. Subtracting this value
pktOctets should give the number of octets in use
This object can be used to track how well the entity buffers
data
Object Status: Required if there is a limit on the number
octets that can be buffered
OBJECT:
Type: IA5
Definition: The text identification of the entity. This
should include the full name of the vendor, the type of system
Partridge & Trewitt [Page 16]
RFC 1024 HEMS Definitions October 1987
and the version number of the hardware and software running
the entity
The EventControls
The EventControls dictionary contains objects to control
monitor the delivery of event messages to operations centers
The format of this dictionary is shown below
EventControls ::= [APPLICATION 34] IMPLICIT SET OPTIONAL {
lastEvent [0] IMPLICIT OCTETSTRING OPTIONAL
eventMessageID [1] IMPLICIT Counter
eventCenters [2] IMPLICIT SET of IpAddress
eventList [3] IMPLICIT SET of eventEntry
}
OBJECT:
Type:
Definition: See above
Object Status: This object will be required in entities
support events, after the event definitions have
properly specified. See discussion of the event
at the end of this memo
A description of the fields in this dictionary are given below
OBJECT:
Type:
Definition: The last event message sent
Object Status: Implementation of this object is encouraged if
transport protocol used for events is unreliable (e.g., UDP).
OBJECT:
Type:
Partridge & Trewitt [Page 17]
RFC 1024 HEMS Definitions October 1987
Definition: The HEMP MessageId to be used in the next
message. Equals the number of events sent
OBJECT:
Type: SET of
Definition: The list of IP addresses to which events are sent
This list receives all events. For more selective
monitoring, centers should list themselves under
particular events of interest
Note: If the SET operator is defined then use of some form
access control is recommended
Operations on Object: The defaults except as listed below
CREATE: Adds an address to the list. The new address
not be a broadcast address (it may be a
address).
DELETE: Deletes an address from the list
SET-MATCH: Defined on the IP address. Replaces
address with a new value
EMIT-MATCH: Defined on the IP address
OBJECT:
Type: SET of
Definition: An array of entries which contain objects which
management centers to control how and when events are sent
(The contents of the eventEntry structure are explained below.)
The eventControls Dictionary: eventList/
The eventEntry provides the necessary control objects to manage
a particular event is sent. The format of the eventEntry is
below
eventEntry ::= [0] IMPLICIT SET {
eventID [0] IMPLICIT INTEGER
eventMode [1] IMPLICIT INTEGER
eventCount [2] IMPLICIT Counter
threshold [3] IMPLICIT Counter
Partridge & Trewitt [Page 18]
RFC 1024 HEMS Definitions October 1987
thresholdIncr [4] IMPLICIT INTEGER
eventExecution [5] IMPLICIT InstructionGroup OPTIONAL
eventCenters [6] IMPLICIT SET of
}
OBJECT:
Type:
Definition: See Above
OBJECT:
Type:
Definition: The particular event ID
OBJECT:
Type:
Definition: A control object which determines how and whether
event is sent. The three modes are
0 -- unused
1 -- off. The event is not sent
2 -- on. The event is sent every time it occurs
3 -- threshold. The event is sent every time
event count reaches the threshold
OBJECT:
Type:
Definition: The number of times this event has occurred
OBJECT:
Type:
Partridge & Trewitt [Page 19]
RFC 1024 HEMS Definitions October 1987
Definition: The event threshold. If the eventMode is "threshold
then a event is sent every time the eventCount equals
value
Operations on Object: The defaults except as noted below
SET: Changes the threshold
OBJECT:
Type:
Definition: The threshold increment. Every time a event
is reached, the threshold value is incremented by this
(modulo the precision of the Counter) to find the
threshold
Operations on Object: The defaults except as noted below
SET: Changes the increment
OBJECT:
Type:
Definition: A query to be executed whenever the event is
sent. Any data retrieved by this query is appended to
event message
Object Status: Encouraged
Operations on Object: The defaults except as noted below
SET: Changes the buffer
OBJECT:
Type:
Definition: The IP addresses of the monitoring centers which
to listen to this particular event. Note that events should
sent to both these centers and the global list of event centers
Operations on Object: The defaults except as noted below
CREATE: Adds an address to the list of centers
Partridge & Trewitt [Page 20]
RFC 1024 HEMS Definitions October 1987
DELETE: Deletes an address from the list
SET-MATCH: Defined on the IP address. Replaces
entry with a new value
EMIT-MATCH: Defined on the IP address
The Interfaces
The Interfaces dictionary a list of per-interface objects.
one of the fundamental goals of HEMS is to use generic
across differing hardwares, all hardware interfaces are described
the same data structure, the InterfaceData
Interfaces ::= [APPLICATION 35] IMPLICIT SET OF
OBJECT:
Type:
Definition: see above
The Interfaces Dictionary: The InterfaceData structure
The InterfaceData structure contains all information on a
interface. The form of the structure is shown below
InterfaceData ::= [0] IMPLICIT SET {
addresses [0] IMPLICIT SET of IpAddress
mtu [1] IMPLICIT INTEGER
netMask [2] IMPLICIT IpAddress
pktsIn [3] IMPLICIT Counter
pktsOut [4] IMPLICIT Counter
inputPktsDropped [5] IMPLICIT Counter
outputPktsDropped [6] IMPLICIT Counter
bcastPktsIn [7] IMPLICIT Counter OPTIONAL
bcastPktsOut [8] IMPLICIT Counter OPTIONAL
mcastPktsIn [9] IMPLICIT Counter OPTIONAL
mcastPktsOut [10] IMPLICIT Counter OPTIONAL
inputErrors [11] IMPLICIT Counter
outputErrors [12] IMPLICIT Counter
outputQLen [13] IMPLICIT INTEGER
name [14] IMPLICIT IA5String
status [15] IMPLICIT INTEGER
ifType [16] IMPLICIT INTEGER
mediaErrors [17] IMPLICIT Counter OPTIONAL
Partridge & Trewitt [Page 21]
RFC 1024 HEMS Definitions October 1987
upTime [18] IMPLICIT TimeStamp
broadcast [19] IMPLICIT
multicast [20] IMPLICIT SET of BITSTRING
addressList [21] IMPLICIT SET OPTIONAL
}
OBJECT:
Type:
Definition: see above
Operations on Object: The defaults except as noted below
SET-MATCH: This operation is optionally defined on
address field of the structure. Only certain
in this structure may be changed. The fields
may be SET are indicated in the descriptions below
GET-MATCH: Defined to emit information on the
which matches the address given
The fields in the structure are defined below
OBJECT:
Type: SET of
Definition: The IP addresses that the interface accepts. Note
additional information on multicast addresses may be found
the IgmpValues dictionary
OBJECT:
Type:
Definition: The maximum transmission unit of the device
OBJECT:
Type:
Definition: The subnet mask, which is an address with all
network bits set to 1 and all the hosts bits set to 0. Used
identify subnets
Partridge & Trewitt [Page 22]
RFC 1024 HEMS Definitions October 1987
OBJECT:
Type:
Definition: The total number of packets received on this
including those in error
OBJECT:
Type:
Definition: The total number of packets that higher levels
attempted to send, including those that were not sent
OBJECT:
Type:
Definition: The number of good inbound packets dropped (
to free up buffer space).
OBJECT:
Type:
Definition: The number of good outbound packets dropped (
to free up buffer space).
OBJECT:
Type:
Definition: The number of broadcast packets received
those in error
Object Status: Encouraged on interfaces that support broadcast
OBJECT:
Type:
Definition: The number of broadcast packets that higher
attempted to send, including those that were not sent
Object Status: Encouraged on interfaces that support broadcast
Partridge & Trewitt [Page 23]
RFC 1024 HEMS Definitions October 1987
OBJECT:
Type:
Definition: The number of multicast packets received
those in error
Object Status: Encouraged on interfaces that support multicast
OBJECT:
Type:
Definition: The number of multicast packets sent, including
that were not sent
Object Status: Encouraged on interfaces that support multicast
OBJECT:
Type:
Definition: The number of inbound packets that could not
delivered. The number of inbound packets
should equal inputPkts less this value and inputPktsDropped
OBJECT:
Type:
Definition: The number of outbound packets that could not
transmitted because of errors. The number of
packets placed on the network should equal
less this value and outputPktsDropped
OBJECT:
Type:
Definition: The length of the output packet queue (in packets).
OBJECT:
Type: IA5
Partridge & Trewitt [Page 24]
RFC 1024 HEMS Definitions October 1987
Definition: A text string completely identifying the interface
This string should include the name of the manufacturer,
product name and the version of the hardware
OBJECT:
Type:
Definition: The status of the object. The status values are
0 --
1 -- testing (the interface is in some test mode
2 -- down (the interface is down
3 -- up (the interface is up ready to pass packets
Note: If set operations are defined, access control is required
Operations on Object: The defaults except as noted below
SET: Optionally defined to change the state of the interface
OBJECT:
Type:
Definition: A flag which indicates the type of interface in use.
currently defined types are
0 --
1 -- 1822
2 -- 1822
3 --
4 -- DDN X.25
5 -- RFC-877 X.25
6 --
7 -- Proteon 10
8 -- Proteon 80
9 --
10 -- 802.3
11 -- 802.4 Token
12 -- 802.5 Token
13 -- Point-to-Point
OBJECT:
Type:
Partridge & Trewitt [Page 25]
RFC 1024 HEMS Definitions October 1987
Definition: A counter of media errors, such as collisions
Ethernets, token regeneration on token passing rings, or
RFNMs on PSNs
Object Status: Encouraged for interfaces to media which have
errors
OBJECT:
Type:
Definition: When the interface was put in its current state
OBJECT:
Type:
Definition: Whether this interface has a physical
address
Object Status: Required if the interface has a broadcast adddress
OBJECT:
Type: SET of
Definition: The set of hardware multicast addresses
enabled on the device
Object Status: Encouraged in interfaces which support multicast
OBJECT:
Definition: SET of
addressMap ::= [0] IMPLICIT SET {
ipAddr [0] IMPLICIT
physAddr [1] IMPLICIT
}
Definition: Most interfaces maintain tables mapping
network address to IP address. An example is an ARP table
This table stores that map as a series of entries which
Partridge & Trewitt [Page 26]
RFC 1024 HEMS Definitions October 1987
IP addresses to the physical address
Object Status: Required if the interface has to map IP addresses
physical addresses
The IpNetworkLayer
The IpNetworkLayer dictionary contains all information about the
Layer. The format of the dictionary is shown below
IpNetworkLayer ::= [APPLICATION 36] IMPLICIT SET {
gateway [0] IMPLICIT BOOLEAN
inputPkts [1] IMPLICIT Counter
inputErrors [2] IMPLICIT Counter
inputPktsDropped [3] IMPLICIT Counter
inputQLen [4] IMPLICIT INTEGER OPTIONAL
outputPkts [5] IMPLICIT Counter
outputErrors [6] IMPLICIT Counter
outputPktsDropped [7] IMPLICIT Counter
outputQLen [8] IMPLICIT INTEGER OPTIONAL
ipID [9] IMPLICIT Counter
fragCreated [10] IMPLICIT Counter OPTIONAL
fragRcvd [11] IMPLICIT Counter OPTIONAL
fragDropped [12] IMPLICIT Counter OPTIONAL
pktsReassembled [13] IMPLICIT Counter OPTIONAL
pktsFragmented [14] IMPLICIT Counter OPTIONAL
htm [15] IMPLICIT TrafficMatrix OPTIONAL
itm [16] IMPLICIT TrafficMatrix
}
OBJECT:
Type:
Definition: See above
The fields of the dictionary are defined below
OBJECT:
Type:
Definition: A boolean value which is true if the entity
packets
Partridge & Trewitt [Page 27]
RFC 1024 HEMS Definitions October 1987
OBJECT:
Type:
Definition: The total number of input packets received
those in error
OBJECT:
Type:
Definition: The number of input packets discarded due to
(unknown protocols, format errors, etc).
OBJECT:
Type:
Definition: The number of input packets dropped for lack of
space
OBJECT:
Type:
Definition: The number of inbound packets currently waiting to
processed by the IP layer
Object Status: Encouraged
OBJECT:
Type:
Definition: The total number of outbound packets including
those packets presented to the IP layer by higher layers
packets which are gatewayed
OBJECT:
Type:
Definition: The number of output packets discarded because
Partridge & Trewitt [Page 28]
RFC 1024 HEMS Definitions October 1987
errors (unable to route, format errors, etc).
OBJECT:
Type:
Definition: The number of output packets dropped for lack
buffer space
OBJECT:
Type:
Definition: The number of outbound packets waiting to be
by the IP layer
Object Status: Encouraged
OBJECT:
Type:
Definition: The next IP packet ID identifier to be used.
that in some implementations the transport layer may set
IP identifier, in which case this value is used if the
identifier has not been set by the transport layer
OBJECT:
Type:
Definition: The number of IP fragments created at this entity
(e.g., if an IP is split into three fragments at this entity
then this counter is incremented by three).
Object Status: Encouraged
OBJECT:
Type:
Definition: The number of IP fragments received at this entity
Object Status: Encouraged
Partridge & Trewitt [Page 29]
RFC 1024 HEMS Definitions October 1987
OBJECT:
Type:
Definition: The number of IP fragments discarded at this
for whatever reason (timed out, errors, etc).
Object Status: Encouraged
OBJECT:
Type:
Definition: The number of IP datagrams that have been
at this entity
Object Status:
OBJECT:
Type:
Definition: The number of IP datagrams that have been
at this entity
Object Status: Encouraged
OBJECT:
Type:
Definition: A host traffic matrix, mapping all traffic switched
pair of sources and destinations. The count in each
routeDst is expressed in packets. Source routed IP
should be logged as being between their source and
destination (i.e., they should not be treated as destined
this entity).
Notes: This information may be considered sensitive
Object Status: Encouraged in gateways
OBJECT:
Partridge & Trewitt [Page 30]
RFC 1024 HEMS Definitions October 1987
Type:
Definition: An interface traffic matrix showing traffic
between interfaces in an entity. The source and
fields are the IP addresses of the interfaces between
the packet was switched. The count in each trafficEntry
expressed in packets
Object Status: Useful
The IpRoutingTable
The IpRoutingTable dictionary contains all routing information
Note that information about any routing protocols used to
the routing table is found under the entry for the routing protocol
The format of the routing dictionary is shown below
IpRoutingTable ::= [APPLICATION 37] IMPLICIT SET {
routingProtocols [0] IMPLICIT OCTETSTRING
coreRouter [1] IMPLICIT BOOLEAN
autoSys [2] IMPLICIT INTEGER
metricUsed [3] IMPLICIT OCTET
[4] RoutingEntries
}
OBJECT:
Type:
Definition: See above
The objects contained in the dictionary are described below
OBJECT:
Type:
Definition: A sparse list of the routing protocols used to
the routing table (e.g., EGP and ICMP). Each octet contains
of the following values
0 -- anything not specified below
1 -- local (non-protocol) information. (E.g
routing tables can be changed by hand).
Partridge & Trewitt [Page 31]
RFC 1024 HEMS Definitions October 1987
2 -- HEMS (was changed/set by a HEMS operation
3 -- Internet Control Message Protocols, (i.e
ICMP redirects).
4 -- Exterior Gateway Protocol (EGP).
5 -- Gateway-to-Gateway Protocol (GGP).
6 -- Dissimilar Gateway Protocol (DGP).
7 --
8 --
9 -- Proprietary
OBJECT:
Type:
Definition: This value is set to true if this entity is a
router for any other router (i.e., if it distributes any of
routes to other machines).
OBJECT:
Type:
Definition: The autonomous system number of the autonomous system
which this entity resides
OBJECT:
Type:
Definition: Classifies the routing metric used in the routing
entries. The value should be chosen from the list of values
routingProtocols above, and indicates the metric definition
(e.g., this entity uses an EGP metric internally).
OBJECT:
Type: SET of
Partridge & Trewitt [Page 32]
RFC 1024 HEMS Definitions October 1987
Definition: The set of all routing entries. The RoutingEntry
defined below
The IpRoutingTable Dictionary: The
The RoutingEntry contains all information on a particular route
The format of the structure is shown below
RoutingEntry ::= [0] IMPLICIT SET {
routeMetric [0] IMPLICIT INTEGER
routeDst [1] IMPLICIT IpAddress
nextHop [2] IMPLICIT IpAddress
routeAuthor [3] IMPLICIT IpAddress OPTIONAL
routeproto [4] IMPLICIT Octet OPTIONAL
routeTime [5] TimeStamp
routeTOS [6] IMPLICIT INTEGER OPTIONAL
valid [7] IMPLICIT
}
OBJECT:
Type:
Definition: See above
Operations on Object: Defaults except as specified below
CREATE: Adds a new routing entry. It should be
that the entry is new
DELETE: Deletes a routing entry
GET-MATCH: The match operator is defined on the
field. A match on an IpAddress is defined to be
search to find the route or routes which would
used to reach the IpAddress. More than one
may be applicable, in which case all possible
should be returned
SET-MATCH: Is optionally defined on the object. A
on an entire RoutingEntry replaces the entire
with a new value. Certain fields (indicated below
can also be changed using a SET-MATCH
The match operator is defined on the routeDst
routeTOS fields. To SET a value, the match must
exact on the IP address (this is different from
Partridge & Trewitt [Page 33]
RFC 1024 HEMS Definitions October 1987
search definition for GET-MATCH).
Note that support of the operator on an
which uses a dynamic routing protocol such
GGP or EGP will require close coordination
the routing protocol to ensure consistent data
(Arguably, this facility should not be
on such machines).
The definitions of the fields in the RoutingEntry are given below
OBJECT:
Type:
Definition: The routing metric on this route. Note that the type
metric is defined in the metricUsed field of the
dictionary
OBJECT:
Type:
Definition: The final destination that can be reached via
route
OBJECT:
Type:
Definition: The next hop to the final destination
OBJECT:
Type:
Definition: The IP address of the entity from which this route
*first* received. That is, the first entity which stated
was reached via nextHop. The default IpAddress should be
to indicate routes which originated on the entity
Object Status: Encouraged
OBJECT:
Partridge & Trewitt [Page 34]
RFC 1024 HEMS Definitions October 1987
Type:
Definition: The routing protocol from which this route was learned
The value is taken from the list of values for
above
Object Status: Encouraged
OBJECT:
Type:
Definition: When this route was first received
Object Status: Encouraged
OBJECT:
Type:
Definition: The IP Type of Service which this routing entry serves
Object Status: Required if type of service routing is supported
OBJECT:
Type:
Definition: Whether the route is active. (Some machines
routes which are no longer valid for various reasons.)
The IpTransportLayer
The IpTransportLayer Dictionary contains any information
pertains to transport protocols which use the IP protocol as
network protocol. For ease of reference, the ASN.1 tag of
transport protocol's dictionary is the same as the assigned
Protocol number. The definition of the
dictionary is shown below. Note that dictionaries for
protocols are not yet defined
IpTransportLayer ::= [APPLICATION 38] IMPLICIT SET {
[0] IMPLICIT ProtocolsSupported
[1] IMPLICIT IcmpValues
[2] IMPLICIT IgmpValues OPTIONAL
Partridge & Trewitt [Page 35]
RFC 1024 HEMS Definitions October 1987
[3] IMPLICIT GgpValues OPTIONAL
[7] IMPLICIT TcpValues OPTIONAL
[8] IMPLICIT EgpValues OPTIONAL
[17] IMPLICIT UdpValues OPTIONAL
[20] IMPLICIT HmpValues OPTIONAL
[27] IMPLICIT RdpValues OPTIONAL
[30] IMPLICIT NetbltValues OPTIONAL
}
OBJECT:
Type:
Definition: see above
The objects in the dictionary are defined below
The IpTransportLayer Dictionary:
OBJECT:
Type:
Definition: Sparse list of transport protocols supported.
octet in the OCTETSTRING contains the IP protocol number of
supported protocol. For the purposes of this definition,
entity supports a protocol if it both contains software
makes it possible for the protocol to be used
communications with the entity, AND the entity keeps
required values (if any) defined in this memo for that protocol
The IpTransportLayer Dictionary:
The IcmpValues dictionary is a subdictionary of the
dictionary which tracks the workings of the Internet Control
Protocol, defined in RFC-792. The form of the dictionary is
below
IcmpValues ::= SET {
inputPktCount [0] IMPLICIT Counter
inputPktErrors [1] IMPLICIT Counter
inputPktDeliver [2] IMPLICIT Counter
inputPktTypes [3] IMPLICIT Histogram OPTIONAL
outputPktCount [4] IMPLICIT Counter
outputPktErrors [5] IMPLICIT Counter
outputPktTypes [6] IMPLICIT Histogram OPTIONAL
icmpTraffic [7] IMPLICIT TrafficMatrix OPTIONAL
ipID [8] IMPLICIT Counter
Partridge & Trewitt [Page 36]
RFC 1024 HEMS Definitions October 1987
}
OBJECT:
Type:
Definition: see above
The objects in the dictionary are defined below
OBJECT:
Type:
Definition: The total number of ICMP packets received (
those in error).
OBJECT:
Type:
Definition: The number of ICMP packets received which proved
have errors (bad checksums, bad length etc). Subtracting
value from the inputPktCount field should give the number
valid ICMP packets received
OBJECT:
Type:
Definition: The number of valid ICMP packets which
successfully processed (e.g., delivered to the
protocol).
OBJECT:
Type:
Definition: A histogram of ICMP messages types and codes received
not including those messages that proved to contain errors
The histogram histValue field contains a 16-bit value which
the the (ICMP type * 256) + ICMP code, and the histCount
contains the number of valid messages containing
Partridge & Trewitt [Page 37]
RFC 1024 HEMS Definitions October 1987
type/code pair which have been received
The message type and code values are those defined in RFC-792
(e.g., the Time Exceeded Message with a code of "
reassembly time exceeded" is (11 * 256) + 1 = 2817).
Object Status: Useful
Operations on Object: The defaults except as listed below
GET-MATCH: Match is defined on the value of the
field
OBJECT:
Type:
Definition: The total number of ICMP packets that the
attempted to send (including those that failed due to lack
buffers, a missing route or other transient
problems).
OBJECT:
Type:
Definition: The number of ICMP packets which the entity could
send due to transmission problems such as the lack of buffers,
missing route or other transient transmission problems.
value is not required to include errors which the ICMP
could not reasonably be expected to detect such as damage to
packet in transit. Subtracting this value from the
field should give the number of ICMP packets the entity
it successfully sent
OBJECT:
Type:
Definition: A histogram of ICMP messages types and codes sent
including those messages that later failed to be transmitted
The histogram histValue field contains a 16-bit value which
the the (ICMP type * 256) + ICMP code, and the histCount
contains the number of valid messages containing this type/
pair which have been sent
Partridge & Trewitt [Page 38]
RFC 1024 HEMS Definitions October 1987
The message type and code values are those defined in RFC-792
(e.g., the Time Exceeded Message with a code of "
reassembly time exceeded" is (11 * 256) + 1 = 2817).
Object Status: Useful
Operations on Object: The defaults except as listed below
GET-MATCH: Match is defined on the value of the
field
OBJECT:
Type:
Definition: All ICMP traffic which has originated on this machine
The source address in the traffic matrix should be the
from which the packet was sent. The destination is the
to which the packet is to finally be delivered (not
intermediate hop).
Object Status: Useful
OBJECT:
Type:
Definition: The next IP packet ID identifier to be used by the
code
Object Status: Required if the ICMP code generates its own
identifiers
The IpTransportLayer Dictionary:
IgmpValues ::= SET {
conformance [0] IMPLICIT INTEGER
inputPktCount [1] IMPLICIT Counter
inputPktErrors [2] IMPLICIT Counter
inputPktTypes [3] IMPLICIT Histogram OPTIONAL
outputPktCount [4] IMPLICIT Counter
outputPktErrors [5] IMPLICIT Counter
outputPktTypes [6] IMPLICIT Histogram OPTIONAL
igmpTraffic [7] IMPLICIT TrafficMatrix
Partridge & Trewitt [Page 39]
RFC 1024 HEMS Definitions October 1987
igmpGroups [8] IMPLICIT SET of IgmpGroupEntry
ipID [9] IMPLICIT Counter OPTIONAL
}
OBJECT:
Type:
Definition: The dictionary of information on the Internet
Management Protocol (RFC-988).
Object Status: Required in hosts which support IGMP
The objects stored in this dictionary are defined below
OBJECT:
Type:
Definition: The level of conformance with RFC-988. The
levels are
0 -- Level 0. No support for IP
1 -- Level 1. Support for sending but not
multicast datagrams
2 -- Level 2. Full support for IP multicasting
These values are taken directly from RFC-988.
OBJECT:
Type:
Definition: The number of IGMP packets received including
that proved to be in error
OBJECT:
Type:
