Simple Gateway Monitoring Protocol
RFC 1028
|
| Document |
Type |
|
RFC - Historic
(November 1987; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
RFC 1028 (Historic)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group J. Davin
Request for Comments: 1028 Proteon, Inc.
J. Case
University of Tennessee at Knoxville
M. Fedor
Cornell University
M. Schoffstall
Rensselaer Polytechnic Institute
November 1987
A Simple Gateway Monitoring Protocol
1. Status of this Memo
This document is being distributed to members of the Internet
community in order to solicit their reactions to the proposals
contained in it. While the issues discussed may not be directly
relevant to the research problems of the Internet, they may be
interesting to a number of researchers and implementors.
This memo defines a simple application-layer protocol by which
management information for a gateway may be inspected or altered by
logically remote users.
This proposal is intended only as an interim response to immediate
gateway monitoring needs while work on more elaborate and robust
designs proceeds with the care and deliberation appropriate to that
task. Accordingly, long term use of the mechanisms described here
should be seriously questioned as more comprehensive proposals emerge
in the future. Distribution of this memo is unlimited.
2. Protocol Design Strategy
The proposed protocol is shaped in large part by the desire to
minimize the number and complexity of management functions realized
by the gateway itself. This goal is attractive in at least four
respects:
(1) The development cost for gateway software necessary to
support the protocol is accordingly reduced.
(2) The degree of management function that is remotely
supported is accordingly increased, thereby admitting
fullest use of internet resources in the management task.
Davin, Case, Fedor and Schoffstall [Page 1]
RFC 1028 Simple Gateway Monitoring November 1987
(3) The degree of management function that is remotely
supported is accordingly increased, thereby imposing the
fewest possible restrictions on the form and sophistication
of management tools.
(4) A simplified set of management functions is easily
understood and used by developers of gateway management
tools.
A second design goal is that the functional paradigm for monitoring
and control be sufficiently extensible to accommodate additional,
possibly unanticipated aspects of gateway operation.
A third goal is that the design be, as much as possible, independent
of the architecture and mechanisms of particular hosts or particular
gateways.
Consistent with the foregoing design goals are a number of decisions
regarding the overall form of the protocol design.
One such decision is to model all gateway management functions as
alterations or inspections of various parameter values. By this
model, a protocol entity on a logically remote host (possibly the
gateway itself) interacts with a protocol entity resident on the
gateway in order to alter or retrieve named portions (variables) of
the gateway state. This design decision has at least two positive
consequences:
(1) It has the effect of limiting the number of essential
management functions realized by the gateway to two: one
operation to assign a value to a specified configuration
parameter and another to retrieve such a value.
(2) A second effect of this decision is to avoid introducing
into the protocol definition support for imperative
management commands: the number of such commands is in
practice ever-increasing, and the semantics of such
commands are in general arbitrarily complex.
The exclusion of imperative commands from the set of explicitly
supported management functions is unlikely to preclude any desirable
gateway management operation. Currently, most gateway commands are
requests either to set the value of some gateway parameter or to
retrieve such a value, and the function of the few imperative
commands currently supported is easily accommodated in an
asynchronous mode by this management model. In this scheme, an
imperative command might be realized as the setting of a parameter
value that subsequently triggers the desired action.
Davin, Case, Fedor and Schoffstall [Page 2]
RFC 1028 Simple Gateway Monitoring November 1987
Show full document text