idnits 2.17.1 draft-ietf-rtfm-architecture-02.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 1072 has weird spacing: '... goto tes...' == Line 1669 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 (Jun 1998) is 9447 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. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Brownlee, Mills, Ruth 2 INTERNET-DRAFT The University of Auckland 3 Dec 1997 4 Expires Jun 1998 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 (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document describes an architecture for the measurement and 33 reporting of network traffic flows, discusses how this relates to an 34 overall network traffic flow architecture, and describes how it can be 35 used within the Internet. It is intended to provide a starting point 36 for the Realtime Traffic Flow Measurement Working Group. 38 Contents 40 1 Statement of Purpose and Scope 3 41 1.1 Changes Introduced Since RFC 2063 . . . . . . . . . . . . . . 4 43 2 Traffic Flow Measurement Architecture 5 44 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 5 45 2.2 Interaction Between METER and METER READER . . . . . . . . . . 7 46 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8 47 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8 48 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 49 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 50 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10 52 3 Traffic Flows and Reporting Granularity 10 53 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 54 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13 55 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only. . . . 15 57 4 Meters 17 58 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 59 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18 60 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 61 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 62 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26 63 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27 65 5 Meter Readers 28 66 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 28 67 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29 68 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30 70 6 Managers 30 71 6.1 Between Manager and Meter: Control Functions . . . . . . . . 30 72 6.2 Between Manager and Meter Reader: Control Functions . . . . . 31 73 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33 74 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34 76 7 Security Considerations 34 77 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 34 78 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 35 80 8 APPENDICES 37 81 8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 37 82 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 38 83 8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 39 84 8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 40 86 9 Acknowledgments 40 88 10 References 41 90 11 Author's Addresses 41 91 1 Statement of Purpose and Scope 93 This document describes an architecture for traffic flow measurement and 94 reporting for data networks which has the following characteristics: 96 - The traffic flow model can be consistently applied to any 97 protocol/application at any network layer (e.g. network, 98 transport, application layers). 100 - Traffic flow attributes are defined in such a way that they are 101 valid for multiple networking protocol stacks, and that traffic 102 flow measurement implementations are useful in MULTI-PROTOCOL 103 environments. 105 - Users may specify their traffic flow measurement requirements by 106 writing 'rule sets,' allowing them to collect the flow data they 107 need while ignoring other traffic. 109 - The data reduction effort to produce requested traffic flow 110 information is placed as near as possible to the network 111 measurement point. This minimises the volume of data to be 112 obtained (and transmitted across the network for storage), and 113 reduces the amount of processing required in traffic flow analysis 114 applications. 116 The architecture specifies common metrics for measuring traffic flows. 117 By using the same metrics, traffic flow data can be exchanged and 118 compared across multiple platforms. Such data is useful for: 120 - Understanding the behaviour of existing networks, 122 - Planning for network development and expansion, 124 - Quantification of network performance, 126 - Verifying the quality of network service, and 128 - Attribution of network usage to users. 130 The traffic flow measurement architecture is deliberately structured so 131 that specific protocol implementations may extend coverage to 132 multi-protocol environments and to other protocol layers, such as usage 133 measurement for application-level services. Use of the same model for 134 both network- and application-level measurement may simplify the 135 development of generic analysis applications which process and/or 136 correlate any or all levels of traffic and usage information. Within 137 this docuemt the term 'usage data' is used as a generic term for the 138 data obtained using the traffic flow measurement architecture. 140 This document is not a protocol specification. It specifies and 141 structures the information that a traffic flow measurement system needs 142 to collect, describes requirements that such a system must meet, and 143 outlines tradeoffs which may be made by an implementor. 145 For performance reasons, it may be desirable to use traffic information 146 gathered through traffic flow measurement in lieu of network statistics 147 obtained in other ways. Although the quantification of network 148 performance is not the primary purpose of this architecture, the 149 measured traffic flow data may be used as an indication of network 150 performance. 152 A cost recovery structure decides "who pays for what." The major issue 153 here is how to construct a tariff (who gets billed, how much, for which 154 things, based on what information, etc). Tariff issues include 155 fairness, predictability (how well can subscribers forecast their 156 network charges), practicality (of gathering the data and administering 157 the tariff), incentives (e.g. encouraging off-peak use), and cost 158 recovery goals (100% recovery, subsidisation, profit making). Issues 159 such as these are not covered here. 161 Background information explaining why this approach was selected is 162 provided by the 'Internet Accounting: Background' RFC [1]. 164 1.1 Changes Introduced Since RFC 2063 166 The first version of the Traffic Flow Measurement Architecture was 167 published as RFC 2063 in January 1997. The most significant changes 168 made since then are summarised below. 170 - A Traffic Meter can now run multiple rule sets concurrently. This 171 makes a meter much more useful, and required only minimal changes 172 to the architecture. 174 - 'NoMatch' replaces 'Fail' as an action. This name was agreed to at 175 the Working Group 1996 meeting in Montreal; it better indicates 176 that although a particular match has failed, it may be tried again 177 with the packet's addresses reversed. 179 - The 'MatchingStoD' attribute has been added. This is a Packet 180 Matching Engine (PME) attribute indicating that addresses are being 181 matched in StoD (i.e. 'wire') order. It can be used to perform 182 different actions when the match is retried, thereby simplifying 183 some kinds of rule sets. It was discussed and agreed to at the San 184 Jose meeting in 1996. 186 - Computed attributes (Class and Kind) may now be tested within a 187 rule set. This lifts an unneccessary earlier restriction. 189 - The list of attribute numbers has been extended to define ranges 190 for 'basic' attributes (in this document) and 'extended' attributes 191 (currently being developed by the RTFM Working Group). 193 - The 'Security Considerations' section has been completely 194 rewritten. It provides an evaluation of traffic measurement 195 security risks and their countermeasures. 197 2 Traffic Flow Measurement Architecture 199 A traffic flow measurement system is used by Network Operations 200 personnel to aid in managing and developing a network. It provides a 201 tool for measuring and understanding the network's traffic flows. This 202 information is useful for many purposes, as mentioned in section 1 203 (above). 205 The following sections outline a model for traffic flow measurement, 206 which draws from working drafts of the OSI accounting model [2]. Future 207 extensions are anticipated as the model is refined to address additional 208 protocol layers. 210 2.1 Meters and Traffic Flows 212 At the heart of the traffic measurement model are network entities 213 called traffic METERS. Meters observe packets as they pass by a single 214 point on their way through the network and classify them into certain 215 groups. For each such group a meter will accumulate certain attributes, 216 for example the numbers of packets and bytes observed for the group. 217 These METERED TRAFFIC GROUPS may correspond to a user, a host system, a 218 network, a group of networks, a particular transport address (e.g. an 219 IP port number), any combination of the above, etc, depending on the 220 meter's configuration. 222 We assume that routers or traffic monitors throughout a network are 223 instrumented with meters to measure traffic. Issues surrounding the 224 choice of meter placement are discussed in the 'Traffic Flow 225 Measurement: Background' RFC [1]. An important aspect of meters is 226 that they provide a way of succinctly aggregating traffic information. 228 For the purpose of traffic flow measurement we define the concept of a 229 TRAFFIC FLOW, which is like an artificial logical equivalent to a call 230 or connection. A flow is a portion of traffic, delimited by a start and 231 stop time, that belongs to one of the metered traffic groups mentioned 232 above. Attribute values (source/destination addresses, packet counts, 233 byte counts, etc.) associated with a flow are aggregate quantities 234 reflecting events which take place in the DURATION between the start and 235 stop times. The start time of a flow is fixed for a given flow; the 236 stop time may increase with the age of the flow. 238 For connectionless network protocols such as IP there is by definition 239 no way to tell whether a packet with a particular source/destination 240 combination is part of a stream of packets or not - each packet is 241 completely independent. A traffic meter has, as part of its 242 configuration, a set of 'rules' which specify the flows of interest, in 243 terms of the values of their attributes. It derives attribute values 244 from each observed packet, and uses these to decide which flow they 245 belong to. Classifying packets into 'flows' in this way provides an 246 economical and practical way to measure network traffic and subdivide it 247 into well-defined groups. 249 Usage information which is not derivable from traffic flows may also be 250 of interest. For example, an application may wish to record accesses to 251 various different information resources or a host may wish to record the 252 username (subscriber id) for a particular network session. Provision is 253 made in the traffic flow architecture to do this. In the future the 254 measurement model may be extended to gather such information from 255 applications and hosts so as to provide values for higher-layer flow 256 attributes. 258 As well as FLOWS and METERS, the traffic flow measurement model includes 259 MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in 260 following sections. The relationships between them are shown by the 261 diagram below. Numbers on the diagram refer to sections in this 262 document. 264 MANAGER 265 / \ 266 2.3 / \ 2.4 267 / \ 268 / \ ANALYSIS 269 METER <-----> METER READER <-----> APPLICATION 270 2.2 2.7 272 - MANAGER: MANAGER: A traffic measurement manager is an application 273 which configures 'meter' entities and controls 'meter reader' 274 entities. It sends configuration commands to the meters, and 275 supervises the proper operation of each meter and meter reader. It 276 may well be convenient to combine the functions of meter reader and 277 manager within a single network entity. 279 - METER: Meters are placed at measurement points determined by 280 Network Operations personnel. Each meter selectively records 281 network activity as directed by its configuration settings. It can 282 also aggregate, transform and further process the recorded activity 283 before the data is stored. The processed and stored results are 284 called the 'usage data.' 286 - METER READER: A meter reader reliably transports usage data from 287 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, summarizing flow rates over 296 a period of 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 'inactivity' time for flows (if 330 no packets belonging to a flow are seen for this time the flow is 331 considered to have ended, i.e. to have become idle). 333 - Sampling rate. Normally every packet will be observed. It may 334 sometimes be necessary to use sampling techniques to observe only 335 some of the packets. (Sampling algorithms are not prescribed by 336 the architecture; it should be noted that before using sampling one 337 should verify the statistical validity of the algorithm used). 338 Current experience with the measurement architecture shows that a 339 carefully-designed and implemented meter compresses the data such 340 that in normal LANs and WANs of today sampling is really not 341 needed. 343 A meter may run several rule sets concurrently on behalf of one or more 344 managers, and any manager may download a set of flow specifications 345 (i.e. a 'rule set') to a meter. Control parameters which apply to an 346 individual rule set should be set by the manager after it downloads that 347 rule set. 349 One manager should be designated as the 'master' for a meter. 350 Parameters such as sampling rate, which affect the overall operation of 351 the meter, should only be set by the master manager. 353 2.4 Interaction Between MANAGER and METER READER 355 A manager is responsible for configuring and controlling one or more 356 meter readers. A meter reader may only be controlled by a single 357 manager. A meter reader needs to know at least the following for every 358 meter it is collecting usage data from: 360 - The meter's unique identity, i.e. its network name or address. 362 - How often usage data is to be collected from the meter. 364 - Which flow records are to be collected (e.g. all flows, flows for 365 a particular rule set, flows which have been active since a given 366 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 meter 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 data 397 from both meters. 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 running a new set of 408 rules at the same time, then allowing all meter readers to collect the 409 usage data from the flows recorded by the old rule sets. 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 a (user-specieied) METERED TRAFFIC 449 GROUP." 451 In practical terms, a flow is a stream of packets observed by the meter 452 as they pass across a network between two end points (or from a single 453 end point), which have been summarized by a traffic meter for analysis 454 purposes. 456 3.1 Flows and their Attributes 458 Every traffic meter maintains a table of 'flow records' for flows seen 459 by the meter. A flow record holds the values of the ATTRIBUTES of 460 interest for its flow. These attributes might include: 462 - ADDRESSES for the flow's source and destination. These comprise 463 the protocol type, the source and destination addresses at various 464 network layers (extracted from the packet header), and the number 465 of the interface on which the packet was observed. 467 - First and last TIMES when packets were seen for this flow, i.e. 468 the 'creation' and 'last activity' times for the flow. 470 - COUNTS for 'forward' (source to destination) and 'backward' 471 (destination to source) components (e.g. packets and bytes) of the 472 flow's traffic. The specifying of 'source' and 'destination' for 473 flows is discussed in the section on packet matching below. 475 - OTHER attributes, e.g. the index of the flow's record in the flow 476 table and the rule set id for the rules which the meter was running 477 while the flow was observed. The values of these attributes 478 provide a way of distinguishing flows observed by a meter at 479 different times. 481 The attributes listed in this document (Appendix C) provide a basic 482 (i.e. useful minimum) set; they are assigned attribute numbers in the 483 range 0 to 63. The RTFM working group is working on an extended set of 484 attributes, which will have numbers in the range 64 to 127. 485 Implementors wishing to experiment with further new attributes should 486 use attribute numbers 128 and above. 488 A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS 489 attributes. For example, if a flow's address attributes specified only 490 that "source address = IP address 10.1.0.1," then all IP packets from 491 and to that address would be counted in that flow. If a flow's address 492 list were specified as "source address = IP address 10.1.0.1, 493 destination address = IP address 26.1.0.1" then only IP packets between 494 10.1.0.1 and 26.1.0.1 would be counted in that flow. 496 The addresses specifying a flow's address attributes may include one or 497 more of the following types: 499 - The INTERFACE NUMBER for the flow, i.e. the interface on which the 500 meter measured the traffic. Together with a unique address for the 501 meter this uniquely identifies a particular physical-level port. 503 - The ADJACENT ADDRESS, i.e. the [n-1] layer address of the 504 immediate source or destination on the path of the packet. For 505 example, if flow measurement is being performed at the IP layer on 506 an Ethernet LAN [3], an adjacent address will normally be a 507 six-octet Media Access Control (MAC) address. For a host connected 508 to the same LAN segment as the meter the adjacent address will be 509 the MAC address of that host. For hosts on other LAN segments it 510 will be the MAC address of the adjacent (upstream or downstream) 511 router carrying the traffic flow. 513 - The PEER ADDRESS, which identifies the source or destination of the 514 PEER-LEVEL packet. The form of a peer address will depend on the 515 network-layer protocol in use, and the network layer [n] at which 516 traffic measurement is being performed. 518 - The TRANSPORT ADDRESS, which identifies the source or destination 519 port for the packet, i.e. its [n+1] layer address. For example, 520 if flow measurement is being performed at the IP layer a transport 521 address is a two-octet UDP or TCP port number. 523 The four definitions above specify addresses for each of the four lowest 524 layers of the OSI reference model, i.e. Physical layer, Link layer, 525 Network layer and Transport layer. A FLOW RECORD stores both the VALUE 526 for each of its addresses (as described above) and a MASK specifying 527 which bits of the address value are being used and which are ignored. 528 Note that if address bits are being ignored the meter will set them to 529 zero, however their actual values are undefined. 531 One of the key features of the traffic measurement architecture is that 532 attributes have essentially the same meaning for different protocols, so 533 that analysis applications can use the same reporting formats for all 534 protocols. This is straightforward for peer addresses; although the 535 form of addresses differs for the various protocols, the meaning of a 536 'peer address' remains the same. It becomes harder to maintain this 537 correspondence at higher layers - for example, at the Network layer IP, 538 Novell IPX and AppleTalk all use port numbers as a 'transport address,' 539 but CLNP and DECnet have no notion of ports. Further work is needed 540 here, particularly in selecting attributes which will be suitable for 541 the higher layers of the OSI reference model. 543 Reporting by adjacent intermediate sources and destinations or simply by 544 meter interface (most useful when the meter is embedded in a router) 545 supports hierarchical Internet reporting schemes as described in the 546 'Internet Accounting: Background' RFC [1]. That is, it allows backbone 547 and regional networks to measure usage to just the next lower level of 548 granularity (i.e. to the regional and stub/enterprise levels, 549 respectively), with the final breakdown according to end user (e.g. to 550 source IP address) performed by the stub/enterprise networks. 552 In cases where network addresses are dynamically allocated (e.g. mobile 553 subscribers), further subscriber identification will be necessary if 554 flows are to ascribed to individual users. Provision is made to further 555 specify the metered traffic group through the use of an optional 556 SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated 557 with a particular flow either through the current rule set or by 558 proprietary means within a meter, for example via protocol exchanges 559 with one or more (multi-user) hosts. At this time a subscriber ID is an 560 arbitrary text string; later versions of the architecture may specify 561 its contents in more detail. 563 3.2 Granularity of Flow Measurements 565 GRANULARITY is the 'control knob' by which an application and/or the 566 meter can trade off the overhead associated with performing usage 567 reporting against its level of detail. A coarser granularity means a 568 greater level of aggregation; finer granularity means a greater level of 569 detail. Thus, the number of flows measured (and stored) at a meter can 570 be regulated by changing the granularity of their attributes. Flows are 571 like an adjustable pipe - many fine-granularity streams can carry the 572 data with each stream measured individually, or data can be bundled in 573 one coarse-granularity pipe. Time granularity may be controlled by 574 varying the reporting interval, i.e. the time between meter readings. 576 Flow granularity is controlled by adjusting the level of detail for the 577 following: 579 - The metered traffic group (address attributes, discussed above). 581 - The categorisation of packets (other attributes, discussed below). 583 - The lifetime/duration of flows (the reporting interval needs to be 584 short enough to measure them with sufficient precision). 586 The set of rules controlling the determination of each packet's metered 587 traffic group is known as the meter's CURRENT RULE SET. As will be 588 shown, the meter's current rule set forms an integral part of the 589 reported information, i.e. the recorded usage information cannot be 590 properly interpreted without a definition of the rules used to collect 591 that information. 593 Settings for these granularity factors may vary from meter to meter. 594 They are determined by the meter's current rule set, so they will change 595 if network Operations personnel reconfigure the meter to use a new rule 596 set. It is expected that the collection rules will change rather 597 infrequently; nonetheless, the rule set in effect at any time must be 598 identifiable via a RULE SET ID. Granularity of metered traffic groups is 599 further specified by additional ATTRIBUTES. These attributes include: 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 all meter readers which registered to collect 636 it. 638 These 'lifetime' issues are considered further in the section on meter 639 readers (below). A complete list of the attributes currently defined is 640 given in Appendix C later in this document. 642 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 644 Once a usage record is sent, the decision needs to be made whether to 645 clear any existing flow records or to maintain them and add to their 646 counts when recording subsequent traffic on the same flow. The second 647 method, called rolling counters, is recommended and has several 648 advantages. Its primary advantage is that it provides greater 649 reliability - the system can now often survive the loss of some usage 650 records, such as might occur if a meter reader failed and later 651 restarted. The next usage record will very often contain yet another 652 reading of many of the same flow buckets which were in the lost usage 653 record. The 'continuity' of data provided by rolling counters can also 654 supply information used for "sanity" checks on the data itself, to guard 655 against errors in calculations. 657 The use of rolling counters does introduce a new problem: how to 658 distinguish a follow-on flow record from a new flow record. Consider 659 the following example. 661 CONTINUING FLOW OLD FLOW, then NEW FLOW 663 start time = 1 start time = 1 664 Usage record N: flow count = 2000 flow count = 2000 (done) 666 start time = 1 start time = 5 667 Usage record N+1: flow count = 3000 new flow count = 1000 669 Total count: 3000 3000 671 In the continuing flow case, the same flow was reported when its count 672 was 2000, and again at 3000: the total count to date is 3000. In the 673 OLD/NEW case, the old flow had a count of 2000. Its record was then 674 stopped (perhaps because of temporary idleness), but then more traffic 675 with the same characteristics arrived so a new flow record was started 676 and it quickly reached a count of 1000. The total flow count from both 677 the old and new records is 3000. 679 The flow START TIMESTAMP attribute is sufficient to resolve this. In 680 the example above, the CONTINUING FLOW flow record in the second usage 681 record has an old FLOW START timestamp, while the NEW FLOW contains a 682 recent FLOW START timestamp. 684 Each packet is counted in at most one flow for each running ruleset, so 685 as to avoid multiple counting of a single packet. The record of a 686 single flow is informally called a "bucket." If multiple, sometimes 687 overlapping, records of usage information are required (aggregate, 688 individual, etc), the network manager should collect the counts in 689 sufficiently detailed granularity so that aggregate and combination 690 counts can be reconstructed in post-processing of the raw usage data. 691 Alternatively, multiple rulesets could be used to collect data at 692 different granularities. 694 For example, consider a meter from which it is required to record both 695 'total packets coming in interface #1' and 'total packets arriving from 696 any interface sourced by IP address = a.b.c.d,' using a single rule set. 697 Although a bucket can be declared for each case, it is not clear how to 698 handle a packet which satisfies both criteria. It must only be counted 699 once. By default it will be counted in the first bucket for which it 700 qualifies, and not in the other bucket. Further, it is not possible to 701 reconstruct this information by post-processing. The solution in this 702 case is to define not two, but THREE buckets, each one collecting a 703 unique combination of the two criteria: 705 Bucket 1: Packets which came in interface 1, 706 AND were sourced by IP address a.b.c.d 708 Bucket 2: Packets which came in interface 1, 709 AND were NOT sourced by IP address a.b.c.d 711 Bucket 3: Packets which did NOT come in interface 1, 712 AND were sourced by IP address a.b.c.d 714 (Bucket 4: Packets which did NOT come in interface 1, 715 AND NOT sourced by IP address a.b.c.d) 717 The desired information can now be reconstructed by post-processing. 718 "Total packets coming in interface 1" can be found by adding buckets 1 & 719 2, and "Total packets sourced by IP address a.b.c.d" can be found by 720 adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly 721 required since its information is not of interest, but it is supplied 722 here in parentheses for completeness. 724 Alternatively, the above could be achieved by running two rule sets (A 725 and B), as follows: 727 Bucket 1: Packets which came in interface 1; 728 counted by rule set A. 730 Bucket 2: Packets which were sourcede by IP address a.b.c.d; 731 counted by rule set B. 733 4 Meters 735 A traffic flow meter is a device for collecting data about traffic flows 736 at a given point within a network; we will call this the METERING POINT. 737 The header of every packet passing the network metering point is offered 738 to the traffic meter program. 740 A meter could be implemented in various ways, including: 742 - A dedicated small host, connected to a LAN (so that it can see all 743 packets as they pass by) and running a traffic meter program. The 744 metering point is the LAN segment to which the meter is attached. 746 - A multiprocessing system with one or more network interfaces, with 747 drivers enabling a traffic meter program to see packets. In this 748 case the system provides multiple metering points - traffic flows 749 on any subset of its network interfaces can be measured. 751 - A packet-forwarding device such as a router or switch. This is 752 similar to (b) except that every received packet should also be 753 forwarded, usually on a different interface. 755 4.1 Meter Structure 757 An outline of the meter's structure is given in the following diagram: 759 Briefly, the meter works as follows: 761 - Incoming packet headers arrive at the top left of the diagram and 762 are passed to the PACKET PROCESSOR. 764 - The packet processor passes them to the Packet Matching Engine 765 (PME) where they are classified. 767 - The PME is a Virtual Machine running a pattern matching program 768 contained in the CURRENT RULE SET. It is invoked by the Packet 769 Processor, and returns instructions on what to do with the packet. 771 - Some packets are classified as 'to be ignored.' They are discarded 772 by the Packet Processor. 774 - Other packets are matched by the PME, which returns a FLOW KEY 775 describing the flow to which the packet belongs. 777 - The flow key is used to locate the flow's entry in the FLOW TABLE; 778 a new entry is created when a flow is first seen. The entry's data 779 fields (e.g. packet and byte counters) are updated. 781 - A meter reader may collect data from the flow table at any time. 782 It may use the 'collect' index to locate the flows to be collected 783 within the flow table. 785 packet +------------------+ 786 header | Current Rule Set | 787 | +--------+---------+ 788 | | 789 +--------*---------+ +----------*-------------+ 790 | Packet Processor |<----->| Packet Matching Engine | 791 +--+------------+--+ +------------------------+ 792 | | 793 Ignore * | Count via flow key 794 | 795 +--*--------------+ 796 | 'Search' index | 797 +--------+--------+ 798 | 799 +--------*--------+ 800 | | 801 | Flow Table | 802 | | 803 +--------+--------+ 804 | 805 +--------*--------+ 806 | 'Collect' index | 807 +--------+--------+ 808 | 809 * 810 Meter Reader 812 The discussion above assumes that a meter will only be running a single 813 rule set. A meter may, however, run several rule sets concurrently. To 814 do this the meter maintains a table of current rulesets. The packet 815 processor matches each packet against every current ruleset, producing a 816 single flow table with flows from all the rule sets. The overall effect 817 of doing this is somewhat similar to running several independent meters, 818 one for each rule set. 820 4.2 Flow Table 822 Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows 823 seen by the meter. A flow record contains attribute values for its 824 flow, including: 826 - Addresses for the flow's source and destination. These include 827 addresses and masks for various network layers (extracted from the 828 packet), and the identity of the interface on which the packet was 829 observed. 831 - First and last times when packets were seen for this flow. 833 - Counts for 'forward' (source to destination) and 'backward' 834 (destination to source) components of the flow's traffic. 836 - Other attributes, e.g. state of the flow record (discussed below). 838 The state of a flow record may be: 840 - INACTIVE: The flow record is not being used by the meter. 842 - CURRENT: The record is in use and describes a flow which belongs to 843 the 'current flow set,' i.e. the set of flows recently seen by the 844 meter. 846 - IDLE: The record is in use and the flow which it describes is part 847 of the current flow set. In addition, no packets belonging to this 848 flow have been seen for a period specified by the meter's 849 InactivityTime variable. 851 4.3 Packet Handling, Packet Matching 853 Each packet header received by the traffic meter program is processed as 854 follows: 856 - Extract attribute values from the packet header and use them to 857 create a MATCH KEY for the packet. 859 - Match the packet's key against the current rule set, as explained 860 in detail below. 862 The rule set specifies whether the packet is to be counted or ignored. 863 If it is to be counted the matching process produces a FLOW KEY for the 864 flow to which the packet belongs. This flow key is used to find the 865 flow's record in the flow table; if a record does not yet exist for this 866 flow, a new flow record may be created. The data for the matching flow 867 record can then be updated. 869 For example, the rule set could specify that packets to or from any host 870 in IP network 130.216 are to be counted. It could also specify that 871 flow records are to be created for every pair of 24-bit (Class C) 872 subnets within network 130.216. 874 Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE 875 (PME) for matching. The PME is a Virtual Machine which uses a set of 876 instructions called RULES, i.e. a RULE SET is a program for the PME. A 877 packet's match key contains source (S) and destination (D) interface 878 identities, address values and masks. 880 If measured flows were unidirectional, i.e. only counted packets 881 travelling in one direction, the matching process would be simple. The 882 PME would be called once to match the packet. Any flow key produced by 883 a successful match would be used to find the flow's record in the flow 884 table, and that flow's counters would be updated. 886 Flows are, however, bidirectional, reflecting the forward and reverse 887 packets of a protocol interchange or 'session.' Maintaining two sets of 888 counters in the meter's flow record makes the resulting flow data much 889 simpler to handle, since analysis programs do not have to gather 890 together the 'forward' and 'reverse' components of sessions. 891 Implementing bi-directional flows is, of course, more difficult for the 892 meter, since it must decide whether a packet is a 'forward' packet or a 893 'reverse' one. To make this decision the meter will often need to 894 invoke the PME twice, once for each possible packet direction. 896 The diagram below describes the algorithm used by the traffic meter to 897 process each packet. Flow through the diagram is from left to right and 898 top to bottom, i.e. from the top left corner to the bottom right 899 corner. S indicates the flow's source address (i.e. its set of source 900 address attribute values) from the packet header, and D indicates its 901 destination address. 903 There are several cases to consider. These are: 905 - The packet is recognised as one which is TO BE IGNORED. 907 - The packet would MATCH IN EITHER DIRECTION. One situation in which 908 this could happen would be a rule set which matches flows within 909 network X (Source = X, Dest = X) but specifies that flows are to be 910 created for each subnet within network X, say subnets y and z. If, 911 for example a packet is seen for y->z, the meter must check that 912 flow z->y is not already current before creating y->z. 914 - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already 915 current, its forward or reverse counters are incremented. 916 Otherwise it is added to the flow table and then counted. 918 Ignore 919 --- match(S->D) -------------------------------------------------+ 920 | Suc | NoMatch | 921 | | Ignore | 922 | match(D->S) -----------------------------------------+ 923 | | Suc | NoMatch | 924 | | | | 925 | | +-------------------------------------------+ 926 | | | 927 | | Suc | 928 | current(D->S) ---------- count(D->S,r) --------------+ 929 | | Fail | 930 | | | 931 | create(D->S) ----------- count(D->S,r) --------------+ 932 | | 933 | Suc | 934 current(S->D) ------------------ count(S->D,f) --------------+ 935 | Fail | 936 | Suc | 937 current(D->S) ------------------ count(D->S,r) --------------+ 938 | Fail | 939 | | 940 create(S->D) ------------------- count(S->D,f) --------------+ 941 | 942 * 944 The algorithm uses four functions, as follows: 946 match(A->B) implements the PME. It uses the meter's current rule set 947 to match the attribute values in the packet's match key. A->B means 948 that the assumed source address is A and destination address B, i.e. 949 that the packet was travelling from A to B. match() returns one of 950 three results: 952 'Ignore' means that the packet was matched but this flow is not 953 to be counted. 955 'NoMatch' means that the packet did not match. It might, however 956 match with its direction reversed, i.e. from B to A. 958 'Suc' means that the packet did match, i.e. it belongs to a flow 959 which is to be counted. 961 current(A->B) succeeds if the flow A-to-B is current - i.e. has 962 a record in the flow table whose state is Current - and fails 963 otherwise. 965 create(A->B) adds the flow A-to-B to the flow table, setting the 966 value for attributes - such as addresses - which remain constant, 967 and zeroing the flow's counters. 969 count(A->B,f) increments the 'forward' counters for flow A-to-B. 970 count(A->B,r) increments the 'reverse' counters for flow A-to-B. 971 'Forward' here means the counters for packets travelling from 972 A to B. Note that count(A->B,f) is identical to count(B->A,r). 974 When writing rule sets one must remember that the meter will normally 975 try to match each packet in the reverse direction if the forward match 976 does not succeed. It is particularly important that the rule set does 977 not contain inconsistencies which will upset this process. 979 Consider, for example, a rule set which counts packets from source 980 network A to destination network B, but which ignores packets from 981 source network B. This is an obvious example of an inconsistent rule 982 set, since packets from network B should be counted as reverse packets 983 for the A-to-B flow. 985 This problem could be avoided by devising a language for specifying rule 986 files and writing a compiler for it, thus making it much easier to 987 produce correct rule sets. Another approach would be to write a 'rule 988 set consistency checker' program, which could detect problems in 989 hand-written rule sets. 991 Normally, the best way to avoid these problems is to write rule sets 992 which only classify flows in the forward direction, and rely on the 993 meter to handle reverse-travelling packets. 995 Occasionally there can be situations when a rule set needs to know the 996 direction in which a packet is being matched. Consider, for example, a 997 rule set which wants to save some attribute values (source and 998 destination addresses perhaps) for any 'unusual' packets. The rule set 999 will contain a sequence of tests for all the 'usual' source addresses; 1000 follwed by a rule which will execute a 'NoMatch' action. If the match 1001 fails in the S->D direction, the NoMatch action will cause it to be 1002 retried. If it fails in the D->S direction, the packet can be counted 1003 as an 'unusual' packet. 1005 To count such an 'unusual' packet we need to know the matching 1006 direction: the MatchingStoD attribute provides this. To use it, one 1007 follows the source address tests with a rule which tests whether the 1008 matching direction is S->D (MatchingStoD value is 1). If so, a 1009 'NoMatch' action is executed. Otherwise, the packet has failed to match 1010 in both directions; we can Push whatever attribute values are of 1011 interest and count the 'unusual' packet. 1013 4.4 Rules and Rule Sets 1015 A rule set is an array of rules. Rule sets are held within a meter as 1016 entries in an array of rule sets. 1018 Rule set 1 (the first entry in the rule set table) is built-in to the 1019 meter and cannot be changed. It is run when the meter is started up, 1020 and provides a very coarse reporting granularity; it is mainly useful 1021 for verifying that the meter is running, before a 'useful' rule set is 1022 downloaded to it. 1024 A meter also maintains an array of 'tasks,' which specify what rule sets 1025 the meter is running. Each task has a 'current' rule set (the one which 1026 it normally uses), and a 'standby' rule set (which will be used when the 1027 overall traffic level is unusually high). If a task is instructed to 1028 use rule set 0, it will cease measuring; all packets will be ignored 1029 until another (non-zero) rule set is made current. 1031 Each rule in a rule set is structured as follows: 1033 +-------- test ---------+ +---- action -----+ 1035 attribute & mask = value: opcode, parameter; 1037 Opcodes contain two flags: 'goto' and 'test.' The PME maintains a 1038 Boolean indicator called the 'test indicator,' which is initially set 1039 (true). Execution begins with rule 1, the first in the rule set. It 1040 proceeds as follows: 1042 If the test indicator is true: 1043 Perform the test, i.e. AND the attribute value with the 1044 mask and compare it with the value. 1045 If these are equal the test has succeeded; perform the 1046 rule's action (below). 1047 If the test fails execute the next rule in the rule set. 1048 If there are no more rules in the rule set, return from the 1049 match() function indicating NoMatch. 1051 If the test indicator is false, or the test (above) succeeded: 1052 Set the test indicator to this opcode's test flag value. 1053 Determine the next rule to execute. 1054 If the opcode has its goto flag set, its parameter value 1055 specifies the number of the next rule. 1056 Opcodes which don't have their goto flags set either 1057 determine the next rule in special ways (Return), 1058 or they terminate execution (Ignore, NoMatch, Count, 1059 CountPkt). 1060 Perform the action. 1062 The PME maintains two 'history' data structures. The first, the 1063 'return' stack, simply records the index (i.e. 1-origin rule number) of 1064 each Gosub rule as it is executed; Return rules pop their Gosub rule 1065 index. The second, the 'pattern' queue, is used to save information for 1066 later use in building a flow key. A flow key is built by zeroing all 1067 its attribute values, then copying attribute and mask information from 1068 the pattern queue in the order it was enqueued. 1070 The opcodes are: 1072 opcode goto test 1074 1 Ignore 0 - 1075 2 NoMatch 0 - 1076 3 Count 0 - 1077 4 CountPkt 0 - 1078 5 Return 0 0 1079 6 Gosub 1 1 1080 7 GosubAct 1 0 1081 8 Assign 1 1 1082 9 AssignAct 1 0 1083 10 Goto 1 1 1084 11 GotoAct 1 0 1085 12 PushRuleTo 1 1 1086 13 PushRuleToAct 1 0 1087 14 PushPktTo 1 1 1088 15 PushPktToAct 1 0 1090 The actions they perform are: 1092 Ignore: Stop matching, return from the match() function 1093 indicating that the packet is to be ignored. 1095 NoMatch: Stop matching, return from the match() function 1096 indicating failure. 1098 Count: Stop matching. Save this rule's attribute name, 1099 mask and value in the PME's pattern queue, then 1100 construct a flow key for the flow to which this 1101 packet belongs. Return from the match() function 1102 indicating success. The meter will use the flow 1103 key to search for the flow record for this 1104 packet's flow. 1106 CountPkt: As for Count, except that the masked value from 1107 the packet is saved in the PME's pattern queue 1108 instead of the rule's value. 1110 Gosub: Call a rule-matching subroutine. Push the current 1111 rule number on the PME's return stack, set the 1112 test indicator then goto the specified rule. 1114 GosubAct: Same as Gosub, except that the test indicator is 1115 cleared before going to the specified rule. 1117 Return: Return from a rule-matching subroutine. Pop the 1118 number of the calling gosub rule from the PME's 1119 'return' stack and add this rule's parameter value 1120 to it to determine the 'target' rule. Clear the 1121 test indicator then goto the target rule. 1123 A subroutine call appears in a rule set as a Gosub 1124 rule followed by a small group of following rules. 1125 Since a Return action clears the test flag, the 1126 action of one of these 'following' rules will be 1127 executed; this allows the subroutine to return a 1128 result (in addition to any information it may save 1129 in the PME's pattern queue). 1131 Assign: Set the attribute specified in this rule to the 1132 value specified in this rule. Set the test 1133 indicator then goto the specified rule. 1135 AssignAct: Same as Assign, except that the test indicator 1136 is cleared before going to the specified rule. 1138 Goto: Set the test indicator then goto the 1139 specified rule. 1141 GotoAct: Clear the test indicator then goto the specified 1142 rule. 1144 PushRuleTo: Save this rule's attribute name, mask and value 1145 in the PME's pattern queue. Set the test 1146 indicator then goto the specified rule. 1148 PushRuleToAct: Same as PushRuleTo, except that the test indicator 1149 is cleared before going to the specified rule. 1151 PushRuleTo actions may be used to save the value 1152 and mask used in a test, or (if the test is not 1153 performed) to save an arbitrary value and mask. 1155 PushPktTo: Save this rule's attribute name, mask, and the 1156 masked value from the packet header, in the PME's 1157 pattern queue. Set the test indicator then goto 1158 the specified rule. 1160 PushPktToAct: Same as PushPktTo, except that the test indicator 1161 is cleared before going to the specified rule. 1163 PushPktTo actions may be used to save a value from 1164 the packet using a specified mask. The test in 1165 PushPktTo rules will almost never be executed. 1167 As well as the attributes applying directly to packets (such as 1168 SourcePeerAddress, DestTransAddress, etc.) the PME implements several 1169 further attribtes. These are: 1171 Null: Tests performed on the Null attribute always succeed. 1173 MatchingStoD: Indicates whether the PME is matching the packet 1174 with its addresses in 'wire order' or with its 1175 addresses reversed. MatchingStoD's value is 1 if the 1176 addresses are in wire order (StoD), and != 1 otherwise. 1178 v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They 1179 provide a way to pass parameters into rule-matching 1180 subroutines. Each may hold the number of a normal 1181 attribute; its value is set by an Assign action. 1182 When a meter variable appears as the attribute of a 1183 rule, its value specifies the actual attribute to be 1184 tested. For example, if v1 had been assigned 1185 SourcePeerAddress as its value, a rule with v1 as its 1186 attribute would actually test SourcePeerAddress. 1188 SourceClass, DestClass, FlowClass, 1189 SourceKind, DestKind, FlowKind: 1190 These six attributes may be set by executing PushRuleto 1191 actions. They allow the PME to save (in flow records) 1192 information which has been built up during matching. 1193 Their values may be tested in rules; this allows one 1194 to set them early in a rule set, and test them later. 1196 4.5 Maintaining the Flow Table 1198 The flow table may be thought of as a 1-origin array of flow records. 1199 (A particular implementation may, of course, use whatever data structure 1200 is most suitable). When the meter starts up there are no known flows; 1201 all the flow records are in the 'inactive' state. 1203 Each time a packet is matched for a flow which is not in a current flow 1204 set a flow record is created for it; the state of such a record is 1205 'current.' When selecting a record for the new flow the meter searches 1206 the flow table for an 'inactive' record. If no inactive records are 1207 available it will search for an 'idle' one instead. Note that there is 1208 no particular significance in the ordering of records within the table. 1210 Flow data may be collected by a 'meter reader' at any time. There is no 1211 requirement for collections to be synchronized. The reader may collect 1212 the data in any suitable manner, for example it could upload a copy of 1213 the whole flow table using a file transfer protocol, or it could read 1214 the records in the current flow set row by row using a suitable data 1215 transfer protocol. 1217 The meter keeps information about collections, in particular it 1218 maintains ReaderLastTime variables which remember the time the last 1219 collection was made by each reader. A second variable, InactivityTime, 1220 specifies the minimum time the meter will wait before considering that a 1221 flow is idle. 1223 The meter must recover records used for idle flows, if only to prevent 1224 it running out of flow records. Recovered flow records are returned to 1225 the 'inactive' state. A variety of recovery strategies are possible, 1226 including the following: 1228 One possible recovery strategy is to recover idle flow records as soon 1229 as possible after their data has been collected by all readers which 1230 have registered to do so. To implement this the meter could run a 1231 background process which scans the flow table looking for 'current' 1232 flows whose 'last packet' time is earlier than the meter's 1233 LastCollectTime. 1235 Another recovery strategy is to leave idle flows alone as long as 1236 possible, which would be suitable if one was only interested in 1237 measuring total traffic volumes. It could be implemented by having the 1238 meter search for collected idle flows only when it ran low on 'inactive' 1239 flow records. 1241 One further factor a meter should consider before recovering a flow is 1242 the number of meter readers which have collected the flow's data. If 1243 there are multiple meter readers operating, each reader should collect a 1244 flow's data before its memory is recovered. 1246 4.6 Handling Increasing Traffic Levels 1248 Under normal conditions the meter reader specifies which set of usage 1249 records it wants to collect, and the meter provides them. 1251 If memory usage rises above the high-water mark the meter should switch 1252 to a STANDBY RULE SET so as to decrease the rate at which new flows are 1253 created. When the manager, usually as part of a regular poll, becomes 1254 aware that the meter is using its standby rule set, it could decrease 1255 the interval between collections. The meter should also increase its 1256 efforts to recover flow memory so as to reduce the number of idle flows 1257 in memory. When the situation returns to normal, the manager may 1258 request the meter to switch back to its normal rule set. 1260 5 Meter Readers 1262 Usage data is accumulated by a meter (e.g. in a router) as memory 1263 permits. It is collected at regular reporting intervals by meter 1264 readers, as specified by a manager. The collected data is recorded in a 1265 disk file called a FLOW DATA FILE, as a sequence of USAGE RECORDS. 1267 The following sections describe the contents of usage records and flow 1268 data files. Note, however, that at this stage the details of such 1269 records and files is not specified in the architecture. Specifying a 1270 common format for them would be a worthwhile future development. 1272 5.1 Identifying Flows in Flow Records 1274 Once a packet has been classified and is ready to be counted, an 1275 appropriate flow data record must already exist in the flow table; 1276 otherwise one must be created. The flow record has a flexible format 1277 where unnecessary identification attributes may be omitted. The 1278 determination of which attributes of the flow record to use, and of what 1279 values to put in them, is specified by the current rule set. 1281 Note that the combination of start time, rule set id and subscript (row 1282 number in the flow table) provide a unique flow identifier, regardless 1283 of the values of its other attributes. 1285 The current rule set may specify additional information, e.g. a 1286 computed attribute value such as FlowKind, which is to be placed in the 1287 attribute section of the usage record. That is, if a particular flow is 1288 matched by the rule set, then the corresponding flow record should be 1289 marked not only with the qualifying identification attributes, but also 1290 with the additional information. Using this feature, several flows may 1291 each carry the same FlowKind value, so that the resulting usage records 1292 can be used in post-processing or between meter reader and meter as a 1293 criterion for collection. 1295 5.2 Usage Records, Flow Data Files 1297 The collected usage data will be stored in flow data files on the meter 1298 reader, one file for each meter. As well as containing the measured 1299 usage data, flow data files must contain information uniquely 1300 identifiying the meter from which it was collected. 1302 A USAGE RECORD contains the descriptions of and values for one or more 1303 flows. Quantities are counted in terms of number of packets and number 1304 of bytes per flow. Each usage record contains the metered traffic group 1305 identifier of the meter (a set of network addresses), a time stamp and a 1306 list of reported flows (FLOW DATA RECORDS). A meter reader will build up 1307 a file of usage records by regularly collecting flow data from a meter, 1308 using this data to build usage records and concatenating them to the 1309 tail of a file. Such a file is called a FLOW DATA FILE. 1311 A usage record contains the following information in some form: 1313 +-------------------------------------------------------------------+ 1314 | RECORD IDENTIFIERS: | 1315 | Meter Id (& digital signature if required) | 1316 | Timestamp | 1317 | Collection Rules ID | 1318 +-------------------------------------------------------------------+ 1319 | FLOW IDENTIFIERS: | COUNTERS | 1320 | Address List | Packet Count | 1321 | Subscriber ID (Optional) | Byte Count | 1322 | Attributes (Optional) | Flow Start/Stop Time | 1323 +-------------------------------------------------------------------+ 1325 5.3 Meter to Meter Reader: Usage Record Transmission 1327 The usage record contents are the raison d'etre of the system. The 1328 accuracy, reliability, and security of transmission are the primary 1329 concerns of the meter/meter reader exchange. Since errors may occur on 1330 networks, and Internet packets may be dropped, some mechanism for 1331 ensuring that the usage information is transmitted intact is needed. 1333 Flow data is moved from meter to meter reader via a series of protocol 1334 exchanges between them. This may be carried out in various ways, moving 1335 individual attribute values, complete flows, or the entire flow table 1336 (i.e. all the active and idle flows). One possible method of achieving 1337 this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' 1338 document [4] gives details. Note that this is simply one example; the 1339 transfer of flow data from meter to meter reader is not specified in 1340 this document. 1342 The reliability of the data transfer method under light, normal, and 1343 extreme network loads should be understood before selecting among 1344 collection methods. 1346 In normal operation the meter will be running a rule file which provides 1347 the required degree of flow reporting granularity, and the meter 1348 reader(s) will collect the flow data often enough to allow the meter's 1349 garbage collection mechanism to maintain a stable level of memory usage. 1351 In the worst case traffic may increase to the point where the meter is 1352 in danger of running completely out of flow memory. The meter 1353 implementor must decide how to handle this, for example by switching to 1354 a default (extremely coarse granularity) rule set, by sending a trap 1355 message to the manager, or by attempting to dump flow data to the meter 1356 reader. 1358 Users of the Traffic Flow Measurement system should analyse their 1359 requirements carefully and assess for themselves whether it is more 1360 important to attempt to collect flow data at normal granularity 1361 (increasing the collection frequency as needed to keep up with traffic 1362 volumes), or to accept flow data with a coarser granularity. Similarly, 1363 it may be acceptable to lose flow data for a short time in return for 1364 being sure that the meter keeps running properly, i.e. is not 1365 overwhelmed by rising traffic levels. 1367 6 Managers 1369 A manager configures meters and controls meter readers. It does this 1370 via the interactions described below. 1372 6.1 Between Manager and Meter: Control Functions 1374 - DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of 1375 these, the 'default' rule set, is built in to the meter and cannot 1376 be changed; the others must be downloaded by the manager. A 1377 manager may use any suitable protocol exchange to achieve this, for 1378 example an FTP file transfer or a series of SNMP SETs, one for each 1379 row of the rule set. 1381 - SPECIFY METER TASK: Once the rule sets have been downloaded, the 1382 manager must instruct the meter which rule sets will be the 1383 'current' and 'standby' ones for each task the meter is to perform. 1385 - SET HIGH WATER MARK: A percentage of the flow table capacity, used 1386 by the meter to determine when to switch to its standby rule set 1387 (so as to increase the granularity of the flows and conserve the 1388 meter's flow memory). Once this has happened, the manager may also 1389 change the polling frequency or the meter's control parameters (so 1390 as to increase the rate at which the meter can recover memory from 1391 idle flows). 1393 If the high traffic levels persist, the meter's normal rule set may 1394 have to be rewritten to permanently reduce the reporting 1395 granularity. 1397 - SET FLOW TERMINATION PARAMETERS: The meter should have the good 1398 sense in situations where lack of resources may cause data loss to 1399 purge flow records from its tables. Such records may include: 1401 - Flows that have already been reported to all registered meter 1402 readers, and show no activity since the last report, 1404 - Oldest flows, or 1406 - Flows with the smallest number of observed packets. 1408 - SET INACTIVITY TIMEOUT: This is a time in seconds since the last 1409 packet was seen for a flow. Flow records may be reclaimed if they 1410 have been idle for at least this amount of time, and have been 1411 collected in accordance with the current collection criteria. 1413 6.2 Between Manager and Meter Reader: Control Functions 1415 Because there are a number of parameters that must be set for traffic 1416 flow measurement to function properly, and viable settings may change as 1417 a result of network traffic characteristics, it is desirable to have 1418 dynamic network management as opposed to static meter configurations. 1419 Many of these operations have to do with space tradeoffs - if memory at 1420 the meter is exhausted, either the collection interval must be decreased 1421 or a coarser granularity of aggregation must be used to reduce the 1422 number of active flows. 1424 Increasing the collection interval effectively stores data in the meter; 1425 usage data in transit is limited by the effective bandwidth of the 1426 virtual link between the meter and the meter reader, and since these 1427 limited network resources are usually also used to carry user data (the 1428 purpose of the network), the level of traffic flow measurement traffic 1429 should be kept to an affordable fraction of the bandwidth. 1430 ("Affordable" is a policy decision made by the Network Operations 1431 personnel). At any rate, it must be understood that the operations 1432 below do not represent the setting of independent variables; on the 1433 contrary, each of the values set has a direct and measurable effect on 1434 the behaviour of the other variables. 1436 Network management operations follow: 1438 - MANAGER and METER READER IDENTIFICATION: The manager should ensure 1439 that meters are read by the correct set of meter readers, and take 1440 steps to prevent unauthorised access to usage information. The 1441 meter readers so identified should be prepared to poll if necessary 1442 and accept data from the appropriate meters. Alternate meter 1443 readers may be identified in case both the primary manager and the 1444 primary meter reader are unavailable. Similarly, alternate 1445 managers may be identified. 1447 - REPORTING INTERVAL CONTROL: The usual reporting interval should be 1448 selected to cope with normal traffic patterns. However, it may be 1449 possible for a meter to exhaust its memory during traffic spikes 1450 even with a correctly set reporting interval. Some mechanism 1451 should be available for the meter to tell the manager that it is in 1452 danger of exhausting its memory (by declaring a 'high water' 1453 condition), and for the manager to arbitrate (by decreasing the 1454 polling interval, letting nature take its course, or by telling the 1455 meter to ask for help sooner next time). 1457 - GRANULARITY CONTROL: Granularity control is a catch-all for all the 1458 parameters that can be tuned and traded to optimise the system's 1459 ability to reliably measure and store information on all the 1460 traffic (or as close to all the traffic as an administration 1461 requires). Granularity 1463 - Controls the amount of address information identifying each 1464 flow, and 1466 - Determines the number of buckets into which user traffic will 1467 be lumped together. 1469 Since granularity is controlled by the meter's current rule set, 1470 the manager can only change it by requesting the meter to switch to 1471 a different rule set. The new rule set could be downloaded when 1472 required, or it could have been downloaded as part of the meter's 1473 initial configuration. 1475 - FLOW LIFETIME CONTROL: Flow termination parameters include timeout 1476 parameters for obsoleting inactive flows and removing them from 1477 tables, and maximum flow lifetimes. This is intertwined with 1478 reporting interval and granularity, and must be set in accordance 1479 with the other parameters. 1481 6.3 Exception Conditions 1483 Exception conditions must be handled, particularly occasions when the 1484 meter runs out of space for flow data. Since - to prevent an active 1485 task from counting any packet twice - packets can only be counted in a 1486 single flow, discarding records will result in the loss of information. 1487 The mechanisms to deal with this are as follows: 1489 - METER OUTAGES: In case of impending meter outages (controlled 1490 restarts, etc.) the meter could send a trap to the manager. The 1491 manager could then request one or more meter readers to pick up the 1492 data from the meter. 1494 Following an uncontrolled meter outage such as a power failure, the 1495 meter could send a trap to the manager indicating that it has 1496 restarted. The manager could then download the meter's correct 1497 rule set and advise the meter reader(s) that the meter is running 1498 again. Alternatively, the meter reader may discover from its 1499 regular poll that a meter has failed and restarted. It could then 1500 advise the manager of this, instead of relying on a trap from the 1501 meter. 1503 - METER READER OUTAGES: If the collection system is down or isolated, 1504 the meter should try to inform the manager of its failure to 1505 communicate with the collection system. Usage data is maintained 1506 in the flows' rolling counters, and can be recovered when the meter 1507 reader is restarted. 1509 - MANAGER OUTAGES: If the manager fails for any reason, the meter 1510 should continue measuring and the meter reader(s) should keep 1511 gathering usage records. 1513 - BUFFER PROBLEMS: The network manager may realise that there is a 1514 'low memory' condition in the meter. This can usually be 1515 attributed to the interaction between the following controls: 1517 - The reporting interval is too infrequent, or 1519 - The reporting granularity is too fine. 1521 Either of these may be exacerbated by low throughput or bandwidth 1522 of circuits carrying the usage data. The manager may change any of 1523 these parameters in response to the meter (or meter reader's) plea 1524 for help. 1526 6.4 Standard Rule Sets 1528 Although the rule table is a flexible tool, it can also become very 1529 complex. It may be helpful to develop some rule sets for common 1530 applications: 1532 - PROTOCOL TYPE: The meter records packets by protocol type. This 1533 will be the default rule table for Traffic Flow Meters. 1535 - ADJACENT SYSTEMS: The meter records packets by the MAC address of 1536 the Adjacent Systems (neighbouring originator or next-hop). 1537 (Variants on this table are "report source" or "report sink" only.) 1538 This strategy might be used by a regional or backbone network which 1539 wants to know how much aggregate traffic flows to or from its 1540 subscriber networks. 1542 - END SYSTEMS: The meter records packets by the IP address pair 1543 contained in the packet. (Variants on this table are "report 1544 source" or "report sink" only.) This strategy might be used by an 1545 End System network to get detailed host traffic matrix usage data. 1547 - TRANSPORT TYPE: The meter records packets by transport address; for 1548 IP packets this provides usage information for the various IP 1549 services. 1551 - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface 1552 report End Systems, for another interface report Adjacent Systems. 1553 This strategy might be used by an enterprise network to learn 1554 detail about local usage and use an aggregate count for the shared 1555 regional network. 1557 7 Security Considerations 1559 7.1 Threat Analysis 1561 A traffic flow measurement system may be subject to the following kinds 1562 of attacks: 1564 - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain 1565 advantage or cause mischief (e.g. denial of service) by subverting 1566 any of the system elements - meters, meter readers or managers. 1568 - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to 1569 disclosure can be read through active or passive attacks unless it 1570 is suitably protected. Usage data may or may not be of this type. 1571 Control messages, traps, etc. are not likely to be considered 1572 sensitive to disclosure. 1574 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: 1575 Similarly, any data whose integrity is sensitive can be altered, 1576 replaced/injected or deleted through active or passive attacks 1577 unless it is suitably protected. Attackers may modify message 1578 streams to falsify usage data or interfere with the proper 1579 operation of the traffic flow measurement system. Therefore, all 1580 messages, both those containing usage data and those containing 1581 control data, should be considered vulnerable to such attacks. 1583 7.2 Countermeasures 1585 The following countermeasures are recommended to address the possible 1586 threats enumerated above: 1588 - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use 1589 of authentication and access control services. 1591 - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a 1592 confidentiality (encryption) service. 1594 - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is 1595 countered through the use of an integrity service. 1597 A Traffic Measurement system must address all of these concerns. Since 1598 a high degree of protection is required, the use of strong cryptographic 1599 methodologies is recommended. The security requirements for 1600 communication between pairs of traffic measurmement system elements are 1601 summarized in the table below. It is assumed that meters do not 1602 communicate with other meters, and that meter readers do not communicate 1603 directly with other meter readers (if synchronization is required, it is 1604 handled by the manager, see Section 2.5). Each entry in the table 1605 indicates which kinds of security services are required. Basically, the 1606 requirements are as follows: 1608 Security Service Requirements for RTFM elements 1610 +------------------------------------------------------------------+ 1611 | from\to | meter | meter reader | application | manager | 1612 |---------+--------------+--------------+-------------+------------| 1613 | meter | N/A | authent | N/A | authent | 1614 | | | acc ctrl | | acc ctrl | 1615 | | | integrity | | | 1616 | | | confid ** | | | 1617 |---------+--------------+--------------+-------------+------------| 1618 | meter | authent | N/A | authent | authent | 1619 | reader | acc ctrl | | acc ctrl | acc ctrl | 1620 | | | | integrity | | 1621 | | | | confid ** | | 1622 |---------+--------------+--------------+-------------+------------| 1623 | appl | N/A | authent | | | 1624 | | | acc ctrl | ## | ## | 1625 |---------+--------------+--------------+-------------+------------| 1626 | manager | authent | authent | ## | authent | 1627 | | acc ctrl | acc ctrl | | acc ctrl | 1628 | | integrity | integrity | | integrity | 1629 +------------------------------------------------------------------+ 1631 N/A = Not Applicable ** = optional ## = outside RTFM scope 1633 - When any two elements intercommunicate they should mutually 1634 authenticate themselves to one another. This is indicated by 1635 'authent' in the table. Once authentication is complete, an 1636 element should check that the requested type of access is allowed; 1637 this is indicated on the table by 'acc ctrl.' 1639 - Whenever there is a transfer of information its integrity should be 1640 protected. 1642 - Whenever there is a transfer of usage data it should be possible to 1643 ensure its confidentiality if it is deemed sensitive to disclosure. 1644 This is indicated by 'confid' in the table. 1646 Security protocols are not specified in this document. The system 1647 elements' management and collection protocols are responsible for 1648 providing sufficient data integrity, confidentiality, authentication and 1649 access control services. 1651 8 APPENDICES 1653 8.1 Appendix A: Network Characterisation 1655 Internet users have extraordinarily diverse requirements. Networks 1656 differ in size, speed, throughput, and processing power, among other 1657 factors. There is a range of traffic flow measurement capabilities and 1658 requirements. For traffic flow measurement purposes, the Internet may 1659 be viewed as a continuum which changes in character as traffic passes 1660 through the following representative levels: 1662 International | 1663 Backbones/National --------------- 1664 / \ 1665 Regional/MidLevel ---------- ---------- 1666 / \ \ / / \ 1667 Stub/Enterprise --- --- --- ---- ---- 1668 ||| ||| ||| |||| |||| 1669 End-Systems/Hosts xxx xxx xxx xxxx xxxx 1671 Note that mesh architectures can also be built out of these components, 1672 and that these are merely descriptive terms. The nature of a single 1673 network may encompass any or all of the descriptions below, although 1674 some networks can be clearly identified as a single type. 1676 BACKBONE networks are typically bulk carriers that connect other 1677 networks. Individual hosts (with the exception of network management 1678 devices and backbone service hosts) typically are not directly connected 1679 to backbones. 1681 REGIONAL networks are closely related to backbones, and differ only in 1682 size, the number of networks connected via each port, and geographical 1683 coverage. Regionals may have directly connected hosts, acting as hybrid 1684 backbone/stub networks. A regional network is a SUBSCRIBER to the 1685 backbone. 1687 STUB/ENTERPRISE networks connect hosts and local area networks. 1688 STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 1689 networks. 1691 END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above 1692 networks. 1694 Providing a uniform identification of the SUBSCRIBER in finer 1695 granularity than that of end-system, (e.g. user/account), is beyond the 1696 scope of the current architecture, although an optional attribute in the 1697 traffic flow measurement record may carry system-specific 'user 1698 identification' labels so that meters can implement proprietary or 1699 non-standard schemes for the attribution of network traffic to 1700 responsible parties. 1702 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 1704 Initial recommended traffic flow measurement conventions are outlined 1705 here according to the following Internet building blocks. It is 1706 important to understand what complexity reporting introduces at each 1707 network level. Whereas the hierarchy is described top-down in the 1708 previous section, reporting requirements are more easily addressed 1709 bottom-up. 1711 End-Systems 1712 Stub Networks 1713 Enterprise Networks 1714 Regional Networks 1715 Backbone Networks 1717 END-SYSTEMS are currently responsible for allocating network usage to 1718 end-users, if this capability is desired. From the Internet Protocol 1719 perspective, end-systems are the finest granularity that can be 1720 identified without protocol modifications. Even if a meter violated 1721 protocol boundaries and tracked higher-level protocols, not all packets 1722 could be correctly allocated by user, and the definition of user itself 1723 varies widely from operating system to operating system (e.g. how to 1724 trace network usage back to users from shared processes). 1726 STUB and ENTERPRISE networks will usually collect traffic data either by 1727 end-system network address or network address pair if detailed reporting 1728 is required in the local area network. If no local reporting is 1729 required, they may record usage information in the exit router to track 1730 external traffic only. (These are the only networks which routinely use 1731 attributes to perform reporting at granularities finer than end-system 1732 or intermediate-system network address.) 1734 REGIONAL networks are intermediate networks. In some cases, subscribers 1735 will be enterprise networks, in which case the intermediate system 1736 network address is sufficient to identify the regional's immediate 1737 subscriber. In other cases, individual hosts or a disjoint group of 1738 hosts may constitute a subscriber. Then end-system network address 1739 pairs need to be tracked for those subscribers. When the source may be 1740 an aggregate entity (such as a network, or adjacent router representing 1741 traffic from a world of hosts beyond) and the destination is a singular 1742 entity (or vice versa), the meter is said to be operating as a HYBRID 1743 system. 1745 At the regional level, if the overhead is tolerable it may be 1746 advantageous to report usage both by intermediate system network address 1747 (e.g. adjacent router address) and by end-system network address or 1748 end-system network address pair. 1750 BACKBONE networks are the highest level networks operating at higher 1751 link speeds and traffic levels. The high volume of traffic will in most 1752 cases preclude detailed traffic flow measurement. Backbone networks 1753 will usually account for traffic by adjacent routers' network addresses. 1755 8.3 Appendix C: List of Defined Flow Attributes 1757 This Appendix provides a checklist of the attributes defined to date; 1758 others will be added later as the Traffic Measurement Architecture is 1759 further developed. 1761 0 Null 1762 1 Flow Subscript Integer Flow table info 1764 4 Source Interface Integer Source Address 1765 5 Source Adjacent Type Integer 1766 6 Source Adjacent Address String 1767 7 Source Adjacent Mask String 1768 8 Source Peer Type Integer 1769 9 Source Peer Address String 1770 10 Source Peer Mask String 1771 11 Source Trans Type Integer 1772 12 Source Trans Address String 1773 13 Source Trans Mask String 1775 14 Destination Interface Integer Destination Address 1776 15 Destination Adjacent Type Integer 1777 16 Destination Adjacent Address String 1778 17 Destination AdjacentMask String 1779 18 Destination PeerType Integer 1780 19 Destination PeerAddress String 1781 20 Destination PeerMask String 1782 21 Destination TransType Integer 1783 22 Destination TransAddress String 1784 23 Destination TransMask String 1786 26 Rule Set Number Integer Meter attribute 1788 27 Forward Bytes Integer Source-to-Dest counters 1789 28 Forward Packets Integer 1790 29 Reverse Bytes Integer Dest-to-Source counters 1791 30 Reverse Packets Integer 1792 31 First Time Timestamp Activity times 1793 32 Last Active Time Timestamp 1794 33 Source Subscriber ID String Session attributes 1795 34 Destination Subscriber ID String 1796 35 Session ID String 1798 36 Source Class Integer 'Computed' attributes 1799 37 Destination Class Integer 1800 38 Flow Class Integer 1801 39 Source Kind Integer 1802 40 Destination Kind Integer 1803 41 Flow Kind Integer 1805 50 MatchingStoD Integer PME variable 1807 65 1808 .. 'Extended' attributes (to be defined by the RTFM working group) 1809 127 1811 8.4 Appendix D: List of Meter Control Variables 1813 Meter variables: 1814 Flood Mark Percentage 1815 Inactivity Timeout (seconds) Integer 1817 'per task' variables: 1818 Current Rule Set Number Integer 1819 Standby Rule Set Number Integer 1820 High Water Mark Percentage 1822 'per reader' variables: 1823 Reader Last Time Timestamp 1825 9 Acknowledgments 1827 An initial draft of this document was produced under the auspices of the 1828 IETF's Internet Accounting Working Group with assistance from SNMP, RMON 1829 and SAAG working groups. This version documents the implementation work 1830 done by the Internet Accounting Working Group, and is intended to 1831 provide a starting point for the Realtime Traffic Flow Measurement 1832 Working Group. Particular thanks are due to Stephen Stibler (IBM 1833 Research) for his patient and careful comments during the preparation of 1834 this draft. 1836 10 References 1838 [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 1839 Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian 1840 Technology Corporation, November 1991. 1842 [2] International Standards Organisation (ISO), "Management 1843 Framework," Part 4 of Information Processing Systems Open 1844 Systems Interconnection Basic Reference Model, ISO 7498-4, 1845 1994. 1847 [3] IEEE 802.3/ISO 8802-3 Information Processing Systems - 1848 Local Area Networks - Part 3: Carrier sense multiple access 1849 with collision detection (CSMA/CD) access method and physical 1850 layer specifications, 2nd edition, September 21, 1990. 1852 [4] Brownlee, N., "Traffic Flow Measurement: Meter MIB," 1853 Internet Draft, 'Working draft' to become an experimental RFC. 1855 11 Author's Addresses 1857 Nevil Brownlee 1858 Information Technology Systems & Services 1859 The University of Auckland 1861 Phone: +64 9 373 7599 x8941 1862 E-mail: n.brownlee@auckland.ac.nz 1864 Cyndi Mills 1865 GTE Laboratories, Inc 1867 Phone: +1 617 466 4278 1868 E-mail: cmills@gte.com 1870 Greg Ruth 1871 GTE Laboratories, Inc 1873 Phone: +1 617 466 2448 1874 E-mail: gruth@gte.com 1876 Expires Jun 1998