RFC1856 日本語訳
1856 The Opstat Client-Server Model for Statistics Retrieval. H.Clark. September 1995. (Format: TXT=29954 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Clark Request For Comments: 1856 BBN Planet Category: Informational September 1995
Network Working Group H. Clark Request For Comments: 1856 BBN Planet Category: Informational September 1995
The Opstat Client-Server Model for Statistics Retrieval
The Opstat Client-Server Model for Statistics Retrieval
Status of this Memo
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.
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
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.
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
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.
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
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.
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
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).
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 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.
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.0 Client-Server Description
2.1 The Client
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.
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:
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
- 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).
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
Clark Informational [Page 2] RFC 1856 Opstat Client-Server Model October 1995
2.2 The Server
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 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.
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
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:
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
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.
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.
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
Clark Informational [Page 3] RFC 1856 Opstat Client-Server Model October 1995
3.1 Command Return Codes
3.1 Command Return Codes
The responses a server will return to a client are of the form:
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
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:
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
1 Error 9 Success / Informational
The commands are encoded as:
The commands are encoded as:
1 LOGIN
2 SELECT
3 STATUS
4 LIST
5 GET
9 EXIT
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:
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
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
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.
Other codes may be used, but may not be supported by all clients or servers.
3.2 The LOGIN Command
3.2 The LOGIN Command
The LOGIN command authenticates a user to the server. The format of the LOGIN command is:
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> "
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.
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).
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.
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, 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
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
Clark Informational [Page 5] RFC 1856 Opstat Client-Server Model October 1995
information returned in the AUTH response.
information returned in the AUTH response.
An example of an invalid authentication type requested:
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"
>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:
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"
>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:
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"
>LOGIN "cat" "password" <CHAL "send the dumb clear-text password" >AUTH "foobar" <910 "Login accepted"
or
or
>LOGIN "anonymous" "none"
<CHAL "tell me who you are anyway"
>AUTH "bessie@barn.farm.com"
<910 "Login accepted"
>LOGIN "anonymous" "none" <CHAL "tell me who you are anyway" >AUTH "bessie@barn.farm.com" <910 "Login accepted"
An example of a invalid username:
An example of a invalid username:
>LOGIN "mule" "skey"
<CHAL "78 lo39065"
>AUTH "COW DOG FRED LOG COLD WAR"
<110 "Login invalid"
>LOGIN "mule" "skey" <CHAL "78 lo39065" >AUTH "COW DOG FRED LOG COLD WAR" <110 "Login invalid"
The server should have some type of logging mechanism to record both successful and unsuccessful login attempts for a system adminstrator to peruse.
The server should have some type of logging mechanism to record both successful and unsuccessful login attempts for a system adminstrator to peruse.
Clark Informational [Page 6] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 6] RFC 1856 Opstat Client-Server Model October 1995
3.3 The EXIT Command
3.3 The EXIT Command
The EXIT command disconnects a current user from the server. The format of the EXIT command is:
The EXIT command disconnects a current user from the server. The format of the EXIT command is:
EXIT
EXIT
Note that upon reception of an EXIT command, the server must always close the connection, even if it would be appropriate to return an ERROR return code.
Note that upon reception of an EXIT command, the server must always close the connection, even if it would be appropriate to return an ERROR return code.
A sample EXIT command:
A sample EXIT command:
>EXIT
<990 "OK, Bye now"
>EXIT <990 "OK, Bye now"
3.4 The SELECT Command
3.4 The SELECT Command
The SELECT command is the function used to tag data for retrieval from the server. The SELECT command has the format:
The SELECT command is the function used to tag data for retrieval from the server. The SELECT command has the format:
SELECT-COM ::= SELECT <NETWORK> <DEVICE> <INTERFACE> <VARNAME>
<GRANULARITY> <START-DATE> <START-TIME> <END-DATE>
<END-TIME> <AGG> <SELECT-COND>
SELECT-COM ::= SELECT <NETWORK> <DEVICE> <INTERFACE> <VARNAME> <GRANULARITY> <START-DATE> <START-TIME> <END-DATE> <END-TIME> <AGG> <SELECT-COND>
NETWORK ::= <ASCII-STRING>
NETWORK ::= <ASCII-STRING>
DEVICE ::= <ASCII-STRING>
INTERFACE ::= <ASCII-STRING>
VARNAME ::= <ASCII-STRING>
GRANULARITY ::= <ASCII-STRING>
START-DATE ::= <DATE-TYPE>
END-DATE ::= <DATE-TYPE>
DATE-TYPE ::= YYYY-MM-YY
START-TIME ::= <TIME-TYPE>
END-TIME ::= <TIME-TYPE>
TIME-TYPE ::= HH:MM:SS
AGG ::= <AGG-TYPE> | NULL
AGG-TYPE ::= TOTAL | PEAK
SELECT-COND ::= <SELECT-STMT> | NULL
SELECT-STMT ::= WITH DATA <COND-TYPE> <ASCII-STRING>
COND-TYPE ::= LE | GE | EQ | NE | LT | GT
DEVICE ::= <ASCII-STRING> INTERFACE ::= <ASCII-STRING> VARNAME ::= <ASCII-STRING> GRANULARITY ::= <ASCII-STRING> START-DATE ::= <DATE-TYPE> END-DATE ::= <DATE-TYPE> DATE-TYPE ::= YYYY-MM-YY START-TIME ::= <TIME-TYPE> END-TIME ::= <TIME-TYPE> TIME-TYPE ::= HH:MM:SS AGG ::= <AGG-TYPE> | NULL AGG-TYPE ::= TOTAL | PEAK SELECT-COND ::= <SELECT-STMT> | NULL SELECT-STMT ::= WITH DATA <COND-TYPE> <ASCII-STRING> COND-TYPE ::= LE | GE | EQ | NE | LT | GT
If any conditional within the SELECT does not match existing data within the database (such as VARNAME, the S-DATE or E-DATE, or GRANULARITY), the server must return an ERROR (and hopefully a meaningful error message). The time values must be specified in GMT, and hours are specified in the range from 0-23. The granularity
If any conditional within the SELECT does not match existing data within the database (such as VARNAME, the S-DATE or E-DATE, or GRANULARITY), the server must return an ERROR (and hopefully a meaningful error message). The time values must be specified in GMT, and hours are specified in the range from 0-23. The granularity
Clark Informational [Page 7] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 7] RFC 1856 Opstat Client-Server Model October 1995
should always be specified in seconds. A sample query might be:
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
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.
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 be performed upon the data, then the aggregation field specifies how to perform the aggregration (i.e., total or peak) and the granularity specifies to what interval (in seconds) to agggregate the data to. For more details about the granularity types, see [1]. If the server cannot perform the requested action, then it must return a 120 error. The server may, if it wishes, use other error codes in the range 121-129 to convey more information about the specific error that occured. In either case, its recommended that the server return ASCII text describing the error.
Note that if the client requests some type of aggregation to be performed upon the data, then the aggregation field specifies how to perform the aggregration (i.e., total or peak) and the granularity specifies to what interval (in seconds) to agggregate the data to. For more details about the granularity types, see [1]. If the server cannot perform the requested action, then it must return a 120 error. The server may, if it wishes, use other error codes in the range 121-129 to convey more information about the specific error that occured. In either case, its recommended that the server return ASCII text describing the error.
Upon completion of the data lookup, the SELECT must return the an indication of whether the lookup was successful and (if the search was successful) the tag associated with that data. If the lookup was successful, then information in the return code should be encoded as:
Upon completion of the data lookup, the SELECT must return the an indication of whether the lookup was successful and (if the search was successful) the tag associated with that data. If the lookup was successful, then information in the return code should be encoded as:
920 " TAG <ASCII-STRING> "
920 " TAG <ASCII-STRING> "
In this case, the use of the word TAG is used as a handle for the selected data on the server. Note that this single handle may refer to one or more specific SNMP variables (refer to [1] for a further explanation).
In this case, the use of the word TAG is used as a handle for the selected data on the server. Note that this single handle may refer to one or more specific SNMP variables (refer to [1] for a further explanation).
For example, if the tag "foobar" were assigned to the select example above, then the OK would be as:
For example, if the tag "foobar" were assigned to the select example above, then the OK would be as:
920 "TAG foobar"
920 "TAG foobar"
It is recommended that the return tag string be less than 10 bytes long (this gives many tag combinations), although the server (and client) should be capable of handling arbitrary length strings. There is no requirement that the TAG have any particular meaning and may be composed of arbitrary strings.
It is recommended that the return tag string be less than 10 bytes long (this gives many tag combinations), although the server (and client) should be capable of handling arbitrary length strings. There is no requirement that the TAG have any particular meaning and may be composed of arbitrary strings.
The server must keep any internal information it needs during a session so that all SELECT tags can be processed by GET or other commands. If a server doesn't have the resources to process the given SELECT, it must return an error message.
The server must keep any internal information it needs during a session so that all SELECT tags can be processed by GET or other commands. If a server doesn't have the resources to process the given SELECT, it must return an error message.
Clark Informational [Page 8] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 8] RFC 1856 Opstat Client-Server Model October 1995
It is the responsibility of the client to store information about the data that a particular tag corresponds to, i.e., if the server had returned a tag "1234" for ifInOctet data for October 1993, then the client must store that information someplace as the variables which correspond to that tag cannot be retrieved from the server.
It is the responsibility of the client to store information about the data that a particular tag corresponds to, i.e., if the server had returned a tag "1234" for ifInOctet data for October 1993, then the client must store that information someplace as the variables which correspond to that tag cannot be retrieved from the server.
3.5 The STATUS Command
3.5 The STATUS Command
The STATUS command shows the general state of the server plus listing all data sets which have been tagged via the SELECT command. The STATUS command has no arguments. The output from a STATUS command is:
The STATUS command shows the general state of the server plus listing all data sets which have been tagged via the SELECT command. The STATUS command has no arguments. The output from a STATUS command is:
STATUS-DATA ::= <SERVER-STATUS> <SERVER-TAG-LIST>
SERVER-STATUS ::= "STATUS= " <STATUS-FIELDS>
STATUS-FIELDS ::= "OK" | "NOT-OK"
SERVER-TAG-LIST ::= <SERVER-TAG> | NULL
SERVER-TAG ::= "TAG" <TAG-ID> "SIZE" <NUMBER>
STATUS-DATA ::= <SERVER-STATUS> <SERVER-TAG-LIST> SERVER-STATUS ::= "STATUS= " <STATUS-FIELDS> STATUS-FIELDS ::= "OK" | "NOT-OK" SERVER-TAG-LIST ::= <SERVER-TAG> | NULL SERVER-TAG ::= "TAG" <TAG-ID> "SIZE" <NUMBER>
The number returned in the SIZE field represents the number of octets of data represented by the particular TAG. The server must return a 931 message before the STATUS output starts, and a 932 message at the 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 a message in the range of 131-139 if it wishes, but its recommended that the server always return ASCII describing the enoutered error. For example, a sample output might look like:
The number returned in the SIZE field represents the number of octets of data represented by the particular TAG. The server must return a 931 message before the STATUS output starts, and a 932 message at the 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 a message in the range of 131-139 if it wishes, but its recommended that the server always return ASCII describing the enoutered error. For example, a sample output might look like:
>STATUS
<931 "STATUS Command Starting"
<STATUS= OK
<TAG 1234 SIZE 123456
<TAG ABCD SIZE 654321
<932 "STATUS Command successful"
>STATUS <931 "STATUS Command Starting" <STATUS= OK <TAG 1234 SIZE 123456 <TAG ABCD SIZE 654321 <932 "STATUS Command successful"
or
or
>STATUS
<130 "Can't get STATUS right now, sorry."
>STATUS <130 "Can't get STATUS right now, sorry."
or
or
>STATUS
<931 "STATUS Command Starting"
<STATUS= OK
<TAG 1234 SIZE 1
<131 "Oops, error reading TAG table, sorry."
>STATUS <931 "STATUS Command Starting" <STATUS= OK <TAG 1234 SIZE 1 <131 "Oops, error reading TAG table, sorry."
Clark Informational [Page 9] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 9] RFC 1856 Opstat Client-Server Model October 1995
3.6 The GET Command
3.6 The GET Command
The GET command actually retrieves the data chosen via a previous SELECT command. The GET command has the format:
The GET command actually retrieves the data chosen via a previous SELECT command. The GET command has the format:
GET-CMD ::= GET <TAG> <TYPE>
TAG ::= <ASCII-STRING>
TYPE ::= 1404 | <ASCII-STRING>
GET-CMD ::= GET <TAG> <TYPE> TAG ::= <ASCII-STRING> TYPE ::= 1404 | <ASCII-STRING>
If the TAG matches a previously returned TAG from a SELECT statement, then the previously tagged data is returned. If the TAG is invalid (i.e., it hasn't been previously assigned by the server), then the server must return an error. The TYPE specifies the encoding of the data stream. All servers must support "1404" encoding. Others forms may be supported as desired.
If the TAG matches a previously returned TAG from a SELECT statement, then the previously tagged data is returned. If the TAG is invalid (i.e., it hasn't been previously assigned by the server), then the server must return an error. The TYPE specifies the encoding of the data stream. All servers must support "1404" encoding. Others forms may be supported as desired.
If the server, while retrieving the data, cannot retrieve some portion of the data (i.e., some of the data previously found 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 an encoding type not supported by the server, then the server must return a 151 error.
If the server, while retrieving the data, cannot retrieve some portion of the data (i.e., some of the data previously found 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 an encoding type not supported by the server, then the server must return a 151 error.
The format of the returned data is as follows:
The format of the returned data is as follows:
RETURN-DATA-TYPE ::= START-DATA <RETURN-TYPE> <DATA> END-DATA
RETURN-TYPE ::= 1404 | <ASCII-STRING>
RETURN-DATA-TYPE ::= START-DATA <RETURN-TYPE> <DATA> END-DATA RETURN-TYPE ::= 1404 | <ASCII-STRING>
An example would be:
An example would be:
>GET ABC 1404
<951 "OK, here it comes!"
<START-DATA 1404
>GET ABC 1404 <951 "OK, here it comes!" <START-DATA 1404
1404 data stream here...
1404 data stream here...
<END-DATA
<952 "All done!"
<END-DATA <952 "All done!"
Error examples:
Error examples:
>GET ABC STRONG-CRYPT
<151 "Sorry, that encoding not available here"
>GET ABC STRONG-CRYPT <151 "Sorry, that encoding not available here"
or
or
>GET ABC 1404
<951 "OK, here it comes!"
>GET ABC 1404 <951 "OK, here it comes!"
Clark Informational [Page 10] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 10] RFC 1856 Opstat Client-Server Model October 1995
<START-DATA 1404
<START-DATA 1404
1404 data stream here...
1404 data stream here...
<END-DATA
<150 "Whoa, bad data..."
<END-DATA <150 "Whoa, bad data..."
If any type of error code is returned by the server, the client must discard all data received from the server.
If any type of error code is returned by the server, the client must discard all data received from the server.
3.7 The LIST Command
3.7 The LIST Command
The LIST command allows the client to query the server about available data residing on the server. The LIST command has the format:
The LIST command allows the client to query the server about available data residing on the server. The LIST command has the format:
LIST-CMD ::= LIST <net> <dev> <intf> <var> <gran> <sdate> <stime>
<edate> <etime>
<net> ::= <ASCII-STRING> | *
<dev> ::= <ASCII-STRING> | *
<intf> ::= <ASCII-STRING> | *
<var> ::= <ASCII-STRING> | *
<gran> ::= <ASCII-STRING> | *
<sdate> ::= <DATE-TYPE> | *
<edate> ::= <DATE-TYPE> | *
<stime> ::= <TIME-TYPE> | *
<etime> ::= <TIME-TYPE> | *
LIST-CMD ::= LIST <net> <dev> <intf> <var> <gran> <sdate> <stime> <edate> <etime> <net> ::= <ASCII-STRING> | * <dev> ::= <ASCII-STRING> | * <intf> ::= <ASCII-STRING> | * <var> ::= <ASCII-STRING> | * <gran> ::= <ASCII-STRING> | * <sdate> ::= <DATE-TYPE> | * <edate> ::= <DATE-TYPE> | * <stime> ::= <TIME-TYPE> | * <etime> ::= <TIME-TYPE> | *
For example, to get a list of networks that the server has data for, you would use the command:
For example, to get a list of networks that the server has data for, you would use the command:
LIST * * * * * * * * *
LIST * * * * * * * * *
The command
The command
LIST netx rtry * * * * * * *
LIST netx rtry * * * * * * *
will list all interfaces for rtry. The command
will list all interfaces for rtry. The command
LIST netx rtry * ifInOctets * 1993-02-01 * * *
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 date of Februrary 1, 1993.
will get the list of interfaces on device "rtry" in network "netx" which have values for the variable "ifInOctets" after the start date of Februrary 1, 1993.
Clark Informational [Page 11] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 11] RFC 1856 Opstat Client-Server Model October 1995
To process wildcards in a LIST command, follow these rules:
To process wildcards in a LIST command, follow these rules:
1) Only the leftmost wildcard will be serviced for a given
LIST command
2) If all fields to the right of the leftmost wildcard are
wildcards, then all values for the wildcard being processed
will be returned.
3) If specific values are given for fields to the right of the
wildcard being serviced, then the specific values must match
a known value
1) Only the leftmost wildcard will be serviced for a given LIST command 2) If all fields to the right of the leftmost wildcard are wildcards, then all values for the wildcard being processed will be returned. 3) If specific values are given for fields to the right of the wildcard being serviced, then the specific values must match a known value
The output from the LIST command is formatted as follows:
The output from the LIST command is formatted as follows:
LIST-RETURN ::= START-LIST <LIST-ENTRY> END-LIST
LIST-ENTRY ::= <net> <device> <intf> <var> <gran> <sdate> <stime>
<edate> <etime>
<net> ::= <ASCII-STRING>
<device> ::= <ASCII-STRING> | <NULL>
<intf> ::= <ASCII-STRING> | <NULL>
<var> ::= <ASCII-STRING> | <NULL>
<gran> ::= <ASCII-STRING> | <NULL>
<sdate> ::= <DATE-TYPE> | <NULL>
<edate> ::= <DATE-TYPE> | <NULL>
<stime> ::= <TIME-TYPE> | <NULL>
<etime> ::= <TIME-TYPE> | <NULL>
LIST-RETURN ::= START-LIST <LIST-ENTRY> END-LIST LIST-ENTRY ::= <net> <device> <intf> <var> <gran> <sdate> <stime> <edate> <etime> <net> ::= <ASCII-STRING> <device> ::= <ASCII-STRING> | <NULL> <intf> ::= <ASCII-STRING> | <NULL> <var> ::= <ASCII-STRING> | <NULL> <gran> ::= <ASCII-STRING> | <NULL> <sdate> ::= <DATE-TYPE> | <NULL> <edate> ::= <DATE-TYPE> | <NULL> <stime> ::= <TIME-TYPE> | <NULL> <etime> ::= <TIME-TYPE> | <NULL>
Note that only the fields with values in them will be returned by the server. For example, the query to find the interfaces on rtry:
Note that only the fields with values in them will be returned by the server. For example, the query to find the interfaces on rtry:
>LIST netx rtry * * * * * * *
<941 "OK, here comes the list..."
<START-LIST
<netx rtry intf1
<netx rtry intf2
<netx rtry intf3
<END-LIST
<942 "all done"
>LIST netx rtry * * * * * * * <941 "OK, here comes the list..." <START-LIST <netx rtry intf1 <netx rtry intf2 <netx rtry intf3 <END-LIST <942 "all done"
The query to find interfaces having ifInOctets data with a 15 minute granularity:
The query to find interfaces having ifInOctets data with a 15 minute granularity:
>LIST netx rtry * ifInOctets 15min * * * *
<941 "OK, here comes the list..."
<START-LIST
<netx rtry intf1
<netx rtry intf2
<netx rtry intf3
<END-LIST
>LIST netx rtry * ifInOctets 15min * * * * <941 "OK, here comes the list..." <START-LIST <netx rtry intf1 <netx rtry intf2 <netx rtry intf3 <END-LIST
Clark Informational [Page 12] RFC 1856 Opstat Client-Server Model October 1995
Clark Informational [Page 12] RFC 1856 Opstat Client-Server Model October 1995
<942 "all done"
<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 server cannot process the LIST command (syntax error, etc.), then it must return a 141 message. For example:
If, while processing a LIST command, the server encounters an error, then the server must return a 140 error message. If the server cannot process the LIST command (syntax error, etc.), then it must return a 141 message. For example:
>LIST netx rtry
<141 "huh, bad list dude"
>LIST netx rtry <141 "huh, bad list dude"
or
or
>LIST netx rtry * ifInOctets 15min * * * *
<941 "OK, here comes the list..."
<START-LIST
<netx rtry intf1
<netx rtry intf2
<netx rtry intf3
<END-LIST
<140 "Whoa, bad list dude, please ignore"
>LIST netx rtry*ifInOctets15分****<941、「OK、リストはここに来ます」… <START-LIST<netx rtry intf1<netx rtry intf2<netx rtry intf3<END-LIST<140、「ワオ、悪いリスト奴をお願いします、無視、」
3.8 The Server State Machine
3.8 サーバ州のマシン
The state machine pictured below describes how a server should interact with a client:
以下に描写された州のマシンはサーバがどう対話するべきであるかをクライアントに説明します:
+------+
+-------->| WAIT |<-----+
| +------+ |
| New | |
| Connect | | LOGIN Failure
EXIT | \ / |
Received | +-------+ |
| | LOGIN |-----+
| +-------+
| |
| | LOGIN Successful
| \ /
| +---------+
+--------| PROCESS |<----+
+---------+ |
| | Process Commands
| |
+----------+
+------+ +-------->| 待ち| <、-、-、-、--+ | +------+ | | 新しい| | | 接続してください。| | ログイン失敗出口| \ / | 受信します。| +-------+ | | | ログイン|-----+ | +-------+ | | | | うまくいった状態で、ログインしてください。| \ / | +---------+ +--------| プロセス| <、-、-、--+ +---------+ | | | プロセスコマンド| | +----------+
Clark Informational [Page 13] RFC 1856 Opstat Client-Server Model October 1995
[13ページ]RFC1856Opstatクライアント・サーバモデル1995年10月の情報のクラーク
The server normally stays in WAIT (after starting and initialization) until a new connection is made from a client. The first command a client must issue is a LOGIN command, otherwise the server must immediately close the connection. If the login process fails in any way (as described in 3.2), then the server must immediately close the connection and return to the WAIT state.
新しい接続がクライアントから作られるまで、通常、サーバはWAIT(始めと初期化の後の)に残っています。 クライアントが発行しなければならない最初のコマンドがLOGINコマンドである、さもなければ、サーバはすぐに、接続を終えなければなりません。 ログインプロセスが何らかの方法で失敗するなら(3.2で説明されるように)、サーバは、すぐに、接続を終えて、WAIT状態に戻らなければなりません。
Once a successful LOGIN is received, the server enters the PROCESS state where it processes some number of LIST, GET, STATUS, and SELECT commands. Any other command received while in this state must be ignored, except for the EXIT command. Once an EXIT command is received, the server exits immediately (after perfoming any needed internal bookkeeping) and returns to the WAIT state. Any command a server receives while processing a command (e.g., if you send an "EXIT" while a large "GET" is being processed) will be ignored until the command being processed completes.
うまくいっているLOGINがいったん受け取られているようになると、サーバはそれが何らかの数のLIST、GET、STATUS、およびSELECTコマンドを処理するPROCESS状態に入ります。 EXITコマンドを除いて、この状態にある間に受け取られたいかなる他のコマンドも無視しなければなりません。 EXITコマンドがいったん受け取られているようになると、サーバは、すぐに(どんな必要な内部の簿記もperfomingした後に)、出て、WAIT状態に戻ります。 サーバがコマンドを処理している間に(例えば、大きい「得ること」が処理されている間、あなたが「出口」を送るなら)受け取るどんなコマンドも処理されるのが終了するコマンドまで無視されるでしょう。
If the data connection to the client closes for any reason while the server is in the PROCESS state, the server must immediately close its connection and do any associated internal cleanup and return to the LOGIN state.
サーバがPROCESS状態にありますが、クライアントとのデータ接続がどんな理由にも閉じるなら、サーバは、すぐに、接続を終えて、どんな関連内部のクリーンアップもして、LOGIN状態に戻らなければなりません。
4.0 Security Issues
4.0 セキュリティ問題
There are legal, ethical and political concerns of data sharing. For this reason there is a need to insure integrity and confidentiality of any shared data. Although not specified in this standard, mechanisms to control a user's access to specific data about specific objects may need to be included in server implementations. This could potentially be done in several ways, including a configuration file that listed the objects a user was allowed to access or limiting file access by using file permissions within a given file system. At a minimum, the server should not allow default access to all data on the server.
データ共有の法的で、倫理的で政治上の関心があります。 この理由で、どんな共有データの保全と秘密性も保障する必要があります。 この規格では指定されませんが、特定のオブジェクトに関する特定のデータへのユーザのアクセスを制御するメカニズムは、サーバ実装に含まれる必要があるかもしれません。 潜在的にいくつかの方法でこれができました、ユーザがアクセスできたオブジェクトを記載した構成ファイルを含んでいるか、または与えられたファイルシステムの中でファイル許容を使用することによってファイルアクセスを制限して。 最小限では、サーバはサーバに関するすべてのデータへのデフォルトアクセスを許すべきではありません。
Additionally, the server should strictly follow the state diagram shown in section 3.8. The server should be tested with arbitrary strings in the command fields to ensure that no unexpected security problems will be caused by the server. The server should specifically discard illegal ASCII characters as discussed in section 3.0. If the server executes other programs, then the server must verify that no unexpected side-effects will occur as the result of the invocation or the arguments given to that program. The server should always verify that all data is contained within the input buffer, and that a long input string from a client will not cause unexpected side-effects.
さらに、サーバは厳密にセクション3.8で見せられた州のダイヤグラムに従うべきです。 任意のストリングがコマンド欄にある状態で、サーバは、どんな予期していなかった警備上の問題もサーバによって引き起こされないのを保証するために検査されるべきです。サーバはセクション3.0で議論するように明確に不法なASCII文字を捨てるべきです。 サーバが他のプログラムを実行するなら、サーバは、どんな予期していなかった副作用も実施の結果かそのプログラムに与えられた議論として起こらないことを確かめなければなりません。 サーバは、いつもすべてのデータが入力バッファの中に含まれていて、クライアントからの長い入力ストリングが予期していなかった副作用を引き起こさないことを確かめるべきです。
Clark Informational [Page 14] RFC 1856 Opstat Client-Server Model October 1995
[14ページ]RFC1856Opstatクライアント・サーバモデル1995年10月の情報のクラーク
Finally, given the relative insecurity of the global Internet, and the presence of packet-sniffing capability, several considerations must be weighed. The authentication process via the LOGIN process must be strictly adhered to, and the use of one-time authentication is strongly encouraged. It is also suggested that the data returned from the server be protected (such as through encryption) so that no sensitive data is revealed by accident.
最終的に、世界的なインターネットの相対的な不安定、およびパケットをかぐ能力の存在を考えて、いくつかの問題を熟慮しなければなりません。 厳密にLOGINプロセスを通した認証過程を固く守らなければなりません、そして、1回の認証の使用は強く奨励されます。 また、サーバから返されたデータが保護されることが(暗号化でそのような)提案されるので、極秘データは全く偶然に明らかにされません。
5.0 Summary
5.0 概要
This document defines a protocol which could be used in a client- server relationship to retrieve statistics from a remote database server.
このドキュメントはリモートデータベースサーバから統計を検索するのにクライアントサーバ関係に使用できたプロトコルを定義します。
Much work remains to be done in the area of Operational Statistics including questions such as:
多くの仕事が、以下などの質問を含むOperational Statisticsの領域でするために残っています。
- what "standard" graphs or "variables" should always be made
available to the user?
- what additions to the standard MIB would make the network
manager's job easier?
- いつもどんな「標準」のグラフか「変数」をユーザにとって利用可能にするべきですか? - 標準のMIBへのどんな追加で、ネットワークマネージャの仕事は、より簡単になるでしょうか?
6.0 References
6.0の参照箇所
[1] Stockman, B., "A Model for Common Operational Statistics", RFC
1404, NORDUnet/SUNET, January 1993.
[1] 牧畜業者、B.、「一般的な操作上の統計のためのモデル」、RFC1404、NORDUnet/SUNET、1993年1月。
Clark Informational [Page 15] RFC 1856 Opstat Client-Server Model October 1995
[15ページ]RFC1856Opstatクライアント・サーバモデル1995年10月の情報のクラーク
Appendix A: Sample Client-Server Sessions
付録A: サンプルクライアント/サーバセッション
Session 1: Check available variables on device rtr1 interface eth0
セッション1: デバイスrtr1インタフェースeth0で利用可能な変数をチェックしてください。
>LOGIN "henry" "skey"
<CHAL "78 lo35098"
>AUTH "COW MOO DOG BARK CAT MEOW"
<910 "Login OK, what now?"
>LIST OARnet rtr1 eth0 * * * *
<941 "List lookup OK, here it comes!"
<START-LIST
<OARnet rtr1 eth0 ifInOctets
<OARnet rtr1 eth0 ifOutOctets
<OARnet rtr1 eth0 ifInErrors
<OARnet rtr1 eth0 ifOutErrors
<END-LIST
<942 "List done!"
>EXIT
<990 "OK, Bye now!"
>LOGIN"henry""skey"<CHAL「78lo35098」>AUTH「牛のもー犬の樹皮猫ネコの鳴き声」<910、「Login OK、どんな現在?」 >LIST OARnet rtr1 eth0****<、941 「ルックアップOKをリストアップしてください、そして、ここに、来ます!」 <START-LIST<OARnet rtr1 eth0 ifInOctets<OARnet rtr1 eth0 ifOutOctets<OARnet rtr1 eth0 ifInErrors<OARnet rtr1 eth0 ifOutErrors<END-LIST<942、「行われたリスト!」 >EXIT<、990 「OK、現在のBye!」
Session 2: Retrieve a bit of data from the server
セッション2: サーバからの少しのデータを検索してください。
>LOGIN henryc "skey"
<CHAL "78 lo35098"
>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"
>STATUS
<931 "here it comes..."
<STATUS= OK
<TAG blah SIZE 654321
<932 "all done"
>GET blah 1404
<951 "here it comes..."
<START-DATA 1404
>LOGIN henryc"skey"<CHAL「78lo35098」>AUTH「牛のもー犬の樹皮猫ネコの鳴き声」<910、「Login OK、どんな現在?」 >のSELECT OARnet rtr1 eth0 InBytesの00:00:00 1993年3月1日の15分の1993年2月1日の23:59:59<920「TAGたわごと」>STATUS<931、「ここに、来ます」… <STATUSはOK<TAGたわごとSIZE654321<932「すべてした」>GETたわごと1404<951と等しいです。「ここに、来ます」… <スタートデータ1404
1404 data here
ここの1404のデータ
<END-DATA
<952 "wow, all done"
>EXIT
<990 "OK, bye"
<END-DATA<952「ワオ、行われたすべて」>EXIT<990「OK、さようなら」
Clark Informational [Page 16] RFC 1856 Opstat Client-Server Model October 1995
[16ページ]RFC1856Opstatクライアント・サーバモデル1995年10月の情報のクラーク
Author's Address
作者のアドレス
Henry Clark BBN Planet Corp. 150 Cambridge Park Dr. Cambridge, MA 02140
ケンブリッジ、ヘンリークラークBBN惑星社150ケンブリッジPark博士MA 02140
Phone: (617) 873-4622 EMail: henryc@bbnplanet.com
以下に電話をしてください。 (617) 873-4622 メールしてください: henryc@bbnplanet.com
Clark Informational [Page 17]
クラークInformationalです。[17ページ]
一覧
スポンサーリンク
