diff options
Diffstat (limited to 'doc/rfc/rfc996.txt')
-rw-r--r-- | doc/rfc/rfc996.txt | 175 |
1 files changed, 175 insertions, 0 deletions
diff --git a/doc/rfc/rfc996.txt b/doc/rfc/rfc996.txt new file mode 100644 index 0000000..67a099f --- /dev/null +++ b/doc/rfc/rfc996.txt @@ -0,0 +1,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] + +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] + +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] + |