idnits 2.17.1 draft-ietf-rtfm-architecture-00.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-26) 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 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 1041 has weird spacing: '... goto tes...' == Line 1543 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 (September 1997) is 9720 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 (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Brownlee, Mills, Ruth 3 INTERNET-DRAFT The University of Auckland 4 September 1997 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 Internet Accounting 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 Please check the I-D abstract listing contained in the Internet-drafts 25 Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 26 ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or 27 any other Internet Draft. 29 Abstract 31 This document describes an architecture for the measurement and 32 reporting of network traffic flows, discusses how this relates to an 33 overall network traffic flow architecture, and describes how it can be 34 used within the Internet. It is intended to provide a starting point 35 for the Realtime Traffic Flow Measurement Working Group. 37 Contents 39 1 Statement of Purpose and Scope 3 40 1.1 Changes Introduced Since RFC 2063 . . . . . . . . . . . . . . 4 41 2 Traffic Flow Measurement Architecture 5 42 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 5 43 2.2 Interaction Between METER and METER READER . . . . . . . . . . 7 44 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8 45 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8 46 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 47 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 48 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10 50 3 Traffic Flows and Reporting Granularity 10 51 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 52 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13 53 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15 55 4 Meters 16 56 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 57 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18 58 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 59 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 22 60 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26 61 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27 63 5 Meter Readers 27 64 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 27 65 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 28 66 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . . 28 68 6 Managers 29 69 6.1 Between Manager and Meter: Control Functions . . . . . . . . . 29 70 6.2 Between Manager and Meter Reader: Control Functions . . . . . 30 71 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 32 72 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 33 74 7 APPENDICES 34 75 7.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 34 76 7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 35 77 7.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 36 78 7.4 Appendix D: List of Meter Control Variables . . . . . . . . . 37 80 8 Security Considerations 38 81 8.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 38 82 8.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 38 84 9 Acknowledgments 40 86 10 References 40 88 11 Author's Addresses 41 89 1 Statement of Purpose and Scope 91 This document describes an architecture for traffic flow measurement and 92 reporting for data networks which has the following characteristics: 94 - The traffic flow model can be consistently applied to any 95 protocol/application at any network layer (e.g. network, 96 transport, application layers). 98 - Traffic flow attributes are defined in such a way that they are 99 valid for multiple networking protocol stacks, and that traffic 100 flow measurement implementations are useful in MULTI-PROTOCOL 101 environments. 103 - Users may specify their traffic flow measurement requirements in a 104 simple manner, allowing them to collect the flow data they need 105 while ignoring other traffic. 107 - The data reduction effort to produce requested traffic flow 108 information is placed as near as possible to the network 109 measurement point. This reduces the volume of data to be obtained 110 (and transmitted across the network for storage), and minimises the 111 amount of processing required in traffic flow analysis 112 applications. 114 The architecture specifies common metrics for measuring traffic flows. 115 By using the same metrics, traffic flow data can be exchanged and 116 compared across multiple platforms. Such data is useful for: 118 - Understanding the behaviour of existing networks, 120 - Planning for network development and expansion, 122 - Quantification of network performance, 124 - Verifying the quality of network service, and 126 - Attribution of network usage to users. 128 The traffic flow measurement architecture is deliberately structured so 129 that specific protocol implementations may extend coverage to 130 multi-protocol environments and to other protocol layers, such as usage 131 measurement for application-level services. Use of the same model for 132 both network- and application-level measurement may simplify the 133 development of generic analysis applications which process and/or 134 correlate any or all levels of traffic and usage information. Within 135 this docuemt the term 'usage data' is used as a generic term for the 136 data obtained using the traffic flow measurement architecture. 138 This document is not a protocol specification. It specifies and 139 structures the information that a traffic flow measurement system needs 140 to collect, describes requirements that such a system must meet, and 141 outlines tradeoffs which may be made by an implementor. 143 For performance reasons, it may be desirable to use traffic information 144 gathered through traffic flow measurement in lieu of network statistics 145 obtained in other ways. Although the quantification of network 146 performance is not the primary purpose of this architecture, the 147 measured traffic flow data may be used as an indication of network 148 performance. 150 A cost recovery structure decides "who pays for what." The major issue 151 here is how to construct a tariff (who gets billed, how much, for which 152 things, based on what information, etc). Tariff issues include 153 fairness, predictability (how well can subscribers forecast their 154 network charges), practicality (of gathering the data and administering 155 the tariff), incentives (e.g. encouraging off-peak use), and cost 156 recovery goals (100% recovery, subsidisation, profit making). Issues 157 such as these are not covered here. 159 Background information explaining why this approach was selected is 160 provided by the 'Traffic Flow Measurement: Background' RFC [1]. 162 1.1 Changes Introduced Since RFC 2063 164 The first version of the Traffic Flow Measurement Architecture was 165 published as RFC 2063 in January 1997. The most significant changes 166 made since then are summarised below. 168 - A Traffic Meter is now expected to run multiple rule sets 169 concurrently. This makes a meter much more useful, and 170 required only minimal changes to the architecture. 172 - 'NoMatch' replaces 'Fail' as an action. This name was agreed to at 173 the Working Group 1996 meeting in Montreal; it better indicates 174 that although a particular match has failed, it may be tried again 175 with the packet's addresses reversed. 177 - The 'MatchingStoD' attribute has been added. This is a Packet 178 Matching Engine (PME) attribute indicating that addresses are being 179 matched in StoD (i.e. 'wire') order. It can be used to perform 180 different actions when the match is retried, thereby simplifying 181 some kinds of rule sets. It was discussed and agreed to at the San 182 Jose meeting in 1996. 184 - Computed attributes (Class and Kind) may now be tested within a 185 rule set. This lifts an unneccessary earlier restriction. 187 - The list of attribute numbers has been extended to define ranges 188 for 'basic' attributes (in this document) and 'extended' attributes 189 (currently being developed by the RTFM Working Group). 191 - The 'Security Considerations' section has been completely 192 rewritten. It provides an evaluation of traffic measurement 193 security risks and their countermeasures. 195 2 Traffic Flow Measurement Architecture 197 A traffic flow measurement system is used by network Operations 198 personnel for managing and developing a network. It provides a tool for 199 measuring and understanding the network's traffic flows. This 200 information is useful for many purposes, as mentioned in section 1 201 (above). 203 The following sections outline a model for traffic flow measurement, 204 which draws from working drafts of the OSI accounting model [2]. Future 205 extensions are anticipated as the model is refined to address additional 206 protocol layers. 208 2.1 Meters and Traffic Flows 210 At the heart of the traffic measurement model are network entities 211 called traffic METERS. Meters count certain attributes (such as numbers 212 of packets and bytes) and classify them as belonging to ACCOUNTABLE 213 ENTITIES using other attributes (such as source and destination 214 addresses). An accountable entity is someone who (or something which) 215 is responsible for some activity on the network. It may be a user, a 216 host system, a network, a group of networks, etc, depending on the 217 granularity specified by the meter's configuration. 219 We assume that routers or traffic monitors throughout a network are 220 instrumented with meters to measure traffic. Issues surrounding the 221 choice of meter placement are discussed in the 'Traffic Flow 222 Measurement: Background' RFC [1]. An important aspect of meters is 223 that they provide a way of succinctly aggregating entity usage 224 information. 226 For the purpose of traffic flow measurement we define the concept of a 227 TRAFFIC FLOW, which is an artificial logical equivalent to a call or 228 connection. A flow is a portion of traffic, delimited by a start and 229 stop time, that was generated by a particular accountable entity. 230 Attribute values (source/destination addresses, packet counts, byte 231 counts, etc.) associated with a flow are aggregate quantities 232 reflecting events which take place in the DURATION between the start and 233 stop times. The start time of a flow is fixed for a given flow; the 234 stop time may increase with the age of the flow. 236 For connectionless network protocols such as IP there is by definition 237 no way to tell whether a packet with a particular source/destination 238 combination is part of a stream of packets or not - each packet is 239 completely independent. A traffic meter has, as part of its 240 configuration, a set of 'rules' which specify the flows of interest, in 241 terms of the values of their attributes. It derives attribute values 242 from each observed packet, and uses these to decide which flow they 243 belong to. Classifying packets into 'flows' in this way provides an 244 economical and practical way to measure network traffic and ascribe it 245 to accountable entities. 247 Usage information which is not derivable from traffic flows may also be 248 of interest. For example, an application may wish to record accesses to 249 various different information resources or a host may wish to record the 250 username (subscriber id) for a particular network session. Provision is 251 made in the traffic flow architecture to do this. In the future the 252 measurement model will be extended to gather such information from 253 applications and hosts so as to provide values for higher-layer flow 254 attributes. 256 As well as FLOWS and METERS, the traffic flow measurement model includes 257 MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in 258 following sections. The relationships between them are shown by the 259 diagram below. Numbers on the diagram refer to sections in this 260 document. 262 MANAGER 263 / \ 264 2.3 / \ 2.4 265 / \ 266 / \ ANALYSIS 267 METER <-----> METER READER <-----> APPLICATION 268 2.2 2.7 270 - MANAGER: A traffic measurement manager is an application which 271 configures 'meter' entities and controls 'meter reader' entities. 272 It uses the data requirements of analysis applications to determine 273 the appropriate configurations for each meter, and the proper 274 operation of each meter reader. It may well be convenient to 275 combine the functions of meter reader and manager within a single 276 network entity. 278 - METER: Meters are placed at measurement points determined by 279 network Operations personnel. Each meter selectively records 280 network activity as directed by its configuration settings. It can 281 also aggregate, transform and further process the recorded activity 282 before the data is stored. The processed and stored results are 283 called the 'usage data.' 285 - METER READER: A meter reader reliably transports usage data from 286 meters so that it is available to analysis applications. 288 - ANALYSIS APPLICATION: An analysis application processes the usage 289 data so as to provide information and reports which are useful for 290 network engineering and management purposes. Examples include: 292 - TRAFFIC FLOW MATRICES, showing the total flow rates for many of 293 the possible paths within an internet. 295 - FLOW RATE FREQUENCY DISTRIBUTIONS, indicating how flow rates 296 vary with time. 298 - USAGE DATA showing the total traffic volumes sent and received 299 by particular hosts. 301 The operation of the traffic measurement system as a whole is best 302 understood by considering the interactions between its components. 303 These are described in the following sections. 305 2.2 Interaction Between METER and METER READER 307 The information which travels along this path is the usage data itself. 308 A meter holds usage data in an array of flow data records known as the 309 FLOW TABLE. A meter reader may collect the data in any suitable manner. 310 For example it might upload a copy of the whole flow table using a file 311 transfer protocol, or read the records in the current flow set one at a 312 time using a suitable data transfer protocol. Note that the meter 313 reader need not read complete flow data records, a subset of their 314 attribute values may well be sufficient. 316 A meter reader may collect usage data from one or more meters. Data may 317 be collected from the meters at any time. There is no requirement for 318 collections to be synchronized in any way. 320 2.3 Interaction Between MANAGER and METER 322 A manager is responsible for configuring and controlling one or more 323 meters. Each meter's configuration includes information such as: 325 - Flow specifications, e.g. which traffic flows are to be measured, 326 how they are to be aggregated, and any data the meter is required 327 to compute for each flow being measured. 329 - Meter control parameters, e.g. the maximum size of its flow table, 330 the 'inactivity' time for flows (if no packets belonging to a flow 331 are seen for this time the flow is considered to have ended, i.e. 332 to have become idle). 334 - Sampling rate. Normally every packet will be observed. It may 335 sometimes be necessary to use sampling techniques to observe only 336 some of the packets. (Sampling algorithms are not prescribed by 337 the architecture; it should be noted that before using sampling one 338 should verify the statistical validity of the algorithm used). 339 Current experience with the measurement architecture shows that a 340 carefully-designed and implemented meter compresses the data such 341 that in normal LANs and WANs of today sampling is really not 342 needed. 344 A meter may run several rule sets concurrently on behalf of one or more 345 managers, and any manager may download a set of flow specifications 346 (i.e. a 'rule set') to a meter. Control parameters which apply to an 347 individual rule set should be set by the manager when it downloads that 348 rule set. 350 One manager should be designated as the 'master' for a meter. 351 Parameters such as sampling rate, which affect the overall operation of 352 the meter, should only be set by the master manager. 354 2.4 Interaction Between MANAGER and METER READER 356 A manager is responsible for configuring and controlling one or more 357 meter readers. A meter reader may only be controlled by a single 358 manager. A meter reader needs to know at least the following for every 359 meter it is collecting usage data from: 361 - The meter's unique identity, i.e. its network name or address. 363 - How often usage data is to be collected from the meter. 365 - Which flow records are to be collected (e.g. all active flows, the 366 whole flow table, flows seen since a given time, etc.). 368 - Which attribute values are to be collected for the required flow 369 records (e.g. all attributes, or a small subset of them) 371 Since redundant reporting may be used in order to increase the 372 reliability of usage data, exchanges among multiple entities must be 373 considered as well. These are discussed below. 375 2.5 Multiple METERs or METER READERs 377 -- METER READER A -- 378 / | \ 379 / | \ 380 =====METER 1 METER 2=====METER 3 METER 4===== 381 \ | / 382 \ | / 383 -- METER READER B -- 385 Several uniquely identified meters may report to one or more meter 386 readers. The diagram above gives an example of how multiple meters and 387 meter readers could be used. 389 In the diagram above meter 1 is read by meter reader A, and meter 4 is 390 read by meter reader B. Meters 1 and 4 have no redundancy; if either 391 fails, usage data for their network segments will be lost. 393 Meters 2 and 3, however, measure traffic on the same network segment. 394 One of them may fail leaving the other collecting the segment's usage 395 data. Meters 2 and 3 are read by meter reader A and by meter reader B. 396 If one meter reader fails, the other will continue collecting usage 397 data. 399 The architecture does not require multiple meter readers to be 400 synchronized. In the situation above meter readers A and B could both 401 collect usage data at the same intervals, but not neccesarily at the 402 same times. Note that because collections are asynchronous it is 403 unlikely that usage records from two different meter readers will agree 404 exactly. 406 If precisely synchronized collections are required this can be achieved 407 by having one manager request each meter to begin collecting a new set 408 of flows, then allowing all meter readers to collect the usage data from 409 the old sets of flows. 411 If there is only one meter reader and it fails, the meters continue to 412 run. When the meter reader is restarted it can collect all of the 413 accumulated flow data. Should this happen, time resolution will be lost 414 (because of the missed collections) but overall traffic flow information 415 will not. The only exception to this would occur if the traffic volume 416 was sufficient to 'roll over' counters for some flows during the 417 failure; this is addressed in the section on 'Rolling Counters.' 419 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 421 Synchronization between multiple management systems is the province of 422 network management protocols. This traffic flow measurement 423 architecture specifies only the network management controls necessary to 424 perform the traffic flow measurement function and does not address the 425 more global issues of simultaneous or interleaved (possibly conflicting) 426 commands from multiple network management stations or the process of 427 transferring control from one network management station to another. 429 2.7 METER READERs and APPLICATIONs 431 Once a collection of usage data has been assembled by a meter reader it 432 can be processed by an analysis application. Details of analysis 433 applications - such as the reports they produce and the data they 434 require - are outside the scope of this architecture. 436 It should be noted, however, that analysis applications will often 437 require considerable amounts of input data. An important part of 438 running a traffic flow measurement system is the storage and regular 439 reduction of flow data so as to produce daily, weekly or monthly summary 440 files for further analysis. Again, details of such data handling are 441 outside the scope of this architecture. 443 3 Traffic Flows and Reporting Granularity 445 A flow was defined in section 2.1 above in abstract terms as follows: 447 "A TRAFFIC FLOW is an artifical logical equivalent to a call or 448 connection, belonging to an ACCOUNTABLE ENTITY." 450 In practical terms, a flow is a stream of packets passing across a 451 network between two end points (or being sent from a single end point), 452 which have been summarized by a traffic meter for analysis purposes. 454 3.1 Flows and their Attributes 456 Every traffic meter maintains a table of 'flow records' for flows seen 457 by the meter. A flow record holds the values of the ATTRIBUTES of 458 interest for its flow. These attributes might include: 460 - ADDRESSES for the flow's source and destination. These comprise 461 the protocol type, the source and destination addresses at various 462 network layers (extracted from the packet), and the number of the 463 interface on which the packet was observed. 465 - First and last TIMES when packets were seen for this flow, i.e. 466 the 'creation' and 'last activity' times for the flow. 468 - COUNTS for 'forward' (source to destination) and 'backward' 469 (destination to source) components (e.g. packets and bytes) of the 470 flow's traffic. The specifying of 'source' and 'destination' for 471 flows is discussed in the section on packet matching below. 473 - OTHER attributes, e.g. information computed by the meter. 475 The attributes listed in this document (Appendix C) provide a basic 476 (i.e. useful minimum) set; they are assigned attribute numbers in the 477 range 0 to 63. The RTFM working group is working on an extended set of 478 attributes, which will have numbers in the range 65 to 127. 479 Implementors wishing to experiment with further new attributes should 480 use attribute numbers above 128. 482 A flow's ACCOUNTABLE ENTITY is specified by the values of its ADDRESS 483 attributes. For example, if a flow's address attributes specified only 484 that "source address = IP address 10.1.0.1," then all IP packets from 485 and to that address would be counted in that flow. If a flow's address 486 list were specified as "source address = IP address 10.1.0.1, 487 destination address = IP address 26.1.0.1" then only IP packets between 488 10.1.0.1 and 26.1.0.1 would be counted in that flow. 490 The addresses specifying a flow's address attributes may include one or 491 more of the following types: 493 - The INTERFACE NUMBER for the flow, i.e. the interface on which the 494 meter measured the traffic. Together with a unique address for the 495 meter this uniquely identifies a particular physical-level port. 497 - The ADJACENT ADDRESS, i.e. the [n-1] layer address of the 498 immediate source or destination on the path of the packet. For 499 example, if flow measurement is being performed at the IP layer on 500 an Ethernet LAN [3], an adjacent address is a six-octet Media 501 Access Control (MAC) address. For a host connected to the same LAN 502 segment as the meter the adjacent address will be the MAC address 503 of that host. For hosts on other LAN segments it will be the MAC 504 address of the adjacent (upstream or downstream) router carrying 505 the traffic flow. 507 - The PEER ADDRESS, which identifies the source or destination of the 508 PEER-LEVEL packet. The form of a peer address will depend on the 509 network-layer protocol in use, and the network layer [n] at which 510 traffic measurement is being performed. 512 - The TRANSPORT ADDRESS, which identifies the source or destination 513 port for the packet, i.e. its [n+1] layer address. For example, 514 if flow measurement is being performed at the IP layer a transport 515 address is a two-octet UDP or TCP port number. 517 The four definitions above specify addresses for each of the four lowest 518 layers of the OSI reference model, i.e. Physical layer, Link layer, 519 Network layer and Transport layer. A FLOW RECORD stores both the VALUE 520 for each of its addresses (as described above) and a MASK specifying 521 which bits of the address value are being used and which are ignored. 522 Note that if address bits are being ignored the meter will set them to 523 zero, however their actual values are undefined. 525 One of the key features of the traffic measurement architecture is that 526 attributes have essentially the same meaning for different protocols, so 527 that analysis applications can use the same reporting formats for all 528 protocols. This is straightforward for peer addresses; although the 529 form of addresses differs for the various protocols, the meaning of a 530 'peer address' remains the same. It becomes harder to maintain this 531 correspondence at higher layers - for example, at the Network layer IP, 532 Novell IPX and AppleTalk all use port numbers as a 'transport address,' 533 but CLNP and DECnet have no notion of ports. Further work is needed 534 here, particularly in selecting attributes which will be suitable for 535 the higher layers of the OSI reference model. 537 Reporting by adjacent intermediate sources and destinations or simply by 538 meter interface (most useful when the meter is embedded in a router) 539 supports hierarchical Internet reporting schemes as described in the 540 'Traffic Flow Measurement: Background' RFC [1]. That is, it allows 541 backbone and regional networks to measure usage to just the next lower 542 level of granularity (i.e. to the regional and stub/enterprise levels, 543 respectively), with the final breakdown according to end user (e.g. to 544 source IP address) performed by the stub/enterprise networks. 546 In cases where network addresses are dynamically allocated (e.g. mobile 547 subscribers), further subscriber identification will be necessary if 548 flows are to ascribed to individual users. Provision is made to further 549 specify the accountable entity through the use of an optional SUBSCRIBER 550 ID as part of the flow id. A subscriber ID may be associated with a 551 particular flow either through the current rule set or by proprietary 552 means within a meter, for example via protocol exchanges with one or 553 more (multi-user) hosts. At this time a subscriber ID is an arbitrary 554 text string; later versions of the architecture may specify its contents 555 in more detail. 557 3.2 Granularity of Flow Measurements 559 GRANULARITY is the 'control knob' by which an application and/or the 560 meter can trade off the overhead associated with performing usage 561 reporting against the level of detail supplied. A coarser granularity 562 means a greater level of aggregation; finer granularity means a greater 563 level of detail. Thus, the number of flows measured (and stored) at a 564 meter can be regulated by changing the granularity of the accountable 565 entity, the attributes, or the time intervals. Flows are like an 566 adjustable pipe - many fine-granularity streams can carry the data with 567 each stream measured individually, or data can be bundled in one 568 coarse-granularity pipe. 570 Flow granularity is controlled by adjusting the level of detail at which 571 the following are reported: 573 - The accountable entity (address attributes, discussed above). 575 - The categorisation of packets (other attributes, discussed below). 577 - The lifetime/duration of flows (the reporting interval needs to be 578 short enough to measure them with sufficient precision). 580 The set of rules controlling the determination of each packet's 581 accountable entity is known as the meter's CURRENT RULE SET. As will be 582 shown, the meter's current rule set forms an integral part of the 583 reported information, i.e. the recorded usage information cannot be 584 properly interpreted without a definition of the rules used to collect 585 that information. 587 Settings for these granularity factors may vary from meter to meter. 588 They are determined by the meter's current rule set, so they will change 589 if network Operations personnel reconfigure the meter to use a new rule 590 set. It is expected that the collection rules will change rather 591 infrequently; nonetheless, the rule set in effect at any time must be 592 identifiable via a RULE SET ID. Granularity of accountable entities is 593 further specified by additional ATTRIBUTES. These attributes include: 595 - Meter variables such as the index of the flow's record in the flow 596 table and the rule set id for the rules which the meter was running 597 while the flow was observed. The values of these attributes 598 provide a way of distinguishing flows observed by a meter at 599 different times. 601 - Attributes which record information derived from other attribute 602 values. Six of these are defined (SourceClass, DestClass, 603 FlowClass, SourceKind, DestKind, FlowKind), and their meaning is 604 determined by the meter's rule set. For example, one could have a 605 subroutine in the rule set which determined whether a source or 606 destination peer address was a member of an arbitrary list of 607 networks, and set SourceClass/DestClass to one if the source/dest 608 peer address was in the list or to zero otherwise. 610 - Administratively specified attributes such as Quality Of Service 611 and Priority, etc. These are not defined at this time. 613 - Higher-layer (especially application-level) attributes. These are 614 not defined at this time. 616 Settings for these granularity factors may vary from meter to meter. 617 They are determined by the meter's current rule set, so they will change 618 if network Operations personnel reconfigure the meter to use a new rule 619 set. 621 The LIFETIME of a flow is the time interval which began when the meter 622 observed the first packet belonging to the flow and ended when it saw 623 the last packet. Flow lifetimes are very variable, but many - if not 624 most - are rather short. A meter cannot measure lifetimes directly; 625 instead a meter reader collects usage data for flows which have been 626 active since the last collection, and an analysis application may 627 compare the data from each collection so as to determine when each flow 628 actually stopped. 630 The meter does, however, need to reclaim memory (i.e. records in the 631 flow table) being held by idle flows. The meter configuration includes 632 a variable called InactivityTimeout, which specifies the minimum time a 633 meter must wait before recovering the flow's record. In addition, 634 before recovering a flow record the meter must be sure that the flow's 635 data has been collected by at least one meter reader. 637 These 'lifetime' issues are considered further in the section on meter 638 readers (below). A complete list of the attributes currently defined is 639 given in Appendix C later in this document. 641 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 643 Once a usage record is sent, the decision needs to be made whether to 644 clear any existing flow records or to maintain them and add to their 645 counts when recording subsequent traffic on the same flow. The second 646 method, called rolling counters, is recommended and has several 647 advantages. Its primary advantage is that it provides greater 648 reliability - the system can now often survive the loss of some usage 649 records, such as might occur if a meter reader failed and later 650 restarted. The next usage record will very often contain yet another 651 reading of many of the same flow buckets which were in the lost usage 652 record. The 'continuity' of data provided by rolling counters can also 653 supply information used for "sanity" checks on the data itself, to guard 654 against errors in calculations. 656 The use of rolling counters does introduce a new problem: how to 657 distinguish a follow-on flow record from a new flow record. Consider 658 the following example. 660 CONTINUING FLOW OLD FLOW, then NEW FLOW 662 start time = 1 start time = 1 663 Usage record N: flow count = 2000 flow count = 2000 (done) 665 start time = 1 start time = 5 666 Usage record N+1: flow count = 3000 new flow count = 1000 668 Total count: 3000 3000 670 In the continuing flow case, the same flow was reported when its count 671 was 2000, and again at 3000: the total count to date is 3000. In the 672 OLD/NEW case, the old flow had a count of 2000. Its record was then 673 stopped (perhaps because of temporary idleness, or MAX LIFETIME policy), 674 but then more traffic with the same characteristics arrived so a new 675 flow record was started and it quickly reached a count of 1000. The 676 total flow count from both the old and new records is 3000. 678 The flow START TIMESTAMP attribute is sufficient to resolve this. In 679 the example above, the CONTINUING FLOW flow record in the second usage 680 record has an old FLOW START timestamp, while the NEW FLOW contains a 681 recent FLOW START timestamp. 683 Each packet is counted in one and only one flow, so as to avoid multiple 684 counting of a single packet. The record of a single flow is informally 685 called a "bucket." If multiple, sometimes overlapping, records of usage 686 information are required (aggregate, individual, etc), the network 687 manager should collect the counts in sufficiently detailed granularity 688 so that aggregate and combination counts can be reconstructed in 689 post-processing of the raw usage data. 691 For example, consider a meter from which it is required to record both 692 'total packets coming in interface #1' and 'total packets arriving from 693 any interface sourced by IP address = a.b.c.d.' Although a bucket can 694 be declared for each case, it is not clear how to handle a packet which 695 satisfies both criteria. It must only be counted once. By default it 696 will be counted in the first bucket for which it qualifies, and not in 697 the other bucket. Further, it is not possible to reconstruct this 698 information by post-processing. The solution in this case is to define 699 not two, but THREE buckets, each one collecting a unique combination of 700 the two criteria: 702 Bucket 1: Packets which came in interface 1, 703 AND were sourced by IP address a.b.c.d 705 Bucket 2: Packets which came in interface 1, 706 AND were NOT sourced by IP address a.b.c.d 708 Bucket 3: Packets which did NOT come in interface 1, 709 AND were sourced by IP address a.b.c.d 711 (Bucket 4: Packets which did NOT come in interface 1, 712 AND NOT sourced by IP address a.b.c.d) 714 The desired information can now be reconstructed by post-processing. 715 "Total packets coming in interface 1" can be found by adding buckets 1 & 716 2, and "Total packets sourced by IP address a.b.c.d" can be found by 717 adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly 718 required since its information is not of interest, but it is supplied 719 here in parentheses for completeness. 721 4 Meters 723 A traffic flow meter is a device for collecting data about traffic flows 724 at a given point within a network; we will call this the METERING POINT. 725 The header of every packet passing the network metering point is offered 726 to the traffic meter program. 728 A meter could be implemented in various ways, including: 730 - A dedicated small host, connected to a LAN (so that it can see all 731 packets as they pass by) and running a 'traffic meter' program. 732 The metering point is the LAN segment to which the meter is 733 attached. 735 - A multiprocessing system with one or more network interfaces, with 736 drivers enabling a traffic meter program to see packets. In this 737 case the system provides multiple metering points - traffic flows 738 on any subset of its network interfaces can be measured. 740 - A packet-forwarding device such as a router or switch. This is 741 similar to (b) except that every received packet should also be 742 forwarded, usually on a different interface. 744 4.1 Meter Structure 746 An outline of the meter's structure is given in the following diagram: 748 packet +------------------+ 749 header | Current Rule Set | 750 | +--------+---------+ 751 | | 752 +--------*---------+ +----------*-------------+ 753 | Packet Processor |<----->| Packet Matching Engine | 754 +--+------------+--+ +------------------------+ 755 | | 756 Ignore * | Count via flow key 757 | 758 +--*--------------+ 759 | 'Search' index | 760 +--------+--------+ 761 | 762 +--------*--------+ 763 | | 764 | Flow Table | 765 | | 766 +--------+--------+ 767 | 768 +--------*--------+ 769 | 'Collect' index | 770 +--------+--------+ 771 | 772 * 773 Meter Reader 775 Briefly, the meter works as follows: 777 - Incoming packet headers arrive at the top left of the diagram and 778 are passed to the PACKET PROCESSOR. 780 - The packet processor passes them to the Packet Matching Engine 781 (PME) where they are classified. 783 - The PME is a Virtual Machine running a pattern matching program 784 contained in the CURRENT RULE SET. It is invoked by the Packet 785 Processor, and returns instructions on what to do with the packet. 787 - Some packets are classified as 'to be ignored.' They are discarded 788 by the Packet Processor. 790 - Other packets are matched by the PME, which returns a FLOW KEY 791 describing the flow to which the packet belongs. 793 - The flow key is used to locate the flow's entry in the FLOW TABLE; 794 a new entry is created when a flow is first seen. The entry's 795 packet and byte counters are updated. 797 - A meter reader may collect data from the flow table at any time. 798 It may use the 'collect' index to locate the flows to be collected 799 within the flow table. 801 The discussion above assumes that a meter will only be running a single 802 rule set. A meter may, however, run several rule sets concurrently. To 803 do this the meter maintains a table of current rulesets. The packet 804 processor matches each packet against every current ruleset, producing a 805 single flow table with flows from all the rule sets. The overall effect 806 of doing this is somewhat similar to running several independent meters, 807 one for each rule set. 809 4.2 Flow Table 811 Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows 812 seen by the meter. A flow record contains attribute values for its 813 flow, including: 815 - Addresses for the flow's source and destination. These include 816 addresses and masks for various network layers (extracted from the 817 packet), and the number of the interface on which the packet was 818 observed. 820 - First and last times when packets were seen for this flow. 822 - Counts for 'forward' (source to destination) and 'backward' 823 (destination to source) components of the flow's traffic. 825 - Other attributes, e.g. state of the flow record (discussed below). 827 The state of a flow record may be: 829 - INACTIVE: The flow record is not being used by the meter. 831 - CURRENT: The record is in use and describes a flow which belongs to 832 the 'current flow set,' i.e. the set of flows recently seen by the 833 meter. 835 - IDLE: The record is in use and the flow which it describes is part 836 of the current flow set. In addition, no packets belonging to this 837 flow have been seen for a period specified by the meter's 838 InactivityTime variable. 840 4.3 Packet Handling, Packet Matching 842 Each packet header received by the traffic meter program is processed as 843 follows: 845 - Extract attribute values from the packet header and use them to 846 create a MATCH KEY for the packet. 848 - Match the packet's key against the current rule set, as explained 849 in detail below. 851 The rule set specifies whether the packet is to be counted or ignored. 852 If it is to be counted the matching process produces a FLOW KEY for the 853 flow to which the packet belongs. This flow key is used to find the 854 flow's record in the flow table; if a record does not yet exist for this 855 flow, a new flow record may be created. The counts for the matching 856 flow record can then be incremented. 858 For example, the rule set could specify that packets to or from any host 859 in IP network 130.216 are to be counted. It could also specify that 860 flow records are to be created for every pair of 24-bit (Class C) 861 subnets within network 130.216. 863 Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE 864 (PME) for matching. The PME is a Virtual Machine which uses a set of 865 instructions called RULES, i.e. a RULE SET is a program for the PME. A 866 packet's match key contains an interface number, source address (S) and 867 destination address (D) values. It does not, however, contain any 868 attribute masks for its attributes, only their values. 870 If measured flows were unidirectional, i.e. only counted packets 871 travelling in one direction, the matching process would be simple. The 872 PME would be called once to match the packet. Any flow key produced by 873 a successful match would be used to find the flow's record in the flow 874 table, and that flow's counters would be updated. 876 Flows are, however, bidirectional, reflecting the forward and reverse 877 packets of a protocol interchange or 'session.' Maintaining two sets of 878 counters in the meter's flow record makes the resulting flow data much 879 simpler to handle, since analysis programs do not have to gather 880 together the 'forward' and 'reverse' components of sessions. 881 Implementing bi-directional flows is, of course, more difficult for the 882 meter, since it must decide whether a packet is a 'forward' packet or a 883 'reverse' one. To make this decision the meter will often need to 884 invoke the PME twice, once for each possible packet direction. 886 The diagram below describes the algorithm used by the traffic meter to 887 process each packet. Flow through the diagram is from left to right and 888 top to bottom, i.e. from the top left corner to the bottom right 889 corner. S indicates the flow's source address (i.e. its set of source 890 address attribute values) from the packet, and D indicates its 891 destination address. 893 There are several cases to consider. These are: 895 - The packet is recognised as one which is TO BE IGNORED. 897 - The packet MATCHES IN BOTH DIRECTIONS. One situation in which this 898 could happen would be a rule set which matches flows within network 899 X (Source = X, Dest = X) but specifies that flows are to be created 900 for each subnet within network X, say subnets y and z. If, for 901 example a packet is seen for y->z, the meter must check that flow 902 z->y is not already current before creating y->z. 904 - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already 905 current, its forward or reverse counters are incremented. 906 Otherwise it is added to the flow table and then counted. 908 The algorithm uses four functions, as follows: 910 match(A->B) implements the PME. It uses the meter's current rule set 911 to match the attribute values in the packet's match key. A->B means 912 that the assumed source address is A and destination address B, i.e. 913 that the packet was travelling from A to B. match() returns one of 914 three results: 916 'Ignore' means that the packet was matched but this flow is not 917 to be counted. 919 'Fail' means that the packet did not match. It might, however 920 match with its direction reversed, i.e. from B to A. 922 'Suc' means that the packet did match, i.e. it belongs to a flow 923 which is to be counted. 925 current(A->B) succeeds if the flow A-to-B is current - i.e. has 926 a record in the flow table whose state is Current - and fails 927 otherwise. 929 create(A->B) adds the flow A-to-B to the flow table, setting the 930 value for attributes - such as addresses - which remain constant, 931 and zeroing the flow's counters. 933 count(A->B,f) increments the 'forward' counters for flow A-to-B. 934 count(A->B,r) increments the 'reverse' counters for flow A-to-B. 935 'Forward' here means the counters for packets travelling from 936 A to B. Note that count(A->B,f) is identical to count(B->A,r). 938 Ignore 939 --- match(S->D) -------------------------------------------------+ 940 | Suc | Fail | 941 | | Ignore | 942 | match(D->S) -----------------------------------------+ 943 | | Suc | Fail | 944 | | | | 945 | | +-------------------------------------------+ 946 | | | 947 | | Suc | 948 | current(D->S) ---------- count(D->S,r) --------------+ 949 | | Fail | 950 | | | 951 | create(D->S) ----------- count(D->S,r) --------------+ 952 | | 953 | Suc | 954 current(S->D) ------------------ count(S->D,f) --------------+ 955 | Fail | 956 | Suc | 957 current(D->S) ------------------ count(D->S,r) --------------+ 958 | Fail | 959 | | 960 create(S->D) ------------------- count(S->D,f) --------------+ 961 | 962 * 964 When writing rule sets one must remember that the meter will normally 965 try to match each packet in both directions. It is particularly 966 important that the rule set does not contain inconsistencies which will 967 upset this process. 969 Consider, for example, a rule set which counts packets from source 970 network A to destination network B, but which ignores packets from 971 source network B. This is an obvious example of an inconsistent rule 972 set, since packets from network B should be counted as reverse packets 973 for the A-to-B flow. 975 This problem could be avoided by devising a language for specifying rule 976 files and writing a compiler for it, thus making it much easier to 977 produce correct rule sets. Another approach would be to write a 'rule 978 set consistency checker' program, which could detect problems in 979 hand-written rule sets. 981 In the short term the best way to avoid these problems is to write rule 982 sets which only clasify flows in the forward direction, and rely on the 983 meter to handle reverse-travelling packets. 985 4.4 Rules and Rule Sets 987 A rule set is an array of rules. Rule sets are held within a meter as 988 entries in an array of rule sets. One member of this array is the 989 CURRENT RULE SET, in that it is the one which is currently being used by 990 the meter to classify incoming packets. 992 Rule set 1 is built in to the meter and cannot be changed. It is run 993 when the meter is started up, and provides a very coarse reporting 994 granularity; it is mainly useful for verifying that the meter is 995 running, before a 'useful' rule set is downloaded to it. 997 If the meter is instructed to use rule set 0, it will cease measuring; 998 all packets will be ignored until another (non-zero) rule set is made 999 current. 1001 Each rule in a rule set is structured as follows: 1003 +-------- test ---------+ +---- action -----+ 1004 attribute & mask = value: opcode, parameter; 1006 Opcodes contain two flags: 'goto' and 'test.' The PME maintains a 1007 Boolean indicator called the 'test indicator,' which is initially set 1008 (true). Execution begins with rule 1, the first in the rule set. It 1009 proceeds as follows: 1011 If the test indicator is true: 1012 Perform the test, i.e. AND the attribute value with the 1013 mask and compare it with the value. 1014 If these are equal the test has succeeded; perform the 1015 rule's action (below). 1016 If the test fails execute the next rule in the rule set. 1017 If there are no more rules in the rule set, return from the 1018 match() function indicating failure. 1020 If the test indicator is false, or the test (above) succeeded: 1021 Set the test indicator to this rule's test flag value. 1022 Determine the next rule to execute. 1023 If the opcode has its goto flag set, its parameter value 1024 specifies the number of the next rule. 1025 Opcodes which don't have their goto flags set either 1026 determine the next rule in special ways (Return), 1027 or they terminate execution (Ignore, NoMatch, Count, 1028 CountPkt). 1029 Perform the action. 1031 The PME maintains two 'history' data structures. The first, the 1032 'return' stack, simply records the index (i.e. 1-origin rule number) of 1033 each Gosub rule as it is executed; Return rules pop their Gosub rule 1034 index. The second, the 'pattern' queue, is used to save information for 1035 later use in building a flow key. A flow key is built by zeroing all 1036 its attribute values, then copying attribute and mask information from 1037 the pattern stack in the order it was enqueued. 1039 The opcodes are: 1041 opcode goto test 1043 1 Ignore 0 - 1044 2 NoMatch 0 - 1045 3 Count 0 - 1046 4 CountPkt 0 - 1047 5 Return 0 0 1048 6 Gosub 1 1 1049 7 GosubAct 1 0 1050 8 Assign 1 1 1051 9 AssignAct 1 0 1052 10 Goto 1 1 1053 11 GotoAct 1 0 1054 12 PushRuleTo 1 1 1055 13 PushRuleToAct 1 0 1056 14 PushPktTo 1 1 1057 15 PushPktToAct 1 0 1059 The actions they perform are: 1061 Ignore: Stop matching, return from the match() function 1062 indicating that the packet is to be ignored. 1064 NoMatch: Stop matching, return from the match() function 1065 indicating failure. 1067 Count: Stop matching. Save this rule's attribute name, 1068 mask and value in the PME's pattern queue, then 1069 construct a flow key for the flow to which this 1070 this packet belongs. Return from the match() 1071 function indicating success. The meter will use 1072 the flow key to locate the flow record for this 1073 packet's flow. 1075 CountPkt: As for Count, except that the masked value from 1076 the packet is saved in the PME's pattern queue 1077 instead of the rule's value. 1079 Gosub: Call a rule-matching subroutine. Push the current 1080 rule number on the PME's return stack, set the 1081 test indicator then goto the specified rule. 1083 GosubAct: Same as Gosub, except that the test indicator is 1084 cleared before going to the specified rule. 1086 Return: Return from a rule-matching subroutine. Pop the 1087 number of the calling gosub rule from the PME's 1088 'return' stack and add this rule's parameter value 1089 to it to determine the 'target' rule. Clear the 1090 test indicator then goto the target rule. 1092 A subroutine call appears in a rule set as a Gosub 1093 rule followed by a small group of following rules. 1094 Since a Return action clears the test flag, the 1095 action of one of these 'following' rules will be 1096 executed; this allows the subroutine to return a 1097 result (in addition to any information it may save 1098 in the PME's pattern queue). 1100 Assign: Set the attribute specified in this rule to the 1101 value specified in this rule. Set the test 1102 indicator then goto the specified rule. 1104 AssignAct: Same as Assign, except that the test indicator 1105 is cleared before going to the specified rule. 1107 Goto: Set the test indicator then goto the 1108 specified rule. 1110 GotoAct: Clear the test indicator then goto the specified 1111 rule. 1113 PushRuleTo: Save this rule's attribute name, mask and value 1114 in the PME's pattern queue. Set the test 1115 indicator then goto the specified rule. 1117 PushRuleToAct: Same as PushRuleTo, except that the test indicator 1118 is cleared before going to the specified rule. 1120 PushRuleTo actions may be used to save the value 1121 and mask used in a test, or (if the test is not 1122 performed) to save an arbitrary value and mask. 1124 PushPktTo: Save this rule's attribute name, mask, and the 1125 masked value from the packet, in the PME's pattern 1126 SET the test indicator then goto the specified 1127 rule. 1129 PushPktToAct: Same as PushPktTo, except that the test indicator 1130 is cleared before going to the specified rule. 1132 PushPktTo actions may be used to save a value from 1133 the packet using a specified mask. The test in 1134 PushPktTo rules will almost never be executed. 1136 As well as the attributes applying directly to packets (such as 1137 SourcePeerAddress, DestTransAddress, etc.) the PME implements several 1138 further attribtes. These are: 1140 Null: Tests performed on the Null attribute always succeed. 1142 MatchingStoD: Indicates whether the PME is matching the packet 1143 with its addresses in 'wire order' or with its 1144 addresses reversed. MatchingStoD's value is 1 if the 1145 addresses are in wire order (StoD), and != 1 otherwise. 1147 v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They 1148 provide a way to pass parameters into rule-matching 1149 subroutines. Each may hold the name of a normal 1150 attribute; its value is set by an Assign action. 1151 When a meter variable appears as the attribute of a 1152 rule, its value specifies the actual attribute to be 1153 tested. For example, if v1 had been assigned 1154 SourcePeerAddress as its value, a rule with v1 as its 1155 attribute would actually test SourcePeerAddress. 1157 SourceClass, DestClass, FlowClass, 1158 SourceKind, DestKind, FlowKind: 1159 These six attributes may be set by executing PushRuleto 1160 actions. They allow the PME to save (in flow records) 1161 information which has been built up during matching. 1162 Their values may be tested in rules; this allows one 1163 to set them early in a rule set, and test them later. 1165 4.5 Maintaining the Flow Table 1167 The flow table may be thought of as a 1-origin array of flow records. 1168 (A particular implementation may, of course, use whatever data structure 1169 is most suitable). When the meter starts up there are no known flows; 1170 all the flow records are in the 'inactive' state. 1172 Each time a packet is seen for a flow which is not in the current flow 1173 set a flow record is set up for it; the state of such a record is 1174 'current.' When selecting a record for the new flow the meter searches 1175 the flow table for a 'inactive' record - there is no particular 1176 significance in the ordering of records within the table. 1178 Flow data may be collected by a 'meter reader' at any time. There is no 1179 requirement for collections to be synchronized. The reader may collect 1180 the data in any suitable manner, for example it could upload a copy of 1181 the whole flow table using a file transfer protocol, or it could read 1182 the records in the current flow set row by row using a suitable data 1183 transfer protocol. 1185 The meter keeps information about collections, in particular it 1186 maintains a LastCollectTime variable which remembers the time the last 1187 collection was made. A second variable, InactivityTime, specifies the 1188 minimum time the meter will wait before considering that a flow is idle. 1190 The meter must recover records used for idle flows, if only to prevent 1191 it running out of flow records. Recovered flow records are returned to 1192 the 'inactive' state. A variety of recovery strategies are possible, 1193 including the following: 1195 One possible recovery strategy is to recover idle flow records as soon 1196 as possible after their data has been collected. To implement this the 1197 meter could run a background process which scans the flow table looking 1198 for 'current' flows whose 'last packet' time is earlier than the meter's 1199 LastCollectTime. This would be suitable for use when one was interested 1200 in measuring flow lifetimes. 1202 Another recovery strategy is to leave idle flows alone as long as 1203 possible, which would be suitable if one was only interested in 1204 measuring total traffic volumes. It could be implemented by having the 1205 meter search for collected idle flows only when it ran out of 'inactive' 1206 flow records. 1208 One further factor a meter should consider before recovering a flow is 1209 the number of meter readers which have collected the flow's data. If 1210 there are multiple meter readers operating, each reader should collect a 1211 flow's data before its memory is recovered. 1213 4.6 Handling Increasing Traffic Levels 1215 Under normal conditions the meter reader specifies which set of usage 1216 records it wants to collect, and the meter provides them. 1218 If memory usage rises above the high-water mark the meter should switch 1219 to a STANDBY RULE SET so as to increase the granularity of flow 1220 collection and decrease the rate at which new flows are created. When 1221 the manager, usually as part of a regular poll, becomes aware that the 1222 meter is using its standby rule set, it could decrease the interval 1223 between collections. The meter should also increase its efforts to 1224 recover flow memory so as to reduce the number of idle flows in memory. 1225 When the situation returns to normal, the manager may request the meter 1226 to switch back to its normal rule set. 1228 5 Meter Readers 1230 Usage data is accumulated by a meter (e.g. in a router) as memory 1231 permits. It is collected at regular reporting intervals by meter 1232 readers, as specified by a manager. The collected data is recorded in a 1233 disk file called a FLOW DATA FILE, as a sequence of USAGE RECORDS. 1235 The following sections describe the contents of usage records and flow 1236 data files. Note, however, that at this stage the details of such 1237 records and files is not specified in the architecture. Specifying a 1238 common format for them would be a worthwhile future development. 1240 5.1 Identifying Flows in Flow Records 1242 Once a packet has been classified and is ready to be counted, an 1243 appropriate flow data record must already exist in the flow table; 1244 otherwise one must be created. The flow record has a flexible format 1245 where unnecessary identification attributes may be omitted. The 1246 determination of which attributes of the flow record to use, and of what 1247 values to put in them, is specified by the current rule set. 1249 Note that the combination of start time, rule set id and subscript (row 1250 number in the flow table) provide a unique flow identifier, regardless 1251 of the values of its other attributes. 1253 The current rule set may specify additional information, e.g. a 1254 computed attribute value such as FlowKind, which is to be placed in the 1255 attribute section of the usage record. That is, if a particular flow is 1256 matched by the rule set, then the corresponding flow record should be 1257 marked not only with the qualifying identification attributes, but also 1258 with the additional information. Using this feature, several flows may 1259 each carry the same FlowKind value, so that the resulting usage records 1260 can be used in post-processing or between meter reader and meter as a 1261 criterion for collection. 1263 5.2 Usage Records, Flow Data Files 1265 The collected usage data will be stored in flow data files on the meter 1266 reader, one file for each meter. As well as containing the measured 1267 usage data, flow data files must contain information uniquely 1268 identifiying the meter from which it was collected. 1270 A USAGE RECORD contains the descriptions of and values for one or more 1271 flows. Quantities are counted in terms of number of packets and number 1272 of bytes per flow. Each usage record contains the entity identifier of 1273 the meter (a network address), a time stamp and a list of reported flows 1274 (FLOW DATA RECORDS). A meter reader will build up a file of usage 1275 records by regularly collecting flow data from a meter, using this data 1276 to build usage records and concatenating them to the tail of a file. 1277 Such a file is called a FLOW DATA FILE. 1279 A usage record contains the following information in some form: 1281 +-------------------------------------------------------------------+ 1282 | RECORD IDENTIFIERS: | 1283 | Meter Id (& digital signature if required) | 1284 | Timestamp | 1285 | Collection Rules ID | 1286 +-------------------------------------------------------------------+ 1287 | FLOW IDENTIFIERS: | COUNTERS | 1288 | Address List | Packet Count | 1289 | Subscriber ID (Optional) | Byte Count | 1290 | Attributes (Optional) | Flow Start/Stop Time | 1291 +-------------------------------------------------------------------+ 1292 5.3 Meter to Meter Reader: Usage Record Transmission 1294 The usage record contents are the raison d'etre of the system. The 1295 accuracy, reliability, and security of transmission are the primary 1296 concerns of the meter/meter reader exchange. Since errors may occur on 1297 networks, and Internet packets may be dropped, some mechanism for 1298 ensuring that the usage information is transmitted intact is needed. 1300 Flow data is moved from meter to meter reader via a series of protocol 1301 exchanges between them. This may be carried out in various ways, moving 1302 individual attribute values, complete flows, or the entire flow table 1303 (i.e. all the active flows). One possible method of achieving this 1304 transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' 1305 document [4] gives details. Note that this is simply one example; the 1306 transfer of flow data from meter to meter reader is not specified in 1307 this document. 1309 The reliability of the data transfer method under light, normal, and 1310 extreme network loads should be understood before selecting among 1311 collection methods. 1313 In normal operation the meter will be running a rule file which provides 1314 the required degree of flow reporting granularity, and the meter 1315 reader(s) will collect the flow data often enough to allow the meter's 1316 garbage collection mechanism to maintain a stable level of memory usage. 1318 In the worst case traffic may increase to the point where the meter is 1319 in danger of running completely out of flow memory. The meter 1320 implementor must decide how to handle this, for example by switching to 1321 a default (extremely coarse granularity) rule set, by sending a trap 1322 message to the manager, or by attempting to dump flow data to the meter 1323 reader. 1325 Users of the Traffic Flow Measurement system should analyse their 1326 requirements carefully and assess for themselves whether it is more 1327 important to attempt to collect flow data at normal granularity 1328 (increasing the collection frequency as needed to keep up with traffic 1329 volumes), or to accept flow data with a coarser granularity. Similarly, 1330 it may be acceptable to lose flow data for a short time in return for 1331 being sure that the meter keeps running properly, i.e. is not 1332 overwhelmed by rising traffic levels. 1334 6 Managers 1336 A manager configures meters and controls meter readers. It does this 1337 via the interactions described below. 1339 6.1 Between Manager and Meter: Control Functions 1341 - DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of 1342 these, the 'default' rule set, is built in to the meter and cannot 1343 be changed; the others must be downloaded by the manager. A 1344 manager may use any suitable protocol exchange to achieve this, for 1345 example an FTP file transfer or a series of SNMP SETs, one for each 1346 row of the rule set. 1348 - SWITCH TO SPECIFIED RULE SET: Once the rule sets have been 1349 downloaded, the manager must instruct the meter which rule set it 1350 is to actually run (i.e. which is to be the current rule set), and 1351 which is to be the standby rule set. 1353 - SET HIGH WATER MARK: A percentage value interpreted by the meter 1354 which tells the meter when to switch to its standby rule set, so as 1355 to increase the granularity of the flows and conserve the meter's 1356 flow memory. Once this has happened, the manager may also change 1357 the polling frequency or the meter's control parameters (so as to 1358 increase the rate at which the meter can recover memory from idle 1359 flows). 1361 If the high traffic levels persist, the meter's normal rule set may 1362 have to be rewritten to permanently reduce the reporting 1363 granularity. 1365 - SET FLOW TERMINATION PARAMETERS: The meter should have the good 1366 sense in situations where lack of resources may cause data loss to 1367 purge flow records from its tables. Such records may include: 1369 - Flows that have already been reported to at least one meter 1370 reader, and show no activity since the last report, 1372 - Oldest flows, or 1374 - Flows with the smallest number of unreported packets. 1376 - SET INACTIVITY TIMEOUT: This is a time in seconds since the last 1377 packet was seen for a flow. Flow records may be reclaimed if they 1378 have been idle for at least this amount of time, and have been 1379 collected in accordance with the current collection criteria. 1381 6.2 Between Manager and Meter Reader: Control Functions 1383 Because there are a number of parameters that must be set for traffic 1384 flow measurement to function properly, and viable settings may change as 1385 a result of network traffic characteristics, it is desirable to have 1386 dynamic network management as opposed to static meter configurations. 1387 Many of these operations have to do with space tradeoffs - if memory at 1388 the meter is exhausted, either the reporting interval must be decreased 1389 or a coarser granularity of aggregation must be used so that more data 1390 fits into less space. 1392 Increasing the reporting interval effectively stores data in the meter; 1393 usage data in transit is limited by the effective bandwidth of the 1394 virtual link between the meter and the meter reader, and since these 1395 limited network resources are usually also used to carry user data (the 1396 purpose of the network), the level of traffic flow measurement traffic 1397 should be kept to an affordable fraction of the bandwidth. 1398 ("Affordable" is a policy decision made by the network Operations 1399 personnel). At any rate, it must be understood that the operations 1400 below do not represent the setting of independent variables; on the 1401 contrary, each of the values set has a direct and measurable effect on 1402 the behaviour of the other variables. 1404 Network management operations follow: 1406 - MANAGER and METER READER IDENTIFICATION: The manager should ensure 1407 that meters report to the correct set of meter readers, and take 1408 steps to prevent unauthorised access to usage information. The 1409 meter readers so identified should be prepared to poll if necessary 1410 and accept data from the appropriate meters. Alternate meter 1411 readers may be identified in case both the primary manager and the 1412 primary meter reader are unavailable. Similarly, alternate 1413 managers may be identified. 1415 - REPORTING INTERVAL CONTROL: The usual reporting interval should be 1416 selected to cope with normal traffic patterns. However, it may be 1417 possible for a meter to exhaust its memory during traffic spikes 1418 even with a correctly set reporting interval. Some mechanism must 1419 be available for the meter to tell the manager that it is in danger 1420 of exhausting its memory (by declaring a 'high water' condition), 1421 and for the manager to arbitrate (by decreasing the polling 1422 interval, letting nature take its course, or by telling the meter 1423 to ask for help sooner next time). 1425 - GRANULARITY CONTROL: Granularity control is a catch-all for all the 1426 parameters that can be tuned and traded to optimise the system's 1427 ability to reliably measure and store information on all the 1428 traffic (or as close to all the traffic as an administration 1429 requires). Granularity 1430 - Controls flow-id granularities for each interface, and 1432 - Determines the number of buckets into which user traffic will 1433 be lumped together. 1435 Since granularity is controlled by the meter's current rule set, 1436 the manager can only change it by requesting the meter to switch to 1437 a different rule set. The new rule set could be downloaded when 1438 required, or it could have been downloaded as part of the meter's 1439 initial configuration. 1441 - FLOW LIFETIME CONTROL: Flow termination parameters include timeout 1442 parameters for obsoleting inactive flows and removing them from 1443 tables, and maximum flow lifetimes. This is intertwined with 1444 reporting interval and granularity, and must be set in accordance 1445 with the other parameters. 1447 6.3 Exception Conditions 1449 Exception conditions must be handled, particularly occasions when the 1450 meter runs out of buffer space. Since, to prevent counting any packet 1451 twice, packets can only be counted in a single flow at any given time, 1452 discarding records will result in the loss of information. The 1453 mechanisms to deal with this are as follows: 1455 - METER OUTAGES: In case of impending meter outages (controlled 1456 restarts, etc.) the meter could send a trap to the manager. The 1457 manager could then request one or more meter readers to pick up the 1458 usage record from the meter. 1460 Following an uncontrolled meter outage such as a power failure, the 1461 meter could send a trap to the manager indicating that it has 1462 restarted. The manager could then download the meter's correct 1463 rule set and advise the meter reader(s) that the meter is running 1464 again. Alternatively, the meter reader may discover from its 1465 regular poll that a meter has failed and restarted. It could then 1466 advise the manager of this, instead of relying on a trap from the 1467 meter. 1469 - METER READER OUTAGES: If the collection system is down or isolated, 1470 the meter should try to inform the manager of its failure to 1471 communicate with the collection system. Usage data is maintained 1472 in the flows' rolling counters, and can be recovered when the meter 1473 reader is restarted. 1475 - MANAGER OUTAGES: If the manager fails for any reason, the meter 1476 should continue measuring and the meter reader(s) should keep 1477 gathering usage records. 1479 - BUFFER PROBLEMS: The network manager may realise that there is a 1480 'low memory' condition in the meter. This can usually be 1481 attributed to the interaction between the following controls: 1483 - The reporting interval is too infrequent, 1485 - The reporting granularity is too fine, or 1487 - The throughput/bandwidth of circuits carrying the usage data is 1488 too low. 1490 The manager may change any of these parameters in response to the 1491 meter (or meter reader's) plea for help. 1493 6.4 Standard Rule Sets 1495 Although the rule table is a flexible tool, it can also become very 1496 complex. It may be helpful to develop some rule sets for common 1497 applications: 1499 - PROTOCOL TYPE: The meter records packets by protocol type. This 1500 will be the default rule table for Traffic Flow Meters. 1502 - ADJACENT SYSTEMS: The meter records packets by the MAC address of 1503 the Adjacent Systems (neighbouring originator or next-hop). 1504 (Variants on this table are "report source" or "report sink" only.) 1505 This strategy might be used by a regional or backbone network which 1506 wants to know how much aggregate traffic flows to or from its 1507 subscriber networks. 1509 - END SYSTEMS: The meter records packets by the IP address pair 1510 contained in the packet. (Variants on this table are "report 1511 source" or "report sink" only.) This strategy might be used by an 1512 End System network to get detailed host traffic matrix usage data. 1514 - TRANSPORT TYPE: The meter records packets by transport address; for 1515 IP packets this provides usage information for the various IP 1516 services. 1518 - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface 1519 report End Systems, for another interface report Adjacent Systems. 1521 This strategy might be used by an enterprise network to learn 1522 detail about local usage and use an aggregate count for the shared 1523 regional network. 1525 7 APPENDICES 1527 7.1 Appendix A: Network Characterisation 1529 Internet users have extraordinarily diverse requirements. Networks 1530 differ in size, speed, throughput, and processing power, among other 1531 factors. There is a range of traffic flow measurement capabilities and 1532 requirements. For traffic flow measurement purposes, the Internet may 1533 be viewed as a continuum which changes in character as traffic passes 1534 through the following representative levels: 1536 International | 1537 Backbones/National ---------------- 1538 / \ 1539 Regional/MidLevel ---------- ----------- 1540 / \ \ / / \ 1541 Stub/Enterprise --- --- --- ---- ---- 1542 ||| ||| ||| |||| |||| 1543 End-Systems/Hosts xxx xxx xxx xxxx xxxx 1545 Note that mesh architectures can also be built out of these components, 1546 and that these are merely descriptive terms. The nature of a single 1547 network may encompass any or all of the descriptions below, although 1548 some networks can be clearly identified as a single type. 1550 BACKBONE networks are typically bulk carriers that connect other 1551 networks. Individual hosts (with the exception of network management 1552 devices and backbone service hosts) typically are not directly connected 1553 to backbones. 1555 REGIONAL networks are closely related to backbones, and differ only in 1556 size, the number of networks connected via each port, and geographical 1557 coverage. Regionals may have directly connected hosts, acting as hybrid 1558 backbone/stub networks. A regional network is a SUBSCRIBER to the 1559 backbone. 1561 STUB/ENTERPRISE networks connect hosts and local area networks. 1562 STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 1563 networks. 1565 END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above 1566 networks. 1568 Providing a uniform identification of the SUBSCRIBER in finer 1569 granularity than that of end-system, (e.g. user/account), is beyond the 1570 scope of the current architecture, although an optional attribute in the 1571 traffic flow measurement record may carry system-specific "accountable 1572 (billable) party" labels so that meters can implement proprietary or 1573 non-standard schemes for the attribution of network traffic to 1574 responsible parties. 1576 7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 1578 Initial recommended traffic flow measurement conventions are outlined 1579 here according to the following Internet building blocks. It is 1580 important to understand what complexity reporting introduces at each 1581 network level. Whereas the hierarchy is described top-down in the 1582 previous section, reporting requirements are more easily addressed 1583 bottom-up. 1585 End-Systems 1586 Stub Networks 1587 Enterprise Networks 1588 Regional Networks 1589 Backbone Networks 1591 END-SYSTEMS are currently responsible for allocating network usage to 1592 end-users, if this capability is desired. From the Internet Protocol 1593 perspective, end-systems are the finest granularity that can be 1594 identified without protocol modifications. Even if a meter violated 1595 protocol boundaries and tracked higher-level protocols, not all packets 1596 could be correctly allocated by user, and the definition of user itself 1597 varies widely from operating system to operating system (e.g. how to 1598 trace network usage back to users from shared processes). 1600 STUB and ENTERPRISE networks will usually collect traffic data either by 1601 end- system network address or network address pair if detailed 1602 reporting is required in the local area network. If no local reporting 1603 is required, they may record usage information in the exit router to 1604 track external traffic only. (These are the only networks which 1605 routinely use attributes to perform reporting at granularities finer 1606 than end-system or intermediate-system network address.) 1608 REGIONAL networks are intermediate networks. In some cases, subscribers 1609 will be enterprise networks, in which case the intermediate system 1610 network address is sufficient to identify the regional's immediate 1611 subscriber. In other cases, individual hosts or a disjoint group of 1612 hosts may constitute a subscriber. Then end- system network address 1613 pairs need to be tracked for those subscribers. When the source may be 1614 an aggregate entity (such as a network, or adjacent router representing 1615 traffic from a world of hosts beyond) and the destination is a singular 1616 entity (or vice versa), the meter is said to be operating as a HYBRID 1617 system. 1619 At the regional level, if the overhead is tolerable it may be 1620 advantageous to report usage both by intermediate system network address 1621 (e.g. adjacent router address) and by end-system network address or 1622 end-system network address pair. 1624 BACKBONE networks are the highest level networks operating at higher 1625 link speeds and traffic levels. The high volume of traffic will in most 1626 cases preclude detailed traffic flow measurement. Backbone networks 1627 will usually account for traffic by adjacent routers' network addresses. 1629 7.3 Appendix C: List of Defined Flow Attributes 1631 This Appendix provides a checklist of the attributes defined to date; 1632 others will be added later as the Traffic Measurement Architecture is 1633 further developed. 1635 0 Null 1636 1 Flow Subscript Integer Flow table info 1637 2 Flow Status Integer 1639 4 Source Interface Integer Source Address 1640 5 Source Adjacent Type Integer 1641 6 Source Adjacent Address String 1642 7 Source Adjacent Mask String 1643 8 Source Peer Type Integer 1644 9 Source Peer Address String 1645 10 Source Peer Mask String 1646 11 Source Trans Type Integer 1647 12 Source Trans Address String 1648 13 Source Trans Mask String 1650 14 Destination Interface Integer Destination Address 1651 15 Destination Adjacent Type Integer 1652 16 Destination Adjacent Address String 1653 17 Destination AdjacentMask String 1654 18 Destination PeerType Integer 1655 19 Destination PeerAddress String 1656 20 Destination PeerMask String 1657 21 Destination TransType Integer 1658 22 Destination TransAddress String 1659 23 Destination TransMask String 1661 24 Packet Scale Factor Integer 'Other' attributes 1662 25 Byte Scale Factor Integer 1663 26 Rule Set Number Integer 1665 27 Forward Bytes Counter Source-to-Dest counters 1666 28 Forward Packets Counter 1667 29 Reverse Bytes Counter Dest-to-Source counters 1668 30 Reverse Packets Counter 1669 31 First Time TimeTicks Activity times 1670 32 Last Active Time TimeTicks 1671 33 Source Subscriber ID String Session attributes 1672 34 Destination Subscriber ID String 1673 35 Session ID String 1675 36 Source Class Integer 'Computed' attributes 1676 37 Destination Class Integer 1677 38 Flow Class Integer 1678 39 Source Kind Integer 1679 40 Destination Kind Integer 1680 41 Flow Kind Integer 1682 50 MatchingStoD Integer PME variable 1684 51 V1 Integer Meter variables 1685 52 V2 Integer 1686 53 V3 Integer 1687 54 V4 Integer 1688 55 V5 Integer 1690 65 1691 .. 'Extended' attributes (to be defined by the RTFM working group) 1692 127 1694 7.4 Appendix D: List of Meter Control Variables 1696 Current Rule Set Number Integer 1697 Standby Rule Set Number Integer 1698 High Water Mark Percentage 1699 Flood Mark Percentage 1700 Inactivity Timeout (seconds) Integer 1701 Last Collect Time TimeTicks 1703 8 Security Considerations 1705 8.1 Threat Analysis 1707 A traffic flow measurement system may be subject to the following kinds 1708 of attacks: 1710 - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain 1711 advantage or cause mischief (e.g. denial of service) by subverting 1712 any of the system elements - meters, meter readers or managers. 1714 - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to 1715 disclosure can be read through active or passive attacks unless it 1716 is suitably protected. Usage data may or may not be of this type. 1717 Control messages, traps, etc. are not likely to be considered 1718 sensitive to disclosure. 1720 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: 1721 Similarly, any data whose integrity is sensitive can be altered, 1722 replaced/injected or deleted through active or passive attacks 1723 unless it is suitably protected. Attackers may modify message 1724 streams to falsify usage data or interfere with the proper 1725 operation of the traffic flow measurement system. Therefore, all 1726 messages, both those containing usage data and those containing 1727 control data, should be considered vulnerable to such attacks. 1729 8.2 Countermeasures 1731 The following countermeasures are recommended to address the possible 1732 threats enumerated above: 1734 - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use 1735 of authentication and access control services. 1737 - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a 1738 confidentiality (encryption) service. 1740 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is 1741 countered through the use of an integrity service. 1743 An Internet Accounting system must address all of these concerns. Since 1744 a high degree of protection is required, the use of strong cryptographic 1745 methodologies is recommended. The security requirements for 1746 communication between pairs of accounting system elements are summarized 1747 in the table below. It is assumed that meters do not communicate with 1748 other meters, and that meter readers do not communicate directly with 1749 other meter readers (if synchronization is required, it is handled by 1750 the manager, see Section 2.5). Each entry in the table indicates which 1751 kinds of security services are required. Basically, the requirements 1752 are as follows: 1754 Security Service Requirements for RTFM elements 1756 +------------------------------------------------------------------+ 1757 | from\to | meter | meter reader | application | manager | 1758 |---------+--------------+--------------+-------------+------------| 1759 | meter | N/A | authent | N/A | authent | 1760 | | | acc ctrl | | acc ctrl | 1761 | | | integrity | | | 1762 | | | confid ** | | | 1763 |---------+--------------+--------------+-------------+------------| 1764 | meter | authent | N/A | authent | authent | 1765 | reader | acc ctrl | | acc ctrl | acc ctrl | 1766 | | | | integrity | | 1767 | | | | confid ** | | 1768 |---------+--------------+--------------+-------------+------------| 1769 | appl | N/A | authent | | | 1770 | | | acc ctrl | ## | N/A | 1771 |---------+--------------+--------------+-------------+------------| 1772 | manager | authent | authent | N/A | authent | 1773 | | acc ctrl | acc ctrl | | acc ctrl | 1774 | | integrity | integrity | | integrity | 1775 +------------------------------------------------------------------+ 1777 N/A = Not Applicable ** = optional ## = outside RTFM scope 1779 - When any two elements intercommunicate they should mutually 1780 authenticate themselves to one another. 1782 - Whenever there is a transfer of information its integrity should be 1783 protected. 1785 - Whenever there is a transfer of usage data it should be possible to 1786 ensure its confidentiality if it is deemed sensitive to disclosure. 1788 Security protocols are not specified in this document. The system 1789 elements' management and collection protocols are responsible for 1790 providing sufficient data integrity, confidentiality, authentication and 1791 access control services. 1793 9 Acknowledgments 1795 An initial draft of this document was produced under the auspices of the 1796 IETF's Internet Accounting Working Group with assistance from SNMP, RMON 1797 and SAAG working groups. This version documents the implementation work 1798 done by the Internet Accounting Working Group, and is intended to 1799 provide a starting point for the Realtime Traffic Flow Measurement 1800 Working Group. Particular thanks are due to Stephen Stibler (IBM 1801 Research) for his patient and careful comments during the preparation of 1802 this draft. 1804 10 References 1806 [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 1807 Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian 1808 Technology Corporation, November 1991. 1810 [2] International Standards Organisation (ISO), "Management 1811 Framework," Part 4 of Information Processing Systems Open 1812 Systems Interconnection Basic Reference Model, ISO 7498-4, 1813 1994. 1815 [3] IEEE 802.3/ISO 8802-3 Information Processing Systems - 1816 Local Area Networks - Part 3: Carrier sense multiple access 1817 with collision detection (CSMA/CD) access method and physical 1818 layer specifications, 2nd edition, September 21, 1990. 1820 [4] Brownlee, N., "Traffic Flow Measurement: Meter MIB," 1821 Internet Draft, 'Working draft' to become an experimental RFC. 1823 11 Author's Addresses 1825 Nevil Brownlee 1826 Information Technology Systems & Services 1827 The University of Auckland 1829 Phone: +64 9 373 7599 x8941 1830 E-mail: n.brownlee @auckland.ac.nz 1832 Cyndi Mills 1833 BBN Systems and Technologies 1835 Phone: +1 617 873 4143 1836 E-mail: cmills@bbn.com 1838 Greg Ruth 1839 GTE Laboratories, Inc 1841 Phone: +1 617 466 2448 1842 E-mail: gruth@gte.com