Browse Prior Art Database

High-level Entity Management Protocol (HEMP) (RFC1022) Disclosure Number: IPCOM000001826D
Original Publication Date: 1987-Oct-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 12 page(s) / 15K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR [+1]

Related Documents

10.17487/RFC1022: DOI


This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 14% of the total text.

Network Working Group C. Partridge Request For Comment: 1022 BBN/NNSC G. Trewitt Stanford 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 sections.


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