idnits 2.17.1 draft-ietf-rtfm-new-traffic-flow-04.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-25) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 252 has weird spacing: '...r every packe...' == Line 269 has weird spacing: '... method for s...' == Line 436 has weird spacing: '...e could be pu...' -- 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 (February 7, 1999) is 9209 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 645 looks like a reference -- Missing reference section? '4' on line 653 looks like a reference -- Missing reference section? '2' on line 648 looks like a reference -- Missing reference section? '8' on line 666 looks like a reference -- Missing reference section? '3' on line 650 looks like a reference -- Missing reference section? '6' on line 660 looks like a reference -- Missing reference section? '9' on line 669 looks like a reference -- Missing reference section? '7' on line 663 looks like a reference -- Missing reference section? '5' on line 657 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 11 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 S. Stibler 14 IBM 15 Hawthorne, NY USA 17 August 7, 1998 18 expires 19 February 7, 1999 21 RTFM Working Group - New Attributes for Traffic Flow Measurement 23 25 1. Status of this Memo 27 This document is an Internet-Draft. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 29 and its working groups. Note that other groups may also distribute 30 working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 40 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 41 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 43 2. Introduction 45 The Real-Time Flow Measurement (RTFM) Working Group (WG) 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 The new attributes described in this document will be useful for 50 monitoring network performance and will expand the scope of RTFM 51 beyond simple measurement of traffic volumes. A companion document 52 to this draft will be written to define MIB structures for the new 53 attributes. 55 This draft was started in 1996 to advance the work of the RTFM group. 56 The goal of this work is to produce a simple set of abstractions, 57 which can be easily implemented and at the same time enhance the 58 value of RTFM Meters. This document also defines a method for 59 organizing the flow abstractions to augment the existing RTFM flow 60 table. 62 Implementations of the RTFM Meter have been done by Nevil Brownlee in 63 the University of Auckland, NZ, and Stephen Stibler and Sig Handelman 64 at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role 65 of the Meter Reader whose role is to retrieve flow data from the 66 Meter. 68 Note on flows and positioning of meters. 70 A flow as it traverses the Internet may have some of its 71 characteristics altered as it travels through Routers, Switches, and 72 other network units. It is important to note the spatial location of 73 the Meter when referring to attributes of a flow. An example, a 74 server may send a sequence of packets with a definite order, and 75 inter packet timing with a leaky bucket algorithm. A meter reading 76 downstream of the leaky bucket would record a set with minimal inter 77 packet timing due to the leaky bucket. At the client's location, the 78 packets may arrive out of sequence, with the timings altered. A meter 79 at the client's location would record different attributes for the 80 same flow. 82 2.1 RTFM's Definition of Flows 84 The RTFM Meter architecture views a flow as a set of packets between 85 two endpoints (as defined by their source and destination attribute 86 values and start and end times), and as BI-DIRECTIONAL (i.e. the 87 meter effectively monitors two sub-flows, one in each direction). 89 Reasons why RTFM flows are bi-directional: 91 - The WG is interested in understanding the behavior of sessions 92 between endpoints. 94 - The endpoint attribute values (the "Address" and "Type" ones) are 95 the same for both directions; storing them in bi-directional flows 96 reduces the meter's memory demands. 98 - 'One-way' (uni-directional) flows are a degenerate case. Existing 99 RTFM meters can handle this by using one of the computed attributes 100 e.g. FlowKind) to indicate direction. 102 2.2 RTFM's Current Definition of Flows and their Attributes 104 Flows, as described in the "Architecture" document [1] have the 105 following properties: 107 a. They occur between two endpoints, specified as sets of attribute 108 values in the meter's current rule set. A flow is completely 109 identified by its set of endpoint attribute values. 111 b. Each flow may also have values for "computed" attributes (Class 112 and Kind). These are directly derived from the endpoint attribute 113 values. 115 c. A new flow is created when a packet is to be counted that does not 116 match the attributes of an existing flow. The meter records the time 117 when this new flow is created. 119 d. Attribute values in (a), (b) and (c) are set when the meter sees 120 the first packet for the flow, and are never changed. 122 e. Each flow has a "LastTime" attribute, which indicates the time the 123 meter last saw a packet for the flow. 125 f. Each flow has two packet and two byte counters, one for each flow 126 direction (Forward and Backward). These are updated as packets for 127 the flow are observed by the meter. 129 g. ALL the attributes have (more or less) the same meaning for a 130 variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as 131 TCP/IP. 133 Current flow attributes - as described above - fit very well into the 134 SNMP data model. They are either static, or are continuously updated 135 counters. They are NEVER reset. In this document they will be 136 referred to as "old-style" attributes. 138 It is easy to add further "old-style" attributes, since they don't 139 require any new features in the architecture. For example: 141 - Count of the number of "lost" packets (determined by watching 142 sequence number fields for packets in each direction; only available 143 for protocols which have such sequence numbers). 145 - In the future, RTFM could coordinate directly with the Flow Label 146 from the IPv6 header. 148 2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 150 The concept of flows has been studied in various different contexts. 151 For the purpose of extending RTFM, a starting point is the work of 152 the Integrated Services WG. We will measure quantities that are often 153 set by Integrated Services configuration programs. We will look at 154 the work of the Benchmarking / IP Performance Metrics Working Group, 155 and also look at the work of Claffy, Braun and Polyzos [4]. We will 156 demonstrate how RTFM can compute throughput, packet loss, and delays 157 from flows. 159 An example of the use of capacity and performance information is 160 found in "The Use of RSVP with IETF Integrated Services" [2]. RSVP's 161 use of Integrated Services revolves around Token Bucket Rate, Token 162 Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet 163 Size, and the Slack term. These are set by TSpec, ADspec and FLowspec 164 (Integrated Services Keywords), and are used in configuration and 165 operation of Integrated Services. RTFM could monitor explicitly Peak 166 Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack 167 term. RTFM could infer details of the Token Bucket. The WG will 168 develop measures to work with these service metrics. An initial 169 implementation of IIS Monitoring has been developd at CEFRIEL in 170 Italy [8]. 172 RTFM will work with several traffic measurements identified by IPPM 173 [3]. There are three broad areas in which RTFM is useful for IPPM. 174 An RTFM Meter could act as a passive device, gathering traffic and 175 performance statistics at appropriate places in networks (server or 176 client locations). RTFM could give detailed analyses of IPPM test 177 flows that pass through the Network segment that RTFM is monitoring. 178 RTFM could be used to identify the most-used paths in a network mesh, 179 so that detailed IPPM work could be applied to these most used paths. 181 3.0 Flow Abstractions 183 Performance attributes include throughput, packet loss, delays, 184 jitter, and congestion measures. RTFM will calculate these attributes 185 in the form of extensions to the RTFM flow attributes according to 186 three general classes: 188 o 'trace' - attributes of individual packets in a flow or a segment 189 of a flow (e.g. last packet size, last packet arrival time). 191 o 'aggregates' - statistics derived from the flow taken as a whole 192 (e.g. mean rate, max packet size, packet size distribution). 194 o 'group'- attributes that depend on groups of packet values within 195 the flow (e.g. inter-arrival times, short-term traffic rates). 197 Note that attributes within each of these classes may have various 198 types of values - numbers, distributions, time series, and so on. 200 3.1. Meter Readers and Meters 202 A note on the relation between Meter Readers and Meters. 204 Several of the measurements enumerated below can be implemented by a 205 Meter Reader that is tied to the meter with very short response time 206 and very high bandwidth. If the Meter Reader and Meter can be 207 arranged in such a way, RTFM could collect Packet Traces with time 208 stamps and provide them directly to the Meter Reader for further 209 processing. 211 A more useful alternative is to have the Meter calculate some flow 212 statistics locally. This allows a looser coupling between the Meter 213 and Meter Reader. RTFM will monitor an 'extended attribute' depending 214 upon settings in its Rule table. RTFM will not create any "extended 215 attribute" data without explicit instructions in the Rule table. 217 3.2. Attribute Types 219 Section 3.0 described three different classes of attributes; this 220 section considers the "data types" of these attributes. 222 Packet Traces (as described below) are a special case in that they 223 are tables with each row containing a sequence of values, each of 224 varying type. They are essentially 'compound objects' i.e. lists of 225 attribute values for a string of packets. 227 Aggregate attributes are like the 'old-style' attributes. Their 228 types are 230 - Addresses, represented as byte strings (1 to 20 bytes long) 231 - Counters, represented as 64-bit unsigned integers 233 - Times, represented as 32-bit unsigned integers 235 Addresses are saved when the first packet of a flow is observed. They 236 do not change with time, and they are used as a key to find the 237 flow's entry in the meter's flow table. 239 Counters are incremented for each packet, and are never reset. An 240 analysis application can compute differences between readings of the 241 counters, so as to determine rates for these attributes. For 242 example, if we read flow data at five-minute intervals, we can 243 calculate five-minute packet and byte rates for the flow's two 244 directions. 246 Times - the FirstTime for a flow is set when its first packet is 247 observed. LastTime is updated as each packet in the flow is observed. 249 All the above types have the common feature that they are expressed 250 as single values. At least some of the new attributes will require 251 multiple values. If, for example, we are interested in inter-packet 252 time intervals, we can compute an interval for every packet after 253 the first. If we are interested in packet sizes, a new value is 254 obtained as each packet arrives. When it comes to storing this data 255 we have two options: 257 - As a distribution, i.e. in an array of 'buckets.' This method is 258 a compact representation of the data, with the values being stored as 259 counters between a minimum and maximum, with defined steps in each 260 bucket. This fits the RTFM goal of compact data storage. 262 - As a sequence of single values. This saves all the information, 263 but does not fit well with the RTFM goal of doing as much data 264 reduction as possible within the meter. 266 Studies which would be limited by the use of distributions might well 267 use packet traces instead. 269 A method for specifying the distribution parameters, and for 270 encoding the distribution so that it can be easily read, is described 271 in section 4.2. 273 3.3 Packet Traces 275 The simplest way of collecting a trace in the meter would be to have 276 a new attribute called, say, "PacketTrace." This could be a table, 277 with a column for each property of interest. For example, one could 278 trace 280 - Packet Arrival time (TimeTicks from sysUpTime, or microseconds from 281 FirstTime for the flow). 283 - Packet Direction (Forward or Backward) 285 - Packet Sequence number (for protocols with sequence numbers) 287 - Packet Flags (for TCP at least) 289 Note: The following implementation proposal is for the user who is 290 familiar with the writing of rule sets for the RTFM Meter. 292 To add a row to the table, we only need a rule which PushPkts the 293 PacketTrace attribute. To use this, one would write a rule set which 294 selected out a small number of flows of interest, with a 'PushPkt 295 PacketTrace' rule for each of them. A MaxTraceRows default value of 296 2000 would be enough to allow a Meter Reader to read one-second ping 297 traces every 10 minutes or so. More realistically, a MaxTraceRows of 298 500 would be enough for one-minute pings, read once each hour. Note 299 that packet traces are already implemented in the RMON MIB [6], in 300 the Packet Capture Group. They are therefore a low priority for RTFM. 302 3.4 Aggregate Attributes 304 RTFM's "old-style" flow attributes count the bytes and packets for 305 packets which match the rule set for an individual flow. In addition 306 to these totals, RTFM could calculate Packet Size and Bit Rate 307 statistics. Bit Rate statistics point to the throughput-related 308 performance metrics. This data can be stored as distributions, though 309 it may sometimes be sufficient to simply keep a maximum value. 311 Packet Size - RTFM's packet flows can be examined to determine the 312 maximum packet size found in a flow. This will give the Network 313 Operator an indication of the MTU being used in a flow. It will also 314 give an indication of the sensitivity to loss of a flow, for losing 315 large packets causes more data to be retransmitted. 317 Short-term bit rate - The data could also be recorded as the maximum 318 and minimum data rate of the flow, found over specific time periods 319 during the lifetime of a flow; this is a special kind of 320 'distribution.' Bit rate could be used to define the throughput of a 321 flow, and if the RTFM flow is defined to be the sum of all traffic in 322 a network, one can find the throughput of the network. 324 If we are interested in '10-second' forward data rates, the meter 325 might compute this for each flow of interest as follows: 327 - maintain an array of counters to hold the flow's 10-second data 328 rate distribution. 330 - every 10 seconds, compute and save 10-second octet count, and save 331 a copy of the flow's forward octet counter. 333 To achieve this, the meter will have to keep a list of aggregate 334 flows and the intervals at which they require processing. Careful 335 programming is needed to achieve this, but provided the meter is not 336 asked to do it for very large numbers of flows, it has been 337 successfully implemented. 339 Note that aggregate attributes are a simple extension of the 'old- 340 style' attributes; their values are never reset. For example, an 341 array of counters could hold a '10-second bit rate' distribution. 342 The counters continue to increase, a meter reader will collect their 343 values at regular intervals, and an analysis application will compute 344 and display distributions of the 10-second bit rate for each 345 collection interval. 347 3.5 Group Attributes 349 The notion of group attributes is to keep simple statistics for 350 measures that involve more than one packet. This section describes 351 some group attributes which it is feasible to implement in a traffic 352 meter, and which seem interesting and useful. 354 Inter-arrival times. The Meter knows the time that it encounters each 355 individual packet. Statistics can be kept to record the inter-arrival 356 times of the packets, which would give an indication of the jitter 357 found in the Flow. 359 Turn-around statistics. Sine the Meter knows the time that it 360 encounters each individual packet, it can produce statistics of the 361 time intervals between packets in opposite directions are observed on 362 the network. For protocols such as SNMP (where every packet elicits 363 an answering packet) this gives a good indication of turn-around 364 times. 366 Subflow analysis. Since the choice of flow endpoints is controlled 367 by the meter's rule set, it is easy to define an aggregate flow, e.g 368 "all the TCP streams between hosts A and B." Preliminary 369 implementation work suggests that - at least for this case - it 370 should be possible for the meter to maintain a table of information 371 about all the active streams. This could be used to produce at least 372 the following attributes: 373 - Number of streams, e.g. streams active for n-second intervals. 374 Determined for TCP and UDP using source-dest port number pairs. 375 - Number of TCP bytes, determined by taking difference of TCP 376 sequence numbers for each direction of the aggreagate flow. 378 IIS attributes. Work at CEFRIEL [8] has produced a traffic meter 379 with a rule set modified 'on the fly' so as to maintain a list of 380 RSVP-reserved flows. For such flows the following attributes have 381 been implemented (these quantities are defined in [9]): 383 - QoSService: Service class for the flow 384 (guaranteed, controlled load) 385 - QoSStyle: Reservation setup style 386 (wildcard filter, fixed filter, 387 shared explicit) 388 - QoSRate: [byte/s] rate for flows with 389 guaranteed service 390 - QoSSlackTerm: [microseconds] Slack Term QoS parameter 391 for flows with guaranteed service 392 - QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter 393 for flows with guaranteed or 394 controlled load service 396 The following are also being considered: 398 - QoSTokenBucketSize: [byte] Size of Token Bucket 400 - QoSPeakDataRate: [byte/s] Maximum rate for incoming data 402 - QoSMinPolicedUnit: [byte] IP datagrams less than this are 403 counted as being this size 404 - QoSMaxDatagramSize: [byte] Size of biggest datagram which 405 conforms to the traffic specification 407 3.6 Actions on Exceptions 409 Some users of RTFM have requested the ability to mark flows as having 410 High Watermarks. The existence of abnormal service conditions, such 411 as non-ending flow, a flow that exceeds a given limit in traffic 412 (e.g. a flow that is exhausting the capacity of the line that carries 413 it) would cause an ALERT to be sent to the Meter Reader for 414 forwarding to the Manager. Operations Support could define service 415 situations in many different environments. This is an area for 416 further discussion on Alert and Trap handling. 418 4. Extensions to the 'Basic' RTFM Meter 419 The WG has agreed that the basic RTFM Meter will not be altered by 420 the addition of the new attributes of this document. This section 421 describes the extensions needed to implement the new attributes. 423 4.1 Flow table extensions 425 The architecture of RTFM has defined the structure of flows, and this 426 draft does not change that structure. The flow table could have 427 ancillary tables called "Distribution Tables" and "Trace Tables," 428 these would contain rows of values and or actions as defined above. 429 Each entry in these tables would be marked with the number of its 430 corresponding flow in the RTFM flow table. 432 Note: The following section is for the user who is familiar with the 433 writing of rule sets for the RTFM Meter. 435 In order to identify the data in a Packet Flow Table, the attribute 436 name could be pushed into a string at the head of each row. For 437 example, if a table entry has "To Bit Rate" for a particular flow, 438 the "ToBitRate" string would be found at the head of the row. (An 439 alternative method would be to code an identification value for each 440 extended attribute and push that value into the head of the row.) See 441 section 5.0 for an inital set of ten extended flow attributes. 443 4.2. Specifying Distributions in RuleSets 445 At first sight it would seem neccessary to add extra features to the 446 RTFM Meter architecture to support distributions. This, however, is 447 not neccessarily the case. 449 What is actually needed is a way to specify, in a ruleset, the 450 distribution parameters. These include the number of counters, the 451 lower and upper bounds of the distribution, whether it is linear or 452 logarithmic, and any other details (e.g. the time interval for 453 short-term rate attributes). 455 Any attribute which is distribution-valued needs to be allocated a 456 RuleAttributeNumber value. These will be chosen so as to extend the 457 list already in the RTFM Meter MIB document [7]. 459 Since distribution attributes are multi-valued it does not make sense 460 to test them. This means that a PushPkt (or PushPkttoAct) action 461 must be executed to add a new value to the distribution. The old- 462 style attributes use the 'mask' field to specify which bits of the 463 value are required, but again, this is not the case for 464 distributions. Lastly, the MatchedValue ('value') field of a PushPkt 465 rule is never used. Overall, therefore, the 'mask' and 'value' 466 fields in the PushPkt rule are available to specify distribution 467 parameters. 469 Both these fields are at least six bytes long, the size of a MAC 470 address. All we have to do is specify how these bytes should be 471 used! As a starting point, the following is proposed (bytes are 472 numbered left-to-right. 474 Mask bytes: 475 1 Transform 1 = linear, 2 = logarithmic 476 2 Scale Factor Power of 10 multiplier for Limits and Counts 477 3-4 Lower Limit Highest value for first bucket 478 5-6 Upper Limit Highest value for last bucket 480 Value bytes: 481 1 Buckets Number of buckets. Does not include 482 the 'overflow' bucket 483 2 Parameter-1 } Parameter use depends 484 3-4 Parameter-2 } on distribution-valued 485 5-6 Parameter-3 } attribute 487 For example: 489 FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next; 491 ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next; 493 FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next; 495 In these mask and value fields a dot indicates that the preceding 496 number is a one-byte integer, the exclamation marks indicate that 497 the preceding number is a two-byte integer, and the last number is 498 two bytes wide since this was the width of the preceding field. 499 (Note that this convention follows that for IP addresses - 130.216 500 means 130.216.0.0). 502 The first rule specifies that a distribution of packet sizes is 503 to be built. It uses an array of 60 buckets, storing values from 504 1 to 1500 bytes (i.e. linear steps of 25 bytes each bucket). Any 505 packets with size greater than 1500 will be counted in the 507 The second rule specifies an arrival-time distribution, using a 508 logarithmic scale for an array of 60 counters (and an overflow 509 bucket) for rates from 1 ms to 1.8 s. The scale factor of 3 510 indicates that the limits are given in milliseconds. 512 The third rule specifies a bit-rate distribution, with the rate 513 being calculated every 5 seconds (parameter 1). A logarithmic 514 array of 60 counters (and an overflow bucket) are used for 515 rates from 1 kbps to 10 Mbps. The scale factor of 3 indicates 516 that the limits are given in thousands of bits per second. 518 These distribution parameters will need to be stored in the meter 519 so that they are available for building the distribution. They 520 will also need to be read from the meter and saved together with 521 the other flow data. 523 4.3 Reading Distributions 525 Since RTFM flows are bi-directional, each distribution-valued quantity 526 (e.g. packet size, bit rate, etc.) 527 will actually need two sets of counters, one for packets travelling in each 528 direction. It is 529 tempting to regard these as components of a single 'distribution,' but 530 in many cases only one of the two directions will be of interest; it 531 seems better to keep them in separate distributions. This is similar 532 to the old-style counter-valued attributes such as toOctets and fromOctets. 534 A distribution should be read by a meter reader as a single, 535 structured object. The components of a distribution object are 537 - 'mask' and 'value' fields from the rule which created the distribution 538 - sequence of counters ('buckets' + overflow) 540 These can be easily collected into a BER-encoded octet string, 541 and would be read and referred to as a 'distribution.' 543 5. Extensions to the Rules Table 545 Extensions to the Rules Table, Attribute Numbers 547 The Rules Table of "old-style" attributes will be extended for the 548 new flow types. A list of actions, and keywords, such as "ToBitRate", 549 "ToPacketSize", etc. will be developed and used to inform an RTFM 550 meter to collect a set of extended values for a 551 particular flow (or set of flows). 553 Note. An implementation suggestion. Value 65 is used for 'Distributions,' 554 which has one bit set for each distribution-valued attribute present 555 for the flow, using bit 0 for attribute 66, bit 1 for attribute 67, etc. 557 Here are ten possible distribution-valued attributes numbered according 558 to RTFM WG consensus at the 1997 meeting in Munich: 560 ToPacketSize(66) size of PDUs in bytes (i.e. number 561 FromPacketSize(67) of bytes actually transmitted) 562 ToInterarrivalTime(68) microseconds between successive packets 563 FromInterarrivalTime(69) travelling in the same direction 565 ToTurnaroundTime(70) microseconds between successive packets 566 FromTurnaroundTime(71) travelling in opposite directions 568 ToBitRate(72) short-term flow rate in bits per second 569 FromBitRate(73) Parameter 1 = rate interval in seconds 571 ToPDURate(74) short-term flow rate in PDUs per second 572 FromPDURate(75) Parameter 1 = rate interval in seconds 574 (76 .. 97) other distributions 576 It seems reasonable to allocate a further group of numbers 577 for the IIS attributes described above - 579 QoSService(98) 580 QoSStyle(99) 581 QoSRate(100) 582 QoSSlackTerm(101) 583 QoSTokenBucketRate(102) 584 QoSTokenBucketSize(103) 585 QoSPeakDataRate(104) 586 QoSMinPolicedUnit(105) 587 QoSMaxPolicedUnit(106) 589 The following attributes have also been implemented in NetFlowMet, a 590 version of the NeTraMet meter - 592 MeterID(112) Integer identifying the router producing 593 NetFlow data (needed when NetFlowMet takes 594 data from several routers) 595 SourceASN(113) Autonomous System Number for flow's source 596 SourcePrefix(114) CIDR width used by router for determining 597 flow's source network 598 DestASN(115) Autonomous System Number for flow's destination 599 DestPrefix(116) CIDR width used by router for determining 600 flow's destination network 602 Some of the above, e.g. SourceASN and DestASN, might sensibly be 603 allocated attribute numbers below 64, making them part of the 'base' 604 RTFM meter attributes. 606 6. Security Considerations 608 The attributes considered in this document represent properties 609 of traffic flows; they do not present any security issues in 610 themselves. The attributes may, however, be used in measuring the 611 behaviour of traffic flows, and the collected traffic flow data 612 could be of considerable value. Suitable precautions should be taken to keep 613 such data safe. 615 7. Acknowledgments 617 8. Author's Address: 619 Sig Handelman 620 IBM Research Division 621 Hawthorne, NY 622 Phone: 1-914-784-7626 623 E-mail: swhandel@us.ibm.com 625 Nevil Brownlee 626 The University of Auckland 627 New Zealand 628 Phone: +64 9 373 7599 x8941 629 E-mail: n.brownlee@auckland.ac.nz 631 Greg Ruth 632 GTE Laboratories 633 Waltham, MA 634 Phone: 1 781 466 2448 635 E-mail: grr1@gte.com 637 Stephen Stibler 638 IBM Research Division 639 Hawthorne, NY 640 Phone: 1-914-784-7191 641 E-mail: stibler@us.ibm.com 643 9. References: 645 [1] Brownlee, N., Mills, C., Ruth, G.: "Traffic Flow Measurement: 646 Architecture", RFC 2063, 1997 648 [2] Wroclawski, J.: "The Use of RSVP with IETF Integrated Services" 650 [3] Almes, G. et al: "Framework for IP Performance Metrics" Internet 651 Draft. July 1996 653 [4] Claffy, K., Braun, H-W, Polyzos, G.: "A Parameterizable 654 Methodology for Internet Traffic Flow Profiling," IEEE Journal on 655 Selected Areas in Communications, Vol. 13, No. 8, October 1995. 657 [5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272, 658 1992. 660 [6] Waldbusser, S.: "Remote Network Monitoring Management Information 661 Base," RFC 1757, 1995, and RFC 2021, 1997. 663 [7] Brownlee, N: "Traffic Flow Measurement: Meter MIB", RFC 2064, 664 1997 666 [8] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: User's Guide", 667 CEFRIEL, Milan, 5 May 1998, (See also, http://www.cefriel.it/ntw). 669 [9] Shenker, S., Partridge, C., Guerin, R.: "Specification of 670 Guaranteed Quality of Service," RFC 2212, 1997.