📄 rfc1076.txt
字号:
Network Working Group G. Trewitt
Request for Comments: 1076 Stanford University
Obsoletes: RFC 1023 C. Partridge
BBN/NNSC
November 1988
HEMS Monitoring and Control Language
TABLE OF CONTENTS
1. Status of This Memo 1
Introduction 2
2. Overview and Scope 2
3. Overview of Query Processor Operation 4
4. Encoding of Queries and Responses 5
4.1 Notation Used in This Proposal 5
5. Data Organization 6
5.1 Example Data Tree 7
5.2 Arrays 8
6. Components of a Query 9
7. Reply to a Query 10
8. Query Language 12
8.1 Moving Around in the Data Tree 14
8.2 Retrieving Data 15
8.3 Data Attributes 16
8.4 Examining Memory 18
8.5 Control Operations: Modifying the Data Tree 19
8.6 Associative Data Access: Filters 21
8.7 Terminating a Query 26
9. Extending the Set of Values 27
10. Authorization 27
11. Errors 28
I. ASN.1 Descriptions of Query Language Components 29
I.1 Operation Codes 30
I.2 Error Returns 31
I.3 Filters 33
I.4 Attributes 34
I.5 VendorSpecific 36
II. Implementation Hints 36
III. Obtaining a Copy of the ASN.1 Specification 42
1. STATUS OF THIS MEMO
This RFC specifies a query language for monitoring and control of
network entities. This RFC supercedes RFC-1023, extending the query
language and providing more discussion of the underlying issues.
Trewitt & Partridge [Page 1]
RFC 1076 HEMS Monitoring and Control Language November 1988
This language is a component of the High-Level Entity Monitoring
System (HEMS) described in RFC-1021 and RFC-1022. Readers may wish
to consult these RFCs when reading this memo. RFC-1024 contains
detailed assignments of numbers and structures used in this system.
Portions of RFC-1024 that define query language structures are
superceded by definitions in this memo. This memo assumes a
knowledge of the ISO data encoding standard, ASN.1.
Distribution of this memo is unlimited.
INTRODUCTION
This RFC specifies the design of a general-purpose, yet efficient,
monitoring and control language for managing network entities. The
data in the entity is modeled as a hierarchy and specific items are
named by giving the path from the root of the tree. Most items are
read-only, but some can be "set" in order to perform control
operations. Both requests and responses are represented using the
ISO ASN.1 data encoding rules.
2. OVERVIEW AND SCOPE
The basic model of monitoring and control used in this memo is that a
query is sent to a monitored entity and the entity sends back a
response. The term query is used in the database sense -- it may
request information, modify data, or both. We will use gateway-
oriented examples, but it should be understood that this query-
response mechanism is applicable to any IP entity.
In particular, there is no notion of an interactive "conversation" as
in SMTP [RFC-821] or FTP [RFC-959]. A query is a complete request
that stands on its own and elicits a complete response.
In order to design the query language, we had to define a model for
the data to be retrieved by the queries, which required some
understanding of and assumptions to be made about the data. We ended
up with a fairly flexible data model, which places few limits on the
type or size of the data.
Wherever possible, we give motivations for the design decisions or
assumptions that led to particular features or definitions. Some of
the important global considerations and assumptions are:
- The query processor should place as little computational
burden on the monitored entity as possible.
- It should not be necessary for a monitored entity to store
the complete query. Nothing in the query language should
Trewitt & Partridge [Page 2]
RFC 1076 HEMS Monitoring and Control Language November 1988
preclude an implementation from being able to process the
query on the fly, producing portions of the response while
the query is still being read and parsed. There may be
other constraints that require large amounts of data to be
buffered, but the query language design must not be one.
- It is assumed that there is some mechanism to transport a
sequence of octets to a query processor within the
monitored entity and that there is some mechanism to return
a sequence of octets to the entity making the query. In
HEMS, this is provided by HEMP and its underlying transport
layer. The query language design is independent of these
details, however, and could be grafted onto some other
protocol.
- The data model must provide organization for the data, so
that it can be conveniently named.
- Much of the data to be monitored will be contained in
tables. Some tables may contain other tables. The query
language should be able to deal with such tables.
- We don't provide capabilities for data reduction in the
query language. We will provide for data selection, for
example, only retrieving certain table entries, but we will
not provide general facilities for processing data, such as
computing averages.
- Because one monitoring center may be querying many
(possibly hetrogenous) hosts, it must be possible to write
generic queries that can be sent to all hosts, and have the
query elicit as much information as is available from each
host. i.e., queries must not be aborted just because they
requested non-existent data.
There were some assumptions that we specifically did not make:
- It is up to the implementation to choose what degree of
concurrency will be allowed when processing queries. By
locking only portions of the database, it should be
possible to achieve good concurrency while still preventing
deadlock.
- This specification makes no statement about the use of the
"definite" and "indefinite" length forms in ASN.1. There
is currently some debate about this usage in the ISO
community; implementors should note the recommendations in
the ASN.1 specification.
Trewitt & Partridge [Page 3]
RFC 1076 HEMS Monitoring and Control Language November 1988
Other RFCs associated with HEMS are:
RFC-1021 Overview;
RFC-1022 Transport protocol and message encapsulation;
RFC-1024 Precise data definitions.
The rest of this report is organized as follows:
Section 3 Gives a brief overview of the data model and the
operation of the query processor.
Section 4 Describes the encoding used for queries and
responses, and the notation used to represent them
in this report.
Section 5 Describes how the data is organized in the
monitored entity, and the view provided of it by
the query processor.
Section 6 Describes the basic data types that may be given
to the query processor as input.
Section 7 Describes how a reply to a query is organized.
Section 8 Describes the operations available in the query
language.
Section 9 Describes how the set of data in the tree may be
extended.
Section 10 Describes how authorization issues affect the
execution of a query.
Section 11 Describes how errors are reported, and their
effect on the processing of the query.
Appendix I Gives precise ASN.1 definitions of the data types
used by the query processor.
Appendix II Gives extensive implementation hints for the core
of the query processor.
3. OVERVIEW OF QUERY PROCESSOR OPERATION
In this section, we give an overview of the operation of the query
processor, to provide a framework for the later sections.
The query language models the manageable data as a tree, with each
Trewitt & Partridge [Page 4]
RFC 1076 HEMS Monitoring and Control Language November 1988
branch representing a different aspect of the entity, such as
different layers of protocols. Subtrees are further divided to
provide additional structure to the data. The leaves of the tree
contain the actual data.
Given this data representation, the task of the query processor is to
traverse this tree and retrieve (or modify) data specified in a
query. A query consists of instructions to move around in the tree
and to retrieve (or modify) named data. The result of a query is an
exact image of the parts of the tree that the query processor
visited.
The query processor is very simple -- it only understands eight
commands, most of which share the same structure. It is helpful to
think of the query processor as an automaton that walks around in the
tree, directed by commands in the query. As it moves around, it
copies the tree structure it traverses to the query result. Data
that is requested by the query is copied into the result as well.
Data that is changed by a query is copied into the result after the
modification is made.
4. ENCODING OF QUERIES AND RESPONSES
Both queries and responses are encoded using the representation
defined in ISO Standard ASN.1 (Abstract Syntax Notation 1). ASN.1
represents data as sequences of <tag,length,contents> triples that
are encoded as a stream of octets. The data tuples may be
recursively nested to represent structured data such as arrays or
records. For a full description, see the ISO standards IS 8824 and
IS 8825. See appendix for information about obtaining these
documents.
4.1 Notation Used in This Proposal
The notation used in this memo is similar to that used in ASN.1, but
less formal, smaller, and (hopefully) easier to read. We will refer
to a <tag,length,contents> tuple as a "data object". In this RFC, we
will not be concerned with the details of the object lengths. They
exist in the actual ASN.1 encoding, but will be omitted in the
examples here.
Data objects that have no internal ASN.1 structure such as integer or
octet string are referred to as "simple types" or "simple objects".
Objects which are constructed out of other ASN.1 data objects will be
referred to as "composite types" or "composite objects".
Trewitt & Partridge [Page 5]
RFC 1076 HEMS Monitoring and Control Language November 1988
The notation
ID(value)
represents a simple object whose tag is "ID" with the given value. A
composite object is represented as
ID{ ... contents ... }
where contents is a sequence of data objects. The contents may
include both simple and structured types, so the structure is fully
recursive.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -