summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc996.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc996.txt')
-rw-r--r--doc/rfc/rfc996.txt175
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]
+