rfc1856.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

Network Working Group                                           H. Clark
Request For Comments: 1856                                    BBN Planet
Category: Informational                                   September 1995


        The Opstat Client-Server Model for Statistics Retrieval

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Network administrators gather data related to the performance,
   utilization, usability and growth of their data network.  The amount
   of raw data gathered is usually quite large, typically ranging
   somewhere between several megabytes to several gigabytes of data each
   month.  Few (if any) tools exist today for the sharing of that raw
   data among network operators or between a network service provider
   (NSP) and its customers.  This document defines a model and protocol
   for a set of tools which could be used by NSPs and Network Operation
   Centers (NOCs) to share data among themselves and with customers.

1.0  Introduction

   Network administrators gather data related to the performance,
   utilization, usability and growth of their data network.  The primary
   goal of gathering the data is to facilitate near-term problem
   isolation and longer-term network planning within the organization.
   The amount of raw data gathered is usually quite large, typically
   ranging somewhere between several megabytes to several gigabytes of
   data each month.  From this raw data, the network administrator
   produces various types of reports.  Few (if any) tools exist today
   for the sharing of that raw data among network operators or between a
   network service provider (NSP) and its customers.  This document
   defines a model and protocol for a set of tools which could be used
   by NSPs and Network Operation Centers (NOCs) to share data among
   themselves and with customers.

1.1 The OPSTAT Model

   Under the Operational Statistics model [1], there exists a common
   model under which tools exist for the collection, storage, retrieval
   and presentation of network management data.





Clark                        Informational                      [Page 1]

RFC 1856               Opstat Client-Server Model           October 1995


   This document defines a protocol which would allow a client on a
   remote machine to retrieve data from a central server, which itself
   retrieves from the common statistics database.  The client then
   presents the data to the user in the form requested (maybe to a X-
   window, or to paper).

   The basic model used for the retrieval methods defined in this
   document is a client-server model.  This architecture envisions that
   each NOC (or NSP) should install a server which provides locally
   collected information for clients.  Using a query language the client
   should be able to define the network object of interest, the
   interface, the metrics and the time period to be examined.  Using a
   reliable transport-layer protocol (e.g., TCP), the server will
   transmit the requested data.  Once this data is received by the
   client it could be processed and presented by a variety of tools
   including displaying the data in a X window, sending postscript to a
   printer, or displaying the raw data on the user's terminal.

   The remainder of this document describes how the client and server
   interact, describes the protocol used between the client and server,
   and discusses a variety of other issues surrounding the sharing of
   data.

2.0  Client-Server Description

2.1  The Client

   The basic function of the client is to retrieve data from the server.
   It will accept requests from the user, translate those requests into
   the common retrieval protocol and transmit them to the server, wait
   for the server's reply, and send that reply to the user.

   Note that this document does not define how the data should be
   presented to the user.  There are many methods of doing this
   including:

    - use a X based tool that displays graphs (line, histogram, etc.)
    - generate PostScript output to be sent to a printer
    - dump the raw data to the user's terminal

   Future documents based on the Operational Statistics model may define
   standard  graphs  and variables to be displayed, but this is work yet
   to be done (as of this writing).








Clark                        Informational                      [Page 2]

RFC 1856               Opstat Client-Server Model           October 1995


2.2  The Server

   The basic function of the server is to accept connections from a
   client, accept some series of commands from the client and perform a
   series of actions based on the commands, and then close the
   connection to the client.

   The server must have some type of configuration file, which is left
   undefined in this document.  The configuration file would list users
   that could access the server along with the authentication they would
   use.  The configuration file should also allow the specification of
   the data items that the user should be permitted to access (and, by
   implication, not allowed to access).  Server security concerns are
   specifically addressed in Section 4.

3.0  Protocol Commands

   This section defines the commands which may be transmitted to the
   server and the server responses to those commands.  The available
   commands are:

    LOGIN  - accept new connection
    EXIT   - disconnect
    LIST   - show available variables
    SELECT - mark data for retrieval
    STATUS - show the state of the server
    GET    - download data to the client

   In addition, a state machine describing specific actions by the
   server is included.  Server security concerns are addressed in
   Section 4.

   Note that in some of the descriptions below, the term <ASCII-STRING>
   is used.  This refers to printable ASCII characters, defined as all
   letters, numbers, and special characters such as $, %, or *.  It
   specifically excludes all special control characters in the lower
   parts of the character set (i.e., 0x00 - 0x1F), and any such
   characters that are received by the server or client should be
   ignored.












Clark                        Informational                      [Page 3]

RFC 1856               Opstat Client-Server Model           October 1995


3.1  Command Return Codes

   The responses a server will return to a client are of the form:

    RETURN-INFO  ::=  <RETURN-CODE> " <ASCII-STRING> " | <RETURN-CODE>
    RETURN-CODE  ::=  <MAIN-CODE><COMMAND><SUB-CODE>
    MAIN-CODE    ::=  1..9
    COMMAND      ::=  1..9
    SUB-CODE     ::=  0..9

   For each command sent to the server, the server returns a series of
   three digit numeric codes which specifies the result of the
   operation, plus optional ASCII text for humans.  The value of MAIN-
   CODE specifies what happened, as in:

    1   Error
    9   Success / Informational

    The commands are encoded as:

    1   LOGIN
    2   SELECT
    3   STATUS
    4   LIST
    5   GET
    9   EXIT

   The following specific error codes must be supported by  all  servers
   and clients:

    110  Login Invalid
    113  Scanning Error during LOGIN
    120  SELECT Failed
    130  STATUS Failed
    140  LIST Failed
    141  Bad LIST encoding
    150  GET Failed
    151  GET doesn't support that type of encoding
    910  Login Accepted
    920  SELECT successful
    931  STATUS Output Starting
    932  STATUS Output Done
    941  LIST lookup successful, here comes the data!
    942  LIST dump done!
    951  GET lookup successful, here comes the data!
    952  GET dump done!
    990  Server closing connection after EXIT received




Clark                        Informational                      [Page 4]

RFC 1856               Opstat Client-Server Model           October 1995


   Other codes may be used, but may not be supported by all clients or
   servers.

3.2  The LOGIN Command

   The LOGIN command authenticates a user to the server.  The format  of
   the LOGIN command is:

    LOGIN-CMD    ::=  LOGIN <username> <auth-type>
    USERNAME     ::=  " <ASCII-STRING> "
    AUTH-TYPE    ::=  "none" | "password" | " <ASCII-STRING> "
    CHAL-CMD     ::=  CHAL " <ASCII-STRING> "
    AUTH-CMD     ::=  AUTH " <ASCII-STRING> "

   The authentication types supported by each server will vary, but must
   include "none" and "password".  Note that a server may or may not
   choose to allow logins via either of these methods, but it must
   recognize the two special authentication types.

   In processing a LOGIN command sequence, the server first checks the
   username and authentication type requested.  If the username is
   invalid (e.g., there's no such user known to the server) or the
   authentication type requested is not supported by the server, then
   the server must return a 110 error and close the connection after
   faking the challenge/authentication process (see examples below).

   After passing the username and authentication type checking, a
   challenge must be sent.  Note that the challenge will be specific to
   the type of authentication requested, and the ASCII string may be an
   empty string if no specific challenge is needed (such as in the
   password-only case). The next command the client returns must be an
   AUTH response, and if not, the server must close the connection.
   After processing the authentication information, the server must
   return a 910 code if the authentication process is successful, or a
   110 error messsage if unsuccessful. Additionally, if the
   authentication fails, the server must immediately close the
   connection.

   If, at any point, during the LOGIN sequence, a syntax error occurs (a
   client doesn't send the correct number of arguments in the LOGIN
   command, for example), the server must return a 113 error and close
   the connection.

   If the special AUTH-TYPE of "none" is used, and the server allows the
   specified username (such as anonymous) to login without
   authentication, then the server should still send a "CHAL" response
   to get additional information about the person logging in.  The
   server may then choose to allow or disallow the login based on the



Clark                        Informational                      [Page 5]

RFC 1856               Opstat Client-Server Model           October 1995


   information returned in the AUTH response.

   An example of an invalid authentication type requested:

    >LOGIN "cow" "s/key"
    <CHAL "lo35098 98"
    >AUTH "COW DOG BARK CAT MOO MEOW"
    <110 "Login invalid"

    The server didn't support S/Key, but it made it appear to the user as
    if it did.  An example of an authentication failure:

    >LOGIN "dog" "securid"
    <CHAL "enter passcode"
    >AUTH "103945"
    <110 "Login invalid"

   The user gave the wrong number for SecurID authentication.  An
   example of a successful login:

    >LOGIN "cat" "password"
    <CHAL "send the dumb clear-text password"
    >AUTH "foobar"
    <910 "Login accepted"

    or

    >LOGIN "anonymous" "none"
    <CHAL "tell me who you are anyway"
    >AUTH "[e-mail]"
    <910 "Login accepted"

    An example of a invalid username: