Simple Gateway Monitoring Protocol
RFC 1028

Document Type RFC - Historic (November 1987; No errata)
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized 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

   (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

   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

   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

   (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

   A second design decision is to realize any needed authentication
Show full document text