1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Network Working Group D.L. Mills
Request for Comments: 996 University of Delaware
February 1987
Statistics Server
STATUS OF THIS MEMO
This RFC specifies a standard for the ARPA Internet community. Hosts
and gateways on the DARPA Internet that choose to implement a remote
statistics monitoring facility may use this protocol to send
statistics data upon request to a monitoring center or debugging
host. Distribution of this memo is unlimited.
DISCUSSION
Many host and gateway implementations include a facility which
records traffic statistics, such as packet counters, error counters
and significant event counters for debugging and performance
evluation. Simple data-access and formatting programs can be used to
display these statistics along with the status of connections, etc.
Several operating systems, including the various Unix systems and
Fuzzball systems, already provide extensive facilities to capture and
display these data for local users and/or operators.
In many instances it is highly useful to observe statistics data on
remote hosts and gateways from a monitoring center or debugging host.
Indeed, several protocols have been implemented and used expressly
for this purpose [1-6]. In many cases the data can be retrieved using
conventional services such as remote login or even file transfer.
However, use of these heavyweight mechanisms is awkward and intrusive
if conducted on a regular, frequent basis and may involve substantial
intrusion in the operating system if retrofitted to existing systems.
The Statistics Server (STATSRV) protocol is intended as a lightweight
mechanism similar in spirit to NETSTAT [7] and complementary to it.
STATSRV is designed to capture statistics data with minimal intrusion
on existing systems or networks. It is intended for use with existing
hosts and gateways primarily for casual monitoring and debugging
purposes. It is not intended as a full-function monitoring protocol
[1,5,6] providing detailed, standardized reports suitable for machine
analysis, for example, but could be useful in exploratory development
leading to enduring systems of this type.
The STATSRV model is based on the native host command language used
for statistics monitoring and display. The client sends a null-
terminated ASCII command to the server, which then responds with a
null-terminated ASCII response suitable for a printer or CRT display.
Although in principle STATSRV could be used over TCP, it is less
intrusive and more efficient to use it over UDP. In the case of UDP,
D. L. Mills [Page 1]
^L
RFC 996 February 1987
commands and responses must fit into a single 576-octet IP datagram.
In both UDP and TCP the assigned port number is 133 (decimal).
As is conventional in other lightweight services of this type
(NETSTAT, FINGER, etc.), there is no provision for access control or
authentication in STATSRV. If necessary, each command could include a
password or other mechanism to discourage casual abuse.
EXAMPLE
The Fuzzball system includes many local commands to display internal
data structures, including one that produces the following billboard
for each network device, in this case "dm0" on host "udel2.udel.edu":
Process type: 000027 options: 040000
Subnet: DMV status: 376 hello: 15 timeout: 2000
Foreign address: [192.5.39.87] max size: 576
Input packets 3645 Output packets 3690
bad format 0 ICMP msgs 0
bad checksum 0 Input errors 0
returned 0 Output errors 0
dropped 2 No buffer 0
HELLO msgs 2286 Preempted 0
The same billboard is returned as a null-terminated ASCII string in a
UDP datagram by sending the null-terminated ASCII command "dm0" in a
UDP datagram to the host. Similar billboards can be produced for most
processes in the system. Unix programs and shell scripts have been
built which send commands like these to selected hosts on a periodic
basis in order to construct a simple, ad-hoc monitoring facility.
REFERENCES
[1] Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network
Working Group Report IEN-131, Bolt Beranek and Newman, February
1980.
[2] Flood Page, D., "The CMCC Terminal Process", DARPA Network
Working Group Report IEN-132, Bolt Beranek and Newman, February
1980.
[3] Flood Page, D., "CMCC Performance Measurement Message Formats",
DARPA Network Working Group Report IEN-157, Bolt Beranek and
Newman, September 1980.
[4] Jones, R.G., " A Proposal for Simple Measurement Support for
Users", DARPA Network Working Group Report IEN-161, University
College London, November 1980.
D. L. Mills [Page 2]
^L
RFC 996 February 1987
[5] Littauer, B.M., A.J. Huang and R.M. Hinden," A Host Monitoring
Protocol", DARPA Network Working Group Report IEN-197, Bolt
Beranek and Newman, September 1981.
[6] Hinden, R.M.," A Host Monitoring Protocol", DARPA Network
Working Group Report RFC-869, BBN Communications Corporation,
December 1983.
[7] Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network
Working Group Report RFC-990, USC Information Sciences
Institute, November 1986.
D. L. Mills [Page 3]
^L
|
