High-level Entity Management Protocol (HEMP)
RFC 1022

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



   An application protocol for managing network entities such as hosts,
   gateways and front-end machines, is presented.  This protocol is a
   component of the High-Level Entity Management System (HEMS) described
   in RFC-1021.  Readers may want to consult RFC-1021 when reading this
   memo.  This memo also assumes a knowledge of the ISO data encoding
   standard, ASN.1.  Distribution of this memo is unlimited.


   The High-Level Entity Management Protocol (HEMP) provides an
   encapsulation system and set of services for communications between
   applications and managed entities.  HEMP is an application protocol
   which relies on existing transport protocols to deliver HEMP messages
   to their destination(s).

   The protocol is targeted for management interactions between
   applications and entities.  The protocol is believed to be suitable
   for both monitoring and control interactions.

   HEMP provides what the authors believe are the three essential
   features of a management protocol:  (1) a standard encapsulation
   scheme for all interactions, (2) an authentication facility which can
   be used both to verify messages and limit access to managed systems,
   and (3) the ability to encrypt messages to protect sensitive
   information.  These features are discussed in detail in the following


   HEMP is designed to support messages; where a message is an
   arbitrarily long sequence of octets.

   Five types of messages are currently defined: request, event, reply,
   and protocol error, and application error messages.  Reply, protocol
   error and application error messages are only sent in reaction to a
   request message, and are referred to collectively as responses.

Partridge & Trewitt                                             [Page 1]
RFC 1022                     HEMS Protocol                  October 1987

   Two types of interaction are envisioned: a message exchange between
   an application and an entity managed by the application, and
   unsolicited messages from an entity to the management centers
   responsible for managing it.

   When an application wants to retrieve information from an entity or
   gives instructions to an entity, it sends a request message to the
   entity.  The entity replies with a response, either a reply message
   if the request was valid, or an error message if the request was
   invalid (e.g., failed authentication).  It is expected that there
   will only be one response to a request message, although the protocol
   does not preclude multiple responses to a single request.

   Protocol error messages are generated if errors are found when
   processing the HEMP encapsulation of the message.  The possible
   protocol error messages are described later in this document.  Non-
   HEMP errors (e.g., errors that occur during the processing of the
   contents of the message) are application errors.  The existence of
   application error messages does not preclude the possibility that a
   reply will have an error message in it.  It is expected that the
   processing agent on the entity may have already started sending a
   reply message before an error in a request message is discovered.  As
   a result, application errors found during processing may show up in
   the reply message instead of a separate application error message.

   Note that in certain situations, such as on secure networks,
   returning error messages may be considered undesirable.  As a result,
   entities are not required to send error messages, although on
   "friendly" networks the use of error messages is encouraged.

   Event messages are unsolicited notices sent by an entity to an
   address, which is expected to correspond to one or more management
   centers.  (Note that a single address may correspond to a multicast
   address, and thus reach multiple hosts.)  Event messages are
   typically used to allow entities to alert management centers of
   important changes in their state (for example, when an interface goes
   down or the entity runs out of network buffers).

Partridge & Trewitt                                             [Page 2]
RFC 1022                     HEMS Protocol                  October 1987


   Every HEMP message is put in the general form shown in Figure 1.

                     :           leader              :
Show full document text