idnits 2.17.1 draft-ietf-rtfm-architecture-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 96 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 43 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 1161 has weird spacing: '... goto tes...' == Line 1797 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 (January 1999) is 9232 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) ** Downref: Normative reference to an Informational RFC: RFC 1272 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Brownlee, Mills, Ruth 2 INTERNET-DRAFT The University of Auckland 3 July 98 4 Expires January 1999 6 Traffic Flow Measurement: Architecture 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. This Internet Draft is a product of the 16 Realtime Traffic Flow Measurement Working Group of the IETF. 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet Drafts as 21 reference material or to cite them other than as a "working draft" or 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 27 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 28 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document provides a general framework for describing network 33 traffic flows, presents an architecture for traffic flow measurement and 34 reporting, discusses how this relates to an overall network traffic flow 35 architecture and indicates how it can be used within the Internet. 37 Contents 39 1 Statement of Purpose and Scope 3 40 1.1 Brief Technical Specification (TS) . . . . . . . . . . . . . . 3 41 1.2 Applicability Statement (AS) . . . . . . . . . . . . . . . . . 3 42 1.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 46 2 Traffic Flow Measurement Architecture 6 47 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 6 48 2.2 Interaction Between METER and METER READER . . . . . . . . . . 8 49 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8 50 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 9 51 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 52 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 53 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 11 55 3 Traffic Flows and Reporting Granularity 11 56 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 57 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 14 58 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15 60 4 Meters 17 61 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 18 62 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 20 64 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 65 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27 66 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28 68 5 Meter Readers 29 69 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 29 70 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29 71 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30 73 6 Managers 31 74 6.1 Between Manager and Meter: Control Functions . . . . . . . . 31 75 6.2 Between Manager and Meter Reader: Control Functions . . . . . 32 76 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33 77 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34 79 7 Security Considerations 35 80 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35 81 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 36 83 8 APPENDICES 38 84 8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 38 85 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 39 86 8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 40 87 8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 41 88 8.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 41 90 9 Acknowledgments 42 92 10 References 42 94 11 Author's Address 43 96 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 98 1 Statement of Purpose and Scope 100 1.1 Brief Technical Specification (TS) 102 RTFM provides for the measurement of network traffic FLOWS, i.e. 104 - a method of specifying traffic flows within 105 a network 106 - a hierarchy of devices (meters, meter readers, managers) 107 for measuring the specified flows 108 - a mechanism for configuring meters and meter readers, 109 and for collecting the flow data from remote meters 111 The RTFM Meter is designed so as to do as much data reduction work as 112 possible. This minimizes the amount of data to be read and the amount 113 of processing needed to produce useful reports from it. 115 RTFM flow data can be used for a wide range of purposes, such as usage 116 accounting, long-term recording of network usage (classified by IP 117 address attributes) and real-time analysis of traffic flows at remote 118 metering points. 120 1.2 Applicability Statement (AS) 122 To use RTFM for collecting network traffic information one must first 123 consider where in the network traffic flows are to be measured. Once 124 this is decided, an RTFM Meter must be installed at each chosen 125 measurement point. 127 At least one Meter Reader is needed to collect the measured data from 128 the meters, and a single Manager is needed to control the meters and 129 meter readers. 131 RTFM Meters may be single- or multi-user hosts running a meter program 132 (one such program is available as free software, a second is under 133 development at IBM Research). Alternatively, meters could be run as 134 firmware in switches or routers. A hybrid approach, where an RTFM meter 135 takes raw traffic data from a router, provides another useful 136 implementation path. 138 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 140 RTFM Managers are programs running on a Unix host, communicating with 141 meters and meter readers via the network. In principle any protocol 142 could be used for this, but current implementations use the RTFM Meter 143 MIB [4] to store and access the flow data. This will require networks 144 using RTFM to implement the IP protocol so as to send and receive SNMP 145 requests carried in UDP datagrams. 147 As indicated above, a meter must handle SNMP over UDP. If it runs on a 148 dedicated host it must also respond to ARP requests. To aid in 149 troubleshooting, it should respond to ICMP echo (ping) requests. These 150 remarks also apply to RTFM Meter Readers and Managers. 152 (The paragraphs above describe the current implementations of RTFM. 153 Its architecture is not limited to having the meter be an SNMP agent - 154 other communication and storage methods could be used. For example, 155 configuration data could be downloaded via FTP, data could be stored in 156 an SQL database and meter readers could get it via SQL requests.) 158 Users of RTFM should note that installing meters, meter readers and 159 managers merely provides one with the capability to collect flow data. 160 Further installation work will be needed to develop configuration files 161 ('RTFM rulesets') for each meter, data processing applications to 162 analyse the flow data, and various scripts, cron jobs, etc. so as to 163 create a useful production-quality measurement system which suits a 164 user's particular needs. 166 1.3 Introduction 168 This document describes an architecture for traffic flow measurement 169 and reporting for data networks; it has the following characteristics: 171 - The traffic flow model can be consistently applied to any 172 protocol/application at any network layer (e.g. network, 173 transport, application layers). 175 - Traffic flow attributes are defined in such a way that they are 176 valid for multiple networking protocol stacks, and that traffic 177 flow measurement implementations are useful in MULTI-PROTOCOL 178 environments. 180 - Users may specify their traffic flow measurement requirements by 181 writing 'rule sets,' allowing them to collect the flow data they 182 need while ignoring other traffic. 184 - The data reduction effort to produce requested traffic flow 185 information is placed as near as possible to the network 186 measurement point. This minimises the volume of data to be 188 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 190 obtained (and transmitted across the network for storage), and 191 reduces the amount of processing required in traffic flow analysis 192 applications. 194 The architecture specifies common metrics for measuring traffic flows. 195 By using the same metrics, traffic flow data can be exchanged and 196 compared across multiple platforms. Such data is useful for: 198 - Understanding the behaviour of existing networks, 200 - Planning for network development and expansion, 202 - Quantification of network performance, 204 - Verifying the quality of network service, and 206 - Attribution of network usage to users. 208 The traffic flow measurement architecture is deliberately structured so 209 that specific protocol implementations may extend coverage to 210 multi-protocol environments and to other protocol layers, such as usage 211 measurement for application-level services. Use of the same model for 212 both network- and application-level measurement may simplify the 213 development of generic analysis applications which process and/or 214 correlate any or all levels of traffic and usage information. Within 215 this docuemt the term 'usage data' is used as a generic term for the 216 data obtained using the traffic flow measurement architecture. 218 This document is not a protocol specification. It specifies and 219 structures the information that a traffic flow measurement system needs 220 to collect, describes requirements that such a system must meet, and 221 outlines tradeoffs which may be made by an implementor. 223 For performance reasons, it may be desirable to use traffic information 224 gathered through traffic flow measurement in lieu of network statistics 225 obtained in other ways. Although the quantification of network 226 performance is not the primary purpose of this architecture, the 227 measured traffic flow data may be used as an indication of network 228 performance. 230 A cost recovery structure decides "who pays for what." The major issue 231 here is how to construct a tariff (who gets billed, how much, for which 232 things, based on what information, etc). Tariff issues include 233 fairness, predictability (how well can subscribers forecast their 234 network charges), practicality (of gathering the data and administering 235 the tariff), incentives (e.g. encouraging off-peak use), and cost 236 recovery goals (100% recovery, subsidisation, profit making). Issues 237 such as these are not covered here. 239 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 241 Background information explaining why this approach was selected is 242 provided by the 'Internet Accounting: Background' RFC [1]. 244 2 Traffic Flow Measurement Architecture 246 A traffic flow measurement system is used by Network Operations 247 personnel to aid in managing and developing a network. It provides a 248 tool for measuring and understanding the network's traffic flows. This 249 information is useful for many purposes, as mentioned in section 1 250 (above). 252 The following sections outline a model for traffic flow measurement, 253 which draws from working drafts of the OSI accounting model [2]. Future 254 extensions are anticipated as the model is refined to address additional 255 protocol layers. 257 2.1 Meters and Traffic Flows 259 At the heart of the traffic measurement model are network entities 260 called traffic METERS. Meters observe packets as they pass by a single 261 point on their way through the network and classify them into certain 262 groups. For each such group a meter will accumulate certain attributes, 263 for example the numbers of packets and bytes observed for the group. 264 These METERED TRAFFIC GROUPS may correspond to a user, a host system, a 265 network, a group of networks, a particular transport address (e.g. an 266 IP port number), any combination of the above, etc, depending on the 267 meter's configuration. 269 We assume that routers or traffic monitors throughout a network are 270 instrumented with meters to measure traffic. Issues surrounding the 271 choice of meter placement are discussed in the 'Traffic Flow 272 Measurement: Background' RFC [1]. An important aspect of meters is 273 that they provide a way of succinctly aggregating traffic information. 275 For the purpose of traffic flow measurement we define the concept of a 276 TRAFFIC FLOW, which is like an artificial logical equivalent to a call 277 or connection. A flow is a portion of traffic, delimited by a start and 278 stop time, that belongs to one of the metered traffic groups mentioned 279 above. Attribute values (source/destination addresses, packet counts, 280 byte counts, etc.) associated with a flow are aggregate quantities 281 reflecting events which take place in the DURATION between the start and 282 stop times. The start time of a flow is fixed for a given flow; the 283 stop time may increase with the age of the flow. 285 For connectionless network protocols such as IP there is by definition 286 no way to tell whether a packet with a particular source/destination 288 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 290 combination is part of a stream of packets or not - each packet is 291 completely independent. A traffic meter has, as part of its 292 configuration, a set of 'rules' which specify the flows of interest, in 293 terms of the values of their attributes. It derives attribute values 294 from each observed packet, and uses these to decide which flow they 295 belong to. Classifying packets into 'flows' in this way provides an 296 economical and practical way to measure network traffic and subdivide it 297 into well-defined groups. 299 Usage information which is not derivable from traffic flows may also be 300 of interest. For example, an application may wish to record accesses to 301 various different information resources or a host may wish to record the 302 username (subscriber id) for a particular network session. Provision is 303 made in the traffic flow architecture to do this. In the future the 304 measurement model may be extended to gather such information from 305 applications and hosts so as to provide values for higher-layer flow 306 attributes. 308 As well as FLOWS and METERS, the traffic flow measurement model includes 309 MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in 310 following sections. The relationships between them are shown by the 311 diagram below. Numbers on the diagram refer to sections in this 312 document. 314 MANAGER 315 / \ 316 2.3 / \ 2.4 317 / \ 318 / \ ANALYSIS 319 METER <-----> METER READER <-----> APPLICATION 320 2.2 2.7 322 - MANAGER: MANAGER: A traffic measurement manager is an application 323 which configures 'meter' entities and controls 'meter reader' 324 entities. It sends configuration commands to the meters, and 325 supervises the proper operation of each meter and meter reader. It 326 may well be convenient to combine the functions of meter reader and 327 manager within a single network entity. 329 - METER: Meters are placed at measurement points determined by 330 Network Operations personnel. Each meter selectively records 331 network activity as directed by its configuration settings. It can 332 also aggregate, transform and further process the recorded activity 333 before the data is stored. The processed and stored results are 334 called the 'usage data.' 336 - METER READER: A meter reader reliably transports usage data from 337 meters so that it is available to analysis applications. 339 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 341 - ANALYSIS APPLICATION: An analysis application processes the usage 342 data so as to provide information and reports which are useful for 343 network engineering and management purposes. Examples include: 345 - TRAFFIC FLOW MATRICES, showing the total flow rates for many of 346 the possible paths within an internet. 348 - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over 349 a period of time. 351 - USAGE DATA showing the total traffic volumes sent and received 352 by particular hosts. 354 The operation of the traffic measurement system as a whole is best 355 understood by considering the interactions between its components. 356 These are described in the following sections. 358 2.2 Interaction Between METER and METER READER 360 The information which travels along this path is the usage data itself. 361 A meter holds usage data in an array of flow data records known as the 362 FLOW TABLE. A meter reader may collect the data in any suitable manner. 363 For example it might upload a copy of the whole flow table using a file 364 transfer protocol, or read the records in the current flow set one at a 365 time using a suitable data transfer protocol. Note that the meter 366 reader need not read complete flow data records, a subset of their 367 attribute values may well be sufficient. 369 A meter reader may collect usage data from one or more meters. Data may 370 be collected from the meters at any time. There is no requirement for 371 collections to be synchronized in any way. 373 2.3 Interaction Between MANAGER and METER 375 A manager is responsible for configuring and controlling one or more 376 meters. Each meter's configuration includes information such as: 378 - Flow specifications, e.g. which traffic flows are to be measured, 379 how they are to be aggregated, and any data the meter is required 380 to compute for each flow being measured. 382 - Meter control parameters, e.g. the 'inactivity' time for flows (if 383 no packets belonging to a flow are seen for this time the flow is 384 considered to have ended, i.e. to have become idle). 386 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 388 - Sampling rate. Normally every packet will be observed. It may 389 sometimes be necessary to use sampling techniques to observe only 390 some of the packets. (Sampling algorithms are not prescribed by 391 the architecture; it should be noted that before using sampling one 392 should verify the statistical validity of the algorithm used). 393 Current experience with the measurement architecture shows that a 394 carefully-designed and implemented meter compresses the data such 395 that in normal LANs and WANs of today sampling is really not 396 needed. 398 A meter may run several rule sets concurrently on behalf of one or more 399 managers, and any manager may download a set of flow specifications 400 (i.e. a 'rule set') to a meter. Control parameters which apply to an 401 individual rule set should be set by the manager after it downloads that 402 rule set. 404 One manager should be designated as the 'master' for a meter. 405 Parameters such as sampling rate, which affect the overall operation of 406 the meter, should only be set by the master manager. 408 2.4 Interaction Between MANAGER and METER READER 410 A manager is responsible for configuring and controlling one or more 411 meter readers. A meter reader may only be controlled by a single 412 manager. A meter reader needs to know at least the following for every 413 meter it is collecting usage data from: 415 - The meter's unique identity, i.e. its network name or address. 417 - How often usage data is to be collected from the meter. 419 - Which flow records are to be collected (e.g. all flows, flows for 420 a particular rule set, flows which have been active since a given 421 time, etc.). 423 - Which attribute values are to be collected for the required flow 424 records (e.g. all attributes, or a small subset of them) 426 Since redundant reporting may be used in order to increase the 427 reliability of usage data, exchanges among multiple entities must be 428 considered as well. These are discussed below. 430 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 432 2.5 Multiple METERs or METER READERs 434 -- METER READER A -- 435 / | \ 436 / | \ 437 =====METER 1 METER 2=====METER 3 METER 4===== 438 \ | / 439 \ | / 440 -- METER READER B -- 442 Several uniquely identified meters may report to one or more meter 443 readers. The diagram above gives an example of how multiple meters and 444 meter readers could be used. 446 In the diagram above meter 1 is read by meter reader A, and meter 4 is 447 read by meter reader B. Meters 1 and 4 have no redundancy; if either 448 meter fails, usage data for their network segments will be lost. 450 Meters 2 and 3, however, measure traffic on the same network segment. 451 One of them may fail leaving the other collecting the segment's usage 452 data. Meters 2 and 3 are read by meter reader A and by meter reader B. 453 If one meter reader fails, the other will continue collecting usage data 454 from both meters. 456 The architecture does not require multiple meter readers to be 457 synchronized. In the situation above meter readers A and B could both 458 collect usage data at the same intervals, but not neccesarily at the 459 same times. Note that because collections are asynchronous it is 460 unlikely that usage records from two different meter readers will agree 461 exactly. 463 If precisely synchronized collections are required this can be achieved 464 by having one manager request each meter to begin running a new set of 465 rules at the same time, then allowing all meter readers to collect the 466 usage data from the flows recorded by the old rule sets. 468 If there is only one meter reader and it fails, the meters continue to 469 run. When the meter reader is restarted it can collect all of the 470 accumulated flow data. Should this happen, time resolution will be lost 471 (because of the missed collections) but overall traffic flow information 472 will not. The only exception to this would occur if the traffic volume 473 was sufficient to 'roll over' counters for some flows during the 474 failure; this is addressed in the section on 'Rolling Counters.' 476 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 478 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 480 Synchronization between multiple management systems is the province of 481 network management protocols. This traffic flow measurement 482 architecture specifies only the network management controls necessary to 483 perform the traffic flow measurement function and does not address the 484 more global issues of simultaneous or interleaved (possibly conflicting) 485 commands from multiple network management stations or the process of 486 transferring control from one network management station to another. 488 2.7 METER READERs and APPLICATIONs 490 Once a collection of usage data has been assembled by a meter reader it 491 can be processed by an analysis application. Details of analysis 492 applications - such as the reports they produce and the data they 493 require - are outside the scope of this architecture. 495 It should be noted, however, that analysis applications will often 496 require considerable amounts of input data. An important part of 497 running a traffic flow measurement system is the storage and regular 498 reduction of flow data so as to produce daily, weekly or monthly summary 499 files for further analysis. Again, details of such data handling are 500 outside the scope of this architecture. 502 3 Traffic Flows and Reporting Granularity 504 A flow was defined in section 2.1 above in abstract terms as follows: 506 "A TRAFFIC FLOW is an artifical logical equivalent to a call or 507 connection, belonging to a (user-specieied) METERED TRAFFIC 508 GROUP." 510 In practical terms, a flow is a stream of packets observed by the meter 511 as they pass across a network between two end points (or from a single 512 end point), which have been summarized by a traffic meter for analysis 513 purposes. 515 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 517 3.1 Flows and their Attributes 519 Every traffic meter maintains a table of 'flow records' for flows seen 520 by the meter. A flow record holds the values of the ATTRIBUTES of 521 interest for its flow. These attributes might include: 523 - ADDRESSES for the flow's source and destination. These comprise 524 the protocol type, the source and destination addresses at various 525 network layers (extracted from the packet header), and the number 526 of the interface on which the packet was observed. 528 - First and last TIMES when packets were seen for this flow, i.e. 529 the 'creation' and 'last activity' times for the flow. 531 - COUNTS for 'forward' (source to destination) and 'backward' 532 (destination to source) components (e.g. packets and bytes) of the 533 flow's traffic. The specifying of 'source' and 'destination' for 534 flows is discussed in the section on packet matching below. 536 - OTHER attributes, e.g. the index of the flow's record in the flow 537 table and the rule set id for the rules which the meter was running 538 while the flow was observed. The values of these attributes 539 provide a way of distinguishing flows observed by a meter at 540 different times. 542 The attributes listed in this document (Appendix C) provide a basic 543 (i.e. useful minimum) set; they are assigned attribute numbers in the 544 range 0 to 63. The RTFM working group is working on an extended set of 545 attributes, which will have numbers in the range 64 to 127. 546 Implementors wishing to experiment with further new attributes should 547 use attribute numbers 128 and above. 549 A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS 550 attributes. For example, if a flow's address attributes specified only 551 that "source address = IP address 10.1.0.1," then all IP packets from 552 and to that address would be counted in that flow. If a flow's address 553 list were specified as "source address = IP address 10.1.0.1, 554 destination address = IP address 26.1.0.1" then only IP packets between 555 10.1.0.1 and 26.1.0.1 would be counted in that flow. 557 The addresses specifying a flow's address attributes may include one or 558 more of the following types: 560 - The INTERFACE NUMBER for the flow, i.e. the interface on which the 561 meter measured the traffic. Together with a unique address for the 562 meter this uniquely identifies a particular physical-level port. 564 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 566 - The ADJACENT ADDRESS, i.e. the [n-1] layer address of the 567 immediate source or destination on the path of the packet. For 568 example, if flow measurement is being performed at the IP layer on 569 an Ethernet LAN [3], an adjacent address will normally be a 570 six-octet Media Access Control (MAC) address. For a host connected 571 to the same LAN segment as the meter the adjacent address will be 572 the MAC address of that host. For hosts on other LAN segments it 573 will be the MAC address of the adjacent (upstream or downstream) 574 router carrying the traffic flow. 576 - The PEER ADDRESS, which identifies the source or destination of the 577 PEER-LEVEL packet. The form of a peer address will depend on the 578 network-layer protocol in use, and the network layer [n] at which 579 traffic measurement is being performed. 581 - The TRANSPORT ADDRESS, which identifies the source or destination 582 port for the packet, i.e. its [n+1] layer address. For example, 583 if flow measurement is being performed at the IP layer a transport 584 address is a two-octet UDP or TCP port number. 586 The four definitions above specify addresses for each of the four lowest 587 layers of the OSI reference model, i.e. Physical layer, Link layer, 588 Network layer and Transport layer. A FLOW RECORD stores both the VALUE 589 for each of its addresses (as described above) and a MASK specifying 590 which bits of the address value are being used and which are ignored. 591 Note that if address bits are being ignored the meter will set them to 592 zero, however their actual values are undefined. 594 One of the key features of the traffic measurement architecture is that 595 attributes have essentially the same meaning for different protocols, so 596 that analysis applications can use the same reporting formats for all 597 protocols. This is straightforward for peer addresses; although the 598 form of addresses differs for the various protocols, the meaning of a 599 'peer address' remains the same. It becomes harder to maintain this 600 correspondence at higher layers - for example, at the Network layer IP, 601 Novell IPX and AppleTalk all use port numbers as a 'transport address,' 602 but CLNP and DECnet have no notion of ports. Further work is needed 603 here, particularly in selecting attributes which will be suitable for 604 the higher layers of the OSI reference model. 606 Reporting by adjacent intermediate sources and destinations or simply by 607 meter interface (most useful when the meter is embedded in a router) 608 supports hierarchical Internet reporting schemes as described in the 609 'Internet Accounting: Background' RFC [1]. That is, it allows backbone 610 and regional networks to measure usage to just the next lower level of 611 granularity (i.e. to the regional and stub/enterprise levels, 612 respectively), with the final breakdown according to end user (e.g. to 613 source IP address) performed by the stub/enterprise networks. 615 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 617 In cases where network addresses are dynamically allocated (e.g. mobile 618 subscribers), further subscriber identification will be necessary if 619 flows are to ascribed to individual users. Provision is made to further 620 specify the metered traffic group through the use of an optional 621 SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated 622 with a particular flow either through the current rule set or by 623 proprietary means within a meter, for example via protocol exchanges 624 with one or more (multi-user) hosts. At this time a subscriber ID is an 625 arbitrary text string; later versions of the architecture may specify 626 its contents in more detail. 628 3.2 Granularity of Flow Measurements 630 GRANULARITY is the 'control knob' by which an application and/or the 631 meter can trade off the overhead associated with performing usage 632 reporting against its level of detail. A coarser granularity means a 633 greater level of aggregation; finer granularity means a greater level of 634 detail. Thus, the number of flows measured (and stored) at a meter can 635 be regulated by changing the granularity of their attributes. Flows are 636 like an adjustable pipe - many fine-granularity streams can carry the 637 data with each stream measured individually, or data can be bundled in 638 one coarse-granularity pipe. Time granularity may be controlled by 639 varying the reporting interval, i.e. the time between meter readings. 641 Flow granularity is controlled by adjusting the level of detail for the 642 following: 644 - The metered traffic group (address attributes, discussed above). 646 - The categorisation of packets (other attributes, discussed below). 648 - The lifetime/duration of flows (the reporting interval needs to be 649 short enough to measure them with sufficient precision). 651 The set of rules controlling the determination of each packet's metered 652 traffic group is known as the meter's CURRENT RULE SET. As will be 653 shown, the meter's current rule set forms an integral part of the 654 reported information, i.e. the recorded usage information cannot be 655 properly interpreted without a definition of the rules used to collect 656 that information. 658 Settings for these granularity factors may vary from meter to meter. 659 They are determined by the meter's current rule set, so they will change 660 if network Operations personnel reconfigure the meter to use a new rule 661 set. It is expected that the collection rules will change rather 663 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 665 infrequently; nonetheless, the rule set in effect at any time must be 666 identifiable via a RULE SET ID. Granularity of metered traffic groups is 667 further specified by additional ATTRIBUTES. These attributes include: 669 - Attributes which record information derived from other attribute 670 values. Six of these are defined (SourceClass, DestClass, 671 FlowClass, SourceKind, DestKind, FlowKind), and their meaning is 672 determined by the meter's rule set. For example, one could have a 673 subroutine in the rule set which determined whether a source or 674 destination peer address was a member of an arbitrary list of 675 networks, and set SourceClass/DestClass to one if the source/dest 676 peer address was in the list or to zero otherwise. 678 - Administratively specified attributes such as Quality Of Service 679 and Priority, etc. These are not defined at this time. 681 - Higher-layer (especially application-level) attributes. These are 682 not defined at this time. 684 Settings for these granularity factors may vary from meter to meter. 685 They are determined by the meter's current rule set, so they will change 686 if Network Operations personnel reconfigure the meter to use a new rule 687 set. 689 The LIFETIME of a flow is the time interval which began when the meter 690 observed the first packet belonging to the flow and ended when it saw 691 the last packet. Flow lifetimes are very variable, but many - if not 692 most - are rather short. A meter cannot measure lifetimes directly; 693 instead a meter reader collects usage data for flows which have been 694 active since the last collection, and an analysis application may 695 compare the data from each collection so as to determine when each flow 696 actually stopped. 698 The meter does, however, need to reclaim memory (i.e. records in the 699 flow table) being held by idle flows. The meter configuration includes 700 a variable called InactivityTimeout, which specifies the minimum time a 701 meter must wait before recovering the flow's record. In addition, 702 before recovering a flow record the meter must be sure that the flow's 703 data has been collected by all meter readers which registered to collect 704 it. 706 These 'lifetime' issues are considered further in the section on meter 707 readers (below). A complete list of the attributes currently defined is 708 given in Appendix C later in this document. 710 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 712 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 714 Once a usage record is sent, the decision needs to be made whether to 715 clear any existing flow records or to maintain them and add to their 716 counts when recording subsequent traffic on the same flow. The second 717 method, called rolling counters, is recommended and has several 718 advantages. Its primary advantage is that it provides greater 719 reliability - the system can now often survive the loss of some usage 720 records, such as might occur if a meter reader failed and later 721 restarted. The next usage record will very often contain yet another 722 reading of many of the same flow buckets which were in the lost usage 723 record. The 'continuity' of data provided by rolling counters can also 724 supply information used for "sanity" checks on the data itself, to guard 725 against errors in calculations. 727 The use of rolling counters does introduce a new problem: how to 728 distinguish a follow-on flow record from a new flow record. Consider 729 the following example. 731 CONTINUING FLOW OLD FLOW, then NEW FLOW 733 start time = 1 start time = 1 734 Usage record N: flow count = 2000 flow count = 2000 (done) 736 start time = 1 start time = 5 737 Usage record N+1: flow count = 3000 new flow count = 1000 739 Total count: 3000 3000 741 In the continuing flow case, the same flow was reported when its count 742 was 2000, and again at 3000: the total count to date is 3000. In the 743 OLD/NEW case, the old flow had a count of 2000. Its record was then 744 stopped (perhaps because of temporary idleness), but then more traffic 745 with the same characteristics arrived so a new flow record was started 746 and it quickly reached a count of 1000. The total flow count from both 747 the old and new records is 3000. 749 The flow START TIMESTAMP attribute is sufficient to resolve this. In 750 the example above, the CONTINUING FLOW flow record in the second usage 751 record has an old FLOW START timestamp, while the NEW FLOW contains a 752 recent FLOW START timestamp. 754 Each packet is counted in at most one flow for each running ruleset, so 755 as to avoid multiple counting of a single packet. The record of a 756 single flow is informally called a "bucket." If multiple, sometimes 757 overlapping, records of usage information are required (aggregate, 758 individual, etc), the network manager should collect the counts in 759 sufficiently detailed granularity so that aggregate and combination 761 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 763 counts can be reconstructed in post-processing of the raw usage data. 764 Alternatively, multiple rulesets could be used to collect data at 765 different granularities. 767 For example, consider a meter from which it is required to record both 768 'total packets coming in interface #1' and 'total packets arriving from 769 any interface sourced by IP address = a.b.c.d,' using a single rule set. 770 Although a bucket can be declared for each case, it is not clear how to 771 handle a packet which satisfies both criteria. It must only be counted 772 once. By default it will be counted in the first bucket for which it 773 qualifies, and not in the other bucket. Further, it is not possible to 774 reconstruct this information by post-processing. The solution in this 775 case is to define not two, but THREE buckets, each one collecting a 776 unique combination of the two criteria: 778 Bucket 1: Packets which came in interface 1, 779 AND were sourced by IP address a.b.c.d 781 Bucket 2: Packets which came in interface 1, 782 AND were NOT sourced by IP address a.b.c.d 784 Bucket 3: Packets which did NOT come in interface 1, 785 AND were sourced by IP address a.b.c.d 787 (Bucket 4: Packets which did NOT come in interface 1, 788 AND NOT sourced by IP address a.b.c.d) 790 The desired information can now be reconstructed by post-processing. 791 "Total packets coming in interface 1" can be found by adding buckets 1 & 792 2, and "Total packets sourced by IP address a.b.c.d" can be found by 793 adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly 794 required since its information is not of interest, but it is supplied 795 here in parentheses for completeness. 797 Alternatively, the above could be achieved by running two rule sets (A 798 and B), as follows: 800 Bucket 1: Packets which came in interface 1; 801 counted by rule set A. 803 Bucket 2: Packets which were sourcede by IP address a.b.c.d; 804 counted by rule set B. 806 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 808 4 Meters 810 A traffic flow meter is a device for collecting data about traffic flows 811 at a given point within a network; we will call this the METERING POINT. 812 The header of every packet passing the network metering point is offered 813 to the traffic meter program. 815 A meter could be implemented in various ways, including: 817 - A dedicated small host, connected to a LAN (so that it can see all 818 packets as they pass by) and running a traffic meter program. The 819 metering point is the LAN segment to which the meter is attached. 821 - A multiprocessing system with one or more network interfaces, with 822 drivers enabling a traffic meter program to see packets. In this 823 case the system provides multiple metering points - traffic flows 824 on any subset of its network interfaces can be measured. 826 - A packet-forwarding device such as a router or switch. This is 827 similar to (b) except that every received packet should also be 828 forwarded, usually on a different interface. 830 4.1 Meter Structure 832 An outline of the meter's structure is given in the following diagram: 834 Briefly, the meter works as follows: 836 - Incoming packet headers arrive at the top left of the diagram and 837 are passed to the PACKET PROCESSOR. 839 - The packet processor passes them to the Packet Matching Engine 840 (PME) where they are classified. 842 - The PME is a Virtual Machine running a pattern matching program 843 contained in the CURRENT RULE SET. It is invoked by the Packet 844 Processor, and returns instructions on what to do with the packet. 846 - Some packets are classified as 'to be ignored.' They are discarded 847 by the Packet Processor. 849 - Other packets are matched by the PME, which returns a FLOW KEY 850 describing the flow to which the packet belongs. 852 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 854 - The flow key is used to locate the flow's entry in the FLOW TABLE; 855 a new entry is created when a flow is first seen. The entry's data 856 fields (e.g. packet and byte counters) are updated. 858 - A meter reader may collect data from the flow table at any time. 859 It may use the 'collect' index to locate the flows to be collected 860 within the flow table. 862 packet +------------------+ 863 header | Current Rule Set | 864 | +--------+---------+ 865 | | 866 +--------*---------+ +----------*-------------+ 867 | Packet Processor |<----->| Packet Matching Engine | 868 +--+------------+--+ +------------------------+ 869 | | 870 Ignore * | Count via flow key 871 | 872 +--*--------------+ 873 | 'Search' index | 874 +--------+--------+ 875 | 876 +--------*--------+ 877 | | 878 | Flow Table | 879 | | 880 +--------+--------+ 881 | 882 +--------*--------+ 883 | 'Collect' index | 884 +--------+--------+ 885 | 886 * 887 Meter Reader 889 The discussion above assumes that a meter will only be running a single 890 rule set. A meter may, however, run several rule sets concurrently. To 891 do this the meter maintains a table of current rulesets. The packet 892 processor matches each packet against every current ruleset, producing a 893 single flow table with flows from all the rule sets. The overall effect 894 of doing this is somewhat similar to running several independent meters, 895 one for each rule set. 897 4.2 Flow Table 899 Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows 900 seen by the meter. A flow record contains attribute values for its 901 flow, including: 903 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 905 - Addresses for the flow's source and destination. These include 906 addresses and masks for various network layers (extracted from the 907 packet), and the identity of the interface on which the packet was 908 observed. 910 - First and last times when packets were seen for this flow. 912 - Counts for 'forward' (source to destination) and 'backward' 913 (destination to source) components of the flow's traffic. 915 - Other attributes, e.g. state of the flow record (discussed below). 917 The state of a flow record may be: 919 - INACTIVE: The flow record is not being used by the meter. 921 - CURRENT: The record is in use and describes a flow which belongs to 922 the 'current flow set,' i.e. the set of flows recently seen by the 923 meter. 925 - IDLE: The record is in use and the flow which it describes is part 926 of the current flow set. In addition, no packets belonging to this 927 flow have been seen for a period specified by the meter's 928 InactivityTime variable. 930 4.3 Packet Handling, Packet Matching 932 Each packet header received by the traffic meter program is processed as 933 follows: 935 - Extract attribute values from the packet header and use them to 936 create a MATCH KEY for the packet. 938 - Match the packet's key against the current rule set, as explained 939 in detail below. 941 The rule set specifies whether the packet is to be counted or ignored. 942 If it is to be counted the matching process produces a FLOW KEY for the 943 flow to which the packet belongs. This flow key is used to find the 945 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 947 flow's record in the flow table; if a record does not yet exist for this 948 flow, a new flow record may be created. The data for the matching flow 949 record can then be updated. 951 For example, the rule set could specify that packets to or from any host 952 in IP network 130.216 are to be counted. It could also specify that 953 flow records are to be created for every pair of 24-bit (Class C) 954 subnets within network 130.216. 956 Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE 957 (PME) for matching. The PME is a Virtual Machine which uses a set of 958 instructions called RULES, i.e. a RULE SET is a program for the PME. A 959 packet's match key contains source (S) and destination (D) interface 960 identities, address values and masks. 962 If measured flows were unidirectional, i.e. only counted packets 963 travelling in one direction, the matching process would be simple. The 964 PME would be called once to match the packet. Any flow key produced by 965 a successful match would be used to find the flow's record in the flow 966 table, and that flow's counters would be updated. 968 Flows are, however, bidirectional, reflecting the forward and reverse 969 packets of a protocol interchange or 'session.' Maintaining two sets of 970 counters in the meter's flow record makes the resulting flow data much 971 simpler to handle, since analysis programs do not have to gather 972 together the 'forward' and 'reverse' components of sessions. 973 Implementing bi-directional flows is, of course, more difficult for the 974 meter, since it must decide whether a packet is a 'forward' packet or a 975 'reverse' one. To make this decision the meter will often need to 976 invoke the PME twice, once for each possible packet direction. 978 The diagram below describes the algorithm used by the traffic meter to 979 process each packet. Flow through the diagram is from left to right and 980 top to bottom, i.e. from the top left corner to the bottom right 981 corner. S indicates the flow's source address (i.e. its set of source 982 address attribute values) from the packet header, and D indicates its 983 destination address. 985 There are several cases to consider. These are: 987 - The packet is recognised as one which is TO BE IGNORED. 989 - The packet would MATCH IN EITHER DIRECTION. One situation in which 990 this could happen would be a rule set which matches flows within 991 network X (Source = X, Dest = X) but specifies that flows are to be 992 created for each subnet within network X, say subnets y and z. If, 993 for example a packet is seen for y->z, the meter must check that 994 flow z->y is not already current before creating y->z. 996 - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already 997 current, its forward or reverse counters are incremented. 998 Otherwise it is added to the flow table and then counted. 1000 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1002 Ignore 1003 --- match(S->D) -------------------------------------------------+ 1004 | Suc | NoMatch | 1005 | | Ignore | 1006 | match(D->S) -----------------------------------------+ 1007 | | Suc | NoMatch | 1008 | | | | 1009 | | +-------------------------------------------+ 1010 | | | 1011 | | Suc | 1012 | current(D->S) ---------- count(D->S,r) --------------+ 1013 | | Fail | 1014 | | | 1015 | create(D->S) ----------- count(D->S,r) --------------+ 1016 | | 1017 | Suc | 1018 current(S->D) ------------------ count(S->D,f) --------------+ 1019 | Fail | 1020 | Suc | 1021 current(D->S) ------------------ count(D->S,r) --------------+ 1022 | Fail | 1023 | | 1024 create(S->D) ------------------- count(S->D,f) --------------+ 1025 | 1026 * 1028 The algorithm uses four functions, as follows: 1030 match(A->B) implements the PME. It uses the meter's current rule set 1031 to match the attribute values in the packet's match key. A->B means 1032 that the assumed source address is A and destination address B, i.e. 1033 that the packet was travelling from A to B. match() returns one of 1034 three results: 1036 'Ignore' means that the packet was matched but this flow is not 1037 to be counted. 1039 'NoMatch' means that the packet did not match. It might, however 1040 match with its direction reversed, i.e. from B to A. 1042 'Suc' means that the packet did match, i.e. it belongs to a flow 1043 which is to be counted. 1045 current(A->B) succeeds if the flow A-to-B is current - i.e. has 1046 a record in the flow table whose state is Current - and fails 1047 otherwise. 1049 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1051 create(A->B) adds the flow A-to-B to the flow table, setting the 1052 value for attributes - such as addresses - which remain constant, 1053 and zeroing the flow's counters. 1055 count(A->B,f) increments the 'forward' counters for flow A-to-B. 1056 count(A->B,r) increments the 'reverse' counters for flow A-to-B. 1057 'Forward' here means the counters for packets travelling from 1058 A to B. Note that count(A->B,f) is identical to count(B->A,r). 1060 When writing rule sets one must remember that the meter will normally 1061 try to match each packet in the reverse direction if the forward match 1062 does not succeed. It is particularly important that the rule set does 1063 not contain inconsistencies which will upset this process. 1065 Consider, for example, a rule set which counts packets from source 1066 network A to destination network B, but which ignores packets from 1067 source network B. This is an obvious example of an inconsistent rule 1068 set, since packets from network B should be counted as reverse packets 1069 for the A-to-B flow. 1071 This problem could be avoided by devising a language for specifying rule 1072 files and writing a compiler for it, thus making it much easier to 1073 produce correct rule sets. Another approach would be to write a 'rule 1074 set consistency checker' program, which could detect problems in 1075 hand-written rule sets. 1077 Normally, the best way to avoid these problems is to write rule sets 1078 which only classify flows in the forward direction, and rely on the 1079 meter to handle reverse-travelling packets. 1081 Occasionally there can be situations when a rule set needs to know the 1082 direction in which a packet is being matched. Consider, for example, a 1083 rule set which wants to save some attribute values (source and 1084 destination addresses perhaps) for any 'unusual' packets. The rule set 1085 will contain a sequence of tests for all the 'usual' source addresses; 1086 follwed by a rule which will execute a 'NoMatch' action. If the match 1087 fails in the S->D direction, the NoMatch action will cause it to be 1088 retried. If it fails in the D->S direction, the packet can be counted 1089 as an 'unusual' packet. 1091 To count such an 'unusual' packet we need to know the matching 1092 direction: the MatchingStoD attribute provides this. To use it, one 1093 follows the source address tests with a rule which tests whether the 1094 matching direction is S->D (MatchingStoD value is 1). If so, a 1095 'NoMatch' action is executed. Otherwise, the packet has failed to match 1096 in both directions; we can Push whatever attribute values are of 1097 interest and count the 'unusual' packet. 1099 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1101 4.4 Rules and Rule Sets 1103 A rule set is an array of rules. Rule sets are held within a meter as 1104 entries in an array of rule sets. 1106 Rule set 1 (the first entry in the rule set table) is built-in to the 1107 meter and cannot be changed. It is run when the meter is started up, 1108 and provides a very coarse reporting granularity; it is mainly useful 1109 for verifying that the meter is running, before a 'useful' rule set is 1110 downloaded to it. 1112 A meter also maintains an array of 'tasks,' which specify what rule sets 1113 the meter is running. Each task has a 'current' rule set (the one which 1114 it normally uses), and a 'standby' rule set (which will be used when the 1115 overall traffic level is unusually high). If a task is instructed to 1116 use rule set 0, it will cease measuring; all packets will be ignored 1117 until another (non-zero) rule set is made current. 1119 Each rule in a rule set is structured as follows: 1121 +-------- test ---------+ +---- action -----+ 1122 attribute & mask = value: opcode, parameter; 1124 Opcodes contain two flags: 'goto' and 'test.' The PME maintains a 1125 Boolean indicator called the 'test indicator,' which is initially set 1126 (true). Execution begins with rule 1, the first in the rule set. It 1127 proceeds as follows: 1129 If the test indicator is true: 1130 Perform the test, i.e. AND the attribute value with the 1131 mask and compare it with the value. 1132 If these are equal the test has succeeded; perform the 1133 rule's action (below). 1134 If the test fails execute the next rule in the rule set. 1135 If there are no more rules in the rule set, return from the 1136 match() function indicating NoMatch. 1138 If the test indicator is false, or the test (above) succeeded: 1139 Set the test indicator to this opcode's test flag value. 1140 Determine the next rule to execute. 1141 If the opcode has its goto flag set, its parameter value 1142 specifies the number of the next rule. 1143 Opcodes which don't have their goto flags set either 1144 determine the next rule in special ways (Return), 1145 or they terminate execution (Ignore, NoMatch, Count, 1146 CountPkt). 1147 Perform the action. 1149 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1151 The PME maintains two 'history' data structures. The first, the 1152 'return' stack, simply records the index (i.e. 1-origin rule number) of 1153 each Gosub rule as it is executed; Return rules pop their Gosub rule 1154 index. The second, the 'pattern' queue, is used to save information for 1155 later use in building a flow key. A flow key is built by zeroing all 1156 its attribute values, then copying attribute and mask information from 1157 the pattern queue in the order it was enqueued. 1159 The opcodes are: 1161 opcode goto test 1163 1 Ignore 0 - 1164 2 NoMatch 0 - 1165 3 Count 0 - 1166 4 CountPkt 0 - 1167 5 Return 0 0 1168 6 Gosub 1 1 1169 7 GosubAct 1 0 1170 8 Assign 1 1 1171 9 AssignAct 1 0 1172 10 Goto 1 1 1173 11 GotoAct 1 0 1174 12 PushRuleTo 1 1 1175 13 PushRuleToAct 1 0 1176 14 PushPktTo 1 1 1177 15 PushPktToAct 1 0 1178 16 PopTo 1 1 1179 17 PopToAct 1 0 1181 The actions they perform are: 1183 Ignore: Stop matching, return from the match() function 1184 indicating that the packet is to be ignored. 1186 NoMatch: Stop matching, return from the match() function 1187 indicating failure. 1189 Count: Stop matching. Save this rule's attribute name, 1190 mask and value in the PME's pattern queue, then 1191 construct a flow key for the flow to which this 1192 packet belongs. Return from the match() function 1193 indicating success. The meter will use the flow 1194 key to search for the flow record for this 1195 packet's flow. 1197 CountPkt: As for Count, except that the masked value from 1198 the packet is saved in the PME's pattern queue 1199 instead of the rule's value. 1201 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1203 Gosub: Call a rule-matching subroutine. Push the current 1204 rule number on the PME's return stack, set the 1205 test indicator then goto the specified rule. 1207 GosubAct: Same as Gosub, except that the test indicator is 1208 cleared before going to the specified rule. 1210 Return: Return from a rule-matching subroutine. Pop the 1211 number of the calling gosub rule from the PME's 1212 'return' stack and add this rule's parameter value 1213 to it to determine the 'target' rule. Clear the 1214 test indicator then goto the target rule. 1216 A subroutine call appears in a rule set as a Gosub 1217 rule followed by a small group of following rules. 1218 Since a Return action clears the test flag, the 1219 action of one of these 'following' rules will be 1220 executed; this allows the subroutine to return a 1221 result (in addition to any information it may save 1222 in the PME's pattern queue). 1224 Assign: Set the attribute specified in this rule to the 1225 value specified in this rule. Set the test 1226 indicator then goto the specified rule. 1228 AssignAct: Same as Assign, except that the test indicator 1229 is cleared before going to the specified rule. 1231 Goto: Set the test indicator then goto the 1232 specified rule. 1234 GotoAct: Clear the test indicator then goto the specified 1235 rule. 1237 PushRuleTo: Save this rule's attribute name, mask and value 1238 in the PME's pattern queue. Set the test 1239 indicator then goto the specified rule. 1241 PushRuleToAct: Same as PushRuleTo, except that the test indicator 1242 is cleared before going to the specified rule. 1244 PushRuleTo actions may be used to save the value 1245 and mask used in a test, or (if the test is not 1246 performed) to save an arbitrary value and mask. 1248 PushPktTo: Save this rule's attribute name, mask, and the 1249 masked value from the packet header, in the PME's 1250 pattern queue. Set the test indicator then goto 1251 the specified rule. 1253 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1255 PushPktToAct: Same as PushPktTo, except that the test indicator 1256 is cleared before going to the specified rule. 1258 PushPktTo actions may be used to save a value from 1259 the packet using a specified mask. The test in 1260 PushPktTo rules will almost never be executed. 1262 PopTo: Delete the most recent item from the pattern 1263 queue, so as to remove the information saved by 1264 an earlier 'push' action. Set the test indicator 1265 then goto the specified rule. 1267 PopToAct: Same as PopTo, except that the test indicator 1268 is cleared before going to the specified rule. 1270 As well as the attributes applying directly to packets (such as 1271 SourcePeerAddress, DestTransAddress, etc.) the PME implements several 1272 further attribtes. These are: 1274 Null: Tests performed on the Null attribute always succeed. 1276 MatchingStoD: Indicates whether the PME is matching the packet 1277 with its addresses in 'wire order' or with its 1278 addresses reversed. MatchingStoD's value is 1 if the 1279 addresses are in wire order (StoD), and != 1 otherwise. 1281 v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They 1282 provide a way to pass parameters into rule-matching 1283 subroutines. Each may hold the number of a normal 1284 attribute; its value is set by an Assign action. 1285 When a meter variable appears as the attribute of a 1286 rule, its value specifies the actual attribute to be 1287 tested. For example, if v1 had been assigned 1288 SourcePeerAddress as its value, a rule with v1 as its 1289 attribute would actually test SourcePeerAddress. 1291 SourceClass, DestClass, FlowClass, 1292 SourceKind, DestKind, FlowKind: 1293 These six attributes may be set by executing PushRuleto 1294 actions. They allow the PME to save (in flow records) 1295 information which has been built up during matching. 1296 Their values may be tested in rules; this allows one 1297 to set them early in a rule set, and test them later. 1299 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1301 4.5 Maintaining the Flow Table 1303 The flow table may be thought of as a 1-origin array of flow records. 1304 (A particular implementation may, of course, use whatever data structure 1305 is most suitable). When the meter starts up there are no known flows; 1306 all the flow records are in the 'inactive' state. 1308 Each time a packet is matched for a flow which is not in a current flow 1309 set a flow record is created for it; the state of such a record is 1310 'current.' When selecting a record for the new flow the meter searches 1311 the flow table for an 'inactive' record. If no inactive records are 1312 available it will search for an 'idle' one instead. Note that there is 1313 no particular significance in the ordering of records within the table. 1315 Flow data may be collected by a 'meter reader' at any time. There is no 1316 requirement for collections to be synchronized. The reader may collect 1317 the data in any suitable manner, for example it could upload a copy of 1318 the whole flow table using a file transfer protocol, or it could read 1319 the records in the current flow set row by row using a suitable data 1320 transfer protocol. 1322 The meter keeps information about collections, in particular it 1323 maintains ReaderLastTime variables which remember the time the last 1324 collection was made by each reader. A second variable, InactivityTime, 1325 specifies the minimum time the meter will wait before considering that a 1326 flow is idle. 1328 The meter must recover records used for idle flows, if only to prevent 1329 it running out of flow records. Recovered flow records are returned to 1330 the 'inactive' state. A variety of recovery strategies are possible, 1331 including the following: 1333 One possible recovery strategy is to recover idle flow records as soon 1334 as possible after their data has been collected by all readers which 1335 have registered to do so. To implement this the meter could run a 1336 background process which scans the flow table looking for 'current' 1337 flows whose 'last packet' time is earlier than the meter's 1338 LastCollectTime. 1340 Another recovery strategy is to leave idle flows alone as long as 1341 possible, which would be suitable if one was only interested in 1342 measuring total traffic volumes. It could be implemented by having the 1343 meter search for collected idle flows only when it ran low on 'inactive' 1344 flow records. 1346 One further factor a meter should consider before recovering a flow is 1347 the number of meter readers which have collected the flow's data. If 1348 there are multiple meter readers operating, each reader should collect a 1349 flow's data before its memory is recovered. 1351 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1353 4.6 Handling Increasing Traffic Levels 1355 Under normal conditions the meter reader specifies which set of usage 1356 records it wants to collect, and the meter provides them. 1358 If memory usage rises above the high-water mark the meter should switch 1359 to a STANDBY RULE SET so as to decrease the rate at which new flows are 1360 created. When the manager, usually as part of a regular poll, becomes 1361 aware that the meter is using its standby rule set, it could decrease 1362 the interval between collections. The meter should also increase its 1363 efforts to recover flow memory so as to reduce the number of idle flows 1364 in memory. When the situation returns to normal, the manager may 1365 request the meter to switch back to its normal rule set. 1367 5 Meter Readers 1369 Usage data is accumulated by a meter (e.g. in a router) as memory 1370 permits. It is collected at regular reporting intervals by meter 1371 readers, as specified by a manager. The collected data is recorded in a 1372 disk file called a FLOW DATA FILE, as a sequence of USAGE RECORDS. 1374 The following sections describe the contents of usage records and flow 1375 data files. Note, however, that at this stage the details of such 1376 records and files is not specified in the architecture. Specifying a 1377 common format for them would be a worthwhile future development. 1379 5.1 Identifying Flows in Flow Records 1381 Once a packet has been classified and is ready to be counted, an 1382 appropriate flow data record must already exist in the flow table; 1383 otherwise one must be created. The flow record has a flexible format 1384 where unnecessary identification attributes may be omitted. The 1385 determination of which attributes of the flow record to use, and of what 1386 values to put in them, is specified by the current rule set. 1388 Note that the combination of start time, rule set id and subscript (row 1389 number in the flow table) provide a unique flow identifier, regardless 1390 of the values of its other attributes. 1392 The current rule set may specify additional information, e.g. a 1393 computed attribute value such as FlowKind, which is to be placed in the 1394 attribute section of the usage record. That is, if a particular flow is 1395 matched by the rule set, then the corresponding flow record should be 1396 marked not only with the qualifying identification attributes, but also 1397 with the additional information. Using this feature, several flows may 1399 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1401 each carry the same FlowKind value, so that the resulting usage records 1402 can be used in post-processing or between meter reader and meter as a 1403 criterion for collection. 1405 5.2 Usage Records, Flow Data Files 1407 The collected usage data will be stored in flow data files on the meter 1408 reader, one file for each meter. As well as containing the measured 1409 usage data, flow data files must contain information uniquely 1410 identifiying the meter from which it was collected. 1412 A USAGE RECORD contains the descriptions of and values for one or more 1413 flows. Quantities are counted in terms of number of packets and number 1414 of bytes per flow. Each usage record contains the metered traffic group 1415 identifier of the meter (a set of network addresses), a time stamp and a 1416 list of reported flows (FLOW DATA RECORDS). A meter reader will build up 1417 a file of usage records by regularly collecting flow data from a meter, 1418 using this data to build usage records and concatenating them to the 1419 tail of a file. Such a file is called a FLOW DATA FILE. 1421 A usage record contains the following information in some form: 1423 +-------------------------------------------------------------------+ 1424 | RECORD IDENTIFIERS: | 1425 | Meter Id (& digital signature if required) | 1426 | Timestamp | 1427 | Collection Rules ID | 1428 +-------------------------------------------------------------------+ 1429 | FLOW IDENTIFIERS: | COUNTERS | 1430 | Address List | Packet Count | 1431 | Subscriber ID (Optional) | Byte Count | 1432 | Attributes (Optional) | Flow Start/Stop Time | 1433 +-------------------------------------------------------------------+ 1435 5.3 Meter to Meter Reader: Usage Record Transmission 1437 The usage record contents are the raison d'etre of the system. The 1438 accuracy, reliability, and security of transmission are the primary 1439 concerns of the meter/meter reader exchange. Since errors may occur on 1440 networks, and Internet packets may be dropped, some mechanism for 1441 ensuring that the usage information is transmitted intact is needed. 1443 Flow data is moved from meter to meter reader via a series of protocol 1444 exchanges between them. This may be carried out in various ways, moving 1445 individual attribute values, complete flows, or the entire flow table 1447 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1449 (i.e. all the active and idle flows). One possible method of achieving 1450 this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' 1451 document [4] gives details. Note that this is simply one example; the 1452 transfer of flow data from meter to meter reader is not specified in 1453 this document. 1455 The reliability of the data transfer method under light, normal, and 1456 extreme network loads should be understood before selecting among 1457 collection methods. 1459 In normal operation the meter will be running a rule file which provides 1460 the required degree of flow reporting granularity, and the meter 1461 reader(s) will collect the flow data often enough to allow the meter's 1462 garbage collection mechanism to maintain a stable level of memory usage. 1464 In the worst case traffic may increase to the point where the meter is 1465 in danger of running completely out of flow memory. The meter 1466 implementor must decide how to handle this, for example by switching to 1467 a default (extremely coarse granularity) rule set, by sending a trap 1468 message to the manager, or by attempting to dump flow data to the meter 1469 reader. 1471 Users of the Traffic Flow Measurement system should analyse their 1472 requirements carefully and assess for themselves whether it is more 1473 important to attempt to collect flow data at normal granularity 1474 (increasing the collection frequency as needed to keep up with traffic 1475 volumes), or to accept flow data with a coarser granularity. Similarly, 1476 it may be acceptable to lose flow data for a short time in return for 1477 being sure that the meter keeps running properly, i.e. is not 1478 overwhelmed by rising traffic levels. 1480 6 Managers 1482 A manager configures meters and controls meter readers. It does this 1483 via the interactions described below. 1485 6.1 Between Manager and Meter: Control Functions 1487 - DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of 1488 these, the 'default' rule set, is built in to the meter and cannot 1489 be changed; the others must be downloaded by the manager. A 1490 manager may use any suitable protocol exchange to achieve this, for 1491 example an FTP file transfer or a series of SNMP SETs, one for each 1492 row of the rule set. 1494 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1496 - SPECIFY METER TASK: Once the rule sets have been downloaded, the 1497 manager must instruct the meter which rule sets will be the 1498 'current' and 'standby' ones for each task the meter is to perform. 1500 - SET HIGH WATER MARK: A percentage of the flow table capacity, used 1501 by the meter to determine when to switch to its standby rule set 1502 (so as to increase the granularity of the flows and conserve the 1503 meter's flow memory). Once this has happened, the manager may also 1504 change the polling frequency or the meter's control parameters (so 1505 as to increase the rate at which the meter can recover memory from 1506 idle flows). 1508 If the high traffic levels persist, the meter's normal rule set may 1509 have to be rewritten to permanently reduce the reporting 1510 granularity. 1512 - SET FLOW TERMINATION PARAMETERS: The meter should have the good 1513 sense in situations where lack of resources may cause data loss to 1514 purge flow records from its tables. Such records may include: 1516 - Flows that have already been reported to all registered meter 1517 readers, and show no activity since the last report, 1519 - Oldest flows, or 1521 - Flows with the smallest number of observed packets. 1523 - SET INACTIVITY TIMEOUT: This is a time in seconds since the last 1524 packet was seen for a flow. Flow records may be reclaimed if they 1525 have been idle for at least this amount of time, and have been 1526 collected in accordance with the current collection criteria. 1528 6.2 Between Manager and Meter Reader: Control Functions 1530 Because there are a number of parameters that must be set for traffic 1531 flow measurement to function properly, and viable settings may change as 1532 a result of network traffic characteristics, it is desirable to have 1533 dynamic network management as opposed to static meter configurations. 1534 Many of these operations have to do with space tradeoffs - if memory at 1535 the meter is exhausted, either the collection interval must be decreased 1536 or a coarser granularity of aggregation must be used to reduce the 1537 number of active flows. 1539 Increasing the collection interval effectively stores data in the meter; 1540 usage data in transit is limited by the effective bandwidth of the 1541 virtual link between the meter and the meter reader, and since these 1543 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1545 limited network resources are usually also used to carry user data (the 1546 purpose of the network), the level of traffic flow measurement traffic 1547 should be kept to an affordable fraction of the bandwidth. 1548 ("Affordable" is a policy decision made by the Network Operations 1549 personnel). At any rate, it must be understood that the operations 1550 below do not represent the setting of independent variables; on the 1551 contrary, each of the values set has a direct and measurable effect on 1552 the behaviour of the other variables. 1554 Network management operations follow: 1556 - MANAGER and METER READER IDENTIFICATION: The manager should ensure 1557 that meters are read by the correct set of meter readers, and take 1558 steps to prevent unauthorised access to usage information. The 1559 meter readers so identified should be prepared to poll if necessary 1560 and accept data from the appropriate meters. Alternate meter 1561 readers may be identified in case both the primary manager and the 1562 primary meter reader are unavailable. Similarly, alternate 1563 managers may be identified. 1565 - REPORTING INTERVAL CONTROL: The usual reporting interval should be 1566 selected to cope with normal traffic patterns. However, it may be 1567 possible for a meter to exhaust its memory during traffic spikes 1568 even with a correctly set reporting interval. Some mechanism 1569 should be available for the meter to tell the manager that it is in 1570 danger of exhausting its memory (by declaring a 'high water' 1571 condition), and for the manager to arbitrate (by decreasing the 1572 polling interval, letting nature take its course, or by telling the 1573 meter to ask for help sooner next time). 1575 - GRANULARITY CONTROL: Granularity control is a catch-all for all the 1576 parameters that can be tuned and traded to optimise the system's 1577 ability to reliably measure and store information on all the 1578 traffic (or as close to all the traffic as an administration 1579 requires). Granularity 1581 - Controls the amount of address information identifying each 1582 flow, and 1584 - Determines the number of buckets into which user traffic will 1585 be lumped together. 1587 Since granularity is controlled by the meter's current rule set, 1588 the manager can only change it by requesting the meter to switch to 1589 a different rule set. The new rule set could be downloaded when 1590 required, or it could have been downloaded as part of the meter's 1591 initial configuration. 1593 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1595 - FLOW LIFETIME CONTROL: Flow termination parameters include timeout 1596 parameters for obsoleting inactive flows and removing them from 1597 tables, and maximum flow lifetimes. This is intertwined with 1598 reporting interval and granularity, and must be set in accordance 1599 with the other parameters. 1601 6.3 Exception Conditions 1603 Exception conditions must be handled, particularly occasions when the 1604 meter runs out of space for flow data. Since - to prevent an active 1605 task from counting any packet twice - packets can only be counted in a 1606 single flow, discarding records will result in the loss of information. 1607 The mechanisms to deal with this are as follows: 1609 - METER OUTAGES: In case of impending meter outages (controlled 1610 restarts, etc.) the meter could send a trap to the manager. The 1611 manager could then request one or more meter readers to pick up the 1612 data from the meter. 1614 Following an uncontrolled meter outage such as a power failure, the 1615 meter could send a trap to the manager indicating that it has 1616 restarted. The manager could then download the meter's correct 1617 rule set and advise the meter reader(s) that the meter is running 1618 again. Alternatively, the meter reader may discover from its 1619 regular poll that a meter has failed and restarted. It could then 1620 advise the manager of this, instead of relying on a trap from the 1621 meter. 1623 - METER READER OUTAGES: If the collection system is down or isolated, 1624 the meter should try to inform the manager of its failure to 1625 communicate with the collection system. Usage data is maintained 1626 in the flows' rolling counters, and can be recovered when the meter 1627 reader is restarted. 1629 - MANAGER OUTAGES: If the manager fails for any reason, the meter 1630 should continue measuring and the meter reader(s) should keep 1631 gathering usage records. 1633 - BUFFER PROBLEMS: The network manager may realise that there is a 1634 'low memory' condition in the meter. This can usually be 1635 attributed to the interaction between the following controls: 1637 - The reporting interval is too infrequent, or 1639 - The reporting granularity is too fine. 1641 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1643 Either of these may be exacerbated by low throughput or bandwidth 1644 of circuits carrying the usage data. The manager may change any of 1645 these parameters in response to the meter (or meter reader's) plea 1646 for help. 1648 6.4 Standard Rule Sets 1650 Although the rule table is a flexible tool, it can also become very 1651 complex. It may be helpful to develop some rule sets for common 1652 applications: 1654 - PROTOCOL TYPE: The meter records packets by protocol type. This 1655 will be the default rule table for Traffic Flow Meters. 1657 - ADJACENT SYSTEMS: The meter records packets by the MAC address of 1658 the Adjacent Systems (neighbouring originator or next-hop). 1659 (Variants on this table are "report source" or "report sink" only.) 1660 This strategy might be used by a regional or backbone network which 1661 wants to know how much aggregate traffic flows to or from its 1662 subscriber networks. 1664 - END SYSTEMS: The meter records packets by the IP address pair 1665 contained in the packet. (Variants on this table are "report 1666 source" or "report sink" only.) This strategy might be used by an 1667 End System network to get detailed host traffic matrix usage data. 1669 - TRANSPORT TYPE: The meter records packets by transport address; for 1670 IP packets this provides usage information for the various IP 1671 services. 1673 - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface 1674 report End Systems, for another interface report Adjacent Systems. 1675 This strategy might be used by an enterprise network to learn 1676 detail about local usage and use an aggregate count for the shared 1677 regional network. 1679 7 Security Considerations 1681 7.1 Threat Analysis 1683 A traffic flow measurement system may be subject to the following kinds 1684 of attacks: 1686 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1688 - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain 1689 advantage or cause mischief (e.g. denial of service) by subverting 1690 any of the system elements - meters, meter readers or managers. 1692 - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to 1693 disclosure can be read through active or passive attacks unless it 1694 is suitably protected. Usage data may or may not be of this type. 1695 Control messages, traps, etc. are not likely to be considered 1696 sensitive to disclosure. 1698 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: 1699 Similarly, any data whose integrity is sensitive can be altered, 1700 replaced/injected or deleted through active or passive attacks 1701 unless it is suitably protected. Attackers may modify message 1702 streams to falsify usage data or interfere with the proper 1703 operation of the traffic flow measurement system. Therefore, all 1704 messages, both those containing usage data and those containing 1705 control data, should be considered vulnerable to such attacks. 1707 7.2 Countermeasures 1709 The following countermeasures are recommended to address the possible 1710 threats enumerated above: 1712 - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use 1713 of authentication and access control services. 1715 - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a 1716 confidentiality (encryption) service. 1718 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is 1719 countered through the use of an integrity service. 1721 A Traffic Measurement system must address all of these concerns. Since 1722 a high degree of protection is required, the use of strong cryptographic 1723 methodologies is recommended. The security requirements for 1724 communication between pairs of traffic measurmement system elements are 1725 summarized in the table below. It is assumed that meters do not 1726 communicate with other meters, and that meter readers do not communicate 1727 directly with other meter readers (if synchronization is required, it is 1728 handled by the manager, see Section 2.5). Each entry in the table 1729 indicates which kinds of security services are required. Basically, the 1730 requirements are as follows: 1732 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1734 Security Service Requirements for RTFM elements 1736 +------------------------------------------------------------------+ 1737 | from\to | meter | meter reader | application | manager | 1738 |---------+--------------+--------------+-------------+------------| 1739 | meter | N/A | authent | N/A | authent | 1740 | | | acc ctrl | | acc ctrl | 1741 | | | integrity | | | 1742 | | | confid ** | | | 1743 |---------+--------------+--------------+-------------+------------| 1744 | meter | authent | N/A | authent | authent | 1745 | reader | acc ctrl | | acc ctrl | acc ctrl | 1746 | | | | integrity | | 1747 | | | | confid ** | | 1748 |---------+--------------+--------------+-------------+------------| 1749 | appl | N/A | authent | | | 1750 | | | acc ctrl | ## | ## | 1751 |---------+--------------+--------------+-------------+------------| 1752 | manager | authent | authent | ## | authent | 1753 | | acc ctrl | acc ctrl | | acc ctrl | 1754 | | integrity | integrity | | integrity | 1755 +------------------------------------------------------------------+ 1757 N/A = Not Applicable ** = optional ## = outside RTFM scope 1759 - When any two elements intercommunicate they should mutually 1760 authenticate themselves to one another. This is indicated by 1761 'authent' in the table. Once authentication is complete, an 1762 element should check that the requested type of access is allowed; 1763 this is indicated on the table by 'acc ctrl.' 1765 - Whenever there is a transfer of information its integrity should be 1766 protected. 1768 - Whenever there is a transfer of usage data it should be possible to 1769 ensure its confidentiality if it is deemed sensitive to disclosure. 1770 This is indicated by 'confid' in the table. 1772 Security protocols are not specified in this document. The system 1773 elements' management and collection protocols are responsible for 1774 providing sufficient data integrity, confidentiality, authentication and 1775 access control services. 1777 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1779 8 APPENDICES 1781 8.1 Appendix A: Network Characterisation 1783 Internet users have extraordinarily diverse requirements. Networks 1784 differ in size, speed, throughput, and processing power, among other 1785 factors. There is a range of traffic flow measurement capabilities and 1786 requirements. For traffic flow measurement purposes, the Internet may 1787 be viewed as a continuum which changes in character as traffic passes 1788 through the following representative levels: 1790 International | 1791 Backbones/National --------------- 1792 / \ 1793 Regional/MidLevel ---------- ---------- 1794 / \ \ / / \ 1795 Stub/Enterprise --- --- --- ---- ---- 1796 ||| ||| ||| |||| |||| 1797 End-Systems/Hosts xxx xxx xxx xxxx xxxx 1799 Note that mesh architectures can also be built out of these components, 1800 and that these are merely descriptive terms. The nature of a single 1801 network may encompass any or all of the descriptions below, although 1802 some networks can be clearly identified as a single type. 1804 BACKBONE networks are typically bulk carriers that connect other 1805 networks. Individual hosts (with the exception of network management 1806 devices and backbone service hosts) typically are not directly connected 1807 to backbones. 1809 REGIONAL networks are closely related to backbones, and differ only in 1810 size, the number of networks connected via each port, and geographical 1811 coverage. Regionals may have directly connected hosts, acting as hybrid 1812 backbone/stub networks. A regional network is a SUBSCRIBER to the 1813 backbone. 1815 STUB/ENTERPRISE networks connect hosts and local area networks. 1816 STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 1817 networks. 1819 END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above 1820 networks. 1822 Providing a uniform identification of the SUBSCRIBER in finer 1823 granularity than that of end-system, (e.g. user/account), is beyond the 1824 scope of the current architecture, although an optional attribute in the 1826 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1828 traffic flow measurement record may carry system-specific 'user 1829 identification' labels so that meters can implement proprietary or 1830 non-standard schemes for the attribution of network traffic to 1831 responsible parties. 1833 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 1835 Initial recommended traffic flow measurement conventions are outlined 1836 here according to the following Internet building blocks. It is 1837 important to understand what complexity reporting introduces at each 1838 network level. Whereas the hierarchy is described top-down in the 1839 previous section, reporting requirements are more easily addressed 1840 bottom-up. 1842 End-Systems 1843 Stub Networks 1844 Enterprise Networks 1845 Regional Networks 1846 Backbone Networks 1848 END-SYSTEMS are currently responsible for allocating network usage to 1849 end-users, if this capability is desired. From the Internet Protocol 1850 perspective, end-systems are the finest granularity that can be 1851 identified without protocol modifications. Even if a meter violated 1852 protocol boundaries and tracked higher-level protocols, not all packets 1853 could be correctly allocated by user, and the definition of user itself 1854 varies widely from operating system to operating system (e.g. how to 1855 trace network usage back to users from shared processes). 1857 STUB and ENTERPRISE networks will usually collect traffic data either by 1858 end-system network address or network address pair if detailed reporting 1859 is required in the local area network. If no local reporting is 1860 required, they may record usage information in the exit router to track 1861 external traffic only. (These are the only networks which routinely use 1862 attributes to perform reporting at granularities finer than end-system 1863 or intermediate-system network address.) 1865 REGIONAL networks are intermediate networks. In some cases, subscribers 1866 will be enterprise networks, in which case the intermediate system 1867 network address is sufficient to identify the regional's immediate 1868 subscriber. In other cases, individual hosts or a disjoint group of 1869 hosts may constitute a subscriber. Then end-system network address 1870 pairs need to be tracked for those subscribers. When the source may be 1871 an aggregate entity (such as a network, or adjacent router representing 1872 traffic from a world of hosts beyond) and the destination is a singular 1873 entity (or vice versa), the meter is said to be operating as a HYBRID 1874 system. 1876 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1878 At the regional level, if the overhead is tolerable it may be 1879 advantageous to report usage both by intermediate system network address 1880 (e.g. adjacent router address) and by end-system network address or 1881 end-system network address pair. 1883 BACKBONE networks are the highest level networks operating at higher 1884 link speeds and traffic levels. The high volume of traffic will in most 1885 cases preclude detailed traffic flow measurement. Backbone networks 1886 will usually account for traffic by adjacent routers' network addresses. 1888 8.3 Appendix C: List of Defined Flow Attributes 1890 This Appendix provides a checklist of the attributes defined to date; 1891 others will be added later as the Traffic Measurement Architecture is 1892 further developed. 1894 0 Null 1895 1 Flow Subscript Integer Flow table info 1897 4 Source Interface Integer Source Address 1898 5 Source Adjacent Type Integer 1899 6 Source Adjacent Address String 1900 7 Source Adjacent Mask String 1901 8 Source Peer Type Integer 1902 9 Source Peer Address String 1903 10 Source Peer Mask String 1904 11 Source Trans Type Integer 1905 12 Source Trans Address String 1906 13 Source Trans Mask String 1908 14 Destination Interface Integer Destination Address 1909 15 Destination Adjacent Type Integer 1910 16 Destination Adjacent Address String 1911 17 Destination AdjacentMask String 1912 18 Destination PeerType Integer 1913 19 Destination PeerAddress String 1914 20 Destination PeerMask String 1915 21 Destination TransType Integer 1916 22 Destination TransAddress String 1917 23 Destination TransMask String 1919 26 Rule Set Number Integer Meter attribute 1921 27 Forward Bytes Integer Source-to-Dest counters 1922 28 Forward Packets Integer 1924 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1926 29 Reverse Bytes Integer Dest-to-Source counters 1927 30 Reverse Packets Integer 1928 31 First Time Timestamp Activity times 1929 32 Last Active Time Timestamp 1930 33 Source Subscriber ID String Session attributes 1931 34 Destination Subscriber ID String 1932 35 Session ID String 1934 36 Source Class Integer 'Computed' attributes 1935 37 Destination Class Integer 1936 38 Flow Class Integer 1937 39 Source Kind Integer 1938 40 Destination Kind Integer 1939 41 Flow Kind Integer 1941 50 MatchingStoD Integer PME variable 1943 65 1944 .. 'Extended' attributes (to be defined by the RTFM working group) 1945 127 1947 8.4 Appendix D: List of Meter Control Variables 1949 Meter variables: 1950 Flood Mark Percentage 1951 Inactivity Timeout (seconds) Integer 1953 'per task' variables: 1954 Current Rule Set Number Integer 1955 Standby Rule Set Number Integer 1956 High Water Mark Percentage 1958 'per reader' variables: 1959 Reader Last Time Timestamp 1961 8.5 Appendix E: Changes Introduced Since RFC 2063 1963 The first version of the Traffic Flow Measurement Architecture was 1964 published as RFC 2063 in January 1997. The most significant changes 1965 made since then are summarised below. 1967 - A Traffic Meter can now run multiple rule sets concurrently. This 1968 makes a meter much more useful, and required only minimal changes 1969 to the architecture. 1971 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 1973 - 'NoMatch' replaces 'Fail' as an action. This name was agreed to at 1974 the Working Group 1996 meeting in Montreal; it better indicates 1975 that although a particular match has failed, it may be tried again 1976 with the packet's addresses reversed. 1978 - The 'MatchingStoD' attribute has been added. This is a Packet 1979 Matching Engine (PME) attribute indicating that addresses are being 1980 matched in StoD (i.e. 'wire') order. It can be used to perform 1981 different actions when the match is retried, thereby simplifying 1982 some kinds of rule sets. It was discussed and agreed to at the San 1983 Jose meeting in 1996. 1985 - Computed attributes (Class and Kind) may now be tested within a 1986 rule set. This lifts an unneccessary earlier restriction. 1988 - The list of attribute numbers has been extended to define ranges 1989 for 'basic' attributes (in this document) and 'extended' attributes 1990 (currently being developed by the RTFM Working Group). 1992 - The 'Security Considerations' section has been completely 1993 rewritten. It provides an evaluation of traffic measurement 1994 security risks and their countermeasures. 1996 9 Acknowledgments 1998 An initial draft of this document was produced under the auspices of the 1999 IETF's Internet Accounting Working Group with assistance from SNMP, RMON 2000 and SAAG working groups. This version documents the implementation work 2001 done by the Internet Accounting Working Group, and is intended to 2002 provide a starting point for the Realtime Traffic Flow Measurement 2003 Working Group. Particular thanks are due to Stephen Stibler (IBM 2004 Research) for his patient and careful comments during the preparation of 2005 this draft. 2007 10 References 2009 [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 2010 Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian 2011 Technology Corporation, November 1991. 2013 [2] International Standards Organisation (ISO), "Management 2014 Framework," Part 4 of Information Processing Systems Open 2015 Systems Interconnection Basic Reference Model, ISO 7498-4, 2016 1994. 2018 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 2020 [3] IEEE 802.3/ISO 8802-3 Information Processing Systems - 2021 Local Area Networks - Part 3: Carrier sense multiple access 2022 with collision detection (CSMA/CD) access method and physical 2023 layer specifications, 2nd edition, September 21, 1990. 2025 [4] Brownlee, N., "Traffic Flow Measurement: Meter MIB," 2026 Internet Draft, 'Working draft' to become an experimental RFC. 2028 11 Author's Addresses 2030 Nevil Brownlee 2031 Information Technology Systems & Services 2032 The University of Auckland 2034 Phone: +64 9 373 7599 x8941 2035 E-mail: n.brownlee@auckland.ac.nz 2037 Cyndi Mills 2038 GTE Laboratories, Inc 2040 Phone: +1 617 466 4278 2041 E-mail: cmills@gte.com 2043 Greg Ruth 2044 GTE Laboratories, Inc 2046 Phone: +1 617 466 2448 2047 E-mail: gruth@gte.com 2049 Expires January 1999