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