As per Relevance of the word specific, we have this rfc below:
Network Working Group H.
Request For Comments: 1856 BBN
Category: Informational September 1995
The Opstat Client-Server Model for Statistics
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Network administrators gather data related to the performance
utilization, usability and growth of their data network. The
of raw data gathered is usually quite large, typically
somewhere between several megabytes to several gigabytes of data
month. Few (if any) tools exist today for the sharing of that
data among network operators or between a network service
(NSP) and its customers. This document defines a model and
for a set of tools which could be used by NSPs and Network
Centers (NOCs) to share data among themselves and with customers
1.0
Network administrators gather data related to the performance
utilization, usability and growth of their data network. The
goal of gathering the data is to facilitate near-term
isolation and longer-term network planning within the organization
The amount of raw data gathered is usually quite large,
ranging somewhere between several megabytes to several gigabytes
data each month. From this raw data, the network
produces various types of reports. Few (if any) tools exist
for the sharing of that raw data among network operators or between
network service provider (NSP) and its customers. This
defines a model and protocol for a set of tools which could be
by NSPs and Network Operation Centers (NOCs) to share data
themselves and with customers
1.1 The OPSTAT
Under the Operational Statistics model [1], there exists a
model under which tools exist for the collection, storage,
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
remote machine to retrieve data from a central server, which
retrieves from the common statistics database. The client
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
document is a client-server model. This architecture envisions
each NOC (or NSP) should install a server which provides
collected information for clients. Using a query language the
should be able to define the network object of interest,
interface, the metrics and the time period to be examined. Using
reliable transport-layer protocol (e.g., TCP), the server
transmit the requested data. Once this data is received by
client it could be processed and presented by a variety of
including displaying the data in a X window, sending postscript to
printer, or displaying the raw data on the user's terminal
The remainder of this document describes how the client and
interact, describes the protocol used between the client and server
and discusses a variety of other issues surrounding the sharing
data
2.0 Client-Server
2.1 The
The basic function of the client is to retrieve data from the server
It will accept requests from the user, translate those requests
the common retrieval protocol and transmit them to the server,
for the server's reply, and send that reply to the user
Note that this document does not define how the data should
presented to the user. There are many methods of doing
including
- use a X based tool that displays graphs (line, histogram, etc.)
- generate PostScript output to be sent to a
- dump the raw data to the user's
Future documents based on the Operational Statistics model may
standard graphs and variables to be displayed, but this is work
to be done (as of this writing).
Clark Informational [Page 2]
RFC 1856 Opstat Client-Server Model October 1995
2.2 The
The basic function of the server is to accept connections from
client, accept some series of commands from the client and perform
series of actions based on the commands, and then close
connection to the client
The server must have some type of configuration file, which is
undefined in this document. The configuration file would list
that could access the server along with the authentication they
use. The configuration file should also allow the specification
the data items that the user should be permitted to access (and,
implication, not allowed to access). Server security concerns
specifically addressed in Section 4.
3.0 Protocol
This section defines the commands which may be transmitted to
server and the server responses to those commands. The
commands are
LOGIN - accept new
EXIT -
LIST - show available
SELECT - mark data for
STATUS - show the state of the
GET - download data to the
In addition, a state machine describing specific actions by
server is included. Server security concerns are addressed
Section 4.
Note that in some of the descriptions below, the term
is used. This refers to printable ASCII characters, defined as
letters, numbers, and special characters such as $, %, or *.
specifically excludes all special control characters in the
parts of the character set (i.e., 0x00 - 0x1F), and any
characters that are received by the server or client should
ignored
Clark Informational [Page 3]
RFC 1856 Opstat Client-Server Model October 1995
3.1 Command Return
The responses a server will return to a client are of the form
RETURN-INFO ::= " " |
RETURN-CODE ::=
MAIN-CODE ::= 1..9
COMMAND ::= 1..9
SUB-CODE ::= 0..9
For each command sent to the server, the server returns a series
three digit numeric codes which specifies the result of
operation, plus optional ASCII text for humans. The value of MAIN
CODE specifies what happened, as in
1
9 Success /
The commands are encoded as
1
2
3
4
5
9
The following specific error codes must be supported by all
and clients
110 Login
113 Scanning Error during
120 SELECT
130 STATUS
140 LIST
141 Bad LIST
150 GET
151 GET doesn't support that type of
910 Login
920 SELECT
931 STATUS Output
932 STATUS Output
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
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
servers
3.2 The LOGIN
The LOGIN command authenticates a user to the server. The format
the LOGIN command is
LOGIN-CMD ::= LOGIN <username>
USERNAME ::= " "
AUTH-TYPE ::= "none" | "password" | " "
CHAL-CMD ::= CHAL " "
AUTH-CMD ::= AUTH " "
The authentication types supported by each server will vary, but
include "none" and "password". Note that a server may or may
choose to allow logins via either of these methods, but it
recognize the two special authentication types
In processing a LOGIN command sequence, the server first checks
username and authentication type requested. If the username
invalid (e.g., there's no such user known to the server) or
authentication type requested is not supported by the server,
the server must return a 110 error and close the connection
faking the challenge/authentication process (see examples below).
After passing the username and authentication type checking,
challenge must be sent. Note that the challenge will be specific
the type of authentication requested, and the ASCII string may be
empty string if no specific challenge is needed (such as in
password-only case). The next command the client returns must be
AUTH response, and if not, the server must close the connection
After processing the authentication information, the server
return a 910 code if the authentication process is successful, or
110 error messsage if unsuccessful. Additionally, if
authentication fails, the server must immediately close
connection
If, at any point, during the LOGIN sequence, a syntax error occurs (
client doesn't send the correct number of arguments in the
command, for example), the server must return a 113 error and
the connection
If the special AUTH-TYPE of "none" is used, and the server allows
specified username (such as anonymous) to login
authentication, then the server should still send a "CHAL"
to get additional information about the person logging in.
server may then choose to allow or disallow the login based on
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
>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
if it did. An example of an authentication failure
>LOGIN "dog" "securid
>AUTH "103945"
<110 "Login invalid
The user gave the wrong number for SecurID authentication.
example of a successful login
>LOGIN "cat" "password
password
>AUTH "foobar
<910 "Login accepted
>LOGIN "anonymous" "none
>AUTH "bessie@barn.farm.com
<910 "Login accepted
An example of a invalid username
>LOGIN "mule" "skey
>AUTH "COW DOG FRED LOG COLD WAR
<110 "Login invalid
The server should have some type of logging mechanism to record
successful and unsuccessful login attempts for a system
to peruse
Clark Informational [Page 6]
RFC 1856 Opstat Client-Server Model October 1995
3.3 The EXIT
The EXIT command disconnects a current user from the server.
format of the EXIT command is
Note that upon reception of an EXIT command, the server must
close the connection, even if it would be appropriate to return
ERROR return code
A sample EXIT command
>
<990 "OK, Bye now
3.4 The SELECT
The SELECT command is the function used to tag data for
from the server. The SELECT command has the format
SELECT-COM ::= SELECT <INTERFACE>
NETWORK ::=
DEVICE ::=
INTERFACE ::=
VARNAME ::=
GRANULARITY ::=
START-DATE ::=
END-DATE ::=
DATE-TYPE ::= YYYY-MM-
START-TIME ::=
END-TIME ::=
TIME-TYPE ::= HH:MM:
AGG ::= |
AGG-TYPE ::= TOTAL |
SELECT-COND ::= |
SELECT-STMT ::= WITH DATA
COND-TYPE ::= LE | GE | EQ | NE | LT |
If any conditional within the SELECT does not match existing
within the database (such as VARNAME, the S-DATE or E-DATE,
GRANULARITY), the server must return an ERROR (and hopefully
meaningful error message). The time values must be specified in GMT
and hours are specified in the range from 0-23. The
Clark Informational [Page 7]
RFC 1856 Opstat Client-Server Model October 1995
should always be specified in seconds. A sample query might be
SELECT net rtr1 eth-0 ifInOctets 900 1992-01-01 00:00:00 1992-02-
01 23:59:59
which would select all data from network "net" device "rtr1"
interface "eth-0" from Jan 1, 1992 @ 00:00:00 to Feb 1, 1992 @
23:59:59.
Note that if the client requests some type of aggregation to
performed upon the data, then the aggregation field specifies how
perform the aggregration (i.e., total or peak) and the
specifies to what interval (in seconds) to agggregate the data to
For more details about the granularity types, see [1]. If the
cannot perform the requested action, then it must return a 120 error
The server may, if it wishes, use other error codes in the
121-129 to convey more information about the specific error
occured. In either case, its recommended that the server
ASCII text describing the error
Upon completion of the data lookup, the SELECT must return the
indication of whether the lookup was successful and (if the
was successful) the tag associated with that data. If the lookup
successful, then information in the return code should be encoded as
920 " TAG "
In this case, the use of the word TAG is used as a handle for
selected data on the server. Note that this single handle may
to one or more specific SNMP variables (refer to [1] for a
explanation).
For example, if the tag "foobar" were assigned to the select
above, then the OK would be as
920 "TAG foobar
It is recommended that the return tag string be less than 10
long (this gives many tag combinations), although the server (
client) should be capable of handling arbitrary length strings
There is no requirement that the TAG have any particular meaning
may be composed of arbitrary strings
The server must keep any internal information it needs during
session so that all SELECT tags can be processed by GET or
commands. If a server doesn't have the resources to process
given SELECT, it must return an error message
Clark Informational [Page 8]
RFC 1856 Opstat Client-Server Model October 1995
It is the responsibility of the client to store information about
data that a particular tag corresponds to, i.e., if the server
returned a tag "1234" for ifInOctet data for October 1993, then
client must store that information someplace as the variables
correspond to that tag cannot be retrieved from the server
3.5 The STATUS
The STATUS command shows the general state of the server plus
all data sets which have been tagged via the SELECT command.
STATUS command has no arguments. The output from a STATUS
is
STATUS-DATA ::=
SERVER-STATUS ::= "STATUS= "
STATUS-FIELDS ::= "OK" | "NOT-OK
SERVER-TAG-LIST ::= |
SERVER-TAG ::= "TAG" "SIZE"
The number returned in the SIZE field represents the number of
of data represented by the particular TAG. The server must return
931 message before the STATUS output starts, and a 932 message at
end of the STATUS output. If any type of failure occurs, then a 130
error messages must be sent. If the server prefers, it may send
message in the range of 131-139 if it wishes, but its
that the server always return ASCII describing the enoutered error
For example, a sample output might look like
>
<931 "STATUS Command Starting
<932 "STATUS Command successful
>
<130 "Can't get STATUS right now, sorry."
>
<931 "STATUS Command Starting
<131 "Oops, error reading TAG table, sorry."
Clark Informational [Page 9]
RFC 1856 Opstat Client-Server Model October 1995
3.6 The GET
The GET command actually retrieves the data chosen via a
SELECT command. The GET command has the format
GET-CMD ::= GET
TAG ::=
TYPE ::= 1404 |
If the TAG matches a previously returned TAG from a SELECT statement
then the previously tagged data is returned. If the TAG is
(i.e., it hasn't been previously assigned by the server), then
server must return an error. The TYPE specifies the encoding of
data stream. All servers must support "1404" encoding. Others
may be supported as desired
If the server, while retrieving the data, cannot retrieve
portion of the data (i.e., some of the data previously
disappeared between the time of the SELECT and the time of the GET),
then the server must return a 150 error. If the client requests
encoding type not supported by the server, then the server
return a 151 error
The format of the returned data is as follows
RETURN-DATA-TYPE ::= START-DATA END-
RETURN-TYPE ::= 1404 |
An example would be
>GET ABC 1404
<951 "OK, here it comes!"
1404 data stream here...
<952 "All done!"
Error examples
>GET ABC STRONG-
<151 "Sorry, that encoding not available here
>GET ABC 1404
<951 "OK, here it comes!"
Clark Informational [Page 10]
RFC 1856 Opstat Client-Server Model October 1995
1404 data stream here...
<150 "Whoa, bad data..."
If any type of error code is returned by the server, the client
discard all data received from the server
3.7 The LIST
The LIST command allows the client to query the server
available data residing on the server. The LIST command has
format
LIST-CMD ::= LIST
::= | *
::= | *
::= | *
::= | *
::= | *
::= | *
::= | *
::= | *
::= | *
For example, to get a list of networks that the server has data for
you would use the command
LIST * * * * * * * * *
The
LIST netx rtry * * * * * * *
will list all interfaces for rtry. The
LIST netx rtry * ifInOctets * 1993-02-01 * * *
will get the list of interfaces on device "rtry" in network "netx
which have values for the variable "ifInOctets" after the start
of Februrary 1, 1993.
Clark Informational [Page 11]
RFC 1856 Opstat Client-Server Model October 1995
To process wildcards in a LIST command, follow these rules
1) Only the leftmost wildcard will be serviced for a
LIST
2) If all fields to the right of the leftmost wildcard
wildcards, then all values for the wildcard being
will be returned
3) If specific values are given for fields to the right of
wildcard being serviced, then the specific values must
a known
The output from the LIST command is formatted as follows
LIST-RETURN ::= START-LIST END-
LIST-ENTRY ::=
::=
::= |
::= |
::= |
::= |
::= |
::= |
::= |
::= |
Note that only the fields with values in them will be returned by
server. For example, the query to find the interfaces on rtry
>LIST netx rtry * * * * * * *
<941 "OK, here comes the list..."
<942 "all done
The query to find interfaces having ifInOctets data with a 15
granularity
>LIST netx rtry * ifInOctets 15min * * * *
<941 "OK, here comes the list..."
Clark Informational [Page 12]
RFC 1856 Opstat Client-Server Model October 1995
<942 "all done
If, while processing a LIST command, the server encounters an error
then the server must return a 140 error message. If the
cannot process the LIST command (syntax error, etc.), then it
return a 141 message. For example
>LIST netx
<141 "huh, bad list dude
>LIST netx rtry * ifInOctets 15min * * * *
<941 "OK, here comes the list..."
<140 "Whoa, bad list dude, please ignore
3.8 The Server State
The state machine pictured below describes how a server
interact with a client
+------+
+-------->| WAIT |<-----+
| +------+ |
| New | |
| Connect | | LOGIN
EXIT | \ / |
Received | +-------+ |
| | LOGIN |-----+
| +-------+
| |
| | LOGIN
| \ /
| +---------+
+--------| PROCESS |<----+
+---------+ |
| | Process
| |
+----------+
Clark Informational [Page 13]
RFC 1856 Opstat Client-Server Model October 1995
The server normally stays in WAIT (after starting and initialization
until a new connection is made from a client. The first command
client must issue is a LOGIN command, otherwise the server
immediately close the connection. If the login process fails in
way (as described in 3.2), then the server must immediately close
connection and return to the WAIT state
Once a successful LOGIN is received, the server enters the
state where it processes some number of LIST, GET, STATUS, and
commands. Any other command received while in this state must
ignored, except for the EXIT command. Once an EXIT command
received, the server exits immediately (after perfoming any
internal bookkeeping) and returns to the WAIT state. Any command
server receives while processing a command (e.g., if you send
"EXIT" while a large "GET" is being processed) will be ignored
the command being processed completes
If the data connection to the client closes for any reason while
server is in the PROCESS state, the server must immediately close
connection and do any associated internal cleanup and return to
LOGIN state
4.0 Security
There are legal, ethical and political concerns of data sharing.
this reason there is a need to insure integrity and
of any shared data. Although not specified in this standard
mechanisms to control a user's access to specific data about
objects may need to be included in server implementations.
could potentially be done in several ways, including a
file that listed the objects a user was allowed to access or
file access by using file permissions within a given file system.
a minimum, the server should not allow default access to all data
the server
Additionally, the server should strictly follow the state
shown in section 3.8. The server should be tested with
strings in the command fields to ensure that no unexpected
problems will be caused by the server. The server
specifically discard illegal ASCII characters as discussed in
3.0. If the server executes other programs, then the server
verify that no unexpected side-effects will occur as the result
the invocation or the arguments given to that program. The
should always verify that all data is contained within the
buffer, and that a long input string from a client will not
unexpected side-effects
Clark Informational [Page 14]
RFC 1856 Opstat Client-Server Model October 1995
Finally, given the relative insecurity of the global Internet,
the presence of packet-sniffing capability, several
must be weighed. The authentication process via the LOGIN
must be strictly adhered to, and the use of one-time
is strongly encouraged. It is also suggested that the data
from the server be protected (such as through encryption) so that
sensitive data is revealed by accident
5.0
This document defines a protocol which could be used in a client
server relationship to retrieve statistics from a remote
server
Much work remains to be done in the area of Operational
including questions such as
- what "standard" graphs or "variables" should always be
available to the user
- what additions to the standard MIB would make the
manager's job easier
6.0
[1] Stockman, B., "A Model for Common Operational Statistics",
1404, NORDUnet/SUNET, January 1993.
Clark Informational [Page 15]
RFC 1856 Opstat Client-Server Model October 1995
Appendix A: Sample Client-Server
Session 1: Check available variables on device rtr1 interface eth
>LOGIN "henry" "skey
>AUTH "COW MOO DOG BARK CAT MEOW
<910 "Login OK, what now?"
>LIST OARnet rtr1 eth0 * * * *
<941 "List lookup OK, here it comes!"
<942 "List done!"
>
<990 "OK, Bye now!"
Session 2: Retrieve a bit of data from the
>LOGIN henryc "skey
>AUTH "COW MOO DOG BARK CAT MEOW
<910 "Login OK, what now?"
>SELECT OARnet rtr1 eth0 InBytes 15min 1993-02-01 00:00:00 1993-03-01 23:59:59
<920 "TAG blah
>
<931 "here it comes..."
<932 "all done
>GET blah 1404
<951 "here it comes..."
1404 data
<952 "wow, all done
>
<990 "OK, bye
Clark Informational [Page 16]
RFC 1856 Opstat Client-Server Model October 1995
Author's
Henry
BBN Planet Corp
150 Cambridge Park Dr
Cambridge, MA 02140
Phone: (617) 873-4622
EMail: henryc@bbnplanet.
Clark Informational [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
