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