HEMS variable definitions
RFC 1024

Document Type RFC - Unknown (October 1987; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1024 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        C.Partridge
Request For Comment: 1024                                       BBN/NNSC
                                                              G. Trewitt
                                                            October 1987

                       HEMS VARIABLE DEFINITIONS


   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

   The authors assume a working knowledge of the ISO data encoding
   standard, ASN.1, and a general understanding of the IP protocol

   Distribution of this memo is unlimited.


   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


   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.


   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).


   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

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
Show full document text