idnits 2.17.1 draft-ietf-rtfm-new-traffic-flow-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 91 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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: ---------------------------------------------------------------------------- -- 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 2000) is 8834 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) == Unused Reference: 'RMON-MIB' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RMON2-MIB' is defined on line 703, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'C-B-P' -- Possible downref: Non-RFC (?) normative reference: ref. 'IIS-ACCT' ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. 'IPPM-FRM') ** Obsolete normative reference: RFC 2021 (ref. 'RMON-MIB') (Obsoleted by RFC 4502) -- Duplicate reference: RFC2021, mentioned in 'RMON2-MIB', was also mentioned in 'RMON-MIB'. ** Obsolete normative reference: RFC 2021 (ref. 'RMON2-MIB') (Obsoleted by RFC 4502) ** Obsolete normative reference: RFC 2063 (ref. 'RTFM-ARC') (Obsoleted by RFC 2722) ** Obsolete normative reference: RFC 2064 (ref. 'RTFM-MIB') (Obsoleted by RFC 2720) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S.W. Handelman 2 INTERNET-DRAFT IBM 3 Hawthorne, NY USA 5 Nevil Brownlee 6 The University of Auckland 7 New Zealand 9 Greg Ruth 10 GTE Internetworking 11 Waltham, MA USA 13 S. Stibler 14 IBM 15 Hawthorne, NY USA 17 August 1999 18 Expires February 2000 20 RTFM: New Attributes for Traffic Flow Measurement 22 24 Abstract 26 The RTFM Traffic Measurement Architecture provides a general framework 27 for describing and measuring network traffic flows. Flows are defined 28 in terms of their Address Attribute values and measured by a 'Traffic 29 Meter.' This document discusses RTFM flows and the attributes which 30 they can have, so as to provide a logical framework for extending the 31 architecture by adding new attributes. 33 Extensions described include Address Attributes such as DSCodePoint, 34 SourceASN and DestASN, and Group Attributes such as short-term bit rates 35 and turnaround times. Quality of Service parameters for Integrated 36 Services are also discussed. 38 Status of this Memo 40 This document is an Internet-Draft and is in full conformance with all 41 provisions of Section 10 of RFC 2026. 43 Internet-Drafts are working documents of the Internet Engineering Task 44 Force (IETF), its areas, and its working groups. Note that other groups 45 may also distribute working documents as Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference material 50 or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet Draft is a product of the Realtime Traffic Flow 59 Measurement Working Group of the IETF. 61 Contents 63 1 Introduction 3 64 1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . . 3 65 1.2 RTFM's Current Definition of Flows and their Attributes . . . 4 66 1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows . 5 68 2 Flow Abstractions 6 69 2.1 Meter Readers and Meters .. . . . . . . . . . . . . . . . . 6 70 2.2 Attribute Types . . . . . .. . . . . . . . . . . . . . . . . 6 71 2.3 Packet Traces . . . . . . .. . . . . . . . . . . . . . . . . 8 72 2.4 Aggregate Attributes . . . .. . . . . . . . . . . . . . . . . 8 73 2.5 Group Attributes . . . .. . . . . . . . . . . . . . . . . . . 9 74 2.6 Actions on Exceptions . . .. . . . . . . . . . . . . . . . . 10 76 3 Extensions to the 'Basic' RTFM Meter 11 77 3.1 Flow table extensions . . .. . . . . . . . . . . . . . . . . 11 78 3.2 Specifying Distributions in RuleSets . . . . . . . . . . . . 11 79 3.3 Reading Distributions . . .. . . . . . . . . . . . . . . . . 13 81 4 Extensions to the Rules Table, Attribute Numbers 13 83 5 Security Considerations 15 85 6 References 15 87 7 Author's Addresses 16 88 1 Introduction 90 The Real-Time Flow Measurement (RTFM) Working Group (WG) has developed a 91 system for measuring and reporting information about traffic flows in 92 the Internet. This document explores the definition of extensions to 93 the flow measurements as currently defined in [RTFM-ARC]. The new 94 attributes described in this document will be useful for monitoring 95 network performance and will expand the scope of RTFM beyond simple 96 measurement of traffic volumes. A companion document to this draft will 97 be written to define MIB structures for the new attributes. 99 This draft was started in 1996 to advance the work of the RTFM group. 100 The goal of this work is to produce a simple set of abstractions, which 101 can be easily implemented and at the same time enhance the value of RTFM 102 Meters. This document also defines a method for organizing the flow 103 abstractions to augment the existing RTFM flow table. 105 Implementations of the RTFM Meter have been done by Nevil Brownlee in 106 the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at 107 IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role of the 108 Meter Reader whose role is to retrieve flow data from the Meter. 110 Note on flows and positioning of meters: 112 A flow as it traverses the Internet may have some of its 113 characteristics altered as it travels through Routers, 114 Switches, and other network units. It is important to note the 115 spatial location of the Meter when referring to attributes of a 116 flow. An example, a server may send a sequence of packets with 117 a definite order, and inter packet timing with a leaky bucket 118 algorithm. A meter reading downstream of the leaky bucket 119 would record a set with minimal inter packet timing due to the 120 leaky bucket. At the client's location, the packets may arrive 121 out of sequence, with the timings altered. A meter at the 122 client's location would record different attributes for the 123 same flow. 125 1.1 RTFM's Definition of Flows 127 The RTFM Meter architecture views a flow as a set of packets between two 128 endpoints (as defined by their source and destination attribute values 129 and start and end times), and as BI-DIRECTIONAL (i.e. the meter 130 effectively monitors two sub-flows, one in each direction). 132 Reasons why RTFM flows are bi-directional: 134 - The WG is interested in understanding the behavior of sessions 135 between endpoints. 137 - The endpoint attribute values (the "Address" and "Type" ones) are 138 the same for both directions; storing them in bi-directional flows 139 reduces the meter's memory demands. 141 - 'One-way' (uni-directional) flows are a degenerate case. Existing 142 RTFM meters can handle this by using one of the computed attributes 143 (e.g. FlowKind) to indicate direction. 145 1.2 RTFM's Current Definition of Flows and their Attributes 147 Flows, as described in the "Architecture" document [RTFM-ARC] have the 148 following properties: 150 a. They occur between two endpoints, specified as sets of attribute 151 values in the meter's current rule set. A flow is completely 152 identified by its set of endpoint attribute values. 154 b. Each flow may also have values for "computed" attributes (Class 155 and Kind). These are directly derived from the endpoint 156 attribute values. 158 c. A new flow is created when a packet is to be counted that does 159 not match the attributes of an existing flow. The meter records 160 the time when this new flow is created. 162 d. Attribute values in (a), (b) and (c) are set when the meter sees 163 the first packet for the flow, and are never changed. 165 e. Each flow has a "LastTime" attribute, which indicates the time 166 the meter last saw a packet for the flow. 168 f. Each flow has two packet and two byte counters, one for each 169 flow direction (Forward and Backward). These are updated as 170 packets for the flow are observed by the meter. 172 g. ALL the attributes have (more or less) the same meaning for a 173 variety of protocols; IPX, AppleTalk, DECnet and CLNS as well 174 as TCP/IP. 176 Current flow attributes - as described above - fit very well into the 177 SNMP data model. They are either static, or are continuously updated 178 counters. They are NEVER reset. In this document they will be referred 179 to as "old-style" attributes. 181 It is easy to add further "old-style" attributes, since they don't 182 require any new features in the architecture. For example: 184 - Count of the number of "lost" packets (determined by watching 185 sequence number fields for packets in each direction; only 186 available for protocols which have such sequence numbers). 188 - In the future, RTFM could coordinate directly with the Flow Label 189 from the IPv6 header. 191 1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 193 The concept of flows has been studied in various different contexts. 194 For the purpose of extending RTFM, a starting point is the work of the 195 Integrated Services WG. We will measure quantities that are often set by 196 Integrated Services configuration programs. We will look at the work of 197 the Benchmarking / IP Performance Metrics Working Group, and also look 198 at the work of Claffy, Braun and Polyzos [C-B-P]. We will demonstrate 199 how RTFM can compute throughput, packet loss, and delays from flows. 201 An example of the use of capacity and performance information is found 202 in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP]. RSVP's 203 use of Integrated Services revolves around Token Bucket Rate, Token 204 Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, 205 and the Slack term. These are set by TSpec, ADspec and FLowspec 206 (Integrated Services Keywords), and are used in configuration and 207 operation of Integrated Services. RTFM could monitor explicitly Peak 208 Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack 209 term. RTFM could infer details of the Token Bucket. The WG will 210 develop measures to work with these service metrics. An initial 211 implementation of IIS Monitoring has been developd at CEFRIEL in Italy 212 [IIS-ACCT]. 214 RTFM will work with several traffic measurements identified by IPPM 215 [IPPM-FRM]. There are three broad areas in which RTFM is useful for 216 IPPM. 218 - An RTFM Meter could act as a passive device, gathering traffic and 219 performance statistics at appropriate places in networks (server or 220 client locations). 222 - RTFM could give detailed analyses of IPPM test flows that pass 223 through the Network segment that RTFM is monitoring. 225 - RTFM could be used to identify the most-used paths in a network 226 mesh, so that detailed IPPM work could be applied to these most 227 used paths. 229 2 Flow Abstractions 231 Performance attributes include throughput, packet loss, delays, jitter, 232 and congestion measures. RTFM will calculate these attributes in the 233 form of extensions to the RTFM flow attributes according to three 234 general classes: 236 - 'Trace,' attributes of individual packets in a flow or a segment 237 of a flow (\eg last packet size, last packet arrival time). 239 - 'Aggregate,' attributes derived from the flow taken as a whole 240 (e.g. mean rate, max packet size, packet size distribution). 242 - 'Group,' attributes that depend on groups of packet values within 243 the flow (\eg inter-arrival times, short-term traffic rates). 245 Note that attributes within each of these classes may have various types 246 of values - numbers, distributions, time series, and so on. 248 2.1 Meter Readers and Meters 250 A note on the relation between Meter Readers and Meters .. 252 Several of the measurements enumerated below can be implemented by a 253 Meter Reader that is tied to a meter with very short response time and 254 very high bandwidth. If the Meter Reader and Meter can be arranged in 255 such a way, RTFM could collect Packet Traces with time stamps and 256 provide them directly to the Meter Reader for further processing. 258 A more useful alternative is to have the Meter calculate some flow 259 statistics locally. This allows a looser coupling between the Meter and 260 Meter Reader. RTFM will monitor an 'extended attribute' depending upon 261 settings in its Rule table. RTFM will not create any "extended 262 attribute" data without explicit instructions in the Rule table. 264 2.2 Attribute Types 266 Section 2. described three different classes of attributes; this 267 section considers the "data types" of these attributes. 269 Packet Traces (as described below) are a special case in that they are 270 tables with each row containing a sequence of values, each of varying 271 type. They are essentially 'compound objects' i.e. lists of attribute 272 values for a string of packets. 274 Aggregate attributes are like the 'old-style' attributes. Their types 275 are 277 - Addresses, represented as byte strings (1 to 20 bytes long) 279 - Counters, represented as 64-bit unsigned integers 281 - Times, represented as 32-bit unsigned integers 283 Addresses are saved when the first packet of a flow is observed. They 284 do not change with time, and they are used as a key to find the flow's 285 entry in the meter's flow table. 287 Counters are incremented for each packet, and are never reset. An 288 analysis application can compute differences between readings of the 289 counters, so as to determine rates for these attributes. For example, 290 if we read flow data at five-minute intervals, we can calculate 291 five-minute packet and byte rates for the flow's two directions. 293 Times are derived from the FirstTime for a flow, which is set when its 294 first packet is observed. LastTime is updated as each packet in the 295 flow is observed. 297 All the above types have the common feature that they are expressed as 298 single values. At least some of the new attributes will require 299 multiple values. If, for example, we are interested in inter-packet 300 time intervals, we can compute an interval for every packet after the 301 first. If we are interested in packet sizes, a new value is obtained as 302 each packet arrives. When it comes to storing this data we have two 303 options: 305 - As a distribution, i.e. in an array of 'buckets.' This method is a 306 compact representation of the data, with the values being stored as 307 counters between a minimum and maximum, with defined steps in each 308 bucket. This fits the RTFM goal of compact data storage. 310 - As a sequence of single values. This saves all the information, 311 but does not fit well with the RTFM goal of doing as much data 312 reduction as possible within the meter. 314 Studies which would be limited by the use of distributions might well 315 use packet traces instead. 317 A method for specifying the distribution parameters, and for encoding 318 the distribution so that it can be easily read, is described in section 319 3.2. 321 2.3 Packet Traces 323 The simplest way of collecting a trace in the meter would be to have a 324 new attribute called, say, "PacketTrace." This could be a table, with a 325 column for each property of interest. For example, one could trace 327 - Packet Arrival time (TimeTicks from sysUpTime, or microseconds from 328 FirstTime for the flow). 330 - Packet Direction (Forward or Backward) 332 - Packet Sequence number (for protocols with sequence numbers) 334 - Packet Flags (for TCP at least) 336 Note: The following implementation proposal is for the user who is 337 familiar with the writing of rule sets for the RTFM Meter. 339 To add a row to the table, we only need a rule which PushPkts 340 the PacketTrace attribute. To use this, one would write a rule 341 set which selected out a small number of flows of interest, 342 with a 'PushPkt PacketTrace' rule for each of them. A 343 MaxTraceRows default value of 2000 would be enough to allow a 344 Meter Reader to read one-second ping traces every 10 minutes or 345 so. More realistically, a MaxTraceRows of 500 would be enough 346 for one-minute pings, read once each hour. 348 Packet traces are already implemented by the RMON MIB [RMON-MIB, 349 RMON2-MIB], in the Packet Capture Group. They are therefore a low 350 priority for RTFM. 352 2.4 Aggregate Attributes 354 RTFM's "old-style" flow attributes count the bytes and packets for 355 packets which match the rule set for an individual flow. In addition to 356 these totals, for example, RTFM could calculate Packet Size statistics. 357 This data can be stored as distributions, though it may sometimes be 358 sufficient to simply keep a maximum value. 360 As an example, consider Packet Size. RTFM's packet flows can be 361 examined to determine the maximum packet size found in a flow. This 362 will give the Network Operator an indication of the MTU being used in a 363 flow. It will also give an indication of the sensitivity to loss of a 364 flow, for losing large packets causes more data to be retransmitted. 366 Note that aggregate attributes are a simple extension of the 'old-style' 367 attributes; their values are never reset. For example, an array of 368 counters could hold a 'packet size' distribution. The counters continue 369 to increase, a meter reader will collect their values at regular 370 intervals, and an analysis application will compute and display 371 distributions of the packet size for each collection interval. 373 2.5 Group Attributes 375 The notion of group attributes is to keep simple statistics for measures 376 that involve more than one packet. This section describes some group 377 attributes which it is feasible to implement in a traffic meter, and 378 which seem interesting and useful. 380 Short-term bit rate - The data could also be recorded as the maximum and 381 minimum data rate of the flow, found over specific time periods during 382 the lifetime of a flow; this is a special kind of 'distribution.' Bit 383 rate could be used to define the throughput of a flow, and if the RTFM 384 flow is defined to be the sum of all traffic in a network, one can find 385 the throughput of the network. 387 If we are interested in '10-second' forward data rates, the meter might 388 compute this for each flow of interest as follows: 390 - maintain an array of counters to hold the flow's 10-second data 391 rate distribution. 393 - every 10 seconds, compute and save 10-second octet count, and save 394 a copy of the flow's forward octet counter. 396 To achieve this, the meter will have to keep a list of aggregate flows 397 and the intervals at which they require processing. Careful programming 398 is needed to achieve this, but provided the meter is not asked to do it 399 for very large numbers of flows, it has been successfully implemented. 401 Inter-arrival times. The Meter knows the time that it encounters each 402 individual packet. Statistics can be kept to record the inter-arrival 403 times of the packets, which would give an indication of the jitter found 404 in the Flow. 406 Turn-around statistics. Sine the Meter knows the time that it 407 encounters each individual packet, it can produce statistics of the time 408 intervals between packets in opposite directions are observed on the 409 network. For protocols such as SNMP (where every packet elicits an 410 answering packet) this gives a good indication of turn-around times. 412 Subflow analysis. Since the choice of flow endpoints is controlled by 413 the meter's rule set, it is easy to define an aggregate flow, e.g "all 414 the TCP streams between hosts A and B." Preliminary implementation work 415 suggests that - at least for this case - it should be possible for the 416 meter to maintain a table of information about all the active streams. 417 This could be used to produce at least the following attributes: 419 - Number of streams, e.g. streams active for n-second intervals. 420 Determined for TCP and UDP using source-dest port number pairs. 422 - Number of TCP bytes, determined by taking difference of TCP 423 sequence numbers for each direction of the aggreagate flow. 425 IIS attributes. Work at CEFRIEL [IIS-ACCT] has produced a traffic meter 426 with a rule set modified 'on the fly' so as to maintain a list of 427 RSVP-reserved flows. For such flows the following attributes have been 428 implemented (these quantities are defined in [GUAR-QOS]): 430 - QoSService: Service class for the flow 431 (guaranteed, controlled load) 432 - QoSStyle: Reservation setup style 433 (wildcard filter, fixed filter, 434 shared explicit) 435 - QoSRate: [byte/s] rate for flows with 436 guaranteed service 437 - QoSSlackTerm: [microseconds] Slack Term QoS parameter 438 for flows with guaranteed service 439 - QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter 440 for flows with guaranteed or 441 controlled load service 443 The following are also being considered: 445 - QoSTokenBucketSize: [byte] Size of Token Bucket 447 - QoSPeakDataRate: [byte/s] Maximum rate for incoming data 449 - QoSMinPolicedUnit: [byte] IP datagrams less than this are 450 counted as being this size 451 - QoSMaxDatagramSize: [byte] Size of biggest datagram which 452 conforms to the traffic specification 454 2.6 Actions on Exceptions 456 Some users of RTFM have requested the ability to mark flows as having 457 High Watermarks. The existence of abnormal service conditions, such as 458 non-ending flow, a flow that exceeds a given limit in traffic (e.g. a 459 flow that is exhausting the capacity of the line that carries it) would 460 cause an ALERT to be sent to the Meter Reader for forwarding to the 461 Manager. Operations Support could define service situations in many 462 different environments. This is an area for further discussion on Alert 463 and Trap handling. 465 3 Extensions to the 'Basic' RTFM Meter 467 The Working Group has agreed that the basic RTFM Meter will not be 468 altered by the addition of the new attributes of this document. This 469 section describes the extensions needed to implement the new attributes. 471 3.1 Flow table extensions 473 The architecture of RTFM has defined the structure of flows, and this 474 draft does not change that structure. The flow table could have 475 ancillary tables called "Distribution Tables" and "Trace Tables," these 476 would contain rows of values and or actions as defined above. Each 477 entry in these tables would be marked with the number of its 478 corresponding flow in the RTFM flow table. 480 Note: The following section is for the user who is familiar with the 481 writing of rule sets for the RTFM Meter. 483 In order to identify the data in a Packet Flow Table, the 484 attribute name could be pushed into a string at the head of 485 each row. For example, if a table entry has "To Bit Rate" for 486 a particular flow, the "ToBitRate" string would be found at the 487 head of the row. (An alternative method would be to code an 488 identification value for each extended attribute and push that 489 value into the head of the row.) See section 4. for an inital 490 set of ten extended flow attributes. 492 3.2 Specifying Distributions in RuleSets 494 At first sight it would seem neccessary to add extra features to the 495 RTFM Meter architecture to support distributions. This, however, is not 496 neccessarily the case. 498 What is actually needed is a way to specify, in a ruleset, the 499 distribution parameters. These include the number of counters, the 500 lower and upper bounds of the distribution, whether it is linear or 501 logarithmic, and any other details (e.g. the time interval for 502 short-term rate attributes). 504 Any attribute which is distribution-valued needs to be allocated a 505 RuleAttributeNumber value. These will be chosen so as to extend the 506 list already in the RTFM Meter MIB document [RTFM-MIB]. 508 Since distribution attributes are multi-valued it does not make sense to 509 test them. This means that a PushPkt (or PushPkttoAct) action must be 510 executed to add a new value to the distribution. The old-style 511 attributes use the 'mask' field to specify which bits of the value are 512 required, but again, this is not the case for distributions. Lastly, 513 the MatchedValue ('value') field of a PushPkt rule is never used. 514 Overall, therefore, the 'mask' and 'value' fields in the PushPkt rule 515 are available to specify distribution parameters. 517 Both these fields are at least six bytes long, the size of a MAC 518 address. All we have to do is specify how these bytes should be used! 519 As a starting point, the following is proposed (bytes are numbered 520 left-to-right. 522 Mask bytes: 523 1 Transform 1 = linear, 2 = logarithmic 524 2 Scale Factor Power of 10 multiplier for Limits 525 and Counts 526 3-4 Lower Limit Highest value for first bucket 527 5-6 Upper Limit Highest value for last bucket 529 Value bytes: 530 1 Buckets Number of buckets. Does not include 531 the 'overflow' bucket 532 2 Parameter-1 } Parameter use depends 533 3-4 Parameter-2 } on distribution-valued 534 5-6 Parameter-3 } attribute 536 For example, experiments with NeTraMet have used the following 537 rules: 539 FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next; 541 ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next; 543 FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next; 545 In these mask and value fields a dot indicates that the preceding number 546 is a one-byte integer, the exclamation marks indicate that the preceding 547 number is a two-byte integer, and the last number is two bytes wide 548 since this was the width of the preceding field. (Note that this 549 convention follows that for IP addresses - 130.216 means 130.216.0.0). 551 The first rule specifies that a distribution of packet sizes is to be 552 built. It uses an array of 60 buckets, storing values from 1 to 1500 553 bytes (i.e. linear steps of 25 bytes each bucket). Any packets with 554 size greater than 1500 will be counted in the 'overflow' bucket, hence 555 there are 61 counters for the distribution. 557 The second rule specifies an interarrival-time distribution, using a 558 logarithmic scale for an array of 60 counters (and an overflow bucket) 559 for rates from 1 ms to 1.8 s. Arrival times are measured in 560 microseconds, hence the scale factor of 3 indicates that the limits are 561 given in milliseconds. 563 The third rule specifies a bit-rate distribution, with the rate being 564 calculated every 5 seconds (parameter 1). A logarithmic array of 60 565 counters (and an overflow bucket) are used for rates from 1 kbps to 10 566 Mbps. The scale factor of 3 indicates that the limits are given in 567 thousands of bits per second (rates are measured in bps). 569 These distribution parameters will need to be stored in the meter so 570 that they are available for building the distribution. They will also 571 need to be read from the meter and saved together with the other flow 572 data. 574 3.3 Reading Distributions 576 Since RTFM flows are bi-directional, each distribution-valued quantity 577 (e.g. packet size, bit rate, etc.) will actually need two sets of 578 counters, one for packets travelling in each direction. It is tempting 579 to regard these as components of a single 'distribution,' but in many 580 cases only one of the two directions will be of interest; it seems 581 better to keep them in separate distributions. This is similar to the 582 old-style counter-valued attributes such as toOctets and fromOctets. 584 A distribution should be read by a meter reader as a single, structured 585 object. The components of a distribution object are 587 - 'mask' and 'value' fields from the rule which created the 588 distribution 590 - sequence of counters ('buckets' + overflow) 592 These can be easily collected into a BER-encoded octet string, and would 593 be read and referred to as a 'distribution.' 595 4 Extensions to the Rules Table, Attribute Numbers 597 The Rules Table of "old-style" attributes will be extended for the new 598 flow types. A list of actions, and keywords, such as "ToBitRate", 599 "ToPacketSize", etc. will be developed and used to inform an RTFM meter 600 to collect a set of extended values for a particular flow (or set of 601 flows). 603 Note. An implementation suggestion. 605 Value 65 is used for 'Distributions,' which has one bit set for 606 each distribution-valued attribute present for the flow, using 607 bit 0 for attribute 66, bit 1 for attribute 67, etc. 609 Here are ten possible distribution-valued attributes numbered according 610 to RTFM WG consensus at the 1997 meeting in Munich: 612 ToPacketSize(66) size of PDUs in bytes (i.e. number 613 FromPacketSize(67) of bytes actually transmitted) 615 ToInterarrivalTime(68) microseconds between successive packets 616 FromInterarrivalTime(69) travelling in the same direction 618 ToTurnaroundTime(70) microseconds between successive packets 619 FromTurnaroundTime(71) travelling in opposite directions 621 ToBitRate(72) short-term flow rate in bits per second 622 FromBitRate(73) Parameter 1 = rate interval in seconds 624 ToPDURate(74) short-term flow rate in PDUs per second 625 FromPDURate(75) Parameter 1 = rate interval in seconds 627 (76 .. 97) other distributions 629 It seems reasonable to allocate a further group of numbers 630 for the IIS attributes described above - 632 QoSService(98) 633 QoSStyle(99) 634 QoSRate(100) 635 QoSSlackTerm(101) 636 QoSTokenBucketRate(102) 637 QoSTokenBucketSize(103) 638 QoSPeakDataRate(104) 639 QoSMinPolicedUnit(105) 640 QoSMaxPolicedUnit(106) 642 The following attributes have also been implemented in NetFlowMet, a 643 version of the RTFM traffic meter - 644 MeterID(112) Integer identifying the router producing 645 NetFlow data (needed when NetFlowMet takes 646 data from several routers) 647 SourceASN(113) Autonomous System Number for flow's source 649 SourcePrefix(114) CIDR width used by router for determining 650 flow's source network 651 DestASN(115) Autonomous System Number for flow's destination 652 DestPrefix(116) CIDR width used by router for determining 653 flow's destination network 655 Some of the above, e.g. SourceASN and DestASN, might sensibly be 656 allocated attribute numbers below 64, making them part of the 'base' 657 RTFM meter attributes. 659 To support use of the RTFM meter as an 'Edge Device' for implementing 660 Differentiated Services, and/or for metering traffic carried via such 661 services, one more attribute will be useful: 663 DSCodePoint(118) DS Code Point (6 bits) for packets in this flow 665 Since the DS Code Point is a single field within a packet's IP header, 666 it is not possible to have both Source- and Dest- CodePoint attributes. 667 Possible uses of DSCodePoint include aggregating flows using the same 668 Code Points, and separating flows having the same end-point addresses 669 but using different Code Points. 671 5 Security Considerations 673 The attributes considered in this document represent properties of 674 traffic flows; they do not present any security issues in themselves. 675 The attributes may, however, be used in measuring the behaviour of 676 traffic flows, and the collected traffic flow data could be of 677 considerable value. Suitable precautions should be taken to keep such 678 data safe. 680 6 References 682 [C-B-P] Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable 683 Methodology for Internet Traffic Flow Profiling," 684 IEEE Journal on Selected Areas in Communications, 685 Vol. 13, No. 8, October 1995. 687 [GUAR-QOS] Shenker, S., Partridge, C., Guerin, R.: "Specification of 688 Guaranteed Quality of Service," RFC 2212, 1997. 690 [IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: 691 Users' Guide", CEFRIEL, Milan, 5 May 1998. 692 (See also http://www.cefriel.it/ntw) 694 [IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated 695 Services," RFC 2210, September 1997. 697 [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., 698 "Framework for IP Performance Metrics," RFC 2330, May 1998. 700 [RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management 701 Information Base," RFC 2021, February 1995. 703 [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management 704 Information Base Version 2 using SMIv2," 705 RFC 2021, January 1997. 707 [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow 708 Measurement: Architecture", RFC 2063, January 1997. 710 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 711 RFC 2064, January 1997. 713 7 Author's Addresses 715 Sig Handelman 716 IBM Research Division 717 T.J. Watson Research Center 718 P.O. Box 704 719 Yorktown Heights, NY 10598 721 Phone: +1 914 784 7626 722 E-mail: swhandel@us.ibm.com 724 Nevil Brownlee 725 Information Technology Systems & Services 726 The University of Auckland 727 Private Bag 92-019 728 Auckland, New Zealand 730 Phone: +64 9 373 7599 x8941 731 E-mail: n.brownlee@auckland.ac.nz 732 Greg Ruth 733 GTE Internteworking 734 3 Van de Graaff Drive 735 P.O. Box 3073 736 Burlington, MA 01803, U.S.A. 738 Phone: +1 781 262 4831 739 E-mail: grr1@gte.com 741 Stephen Stibler 742 IBM Research Division 743 T.J. Watson Research Center 744 P.O. Box 704 745 Yorktown Heights, NY 10598 747 Phone: +1 914 784 7191 748 E-mail: stibler@us.ibm.com 750 Expires February 2000