home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0996.txt < prev    next >
Text File  |  1996-05-07  |  6KB  |  103 lines

  1.  Network Working Group                                         D.L. Mills Request for Comments: 996                         University of Delaware                                                            February 1987 
  2.  
  3.                             Statistics Server 
  4.  
  5. STATUS OF THIS MEMO 
  6.  
  7.    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. 
  8.  
  9. DISCUSSION 
  10.  
  11.    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. 
  12.  
  13.    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. 
  14.  
  15.    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. 
  16.  
  17.    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, 
  18.  
  19.  
  20.  
  21. D. L. Mills                                                     [Page 1] 
  22.  RFC 996                                                    February 1987 
  23.  
  24.     commands and responses must fit into a single 576-octet IP datagram.    In both UDP and TCP the assigned port number is 133 (decimal). 
  25.  
  26.    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. 
  27.  
  28. EXAMPLE 
  29.  
  30.    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": 
  31.  
  32.         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 
  33.  
  34.    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. 
  35.  
  36. REFERENCES 
  37.  
  38.    [1]  Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network         Working Group Report IEN-131, Bolt Beranek and Newman, February         1980. 
  39.  
  40.    [2]  Flood Page, D., "The CMCC Terminal Process", DARPA Network         Working Group Report IEN-132, Bolt Beranek and Newman, February         1980. 
  41.  
  42.    [3]  Flood Page, D., "CMCC Performance Measurement Message Formats",         DARPA Network Working Group Report IEN-157, Bolt Beranek and         Newman, September 1980. 
  43.  
  44.    [4]  Jones, R.G., " A Proposal for Simple Measurement Support for         Users", DARPA Network Working Group Report IEN-161, University         College London, November 1980. 
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  D. L. Mills                                                     [Page 2] 
  51.  RFC 996                                                    February 1987 
  52.  
  53.     [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. 
  54.  
  55.    [6]  Hinden, R.M.," A Host Monitoring Protocol", DARPA Network         Working Group Report RFC-869, BBN Communications Corporation,         December 1983. 
  56.  
  57.    [7]  Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network         Working Group Report RFC-990, USC Information Sciences         Institute, November 1986. 
  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. D. L. Mills                                                     [Page 3] 
  102.  
  103.