rfc1028.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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


   A second design decision is to realize any needed authentication
   functionality in a distinct protocol layer that provides services to
   the monitoring protocol itself.  The most important benefit of this
   decision is a reduction in the complexity of the individual protocol
   layers - thereby easing the task of implementation.

   Consistent with this layered design strategy is a third design
   decision that the identity of an application protocol entity is known
   to its peers only by the services of the underlying authentication
   protocol.  Implicit in this decision is a model of access control by
   which access to variables of a gateway configuration is managed in
   terms of the association between application entities and sessions of
   the authentication protocol.  Thus, multi-level access to gateway
   variables is supported by multiple instances of the application
   protocol entity, each of which is characterized by:

   (1)  the set of gateway variables known to said entity,

   (2)  the mode of access (READ-ONLY or READ-WRITE) afforded to
        said set of variables, and

   (3)  the authentication protocol session to which belong the
        messages sent and received by said entity.

   A fourth design decision is to adopt the conventions of the CCITT
   X.409 recommendation [1] for representing the information exchanged
   between protocol entities.  One cost of this decision is a modest
   increase in the complexity of the protocol implementation.  One
   benefit of this decision is that protocol data are represented on the
   network in a machine-independent, widely understood, and widely
   accepted form.  A second benefit of this decision is that the form of
   the protocol messages may be concisely and understandably described
   in the X.409 language defined for such purposes.

   A fifth design decision, consistent with the goal of minimizing
   gateway complexity, is that the variables manipulated by the protocol
   assume only integer or octet string type values.

   A sixth design decision, also consistent with the goal of minimizing
   gateway complexity, is that the exchange of protocol messages
   requires only an unreliable datagram transport, and, furthermore,
   that every protocol message is entirely and independently
   representable by a single transport datagram.  While this document
   specifies the exchange of protocol messages via the UDP protocol [2],
   the design proposed here is in general suitable for use with a wide
   variety of transport mechanisms.





Davin, Case, Fedor and Schoffstall                              [Page 3]

RFC 1028               Simple Gateway Monitoring           November 1987


   A seventh design decision, consistent with the goals of simplicity
   and extensibility, is that the variables manipulated by the protocol
   are named by octet string values.  While this decision departs from
   the architectural traditions of the Internet whereby objects are
   identified by assigned integer values, the naming of variables by
   octet strings affords at least two valuable benefits.  Because the
   set of octet string values constitutes a variable name space that, as
   convenient, manifests either flat or hierarchical structure,

   (1)  a single, simple mechanism can provide both random access
        to individual variables and sequential access to
        semantically related groups of variables, and

   (2)  the variable name space may be extended to accommodate
        unforeseen needs without compromising either the
        relationships among existing variables or the potential
        for further extensions to the space.

   An eighth design decision is to minimize the number of unsolicited
   messages required by the protocol definition.  This decision is
   consistent with the goal of simplicity and motivated by the desire to
   retain maximal control over the amount of traffic generated by the
   network management function - even at the expense of additional
   protocol overhead.  The strategy implicit in this decision is that
   the monitoring of network state at any significant level of detail is
   accomplished primarily by polling for appropriate information on the
   part of the monitoring center.  In this context, the definition of
   unsolicited messages in the protocol is confined to those strictly
   necessary to properly guide a monitoring center regarding the timing
   and focus of its polling.

3.  The Gateway Monitoring Protocol

   The gateway monitoring protocol is an application protocol by which
   the variables of a gateway's configuration may be inspected or
   altered.

   Communication among application protocol entities is by the exchange
   of protocol messages using the services of the authentication
   protocol described elsewhere in this document.  Each such message is
   entirely and independently represented by a single message of the
   underlying authentication protocol.  An implementation of this
   protocol need not accept protocol messages whose length exceeds 484
   octets.

   The form and function of the four message types recognized by a
   protocol entity is described below.  The type of a given protocol
   message is indicated by the value of the implicit type tag for the



Davin, Case, Fedor and Schoffstall                              [Page 4]

RFC 1028               Simple Gateway Monitoring           November 1987


   data structure that is represented by said message according to the
   conventions of the CCITT X.409 recommendation.

3.1.  The Get Request Message Type

   The form of a message of Get Request type is described below in the
   language defined in the CCITT X.409 recommendation:

   var_value_type          ::=     CHOICE {

                                   INTEGER,
                                   OCTET STRING

                                     }

   var_name_type           :=      OCTET STRING

   var_op_type             ::=     SEQUENCE {

                           var_name                var_name_type,
                           var_value               var_value_type

                           }

   var_op_list_type        ::=     SEQUENCE OF var_op_type

   error_status_type       ::=     INTEGER {

                           gmp_err_noerror         (0),
                           gmp_err_too_big         (1),
                           gmp_err_nix_name        (2),
                           gmp_err_bad_value       (3)

                           }

   error_index_type        ::=     INTEGER

   request_id_type         ::=     INTEGER

   get_req_message_type    ::=     [ APPLICATION 1 ] IMPLICIT

                           SEQUENCE {

                           request_id              request_id_type,
                           error_status            error_status_type,
                           error_index             error_index_type,
                           var_op_list             var_op_list_type




Davin, Case, Fedor and Schoffstall                              [Page 5]

RFC 1028               Simple Gateway Monitoring           November 1987


                           }

   Upon receipt of a message of this type, the receiving entity responds
   according to any applicable rule in the list below:

   (1)  If, for some var_op_type component of the received message, the
        value of the var_name field does not lexicographically precede
        the name of some variable known to the receiving entity, then
        the receiving entity sends to the originator of the received
        message a message of identical form except that the indicated
        message type is Get Response, the value of the error_status
        field is gmp_err_nix_name, and the value of the error_index
        field is the unit-based index of said var_op_type component in
        the received message.

   (2)  If the size of the Get Response type message generated as
        described below would exceed the size of the largest message
        for which the protocol definition requires acceptance, then the
        receiving entity sends to the originator of the received message
        a message of identical form except that the indicated message
        type is Get Response, the value of the error_status field is
        gmp_err_too_big, and the value of the error_index field is zero.

   If none of the foregoing rules apply, then the receiving entity sends
   to the originator of the received message a Get Response type message
   such that, for each var_op_type component of the received message, a
   corresponding component of the generated message represents the name
   and value of that variable whose name is, in the lexicographical
   ordering of the names of all variables known to the receiving entity
   together with the value of the var_name field of the given component,
   the immediate successor to that value.  The value of the error_status
   field of the generated message is gmp_err_noerror and the value of
   the error_index field is zero.  The value of the request_id field of
   the generated message is that for the received message.

   Messages of the Get Request type are generated by a protocol entity