home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rtfm / rtfm-minutes-97aug.txt < prev    next >
Text File  |  1997-10-10  |  5KB  |  100 lines
  1. Minutes of the RTFM Working Group, Munich, Thursday 14 August 97
  2.  
  3. Reported by Greg Ruth and Stephen Stibler
  4.  
  5. The WG's new charter (which has been approved by IESG) was reviewed; it
  6. is very much the same as the old one, but with a much stronger emphasis
  7. on security.  A new goal of the WG is to share our experience with traffic
  8. measurement and accounting with other groups.
  9.  
  10. Nevil Brownlee reported on the current state of NeTraMet.  A new
  11. release has been available in beta since May 97.  It implements all the
  12. features of our current MIB draft, and NeMaC (NeTraMet's manager)
  13. provides much better checking for invalid rule sets.  The PC version of
  14. the meter uses 32-bit addressing, greatly increasing the number of
  15. flows it can handle.  Nevil is working on a NeTraMet front-end for
  16. Cisco NetFlow data.
  17.  
  18. Sig Handelman reported briefly on the state of the IBM Meter
  19. implementation.  Since last IETF they have implemented the current MIB
  20. and are testing several new attributes.
  21.  
  22. There were three short presentations of work in traffic flow
  23. measurement:
  24.  
  25.  * Siegfried Loeffler described "Fluid," a Java version of Nifty (an
  26.    X-windows analysis program distributed with NeTraMet).  This uses 
  27.    Java SNMP classes from Advent Networks, together with their Secure
  28.    Applet Server (which runs on the Web server and serves as a proxy 
  29.    to allow other hosts to do SNMP interactions with an SNMP agent,
  30.    in this case a NeTraMet meter).  Fluid displays the current traffic
  31.    on the network in real time inside a Web Browser.  It reads about
  32.    300 flow records in 10 seconds, which is fast enough for it to be
  33.    a useful tool for overseeing a network.  Siegfried would like to
  34.    see other people continue this work. A URL for Fluid is http://www.
  35.    mathematik.uni-stuttgart.de/~floeff/diplom/ietfslides/index.htm
  36.    
  37.  * Nevil presented a set of slides from Massimiliano Cansona at Cefriel
  38.    in Italy.  These describe work done by Matteo Snidero on measuring
  39.    RSVP-controlled flows.  He has produced a program which uses RSVP
  40.    request packets to build up a matrix of information about RSVP
  41.    sessions.  Whenever this table changes the program writes a NeTraMet
  42.    rule set which is downloaded to a NeTraMet meter.  The meter has
  43.    been extended with two new attributes - IsRSVP and 
  44.    FlowTokenBucketRate.  These are set by the rules for flows with RSVP
  45.    reservations, and collected by a meter reader along with the 
  46.    measured packet and byte counts.  This allows an analysis
  47.    application to see how actual usage compares with the RSVP request.
  48.    This work is being continued at Cefriel; their URL is
  49.    http://www.cefriel.it/ntw.
  50.    
  51.  * Sig presented a set of slides from John Stewart and John Robinson
  52.    in Ottawa.  They have produced MultiMON, an IP multicast monitor,
  53.    and have released version 1.1 to the community for testing.
  54.    MultiMON allows one to see (on a pie chart) what types of multicast
  55.    traffic are running.  It allows one to join and monitor multicast
  56.    conferences, and will produce plots indicating how RTCP streams are
  57.    performing.  This work is continuing; we hope it will prove useful
  58.    to RTFM as we strive to produce extended attributes for multicast.   
  59.    MultiMON's URL is http://www.merci.crc.doc.ca/mbone/MultiMON.
  60.     
  61. The current Meter MIB draft contains the corrections discussed in
  62. Memphis.  A final version (with minor editorial changes) will be
  63. published shortly.  This will go to WG last call, before being
  64. submitted to IESG for publication as a Proposed Standard RFC.
  65.  
  66. To complement the new Meter MIB we need to revise the Architecture RFC.
  67. Nevil summarised the changes needed, and pointed out that - apart from
  68. a proper 'Security Considerations' section - only very small changes
  69. are needed.  After further discussion, the WG agreed that the editors
  70. will produce a list of proposed changes for discussion on the mailing
  71. list, then publish a new 'Architecture' Draft.  This will be followed
  72. by a WG last call, leading to submission as a Proposed Standard.
  73.  
  74. The latest 'New Attributes' draft was discussed; this has been extended
  75. to include a method of implementing 'distribution-valued' attributes,
  76. proposes ten such attributes, i.e. To/From Packet Size, InterArrival
  77. Time, Turnaround Time, Byte- and Packet-Rate.  Nevil gave a brief
  78. presentation on implementation experience with these.
  79.  
  80. The numbering of attributes was discussed; we propose to reserve 1..63
  81. for 'Basic Meter' attributes, 65..127 for 'Extended' attributes, and
  82. 129..255 for 'Experimental' (user-defined) attributes.  It was pointed
  83. out that it should be possible to determine which attributes are
  84. implemented on a meter.
  85.  
  86. Attributes derived from TCP headers were discussed; we need a
  87. small group of TCP wizards to consider this and send a proposal to the
  88. mailing list.
  89.  
  90. Security-related attributes were discussed.  It would be useful to
  91. count the number of different values appearing in RTFM attributes
  92. (e.g. destination port numbers for specified source/destination
  93. peer address pairs); this will be investigated.
  94.  
  95. The WG's Goals and Milestones were reviewed, but do not need changing
  96. at this time.
  97.  
  98.  
  99.  
  100.