NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Gregory Ruth <gruth@gte.com>
Nevil Brownlee <n.brownlee@auckland.ac.nz>
Sig Handelman <handel@watson.ibm.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion: rtfm@auckland.ac.nz
To Subscribe: majordomo@auckland.ac.nz
In Body: subscribe rtfm your-email-address
Archive: ftp://ftp.auckland.ac.nz/pub/rtfm/archive
Description of Working Group:
This working group has three main objectives:
* Consider current issues in traffic flow measurement, such as
- Security issues relating to both traffic measuring devices and to the data they produce.
- Policy issues relating to traffic measurement and usage accounting, for example any requirements these may place on emerging network protocols
- Existing work in traffic flow measurement, including that of IETF Working Groups such as bmwg/ippm, rsvp and rmonmib, as well as that by vendors and independent researchers
* Produce an improved Traffic Flow Model considering at least the following needs:
- wider range of measurable quantities, e.g. those relating to IPv6, and to class of service - simpler ways to specify flows of interest - better ways to control access to measured flow data - strong focus on data reduction capabilities - efficient hardware implementation
* Develop the RTFM Architecture and Meter MIB as 'standards track' documents with the IETF.
Goals and Milestones:
Feb 96 |
|
Submit set of revised Internet-Drafts and of RFC1272 to the IESG for consideration as Experimental Protocols. |
Mar 96 |
|
Produce outline for 'New Traffic Flow Model' document |
Jul 96 |
|
Submit 'New Traffic Flow Model' document as an Internet-Draft, and begin working on an implementation document. |
Jul 96 |
|
Submit Internet-Draft on Flow Meter MIB. |
Nov 96 |
|
Submit Implementation document as an Internet-Draft. |
Nov 96 |
|
Submit 'New Traffic Flow Model' to the IESG to be considered for publication as an RFC. |
Mar 97 |
|
Submit Implementation Internet-Draft to the IESG to be considered for publication as an RFC. |
Jul 97 |
|
Submit Meter MIB I-D to IESG for consideration as Proposed |
Aug 97 |
|
Publish revised and extended I-D on 'New Attributes' |
Aug 97 |
|
Publish revised 'Architecture' I-D to cover new attributes |
Dec 97 |
|
Submit I-Ds on 'New Attributes' and 'Architecture' for consideration as Proposed Standards |
Internet-Drafts:
· RTFM Working Group - New Attributes for Traffic Flow Measurement
· Traffic Flow Measurement: Meter MIB
· Traffic Flow Measurement: Architecture
Request For Comments:
RFC |
Status |
Title |
RFC2064 |
E |
Traffic Flow Measurement: Meter MIB |
RFC2063 |
E |
Traffic Flow Measurement: Architecture |
RFC2123 |
Traffic Flow Measurement: Experiences with NeTraMet | |
Minutes of the RTFM Working Group Meeting
Reported by Greg Ruth and Stephen Stibler
The WG's new charter, which has been approved by IESG, was reviewed. It is very much the same as the old one, but with a much stronger emphasis on security. A new goal of the WG is to share our experience with traffic measurement and accounting with other groups.
Nevil Brownlee reported on the current state of NeTraMet. A new release has been available in beta since May 1997. It implements all the features of our current MIB draft, and NeMaC (NeTraMet's manager) provides much better checking for invalid rule sets. The PC version of the meter uses 32-bit addressing, greatly increasing the number of flows it can handle. Nevil is working on a NeTraMet front-end for Cisco NetFlow data.
Sig Handelman reported briefly on the state of the IBM Meter implementation. Since the last IETF, they have implemented the current MIB and are testing several new attributes.
There were three short presentations of work in traffic flow measurement:
· Siegfried Loeffler described "Fluid," a Java version of Nifty (an X-windows analysis program distributed with NeTraMet). This uses Java SNMP classes from Advent Networks, together with their Secure Applet Server (which runs on the Web server and serves as a proxy to allow other hosts to do SNMP interactions with an SNMP agent, in this case a NeTraMet meter). Fluid displays the current traffic on the network in real time inside a Web Browser. It reads about 300 flow records in 10 seconds, which is fast enough for it to be a useful tool for overseeing a network. Siegfried would like to see other people continue this work. A URL for Fluid is http://www. mathematik.uni-stuttgart.de/~floeff/diplom/ietfslides/index.htm
· Nevil presented a set of slides from Massimiliano Cansona at Cefriel in Italy. These describe work done by Matteo Snidero on measuring RSVP-controlled flows. He has produced a program that uses RSVP request packets to build up a matrix of information about RSVP sessions. Whenever this table changes the program writes a NeTraMet rule set which is downloaded to a NeTraMet meter. The meter has been extended with two new attributes - IsRSVP and FlowTokenBucketRate. These are set by the rules for flows with RSVP reservations, and collected by a meter reader along with the measured packet and byte counts. This allows an analysis application to see how actual usage compares with the RSVP request. This work is being continued at Cefriel; their URL is http://www.cefriel.it/ntw.
Sig presented a set of slides from John Stewart and John Robinson in Ottawa. They have produced MultiMON, an IP multicast monitor, and have released version 1.1 to the community for testing. MultiMON allows one to see (on a pie chart) what types of multicast traffic are running. It allows one to join and monitor multicast conferences, and will produce plots indicating how RTCP streams are performing. This work is continuing; we hope it will prove useful to RTFM as we strive to produce extended attributes for multicast. MultiMON's URL is http://www.merci.crc.doc.ca/mbone/MultiMON.
The current Meter MIB draft contains the corrections discussed in Memphis. A final version, with minor editorial changes, will be published shortly. This will go to WG last call, before being submitted to IESG for publication as a Proposed Standard RFC.
To complement the new Meter MIB we need to revise the Architecture RFC. Nevil summarized the changes needed, and pointed out that, apart from a proper 'Security Considerations' section, only very small changes are needed. After further discussion, the WG agreed that the editors would produce a list of proposed changes for discussion on the mailing list, then publish a new 'Architecture' Draft. This will be followed by a WG last call, leading to submission as a Proposed Standard.
The latest 'New Attributes' draft was discussed; this has been extended to include a method of implementing 'distribution-valued' attributes, proposes ten such attributes, i.e., To/From Packet Size, InterArrival Time, Turnaround Time, Byte- and Packet-Rate. Nevil gave a brief presentation on implementation experience with these.
The numbering of attributes was discussed; we propose to reserve 1..63 for 'Basic Meter' attributes, 65..127 for 'Extended' attributes, and 129..255 for 'Experimental' (user-defined) attributes. It was pointed out that it should be possible to determine which attributes are implemented on a meter.
Attributes derived from TCP headers were discussed; we need a small group of TCP wizards to consider this and send a proposal to the mailing list.
Security-related attributes were discussed. It would be useful to count the number of different values appearing in RTFM attributes (e.g., destination port numbers for specified source/destination peer address pairs). This will be investigated.
The WG's Goals and Milestones were reviewed, but do not need changing at this time.
Measuring Distributions with NeTraMet
"Fluid" - A Java Version of Nifty
RTFM - RSVP Reserved Quality IP Traffic Accounting