idnits 2.17.1 draft-ietf-rtfm-new-traffic-flow-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 28 has weird spacing: '... Drafts are ...' == Line 33 has weird spacing: '... please check...' == Line 35 has weird spacing: '...ctories on f...' == Line 40 has weird spacing: '... does not ...' == Line 100 has weird spacing: '...he time when ...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 1998) is 9593 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 559 looks like a reference -- Missing reference section? '5' on line 571 looks like a reference -- Missing reference section? '4' on line 567 looks like a reference -- Missing reference section? '2' on line 562 looks like a reference -- Missing reference section? '3' on line 564 looks like a reference -- Missing reference section? '6' on line 574 looks like a reference -- Missing reference section? '7' on line 577 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Real Time Flow Measurement Working Group S.W. Handelman 3 Internet-draft IBM 4 Hawthorne, NY USA 6 Nevil Brownlee 7 U of Auckland, NZ 9 Greg Ruth 10 GTE Laboratories, Inc 11 Waltham, MA USA 13 July 20, 1997 14 expires 15 January 20, 1998 17 RTFM Working Group - New Attributes for Traffic Flow Measurement 19 21 1. Status of this Memo 23 This document is an Internet Draft. Internet Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet Drafts. 28 Internet Drafts are draft documents valid for a maximum of six 29 months, and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet Drafts as reference 31 material or to cite them other than as "work in progress". 33 To learn the current status of any Internet Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 35 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 37 ftp.isi.edu (US West Coast). 39 This memo provides information for the Internet community. This memo 40 does not specify an Internet standard of any kind. Distribution of 41 this memo is unlimited. 43 2. Introduction 45 The Real-time Traffic Flow Measurement (RTFM) Working Group has 46 developed a system for measuring and reporting information about 47 traffic flows in the Internet. This document explores the definition 48 of extensions to the flow measurements as currently defined in [1] 49 and [5]. The new attributes described in this document will be 50 useful for monitoring network performance and expand the scope of 51 RTFM beyond simple measurement of traffic rates. Performance 52 attributes typically deal with throughput, packet loss, and delays. 53 We will explore the methods by which RTFM can extract values from 54 flows so as to measure these attributes. We will also look at 55 capturing information on jitter and congestion control. 57 The RTFM Working Group has defined the concept of a standardized 58 meter which records flows from a traffic stream according to Rule 59 Sets which are active in the meter[1]. 61 Implementations of this meter have been done by Nevil Brownlee in the 62 University of Auckland, NZ, and Stephen Stibler and Sig Handelman at 63 IBM in Hawthorne, NY, USA. The RTFM WG has also defined the Meter 64 Reader Program whose job is to fetch flow data from the Meter. 66 2.1 RTFM's Definition of Flows 68 The RTFM Meter architecture views a flow as a set of packets between 69 two end-points (as defined by their source and destination attribute 70 values), and as BI-DIRECTIONAL (i.e. the meter effectively monitors 71 two sub-flows, one in each direction). 73 Reasons why RTFM flows are bi-directional: 75 - We are interested in understanding the behavior of sessions between 76 end-points. 78 - We want to perform as much data reduction as possible, so as to 79 reduce the amount of data to be retrieved from a remote meter. 81 - The endpoint attribute values (the "Address" and "Type" ones) are 82 the same for both directions; storing them in bi-directional flows 83 reduces the meter's memory demands. 85 2.2 RTFM's Current Definition of Flows and their Attributes 87 Flows, as described in the "Architecture" document [1] have the 88 following properties: 90 a. They occur between two endpoints, specified as sets of attribute 91 values in the meter's current rule set. A flow is completely 92 identified by its set of endpoint attribute values. 94 b. Each flow may also have values for "computed" attributes (Class 95 and Kind). These are directly derived from the endpoint attribute 96 values. 98 c. A new flow is created when a packet is to be counted which is not 99 classified by the Rule Set into an existing flow. The meter records 100 the time when this new flow is created. 102 d. Attribute values in (a), (b) and (c) are set when the meter sees 103 the first packet for the flow, and are never changed. 105 e. Each flow has a "LastTime" attribute, which indicates the time the 106 meter last saw a packet for the flow. 108 f. Each flow has two packet and byte counters, one for each flow 109 direction (Forward and Backward). These are updated as packets are 110 observed by the meter. 112 g. ALL the attributes have (more or less) the same meaning for a 113 variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as 114 TCP/IP. 116 Current flow attributes - as described above - fit very well into the 117 SNMP data model. They are either static, or are continuously updated 118 counters. They are NEVER reset. In this document they will be 119 referred to as "old-style" attributes. 121 It is easy to add further "old-style" attributes, since they don't 122 require any new features in the architecture. For example: 124 - Count of the number of "lost" packets (determined by watching 125 sequence number fields for packets in each direction; only available 126 for protocols which have sequence numbers). 128 - In the future, RTFM could coordinate directly with the Flow number 129 from the IPv6 header. 131 At the June, 1996 meeting of the RTFM WG in Montreal, Canada, a 132 proposal was made to extend the work of the group to produce an 133 Internet Draft "New Attributes for Traffic Flow Measurement". That 134 proposal has brought forth this document. The goal of this work is to 135 produce a simple set of abstractions, which can be easily implemented 136 and at the same time enhance the value of RTFM meters. This document 137 also defines a method for organizing the flow abstractions to 138 preserve the existing RTFM flow table. 140 2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 142 The concept of flows has been studied in various different contexts. 143 For the purpose of extending RTFM, a starting point is the work of 144 the Integrated Services WG. We will measure quantities that are often 145 set by Integrated Services configuration programs. We will look at 146 the work of the Benchmarking / IP Performance Metrics Working Group, 147 and also look at the work of Claffy, Braun and Polyzos [4]. We will 148 demonstrate how RTFM can compute throughput, packet loss, and delays 149 from flows. An example of the use of capacity and performance 150 information is found in "The Use of RSVP with IETF Integrated 151 Services" [2]. RSVP's use of Integrated Services revolves around 152 Token Bucket Rate, Token Bucket Size, Peak Data Rate, Minimum Policed 153 Unit, Maximum Packet Size, and the Slack term. These are set by 154 TSpec, ADspec and FLowspec (Integrated Services Keywords), and are 155 used in configuration and operation of Integrated Services. RTFM 156 could monitor explicitly Peak Data Rate, Minimum Policed Unit, 157 Maximum Packet Size, and the Slack term. RTFM could infer details of 158 the Token Bucket. We will develop measures to work with these service 159 metrics. 161 RTFM will work with several traffic measurements identified by IPPM 162 [3]. There are three broad areas in which RTFM is useful for IPPM. 163 An RTFM meter could act as a passive device that, gathering traffic 164 and performance statistics at appropriate places in TCP/IP networks 165 (server or client locations). RTFM could give detailed analyses of 166 IPPM test flows that pass through the Network segment that RTFM is 167 monitoring. RTFM could be used to identify the most-used paths in a 168 network mesh, so that detailed IPPM work could be applied to the most 169 used paths. 171 3.0 Flow Abstractions 173 Performance attributes include throughput, packet loss, delays, 174 jitter, and congestion measures. RTFM will calculate these attributes 175 in the form of extensions to the RTFM flow attributes according to 176 three general classes: 177 o 'packet traces' - collections of individual packets in a flow or a 178 segment of a flow 179 o 'aggregates' - statistics derived from the flow taken as a whole 180 (e.g. mean rate, max packet size). 181 o 'series'- attributes that depend on more than one packet (e.g. 182 inter-arrival times, short-term traffic rates). 184 The following sections suggest implementations for each of these 185 classes of extensions. 187 As an introduction to flow abstractions one fact must be emphasized. 188 Several of the measurements enumerated below can be implemented by a 189 Meter Reader that is tied to the meter with instantaneous response 190 and very high bandwidth. If the Meter Reader and Meter can be 191 arranged in such a way, RTFM could collect Packet Traces with time 192 stamps and provide them to the Meter Reader for further processing. 194 A more useful alternative is to have the meter calculate some flow 195 statistics locally. This allows a looser coupling between the meter 196 and Meter Reader. RTFM will create an 'extended attribute' depending 197 upon settings in its Rule table. RTFM will not create any "extended 198 attribute" data without explicit instructions in the Rule table. 200 3.1. Attrubute Types 202 The previous section described three different classes of attribute; 203 this section considers what the types of these attributes could be. 205 Packet Traces (as described below) are a special case in that they 206 are tables with each row containing a sequence of values, each of 207 varying type. They are essentially 'compound objects,' and will not 208 be considered further here. 210 Aggregate attributes are like the 'old-style' ones. Their types are 212 - Addresses, represented as byte strings (1 to 20 bytes long) 214 - Counters, represented as 64-bit unsigned integers 216 - Times, represented as 32-bit unsigned integers 218 Addresses are set when the first packet of a flow is observed. They 219 do not change with time, and they are used as a key to find the 220 flow's entry in the meter's flow table. 222 Counters are incremented for each packet, and are never reset. An 223 analysis application can compute differences between readings of the 224 counters, so as to determine rates for these attributes. For 225 example, if we read flow data at five-minute intervals, we can 226 calculate five-minute packet and byte rates for the flow's two 227 directions. 229 Times - the FirstTime for a flow is set when its first packet is 230 observed. LastTime is updated for every packet of the flow. 232 All the above types have the common feature that they are expressed 233 as single values. At least some of the new attributes will require 234 multiple values. If, for example, we are interested in inter-packet 235 time intervals, we can compute an interval for every packet after 236 the first. If we are interested in packet sizes, a new value is 237 produced as each packet arrives. When it comes to storing this data 238 we have two options: 240 - As a distribution, i.e. in an array of 'buckets.' On the other hand 241 meter storage requirements are well-defined, as is the amount of data 242 to be read from the meter. 244 - As a sequence of integers. This saves all the information, but 245 does not fit well with the RTFM goal of doing as much data reduction 246 as possible within the meter. 248 Studies which would be limited by the use of distributions might well 249 use packet traces instead. 251 For most of RTFM's attributes, a 'distribution' (as described above) 252 appears to be the most effective attribute type. A method of 253 specifying the distribution parameters, and for encoding the 254 distribution so that it can be easily read, are described in section 255 4.2. 257 3.2. Packet Traces 259 The simplest way of collecting a trace in the meter would be to have 260 a new attribute called, say, "PacketTrace." This could be a table, 261 with a column for each property of interest. For example, one could 262 trace 264 - Arrival time (TimeTicks from SysUptime, or microseconds from 265 FirstTime for the flow). 267 - Direction (Forward or Backward) 269 - Sequence number (for protocols with sequence numbers) 271 - Flags (for TCP at least). 273 To add a row to the table, we only need a rule which PushPkts the 274 PacketTrace attribute. To use this, one would write a rule set which 275 selected out a small number of flows of interest, with a 'PushPkt 276 PacketTrace' rule for each of them. A MaxTraceRows default value of 277 2000 would be enough to allow a Meter Reader to read 1-second ping 278 traces every 10 minutes or so. More realistically, a MaxTraceRows of 279 500 would be enough for one- minute pings, read once each hour. Note 280 that packet traces are already implemented in the RMON MIB [6], in 281 the Packet Capture Group; they are therefore a low priority for RTFM. 283 3.3 Aggregate Attributes 285 Performance aspects of flows are of interest in the case of a flow 286 between a server and client. TCP/IP and UDP flows contain equivalent 287 performance, with additional data from TCP flows. The performance 288 data found by this method define the flow capacity used by the 289 individual flow, as experienced in the locale of the RTFM meter. 291 For both TCP/IP and UDP, RTFM's "old-style" flow attributes count the 292 bytes and packets for packets which match the rule set for an 293 individual flow. In addition to these totals, RTFM could calculate 294 Packet size and Bit rate statistics. Bit rate statistics point to the 295 throughput-related performance metrics. 297 Packet size - RTFM's packet flows can be examined to determine the 298 maximum packet size found in a flow. This will give the Network 299 Operator an indication of the MTU being used in a flow. It will also 300 give an indication of the sensitivity to loss of a flow, for losing 301 large packets causes more data to be repeated. 303 Short-term bit rate - The data could also be recorded as the maximum 304 and minimum data rate of the flow, found over specific time periods 305 during the lifetime of a flow; this is a special kind of 306 'distribution.' Bit rate could be used to define the throughput of a 307 flow, and if the RTFM flow is defined to be the sum of all traffic in 308 a network, one can find the throughput of the network. 310 If we are interested in '10-second' forward data rates, the meter 311 might compute this for each flow of interest as follows: 313 - maintain an array of counters to hold the flow's 10-second data 314 rate distribution. 316 - every 10 seconds, compute the 10-second octet count, and save a 317 copy of the flow's forward octet counter. 319 To achieve this, the meter will have to keep a list of aggregate 320 flows and the intervals at which they require processing. Careful 321 programming will be needed to achieve this, but provided the meter is 322 not asked to do it for very large numbers of flows, it should not be 323 too difficult! 325 Note that aggregate attributes are a simple extension of the 'old- 326 style' attributes; their values are never reset. For example, an 327 array of counters could hold a '10-second bit rate' distribution. 329 The counters continue to increase, a meter reader will collect their 330 values at regular intervals, and an analysis application will compute 331 and display distributions of the 10-second bit rate for each 332 collection interval. 334 3.4 Series Attributes 336 The notion of series attributes is to keep simple statistics for 337 measures that involve more than one packet. The attribute values 338 would be stored in the meter as a distribution (see above). 340 TCP and UDP 342 Inter-arrival statistics - TCP and UDP. The Meter knows the time that 343 it encounters each individual packet. Statistics can be kept to 344 record the inter-arrival times of the packets, which would give an 345 indication of the jitter found in the Flow. 347 TCP Only - Packet loss - RTFM can calculate packet loss performance 348 metrics. This is an area for further study. TCP packets have byte 349 sequence numbers and SYNS, FINS, and ACK's associated with them. RTFM 350 could track the sequence numbers in the flows, and calculate the 351 packet loss occurring in a flow, and thus we can develop a metric of 352 lost packets and useful traffic. 354 Delay analysis - TCP flows could be examined for the timing between 355 Transmissions and ACKS and thus we can get some measure of delay (of 356 IPPM performance metrics). This assumes the forward and reverse 357 packets are both visible to the meter. In the case of asymmetric 358 flows, RTFM can be run on multiple paths, and with precise timing 359 create packet traces, which can be compared at later times. 361 Subflow analysis - TCP flows, e.g. a Web server's httpd flows 362 actually contain many individual sub flows. Given, a well known Web 363 Server WW, and a client CC, RTFM would normally pick up an 364 aggregation of all the flows of text, graphics, Java programs, etc. 365 that are sent between WW and CC. By analyzing the Sequence numbers, 366 RTFM could estimate when each subflow occurs, and thus maintain 367 statistics about the subflows on a network. 369 Congestion Analysis - In a TCP/IP flow we have information on the 370 negotiation of Window sizes which are used by TCP/IP to control 371 congestion. Well behaved flows honor these requests and in the vast 372 majority of cases the sender will slow down and thus decrease its 373 rate of injecting packets into the congested network. We will look 374 for cases where flows do not honor these congestion control and are 375 not slowing down. We will also look for flows which have the 376 "precedence" fields turned on and thus are aggressively competing for 377 network resources. 379 3.5 Actions on Exceptions 381 The user of RTFM will have the ability to mark flows as having High 382 Watermarks. The existence of abnormal service conditions, such as 383 non-ending flow, a flow that exceeds a given limit in traffic (e.g. a 384 flow that is exhausting the capacity of the line that carries it) 385 causes an ALERT to be sent to the Meter Reader for forwarding to the 386 Manager. Operations Support may define service situations in many 387 different environments. This is an area for further discussion on 388 Alert and Trap handling. 390 4. Extensions to the 'Basic' RTFM Meter 392 4.1 Flow table extensions 394 The architecture of RTFM has defined the structure of flows, and this 395 draft does not change that structure. The flow table could have 396 ancillary tables called "Distribution Tables" and "Trace Tables," 397 these would contain rows of values and or actions as defined above. 398 Each entry in these tables would be marked with the number of its 399 corresponding flow in the RTFM flow table. 401 In order to identify the data in a Packet Flow Table, the attribute 402 name could be pushed into a string at the head of each row. For 403 example, if a table entry has Bit Rates for a particular flow, the 404 "BitRate" string would be found at the head of the row. 406 4.2. Specifying Distributions in RuleSets 408 At first sight it would seem neccessary to add extra features to the 409 RTFM Meter architecture to support distributions. This, however, is 410 not neccessarily the case. 412 What is actually needed is a way to specify, in a ruleset, the 413 distribution parameters. These include the number of counters, the 414 lower and upper bounds of the distribution, whether it is linear or 415 logarithmic, and any other details (e.g. the time interval for 416 short-term rate attributes). 418 Any attribute which is distribution-valued needs to be allocated a 419 RuleAttributeNumber value. These will be chosen so as to extend the 420 list already in the RTFM Meter MIB document [7]. 422 Since distribution attributes are multi-valued it does not make sense 423 to test them. This means that a PushPkt (or PushPkttoAct) action 424 must be executed to add a new value to the distribution. The old- 425 style attributes use the 'mask' field to specify which bits of the 426 value are required, but again, this is not the case for 427 distributions. Lastly, the MatchedValue ('value') field of a PushPkt 428 rule is never used. Overall, therefore, the 'mask' and 'value' 429 fields in the PushPkt rule are available to specify distribution 430 parameters. 432 Both these fields are at least six bytes long, the size of a MAC 433 address. All we have to do is specify how these bytes should be 434 used! As a starting point, the following is proposed (bytes are 435 numbered left-to-right. 437 Mask bytes: 438 1 Transform 1 = linear, 2 = logarithmic 439 2 Scale Factor Power of 10 multiplier for Limits and Counts 440 3-4 Lower Limit Highest value for first bucket 441 5-6 Upper Limit Highest value for last bucket 443 Value bytes: 444 1-2 Buckets Number of buckets. Does not include 445 the 'overflows' bucket 446 3-4 Parameter-1 Parameter use depends on 447 5-6 Parameter-2 distribution attribute 449 For example: 451 ToPacketSize & 1.0,1,1500 = 100,0,0: PushPkt, Next 453 FromBitrate & 2.3,16,2048 = 7,5,0: PushPkt, Next 455 In these mask and value fields a dot indicates that the next 456 number is a one-byte integer, and the commas indicate that the 457 next number is a two-byte integer. 459 The first rule specifies that a distribution of packet sizes is 460 to be built. It uses an array of 100 buckets, storing values 461 from 1 to 1500 bytes (i.e. linear steps of 15 bytes each). Any 462 packets with size greater than 1500 will be counted in the 'overflow' 463 bucket, hence there are 101 counters for the distribution. 465 The second rule specifies a bit-rate distribution, with the rate 466 being calculated every 5 seconds (parameter 1). A logarithmic 467 array of 7 counters (and an overflow bucket) are used for 468 rates from 16 kbps to 2048 kbps. The scale factor of 10 indicates 469 that the limits are given in kilobits per second. 471 These distribution parameters will need to be stored in the meter 472 so that they are available for building the distribution. They 473 will also need to be read from the meter and saved together with 474 the other flow data. 476 4.3 Reading Distributions 478 Since RTFM flows are bi-directional, 479 each distribution-valued quantity (e.g. packet size, bit rate, etc.) 480 will actually need two sets of 481 counters, one for packets travelling in each direction. It is 482 tempting to regard these as components of a single 'distribution,' but 483 in many cases only one of the two directions will be sensible; it 484 seems better to keep them in separate distributions. This is similar 485 to the old-style counter-valued attributes such as toOctets and fromOctets. 487 A distribution should be read by a meter reader as a single, 488 structured object. The components of a distribution object are 490 - 'mask' and 'value' field from rule which created the distribution 491 - sequence of counters ('buckets' + overflow) 493 These could be easily collected into a BER-encoded octet string, 494 and be read and referred to as a 'distribution.' 496 5. Extensions to the Rules Table 498 The Rules Table of "old-style" attributes will be extended for the 499 new flow types. A list of actions, and Keywords, such as "BitRate"- 500 for Bit Rate, "MaxPackSize", for Max Packet size will be developed and 501 used to inform RTFM to collect a set of extended values for a 502 particular flow (or set of flows). 504 To begin with, here are ten possible distribution-valued attributes: 506 ToPacketSize(61) size of PDUs in bytes (i.e. number 507 FromPacketSize(62) of bytes actually transmitted) 509 ToInterarrivalTime(63) microseconds between successive packets 510 FromInterarrivalTime(64) travelling in the same direction 512 ToTurnaroundTime(65) microseconds between successive packets 513 FromTurnaroundTime(66) travelling in opposite directions 515 ToBitRate(67) short-term flow rate in bits per second 516 FromBitRate(68) Parameter 1 = rate interval in seconds 518 ToPDURate(69) short-term flow rate in PDUs per second 519 FromPDURate(70) Parameter 1 = rate interval in seconds 521 6. Security Considerations 523 The attributes considered in this document represent properties 524 of traffic flows; they do not present any security issues in 525 themselves. The attributes may, however, be used in measuring the 526 behaviour of traffic flows, and the collected traffic flow data 527 could be of considerable value. 528 Anyone making such measurments should have a clearly-defined 529 purpose in doing so. They should also take great care to ensure 530 that the data is properly stored, and is used solely for its 531 intended purpose. 533 7. Acknowledgments 535 We thank Stephen Stibler of IBM for his input to, and comments on this draft. 537 8. Author's Address: 539 Sig Handelman 540 IBM Research Division 541 Hawthorne, NY 542 Phone: 1-914-784-7626 543 E-mail: handel@watson.ibm.com 545 Nevil Brownlee 546 The University of Auckland 547 New Zealand 548 Phone: +64 9 373 7599 x8941 549 E-mail: n.brownlee@auckland.ac.nz 551 Greg Ruth 552 GTE Laboratories 553 Waltham, MA 554 Phone: 1 617 466 2448 555 E-mail: grr1@gte.com 557 9. References: 559 [1] Brownlee, N., Mills, C., Ruth, G.: "Traffic Flow Measurement: 560 Architecture", RFC 2063, 1997 562 [2] Wroclawski, J.: "The Use of RSVP with IETF Integrated Services" 564 [3] Almes, G. et al: "Framework for IP Performance Metrics" Internet 565 Draft. July 1996 567 [4] Claffy, K., Braun, H-W, Polyzos, G.: "A Parameterizable 568 Methodology for Internet Traffic Flow Profiling," IEEE Journal on 569 Selected Areas in Communications, Vol. 13, No. 8, October 1995. 571 [5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272, 572 1992. 574 [6] Waldbusser, S.: "Remote Network Monitoring Management Information 575 Base," RFC 1757, 1995, and RFC 2021, 1997. 577 [7] Brownlee, N: "Traffic Flow Measurement: Meter MIB", RFC 2064, 578 1997