RFC 1021

THE HIGH-LEVEL ENTITY MANAGEMENT SYSTEM (HEMS) 🎀

okay bestie, this is RFC 1021 and it's giving foundational 💖 It's Request For Comment 1021 from the Network Working Group 🧚. The authors are C. Partridge (BBN/NNSC) and G. Trewitt (Stanford), and it's dated October 1987 📅. It's experimental, as the status section says right below 🧪. The header doesn't list anything it obsoletes or updates ✨.

---

STATUS OF THIS MEMO ✨

okay so this section gives an overview of the RFCs that make up the High-Level Entity Management System 📚. The system is experimental 🧪 and it's currently being tested in portions of the Internet 🌐. The hope is that this work will help lead to a standard for IP internetwork management 🙏. Distribution of this memo is unlimited 💌.

INTRODUCTION 🌸

until recently, a majority of the critical components in IP networks, like gateways, came from a super small group of vendors 🏪. every vendor had its own set of management protocols and mechanisms, but the collection was small enough that a knowledgeable system administrator could be expected to learn them all 🧠.

now though, the number of vendors has grown quite large 📈, and with no accepted standard for managing network components, things are causing severe management problems 😭. making it worse is the explosive growth of the connected IP networks known as the Internet 🚀. put bigger size and more heterogeneity together and internetwork management gets extremely difficult 💀. this memo talks about an effort to devise a standard protocol for all devices, which should help ease the management problem 🫶.

the RFCs that currently define the High-Level Entity Management System are this memo along with RFC-1022, 1024, and 1023 📖. this list is expected to change and grow over time, so readers are strongly encouraged to check the RFC Index for the most current versions 👀.

MONITORING AND CONTROL 🦋

historically, the IP community has split network management into two distinct types of activities: monitoring and control 🔍🎛️. monitoring is the activity of extracting or collecting data from the network, or a part of the network, to observe its behavior 👁️. control is the activity of taking actions to effect changes in the behavior of the network, or a part of it, in real-time, usually to improve the network's performance ⚡.

note that the ability to control presupposes the ability to monitor 💜 changing the network's behavior without being able to observe the effects is not useful 🙃. on the other hand, monitoring without control makes some sense. just understanding what is causing a network to misbehave can be useful 🕵️‍♀️.

control is also a more difficult functionality to define 😤. control operations other than the most generic are usually device-specific. the problem isn't just providing a mechanism for control, it's also defining a set of control operations that are generally applicable across a diverse set of devices 🧩. letting remote applications exercise control over an entity also implies the need for a suite of safeguards, so that unauthorized applications cannot harm the network 🛡️.

because monitoring is the key first step, the authors concentrated more heavily on the problems of effective monitoring in this initial design 🥇. the basic control mechanisms are defined, but many components need for control, such as strong access control mechanisms, have not been fully defined 🚧.

---

OVERVIEW OF THE HEMS 💅

the HEMS is made up of three parts 🎀. first, there's a query processor, which can reside on any addressable entity. second, there's an event generator, which also resides on entities. third, there are applications, which know how to send requests to the query processor and interpret the replies 📬. the query processor and applications communicate using a message protocol that runs over a standard transport protocol 🚚.

The Query Processor 👑

the query processor is the key to the management system 🔑. it interprets all monitoring and control requests. for optimal network management, we would love to see query processors on most network entities 🥰.

to encourage implementations of query processors, one of the primary goals was to make it as small and simple as possible, consistent with management requirements 🐣.

defining the management requirements was no small task 😩. the networking community hasn't reached a consensus yet about what kinds of monitoring information should be available from network entities, or what control functions are required to properly manage those entities 🤷‍♀️. the HEMS standards came out of discussions with several interest groups, and they represent the authors' best effort to distill the varying sets of needs 🍹.

the authors settled on a system that was extensible, robust, host-architecture independent, and as simple as possible, consistent with the other goals ✨. extensibility was essential, because management needs will keep evolving 📈, and a closed system that couldn't be changed would be obsolete almost as soon as it was defined 🗑️. unfortunately, extensibility is also the requirement least consistent with simplicity 😭, since making the system extensible led the authors to use self-describing data formats and an interpreted query language 🧾.

a robust system is required if the system is going to be useful for diagnosing network failures 🩺. if the monitoring system can't survive at least moderate network failures, it isn't useful 💔.

the query processor is designed to be highly extensible 💫. an application sends the query processor instructions about objects to be examined or changed 📝. the query processor locates the objects in its host entity and performs the requested operations 🎯. the objects are self-describing, using the binary-encoding scheme defined in ISO Standard ASN.1 🧬. care has been taken to use a limited set of the ASN.1 coding set, so that the query processor's handling of data can be optimized 🏎️.

it's a key feature of HEMS that messages to the query processor contain multiple instructions 💜. the authors felt this would give much higher performance than a remote procedure system that limited an application to one operation per message 🚀.

the set of maintained objects is standardized across all entities 🤝. every entity is required to manage a small set of objects. on top of that, entities of a particular type (e.g., a gateway) may be required to manage a larger set of objects, which are optional on other entities 🎁. entities are also permitted to make additional, entity-specific objects available to applications 🌈. a method for discovering the existence of additional objects is defined 🔎.

the combination of self-describing data, the ability to add to the standard data set, and a query language that can be easily enhanced appeared to offer the necessary extensibility 💖.

Event Generator 🔔

on many network entities, especially critical components like gateways, it's necessary to have a way for devices to send unsolicited status messages to network management centers 📣. in the IP community, these messages have historically been called "traps" 🪤, but for compatibility with the ISO nomenclature, the HEMS system calls them "events" 🎉.

in the HEMS system, events are handled as slightly specialized replies to queries, and they're sent to one or more management centers 📨. like all other HEMS messages, events are formatted in ASN.1 format 🧁.

each event is given a well-known code, which is standardized across all entities 🏷️. provision is also made for entity-specific event codes 🫧.

Applications 📱

the HEMS expects applications to be more intelligent than the query processor 🧠. among other functions, applications will have to be able to identify and parse entity-specific values that may be returned 🕵️.

the details of applications are mostly not discussed in the HEMS specifications, because there's very little that needs to be standardized 🙌. applications must send requests using the protocols discussed in the next section 📤. but the interfaces applications provide for displaying monitoring or control information are entirely application dependent 🖼️.

Protocols 🚦

query processors and applications communicate using an application-specific monitoring protocol, the High-Level Entity Management Protocol (HEMP) 🗣️. this protocol provides the formatting rules for the queries and their replies 📐.

HEMP runs over a standard transport protocol 🛣️. there was a real debate in the community about which type of transport protocol was best suited for monitoring 🥊. the key issue was how reliable monitoring interactions needed to be 🤔.

the authors expect that three types of management activities will predominate: status monitoring, firefighting, and event reporting 🎯.

status monitoring is envisioned as occasional retrieval of monitoring information, possibly in response to receiving event messages 🛋️. in these situations, the network is expected to be in good working condition, so monitoring exchanges could probably comfortably work with an unreliable transport protocol 😌. the chance of data loss is small, and it's probably not a serious problem, since the data is unlikely to be so important that it must be reliably delivered 🤞. (however, it should be noted that some applications may prefer reliable delivery because it's more convenient 💅.)

firefighting is a completely different situation 🚒. in this scenario, one or more sites are using management applications to try to locate and fix a network problem 🔧. here we must assume that while the network functions (i.e., data can get through), it's not very healthy 🤒. we should assume packets are being lost, network routes will be non-optimal, and it's essential that the monitoring data (which is presumably diagnostic) gets back to the application, and that control requests are reliably delivered to the entity 📦. in such circumstances, a reliable protocol is essential 🚨

events provide yet another bit of complexity 🌀. events contain useful status information, but experience suggests this information doesn't have to be delivered reliably 🤷‍♀️. if the problem is serious enough, it will re-occur and the event will be sent again 🔁. furthermore, events will often be sent to more than one management center, which would appear to rule out connection-oriented, reliable protocols such as TCP for events 🙅‍♀️.

the current decision is to establish two possible transport options for HEMS 🌷. more experimental systems may use the Versatile Message Transaction Protocol (VMTP), an experimental IP transaction protocol 🧪. near-term production systems can use a combination of the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), as described in RFC-1022 💜

Compatibility with Common Management Information Protocol (CMIP) 🦋

okay so bestie, a bunch of groups were like "we want to build apps that can use BOTH HEMS and the ISO-defined CMIP 👀" and honestly? it turns out they can totally co-exist 💖 ✨ the authors actually put in real effort to make that happen 🫶

here's the lowkey genius part 🧚 at the highest level, CMIP and HEMS both do operations on objects that live in remote entities, and both use ASN.1 to format those objects 💅 so it's possible to write one standard set of interface routines that can access either system, even though the underlying mechanics are super different 🔥 iconic, no cap.