InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

High-level Entity Management Protocol (HEMP) (RFC1022)

IP.com Disclosure Number: IPCOM000001826D
Original Publication Date: 1987-Oct-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 10 page(s) / 23K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR [+2]



This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 13% of the total text.

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.

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