GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1024

Network Working Group C.Partridge Request For Comment: 1024 BBN/NNSC

                                                            G. Trewitt
                                                              Stanford
                                                          October 1987
                     HEMS VARIABLE DEFINITIONS

STATUS OF THIS MEMO

 This memo assigns instruction codes, defines object formats and
 object semantics for use with the High-Level Monitoring and Control
 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 the
 memo.
 The authors assume a working knowledge of the ISO data encoding
 standard, ASN.1, and a general understanding of the IP protocol
 suite.
 Distribution of this memo is unlimited.

INTRODUCTION

 In other memos [RFC-1021, RFC-1022] the authors have described a
 general system for monitoring and controlling network entities; this
 system is called the High-Level Entity Management System (HEMS).
 This system permits applications to read and write values in remote
 entities which support a simple query processor.
 In this memo we standardize the language instruction codes, the
 objects which can be read or written, and the meanings of any
 constants stored in the objects.  There are three parts to this
 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 particular
 packet counter actually tracks).
 This definition is provisional, and the authors hope that it will be
 expanded and improved as the community becomes more experienced with
 HEMS.  Readers with suggestions for additional object definitions, or
 improved definitions are encouraged to contact the authors.

Partridge & Trewitt [Page 1] RFC 1024 HEMS Definitions October 1987

MESSAGE FORMATS

 All HEMS values are conveyed between applications and entities using
 the High-Level Entity Management Protocol (HEMP) specified in RFC-
 1022.  All values specified in this memo are passed in the data
 sections of HEMP messages.  For all message types, the data section
 is a SEQUENCE of objects.  For requests, these objects are operations
 and their operands.  Replies contain a sequence of objects retrieved
 by a request.  Events contain an initial event object followed by an
 optional number of objects related to the event.
 Messages conforming to this memo should set the link field in the
 HEMP CommonHeader to 1, to indicate version 1 of HEMS.  The
 resourceId field should be set to NULL.

CONTROL LANGUAGE INSTRUCTIONS

 The HEMS Monitoring and Control Language defines a suite of
 operations which the query processor must be able to perform.  These
 operations and their operands are ASN.1 objects which are passed to
 the query processor over a network connection.  The operations and
 operands are sent in postfix form (the operation follows the
 operands). Operands are pushed onto a stack and are processed when
 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.  This
 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 consults
 the value to determine which operation is to be done (e.g., GET).

GENERAL COMMENTS ON OBJECTS STORED IN ENTITIES

 The High-Level Monitoring and Control Language requires the object
 space to have a tree-shaped type space.  Locating a particular object
 requires identifying that section of the tree in which the object
 resides.  (A more detailed explanation of the scheme is given in
 RFC-1023).

Partridge & Trewitt [Page 2] RFC 1024 HEMS Definitions October 1987

 This memo defines a universal type space.  A subset of this type
 space is expected to be an appropriate type space for any entity
 (e.g., a gateway or a multi-user host).  The type space is divided
 into required and optional portions.  Implementors should implement
 the required portion of the type space plus that part of the optional
 type space which is appropriate for their particular entity.
 One problem with defining a universal type space is that certain
 interesting objects are not universal, but are instead very machine
 specific (for example, status registers on specialized hardware).  To
 allow implementors to retrieve such implementation-specific objects
 using the HEMS system, a special APPLICATION type is reserved for
 non-standard values.
 Putting objects in ASN.1 form implies an ability to map to and from
 ASN.1 format.  One of the design goals of this system has been to
 minimize the amount of ASN.1 compilation required by the query
 processor to reduce the expense of processing queries at entities.
 (This implies a certain willingness to force the applications
 querying entities to be more powerful).  We expect that most of the
 complex mapping will be done when objects are read; most writable
 objects have a simple format (e.g., an INTEGER, or OCTETSTRING).  As
 a result, we have made a heavy use of the ASN.1 SET type, which
 allows values to be presented in any order.  Applications which
 require particular fields in an object may use the template structure
 to specify particular fields to be retrieved, but this still permits
 the query processor to return the fields in whatever order is
 convenient.
 In addition to ease the problems of ASN.1 compilation, query
 processors are not required to reduce an INTEGER to the minimum
 number of octets as specified in ASN.1.  Applications should be
 prepared to receive INTEGERs which have leading octets with all zeros
 or ones.
 More generally, a design goal of HEMS was to try to limit the data
 processing done at the entity, and to place the burden of data
 reduction on the querying application.  As a result, the objects
 presented here are typically counters, or values which the entity has
 to compute already.  Object definitions which require the entity to
 do data reduction are not supported, although consideration might be
 given to making them optionally available.
 Finally, HEMS is required to support access by multiple network
 management centers or applications.  This constraint has some
 important consequences.  First, the SET operation cannot be applied
 to any Counter, since changing the value of a Counter may impair data
 acquisition by other centers.  More generally, there are questions

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 against
 such requests.  If such facilities become necessary, the authors
 envision the enhancement of the object definitions to incorporate the
 idea of "owned" objects.

READING THE OBJECT DEFINITIONS

 Most of the rest of this memo is devoted to ennumerating the objects
 managed by the query processor.  Many of these objects are
 dictionaries, objects which reference other objects.  Defining
 dictionaries requires that we specify the class of objects they
 reference.
 Most significant objects, such as packet counts, reside at the leaves
 of the object data tree.  They need to be carefully defined to ensure
 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 of
         the object fulfills this definition since an important
         feature of HEMS is that objects have consistent meaning
         across all machines.  It is better not to implement
         an object than to abuse its definition.
 Notes:  An optional section of the definition which is used
         to discuss issues not covered in other sections of
         this specification.
 Object Status:  An optional section of the definition which
         is used to indicate whether the object is required of all
         HEMS implementations, encouraged of HEMS implementations
         or simply considered useful.  Currently, there are four
         levels of status:
             Required:  The object is felt to provide critical
             information and must be included in a fully
             conforming HEMS implementation.
             Required On Condition:  The object is felt to
             provide critical information about an optional

Partridge & Trewitt [Page 4] RFC 1024 HEMS Definitions October 1987

             feature of an IP entity (for example, support of
             the Transmission Control Protocol).  The object
             is required if the feature is implemented in the
             entity.
             Encouraged:  The object is felt to provide very
             useful management information and implementors
             are encouraged to implement it.
             Defined:  The object may be useful and has been
             defined so that all implementations of the object
             are consistent.
         If the object status is not specified, the object should
         be considered required.  If the parent dictionary is optional,
         then the object should be considered required if the parent
         dictionary is supported.
 Operations on Object:  The definition of how each monitoring
         and control operation acts on the object.  Many operations
         have the same effect on almost all values, so some
         default definitions are presented here.  In the absence
         of an operation specification, implementors should use
         the default operations defined here.
         BEGIN:  The default is for BEGIN to be defined for
             dictionaries, and an error if performed on leaf
             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 the
             stack.
         GET-ATTRIBUTES:  The default is that GET-ATTRIBUTES is
             defined on the contents of all dictionaries specified
             in this memo.  The text description attributes
             are optional for values defined in this memo, but
             are required for implementation-specific objects.
             Any descriptions of object listed in this memo should
             cite this memo.  GET-ATTRIBUTES must be supported on
             all entity-specific values.  GET-ATTRIBUTES
             returns a Attributes object, which is defined in
             the well-known types section below.

Partridge & Trewitt [Page 5] RFC 1024 HEMS Definitions October 1987

         GET-ATTRIBUTES-MATCH:  The default is that
             GET-ATTRIBUTES-MATCH is optionally defined on any
             object which supports GET-MATCH, and is an error
             otherwise.  The rules for attributes returned by
             GET-ATTRIBUTES-MATCH are the same as those for
             GET-ATTRIBUTES.
         GET:  The default definition of GET is to emit the operand
             specified is a leaf object, and if the operand is a
             dictionary, to recursively GET the entire dictionary and
             its subdictionaries.
         GET-MATCH:  Unless otherwise specified, GET-MATCH is not
             supported on an object.
         GET-RANGE:  Unless otherwise specified, GET-RANGE is not
             supported on an object.
         SET:  Unless otherwise specified, SET is not supported on an
             object.
         SET-MATCH:  Unless otherwise specified, SET-MATCH is not
             supported on an object.

ATTRIBUTES

 HEMS requires that remote applications be able to discover the
 meaning of an object by querying the entity in which the object is
 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 object
             (e.g., SEQUENCE, or OCTETSTRING).  This attribute
             is required.
         longDesc:  A potentially lengthy text description which
             fully defines the object.  This attribute is optional
             for objects defined in this memo and required for
             entity-specific objects.
         shortDesc:  A short mnemonic string of less than 15 octets
             which is suitable for labelling the value on a display.
             This attribute is optional.
         unitsDesc:  A short string used for integer values to
             indicate the units in which the value is measured
             (e.g. "ms", "sec", "packets", etc).  This attribute
             is optional.
         precision:  For Counter objects, the value at which the
             Counter will roll-over.  Required for all Counter
             objects.
         properties:  A bitstring of boolean properties of the
             object.  If the bit is on, it has the given property.
             This attribute is optional.  The bits currently
             defined are:
                 0 -- If true, the difference between two values
                     of this object is significant. For example,
                     the changes in a packet count is always
                     significant, it always conveys information.
                     In this case, the 0 bit would be set.  On the
                     other hand, the difference between two readings
                     of a queue length may be meaningless.

IMPLEMENTATION SPECIFIC TYPES

 Each vendor or implementation specific value must be contained within
 an VendorSpecific object.  The format of the VendorSpecific object is
 shown below.
 Type:  VendorSpecific
          VendorSpecific ::= [APPLICATION 3] IMPLICIT SET of ANY

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 TYPES

 There are some generally useful types which are defined across the
 system and are considered well-known.  These types support abstract
 notions that are frequently used in other definitions.
 TYPE: Error
         Error ::= [APPLICATION 0] IMPLICIT SEQUENCE {
             errorCode INTEGER,
             errorOffset INTEGER
             errorDescription IA5String,
         }
 The Error type is returned within reply messages when an error is
 countered.  The errorCode is a number specifying a general class of
 error.  The errorOffset is the octet in the query where the error was
 discovered.  Note that the query starts at the first octet (octet 0)
 of the HEMP data section.  The errorDescription is a text message
 explaining the error.  Note that the definition of this section is
 the same (except for the start of the offset) as that of the HEMP
 protocol error structure and the error codes have been selected to
 keep the code spaces distinct.  This is intended to ease the
 processing of error messages.  The defined errorCodes are:
             100 -- Any error not listed below.
             101 -- System error.  The query processor has failed
                 in some way.
             102 -- Format error.  An error has been detected in
                 the input stream.
             103 -- Stack error.  A stack overflow or underflow has
                 occurred.
             104 -- Instruction error.  The instruction is either
                 unknown, or not supported on the object to which
                 it has been applied.
             105 -- Operand error.  The wrong number of operands or
                 inappropriate operands have been given to an
                 instruction.

Partridge & Trewitt [Page 8] RFC 1024 HEMS Definitions October 1987

 TYPE:  Counter
     Counter ::= [APPLICATION 4] IMPLICIT INTEGER
 The Counter type is an unsigned integer which is defined to roll-over
 to 0 when incremented past a certain value.  (The roll-over point may
 be found by examining the attributes for the particular counter.)
 Counter sizes should be chosen such that the counters will not roll
 over more than once every 24 hours.
 TYPE:  InstructionGroup
     InstructionGroup ::= [APPLICATION 5] IMPLICIT SEQUENCE
         of ANY
 An InstructionGroup is an encapsulated sequence of operands and
 operations.  It allows applications to encode queries as objects.
 TYPE:  Histogram
     Histogram ::= SET of HistEntry
     HistEntry ::= SEQUENCE {
         histValue INTEGER,
         histCount Counter
     }
 A Histogram associates a count, histCount, with a numeric value,
 histValue.  No meaning is placed on the count or value by this
 definition.  Each HistEntry may represent a simple map (e.g.,
 histCount instances of histValue), or a more complex relationship
 (e.g., a count of all values between this histValue and the next
 lowest histValue in the Histogram).  The meaning of the particular
 Histogram is given in the object definition.
 TYPE: TrafficMatrix
     TrafficMatrix ::= SET of TrafficEntry
     TrafficEntry ::= SEQUENCE {
         src IpAddress,
         dst IpAddress,
         count Counter
     }
 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
     IpAddress ::= OCTETSTRING
 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 a
 default address (e.g., for indicating default routes).
 TYPE: Fraction
     Fraction ::= INTEGER
 A Fraction is an integer representation of a fractional value.  It
 contains the numerator of a value as expressed over 256.  (For
 example dividing the Fraction by 256 gives the fractional value.)
 TYPE:  BootClock
     BootClock ::= INTEGER
 The time in milliseconds since the machine was last booted or reset.
 This value is always defined.
 TYPE:  localClock
     LocalClock ::= INTEGER
 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, an
 uninitialized time-of-day chip.)
 TYPE:  NetClock
     NetClock ::= INTEGER
 A network synchronized clock, which is assumed to be synchronized
 across some part of a network.  The clock value is measured in
 milliseconds since 00:00 1 January 1900 UTC.  Specific information
 about the synchronization protocol is found in the system variable
 dictionary.  The value 0 is used to indicate an uninitialized clock.
 TYPE: TimeStamp
     TimeStamp ::= CHOICE {
         [0] BootClock

Partridge & Trewitt [Page 10] RFC 1024 HEMS Definitions October 1987

         [1] localClock
         [2] NetClock
     }
 A TimeStamp, which was taken from the boot clock, system clock or the
 synchronized clock.  In general, a time of day is preferred to the
 time since boot, and a synchronized clock is preferred to an
 unsynchronized clock.  It is more useful to know that an event
 occurred at a particular time, than that it happened so many
 milliseconds after the machine booted.

OBJECT DEFINITIONS

The Root Dictionary

 In HEMS, all data is stored in dictionaries, where a dictionary is
 thought to represent a conceptual grouping of values.  The top-level
 dictionary is the root dictionary.  The form of the root dictionary
 for is shown below.
         RootDictionary ::= [APPLICATION 32] IMPLICIT SET {
             SystemVariables,
             EventControls OPTIONAL,
             Interfaces,
             IpNetworkLayer,
             IpRoutingTable,
             IpTransportLayer,
             IpApplications OPTIONAL
         }

The root dictionary is split into seven general dictionaries:

  1. SystemVariables, which stores general system values such

as the system clock, machine memory and system up/down

         status.
  1. EventControls, which stores all objects necessary to

observe and control the event generating mechanism in

         entities which support events.
  1. interfaces, which contains all information on all

the network interfaces and IP to physical address

         maps (ARP tables, X.25 Standard mappings, etc).
  1. IpNetworkLayer, which contains information about the

workings of the IP layer. This includes information such

         as routing tables, general packet counts, and host-traffic

Partridge & Trewitt [Page 11] RFC 1024 HEMS Definitions October 1987

         matrices.
  1. IpRoutingTable, which contains information on how the

machine routes packets. It proved more useful to segregate

         routing information than to keep it stored with the network
         layer data.
  1. IpTransportLayer, which stores information on the transport

protocols that the entity supports.

  1. IpApplications, which may store information about various

internet applications such as the domain system. This

         section is not required of HEMS entities.
 The next several sections define the values stored in the five
 dictionaries.

The SystemVariables Dictionary

 The SystemVariables dictionary stores objects which are not strictly
 protocol, network, or application specific.  Such objects include
 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 OPTIONAL
     systemID         [9] IMPLICIT IA5STRING,
 }
 OBJECT:  SystemVariables
 Type:  SET
 Definition:  see above
 The objects in the dictionary are defined below.
 OBJECT:  referenceClock

Partridge & Trewitt [Page 12] RFC 1024 HEMS Definitions October 1987

 Type:  TimeStamp
 Definition:  The system clock used for placing timestamps on
     information.  Use of a NetClock is encouraged.
 Operations on Object:  Defaults.
 Notes:  Cross-network clock adjustment is best handled by a proper
         time synchronization protocol, not through the use of SET.
 OBJECT:  netClockInfo
 Type:  SET
 Definition:  Detailed information on the referenceClock if the
     referenceClock is a NetClock.  The format of this
     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.  The
      refClockType is a value indicating the type of reference
      clock consulted for network time  (the values are taken
      directly from the Network Time Protocol specification,
      RFC-958).
 Object Status:  Required if the referenceClock is a NetClock.
 OBJECT: processorLoad
 Type:  Fraction
 Definition:  A value, expressed as a Fraction, which indicates
         the current processing load on the entity.  A value of
         256 (= 1.0) is defined to be running at capacity.  It
         is recognized that this is an imprecise definition since
         capacity can be measured in several ways.  For example,
         a multiprocessor may still have plenty of capacity
         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 the
         master processor and handles all context switching.
         The idea is for remote applications to be able to get some
         sense of the current workload on the entity.  Also note
         that the time scale of the measurement should be small.
         A load measure that averages over the past 10 seconds
         is acceptable but a load measure that averages over the
         past 10 minutes is not.  Implementors should chose some
         mapping between system load and this scale such that 256
         represents a machine under severe strain.  (Note that this
         suggests that values greater than 256 may be returned in
         rare cases.)
 OBJECT:  entityState
 Type:  INTEGER
 Definition: An object which indicates the system state.  There are
       several defined object values.  Some values are read-only and
       can only be read from the object.  Over values are write-only
       and will never be read from the object. Over values are
       write-only and will never be read from the object.The values
       are:
         The read-only values are:
                 (0) -- reserved.
                 (1) -- running.  The entity is up and running.
                 (2) -- testing.  The entity is running some sort of
                     diagnostics which may affect its network
                     operation.
         The write-only values are:
                 (0) -- reserved.
                 (1) -- reset the entity.
                 (2) -- reboot the entity. This value is assumed to
                     cause a more aggressive recycling of the system
                     than reset, though this need not be the case.
                 (3) -- halt the entity.  This value stops the
                     entity.  It assumed to prevent the entity from
                     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 strong
    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 object
           if the current value is matched.
 OBJECT:  kernelMemory
 Type:  OCTETSTRING
 Definition:  A sequence of octets which represents the image of the
      kernel software running on the entity.  This facility is
      provided to allow remote network debugging.
      By kernel software, we mean that software which controls the
      operations and access to the hardware.  In particular, the kernel
      is expected to contain all network software up through the IP
      layer.
      Implementations which use lightweight processes or segmented
      images should consider providing some way to map their internal
      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 system
         dictionary should *not* emit this object.
 OBJECT:  pktBuffers
 Type:  INTEGER
 Definition:  The total number of packet buffers in the entity.
 Object Status:  Required if the entity has a maximum number of
     buffers.  Note that most entities do have a limit (even if it

Partridge & Trewitt [Page 15] RFC 1024 HEMS Definitions October 1987

     is for practical purposes, near infinite) and should return
     that limit.
 OBJECT:  pktOctets
 Type:  INTEGER
 Definition:  The maximum number of octets that can be buffered in the
     entity at any one time.
 Object Status:  Required if the entity has a maximum number of octets
     it can buffer.  Note that most entities do have a limit and
     should return that limit.
 OBJECT:  pktBuffersFree
 Type:  INTEGER
 Definition:  The number of packet buffers currently available.
     Subtracting pktBuffersFree from pktBuffers should give the
     number of buffers in use.
 Object Status:  Required if there is a limit on the number of
     buffers.
 OBJECT: pktOctetsFree
 Type: INTEGER
 Definition:  The number of octets currently available including those
     not used in allocated buffers.  Subtracting this value from
     pktOctets should give the number of octets in use.
     This object can be used to track how well the entity buffers its
     data.
     Object Status:  Required if there is a limit on the number of
     octets that can be buffered.
 OBJECT:  systemID
 Type:  IA5STRING
 Definition:  The text identification of the entity.  This value
     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 on
     the entity.

The EventControls Dictionary

  The EventControls dictionary contains objects to control and
  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: eventControls
  Type: SET
  Definition: See above.
  Object Status:  This object will be required in entities which
      support events, after the event definitions have been
      properly specified.  See discussion of the event formats
      at the end of this memo.
  A description of the fields in this dictionary are given below.
  OBJECT:  lastEvent
  Type:  OCTETSTRING
  Definition:  The last event message sent.
  Object Status: Implementation of this object is encouraged if the
      transport protocol used for events is unreliable (e.g., UDP).
  OBJECT:  eventMessageID
  Type:  Counter

Partridge & Trewitt [Page 17] RFC 1024 HEMS Definitions October 1987

  Definition:  The HEMP MessageId to be used in the next event
      message.  Equals the number of events sent.
  OBJECT:  eventCenters
  Type:  SET of IpAddress
  Definition:  The list of IP addresses to which events are sent.
      This list receives all events.  For more selective event
      monitoring, centers should list themselves under the
      particular events of interest.
  Note:  If the SET operator is defined then use of some form of
      access control is recommended.
  Operations on Object: The defaults except as listed below.
      CREATE:  Adds an address to the list.  The new address may
          not be a broadcast address (it may be a multicast
          address).
      DELETE:  Deletes an address from the list.
      SET-MATCH:  Defined on the IP address.  Replaces the
          address with a new value.
      EMIT-MATCH:  Defined on the IP address.
  OBJECT:  eventList
  Type: SET of eventEntry
  Definition: An array of entries which contain objects which allow
      management centers to control how and when events are sent.
      (The contents of the eventEntry structure are explained below.)

The eventControls Dictionary: eventList/eventEntry

  The eventEntry provides the necessary control objects to manage how
  a particular event is sent.  The format of the eventEntry is shown
  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 IpAddress
          }
  OBJECT:  eventEntry
  Type:  SET
  Definition:  See Above.
  OBJECT:  eventID
  Type:  INTEGER
  Definition:  The particular event ID.
  OBJECT:  eventMode
  Type:  INTEGER
  Definition:  A control object which determines how and whether this
      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 the
              event count reaches the threshold.
  OBJECT:  eventCount
  Type:  Counter
  Definition:  The number of times this event has occurred.
  OBJECT:  threshold
  Type:  Counter

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 this
      value.
  Operations on Object:  The defaults except as noted below.
          SET:  Changes the threshold.
  OBJECT:  thresholdIncr
  Type:  INTEGER
  Definition:  The threshold increment.  Every time a event threshold
      is reached, the threshold value is incremented by this value
      (modulo the precision of the Counter) to find the new
      threshold.
  Operations on Object:  The defaults except as noted below.
          SET:  Changes the increment.
  OBJECT:  eventExecution
  Type:  InstructionGroup
  Definition:  A query to be executed whenever the event is actually
      sent.  Any data retrieved by this query is appended to the
      event message.
  Object Status:  Encouraged.
  Operations on Object:  The defaults except as noted below.
          SET:  Changes the buffer.
  OBJECT:  eventCenters
  Type:  SET
  Definition:  The IP addresses of the monitoring centers which wish
      to listen to this particular event.  Note that events should be
      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 the
              entry with a new value.
          EMIT-MATCH:  Defined on the IP address.

The Interfaces Dictionary

  The Interfaces dictionary a list of per-interface objects.  Since
  one of the fundamental goals of HEMS is to use generic interfaces
  across differing hardwares, all hardware interfaces are described by
  the same data structure, the InterfaceData.
       Interfaces ::= [APPLICATION 35] IMPLICIT SET OF InterfaceData
  OBJECT:  Interfaces
  Type:  SET
  Definition:  see above.

The Interfaces Dictionary: The InterfaceData structure.

  The InterfaceData structure contains all information on a particular
  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 BITSTRING
              multicast        [20] IMPLICIT SET of BITSTRING,
              addressList      [21] IMPLICIT SET OPTIONAL,
          }
  OBJECT:  InterfaceData
  Type:  SET
  Definition:  see above.
  Operations on Object:  The defaults except as noted below.
      SET-MATCH:  This operation is optionally defined on the
          address field of the structure.  Only certain fields
          in this structure may be changed.  The fields which
          may be SET are indicated in the descriptions below.
      GET-MATCH:  Defined to emit information on the interface
          which matches the address given.
  The fields in the structure are defined below.
  OBJECT:  addresses
  Type:  SET of IpAddress
  Definition:  The IP addresses that the interface accepts.  Note that
      additional information on multicast addresses may be found in
      the IgmpValues dictionary.
  OBJECT:  mtu
  Type:  INTEGER
  Definition:  The maximum transmission unit of the device.
  OBJECT:  netMask
  Type:  IpAddress
  Definition:  The subnet mask, which is an address with all the
      network bits set to 1 and all the hosts bits set to 0.  Used to
      identify subnets.

Partridge & Trewitt [Page 22] RFC 1024 HEMS Definitions October 1987

  OBJECT:  pktsIn
  Type:  Counter
  Definition:  The total number of packets received on this interface
      including those in error.
  OBJECT:  pktsOut
  Type:  Counter
  Definition:  The total number of packets that higher levels have
      attempted to send, including those that were not sent.
  OBJECT:  inputPktsDropped
  Type:  Counter
  Definition:  The number of good inbound packets dropped (presumably
      to free up buffer space).
  OBJECT:  outputPktsDropped
  Type:  Counter
  Definition:  The number of good outbound packets dropped (presumably
      to free up buffer space).
  OBJECT:  bcastPktsIn
  Type:  Counter
  Definition:  The number of broadcast packets received including
      those in error.
  Object Status:  Encouraged on interfaces that support broadcast.
  OBJECT:  bcastPktsOut
  Type:  Counter
  Definition:  The number of broadcast packets that higher levels
      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:  mcastPktsIn
  Type:  Counter
  Definition:  The number of multicast packets received including
      those in error.
  Object Status:  Encouraged on interfaces that support multicast.
  OBJECT:  mcastPktsOut
  Type:  Counter
  Definition: The number of multicast packets sent, including those
      that were not sent.
  Object Status:  Encouraged on interfaces that support multicast.
  OBJECT:  inputErrors
  Type:  Counter
  Definition: The number of inbound packets that could not be
      delivered.  The number of inbound packets delivered
      should equal inputPkts less this value and inputPktsDropped.
  OBJECT:  outputErrors
  Type:  Counter
  Definition:  The number of outbound packets that could not be
      transmitted because of errors.  The number of outbound
      packets placed on the network should equal outputPkts
      less this value and outputPktsDropped.
  OBJECT:  outputQLen
  Type:  INTEGER
  Definition:  The length of the output packet queue (in packets).
  OBJECT:  name
  Type:  IA5String

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, the
      product name and the version of the hardware.
  OBJECT:  status
  Type:  INTEGER
  Definition:  The status of the object.  The status values are:
              0 -- reserved
              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:  ifType
  Type:  INTEGER
  Definition: A flag which indicates the type of interface in use.  The
      currently defined types are:
                   0 -- reserved
                   1 -- 1822 HDH
                   2 -- 1822
                   3 -- FDDI
                   4 -- DDN X.25
                   5 -- RFC-877 X.25
                   6 -- StarLan
                   7 -- Proteon 10Mbit
                   8 -- Proteon 80Mbit
                   9 -- Ethernet
                  10 -- 802.3 Ethernet
                  11 -- 802.4 Token Bus
                  12 -- 802.5 Token Ring
                  13 -- Point-to-Point Serial
  OBJECT:  mediaErrors
  Type:  Counter

Partridge & Trewitt [Page 25] RFC 1024 HEMS Definitions October 1987

  Definition:  A counter of media errors, such as collisions on
      Ethernets, token regeneration on token passing rings, or lost
      RFNMs on PSNs.
  Object Status:  Encouraged for interfaces to media which have such
      errors.
  OBJECT:  upTime
  Type:  TimeStamp
  Definition:  When the interface was put in its current state.
  OBJECT:  broadcast
  Type:  BITSTRING
  Definition:  Whether this interface has a physical broadcast
      address.
  Object Status:  Required if the interface has a broadcast adddress.
  OBJECT:  multicast
  Type:  SET of BITSTRING
  Definition: The set of hardware multicast addresses currently
      enabled on the device.
  Object Status:  Encouraged in interfaces which support multicast.
  OBJECT:  addressList
  Definition:  SET of addressMap
       addressMap ::= [0] IMPLICIT SET {
               ipAddr     [0] IMPLICIT IpAddress
               physAddr   [1] IMPLICIT BITSTRING
       }
  Definition:  Most interfaces maintain tables mapping physical
      network address to IP address.  An example is an ARP table.
      This table stores that map as a series of entries which map

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 to
      physical addresses.

The IpNetworkLayer Dictionary

  The IpNetworkLayer dictionary contains all information about the IP
  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 OPTIONAL
          }
  OBJECT:  IpNetworkLayer
  Type:  SET
  Definition:  See above.
  The fields of the dictionary are defined below.
  OBJECT:  gateway
  Type:  BOOLEAN
  Definition: A boolean value which is true if the entity gateways
      packets.

Partridge & Trewitt [Page 27] RFC 1024 HEMS Definitions October 1987

  OBJECT: inputPkts
  Type: Counter
  Definition: The total number of input packets received including
      those in error.
  OBJECT: inputErrors
  Type: Counter
  Definition:  The number of input packets discarded due to errors
      (unknown protocols, format errors, etc).
  OBJECT:  inputPktsDropped
  Type:  Counter
  Definition: The number of input packets dropped for lack of buffer
      space.
  OBJECT:  inputQLen
  Type:  INTEGER
  Definition:  The number of inbound packets currently waiting to be
      processed by the IP layer.
  Object Status:  Encouraged.
  OBJECT:  outputPkts
  Type:  Counter
  Definition:  The total number of outbound packets including both
      those packets presented to the IP layer by higher layers and
      packets which are gatewayed.
  OBJECT:  outputErrors
  Type:  Counter
  Definition:  The number of output packets discarded because of

Partridge & Trewitt [Page 28] RFC 1024 HEMS Definitions October 1987

      errors (unable to route, format errors, etc).
  OBJECT:  outputPktsDropped
  Type: Counter
  Definition:  The number of output packets dropped for lack of
      buffer space.
  OBJECT:  outputQLen
  Type:  INTEGER
  Definition: The number of outbound packets waiting to be processed
      by the IP layer.
  Object Status:  Encouraged.
  OBJECT:  ipID
  Type:  Counter
  Definition:  The next IP packet ID identifier to be used.  Note
      that in some implementations the transport layer may set the
      IP identifier, in which case this value is used if the IP
      identifier has not been set by the transport layer.
  OBJECT:  fragCreated
  Type:  Counter
  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:  fragRcvd
  Type:  Counter
  Definition:  The number of IP fragments received at this entity.
  Object Status:  Encouraged.

Partridge & Trewitt [Page 29] RFC 1024 HEMS Definitions October 1987

  OBJECT:  fragDropped
  Type:  Counter
  Definition:  The number of IP fragments discarded at this entity
      for whatever reason (timed out, errors, etc).
  Object Status:  Encouraged.
  OBJECT:  pktsReassembled
  Type:  Counter
  Definition:  The number of IP datagrams that have been reassembled
      at this entity.
  Object Status:  Encouraged
  OBJECT:  pktsFragmented
  Type:  Counter
  Definition:  The number of IP datagrams that have been fragmented
      at this entity.
  Object Status:  Encouraged.
  OBJECT:  htm
  Type:  TrafficMatrix
  Definition:  A host traffic matrix, mapping all traffic switched any
      pair of sources and destinations.  The count in each trafficEntry
      routeDst is expressed in packets.  Source routed IP packets
      should be logged as being between their source and the
      destination (i.e., they should not be treated as destined for
      this entity).
  Notes:  This information may be considered sensitive.
  Object Status:  Encouraged in gateways.
  OBJECT:  itm

Partridge & Trewitt [Page 30] RFC 1024 HEMS Definitions October 1987

  Type:  TrafficMatrix
  Definition: An interface traffic matrix showing traffic switched
      between interfaces in an entity.  The source and destinations
      fields are the IP addresses of the interfaces between which
      the packet was switched.  The count in each trafficEntry is
      expressed in packets.
  Object Status: Useful.

The IpRoutingTable Dictionary

  The IpRoutingTable dictionary contains all routing information.
  Note that information about any routing protocols used to maintain
  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:  IpRoutingTable
  Type:  SET
  Definition:  See above.
  The objects contained in the dictionary are described below.
  OBJECT:  routingProtocols
  Type:  OCTETSTRING
  Definition: A sparse list of the routing protocols used to update
      the routing table (e.g., EGP and ICMP).  Each octet contains one
      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 -- HELO
                  8 -- RIP
                  9 -- Proprietary IGP
  OBJECT: coreRouter
  Type:  BOOLEAN
  Definition:  This value is set to true if this entity is a reference
      router for any other router (i.e., if it distributes any of its
      routes to other machines).
  OBJECT:  autoSys
  Type:  INTEGER
  Definition:  The autonomous system number of the autonomous system in
      which this entity resides.
  OBJECT:  metricUsed
  Type:  OCTET
  Definition: Classifies the routing metric used in the routing table
      entries.  The value should be chosen from the list of values for
      routingProtocols above, and indicates the metric definition used
      (e.g., this entity uses an EGP metric internally).
  OBJECT:  RoutingEntries
  Type:  SET of RoutingEntry

Partridge & Trewitt [Page 32] RFC 1024 HEMS Definitions October 1987

  Definition:  The set of all routing entries.  The RoutingEntry is
      defined below.

The IpRoutingTable Dictionary: The RoutingEntry

  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 BOOLEAN
          }
  OBJECT:  RoutingEntry
  Type:  SET
  Definition:  See above.
  Operations on Object:  Defaults except as specified below.
      CREATE: Adds a new routing entry.  It should be confirmed
          that the entry is new.
      DELETE: Deletes a routing entry.
      GET-MATCH:  The match operator is defined on the routeDst
          field.  A match on an IpAddress is defined to be a
          search to find the route or routes which would be
          used to reach the IpAddress.  More than one route
          may be applicable, in which case all possible routes
          should be returned.
      SET-MATCH: Is optionally defined on the object.  A SET
          on an entire RoutingEntry replaces the entire entry
          with a new value.  Certain fields (indicated below)
          can also be changed using a SET-MATCH.
          The match operator is defined on the routeDst and
          routeTOS fields.  To SET a value, the match must be
          exact on the IP address (this is different from the

Partridge & Trewitt [Page 33] RFC 1024 HEMS Definitions October 1987

          search definition for GET-MATCH).
          Note that support of the operator on an entity
          which uses a dynamic routing protocol such as
          GGP or EGP will require close coordination with
          the routing protocol to ensure consistent data.
          (Arguably, this facility should not be supported
          on such machines).
  The definitions of the fields in the RoutingEntry are given below.
  OBJECT:  routeMetric
  Type:  INTEGER
  Definition: The routing metric on this route.  Note that the type of
      metric is defined in the metricUsed field of the IpRoutingTable
      dictionary.
  OBJECT: routeDst
  Type: IpAddress
  Definition:  The final destination that can be reached via this
      route.
  OBJECT:  nextHop
  Type:  IpAddress
  Definition:  The next hop to the final destination.
  OBJECT:  routeAuthor
  Type:  IpAddress
  Definition:  The IP address of the entity from which this route was
      *first* received.  That is, the first entity which stated that
      was reached via nextHop.  The default IpAddress should be used
      to indicate routes which originated on the entity.
  Object Status:  Encouraged.
  OBJECT:  routeProto

Partridge & Trewitt [Page 34] RFC 1024 HEMS Definitions October 1987

  Type:  Octet
  Definition:  The routing protocol from which this route was learned.
      The value is taken from the list of values for routingProtocols
      above.
  Object Status:  Encouraged.
  OBJECT: routeTime
  Type:  TimeStamp
  Definition:  When this route was first received.
  Object Status:  Encouraged.
  OBJECT:  routeTOS
  Type:  INTEGER
  Definition:  The IP Type of Service which this routing entry serves.
  Object Status:  Required if type of service routing is supported.
  OBJECT:  valid
  Type:  BOOLEAN
  Definition:  Whether the route is active.  (Some machines retain
      routes which are no longer valid for various reasons.)

The IpTransportLayer Dictionary

  The IpTransportLayer Dictionary contains any information which
  pertains to transport protocols which use the IP protocol as the
  network protocol.  For ease of reference, the ASN.1 tag of each
  transport protocol's dictionary is the same as the assigned IP
  Protocol number.  The definition of the IpTransportLayer
  dictionary is shown below.  Note that dictionaries for many
  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:  IpTransportLayer
  Type:  SET
  Definition:  see above.
  The objects in the dictionary are defined below.

The IpTransportLayer Dictionary: ProtocolsSupported

  OBJECT:  protocolsSupported
  Type:  OCTETSTRING
  Definition: Sparse list of transport protocols supported.  Each
      octet in the OCTETSTRING contains the IP protocol number of a
      supported protocol.  For the purposes of this definition, an
      entity supports a protocol if it both contains software to
      makes it possible for the protocol to be used in
      communications with the entity, AND the entity keeps the
      required values (if any) defined in this memo for that protocol.

The IpTransportLayer Dictionary: IcmpValues

  The IcmpValues dictionary is a subdictionary of the IpTransportLayer
  dictionary which tracks the workings of the Internet Control Message
  Protocol, defined in RFC-792.  The form of the dictionary is shown
  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 OPTIONAL

Partridge & Trewitt [Page 36] RFC 1024 HEMS Definitions October 1987

          }
  OBJECT:  IcmpValues
  Type:  SET
  Definition:  see above.
  The objects in the dictionary are defined below.
  OBJECT:  inputPktCount
  Type:  Counter
  Definition:  The total number of ICMP packets received (including
      those in error).
  OBJECT:  inputPktErrors
  Type:  Counter
  Definition:  The number of ICMP packets received which proved to
      have errors (bad checksums, bad length etc).  Subtracting this
      value from the inputPktCount field should give the number of
      valid ICMP packets received.
  OBJECT:  inputPktDeliver
  Type:  Counter
  Definition:  The number of valid ICMP packets which were
      successfully processed (e.g., delivered to the higher
      protocol).
  OBJECT:  inputPktTypes
  Type:  Histogram
  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 is
      the the (ICMP type * 256) + ICMP code, and the histCount field
      contains the number of valid messages containing this

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 "fragment
      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 histValue
          field.
  OBJECT:  outputPktCount
  Type:  Counter
  Definition:  The total number of ICMP packets that the entity
      attempted to send (including those that failed due to lack of
      buffers, a missing route or other transient transmission
      problems).
  OBJECT:  outputPktErrors
  Type:  Counter
  Definition:  The number of ICMP packets which the entity could not
      send due to transmission problems such as the lack of buffers, a
      missing route or other transient transmission problems.  This
      value is not required to include errors which the ICMP layer
      could not reasonably be expected to detect such as damage to the
      packet in transit.  Subtracting this value from the PktCount
      field should give the number of ICMP packets the entity believes
      it successfully sent.
  OBJECT:  outputPktTypes
  Type:  Histogram
  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 is
      the the (ICMP type * 256) + ICMP code, and the histCount field
      contains the number of valid messages containing this type/code
      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 "fragment
      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 histValue
              field.
  OBJECT:  icmpTraffic
  Type:  TrafficMatrix
  Definition:  All ICMP traffic which has originated on this machine.
      The source address in the traffic matrix should be the interface
      from which the packet was sent.  The destination is the address
      to which the packet is to finally be delivered (not an
      intermediate hop).
  Object Status:  Useful.
  OBJECT:  ipID
  Type:  Counter
  Definition:  The next IP packet ID identifier to be used by the ICMP
      code.
  Object Status:  Required if the ICMP code generates its own IP
      identifiers.

The IpTransportLayer Dictionary: IgmpValues

  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 OPTIONAL

Partridge & Trewitt [Page 39] RFC 1024 HEMS Definitions October 1987

      igmpGroups      [8] IMPLICIT SET of IgmpGroupEntry,
      ipID            [9] IMPLICIT Counter OPTIONAL,
     }
  OBJECT:  IgmpValues
  Type:  SET
  Definition:  The dictionary of information on the Internet Group
      Management Protocol (RFC-988).
  Object Status:  Required in hosts which support IGMP.
  The objects stored in this dictionary are defined below.
  OBJECT:  conformance
  Type:  INTEGER
  Definition:  The level of conformance with RFC-988.  The conformance
      levels are:
             0 -- Level 0.  No support for IP multicasting
             1 -- Level 1.  Support for sending but not receiving
                  multicast datagrams.
             2 -- Level 2.  Full support for IP multicasting.
      These values are taken directly from RFC-988.
  OBJECT:  inputPktCount
  Type:  Counter
  Definition:  The number of IGMP packets received including those
      that proved to be in error.
  OBJECT:  inputPktErrors
  Type:  Counter
  Definition:  The number of IGMP packets received which proved to
      be in error.  This value subtracted from inputPktCount should
      give the number of valid IGMP packets received.

Partridge & Trewitt [Page 40] RFC 1024 HEMS Definitions October 1987

  OBJECT:  inputPktTypes
  Type:  Histogram
  Definition:  A histogram of IGMP messages types and codes sent,
      including those messages that later failed to be transmitted.
      The histogram histValue field contains a 16-bit value which
      is the the (IGMP type * 256) + IGMP code, and the histCount
      field contains the number of valid messages containing this
      type/code pair which have been sent.
      The type and code values are taken from RFC-988.
  OBJECT:  outputPktCount
  Type:  Counter
  Definition:  The total number of IGMP packets that the entity
      attempted to send (including those that failed due to lack
      of buffers, a missing route or other transient transmission
      problems).
  OBJECT:  outputPktErrors
  Type:  Counter
  Definition:  The number of IGMP packets which the entity could not
      send due to transmission problems such as the lack of buffers,
      a missing route or other transient transmission problems.
      This value is not required to include errors which the IGMP
      layer could not reasonably be expected to detect such as damage
      to the packet in transit.  Subtracting this value from the
      outputPktCount field should give the number of IGMP packets
      the entity believes it successfully sent.
  OBJECT:  outputPktTypes
  Type:  Histogram
  Definition:  A histogram of IGMP messages types and codes sent,
      including those messages that later failed to be transmitted.
      The histogram histValue field contains a 16-bit value which is
      the the (IGMP type * 256) + IGMP code, and the histCount field
      contains the number of valid messages containing this type/code
      pair which have been sent.
      The type and code values are taken from RFC-988.

Partridge & Trewitt [Page 41] RFC 1024 HEMS Definitions October 1987

  OBJECT: igmpTraffic
  Type: TrafficMatrix
  Definition:  All IGMP traffic which has originated on this machine.
      The source address in the traffic matrix should be the interface
      from which the packet was sent.  The destination is the address
      to which the packet is to finally be delivered (not an
      intermediate hop).
  Object Status: Useful.
  OBJECT: igmpGroups
  Type: SET
  Definition:  The various igmpGroups of which this host is aware.
      This is stored as a set of IgmpGroupEntry.  The format of an
      IgmpGroupEntry is shown below.
                  IgmpGroupEntry ::= [0] SET {
                      groupAddress      [0] IMPLICIT IpAddress,
                      groupAccessKey    [1] IMPLICIT OCTETSTRING,
                      groupAgent        [2] IMPLICIT BOOLEAN,
                  }
      The groupAddress is the multicast IP address.  The
      groupAccessKey is the 8 octet key -- this key may be
      confidential and should only be available to authorized querying
      entities.  The groupAgent field is true if this entity is an
      agent for the multicast group.
  OBJECT:  ipID
  Type:  Counter
  Definition:  The next IP packet ID identifier to be used by the IGMP
      code.
  Object Status:  Required if the IGMP code generates its own IP
      identifiers.

Partridge & Trewitt [Page 42] RFC 1024 HEMS Definitions October 1987

The IpTransportLayer Dictionary: GgpValues

  The definition of the GgpValues dictionary is left for further
  study.

The IpTransportLayer Dictionary: TcpValues

  The TcpValues dictionary is a subdictionary of the IpTransportLayer
  dictionary which tracks the workings of the Transmission Control
  Protocol, defined in RFC-793.  The definitions of several objects in
  this dictionary refer to definitions in RFC-793.  The form of the
  dictionary is shown below.
          TcpValues ::= SET {
                        [0] IMPLICIT TcpParam
                        [1] IMPLICIT TcpStats OPTIONAL,
            tcpConnData [2] IMPLICIT SET of TcpConn,
          }
  OBJECT:  TcpValues
  Type:  IMPLICIT SET
  Definition:  see above.
  Object Status:  Required if the entity supports TCP.
  The objects in the dictionary are defined in the next few sections.

The IpTransportLayer Dictionary: TcpValues/TcpParam

  The TcpParam dictionary contains information about certain
  parameters such as round-trip timer estimation constants which are
  managed on a per-machine basis.  The form of the dictionary is shown
  below.
          TcpParam ::= SET {
              tcpRtoA       [0] IMPLICIT IA5String,
              tcpRtoParam   [1] IMPLICIT SET of RtoParam,
              ipID          [2] IMPLICIT Counter,
              tcpRtoMin     [3] IMPLICIT INTEGER OPTIONAL,
              tcpRtoMax     [4] IMPLICIT INTEGER OPTIONAL,
              tcpMaxSegSiz  [5] IMPLICIT INTEGER,
              tcpMaxConn    [6] IMPLICIT INTEGER OPTIONAL,
              tcpMaxWindow  [7] IMPLICIT INTEGER OPTIONAL,
          }

Partridge & Trewitt [Page 43] RFC 1024 HEMS Definitions October 1987

  OBJECT:  tcpParam
  Type:  SET
  Definition:  see above.
  The definition of the objects in the tcpParam dictionary are given
  below.
  OBJECT:  tcpRtoA
  Type:  IA5String
  Definition:  The TCP retransmission timeout algorithm used.  The
      algorithm is expressed as one or more equations to generate
      a target value, "RTO[N]", which is the retransmission timeout
      for packet "N".  Expressions should use well understood
      symbols such as * for multiplication and / for division, and
      parentheses to indicate precedence.  Variables should begin
      with an upper case character.  Multiple equations should be
      separated by semi-colons.  Comments should be in braces (i.e.,
      {}).  Constants should begin with a lower case character.  In
      addition to "RTO[N]" the symbol "S[N]" is defined to mean the
      round-trip sample for packet N.  Using this syntax, the
      algorithm in RFC-793 would be expressed as:
              RTO[N] = SRTT[N] * beta ;
              SRTT[N] = ( S[N-1] * alpha) + (SRTT[N-1] * (1 - alpha))
  Note:  The syntax probably needs to be refined so that it can be
     parsed and interpreted by a program.  This is left for future
     study.
  OBJECT:  tcpRtoParam
  Type:  SET of RtoParam
  Definition:  The list of the values of the constants used by the
      retransmission timeout algorithm.  The format of the RtoParam
      structure is shown below.
      RtoParam ::= SEQUENCE {
          name IA5String,
          value Fraction
      }

Partridge & Trewitt [Page 44] RFC 1024 HEMS Definitions October 1987

      The name is the name of the constant as expressed in the
      tcpRtoA (e.g., "beta").
  OBJECT:  ipID
  Type:  Counter
  Definition:  The next IP packet ID identifier to be used by the TCP
      code.
  Object Status:  Required if the TCP code generates its own IP
      identifiers.
  OBJECT:  tcpRtoMin
  Type:  INTEGER
  Definition:  The minimum value the TCP implementation permits for
      the retransmission timeout (RTO), measured in milliseconds.
  Note:  If the SET operation is optionally defined, access control
     must be exercised.
  Object Status:  Required if the implementation uses the suggested
      algorithm in RFC-793 or if the implementation sets any limits
      on the minimum RTO.
  Operations on Object:  The defaults except as listed below:
      SET:  Optionally defined to change the value.  Implementations
         should confirm that the new value is less than tcpRtoMax.
  OBJECT:  tcpRtoMax
  Type:  INTEGER
  Definition:  The maximum value the TCP implementation permits for
      the retransmission timeout (RTO), measured in milliseconds.
  Note:  If the SET operation is optionally defined, access control
     must be exercised.
  Object Status:  Required if the implementation uses the suggested
      algorithm in RFC-793 or if the implementation sets any limits
      on the maximum RTO.
  Operations on Object:  The defaults except as listed below:

Partridge & Trewitt [Page 45] RFC 1024 HEMS Definitions October 1987

  SET:  Optionally defined to change the value.  Implementations
       should confirm that the new value is greater than tcpRtoMax,
       and that the value is large (i.e., several seconds).
  OBJECT:  tcpMaxSegSiz
  Type:  INTEGER
  Definition:  The maximum segment size used by this implementation.
  Object Status:  Required if the entity sets an upper limit on the
      MTU.  (Some implementations have no constraints, but chose an
      MTU from external constraints such as the maximum MTU of the
      network interface in use.)
  OBJECT:  tcpMaxConn
  Type:  INTEGER
  Definition:  An optional value, which must be present if the entity
      has a limit on the total number of TCP connections it can support.
  Object Status:  Required if the entity sets limits.
  Note:  If the SET operation is defined, access control must be
      exercised.
  Operations on Object:  The defaults except as listed below:
      SET:  Optionally defined to change the value.  If the
          new value is less than the number of currently
          open connections, implementations are *not* required
          to close existing connections, but may not open
          any additional ones.
  OBJECT:  tcpMaxWindow
  Type:  INTEGER
  Definition:  An optional value, which must be present if the entity
      places a fixed upper limit on the size of any connection's TCP
      window (i.e., if the maximum window size is not per connection
      configurable).
  Object Status:  Required if the entity sets limits.

Partridge & Trewitt [Page 46] RFC 1024 HEMS Definitions October 1987

  Note:  If the SET operation is defined, access control must be
      exercised.
  Operations on Object:  The defaults except as listed below:
          SET:  Optionally defined to change the value.  The new
              value must be at least the size of one maximum
              TCP segment.

The IpTransportLayer Dictionary: TcpValues/TcpStats

  The TcpStats dictionary stores general information about the
  workings of the TCP layer.  The form of the dictionary is shown
  below.
          TcpStats ::= SET {
               connAttempts     [0] IMPLICIT Counter OPTIONAL,
               connOpened       [1] IMPLICIT Counter OPTIONAL,
               connAccepted     [2] IMPLICIT Counter OPTIONAL,
               connClosed       [3] IMPLICIT Counter OPTIONAL,
               connAborted      [4] IMPLICIT Counter OPTIONAL,
               connAbortedInfo  [5] IMPLICIT Histogram OPTIONAL,
               octetsIn         [6] IMPLICIT Counter OPTIONAL,
               octetsOut        [7] IMPLICIT Counter OPTIONAL,
               octetsInDup      [8] IMPLICIT Counter OPTIONAL,
               octetsRetrans    [9] IMPLICIT Counter OPTIONAL,
               inputPkts       [10] IMPLICIT Counter OPTIONAL,
               retransPkts     [11] IMPLICIT Counter OPTIONAL,
               outputPkts      [12] IMPLICIT Counter OPTIONAL,
               dupPkts         [13] IMPLICIT Counter OPTIONAL,
          }
  OBJECT:  TcpStats
  Type:  SET
  Definition:  See above.
  Object Status:  Encouraged.
  The definition of the fields in the dictionary are given below.
  OBJECT:  connAttempts
  Type:  Counter

Partridge & Trewitt [Page 47] RFC 1024 HEMS Definitions October 1987

  Definition:  The number of connection attempts that have been made
      from this host.  This includes pending attempts.
  Object Status:  Encouraged.
  OBJECT:  connOpened
  Type:  Counter
  Definition:  The number of connection attempts from this host which
      successfully generated an open connection.  This includes
      currently open connections.
  Object Status:  Encouraged.
  OBJECT:  connAccepted
  Type:  Counter
  Definition:  The number of connections accepted by listening peers
      on this entity.  This includes currently open connections.
  Object Status:  Encouraged.
  OBJECT:  connClosed
  Type:  Counter
  Definition:  The number of connections which were properly closed.
  Object Status:  Encouraged.
  OBJECT:  connAborted
  Type:  Counter
  Definition:  The number of connections which were aborted.  Note
      that if implementations trace how the connection was aborted,
      they are encouraged to use the connAbortedInfo histogram.
  Object Status:  Encouraged.
  OBJECT:  connAbortedInfo

Partridge & Trewitt [Page 48] RFC 1024 HEMS Definitions October 1987

  Type:  Histogram
  Definition:  The number of connections which were aborted by type of
      abort.  The histValue is one of the codes listed below.  The
      histCount is the number of connections aborted for this reason.
      The histValues codes are:
                  0 -- an abort condition not specified below
                  1 -- remote abort
                  2 -- local application abort
                  3 -- local protocol level abort
  Object Status:  Useful
  OBJECT:  octetsIn
  Type:  Counter
  Definition:  The total number of TCP octets (not including
      duplicates) received at this entity.
  Object Status:  Required if TcpStats is implemented.
  OBJECT:  octetsOut
  Type:  Counter
  Definition:  The total number of TCP octets (not including
      retransmissions) sent from this entity.
  Object Status:  Required if TcpStats is implemented.
  OBJECT:  octetsInDup
  Type:  Counter
  Definition:  The total number of TCP octets received which were
      duplicates.
  Object Status:  Required if TcpStats is implemented.
  OBJECT:  octetsReTrans
  Type:  Counter

Partridge & Trewitt [Page 49] RFC 1024 HEMS Definitions October 1987

  Definition:  The total number of TCP octets which have been
      retransmitted.
  Object Status:  Required if TcpStats is implemented.
  OBJECT:  inputPkts
  Type:  Counter
  Definition:  The total number of valid packets received, including
      those on current connections.
  Object Status:  Useful.
  OBJECT:  retransPkts
  Type:  Counter
  Definition:  The total number of packets retransmitted.
  Object Status:  Useful.
  OBJECT:  outputPkts
  Type:  Counter
  Definition:  The total number of packets sent.
  Object Status:  Useful.
  OBJECT:  dupPkts
  Type:  Counter
  Definition:  The number of packets received which contained only
      data already received.
  Object Status:  Useful.

Partridge & Trewitt [Page 50] RFC 1024 HEMS Definitions October 1987

The IpTransportLayer Dictionary: TcpValues/TcpConn

  The tcpConnData field in the TcpValues dictionary is a set of
  TcpConn, where each TcpConn contains information on a particular TCP
  connection.  The definition of TcpConn is shown below.
              TcpConn ::= SET {
                  localPort       [0] IMPLICIT INTEGER,
                  localAddress    [1] IMPLICIT IpAddress,
                  foreignPort     [2] IMPLICIT INTEGER,
                  foreignAddress  [3] IMPLICIT IpAddress,
                  state           [4] IMPLICIT INTEGER,
                  snduna          [5] IMPLICIT INTEGER,
                  sndnxt          [6] IMPLICIT INTEGER,
                  sndwnd          [7] IMPLICIT INTEGER,
                  congwnd         [8] IMPLICIT INTEGER,
                  rcvnxt          [9] IMPLICIT INTEGER,
                  rcvwnd         [10] IMPLICIT INTEGER,
                  srtt           [11] IMPLICIT INTEGER OPTIONAL,
                  lastrtt        [12] IMPLICIT INTEGER OPTIONAL,
                  maxSegSize     [13] IMPLICIT INTEGER,
                  octetsSent     [14] IMPLICIT Counter OPTIONAL,
                  octetsRXmit    [15] IMPLICIT Counter OPTIONAL,
                  octetsRcvd     [16] IMPLICIT Counter OPTIONAL,
                  octetDups      [17] IMPLICIT Counter OPTIONAL,
                  octetPastWin   [18] IMPLICIT Counter OPTIONAL,
                  segSizes       [19] IMPLICIT Histogram OPTIONAL,
          }
  The set of TCP connections can be searched in a number of ways based
  on the local and foreign addresses (including the port number).
  Individual values of a connection cannot be retrieved without a
  search.
  OBJECT:  TcpConn
  Type:  SET
  Definition:  The per TCP connection data.
  Operations on Object:  The defaults except as listed below:
        GET-MATCH:  Defined on any combination of values of
            localAddress,  localPort, foreignAddress and
            foreignPort.  Returns all connections which match
            the template.  (For example, GET-MATCH on a
            particular foreignAddress returns all connections
            to that address.)

Partridge & Trewitt [Page 51] RFC 1024 HEMS Definitions October 1987

  The definitions of the fields of the tcpConn structure are given
  below.
  OBJECT:  localPort
  Type:  INTEGER
  Definition:  The local port number of this connection.
  Operations on Object: Defaults.  Note that MATCH operators may be
      applied to this object to locate information on a particular TCP
      connection.
  OBJECT:  localAddress
  Type:  IpAddress
  Definition:  The local IP address of this connection.  May be the
      default IP address defined above.  This value may not be valid
      in certain states.
  Operations on Object:  Defaults.  Note that MATCH operators may be
      applied to this object to locate information on a particular
      TCP connection.
  OBJECT:  foreignPort
  Type:  INTEGER
  Definition:  The foreign port number of this connection.  This value
      may be meaningless if the local peer is in certain states (e.g.,
      LISTEN).
  Operations on Object:  Defaults.  Note that MATCH operators may be
     applied to this object to locate information on a particular TCP
     connection.
  OBJECT:  foreignAddress
  Type:  IpAddress
  Definition:  The foreign IP address of this connection.  This value
      may be meaningless if the local peer is in certain states (e.g.,
      LISTEN).
  Operations on Object: Defaults.  Note that MATCH operators may be

Partridge & Trewitt [Page 52] RFC 1024 HEMS Definitions October 1987

      applied to this object to locate information on a particular
      TCP connection.
  OBJECT:  state
  Type:  INTEGER
  Definition:  The current state of the local peer.  The values
      corresponding to the different states are: close(0), listen(1),
      syn-sent(2), syn-received(3), established(4), close-wait(5),
      fin-wait-1(6), closing(7), last-ack(8), fin-wait-2(9),
      time-wait(10).  Implementations must map internal
      representations of the state into these values.
  OBJECT:  snduna
  Type:  INTEGER
  Definition:  The SND.UNA value as defined in RFC-793.
  OBJECT:  sndnxt
  Type:  INTEGER
  Definition:  The SND.NXT value as defined in RFC-793.
  OBJECT:  sndwnd
  Type:  INTEGER
  Definition:  The SND.WND value as defined in RFC-793.
  OBJECT:  congwnd
  Type:  INTEGER
  Definition:  The congestion window.  This value is less than or
      equal to sndwnd.  If less than sndwnd, then congestion
      control is in effect and congwnd is the reduced send window
      size in use.
  OBJECT:  rcvnxt
  Type:  INTEGER

Partridge & Trewitt [Page 53] RFC 1024 HEMS Definitions October 1987

  Definition:  The RCV.NXT value as defined in RFC-793.
  OBJECT:  rcvwnd
  Type:  INTEGER
  Definition:  The RCV.WND value as defined in RFC-793.
  OBJECT:  srtt
  Type:  INTEGER
  Definition:  The smoothed round-trip time in milliseconds.
  Object Status:  Required if the implementation maintains a smoothed
      round-trip time.
  OBJECT:  lastrtt
  Type:  INTEGER
  Definition:  The last round-trip time sample taken in milliseconds.
  Object Status:  Encouraged.
  OBJECT:  maxSegSize
  Type:  INTEGER
  Definition:  The maximum segment size that can be used on this
      connection.
  OBJECT:  octetsSent
  Type:  Counter
  Definition:  The total number of octets transmitted since the
      connection was opened, not including retransmissions.  Can
      alternatively be thought of as the current length of the
      stream.
  Object Status:  Encouraged.

Partridge & Trewitt [Page 54] RFC 1024 HEMS Definitions October 1987

  OBJECT:  octetsRXmit
  Type:  Counter
  Definition:  The total number of octets retransmitted since the
      connection was opened.  This plus octetsSent should give the
      total number of octets sent.
  Object Status:  Encouraged.
  OBJECT:  octetsRcvd
  Type:  Counter
  Definition:  The number of octets received since the connection was
      opened, not including duplicates received.  The receiver's
      version of octetsSent.
  Object Status:  Encouraged.
  OBJECT:  octetDups
  Type:  Counter
  Definition:  The total number of octets received since the
      connection was opened which were redundant (i.e., they had been
      previously received).
  Object Status:  Encouraged.
  OBJECT:  octetPastWin
  Type:  Counter
  Definition:  The number of segments which contained data beyond
      the upper edge of the receive window.
  Object Status:  Encouraged
  OBJECT:  segSizes
  Type:  Histogram
  Definition:  A histogram of the sizes of the packets sent on the

Partridge & Trewitt [Page 55] RFC 1024 HEMS Definitions October 1987

      connection (useful for catching cases of silly-window syndrome).
      This histogram is an range histogram, measuring the number of
      segments whose size fell into a give range.  The histogram
      histValue field contains a segment size, and the histCount
      field contains the number of segments between this size and
      the next largest size.
  Object Status:  Useful.

The IpTransportLayer Dictionary: EgpValues

  The EgpValues dictionary stores information about the workings of
  the Exterior Gateway Protocol, defined in RFC-904.  The format of
  the dictionary is shown below.
          EgpValues ::= SET {
              egpState  [0] IMPLICIT INTEGER,
                        [1] IMPLICIT EgpParam,
                        [2] IMPLICIT EgpStats OPTIONAL,
            egpPeerData [3] IMPLICIT SET of EgpPeer
          }
  OBJECT:  EgpValues
  Type:  SET
  Definition:  See above.
  Object Status:  Required in entities which support EGP.
  The definitions of the subdictionaries of this dictionary are given
  below.
  OBJECT:  egpState
  Type:  INTEGER
  Definition:  The state of the EGP system.  The state values are:
                      0 -- Idle
                      1 -- Acquisition
                      2 -- Down
                      3 -- Up
                      4 -- Cease
  These values are taken directly from RFC-904.

Partridge & Trewitt [Page 56] RFC 1024 HEMS Definitions October 1987

The IpTransportLayer Dictionary: EgpValues/EgpParam

  The EgpParam dictionary stores the various EGP parameters.  The
  format of the dictionary is shown below.
          EgpParam ::= SET {
              p1    [0] IMPLICIT INTEGER,
              p2    [1] IMPLICIT INTEGER,
              p3    [2] IMPLICIT INTEGER,
              p4    [3] IMPLICIT INTEGER,
              p5    [4] IMPLICIT INTEGER,
              ipID  [5] IMPLICIT Counter OPTIONAL
          }
  OBJECT:  EgpParam
  Type:  SET
  Definition:  See above.
  The definition of the fields of the dictionary are given below.  All
  the definitions are taken from RFC-904.
  OBJECT:  p1
  Type:  INTEGER
  Definition:  Minimum interval acceptable between successive Hello
      commands received.
  Operations on Object:  The defaults except as noted below.
      SET:  The set command is optionally defined on this object.
  OBJECT:  p2
  Type:  INTEGER
  Definition:  Minimum interval acceptable between successive Poll
      commands received.
  Operations on Object:  The defaults except as noted below.
      SET:  The set command is optionally defined on this object.
  OBJECT:  p3

Partridge & Trewitt [Page 57] RFC 1024 HEMS Definitions October 1987

  Type:  INTEGER
  Definition:  Interval between Request or Cease command
      retransmissions.
  Operations on Object:  The defaults except as noted below.
      SET:  The set command is optionally defined on this object.
  OBJECT:  p4
  Type:  INTEGER
  Definition:  Interval during which state variables are maintained in
      the absence of commands or response in the Down and Up states.
  Operations on Object:  The defaults except as noted below.
  SET:  The set command is optionally defined on this object.
  OBJECT:  p5
  Type:  INTEGER
  Definition:  Interval during which state variables are maintained in
      the absence of commands or response in the Acquisition and Cease
      states.
  Operations on Object:  The defaults except as noted below.
      SET:  The set command is optionally defined on this object.
  OBJECT: ipID
  Type: Counter
  Definition:  The next IP packet ID identifier to be used by the EGP
      code.
  Object Status: Required if the EGP code generates its own IP
      identifiers.

The IpTransportLayer Dictionary: EgpValues/EgpStats

Partridge & Trewitt [Page 58] RFC 1024 HEMS Definitions October 1987

  The EgpStats dictionary keeps statistics about the use of EGP on
  this entity.  The form of the dictionary is shown below.
          EgpStats ::= SET {
              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,
              egpTraffic      [7] IMPLICIT TrafficMatrix OPTIONAL
          }
  OBJECT:  EgpStats
  Type:  SET
  Definition:  See above.
  The definitions of the objects in this dictionary are given below.
  OBJECT:  inputPktCount
  Type: Counter
  Definition:  The number of EGP packets received including those that
      proved to be in error.
  OBJECT:  inputPktErrors
  Type:  Counter
  Definition:  The number of EGP packets received which proved to be
      in error.  This value subtracted from inputPktCount should give
      the number of valid EGP packets received.
  OBJECT:  inputPktTypes
  Type:  Histogram
  Definition:  A histogram of types of valid EGP messages received.
      The histogram histValue field contains the message type number,
      and the histCount field contains the number of messages of

Partridge & Trewitt [Page 59] RFC 1024 HEMS Definitions October 1987

      this type which have been received.
  Object Status:  Useful.
  OBJECT:  outputPktCount
  Type:  Counter
  Definition:  The total number of EGP packets that the entity
      attempted to send (including those that failed due to lack of
      buffers, a missing route or other transient transmission
      problems).
  OBJECT:  outputPktErrors
  Type:  Counter
  Definition:  The number of EGP packets which the entity could not
      send due to transmission problems such as the lack of buffers,
      a missing route or other transient transmission problems.
      This value is not required to include errors which the EGP
      layer could not reasonably be expected to detect such as
      damage to the packet in transit.  Subtracting this value from
      the outputPktCount field should give the number of EGP packets
      the entity believes it successfully sent.
  OBJECT:  outputPktTypes
  Type:  Histogram
  Definition:  A histogram of EGP messages types sent, including those
      that later failed to be transmitted.  The histogram histValue
      field contains the message type number, and the histCount field
      contains the number of messages of this type which have been sent.
  Object Status:  Useful.
  OBJECT:  egpTraffic
  Type:  TrafficMatrix
  Definition:  All EGP traffic which has originated on this machine.
      The source address in the traffic matrix should be the interface
      from which the packet was sent.  The destination is the address

Partridge & Trewitt [Page 60] RFC 1024 HEMS Definitions October 1987

      to which the packet is to finally be delivered (not an
      intermediate hop).
  Object Status:  Useful.

The IpTransportLayer Dictionary: EgpValues/EgpPeer

  The egpPeerData field of the EgpValues dictionary is a set of
  EgpPeer structures which contain the state variables for a
  particular EGP neighbor.  The form of the EgpPeer structure is shown
  below.
          EgpPeer ::= SET {
              r       [0] IMPLICIT Counter,
              s       [1] IMPLICIT Counter,
              t1      [2] IMPLICIT INTEGER,
              t2      [3] IMPLICIT INTEGER,
              t3      [4] IMPLICIT INTEGER,
              m       [5] IMPLICIT BOOLEAN,
              timer1  [6] IMPLICIT INTEGER,
              timer2  [7] IMPLICIT INTEGER,
              timer3  [8] IMPLICIT INTEGER,
              addr    [9] IMPLICIT IpAddress
          }
  OBJECT:  EgpPeer
  Type:  SET
  Definition:  The state information for a given EGP neighbor.
  The definition of each field is given below.
  OBJECT:  r
  Type:  Counter
  Definition:  The receive sequence number as defined in RFC-904.
  OBJECT:  s
  Type:  Counter
  Definition:  The send sequence number as defined in RFC-904.

Partridge & Trewitt [Page 61] RFC 1024 HEMS Definitions October 1987

  OBJECT:  t1
  Type:  INTEGER
  Definition:  The interval between Hello command retransmissions as
      defined in RFC-904.
  OBJECT:  t2
  Type:  INTEGER
  Definition:  The interval between Poll command retransmissions as
      defined in RFC-904.
  OBJECT:  t3
  Type:  INTEGER
  Definition:  The interval during which neighbor-reachability
      indications are counted, as defined in RFC-904.
  OBJECT:  m
  Type:  BOOLEAN
  Definition:  The Hello Polling mode.  True if in active mode, false
      if in passive mode.
  Operations on Object:  The defaults except as noted below.
      SET:  Optionally defined to change the Hello Polling mode.
  OBJECT:  timer1
  Type:  INTEGER
  Definition:  The value of timer 1 as defined in RFC-904.
  OBJECT:  timer2
  Type:  INTEGER
  Definition:  The value of timer 2 as defined in RFC-904.
  OBJECT:  timer3

Partridge & Trewitt [Page 62] RFC 1024 HEMS Definitions October 1987

  Type:  INTEGER
  Definition:  The value of timer 3 as defined in RFC-904.
  OBJECT:  addr
  Type:  IpAddress
  Definition:  The IP address of the neighbor.

The IpTransportLayer Dictionary: UdpValues

  The UdpValues dictionary stores all information on the User Datagram
  Protocol, defined in RFC-768.  The format of the dictionary is shown
  below.
          UdpValues ::= [17] IMPLICIT SET OPTIONAL {
              ipID        [0] IMPLICIT Counter OPTIONAL,
                          [1] IMPLICIT UdpStats,
              udpPortData [2] IMPLICIT SET of udpPort
          }
  OBJECT:  UdpValues
  Type:  SET
  Definition:  See above.
  Object Status:  Implementation of this dictionary is required if
      the entity supports UDP.
  The fields of this dictionary are given below.
  OBJECT:  ipID
  Type:  Counter
  Definition:  The next IP packet ID identifier to be used by the UDP
      code.
  Object Status:  Required if the UDP code generates its own IP
      identifiers.

The IpTransportLayer Dictionary: UdpValues/UdpStats

  The UdpStats dictionary stores general information about the

Partridge & Trewitt [Page 63] RFC 1024 HEMS Definitions October 1987

  behavior of the UDP protocol on the entity.  The format of the
  dictionary is shown below.
          UdpStats ::= SET {
              inputPkts       [0] IMPLICIT Counter,
              inputPktErrors  [1] IMPLICIT Counter,
              outputPkts      [2] IMPLICIT Counter,
          }
  OBJECT:  UdpStats
  Type:  SET
  Definition:  See above.
  Object Status:  Encouraged.
  The fields in this dictionary are defined below.
  OBJECT:  inputPkts
  Type:  Counter
  Definition:  The total number of UDP packets received at this entity
      including any errors.
  Object Status:  Required if the UdpStats dictionary is implemented.
  OBJECT:  inputPktsErrors
  Type:  Counter
  Definition:  The number of UDP packets which could not be delivered
      because of format errors, data corruption or because there was no
      application at the destination port.
  Object Status:  Required if the UdpStats dictionary is implemented.
  OBJECT:  outputPkts
  Type:  Counter
  Definition:  The total number of UDP segments sent from this entity.
  Object Status:  Required if the UdpStats dictionary is implemented.

Partridge & Trewitt [Page 64] RFC 1024 HEMS Definitions October 1987

The IpTransportLayer Dictionary: UdpValues/udpPortData

  The udpPortData structure stores information about individual UDP
  applications.  The udpPortData is represented as a set of records,
  udpPorts, which track the behavior of individual ports.  The format
  of both structures are shown below.
          udpPortData    [1] IMPLICIT SET of UdpPort
          UdpPort ::=  [0] IMPLICIT SET {
              localAddress     [0] IMPLICIT IpAddress,
              localPort        [1] IMPLICIT INTEGER,
              foreignAddress   [2] IMPLICIT IpAddress OPTIONAL,
              foreignPort      [3] IMPLICIT INTEGER OPTIONAL,
              maxPktSize       [4] IMPLICIT INTEGER,
              pktsRcvd         [5] IMPLICIT Counter,
              octetRcvd        [6] IMPLICIT Counter OPTIONAL,
              pktsSent         [7] IMPLICIT Counter,
              octetSent        [8] IMPLICIT Counter OPTIONAL,
          }
  OBJECT:  udpPortData
  Type:  SET of udpPort
  Definition:  See above.
  OBJECT:  UdpPort
  Type:  SET
  Definition:  See above.
  Operations on Object: The defaults except as noted below.
      GET-MATCH.  Defined on any combination of the values of
          localAddress, localPort, foreignAddress and foreignPort.
          Returns all ports which match the template.
  The meaning of the individual fields of the udpPort record are given
  below.
  OBJECT:  localAddress
  Type:  IpAddress

Partridge & Trewitt [Page 65] RFC 1024 HEMS Definitions October 1987

  Definition:  The local IP address of the port.  May be the default
      IP address if records are accepted from any interface.
  OBJECT:  localPort
  Type:  INTEGER
  Definition:  The local port number.
  OBJECT:  foreignAddress
  Type:  IpAddress
  Definition:  Some UDP implementations permit applications to specify
      the remote address from which packets will be accepted.  In such
      implementations, this field may be used to return the remote IP
      address.  If this value is set to the default IP address, then
      packets from any host are accepted.  The default IP address
      indicates that the application has not specified the remote
      address (but could if it chose).
  Object Status:  Required in entities which permit applications to
      specify the remote address.
  OBJECT:  foreignPort
  Type:  INTEGER
  Definition:  Some UDP implementations permit applications to specify
      the remote address from which packets will be accepted.  In such
      implementations, this field may be used to return the remote
      port.  If this value is set to 0, packets from any remote port
      are accepted.
  Object Status:  Required in entities which permit applications to
      specify the remote port.
  OBJECT:  maxPktSize
  Type:  INTEGER
  Definition:  The maximum UDP packet size, if any, supported by this
      host.
  Object Status:  Required if there is a limit on the UDP packet size.

Partridge & Trewitt [Page 66] RFC 1024 HEMS Definitions October 1987

  OBJECT:  pktsRcvd
  Type:  Counter
  Definition:  The total number of packets received on this port during
      the lifetime of this application (i.e., application which opened
      this port).
  OBJECT:  octetsRcvd
  Type:  Counter
  Definition:  The total number of octets received at this port.
  OBJECT:  pktsSent
  Type:  Counter
  Definition:  The total number of packets sent on this port during the
      lifetime of this application (i.e., the application which opened
      this port).
  OBJECT:  octetsSent
  Type:  Counter
  Definition:  The total number of octets sent on this port during the
      lifetime of this application (i.e., the application which opened
      this port).

The IpTransportLayer Dictionary: HmpValues

   The HmpValues dictionary stores all information on the Host
   Monitoring Protocol, defined in RFC-869.  Since HEMS is designed to
   replace HMP, the definition of this dictionary has been deferred
   until a clear need for it is demonstrated.

The IpTransportLayer Dictionary: RdpValues

   The RdpValues dictionary stores all information on the Reliable
   Data Protocol (RDP).  Since RDP is currently being tested and
   revised, the definition of this dictionary is left for further
   study.

Partridge & Trewitt [Page 67] RFC 1024 HEMS Definitions October 1987

The IpTransportLayer Dictionary: NetbltValues

   The NetbltValues dictionary stores all information on the Network
   Block Transfer protocol.  Since Netblt is currently being tested
   and revised, the definition of this dictionary is left for further
   study.

The IpApplications Dictionary

   The IpApplications dictionary stores information about networking
   applications whose operations may affect the proper operation of
   the network.  Examples of such applications might be domain
   nameservers or distributed routing agents (such as gated or
   routed).  The definition of this dictionary is left for further
   study.

NOTES ON RETRIEVAL OF OBJECTS

   It is assumed in this system that the query processor is only one
   of many concurrently running processes on an entity, and that the
   operations of the other processes may affect the values of the
   objects managed by the query processor.  To permit this
   concurrency, the query processor is not required to keep the values
   frozen during the execution of a query.  As a result, related
   values may change during the course of the query's execution.
   Applications should be prepared for this possibility.
   In several places, specific mathematical relations between objects
   have been specified, for example, that object X minus object Y
   should yield some well-defined value.  Note that in many cases,
   objects X and Y are roll-over counters, in which case these
   relations are only valid modulo the precision of the counter.  This
   is acceptable.  The relationships are only intended to clarify the
   association between objects.

EVENTS

   In the remainder of this memo we present the format and definition
   of event messages which are unsolicited updates sent from entities
   to management centers.
   This section needs much further work.  The authors provide this
   section to illustrate how the trap mechanism works.  However, much
   more research must be done into the questions of what events need
   to be reported, and what information they must carry with them

Partridge & Trewitt [Page 68] RFC 1024 HEMS Definitions October 1987

   before this section can be completed.  The authors welcome any
   advice from the community on this subject.

Format of Event Messages

   Event messages have the same format as replies; they are a sequence
   of objects.  The only difference between a event message and a
   regular reply to a query is that the event message is labelled as a
   event in the HEMP message header and the first object in the event
   message is a special event leader describing the event.  All
   objects after the event message are standard objects stored by the
   entity which might be useful to a monitoring center in
   understanding the machine state which caused the event.  Each event
   has a certain number of objects that it must return.  Additional
   objects may be returned by loading instructions into the
   eventExecution buffer of the relevant eventEntry.
   The format of the event leader is shown below:
           EventLeader ::= [APPLICATION 1024] IMPLICIT SEQUENCE {
               eventCode INTEGER,
               eventIndex INTEGER,
               eventThreshold INTEGER,
               eventTime TimeStamp,
               eventDescr IA5STRING
           }
   The eventCode is a number which indicates the type of event.  The
   eventCodes are defined below.
   The eventIndex is an implementation specific value.  It is
   considered good practice to make sure that a particular event is
   only generated in one place.  It may be the case that certain HEMS
   generic events (for example, "no buffer space") may be generated by
   more than one place in an entity's code.  To allow implementors and
   network managers to determine where the event is actually being
   generated, implementors should make sure that a distinct eventIndex
   is assigned to each location in the code that generates a
   particular event.
   The eventThreshold is the value of the event threshold when the
   event was sent.
   The eventTime indicates when the trap was generated.
   The eventDescr is a text string which describes the event.  This

Partridge & Trewitt [Page 69] RFC 1024 HEMS Definitions October 1987

   description should explain the general problem (e.g., "no buffer
   space") and may also, optionally, include additional information
   about why this particular event was generated (e.g., "could not
   send ICMP redirect").

Event Definitions

   The remainder of this memo presents a few generic events, which are
   presented for illustration only.  Implementors interested in
   supporting events should contact the authors to help work out a
   more comprehensive set of definitions.
   The format of the event definitions is:
   EVENT CODE:  The event code number.
   Definition:  Defines the event.
       Related Objects: The list of related objects which *must* be
       returned following the event header.  All objects should be
       returned as fully qualified objects (with ASN.1 codes tracing
       a complete path from the root object dictionary).  If no
       objects are specified, then no related objects are required.
   Event Status:  Events are either required of all conforming
           implementations, required if the entity supports a
           particular feature (e.g., TCP events) or optional.
   Notes: Any additional notes about the event.

List of Events

       The next few event codes are for system (as opposed to more
       network oriented) events.
       EVENT CODE:  0
       Definition:  Unused
       EVENT CODE:  1
       Definition:  The entity has rebooted.
       Related Objects:   An INTEGER which is the highest HEMP

Partridge & Trewitt [Page 70] RFC 1024 HEMS Definitions October 1987

           messageID reached by the trap system before the system
           crashed.
       EVENT CODE:  2
       Definition:  The entity is about to go into test mode.
       EVENT CODE:  3
       Definition:  The entity is about to reset.
       EVENT CODE:  4
       Definition:  The entity is about to reboot.
       EVENT CODE:  5
       Definition:  The entity is about to halt.
       EVENT CODE:  6
       Definition:  The system is close to depleting its packet buffer
           space.
       Event Status:  optional
       EVENT CODE:  7
       Definition:  The system has depleted its packet buffer space.
       EVENT CODE:  8
       Definition:  The system has depleted a non-packet buffer space.
       Note:  The two trap codes above do not deal neatly with
           systems which have multiple buffer pools, each of which
           may be depleted separately, with very different effects
           on the entity.
       The next set of event codes apply to events related to network
       interfaces.

Partridge & Trewitt [Page 71] RFC 1024 HEMS Definitions October 1987

       EVENT CODE:  1024
       Definition:  The given interface has just come up.
       Related Objects:  The InterfaceData structure for the
           interface.
       EVENT CODE:  1025
       Definition:  The given interface has just been taken down.
       Related Objects:  The InterfaceData structure for the
           interface.
       EVENT CODE:  1026
       Definition:  The given interface has just gone into test mode.
       Related Objects:  The InterfaceData structure for the
           interface.
       The next set of event codes are used to report IP-level errors.
       EVENT CODE:  2048
       Definition:  Unable to route IP packet.
       EVENT CODE:  2049
       Definition:  Bad IP checksum.
       EVENT CODE:  2050
       Definition:  An IP packet with a bad header was received (for
           example, with a broadcast or multicast IP address as the
           source, or the wrong IP version number, or a header length
           which is too short).
       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2051
       Definition:  Packet for unsupported IP transport protocol.

Partridge & Trewitt [Page 72] RFC 1024 HEMS Definitions October 1987

       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2052
       Definition:  A stunted IP packet was received (smaller than
           the IP length says it should be).
       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2053
       Definition:  An oversize IP packet was received (larger than
           the IP length says it should be).
       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2054
       Definition:  A good IP packet was discarded (usually to free
           up buffer space).
       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2055
       Definition:  An IP packet's time-to-live as expired.
       Related Objects:  Should return the IP header of the packet.
           Note that an IP header type has not yet been defined.
       EVENT CODE:  2056
       Definition:  This IP fragment has timed out.
       Related Objects:  Should return the header of the fragment.
           Note that an IP header type has not yet been defined.

Partridge & Trewitt [Page 73] RFC 1024 HEMS Definitions October 1987

AREAS FOR FURTHER STUDY

   There are several parts of this document that could use additional
   study.  Comments from readers are welcome.
   The whole event system needs thorough examination.  It is not clear
   that the event control mechanism strikes the proper balance between
   sufficient flexibility to allow monitoring centers to customize
   their event stream, and keeping the basic mechanism simple.
   Further, the problem of defining generic events for all entities is
   an immense task.  Finally, the system of appending required values
   after traps, followed by optional values read from the data tree
   feels a bit cumbersome.  It would be nice if all values were in the
   same data space.
   Several readers have suggested it might make more sense to keep TCP
   connection parameters on a per-connection basis rather than
   globally.
   The method for specifying the TCP round-trip time algorithm needs
   to be refined.  The expression syntax should be sufficiently
   general that all round-trip-time-related algorithms (e.g., those
   for time or routing protocols) can be expressed in it.
   Much more research could be done into what information needs to be
   gathered to effectively monitor a network.

Partridge & Trewitt [Page 74]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1024.txt · Last modified: 1987/10/29 00:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki