idnits 2.17.1 draft-ietf-rtfm-architecture-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: ---------------------------------------------------------------------------- == 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 100 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1174 has weird spacing: '... goto tes...' == Line 1923 has weird spacing: '...s/Hosts xxx ...' -- 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 8827 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) -- Possible downref: Non-RFC (?) normative reference: ref. '802-3' ** Downref: Normative reference to an Informational RFC: RFC 1272 (ref. 'ACT-BKG') ** Obsolete normative reference: RFC 2434 (ref. 'IANA-RFC') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. 'IPPM-FRM') -- Possible downref: Non-RFC (?) normative reference: ref. 'OSI-ACT' ** Obsolete normative reference: RFC 2064 (ref. 'RTFM-MIB') (Obsoleted by RFC 2720) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTFM-NEW' -- Possible downref: Non-RFC (?) normative reference: ref. 'RTFM-SRL' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 4 Cyndi Mills 5 GTE Laboratories, Inc 7 Greg Ruth 8 GTE Internteworking 10 August 1999 11 Expires February 2000 13 Traffic Flow Measurement: Architecture 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet Draft is a product of the Realtime Traffic Flow 38 Measurement Working Group of the IETF. 40 Abstract 42 This document provides a general framework for describing network 43 traffic flows, presents an architecture for traffic flow measurement and 44 reporting, discusses how this relates to an overall network traffic flow 45 architecture and indicates how it can be used within the Internet. 47 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 49 Contents 51 1 Statement of Purpose and Scope 3 52 1.1 Introduction . . . .. . . . . . . . . . . . . . . . . . . . . 3 54 2 Traffic Flow Measurement Architecture 5 55 2.1 Meters and Traffic Flows .. . . . . . . . . . . . . . . . . 5 56 2.2 Interaction Between METER and METER READER . . . . . . . . . 7 57 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 7 58 2.4 Interaction Between MANAGER and METER READER . . . . . . . . 8 59 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . 9 60 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . 10 61 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . 10 63 3 Traffic Flows and Reporting Granularity 10 64 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . 10 65 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . 13 66 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 14 68 4 Meters 16 69 4.1 Meter Structure . . . . . .. . . . . . . . . . . . . . . . . 17 70 4.2 Flow Table . . . .. . . . . . . . . . . . . . . . . . . . . . 19 71 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . 19 72 4.4 Rules and Rule Sets . . . .. . . . . . . . . . . . . . . . . 23 73 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . 28 74 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . 29 76 5 Meter Readers 29 77 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 30 78 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . 30 79 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 31 81 6 Managers 32 82 6.1 Between Manager and Meter: Control Functions . . . . . . . . 32 83 6.2 Between Manager and Meter Reader: Control Functions . . . . 33 84 6.3 Exception Conditions . . . .. . . . . . . . . . . . . . . . . 34 85 6.4 Standard Rule Sets . . . .. . . . . . . . . . . . . . . . . . 35 87 7 Security Considerations 36 88 7.1 Threat Analysis . . . . . .. . . . . . . . . . . . . . . . . 36 89 7.2 Countermeasures . . . . . .. . . . . . . . . . . . . . . . . 37 91 8 IANA Considerations 38 92 8.1 PME Opcodes . . . . . . . .. . . . . . . . . . . . . . . . . 38 93 8.2 RTFM Attributes . . . . . .. . . . . . . . . . . . . . . . . 39 95 9 APPENDICES 40 96 9.1 Appendix A: Network Characterisation . . . . . . . . . . . . 40 97 9.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 41 98 9.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 42 100 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 102 9.4 Appendix D: List of Meter Control Variables . . . . . . . . . 43 103 9.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 44 105 10 Acknowledgments 44 107 11 References 44 109 12 Author's Addresses 45 111 1 Statement of Purpose and Scope 113 1.1 Introduction 115 This document describes an architecture for traffic flow measurement and 116 reporting for data networks which has the following characteristics: 118 - The traffic flow model can be consistently applied to any protocol, 119 using address attributes in any combination at the 'adjacent' (see 120 below), network and transport layers of the networking stack. 122 - Traffic flow attributes are defined in such a way that they are 123 valid for multiple networking protocol stacks, and that traffic 124 flow measurement implementations are useful in multi-protocol 125 environments. 127 - Users may specify their traffic flow measurement requirements by 128 writing 'rule sets,' allowing them to collect the flow data they 129 need while ignoring other traffic. 131 - The data reduction effort to produce requested traffic flow 132 information is placed as near as possible to the network 133 measurement point. This minimises the volume of data to be 134 obtained (and transmitted across the network for storage), and 135 reduces the amount of processing required in traffic flow analysis 136 applications. 138 'Adjacent' (as used above) is a layer-neutral term for the next layer 139 down in a particular instantiation of protocol layering. Although 140 'adjacent' will usually imply the link layer (MAC addresses), it does 141 not implicitly advocate or dismiss any particular form of tunnelling or 142 layering. 144 The architecture specifies common metrics for measuring traffic flows. 145 By using the same metrics, traffic flow data can be exchanged and 146 compared across multiple platforms. Such data is useful for: 148 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 150 - Understanding the behaviour of existing networks, 152 - Planning for network development and expansion, 154 - Quantification of network performance, 156 - Verifying the quality of network service, and 158 - Attribution of network usage to users. 160 The traffic flow measurement architecture is deliberately structured 161 using address attributes which are defined in a consistent way at the 162 Adjacent, Network and Transport layers of the networking stack, allowing 163 specific implementations of the architecture to be used effectively in 164 multi-protocol environments. Within this document the term 'usage data' 165 is used as a generic term for the data obtained using the traffic flow 166 measurement architecture. 168 In principle one might define address attributes for higher layers, but 169 it would be very difficult to do this in a general way. However, if an 170 RTFM traffic meter were implemented within an application server (where 171 it had direct access to application-specific usage information), it 172 would be possible to use the rest of the rtfm architecture to collect 173 application-specific information. Use of the same model for both 174 network- and application-level measurement in this way could simplify 175 the development of generic analysis applications which process and/or 176 correlate both traffic and usage information. Experimental work in this 177 area is described in the RTFM 'New Attributes' document [RTFM-NEW]. 179 This document is not a protocol specification. It specifies and 180 structures the information that a traffic flow measurement system needs 181 to collect, describes requirements that such a system must meet, and 182 outlines tradeoffs which may be made by an implementor. 184 For performance reasons, it may be desirable to use traffic information 185 gathered through traffic flow measurement in lieu of network statistics 186 obtained in other ways. Although the quantification of network 187 performance is not the primary purpose of this architecture, the 188 measured traffic flow data may be used as an indication of network 189 performance. 191 A cost recovery structure decides "who pays for what." The major issue 192 here is how to construct a tariff (who gets billed, how much, for which 193 things, based on what information, etc). Tariff issues include 194 fairness, predictability (how well can subscribers forecast their 195 network charges), practicality (of gathering the data and administering 196 the tariff), incentives (e.g. encouraging off-peak use), and cost 197 recovery goals (100% recovery, subsidisation, profit making). Issues 198 such as these are not covered here. 200 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 202 Background information explaining why this approach was selected is 203 provided by the 'Internet Accounting Background' RFC [ACT-BKG]. 205 2 Traffic Flow Measurement Architecture 207 A traffic flow measurement system is used by Network Operations 208 personnel to aid in managing and developing a network. It provides a 209 tool for measuring and understanding the network's traffic flows. This 210 information is useful for many purposes, as mentioned in section 1 211 (above). 213 The following sections outline a model for traffic flow measurement, 214 which draws from working drafts of the OSI accounting model [OSI-ACT]. 216 2.1 Meters and Traffic Flows 218 At the heart of the traffic measurement model are network entities 219 called traffic METERS. Meters observe packets as they pass by a single 220 point on their way through the network and classify them into certain 221 groups. For each such group a meter will accumulate certain attributes, 222 for example the numbers of packets and bytes observed for the group. 223 These METERED TRAFFIC GROUPS may correspond to a user, a host system, a 224 network, a group of networks, a particular transport address (e.g. an IP 225 port number), any combination of the above, etc, depending on the 226 meter's configuration. 228 We assume that routers or traffic monitors throughout a network are 229 instrumented with meters to measure traffic. Issues surrounding the 230 choice of meter placement are discussed in the 'Internet Accounting 231 Background' RFC [ACT-BKG]. An important aspect of meters is that they 232 provide a way of succinctly aggregating traffic information. 234 For the purpose of traffic flow measurement we define the concept of a 235 TRAFFIC FLOW, which is like an artificial logical equivalent to a call 236 or connection. A flow is a portion of traffic, delimited by a start and 237 stop time, that belongs to one of the metered traffic groups mentioned 238 above. Attribute values (source/destination addresses, packet counts, 239 byte counts, etc.) associated with a flow are aggregate quantities 240 reflecting events which take place in the DURATION between the start and 241 stop times. The start time of a flow is fixed for a given flow; the 242 stop time may increase with the age of the flow. 244 For connectionless network protocols such as IP there is by definition 245 no way to tell whether a packet with a particular source/destination 246 combination is part of a stream of packets or not - each packet is 247 completely independent. A traffic meter has, as part of its 249 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 251 configuration, a set of 'rules' which specify the flows of interest, in 252 terms of the values of their attributes. It derives attribute values 253 from each observed packet, and uses these to decide which flow they 254 belong to. Classifying packets into 'flows' in this way provides an 255 economical and practical way to measure network traffic and subdivide it 256 into well-defined groups. 258 Usage information which is not derivable from traffic flows may also be 259 of interest. For example, an application may wish to record accesses to 260 various different information resources or a host may wish to record the 261 username (subscriber id) for a particular network session. Provision is 262 made in the traffic flow architecture to do this. In the future the 263 measurement model may be extended to gather such information from 264 applications and hosts so as to provide values for higher-layer flow 265 attributes. 267 As well as FLOWS and METERS, the traffic flow measurement model includes 268 MANAGERS, METER READERS and ANALYSIS APPLICATIONS, which are explained 269 in following sections. The relationships between them are shown by the 270 diagram below. Numbers on the diagram refer to sections in this 271 document. 273 MANAGER 274 / \ 275 2.3 / \ 2.4 276 / \ 277 / \ ANALYSIS 278 METER <-----> METER READER <-----> APPLICATION 279 2.2 2.7 281 - MANAGER: A traffic measurement manager is an application which 282 configures 'meter' entities and controls 'meter reader' entities. 283 It sends configuration commands to the meters, and supervises the 284 proper operation of each meter and meter reader. It may well be 285 convenient to combine the functions of meter reader and manager 286 within a single network entity. 288 - METER: Meters are placed at measurement points determined by 289 Network Operations personnel. Each meter selectively records 290 network activity as directed by its configuration settings. It can 291 also aggregate, transform and further process the recorded activity 292 before the data is stored. The processed and stored results are 293 called the 'usage data.' 295 - METER READER: A meter reader transports usage data from meters so 296 that it is available to analysis applications. 298 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 300 - ANALYSIS APPLICATION: An analysis application processes the usage 301 data so as to provide information and reports which are useful for 302 network engineering and management purposes. Examples include: 304 -TRAFFIC FLOW MATRICES, showing the total flow rates for many of 305 the possible paths within an internet. 307 -FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over 308 a period of time. 310 -USAGE DATA showing the total traffic volumes sent and received 311 by particular hosts. 313 The operation of the traffic measurement system as a whole is best 314 understood by considering the interactions between its components. 315 These are described in the following sections. 317 2.2 Interaction Between METER and METER READER 319 The information which travels along this path is the usage data itself. 320 A meter holds usage data in an array of flow data records known as the 321 FLOW TABLE. A meter reader may collect the data in any suitable manner. 322 For example it might upload a copy of the whole flow table using a file 323 transfer protocol, or read the records in the current flow set one at a 324 time using a suitable data transfer protocol. Note that the meter 325 reader need not read complete flow data records, a subset of their 326 attribute values may well be sufficient. 328 A meter reader may collect usage data from one or more meters. Data may 329 be collected from the meters at any time. There is no requirement for 330 collections to be synchronized in any way. 332 2.3 Interaction Between MANAGER and METER 334 A manager is responsible for configuring and controlling one or more 335 meters. Each meter's configuration includes information such as: 337 - Flow specifications, e.g. which traffic flows are to be measured, 338 how they are to be aggregated, and any data the meter is required 339 to compute for each flow being measured. 341 - Meter control parameters, e.g. the 'inactivity' time for flows (if 342 no packets belonging to a flow are seen for this time the flow is 343 considered to have ended, i.e. to have become idle). 345 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 347 - Sampling behaviour. Normally every packet will be observed. It 348 may sometimes be necessary to use sampling techniques so as to 349 observe only some of the packets (see following note). 351 A note about sampling: Current experience with the measurement 352 architecture shows that a carefully-designed and implemented meter 353 compresses the data sufficiently well that in normal LANs and WANs of 354 today sampling is seldom, if ever, needed. For this reason sampling 355 algorithms are not prescribed by the architecture. If sampling is 356 needed, e.g. for metering a very-high-speed network with fine-grained 357 flows, the sampling technique should be carefully chosen so as not to 358 bias the results. For a good introduction to this topic see the IPPM 359 Working Group's RFC "Framework for IP Performance Metrics" [IPPM-FRM]. 361 A meter may run several rule sets concurrently on behalf of one or more 362 managers, and any manager may download a set of flow specifications 363 (i.e. a 'rule set') to a meter. Control parameters which apply to an 364 individual rule set should be set by the manager after it downloads that 365 rule set. 367 One manager should be designated as the 'master' for a meter. 368 Parameters such as sampling behaviour, which affect the overall 369 operation of the meter, should only be set by the master manager. 371 2.4 Interaction Between MANAGER and METER READER 373 A manager is responsible for configuring and controlling one or more 374 meter readers. A meter reader may only be controlled by a single 375 manager. A meter reader needs to know at least the following for every 376 meter it is collecting usage data from: 378 - The meter's unique identity, i.e. its network name or address. 380 - How often usage data is to be collected from the meter. 382 - Which flow records are to be collected (e.g. all flows, flows for a 383 particular rule set, flows which have been active since a given 384 time, etc.). 386 - Which attribute values are to be collected for the required flow 387 records (e.g. all attributes, or a small subset of them) 389 Since redundant reporting may be used in order to increase the 390 reliability of usage data, exchanges among multiple entities must be 391 considered as well. These are discussed below. 393 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 395 2.5 Multiple METERs or METER READERs 397 -- METER READER A -- 398 / | \ 399 / | \ 400 =====METER 1 METER 2=====METER 3 METER 4===== 401 \ | / 402 \ | / 403 -- METER READER B -- 405 Several uniquely identified meters may report to one or more meter 406 readers. The diagram above gives an example of how multiple meters and 407 meter readers could be used. 409 In the diagram above meter 1 is read by meter reader A, and meter 4 is 410 read by meter reader B. Meters 1 and 4 have no redundancy; if either 411 meter fails, usage data for their network segments will be lost. 413 Meters 2 and 3, however, measure traffic on the same network segment. 414 One of them may fail leaving the other collecting the segment's usage 415 data. Meters 2 and 3 are read by meter reader A and by meter reader B. 416 If one meter reader fails, the other will continue collecting usage data 417 from both meters. 419 The architecture does not require multiple meter readers to be 420 synchronized. In the situation above meter readers A and B could both 421 collect usage data at the same intervals, but not necesarily at the same 422 times. Note that because collections are asynchronous it is unlikely 423 that usage records from two different meter readers will agree exactly. 425 If identical usage records were required from a single meter, a manager 426 could achieve this using two identical copies of a ruleset in that 427 meter. Let's call them RS1 and RS2, and assume that RS1 is running. 428 When a collection is to be made the manager switches the meter from RS1 429 to RS2, and directs the meter reader(s) to read flow data for RS1 from 430 the meter. For the next collection the manager switches back to RS1, 431 and so on. Note, however, that it is not possible to get identical 432 usage records from more than one meter, since there is no way for a 433 manager to switch rulesets in more than one meter at the same time. 435 If there is only one meter reader and it fails, the meters continue to 436 run. When the meter reader is restarted it can collect all of the 437 accumulated flow data. Should this happen, time resolution will be lost 438 (because of the missed collections) but overall traffic flow information 439 will not. The only exception to this would occur if the traffic volume 440 was sufficient to 'roll over' counters for some flows during the 441 failure; this is addressed in the section on 'Rolling Counters.' 443 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 445 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 447 Synchronization between multiple management systems is the province of 448 network management protocols. This traffic flow measurement 449 architecture specifies only the network management controls necessary to 450 perform the traffic flow measurement function and does not address the 451 more global issues of simultaneous or interleaved (possibly conflicting) 452 commands from multiple network management stations or the process of 453 transferring control from one network management station to another. 455 2.7 METER READERs and APPLICATIONs 457 Once a collection of usage data has been assembled by a meter reader it 458 can be processed by an analysis application. Details of analysis 459 applications - such as the reports they produce and the data they 460 require - are outside the scope of this architecture. 462 It should be noted, however, that analysis applications will often 463 require considerable amounts of input data. An important part of 464 running a traffic flow measurement system is the storage and regular 465 reduction of flow data so as to produce daily, weekly or monthly summary 466 files for further analysis. Again, details of such data handling are 467 outside the scope of this architecture. 469 3 Traffic Flows and Reporting Granularity 471 A flow was defined in section 2.1 above in abstract terms as follows: 473 "A TRAFFIC FLOW is an artifical logical equivalent to a call or 474 connection, belonging to a (user-specieied) METERED TRAFFIC 475 GROUP." 477 In practical terms, a flow is a stream of packets observed by the meter 478 as they pass across a network between two end points (or from a single 479 end point), which have been summarized by a traffic meter for analysis 480 purposes. 482 3.1 Flows and their Attributes 484 Every traffic meter maintains a table of 'flow records' for flows seen 485 by the meter. A flow record holds the values of the ATTRIBUTES of 486 interest for its flow. These attributes might include: 488 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 490 - ADDRESSES for the flow's source and destination. These comprise 491 the protocol type, the source and destination addresses at various 492 network layers (extracted from the packet header), and the number 493 of the interface on which the packet was observed. 495 - First and last TIMES when packets were seen for this flow, i.e. the 496 'creation' and 'last activity' times for the flow. 498 - COUNTS for 'forward' (source to destination) and 'backward' 499 (destination to source) components (e.g. packets and bytes) of the 500 flow's traffic. The specifying of 'source' and 'destination' for 501 flows is discussed in the section on packet matching below. 503 - OTHER attributes, e.g. the index of the flow's record in the flow 504 table and the rule set number for the rules which the meter was 505 running while the flow was observed. The values of these 506 attributes provide a way of distinguishing flows observed by a 507 meter at different times. 509 The attributes listed in this document (Appendix C) provide a basic 510 (i.e. useful minimum) set; IANA considerations for allocating new 511 attributes are set out in section 8 below. 513 A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS 514 attributes. For example, if a flow's address attributes were specified 515 as "source address = IP address 10.1.0.1, destination address = IP 516 address 26.1.0.1" then only IP packets from 10.1.0.1 to 26.1.0.1 and 517 back would be counted in that flow. If a flow's address attributes 518 specified only that "source address = IP address 10.1.0.1," then all IP 519 packets from and to 10.1.0.1 would be counted in that flow. 521 The addresses specifying a flow's address attributes may include one or 522 more of the following types: 524 - The INTERFACE NUMBER for the flow, i.e. the interface on which the 525 meter measured the traffic. Together with a unique address for the 526 meter this uniquely identifies a particular physical-level port. 528 - The ADJACENT ADDRESS, i.e. the address in the the next layer down 529 from the peer address in a particular instantiation of protocol 530 layering. Although 'adjacent' will usually imply the link layer, 531 it does not implicitly advocate or dismiss any particular form of 532 tunnelling or layering. 534 For example, if flow measurement is being performed using IP as the 535 network layer on an Ethernet LAN [802-3], an adjacent address will 536 normally be a six-octet Media Access Control (MAC) address. For a 537 host connected to the same LAN segment as the meter the adjacent 538 address will be the MAC address of that host. For hosts on other 539 LAN segments it will be the MAC address of the adjacent (upstream 540 or downstream) router carrying the traffic flow. 542 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 544 - The PEER ADDRESS, which identifies the source or destination of the 545 packet for the network layer (n) at which traffic measurement is 546 being performed. The form of a peer address will depend on the 547 network-layer protocol in use, and the measurement network layer 548 (n). 550 - The TRANSPORT ADDRESS, which identifies the source or destination 551 port for the packet, i.e. its (n+1) layer address. For example, if 552 flow measurement is being performed at the IP layer a transport 553 address is a two-octet UDP or TCP port number. 555 The four definitions above specify addresses for each of the four lowest 556 layers of the OSI reference model, i.e. Physical layer, Link layer, 557 Network layer and Transport layer. A FLOW RECORD stores both the VALUE 558 for each of its addresses (as described above) and a MASK specifying 559 which bits of the address value are being used and which are ignored. 560 Note that if address bits are being ignored the meter will set them to 561 zero, however their actual values are undefined. 563 One of the key features of the traffic measurement architecture is that 564 attributes have essentially the same meaning for different protocols, so 565 that analysis applications can use the same reporting formats for all 566 protocols. This is straightforward for peer addresses; although the 567 form of addresses differs for the various protocols, the meaning of a 568 'peer address' remains the same. It becomes harder to maintain this 569 correspondence at higher layers - for example, at the Network layer IP, 570 Novell IPX and AppleTalk all use port numbers as a 'transport address,' 571 but CLNP and DECnet have no notion of ports. 573 Reporting by adjacent intermediate sources and destinations or simply by 574 meter interface (most useful when the meter is embedded in a router) 575 supports hierarchical Internet reporting schemes as described in the 576 'Internet Accounting Background' RFC [ACT-BKG]. That is, it allows 577 backbone and regional networks to measure usage to just the next lower 578 level of granularity (i.e. to the regional and stub/enterprise levels, 579 respectively), with the final breakdown according to end user (e.g. to 580 source IP address) performed by the stub/enterprise networks. 582 In cases where network addresses are dynamically allocated (e.g. dial-in 583 subscribers), further subscriber identification will be necessary if 584 flows are to ascribed to individual users. Provision is made to further 585 specify the metered traffic group through the use of an optional 586 SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated 587 with a particular flow either through the current rule set or by 588 unspecified means within a meter. At this time a subscriber ID is an 589 arbitrary text string; later versions of the architecture may specify 590 details of its contents. 592 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 594 3.2 Granularity of Flow Measurements 596 GRANULARITY is the 'control knob' by which an application and/or the 597 meter can trade off the overhead associated with performing usage 598 reporting against its level of detail. A coarser granularity means a 599 greater level of aggregation; finer granularity means a greater level of 600 detail. Thus, the number of flows measured (and stored) at a meter can 601 be regulated by changing the granularity of their attributes. Flows are 602 like an adjustable pipe - many fine-granularity streams can carry the 603 data with each stream measured individually, or data can be bundled in 604 one coarse-granularity pipe. Time granularity may be controlled by 605 varying the reporting interval, i.e. the time between meter readings. 607 Flow granularity is controlled by adjusting the level of detail for the 608 following: 610 - The metered traffic group (address attributes, discussed above). 612 - The categorisation of packets (other attributes, discussed below). 614 - The lifetime/duration of flows (the reporting interval needs to be 615 short enough to measure them with sufficient precision). 617 The set of rules controlling the determination of each packet's metered 618 traffic group is known as the meter's CURRENT RULE SET. As will be 619 shown, the meter's current rule set forms an integral part of the 620 reported information, i.e. the recorded usage information cannot be 621 properly interpreted without a definition of the rules used to collect 622 that information. 624 Settings for these granularity factors may vary from meter to meter. 625 They are determined by the meter's current rule set, so they will change 626 if network Operations personnel reconfigure the meter to use a new rule 627 set. It is expected that the collection rules will change rather 628 infrequently; nonetheless, the rule set in effect at any time must be 629 identifiable via a RULE SET NUMBER. Granularity of metered traffic 630 groups is further specified by additional ATTRIBUTES. These attributes 631 include: 633 - Attributes which record information derived from other attribute 634 values. Six of these are defined (SourceClass, DestClass, 635 FlowClass, SourceKind, DestKind, FlowKind), and their meaning is 636 determined by the meter's rule set. For example, one could have a 637 subroutine in the rule set which determined whether a source or 638 destination peer address was a member of an arbitrary list of 639 networks, and set SourceClass/DestClass to one if the source/dest 640 peer address was in the list or to zero otherwise. 642 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 644 - Administratively specified attributes such as Quality of Service 645 and Priority, etc. These are not defined at this time. 647 Settings for these granularity factors may vary from meter to meter. 648 They are determined by the meter's current rule set, so they will change 649 if Network Operations personnel reconfigure the meter to use a new rule 650 set. 652 A rule set can aggregate groups of addresses in two ways. The simplest 653 is to use a mask in a single rule to test for an address within a masked 654 group. The other way is to use a sequence of rules to test for an 655 arbitrary group of (masked) address values, then use a PushRuleTo rule 656 to set a derived attribute (e.g. FlowKind) to indicate the flow's group. 658 The LIFETIME of a flow is the time interval which began when the meter 659 observed the first packet belonging to the flow and ended when it saw 660 the last packet. Flow lifetimes are very variable, but many - if not 661 most - are rather short. A meter cannot measure lifetimes directly; 662 instead a meter reader collects usage data for flows which have been 663 active since the last collection, and an analysis application may 664 compare the data from each collection so as to determine when each flow 665 actually stopped. 667 The meter does, however, need to reclaim memory (i.e. records in the 668 flow table) being held by idle flows. The meter configuration includes 669 a variable called InactivityTimeout, which specifies the minimum time a 670 meter must wait before recovering the flow's record. In addition, 671 before recovering a flow record the meter should be sure that the flow's 672 data has been collected by all meter readers which registered to collect 673 it. These two wait conditions are desired goals for the meter; they are 674 not difficult to achieve in normal usage, however the meter cannot 675 guarantee to fulfil them absolutely. 677 These 'lifetime' issues are considered further in the section on meter 678 readers (below). A complete list of the attributes currently defined is 679 given in Appendix C later in this document. 681 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 683 Once a usage record is sent, the decision needs to be made whether to 684 clear any existing flow records or to maintain them and add to their 685 counts when recording subsequent traffic on the same flow. The second 686 method, called rolling counters, is recommended and has several 687 advantages. Its primary advantage is that it provides greater 688 reliability - the system can now often survive the loss of some usage 689 records, such as might occur if a meter reader failed and later 690 restarted. The next usage record will very often contain yet another 691 reading of many of the same flow buckets which were in the lost usage 693 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 695 record. The 'continuity' of data provided by rolling counters can also 696 supply information used for "sanity" checks on the data itself, to guard 697 against errors in calculations. 699 The use of rolling counters does introduce a new problem: how to 700 distinguish a follow-on flow record from a new flow record. Consider 701 the following example. 703 CONTINUING FLOW OLD FLOW, then NEW FLOW 705 start time = 1 start time = 1 706 Usage record N: flow count = 2000 flow count = 2000 (done) 708 start time = 1 start time = 5 709 Usage record N+1: flow count = 3000 new flow count = 1000 711 Total count: 3000 3000 713 In the continuing flow case, the same flow was reported when its count 714 was 2000, and again at 3000: the total count to date is 3000. In the 715 OLD/NEW case, the old flow had a count of 2000. Its record was then 716 stopped (perhaps because of temporary idleness), but then more traffic 717 with the same characteristics arrived so a new flow record was started 718 and it quickly reached a count of 1000. The total flow count from both 719 the old and new records is 3000. 721 The flow START TIMESTAMP attribute is sufficient to resolve this. In 722 the example above, the CONTINUING FLOW flow record in the second usage 723 record has an old FLOW START timestamp, while the NEW FLOW contains a 724 recent FLOW START timestamp. A flow which has sporadic bursts of 725 activity interspersed with long periods of inactivity will produce a 726 sequence of flow activity records, each with the same set of address 727 attributes, but with increasing FLOW START times. 729 Each packet is counted in at most one flow for each running ruleset, so 730 as to avoid multiple counting of a single packet. The record of a 731 single flow is informally called a "bucket." If multiple, sometimes 732 overlapping, records of usage information are required (aggregate, 733 individual, etc), the network manager should collect the counts in 734 sufficiently detailed granularity so that aggregate and combination 735 counts can be reconstructed in post-processing of the raw usage data. 736 Alternatively, multiple rulesets could be used to collect data at 737 different granularities. 739 For example, consider a meter from which it is required to record both 740 'total packets coming in interface #1' and 'total packets arriving from 741 any interface sourced by IP address = a.b.c.d,' using a single rule set. 742 Although a bucket can be declared for each case, it is not clear how to 744 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 746 handle a packet which satisfies both criteria. It must only be counted 747 once. By default it will be counted in the first bucket for which it 748 qualifies, and not in the other bucket. Further, it is not possible to 749 reconstruct this information by post-processing. The solution in this 750 case is to define not two, but THREE buckets, each one collecting a 751 unique combination of the two criteria: 753 Bucket 1: Packets which came in interface 1, 754 AND were sourced by IP address a.b.c.d 756 Bucket 2: Packets which came in interface 1, 757 AND were NOT sourced by IP address a.b.c.d 759 Bucket 3: Packets which did NOT come in interface 1, 760 AND were sourced by IP address a.b.c.d 762 (Bucket 4: Packets which did NOT come in interface 1, 763 AND NOT sourced by IP address a.b.c.d) 765 The desired information can now be reconstructed by post-processing. 766 "Total packets coming in interface 1" can be found by adding buckets 1 & 767 2, and "Total packets sourced by IP address a.b.c.d" can be found by 768 adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly 769 required since its information is not of interest, but it is supplied 770 here in parentheses for completeness. 772 Alternatively, the above could be achieved by running two rule sets (A 773 and B), as follows: 775 Bucket 1: Packets which came in interface 1; 776 counted by rule set A. 778 Bucket 2: Packets which were sourced by IP address a.b.c.d; 779 counted by rule set B. 781 4 Meters 783 A traffic flow meter is a device for collecting data about traffic flows 784 at a given point within a network; we will call this the METERING POINT. 785 The header of every packet passing the network metering point is offered 786 to the traffic meter program. 788 A meter could be implemented in various ways, including: 790 - A dedicated small host, connected to a broadcast LAN (so that it 791 can see all packets as they pass by) and running a traffic meter 792 program. The metering point is the LAN segment to which the meter 793 is attached. 795 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 797 - A multiprocessing system with one or more network interfaces, with 798 drivers enabling a traffic meter program to see packets. In this 799 case the system provides multiple metering points - traffic flows 800 on any subset of its network interfaces can be measured. 802 - A packet-forwarding device such as a router or switch. This is 803 similar to (b) except that every received packet should also be 804 forwarded, usually on a different interface. 806 4.1 Meter Structure 808 An outline of the meter's structure is given in the following diagram: 810 Briefly, the meter works as follows: 812 - Incoming packet headers arrive at the top left of the diagram and 813 are passed to the PACKET PROCESSOR. 815 - The packet processor passes them to the Packet Matching Engine 816 (PME) where they are classified. 818 - The PME is a Virtual Machine running a pattern matching program 819 contained in the CURRENT RULE SET. It is invoked by the Packet 820 Processor, executes the rules in the current rule set as described 821 in section 4.3 below, and returns instructions on what to do with 822 the packet. 824 - Some packets are classified as 'to be ignored.' They are discarded 825 by the Packet Processor. 827 - Other packets are matched by the PME, which returns a FLOW KEY 828 describing the flow to which the packet belongs. 830 - The flow key is used to locate the flow's entry in the FLOW TABLE; 831 a new entry is created when a flow is first seen. The entry's data 832 fields (e.g. packet and byte counters) are updated. 834 - A meter reader may collect data from the flow table at any time. 835 It may use the 'collect' index to locate the flows to be collected 836 within the flow table. 838 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 840 packet +------------------+ 841 header | Current Rule Set | 842 | +--------+---------+ 843 | | 844 | | 845 +-------*--------+ 'match key' +------*-------+ 846 | Packet |---------------->| Packet | 847 | Processor | | Matching | 848 | |<----------------| Engine | 849 +--+----------+--+ 'flow key' +--------------+ 850 | | 851 | | 852 Ignore * | Count (via 'flow key') 853 | 854 +--*--------------+ 855 | 'Search' index | 856 +--------+--------+ 857 | 858 +--------*--------+ 859 | | 860 | Flow Table | 861 | | 862 +--------+--------+ 863 | 864 +--------*--------+ 865 | 'Collect' index | 866 +--------+--------+ 867 | 868 * 869 Meter Reader 871 The discussion above assumes that a meter will only be running a single 872 rule set. A meter may, however, run several rule sets concurrently. To 873 do this the meter maintains a table of current rulesets. The packet 874 processor matches each packet against every current ruleset, producing a 875 single flow table containing flows from all the rule sets. One way to 876 implement this is to use the Rule Set Number attribute in each flow as 877 part of the flow key. 879 A packet may only be counted once in a rule set (as explained in section 880 3.3 above), but it may be counted in any of the current rulesets. The 881 overall effect of doing this is somewhat similar to running several 882 independent meters, one for each rule set. 884 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 886 4.2 Flow Table 888 Every traffic meter maintains 'flow table,' i.e. a table of TRAFFIC FLOW 889 RECORDS for flows seen by the meter. Details of how the flow table is 890 maintained are given in section 4.5 below. A flow record contains 891 attribute values for its flow, including: 893 - Addresses for the flow's source and destination. These include 894 addresses and masks for various network layers (extracted from the 895 packet header), and the identity of the interface on which the 896 packet was observed. 898 - First and last times when packets were seen for this flow. 900 - Counts for 'forward' (source to destination) and 'backward' 901 (destination to source) components of the flow's traffic. 903 - Other attributes, e.g. state of the flow record (discussed below). 905 The state of a flow record may be: 907 - INACTIVE: The flow record is not being used by the meter. 909 - CURRENT: The record is in use and describes a flow which belongs to 910 the 'current flow set,' i.e. the set of flows recently seen by the 911 meter. 913 - IDLE: The record is in use and the flow which it describes is part 914 of the current flow set. In addition, no packets belonging to this 915 flow have been seen for a period specified by the meter's 916 InactivityTime variable. 918 4.3 Packet Handling, Packet Matching 920 Each packet header received by the traffic meter program is processed as 921 follows: 923 - Extract attribute values from the packet header and use them to 924 create a MATCH KEY for the packet. 926 - Match the packet's key against the current rule set, as explained 927 in detail below. 929 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 931 The rule set specifies whether the packet is to be counted or ignored. 932 If it is to be counted the matching process produces a FLOW KEY for the 933 flow to which the packet belongs. This flow key is used to find the 934 flow's record in the flow table; if a record does not yet exist for this 935 flow, a new flow record may be created. The data for the matching flow 936 record can then be updated. 938 For example, the rule set could specify that packets to or from any host 939 in IP network 130.216 are to be counted. It could also specify that 940 flow records are to be created for every pair of 24-bit (Class C) 941 subnets within network 130.216. 943 Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE 944 (PME) for matching. The PME is a Virtual Machine which uses a set of 945 instructions called RULES, i.e. a RULE SET is a program for the PME. A 946 packet's match key contains source (S) and destination (D) interface 947 identities, address values and masks. 949 If measured flows were unidirectional, i.e. only counted packets 950 travelling in one direction, the matching process would be simple. The 951 PME would be called once to match the packet. Any flow key produced by 952 a successful match would be used to find the flow's record in the flow 953 table, and that flow's counters would be updated. 955 Flows are, however, bidirectional, reflecting the forward and reverse 956 packets of a protocol interchange or 'session.' Maintaining two sets of 957 counters in the meter's flow record makes the resulting flow data much 958 simpler to handle, since analysis programs do not have to gather 959 together the 'forward' and 'reverse' components of sessions. 960 Implementing bi-directional flows is, of course, more difficult for the 961 meter, since it must decide whether a packet is a 'forward' packet or a 962 'reverse' one. To make this decision the meter will often need to 963 invoke the PME twice, once for each possible packet direction. 965 The diagram below describes the algorithm used by the traffic meter to 966 process each packet. Flow through the diagram is from left to right and 967 top to bottom, i.e. from the top left corner to the bottom right corner. 968 S indicates the flow's source address (i.e. its set of source address 969 attribute values) from the packet header, and D indicates its 970 destination address. 972 There are several cases to consider. These are: 974 - The packet is recognised as one which is TO BE IGNORED. 976 - The packet would MATCH IN EITHER DIRECTION. One situation in which 977 this could happen would be a rule set which matches flows within 978 network X (Source = X, Dest = X) but specifies that flows are to be 979 created for each subnet within network X, say subnets y and z. If, 980 for example a packet is seen for y->z, the meter must check that 981 flow z->y is not already current before creating y->z. 983 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 985 - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already 986 current, its forward or reverse counters are incremented. 987 Otherwise it is added to the flow table and then counted. 989 Ignore 990 --- match(S->D) -------------------------------------------------+ 991 | Suc | NoMatch | 992 | | Ignore | 993 | match(D->S) -----------------------------------------+ 994 | | Suc | NoMatch | 995 | | | | 996 | | +-------------------------------------------+ 997 | | | 998 | | Suc | 999 | current(D->S) ---------- count(D->S,r) --------------+ 1000 | | Fail | 1001 | | | 1002 | create(D->S) ----------- count(D->S,r) --------------+ 1003 | | 1004 | Suc | 1005 current(S->D) ------------------ count(S->D,f) --------------+ 1006 | Fail | 1007 | Suc | 1008 current(D->S) ------------------ count(D->S,r) --------------+ 1009 | Fail | 1010 | | 1011 create(S->D) ------------------- count(S->D,f) --------------+ 1012 | 1013 * 1015 The algorithm uses four functions, as follows: 1017 match(A->B) implements the PME. It uses the meter's current rule set 1018 to match the attribute values in the packet's match key. A->B means 1019 that the assumed source address is A and destination address B, i.e. 1020 that the packet was travelling from A to B. match() returns one of 1021 three results: 1023 'Ignore' means that the packet was matched but this flow is not 1024 to be counted. 1026 'NoMatch' means that the packet did not match. It might, however 1027 match with its direction reversed, i.e. from B to A. 1029 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1031 'Suc' means that the packet did match, i.e. it belongs to a flow 1032 which is to be counted. 1034 current(A->B) succeeds if the flow A-to-B is current - i.e. has 1035 a record in the flow table whose state is Current - and fails 1036 otherwise. 1038 create(A->B) adds the flow A-to-B to the flow table, setting the 1039 value for attributes - such as addresses - which remain constant, 1040 and zeroing the flow's counters. 1042 count(A->B,f) increments the 'forward' counters for flow A-to-B. 1043 count(A->B,r) increments the 'reverse' counters for flow A-to-B. 1044 'Forward' here means the counters for packets travelling from 1045 A to B. Note that count(A->B,f) is identical to count(B->A,r). 1047 When writing rule sets one must remember that the meter will normally 1048 try to match each packet in the reverse direction if the forward match 1049 does not succeed. It is particularly important that the rule set does 1050 not contain inconsistencies which will upset this process. 1052 Consider, for example, a rule set which counts packets from source 1053 network A to destination network B, but which ignores packets from 1054 source network B. This is an obvious example of an inconsistent rule 1055 set, since packets from network B should be counted as reverse packets 1056 for the A-to-B flow. 1058 This problem could be avoided by devising a language for specifying rule 1059 files and writing a compiler for it, thus making it much easier to 1060 produce correct rule sets. An example of such a language is described 1061 in the 'SRL' document [RTFM-SRL]. Another approach would be to write a 1062 'rule set consistency checker' program, which could detect problems in 1063 hand-written rule sets. 1065 Normally, the best way to avoid these problems is to write rule sets 1066 which only classify flows in the forward direction, and rely on the 1067 meter to handle reverse-travelling packets. 1069 Occasionally there can be situations when a rule set needs to know the 1070 direction in which a packet is being matched. Consider, for example, a 1071 rule set which wants to save some attribute values (source and 1072 destination addresses perhaps) for any 'unusual' packets. The rule set 1073 will contain a sequence of tests for all the 'usual' source addresses, 1074 follwed by a rule which will execute a 'NoMatch' action. If the match 1075 fails in the S->D direction, the NoMatch action will cause it to be 1076 retried. If it fails in the D->S direction, the packet can be counted 1077 as an 'unusual' packet. 1079 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1081 To count such an 'unusual' packet we need to know the matching 1082 direction: the MatchingStoD attribute provides this. To use it, one 1083 follows the source address tests with a rule which tests whether the 1084 matching direction is S->D (MatchingStoD value is 1). If so, a 1085 'NoMatch' action is executed. Otherwise, the packet has failed to match 1086 in both directions; we can save whatever attribute values are of 1087 interest and count the 'unusual' packet. 1089 4.4 Rules and Rule Sets 1091 A rule set is an array of rules. Rule sets are held within a meter as 1092 entries in an array of rule sets. 1094 Rule set 1 (the first entry in the rule set table) is built-in to the 1095 meter and cannot be changed. It is run when the meter is started up, 1096 and provides a very coarse reporting granularity; it is mainly useful 1097 for verifying that the meter is running, before a 'useful' rule set is 1098 downloaded to it. 1100 A meter also maintains an array of 'tasks,' which specify what rule sets 1101 the meter is running. Each task has a 'current' rule set (the one which 1102 it normally uses), and a 'standby' rule set (which will be used when the 1103 overall traffic level is unusually high). If a task is instructed to 1104 use rule set 0, it will cease measuring; all packets will be ignored 1105 until another (non-zero) rule set is made current. 1107 Each rule in a rule set is an instruction for the Packet Matching 1108 Engine, i.e. it is an instruction for a Virtual Machine. PME 1109 instructions have five component fields, forming two logical groups as 1110 follows: 1112 +-------- test ---------+ +---- action -----+ 1113 attribute & mask = value: opcode, parameter; 1115 The test group allows PME to test the value of an attribute. This is 1116 done by ANDing the attribute value with the mask and comparing the 1117 result with the value field. Note that there is no explicit provision 1118 to test a range, although this can be done where the range can be 1119 covered by a mask, e.g. attribute value less than 2048. 1121 The PME maintains a Boolean indicator called the 'test indicator,' which 1122 determines whether or not a rule's test is performed. The test 1123 indicator is initially set (true). 1125 The opcode group specifies what action may be performed when the rule is 1126 executed. Opcodes contain two flags: 'goto' and 'test,' as detailed in 1127 the table below. Execution begins with rule 1, the first in the rule 1128 set. It proceeds as follows: 1130 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1132 If the test indicator is true: 1133 Perform the test, i.e. AND the attribute value with the 1134 mask and compare it with the value. 1135 If these are equal the test has succeeded; perform the 1136 rule's action (below). 1137 If the test fails execute the next rule in the rule set. 1138 If there are no more rules in the rule set, return from the 1139 match() function indicating NoMatch. 1141 If the test indicator is false, or the test (above) succeeded: 1142 Set the test indicator to this opcode's test flag value. 1143 Determine the next rule to execute. 1144 If the opcode has its goto flag set, its parameter value 1145 specifies the number of the next rule. 1146 Opcodes which don't have their goto flags set either 1147 determine the next rule in special ways (Return), 1148 or they terminate execution (Ignore, NoMatch, Count, 1149 CountPkt). 1150 Perform the action. 1152 The PME maintains two 'history' data structures. The first, the 1153 'return' stack, simply records the index (i.e. 1-origin rule number) of 1154 each Gosub rule as it is executed; Return rules pop their Gosub rule 1155 index. Note that when the Ignore, NoMatch, Count and CountPkt actions 1156 are performed, PME execution is terminated regardless of whether the PME 1157 is executing a subroutine ('return' stack is non-empty) or not. 1159 The second data structure, the 'pattern' queue, is used to save 1160 information for later use in building a flow key. A flow key is built 1161 by zeroing all its attribute values, then copying attribute number, mask 1162 and value information from the pattern queue in the order it was 1163 enqueued. 1165 An attribute number identifies the attribute actually used in a test. 1166 It will usually be the rule's attribute field, unless the attribute is a 1167 'meter variable.' Details of meter variables are given after the table 1168 of opcode actions below. 1170 The opcodes are: 1172 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1174 opcode goto test 1176 1 Ignore 0 - 1177 2 NoMatch 0 - 1178 3 Count 0 - 1179 4 CountPkt 0 - 1180 5 Return 0 0 1181 6 Gosub 1 1 1182 7 GosubAct 1 0 1183 8 Assign 1 1 1184 9 AssignAct 1 0 1185 10 Goto 1 1 1186 11 GotoAct 1 0 1187 12 PushRuleTo 1 1 1188 13 PushRuleToAct 1 0 1189 14 PushPktTo 1 1 1190 15 PushPktToAct 1 0 1191 16 PopTo 1 1 1192 17 PopToAct 1 0 1194 The actions they perform are: 1196 Ignore: Stop matching, return from the match() function 1197 indicating that the packet is to be ignored. 1199 NoMatch: Stop matching, return from the match() function 1200 indicating failure. 1202 Count: Stop matching. Save this rule's attribute number, 1203 mask and value in the PME's pattern queue, then 1204 construct a flow key for the flow to which this 1205 packet belongs. Return from the match() function 1206 indicating success. The meter will use the flow 1207 key to search for the flow record for this 1208 packet's flow. 1210 CountPkt: As for Count, except that the masked value from 1211 the packet header (as it would have been used in 1212 the rule's test) is saved in the PME's pattern 1213 queue instead of the rule's value. 1215 Gosub: Call a rule-matching subroutine. Push the current 1216 rule number on the PME's return stack, set the 1217 test indicator then goto the specified rule. 1219 GosubAct: Same as Gosub, except that the test indicator is 1220 cleared before going to the specified rule. 1222 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1224 Return: Return from a rule-matching subroutine. Pop the 1225 number of the calling gosub rule from the PME's 1226 'return' stack and add this rule's parameter value 1227 to it to determine the 'target' rule. Clear the 1228 test indicator then goto the target rule. 1230 A subroutine call appears in a rule set as a Gosub 1231 rule followed by a small group of following rules. 1232 Since a Return action clears the test flag, the 1233 action of one of these 'following' rules will be 1234 executed; this allows the subroutine to return a 1235 result (in addition to any information it may save 1236 in the PME's pattern queue). 1238 Assign: Set the attribute specified in this rule to the 1239 parameter value specified for this rule. Set the 1240 test indicator then goto the specified rule. 1242 AssignAct: Same as Assign, except that the test indicator 1243 is cleared before going to the specified rule. 1245 Goto: Set the test indicator then goto the 1246 specified rule. 1248 GotoAct: Clear the test indicator then goto the specified 1249 rule. 1251 PushRuleTo: Save this rule's attribute number, mask and value 1252 in the PME's pattern queue. Set the test 1253 indicator then goto the specified rule. 1255 PushRuleToAct: Same as PushRuleTo, except that the test indicator 1256 is cleared before going to the specified rule. 1258 PushRuleTo actions may be used to save the value 1259 and mask used in a test, or (if the test is not 1260 performed) to save an arbitrary value and mask. 1262 PushPktTo: Save this rule's attribute number, mask, and the 1263 masked value from the packet header (as it would 1264 have been used in the rule's test), in the PME's 1265 pattern queue. Set the test indicator then goto 1266 the specified rule. 1268 PushPktToAct: Same as PushPktTo, except that the test indicator 1269 is cleared before going to the specified rule. 1271 PushPktTo actions may be used to save a value from 1272 the packet header using a specified mask. The 1273 simplest way to program this is to use a zero value 1275 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1277 for the PushPktTo rule's value field, and to 1278 GoToAct to the PushPktTo rule (so that it's test is 1279 not executed). 1281 PopTo: Delete the most recent item from the pattern 1282 queue, so as to remove the information saved by 1283 an earlier 'push' action. Set the test indicator 1284 then goto the specified rule. 1286 PopToAct: Same as PopTo, except that the test indicator 1287 is cleared before going to the specified rule. 1289 As well as the attributes applying directly to packets (such as 1290 SourcePeerAddress, DestTransAddress, etc.) the PME implements several 1291 further attribtes. These are: 1293 Null: Tests performed on the Null attribute always succeed. 1295 MatchingStoD: Indicates whether the PME is matching the packet 1296 with its addresses in 'wire order' or with its 1297 addresses reversed. MatchingStoD's value is 1 if the 1298 addresses are in wire order (StoD), and zero otherwise. 1300 v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They 1301 provide a way to pass parameters into rule-matching 1302 subroutines. Each may hold the number of a normal 1303 attribute; its value is set by an Assign action. 1304 When a meter variable appears as the attribute of a 1305 rule, its value specifies the actual attribute to be 1306 tested. For example, if v1 had been assigned 1307 SourcePeerAddress as its value, a rule with v1 as its 1308 attribute would actually test SourcePeerAddress. 1310 SourceClass, DestClass, FlowClass, 1311 SourceKind, DestKind, FlowKind: 1312 These six attributes may be set by executing PushRuleTo 1313 actions. They allow the PME to save (in flow records) 1314 information which has been built up during matching. 1315 Their values may be tested in rules; this allows one 1316 to set them early in a rule set, and test them later. 1318 The opcodes detailed above (with their above 'goto'and 'test' values) 1319 form a minimum set, but one which has proved very effective in current 1320 meter implementations. From time to time it may be useful to add 1321 further opcodes; IANA considerations for allocating these are set out in 1322 section 8 below. 1324 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1326 4.5 Maintaining the Flow Table 1328 The flow table may be thought of as a 1-origin array of flow records. 1329 (A particular implementation may, of course, use whatever data structure 1330 is most suitable). When the meter starts up there are no known flows; 1331 all the flow records are in the 'inactive' state. 1333 Each time a packet is matched for a flow which is not in a current flow 1334 set a flow record is created for it; the state of such a record is 1335 'current.' When selecting a record for the new flow the meter searches 1336 the flow table for an 'inactive' record. If no inactive records are 1337 available it will search for an 'idle' one instead. Note that there is 1338 no particular significance in the ordering of records within the flow 1339 table. 1341 A meter's memory management routines should aim to minimise the time 1342 spent finding flow records for new flows, so as to minimise the setup 1343 overhead associated with each new flow. 1345 Flow data may be collected by a 'meter reader' at any time. There is no 1346 requirement for collections to be synchronized. The reader may collect 1347 the data in any suitable manner, for example it could upload a copy of 1348 the whole flow table using a file transfer protocol, or it could read 1349 the records in the current flow set row by row using a suitable data 1350 transfer protocol. 1352 The meter keeps information about collections, in particular it 1353 maintains ReaderLastTime variables which remember the time the last 1354 collection was made by each reader. A second variable, InactivityTime, 1355 specifies the minimum time the meter will wait before considering that a 1356 flow is idle. 1358 The meter must recover records used for idle flows, if only to prevent 1359 it running out of flow records. Recovered flow records are returned to 1360 the 'inactive' state. A variety of recovery strategies are possible, 1361 including the following: 1363 One possible recovery strategy is to recover idle flow records as soon 1364 as possible after their data has been collected by all readers which 1365 have registered to do so. To implement this the meter could run a 1366 background process which scans the flow table looking for 'current' 1367 flows whose 'last packet' time is earlier than the meter's 1368 LastCollectTime. 1370 Another recovery strategy is to leave idle flows alone as long as 1371 possible, which would be acceptable if one was only interested in 1372 measuring total traffic volumes. It could be implemented by having the 1373 meter search for collected idle flows only when it ran low on 'inactive' 1374 flow records. 1376 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1378 One further factor a meter should consider before recovering a flow is 1379 the number of meter readers which have collected the flow's data. If 1380 there are multiple meter readers operating, each reader should collect a 1381 flow's data before its memory is recovered. 1383 Of course a meter reader may fail, so the meter cannot wait forever for 1384 it. Instead the meter must keep a table of active meter readers, with a 1385 timeout specified for each. If a meter reader fails to collect flow 1386 data within its timeout interval, the meter should delete that reader 1387 from the meter's active meter reader table. 1389 4.6 Handling Increasing Traffic Levels 1391 Under normal conditions the meter reader specifies which set of usage 1392 records it wants to collect, and the meter provides them. If, however, 1393 memory usage rises above the high-water mark the meter should switch to 1394 a STANDBY RULE SET so as to decrease the rate at which new flows are 1395 created. 1397 When the manager, usually as part of a regular poll, becomes aware that 1398 the meter is using its standby rule set, it could decrease the interval 1399 between collections. This would shorten the time that flows sit in 1400 memory waiting to be collected, allowing the meter to free flow memory 1401 faster. 1403 The meter could also increase its efforts to recover flow memory so as 1404 to reduce the number of idle flows in memory. When the situation 1405 returns to normal, the manager may request the meter to switch back to 1406 its normal rule set. 1408 5 Meter Readers 1410 Usage data is accumulated by a meter (e.g. in a router) as memory 1411 permits. It is collected at regular reporting intervals by meter 1412 readers, as specified by a manager. The collected data is recorded in 1413 stable storage as a FLOW DATA FILE, as a sequence of USAGE RECORDS. 1415 The following sections describe the contents of usage records and flow 1416 data files. Note, however, that at this stage the details of such 1417 records and files is not specified in the architecture. Specifying a 1418 common format for them would be a worthwhile future development. 1420 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1422 5.1 Identifying Flows in Flow Records 1424 Once a packet has been classified and is ready to be counted, an 1425 appropriate flow data record must already exist in the flow table; 1426 otherwise one must be created. The flow record has a flexible format 1427 where unnecessary identification attributes may be omitted. The 1428 determination of which attributes of the flow record to use, and of what 1429 values to put in them, is specified by the current rule set. 1431 Note that the combination of start time, rule set number and flow 1432 subscript (row number in the flow table) provide a unique flow 1433 identifier, regardless of the values of its other attributes. 1435 The current rule set may specify additional information, e.g. a computed 1436 attribute value such as FlowKind, which is to be placed in the attribute 1437 section of the usage record. That is, if a particular flow is matched 1438 by the rule set, then the corresponding flow record should be marked not 1439 only with the qualifying identification attributes, but also with the 1440 additional information. Using this feature, several flows may each 1441 carry the same FlowKind value, so that the resulting usage records can 1442 be used in post-processing or between meter reader and meter as a 1443 criterion for collection. 1445 5.2 Usage Records, Flow Data Files 1447 The collected usage data will be stored in flow data files on the meter 1448 reader, one file for each meter. As well as containing the measured 1449 usage data, flow data files must contain information uniquely 1450 identifiying the meter from which it was collected. 1452 A USAGE RECORD contains the descriptions of and values for one or more 1453 flows. Quantities are counted in terms of number of packets and number 1454 of bytes per flow. Other quantities, e.g. short-term flow rates, may be 1455 added later; work on such extensions is described in the RTFM 'New 1456 Attributes' document [RTFM-NEW]. 1458 Each usage record contains the metered traffic group identifier of the 1459 meter (a set of network addresses), a time stamp and a list of reported 1460 flows (FLOW DATA RECORDS). A meter reader will build up a file of usage 1461 records by regularly collecting flow data from a meter, using this data 1462 to build usage records and concatenating them to the tail of a file. 1463 Such a file is called a FLOW DATA FILE. 1465 A usage record contains the following information in some form: 1467 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1469 +-------------------------------------------------------------------+ 1470 | RECORD IDENTIFIERS: | 1471 | Meter Id (& digital signature if required) | 1472 | Timestamp | 1473 | Collection Rules ID | 1474 +-------------------------------------------------------------------+ 1475 | FLOW IDENTIFIERS: | COUNTERS | 1476 | Address List | Packet Count | 1477 | Subscriber ID (Optional) | Byte Count | 1478 | Attributes (Optional) | Flow Start/Stop Time | 1479 +-------------------------------------------------------------------+ 1481 5.3 Meter to Meter Reader: Usage Record Transmission 1483 The usage record contents are the raison d'etre of the system. The 1484 accuracy, reliability, and security of transmission are the primary 1485 concerns of the meter/meter reader exchange. Since errors may occur on 1486 networks, and Internet packets may be dropped, some mechanism for 1487 ensuring that the usage information is transmitted intact is needed. 1489 Flow data is moved from meter to meter reader via a series of protocol 1490 exchanges between them. This may be carried out in various ways, moving 1491 individual attribute values, complete flows, or the entire flow table 1492 (i.e. all the active and idle flows). One possible method of achieving 1493 this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' 1494 RFC [RTFM-MIB] gives details. Note that this is simply one example; the 1495 transfer of flow data from meter to meter reader is not specified in 1496 this document. 1498 The reliability of the data transfer method under light, normal, and 1499 extreme network loads should be understood before selecting among 1500 collection methods. 1502 In normal operation the meter will be running a rule file which provides 1503 the required degree of flow reporting granularity, and the meter 1504 reader(s) will collect the flow data often enough to allow the meter's 1505 garbage collection mechanism to maintain a stable level of memory usage. 1507 In the worst case traffic may increase to the point where the meter is 1508 in danger of running completely out of flow memory. The meter 1509 implementor must decide how to handle this, for example by switching to 1510 a default (extremely coarse granularity) rule set, by sending a trap 1511 message to the manager, or by attempting to dump flow data to the meter 1512 reader. 1514 Users of the Traffic Flow Measurement system should analyse their 1515 requirements carefully and assess for themselves whether it is more 1516 important to attempt to collect flow data at normal granularity 1518 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1520 (increasing the collection frequency as needed to keep up with traffic 1521 volumes), or to accept flow data with a coarser granularity. Similarly, 1522 it may be acceptable to lose flow data for a short time in return for 1523 being sure that the meter keeps running properly, i.e. is not 1524 overwhelmed by rising traffic levels. 1526 6 Managers 1528 A manager configures meters and controls meter readers. It does this 1529 via the interactions described below. 1531 6.1 Between Manager and Meter: Control Functions 1533 - DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of 1534 these, the 'default' rule set, is built in to the meter and cannot 1535 be changed; this is a diagnostic feature, ensuring that when a 1536 meter starts up it will be running a known ruleset. 1538 All other rule sets must be downloaded by the manager. A manager 1539 may use any suitable protocol exchange to achieve this, for example 1540 an FTP file transfer or a series of SNMP SETs, one for each row of 1541 the rule set. 1543 - SPECIFY METER TASK: Once the rule sets have been downloaded, the 1544 manager must instruct the meter which rule sets will be the 1545 'current' and 'standby' ones for each task the meter is to perform. 1547 - SET HIGH WATER MARK: A percentage of the flow table capacity, used 1548 by the meter to determine when to switch to its standby rule set 1549 (so as to increase the granularity of the flows and conserve the 1550 meter's flow memory). Once this has happened, the manager may also 1551 change the polling frequency or the meter's control parameters (so 1552 as to increase the rate at which the meter can recover memory from 1553 idle flows). The meter has a separate high water mark value for 1554 each task it is currently running. 1556 If the high traffic levels persist, the meter's normal rule set may 1557 have to be rewritten to permanently reduce the reporting 1558 granularity. 1560 - SET FLOW TERMINATION PARAMETERS: The meter should have the good 1561 sense in situations where lack of resources may cause data loss to 1562 purge flow records from its tables. Such records may include: 1564 - Flows that have already been reported to all registered meter 1565 readers, and show no activity since the last report, 1566 - Oldest flows, or 1567 - Flows with the smallest number of observed packets. 1569 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1571 - SET INACTIVITY TIMEOUT: This is a time in seconds since the last 1572 packet was seen for a flow. Flow records may be reclaimed if they 1573 have been idle for at least this amount of time, and have been 1574 collected in accordance with the current collection criteria. 1576 It might be useful if a manager could set the FLOW TERMINATION 1577 PARAMETERS to different values for different tasks. Current meter 1578 implementations have only single ('whole meter') values for these 1579 parameters, and experience to date suggests that this provides an 1580 adequate degree of control for the tasks. 1582 6.2 Between Manager and Meter Reader: Control Functions 1584 Because there are a number of parameters that must be set for traffic 1585 flow measurement to function properly, and viable settings may change as 1586 a result of network traffic characteristics, it is desirable to have 1587 dynamic network management as opposed to static meter configurations. 1588 Many of these operations have to do with space tradeoffs - if memory at 1589 the meter is exhausted, either the collection interval must be decreased 1590 or a coarser granularity of aggregation must be used to reduce the 1591 number of active flows. 1593 Increasing the collection interval effectively stores data in the meter; 1594 usage data in transit is limited by the effective bandwidth of the 1595 virtual link between the meter and the meter reader, and since these 1596 limited network resources are usually also used to carry user data (the 1597 purpose of the network), the level of traffic flow measurement traffic 1598 should be kept to an affordable fraction of the bandwidth. 1599 ("Affordable" is a policy decision made by the Network Operations 1600 personnel). At any rate, it must be understood that the operations 1601 below do not represent the setting of independent variables; on the 1602 contrary, each of the values set has a direct and measurable effect on 1603 the behaviour of the other variables. 1605 Network management operations follow: 1607 - MANAGER and METER READER IDENTIFICATION: The manager should ensure 1608 that meters are read by the correct set of meter readers, and take 1609 steps to prevent unauthorised access to usage information. The 1610 meter readers so identified should be prepared to poll if necessary 1611 and accept data from the appropriate meters. Alternate meter 1612 readers may be identified in case both the primary manager and the 1613 primary meter reader are unavailable. Similarly, alternate 1614 managers may be identified. 1616 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1618 - REPORTING INTERVAL CONTROL: The usual reporting interval should be 1619 selected to cope with normal traffic patterns. However, it may be 1620 possible for a meter to exhaust its memory during traffic spikes 1621 even with a correctly set reporting interval. Some mechanism 1622 should be available for the meter to tell the manager that it is in 1623 danger of exhausting its memory (by declaring a 'high water' 1624 condition), and for the manager to arbitrate (by decreasing the 1625 polling interval, letting nature take its course, or by telling the 1626 meter to ask for help sooner next time). 1628 - GRANULARITY CONTROL: Granularity control is a catch-all for all the 1629 parameters that can be tuned and traded to optimise the system's 1630 ability to reliably measure and store information on all the 1631 traffic (or as close to all the traffic as an administration 1632 requires). Granularity: 1634 - Controls the amount of address information identifying each 1635 flow, and 1636 - Determines the number of buckets into which user traffic will 1637 be lumped together. 1639 Since granularity is controlled by the meter's current rule set, 1640 the manager can only change it by requesting the meter to switch to 1641 a different rule set. The new rule set could be downloaded when 1642 required, or it could have been downloaded as part of the meter's 1643 initial configuration. 1645 - FLOW LIFETIME CONTROL: Flow termination parameters include timeout 1646 parameters for obsoleting inactive flows and removing them from 1647 tables, and maximum flow lifetimes. This is intertwined with 1648 reporting interval and granularity, and must be set in accordance 1649 with the other parameters. 1651 6.3 Exception Conditions 1653 Exception conditions must be handled, particularly occasions when the 1654 meter runs out of space for flow data. Since - to prevent an active 1655 task from counting any packet twice - packets can only be counted in a 1656 single flow, discarding records will result in the loss of information. 1657 The mechanisms to deal with this are as follows: 1659 - METER OUTAGES: In case of impending meter outages (controlled 1660 restarts, etc.) the meter could send a trap to the manager. The 1661 manager could then request one or more meter readers to pick up the 1662 data from the meter. 1664 Following an uncontrolled meter outage such as a power failure, the 1665 meter could send a trap to the manager indicating that it has 1666 restarted. The manager could then download the meter's correct 1667 rule set and advise the meter reader(s) that the meter is running 1669 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1671 again. Alternatively, the meter reader may discover from its 1672 regular poll that a meter has failed and restarted. It could then 1673 advise the manager of this, instead of relying on a trap from the 1674 meter. 1676 - METER READER OUTAGES: If the collection system is down or isolated, 1677 the meter should try to inform the manager of its failure to 1678 communicate with the collection system. Usage data is maintained 1679 in the flows' rolling counters, and can be recovered when the meter 1680 reader is restarted. 1682 - MANAGER OUTAGES: If the manager fails for any reason, the meter 1683 should continue measuring and the meter reader(s) should keep 1684 gathering usage records. 1686 - BUFFER PROBLEMS: The network manager may realise that there is a 1687 'low memory' condition in the meter. This can usually be 1688 attributed to the interaction between the following controls: 1690 - The reporting interval is too infrequent, or 1691 - The reporting granularity is too fine. 1693 Either of these may be exacerbated by low throughput or bandwidth 1694 of circuits carrying the usage data. The manager may change any of 1695 these parameters in response to the meter (or meter reader's) plea 1696 for help. 1698 6.4 Standard Rule Sets 1700 Although the rule table is a flexible tool, it can also become very 1701 complex. It may be helpful to develop some rule sets for common 1702 applications: 1704 - PROTOCOL TYPE: The meter records packets by protocol type. This 1705 will be the default rule table for Traffic Flow Meters. 1707 - ADJACENT SYSTEMS: The meter records packets by the MAC address of 1708 the Adjacent Systems (neighbouring originator or next-hop). 1709 (Variants on this table are "report source" or "report sink" only.) 1710 This strategy might be used by a regional or backbone network which 1711 wants to know how much aggregate traffic flows to or from its 1712 subscriber networks. 1714 - END SYSTEMS: The meter records packets by the IP address pair 1715 contained in the packet. (Variants on this table are "report 1716 source" or "report sink" only.) This strategy might be used by an 1717 End System network to get detailed host traffic matrix usage data. 1719 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1721 - TRANSPORT TYPE: The meter records packets by transport address; for 1722 IP packets this provides usage information for the various IP 1723 services. 1725 - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface 1726 report End Systems, for another interface report Adjacent Systems. 1727 This strategy might be used by an enterprise network to learn 1728 detail about local usage and use an aggregate count for the shared 1729 regional network. 1731 7 Security Considerations 1733 7.1 Threat Analysis 1735 A traffic flow measurement system may be subject to the following kinds 1736 of attacks: 1738 - ATTEMPTS TO DISABLE A TRAFFIC METER: An attacker may attempt to 1739 disrupt traffic measurement so as to prevent users being charged 1740 for network usage. For example, a network probe sending packets to 1741 a large number of destination and transport addresses could produce 1742 a sudden rise in the number of flows in a meter's flow table, thus 1743 forcing it to use its coarser standby rule set. 1745 - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain 1746 dadvantage or cause mischief (e.g. denial of service) by subverting 1747 any of the system elements - meters, meter readers or managers. 1749 - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to 1750 disclosure can be read through active or passive attacks unless it 1751 is suitably protected. Usage data may or may not be of this type. 1752 Control messages, traps, etc. are not likely to be considered 1753 sensitive to disclosure. 1755 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: 1756 Similarly, any data whose integrity is sensitive can be altered, 1757 replaced/injected or deleted through active or passive attacks 1758 unless it is suitably protected. Attackers may modify message 1759 streams to falsify usage data or interfere with the proper 1760 operation of the traffic flow measurement system. Therefore, all 1761 messages, both those containing usage data and those containing 1762 control data, should be considered vulnerable to such attacks. 1764 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1766 7.2 Countermeasures 1768 The following countermeasures are recommended to address the possible 1769 threats enumerated above: 1771 - ATTEMPTS TO DISABLE A TRAFFIC METER can't be completely countered. 1772 In practice, flow data records from network security attacks have 1773 proved very useful in determining what happened. The most 1774 effective approach is first to configure the meter so that it has 1775 three or more times as much flow memory as it needs in normal 1776 operation, and second to collect the flow data fairly frequently so 1777 as to minimise the time needed to recover flow memory after such an 1778 attack. 1780 - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use 1781 of authentication and access control services. 1783 - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a 1784 confidentiality (encryption) service. 1786 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is 1787 countered through the use of an integrity service. 1789 A Traffic Measurement system must address all of these concerns. Since 1790 a high degree of protection is required, the use of strong cryptographic 1791 methodologies is recommended. The security requirements for 1792 communication between pairs of traffic measurmement system elements are 1793 summarized in the table below. It is assumed that meters do not 1794 communicate with other meters, and that meter readers do not communicate 1795 directly with other meter readers (if synchronization is required, it is 1796 handled by the manager, see Section 2.5). Each entry in the table 1797 indicates which kinds of security services are required. Basically, the 1798 requirements are as follows: 1800 Security Service Requirements for RTFM elements 1802 +------------------------------------------------------------------+ 1803 | from\to | meter | meter reader | application | manager | 1804 |---------+--------------+--------------+-------------+------------| 1805 | meter | N/A | authent | N/A | authent | 1806 | | | acc ctrl | | acc ctrl | 1807 | | | integrity | | | 1808 | | | confid ** | | | 1809 |---------+--------------+--------------+-------------+------------| 1810 | meter | authent | N/A | authent | authent | 1811 | reader | acc ctrl | | acc ctrl | acc ctrl | 1812 | | | | integrity | | 1813 | | | | confid ** | | 1814 |---------+--------------+--------------+-------------+------------| 1816 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1818 |---------+--------------+--------------+-------------+------------| 1819 | appl | N/A | authent | | | 1820 | | | acc ctrl | ## | ## | 1821 |---------+--------------+--------------+-------------+------------| 1822 | manager | authent | authent | ## | authent | 1823 | | acc ctrl | acc ctrl | | acc ctrl | 1824 | | integrity | integrity | | integrity | 1825 +------------------------------------------------------------------+ 1827 N/A = Not Applicable ** = optional ## = outside RTFM scope 1829 - When any two elements intercommunicate they should mutually 1830 authenticate themselves to one another. This is indicated by 1831 'authent' in the table. Once authentication is complete, an 1832 element should check that the requested type of access is allowed; 1833 this is indicated on the table by 'acc ctrl.' 1835 - Whenever there is a transfer of information its integrity should be 1836 protected. 1838 - Whenever there is a transfer of usage data it should be possible to 1839 ensure its confidentiality if it is deemed sensitive to disclosure. 1840 This is indicated by 'confid' in the table. 1842 Security protocols are not specified in this document. The system 1843 elements' management and collection protocols are responsible for 1844 providing sufficient data integrity, confidentiality, authentication and 1845 access control services. 1847 8 IANA Considerations 1849 The RTFM Architecture, as set out in this document, has two sets of 1850 assigned numbers. Considerations for assigning them are discussed in 1851 this section, using the example policies as set out in the "Guidelines 1852 for IANA Considerations" document [IANA-RFC]. 1854 8.1 PME Opcodes 1856 The Pattern Matching Engine (PME) is a virtual machine, executing RTFM 1857 rules as its instructions. The PME opcodes appear in the 'action' field 1858 of an RTFM rule. The current list of opcodes, and their values for the 1859 PME's 'goto' and 'test' flags, are set out in section 4.4 above ("Rules 1860 and Rulesets). 1862 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1864 The PME opcodes are pivotal to the RTFM architecture, since they must be 1865 implemented in every RTFM meter. Any new opcodes must therefore be 1866 allocated through an IETF Consensus action [IANA-RFC]. 1868 Opcodes are simply non-negative integers, but new opcodes should be 1869 allocated sequentially so as to keep the total opcode range as small as 1870 possible. 1872 8.2 RTFM Attributes 1874 Attribute numbers in the range of 0-511 are globally unique and are 1875 allocated according to an IETF Consensus action [IANA-RFC]. Appendix C 1876 of this document allocates a basic (i.e. useful minimum) set of 1877 attribtes; they are assigned numbers in the range 0 to 63. The RTFM 1878 working group is working on an extended set of attributes, which will 1879 have numbers in the range 64 to 127. 1881 Vendor-specific attribute numbers are in the range 512-1023, and will be 1882 allocated using the First Come FIrst Served policy [IANA-RFC]. Vendors 1883 requiring attribute numbers should submit a request to IANA giving the 1884 attribute names: IANA will allocate them the next available numbers. 1886 Attribute numbers 1024 and higher are Reserved for Private Use 1887 [IANA-RFC]. Implementors wishing to experiment with further new 1888 attributes should use attribute numbers in this range. 1890 Attribute numbers are simply non-negative integers. When writing 1891 specifications for attributes, implementors must give sufficient detail 1892 for the new attributes to be easily added to the RTFM Meter MIB 1893 [RTFM-MIB]. In particular, they must indicate whether the new attributes 1894 may be: 1896 - tested in an IF statement 1897 - saved by a SAVE statement or set by a STORE statement 1898 - read from an RTFM meter 1900 (IF, SAVE and STORE are statements in the SRL Ruleset Language 1901 [RTFM-SRL]). 1903 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1905 9 APPENDICES 1907 9.1 Appendix A: Network Characterisation 1909 Internet users have extraordinarily diverse requirements. Networks 1910 differ in size, speed, throughput, and processing power, among other 1911 factors. There is a range of traffic flow measurement capabilities and 1912 requirements. For traffic flow measurement purposes, the Internet may 1913 be viewed as a continuum which changes in character as traffic passes 1914 through the following representative levels: 1916 International | 1917 Backbones/National --------------- 1918 / \ 1919 Regional/MidLevel ---------- ---------- 1920 / \ \ / / \ 1921 Stub/Enterprise --- --- --- ---- ---- 1922 ||| ||| ||| |||| |||| 1923 End-Systems/Hosts xxx xxx xxx xxxx xxxx 1925 Note that mesh architectures can also be built out of these components, 1926 and that these are merely descriptive terms. The nature of a single 1927 network may encompass any or all of the descriptions below, although 1928 some networks can be clearly identified as a single type. 1930 BACKBONE networks are typically bulk carriers that connect other 1931 networks. Individual hosts (with the exception of network management 1932 devices and backbone service hosts) typically are not directly connected 1933 to backbones. 1935 REGIONAL networks are closely related to backbones, and differ only in 1936 size, the number of networks connected via each port, and geographical 1937 coverage. Regionals may have directly connected hosts, acting as hybrid 1938 backbone/stub networks. A regional network is a SUBSCRIBER to the 1939 backbone. 1941 STUB/ENTERPRISE networks connect hosts and local area networks. 1942 STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 1943 networks. 1945 END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above 1946 networks. 1948 Providing a uniform identification of the SUBSCRIBER in finer 1949 granularity than that of end-system, (e.g. user/account), is beyond the 1950 scope of the current architecture, although an optional attribute in the 1952 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 1954 traffic flow measurement record may carry system-specific 'user 1955 identification' labels so that meters can implement proprietary or 1956 non-standard schemes for the attribution of network traffic to 1957 responsible parties. 1959 9.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 1961 Initial recommended traffic flow measurement conventions are outlined 1962 here according to the following Internet building blocks. It is 1963 important to understand what complexity reporting introduces at each 1964 network level. Whereas the hierarchy is described top-down in the 1965 previous section, reporting requirements are more easily addressed 1966 bottom-up. 1968 End-Systems 1969 Stub Networks 1970 Enterprise Networks 1971 Regional Networks 1972 Backbone Networks 1974 END-SYSTEMS are currently responsible for allocating network usage to 1975 end-users, if this capability is desired. From the Internet Protocol 1976 perspective, end-systems are the finest granularity that can be 1977 identified without protocol modifications. Even if a meter violated 1978 protocol boundaries and tracked higher-level protocols, not all packets 1979 could be correctly allocated by user, and the definition of user itself 1980 varies widely from operating system to operating system (e.g. how to 1981 trace network usage back to users from shared processes). 1983 STUB and ENTERPRISE networks will usually collect traffic data either by 1984 end-system network address or network address pair if detailed reporting 1985 is required in the local area network. If no local reporting is 1986 required, they may record usage information in the exit router to track 1987 external traffic only. (These are the only networks which routinely use 1988 attributes to perform reporting at granularities finer than end-system 1989 or intermediate-system network address.) 1991 REGIONAL networks are intermediate networks. In some cases, subscribers 1992 will be enterprise networks, in which case the intermediate system 1993 network address is sufficient to identify the regional's immediate 1994 subscriber. In other cases, individual hosts or a disjoint group of 1995 hosts may constitute a subscriber. Then end-system network address 1996 pairs need to be tracked for those subscribers. When the source may be 1997 an aggregate entity (such as a network, or adjacent router representing 1999 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 2001 traffic from a world of hosts beyond) and the destination is a singular 2002 entity (or vice versa), the meter is said to be operating as a HYBRID 2003 system. 2005 At the regional level, if the overhead is tolerable it may be 2006 advantageous to report usage both by intermediate system network address 2007 (e.g. adjacent router address) and by end-system network address or 2008 end-system network address pair. 2010 BACKBONE networks are the highest level networks operating at higher 2011 link speeds and traffic levels. The high volume of traffic will in most 2012 cases preclude detailed traffic flow measurement. Backbone networks 2013 will usually account for traffic by adjacent routers' network addresses. 2015 9.3 Appendix C: List of Defined Flow Attributes 2017 This Appendix provides a checklist of the attributes defined to date; 2018 others will be added later as the Traffic Measurement Architecture is 2019 further developed. 2021 Note that this table gives only a very brief summary. The Meter MIB 2022 [RTFM-MIB] provides the definitive specification of attributes and their 2023 allowed values. The MIB variables which represent flow attributes have 2024 'flowData' prepended to their names to indicate that they belong to the 2025 MIB's flowData table. 2027 0 Null 2029 4 SourceInterface Integer Source Address 2030 5 SourceAdjacentType Integer 2031 6 SourceAdjacentAddress String 2032 7 SourceAdjacentMask String 2033 8 SourcePeerType Integer 2034 9 SourcePeerAddress String 2035 10 SourcePeerMask String 2036 11 SourceTransType Integer 2037 12 SourceTransAddress String 2038 13 SourceTransMask String 2040 14 DestInterface Integer Destination Address 2041 15 DestAdjacentType Integer 2042 16 DestAdjacentAddress String 2043 17 DestAdjacentMask String 2044 18 DestPeerType Integer 2045 19 DestPeerAddress String 2046 20 DestPeerMask String 2047 21 DestTransType Integer 2048 22 DestTransAddress String 2049 23 DestTransMask String 2051 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 2053 26 RuleSet Integer Meter attribute 2055 27 ToOctets Integer Source-to-Dest counters 2056 28 ToPDUs Integer 2057 29 FromOctets Integer Dest-to-Source counters 2058 30 FromPDUs Integer 2059 31 FirstTime Timestamp Activity times 2060 32 LastActiveTime Timestamp 2061 33 SourceSubscriberID String Session attributes 2062 34 DestSubscriberID String 2063 35 SessionID String 2065 36 SourceClass Integer 'Computed' attributes 2066 37 DestClass Integer 2067 38 FlowClass Integer 2068 39 SourceKind Integer 2069 40 DestKind Integer 2070 41 FlowKind Integer 2072 50 MatchingStoD Integer PME variable 2074 51 v1 Integer Meter Variables 2075 52 v2 Integer 2076 53 v3 Integer 2077 54 v4 Integer 2078 55 v5 Integer 2080 65 2081 .. 'Extended' attributes (to be defined by the RTFM working group) 2082 127 2084 9.4 Appendix D: List of Meter Control Variables 2086 Meter variables: 2087 Flood Mark Percentage 2088 Inactivity Timeout (seconds) Integer 2090 'per task' variables: 2091 Current Rule Set Number Integer 2092 Standby Rule Set Number Integer 2093 High Water Mark Percentage 2095 'per reader' variables: 2096 Reader Last Time Timestamp 2098 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 2100 9.5 Appendix E: Changes Introduced Since RFC 2063 2102 The first version of the Traffic Flow Measurement Architecture was 2103 published as RFC 2063 in January 1997. The most significant changes 2104 made since then are summarised below. 2106 - A Traffic Meter can now run multiple rule sets concurrently. This 2107 makes a meter much more useful, and required only minimal changes 2108 to the architecture. 2110 - 'NoMatch' replaces 'Fail' as an action. This name was agreed to at 2111 the Working Group 1996 meeting in Montreal; it better indicates 2112 that although a particular match has failed, it may be tried again 2113 with the packet's addresses reversed. 2115 - The 'MatchingStoD' attribute has been added. This is a Packet 2116 Matching Engine (PME) attribute indicating that addresses are being 2117 matched in StoD (i.e. 'wire') order. It can be used to perform 2118 different actions when the match is retried, thereby simplifying 2119 some kinds of rule sets. It was discussed and agreed to at the San 2120 Jose meeting in 1996. 2122 - Computed attributes (Class and Kind) may now be tested within a 2123 rule set. This lifts an unneccessary earlier restriction. 2125 - The list of attribute numbers has been extended to define ranges 2126 for 'basic' attributes (in this document) and 'extended' attributes 2127 (currently being developed by the RTFM Working Group). 2129 - The 'Security Considerations' section has been completely 2130 rewritten. It provides an evaluation of traffic measurement 2131 security risks and their countermeasures. 2133 10 Acknowledgments 2135 An initial draft of this document was produced under the auspices of the 2136 IETF's Internet Accounting Working Group with assistance from SNMP, RMON 2137 and SAAG working groups. Particular thanks are due to Stephen Stibler 2138 (IBM Research) for his patient and careful comments during the 2139 preparation of this draft. 2141 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 2143 11 References 2145 [802-3] IEEE 802.3/ISO 8802-3 Information Processing Systems - Local 2146 Area Networks - Part 3: Carrier sense multiple access with 2147 collision detection (CSMA/CD) access method and physical 2148 layer specifications, 2nd edition, September 21, 1990. 2150 [ACT-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 2151 Background," RFC 1272, November 1991. 2153 [IANA-RFC] Alvestrand, H. and T. Narten, "Guidelines for Writing an 2154 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2155 October 1998. 2157 [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., 2158 "Framework for IP Performance Metrics," RFC 2330, May 1998. 2160 [OSI-ACT] International Standards Organisation (ISO), "Management 2161 Framework," Part 4 of Information Processing Systems Open 2162 Systems Interconnection Basic Reference Model, 2163 ISO 7498-4, 1994. 2165 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 2166 RFC 2064, January 1997. 2168 [RTFM-NEW] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S., 2169 "New Attributes for Traffic Flow Measurment," Internet 2170 Draft 'Work in progress' to become an Informational RFC 2172 [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic 2173 Flows and Specifying Actions for Flow Groups," Internet 2174 Draft 'Work in progress' to become an Informational RFC 2176 12 Author's Addresses 2178 Nevil Brownlee 2179 Information Technology Systems & Services 2180 The University of Auckland 2181 Private Bag 92-019 2182 Auckland, New Zealand 2184 Phone: +64 9 373 7599 x8941 2185 E-mail: n.brownlee@auckland.ac.nz 2187 INTERNET-DRAFT Traffic Flow Measurement: Architecture August 99 2189 Cyndi Mills 2190 GTE Laboratories, Inc 2191 40 Sylvan Rd. 2192 Waltham, MA 02451, U.S.A. 2194 Phone: +1 781 466 4278 2195 E-mail: cmills@gte.com 2197 Greg Ruth 2198 GTE Internteworking 2199 3 Van de Graaff Drive 2200 P.O. Box 3073 2201 Burlington, MA 01803, U.S.A. 2203 Phone: +1 781 262 4831 2204 E-mail: gruth@gte.com 2206 Expires February 2000