idnits 2.17.1 draft-ietf-acct-archreport-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 14 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == 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 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 867: '... GroupMask [3] OCTET STRING (SIZE (1)) OPTIONAL, Masks Not Required...' RFC 2119 keyword, line 878: '... GroupMask [0] OCTET STRING (SIZE (1)) OPTIONAL,...' RFC 2119 keyword, line 883: '... Source-From [0] Address-list OPTIONAL, -- Must have source or dest...' RFC 2119 keyword, line 884: '... Destination-To [1] Address-list OPTIONAL, -- or both...' RFC 2119 keyword, line 885: '... SubscriberID [2] Address-list OPTIONAL....' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 357 has weird spacing: '...egating subsc...' == Line 1346 has weird spacing: '...s/Hosts xxx ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 9, 1992) is 11614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Attributes' on line 385 looks like a reference -- Missing reference section? '0' on line 1237 looks like a reference -- Missing reference section? '1' on line 1238 looks like a reference -- Missing reference section? '2' on line 902 looks like a reference -- Missing reference section? '3' on line 903 looks like a reference -- Missing reference section? '4' on line 904 looks like a reference -- Missing reference section? '5' on line 872 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Accounting Working Group July 9, 1992 4 INTERNET ACCOUNTING: USAGE REPORTING ARCHITECTURE 6 Status of this Memo 8 This document is an Internet Draft. Internet Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its Areas, 10 and its Working Groups. Note that other groups may also distribute 11 working documents as Internet Drafts. This Internet Draft is a 12 product of the Internet Accounting Working Group of the IETF. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the I-D abstract listing contained in each Internet Draft 21 directory to learn the current status of this or any other Internet 22 Draft. 24 1. Statement of Purpose and Scope 26 This INTERNET DRAFT describes an architecture for Internet usage 27 reporting so that: 29 o network usage information is presented to collection and 30 processing applications (e.g. billing) in a standarized 31 format. 33 o the usage reporting protocol structure can be consistently 34 applied to any protocol/application at any network layer (e.g. 35 network, transport, application layers). 37 o usage reporting units are defined in such a way that the units 38 are valid for multiple networking protocol stacks and that 39 usage reporting protocol implementations are useful in multi- 40 protocol environments. 42 o a near-term framework for usage reporting is established to 43 encourage experimentation with internet accounting; results 44 and effectiveness can be compared across multiple 45 implementations now. Long-term and more complete protocols 46 are currently limited to research efforts; stable standards 47 are not expected to emerge for several years. 49 The usage reporting architecture specifies common metrics for 50 measuring usage in an Internet environment. By using the same 51 metrics, usage data can be exchanged and compared across multiple 52 platforms. Usage data can be used for: 54 Internet Accounting Working Group July 9, 1992 56 o attribution of network usage to subscribers, 58 o quantification of network performance, 60 o usage-based policy enforcement, and 62 o usage-based cost recovery (billing) 64 This document addresses the first of these, attribution of network 65 usage to subscribers. The architecture outlined here targets 66 connectionless IP-level services as its primary responsibility. 68 The usage reporting architecture is deliberately structured so that 69 specific protocol implementations may extend coverage to multi- 70 protocol environments and to other protocol layers, such as usage 71 reporting for application-level services. Use of the same model for 72 both network- and application-level billing may simplify the 73 development of generic billing/statistics applications which process 74 and/or correlate any or all levels of usage information. 76 The usage reporting architecture is NOT A PROTOCOL SPECIFICATION. It 77 specifies and structures the information that a usage reporting 78 protocol needs to collect, describes requirements that such a protocol 79 must meet, and outlines tradeoffs. 81 For performance reasons, it may be desirable to use traffic 82 information gathered through usage reporting in lieu of similar 83 network statistics. Although the quantification of network 84 performance is not the purpose of this architecture, the usage data 85 may serve a dual purpose. This architecture favors accounting 86 requirements over statistical convenience. 88 Policy-based routing and access control policies require mechanisms to 89 enforce answers to the question: "who may use the network for what 90 purpose". In the future, tighter coordination between usage reporting 91 and access control should enable the use of real-time controls such as 92 quotas. This architecture does not cover enforcement at this time. 94 The cost recovery structure decides "who pays for what". The major 95 issue here is how to construct a tariff (who gets billed, how much, 96 for which things, based on what info, etc). Tariff issues include 97 fairness, predictability (how well can subscribers forecast their 98 network charges), practicality (of gathering the data and 99 administering the tariff), incentives (e.g. encouraging off-peak use), 100 and cost recovery goals (100% recovery, subsidization, profit making). 101 These issues are not covered here, although usage data reporting is 102 one possible component of a comprehensive billing system. 104 Background information explaining why this approach was selected is 105 provided by: 107 Internet Accounting Working Group July 9, 1992 109 Internet Accounting: Background (RFC 1272) 111 Individual collection protocol documents will address precise formats, 112 e.g. MIB (management information base) specifications for SNMP or 113 other management protocols. 115 2. Internet Accounting Framework 117 The accounting framework and terminology used by OSI Accounting 118 Management is applicable here. The OSI reference model (ISO 7498-4 119 OSI Reference Model Part 4: Management Framework) defines the scope 120 of OSI accounting as follows: 122 "Accounting management is the set of facilities which enables charges 123 to be established for the use of managed objects and costs to be 124 identified for the use of those managed objects. Accounting 125 management is the set of facilities to 127 (a) inform users of costs incurred or resources consumed, 129 (b) enable accounting limits to be set for the use of managed 130 objects, and 132 (c) enable costs to be combined where multiple managed objects are 133 invoked to achieve a given communication objective." 135 Usage reporting mechanisms satisfy the measurement of "resources 136 consumed" in (a). Pricing, i.e. establishing the cost of using these 137 resources, is left to billing applications which are not covered here. 138 Quotas are the mechanism for enforcing (b). Combining costs (c) is 139 achieved through the post-processing of usage data by accounting 140 applications not covered here. 142 The near-term architecture describes usage reporting only. Other 143 aspects of an overall architecture are left for future extension or 144 replacement by a long-term Internet accounting architecture. The 145 following sections outline a model of internet accounting, 146 specifically the usage reporting function, which is further refined 147 throughout this document. 149 Internet Accounting Working Group July 9, 1992 151 2.1 Internet Accounting Model 153 The Internet accounting model draws from working drafts of the OSI 154 accounting model. It separates accounting functions into the parts 155 shown below. 157 NETWORK MANAGER ------------------ 158 / \ \ 159 / \ \ 160 / \ \ 161 / \ \ 162 METER <-----> COLLECTOR <-----> APPLICATION 164 o NETWORK MANAGER (or simply, MANAGER): The network manager is 165 responsible for the control of the meter and collector, and 166 determines and identifies backup collectors and managers as 167 required. 169 o METER: The meter performs the measurement and aggregate the 170 results. Some characteristics of the meter are 171 implementation-specific. 173 o COLLECTOR: The collector is responsible for the integrity and 174 security of data during transport from the meter to the 175 application. This responsibility includes accurate and 176 preferably unforgeable recording of accountable (billable) 177 party identity. 179 o APPLICATION: The application manipulates the usage data in 180 accordance with policy, and determines the need for 181 information from the metering devices. 183 QUOTAS are a means for information to be transferred from the usage 184 reporting system to network management's access control function for 185 the purpose of enforcement, i.e. limits placed on usage. A complete 186 implementation of quotas may involve real-time distributed 187 interactions between meters, the quota system, and access control. 188 Enforcement of quotas is beyond the scope of the near-term 189 architecture. 191 Standard information required for performing the collection of usage 192 information of meters can be viewed as the product of protocol 193 exchanges between the following parties: 195 o the METER itself, where traffic is measured and usage data 196 "generated". 198 o the MANAGER, who manages the topology of the networks and 199 relationships between entities in the network. 201 Internet Accounting Working Group July 9, 1992 203 o the COLLECTOR, or recipient of the usage data. 205 The exchanges can be categorized as follows: 207 o between METER and COLLECTOR 209 The data which travels this path is the usage record itself. 210 The purpose of all the other exchanges is to manage the proper 211 execution of this exchange. Usage record format is described 212 in this section. Usage records which travel from meter to 213 collector consist of meter id, address list, subscriber id, 214 attribute list (not yet defined, since it is only applicable 215 to local-area reporting), and values (packet counts, byte 216 counts, and timestamps). In general, the collector generates 217 no traffic to the meter, with the exception of polls where a 218 polling protocol is used. The collector may know about other 219 characteristics of the interfaces which are being metered 220 through other means. Most notably, if an interface is 221 accounting on a statistical the collector should at least know 222 the average sampling rate and preferably be able to set the 223 sampling rate to control the accounting process. (Sampling 224 algorithms are not prescribed by the architecture, however it 225 should be noted that any sampling techniques must be 226 accompanied by documentation documenting adequate security and 227 statistical validity which should be approved by the Internet 228 Engineering Task Force before adoption.) 230 o between MANAGER and METER 232 The manager is responsible for controlling the meter. Meter 233 management consists of commands which start/stop usage 234 reporting, manage the exchange between meter and collector(s) 235 (to whom do meters report the data they collect), set 236 reporting intervals and timers, and set reporting 237 granularities. 239 Although most of the control information consists of commands 240 to the meter, the meter may need to inform the manager of 241 unanticipated conditions and meter responses to time-critical 242 situations, such as buffer overflows. 244 o between NETWORK MANAGER and COLLECTOR 246 These parallel the manager to meter exchange, permitting 247 feedback on collection performance and controlling access to 248 the collected traffic statistics. Frequently the manager and 249 the collector will be the same entity. 251 o between COLLECTORs (COLLECTOR - COLLECTOR) 253 Internet Accounting Working Group July 9, 1992 255 A CASCADE of collectors is formed when one collector 256 aggregates information from other intermediate collectors. 258 COLLECTOR A 259 / \ 260 / \ 261 COLLECTOR B COLLECTOR C 262 / | \ / | \ 263 / | \ / | \ 264 COLLECTOR D COLLECTOR E COLLECTOR F METER C1 METER C2 METER C3 265 | | | 266 METER D1 METER E1 METER F1 268 Collectors exchange data with other collectors only when 269 cascading is in effect (hierarchical reporting) or collection 270 systems are voluntarily exchanging data for cross-verification 271 or merging incomplete data sets (both examples of peer 272 reporting). One method of cascading reporting is for the 273 collector closer to the actual meter to behave as a meter with 274 regard to the aggregating (closer to the root) collector, 275 using the METER to COLLECTOR exchange to relay data towards 276 the root. The preferred method is file transfer. A generic 277 usage reporting file format for data exchange between 278 collection systems has yet to be specified, e.g. a version or 279 offshoot of AMA based on the modifications made for SMDS 280 accounting. 282 Since redundant reporting may be used in order to increase the 283 reliability of usage data, exchanges among multiple entities must be 284 considered as well. 286 o multiple METERs to a COLLECTOR 288 Several uniquely identified meters report to one or more 289 collectors. Meters are identified by the collection protocol 290 or by a header within each usage message from the meter to the 291 collector. A collector must be able to accept data in varying 292 granularities. Collectors may receive reports on the progress 293 of packets at various metering points along the path which the 294 packet travels. When the collected data is processed or 295 analyzed, parallel information from the network management 296 system may be required in order to determine which meter 297 recorded the entry or exit point of the packet from the 298 network. 300 o one METER to multiple COLLECTORs 302 Meters may also report the same information to multiple 303 collectors for the purposes of redundancy. In that case, the 305 Internet Accounting Working Group July 9, 1992 307 collectors should agree on a single set of collection rules. 309 o between MANAGERs (MANAGER - MANAGER) 311 Synchronization between multiple management systems is the 312 province of network management protocols. This usage 313 reporting architecture specifies only the network management 314 controls necessary to perform the usage reporting function and 315 does not address the more global issues of simultaneous or 316 interleaved conflicting commands from multiple network 317 management stations or the process of transferring control 318 from one network management station to another. 320 3. Usage Reporting Components 322 The usage reporting architecture specifies a means for collecting 323 information about network usage in connectionless Internet 324 environments. Usage is reported on connectionless protocol packets 325 sent at the internet layer. For example, in the OSI protocol suite, 326 the datagrams being counted are OSI CLNP datagrams. In the DoD 327 Protocol Suite, the datagrams are IP datagrams. More precisely, the 328 packets being counted are datagram fragments - the individual units in 329 which the connectionless network protocol carries data, known as 330 Protocol Data Units or PDUs. Routing protocol traffic may also be 331 counted. Connection-oriented 332 protocols can be reported in the same format. 334 The following sections address: 336 o meters 338 o flows and reporting granularity 340 o usage records 342 3.1 Meters 344 Meters count the quantities specified by VALUES and attribute them to 345 ACCOUNTABLE ENTITIES. The accountable entity is the network 346 subscriber. 348 The approach to usage reporting at the IP level outlined here assumes 349 that routers or equivalent traffic monitors throughout the Internet 350 are instrumented with meters to measure traffic. Issues surrounding 351 the choice of meter placement are discussed in the Internet Accounting 352 Background RFC. 354 The purpose of defining meters at the internet level is to devise a 355 Internet Accounting Working Group July 9, 1992 357 way of succinctly aggregating subscriber usage information. Since IP 358 service is connectionless, there is by definition no way to tell 359 whether a datagram with a particular source/destination combination is 360 part of a stream of packets or not. 362 Each packet is completely independent. In order to provide fully 363 detailed reporting about the actions of subscribers on the network, a 364 separate usage record would have to be maintained for each packet 365 detailing the usage information. This would result in a very high 366 level of overhead, possibly as high as one packet of usage information 367 for each packet of data. 369 Therefore, usage aggregation provides an economical and practical way 370 to measure internetwork traffic and ascribe it to a network 371 subscriber. 373 3.2 Flows and Reporting Granularity 375 For the purpose of usage reporting we define the concept of a FLOW, 376 which is an artificial logical equivalent to a call or connection. A 377 flow is a portion of traffic, delimited by a start and stop time, that 378 is attributable to a particular accountable entity. Values (packet 379 counts, byte counts, etc.) associated with a flow are aggregate 380 quantities reflecting events which take place in the DURATION between 381 the start and stop times. The start time of a flow is fixed for a 382 given flow; the end time may increase with the age of the flow. 384 +---------------------------------------------------------------------+ 385 | Sample Entity [Attributes] Values | 386 +---------------------------------------------------------------------+ 387 | 10.1.0.1 IP/UDP Packets, Bytes, Start/Stop Time | 388 +---------------------------------------------------------------------+ 390 GRANULARITY is the "control knob" by which an application and/or the 391 meter can trade off the overhead associated with performing usage 392 reporting for the level of detail supplied. A coarser granularity 393 means a greater level of aggregation; finer granularity means a 394 greater level of detail. Thus, the size and number of flows measured 395 at a meter can be regulated by changing the granularity of the 396 accountable entity, the attributes, or time intervals. Flows are like 397 an adjustable pipe - many fine granularity streams can carry the data 398 with each stream accounted for individually, or data can be bundled in 399 one coarse granularity pipe. 401 Flow granularity is controlled by adjusting the level of detail at 402 which the following are reported: 404 o the accountable entity 406 Internet Accounting Working Group July 9, 1992 408 o the categorization of packets (attributes) 410 o the lifetime/duration of a flow (the reporting interval). 412 Settings for these granularity factors may vary from meter to meter. 413 Also, they may be static (established by definition or agreement) or 414 dynamic (set by a control protocol). 416 The granularity of ACCOUNTABLE ENTITIES is primarily specified by the 417 ADDRESS LIST associated with a flow. That is, a flow's address list 418 determines a subset of the traffic visible to the meter by specifying 419 restrictions on the set of subscribers associated with that traffic. 420 Beyond the local-area (i.e. for Internet traffic which crosses 421 administrative boundaries) the following three types of address 422 specifiers will be used to identify flows: 424 o source address of the packets 426 o destination address of the packets 428 o source/destination address pair of the packets 430 For example, if a flow's address list is specified as "source address 431 = IP address 10.1.0.1", then all IP packets from that address are 432 counted in that flow. If a flow's address list is specified as 433 "source address = IP address 10.1.0.1, destination address = IP 434 address 26.1.0.1" then only IP packets from 10.1.0.1 to 26.1.0.1 are 435 counted in that flow. When source/destination address pairs are used 436 to designate flows, the set of flow data is referred to as a TRAFFIC 437 MATRIX. 439 The addresses appearing in a flow's address list may include one or 440 more of the following three types: 442 o the INTERFACE NUMBER of the meter, i.e. the port on which the 443 meter measured the traffic. Together with a unique address 444 for the meter this uniquely identifies a particular physical 445 level port or port matrix. 447 o the ADJACENT (intermediate-system) NETWORK ADDRESS, which 448 identifies the adjacent internet hop on the path of the 449 packet. Since the network layer address within the network- 450 layer protocol packet refers to end-systems only, the adjacent 451 system (upstream or downstream neighbor) address must be 452 derived from the sub-network address or translated into the 453 appropriate network layer address (or unique name) for that 454 neighbor. 456 o the END-SYSTEM NETWORK ADDRESS, which identifies the source or 457 destination of the NETWORK-LEVEL packet. 459 Internet Accounting Working Group July 9, 1992 461 Reporting by adjacent intermediate sources and destinations or simply 462 by meter interface (most useful when the meter is embedded in a 463 router) supports hierarchical internet reporting schemes as described 464 in the background RFC. That is, it allows backbone and regional 465 networks to measure usage to just the next lower level of granularity 466 (i.e. to the regional and stub/enterprise levels, respectively), with 467 the final breakdown according to end user performed by the 468 stub/enterprise networks. 470 In cases where network addresses are dynamically allocated (e.g. 471 mobile subscribers), further subscriber identification will be 472 necessary for accurate accounting. Therefore, provision is made to 473 further specify the accountable entity through the use of an optional 474 SUBSCRIBER ID as part of the flow id. A subscriber ID may be 475 associated with a particular flow either through a static rule table 476 or through proprietary means within the meter. 478 Granularity of accountable entities is further specified by additional 479 ATTRIBUTES. These attributes include characteristics such as traffic 480 priority or other type of service characteristics. 482 User-level reporting is not addressed at this time, since it requires 483 the addition of an IP option to identify the user, although the 484 addition of a user-id as an entity at a later date is not precluded by 485 this architecture. 487 This model can be continued at levels above the network level, such as 488 transport and application for TCP/IP networks or 489 transport/session/presentation /application for OSI networks. 490 However, since the charter of the Internet Accounting Working Group 491 ends at the internet-address (network layer), extensions to the usage 492 record for application reporting will be left for future work. 494 For local-area reporting (within an administration), flows between 495 subscriber entities can be subdivided into finer granularity by 496 specifying ATTRIBUTES associated with the measured traffic. A sample 497 IP attribute is: 499 o QUALITY OF SERVICE: An internet header contains type of 500 service bits, which indicate that the router should give the 501 packet precedence for throughput, reliability, or delay. 503 Local-area reporting may later specify additional protocol layers in 504 the address list, such as: 506 o TRANSPORT PROTOCOL TYPE: this usually means TCP or UDP. 508 o APPLICATION PROTOCOL TYPE: Many users want to peek up one 509 more layer for TCP connections (probably a violation of 510 protocol layering for an IP-level router, though not for a 512 Internet Accounting Working Group July 9, 1992 514 host-based meter) to know whether the data is FTP (File 515 Transfer), SMTP (E-Mail), Telnet (Virtual Terminal) and for 516 UDP, if it is Domain Name Service (DNS). 518 For example, for a flow with a flow id including only TCP in its 519 attributes, only TCP datagrams would be counted. This level of 520 granularity is considered too detailed to perform well at the backbone 521 level. 523 The set of rules controlling the reporting granularity are known as 524 the COLLECTION RULES. As will be shown, the collection rules form an 525 integral part of the reported information - i.e. the recorded usage 526 information cannot be properly interpreted without a definition of the 527 rules used to collect that information. It is expected that the 528 collection rules will change rather infrequently; nonetheless, the 529 rules in effect at any time must be identifiable via a RULE ID. 531 The usage data contained in the meter is further distinguished by the 532 GROUP MASK. There are 8 arbitrary groups which may be allocated for 533 administrative and policy purposes. For example, one group of usage 534 records (specifiable under the rule set) may have priority over 535 another group. A mask may identify groups which the meter may discard 536 in case of buffer overflow. Different groups may even be collected 537 from different collection stations, depending on the flexibility of 538 the collection protocol. 540 Each group is represented by a bit in a an 8-bit mask. A particular 541 usage record may be a member of multiple groups if multiple bits are 542 set. The masks and polling algorithms should be set up in such a way 543 as to avoid unintentional multiple reporting of individual records. 545 Since on-going counts in a particular bucket may be reported 546 repeatedly during the lifetime of a flow in a fashion analogous to 547 call-progress messages in X.96, the collection system may discard 548 earlier progress messages as more complete messages are received. 550 3.3 Usage Records 552 A USAGE RECORD contains the descriptions of and values for one or more 553 flows. Quantities are counted in terms of number of packets and 554 number of bytes per flow. Each usage record contains the entity 555 identifier of the meter (a network address) and a list of reported 556 flows. The number of flows which can be reported in a single usage 557 record may be limited by the maximum packet size of the collection 558 protocol. If the collection protocol's maximum packet size is smaller 559 than the largest usage record, the granularity of the usage record may 560 be reduced until the usage record fits into the available space. 562 Therefore a usage record contains the following information in some 563 Internet Accounting Working Group July 9, 1992 565 form: 567 +-------------------------------------------------------------------+ 568 | RECORD IDENTIFIERS: | 569 | Meter Id (& digital signature if required) | 570 | Timestamp | 571 | Collection Rule ID | 572 |-------------------------------------------------------------------| 573 | FLOW IDENTIFIERS: | COUNTERS | 574 | Address List | Packet Count | 575 | Subscriber ID (Optional) | Byte Count | 576 | Attributes (Optional) | Flow Start/Stop Time | 577 | Group ID flags | | 578 +-------------------------------------------------------------------+ 580 The flow data is collected by the meter (e.g. in a router) as memory 581 permits and forwarded at the reporting intervals to collectors where 582 the data is stored more permanently in some aggregate form. The 583 processing of data after delivery to the accounting application is 584 beyond the scope of this document. 586 4. Meter Services 588 This section describes the operation and control of meters. The 589 collection and control protocol document must specify the exact format 590 in which information is reported; this section describes the 591 information that can be derived from the data reported by the 592 collection system and characterizes the demands placed on the 593 collection and control protocols. Similarly, meter placement is 594 discussed in the Internet Accounting Background document. 596 4.1 Between Meter and Collector - Usage Data Transmission 598 The usage record contents are the raison d'etre of the system. The 599 accuracy, reliability, and security of transmission are the primary 600 concerns of the meter/collector exchange. Since errors may occur on 601 networks, and Internet packets may be dropped, some mechanism for 602 ensuring that the usage information is transmitted intact is needed. 603 The reliability of the collection protocol under light, normal, and 604 extreme loads should be understood before selecting among the 605 collection methods. 607 4.2 Collection Protocol Requirements: Polling, Interval Reporting, 608 and Traps 610 o POLLING 612 Internet Accounting Working Group July 9, 1992 614 The collector sends a poll to the meter to indicate that the 615 meter should respond with the requested record. Even where 616 polling is used, meters under duress must be able to send data 617 as spontaneous traps. The poll should contain a "piggyback 618 ack", indicating that the collector has received the last 619 message. The acknowledgement will allow the meter to discard 620 completed flow records. 622 o INTERVAL REPORTING 624 The meter spontaneously generates usage information at 625 intervals pre-specified by the manager. Even though the meter 626 sends the data, some form of acknowledgement from the 627 collection host with retransmission, or transmission via fully 628 redundant paths to fully redundant collection hosts, must be 629 used to provide reliability. Since the meter may wish to wait 630 for an acknowledgement before flushing buffers, traps are 631 still a necessary emergency mechanism. 633 o TRAPS 635 This may be threshold reporting or exception mechanism only. 636 The meter senses a threshold condition and spontaneously fires 637 a trap with the usage records to the collector (and, if an 638 exception, sends a trap to the network manager as well 639 indicating that an exception condition has occurred.) 641 In any case, the following scenarios must be considered: 643 (a) a poll or acknowledgement from the collector to the meter is 644 lost, 646 (b) a message containing usage data from the meter to the 647 collector is lost, or 649 (c) the meter fills its buffers faster than the poller empties 650 it. 652 POLLING and INTERVAL reporting differ in that POLLING gives control of 653 the precise timing to the COLLECTION host and INTERVAL reporting gives 654 this control to the METER. Either end may want to have this control 655 for load-balancing purposes, but it can't be had by both. 657 SNMP favors POLLING over INTERVAL reporting as a mechanism. The SNMP 658 trap mechanism is available for the meter as a load-balancing 659 emergency mechanism. The collection host should send acknowledgements 660 to the meter anyway, and polls are messages on which acknowledgements 661 can piggyback. The following discussion assumes that a POLLING 662 Internet Accounting Working Group July 9, 1992 664 algorithm is used with TRAPS as an emergency mechanism. 666 The network manager controls the scheduled interval. Therefore the 667 collector and the meter request changes in reporting interval or 668 granularity through their exchanges with the network management 669 entity, and the network management entity arbitrates the default 670 interval and granularity. (Minor or short-term deviations and load 671 spikes are handled through the regular polling and trap mechanisms.) 673 Under normal polling conditions, the collection host specifies which 674 set of usage records it is prepared to receive and the meter provides 675 them. The poll contains an acknowledgement, so the meter may now 676 flush reported and acknowledged records from its buffers. By using 677 rolling counters in the meters, if a usage report is lost, the next 678 report should contain information on the open flows. (For 679 reliability, closed flows should not be flushed until an 680 acknowledgement is received, or the flow has been reported twice, or 681 an equally suitable reliability mechanism is employed.) 683 4.3 Rolling Counters, Timestamps, and Report-in-One-Bucket-Only 685 Once an usage record is sent the decision needs to be made whether to 686 clear any existing flow records or whether to maintain them and add to 687 the counts when recording subsequent traffic on the same flow. The 688 second method, called rolling counters, is recommended and has several 689 advantages. Its primary advantage is that it provides greater 690 reliability - the system can now often survive the loss of some usage 691 records. The next usage record will very often contain yet another 692 reading of many the same flow buckets which were in the lost usage 693 record. The "continuity" of data provided by rolling counters can 694 also supply information used for "sanity" checks on the data itself, 695 to guard against errors in calculations. 697 The use of rolling counters does introduce a new problem: how to 698 distinguish a follow-on flow record from a new flow record. Consider 699 the following example. 701 CONTINUING FLOW OLD FLOW, then NEW FLOW. 703 start time = 1 start time = 1 704 Usage record N: flow count=2000 flow count=2000 (done) 706 start time = 1 start time = 5 707 Usage record N+1: flow count=3000 new flow count = 3000 709 Total count: 3000 5000 711 In the continuing flow case, the same flow was reported when its count 712 Internet Accounting Working Group July 9, 1992 714 was 2000, and again at 3000: the total count to date is 3000. In the 715 OLD/NEW case, the old flow had a count of 2000. Its record was then 716 stopped (perhaps because of temporary idleness, or MAX LIFETIME 717 rules), but then more traffic on with the same characteristics came so 718 a new flow record was started and it quickly reached a count of 3000. 719 The total flow count from both the old and new records is 5000. 721 The flow START TIMESTAMP field is sufficient to resolve this. In the 722 example above, the CONTINUING FLOW flow record in the second usage 723 record has an old FLOW START timestamp, while the NEW FLOW contains a 724 recent FLOW START timestamp. 726 Each packet counted may show up in only one usage record, so as to 727 avoid multiple counting of a single packet (prevent double billing). 728 The record of a single usage flow is informally called a "bucket". If 729 multiple, sometimes overlapping, records of usage information are 730 required (aggregate, individual, etc), the network manager should 731 collect the counts in sufficiently detailed granularity so that 732 aggregate and combination counts can be reconstructed in post- 733 processing on the raw usage data. 735 For example, consider a meter from which it is required to record both 736 "total packets coming in interface #1" and "total packets arriving 737 from any interface sourced by IP address = a.b.c.d". Although a 738 bucket can be declared for each case, it is not clear how to handle a 739 packet which satisfies both criteria. It must only be counted once. 740 By default, it will be counted in the first bucket for which it 741 qualifies, and not in the other bucket. Further, it is not possible 742 to reconstruct this information by post-processing. The solution in 743 this case is to define not two, but THREE buckets, each one collecting 744 a unique combination of the two criteria: 746 Bucket 1: Packets which came in interface 1, 747 And sourced by IP address a.b.c.d 749 Bucket 2: Packets which came in interface 1, 750 And NOT sourced by IP address a.b.c.d 752 Bucket 3: Packets which did NOT come in interface 1, 753 And sourced by IP address a.b.c.d 755 (Bucket 4: Packets which did NOT come in interface 1, 756 And NOT sourced by IP address a.b.c.d ) 758 The desired information can now be reconstructed by post-processing. 759 "Total packets coming in interface 1" can be found by adding buckets 1 760 & 2, and "Total packets sourced by IP address a.b.c.d" can be found by 761 adding buckets 1 & 3. Note that in this case bucket 4 is not 762 explicitly required since its information is not of interest, but is 763 supplied here in parentheses for completeness. 765 Internet Accounting Working Group July 9, 1992 767 4.4 Exception Conditions 769 Exception conditions are more difficult, particularly when the meter 770 runs out of buffer space. Since, to prevent accounting twice for a 771 single packet, packets can only be counted in a single flow at any 772 given time, discarding records will result in the loss of information. 773 The mechanisms to deal with this are as follows: 775 Meter Outages: 777 In case of impending meter outages (controlled crashes, slow 778 power outages, etc.), the meter should simply trap the high- 779 priority data to the collection system followed by the low- 780 priority data, optionally followed by duplicate traps to the 781 network management system or backup collection system. 783 Collector Outages: 785 If the collection system is down or isolated, the meter should 786 inform the network management system of its failure to 787 communicate with the collection system. Usage data is trapped to 788 the backup collection system and/or directly to the network 789 management system. 791 Management Outages: 793 If the network management system does not appear to be 794 responding, the meter should continue reporting. 796 Buffer problems: 798 First, the network manager is informed by trap that there is too 799 much usage data. This can usually be attributed to the 800 interaction between the following controls: 802 (a) the reporting interval is too infrequent, 804 (b) the reporting granularity is too fine, or 806 (c) the throughput/bandwidth of circuits carrying the usage data 807 is too low. 809 The network manager may change any of these parameters in response to 810 the meter (or collector's) plea for help, or simply permit low- 811 priority usage data to be discarded. 813 If it's a buffer problem and flushing the low-priority data will be 814 sufficient, then the low-priority data is sent by trap to the 815 collection system (optionally to the network management system as well 816 as emergency backup collector), and the low-priority data is flushed 817 Internet Accounting Working Group July 9, 1992 819 from the system. Hopefully this will give enough time for the high- 820 priority data to be reported at the regular interval. 822 If buffer problems are anticipated, the high-priority data is sent by 823 trap to the collection system and optionally to the backup network 824 management system, but not flushed until the need is immediate and the 825 low priority data has already been trapped and flushed. 827 If the buffer requirements are so urgent or persistent that data 828 cannot be sent as a trap, the meter may have permission from the 829 network manager (configurable) to discard low-priority data and/or 830 drop the reporting granularity as an exception-handling capability, in 831 which case it should make attempts to inform the network manager and 832 collection system of its actions. (The alternative is to refuse to 833 pass traffic on new flows, an option which is not acceptable in most 834 networks.) 836 4.5 Usage Record Content Description 838 The usage record is described below. 840 In the ADDRESS_LIST field, the "ADJACENT" address refers to the 841 adjacent router, i.e., either the "previous hop" router or the "next 842 hop" router. The address of the ADJACENT router may be collected in 843 a local format (e.g. X.25, Ethernet,etc.) but it is preferred if the 844 IP address form is used. (This may require an address translation, 845 such as RARP tables.) 847 In the FLOW_RECORD field, the "Source" field is somewhat misnamed in 848 that it handles both addresses of the true originating IP source as 849 well as addresses of the ADJACENT (previous hop) router (see above). 850 It might better be thought of as a "FROM" field. Similarly, the 851 "Destination" field contains both the true IP destination address as 852 well as the address of the ADJACENT (next hop) router, and might be 853 thought of as the "TO" field. 855 The Usage Record has a header containing default values for the 856 flow records within it. Although collection protocols may have 857 varying restrictions on format which make this structure 858 impractical, the data delivered by the collection protocol should 859 be complete enough that the following information can be 860 reconstructed. This organization of data is selected to 861 illustrate how this architecture can be expanded. 863 UsageRecord ::= SEQUENCE { 864 RuleTab [0] RuleTableID,-- Unique ID of RuleTable in effect 865 StartTime [1] TimeStamp, -- Default Start Time for this rec. 866 EndTime [2] TimeStamp, -- Default Stop Time for this record 867 GroupMask [3] OCTET STRING (SIZE (1)) OPTIONAL, Masks Not Required 868 FragmentScale [4] INTEGER (1..127),-- counts are divided by 2 to the n 870 Internet Accounting Working Group July 9, 1992 872 OctetScale [5] INTEGER, -- counts are divided by 2 to the n 874 SEQUENCE OF FlowRecord. -- counts for individual flows 875 } 877 FlowRecord ::= 878 GroupMask [0] OCTET STRING (SIZE (1)) OPTIONAL, 879 Flow [1] FlowID, 880 Values [2] FlowData. 882 FlowID ::= 883 Source-From [0] Address-list OPTIONAL, -- Must have source or dest 884 Destination-To [1] Address-list OPTIONAL, -- or both 885 SubscriberID [2] Address-list OPTIONAL. 886 -- attributes such as TOS to be added here later for local area work 888 -- The address list construct 889 -- in future, might have any address for any layer in the protocol 890 -- stack (session, presentation, application) 892 Address-list ::= SEQUENCE { 893 interface [0] INTEGER OPTIONAL, 894 adjacent_address [1] NetWork_Address OPTIONAL, 895 internet_address [2] NetWork_Address OPTIONAL, 896 subscriberId [3] OCTET STRING OPTIONAL 897 } 899 NetWork_Address ::= CHOICE { 900 n-1LayerAddress [0] IMPLICIT OCTET STRING , 901 ipAddress [1] IMPLICIT IpAddress, 902 nsapAddress [2] IMPLICIT OCTET STRING, 903 idprAddress [3] IMPLICIT OCTET STRING< 904 decnetAddress [4] IMPLICIT OCTET STRING 905 } 907 FlowData ::= BEGIN 908 acctFlowToOctets Counter, -- To Counters 909 acctFlowToPDUs Counter, 910 acctFlowFromOctets Counter, -- From Counters 911 acctFlowFromPDUs Counter, 912 acctFlowFirstTime TimeTicks, 913 acctFlowLastTime TimeTicks 914 } 915 TimeStamp :: = CHOICE { 916 [0] TimeTicks -- 1/100s of a second since base time 917 } -- base time since boot time or other base time 918 -- established between meter, manager, and collector 920 5.0 Between Management and Meter - Control Functions and Exceptions 921 Internet Accounting Working Group July 9, 1992 923 Because there are a number of parameters that must be set for internet 924 usage reporting to function properly, and viable settings may change 925 as a result of network traffic characteristics, it is desirable to 926 have dynamic network management, as opposed to static meter 927 configurations. Many of these operations have to do with space 928 tradeoffs - if memory at the meter is exhausted, either the reporting 929 interval must be decreased or a coarser granularity of aggregation 930 must be used so that more data fits into less space. 932 Increasing the reporting interval effectively stores data in the 933 meter; usage data in transit is limited by the effective bandwidth of 934 the virtual link between the meter and the collector, and since these 935 limited network resources are usually also used to carry user data 936 (the purpose of the network), the level of usage reporting traffic 937 should be kept to an affordable fraction of the bandwidth. 938 ("Affordable" is a policy decision made by the network 939 administration.) At any rate, it must be understood that the 940 operations below do not represent the setting of independent 941 variables; on the contrary, each of the values set has a direct and 942 measurable effect on the behavior of the other variables. 944 Network management operations follow: 946 o NETWORK MANAGEMENT AND COLLECTOR IDENTIFICATION 948 The network management station should ensure that meters 949 report to the correct set of collection stations, and take 950 steps to prevent unauthorized access to usage information. 951 The collection stations so identified should be prepared to 952 poll if necessary and accept data from the appropriate meters. 953 Alternate collection stations may be identified in case both 954 the primary network management station and the primary 955 collection station are unavailable. Similarly, alternate 956 network management stations may be identified. 958 o REPORTING INTERVAL CONTROL 960 The usual reporting interval should be selected to cope with 961 normal traffic patterns. However, it may not be unusual for a 962 meter to exhaust its memory during traffic spikes even with a 963 correctly set reporting interval. Some mechanism must be 964 available for the meter to tell the network management station 965 that it is in danger of exhausting its memory (by declaring a 966 "high water" condition), and for the network management 967 station to arbitrate (by decreasing the polling interval, 968 letting nature take its course, or by telling the meter to ask 969 for help sooner next time.) 971 o DUMP CONTROL 973 Internet Accounting Working Group July 9, 1992 975 At some level of buffer usage it may be agreed that usage data 976 is endangered, i.e. may be lost due to lack of memory. In 977 this case, the meter needs to know at what level of buffer 978 usage it should start to dump usage data (without waiting for 979 a poll). Since this is a complex calculation which includes 980 bandwidth and delay characteristics of the network, as well as 981 the processing rate of the collector, it is assumed that the 982 network management station is best able to determine the 983 correct algorithm with the help of the meter and collector. A 984 second panic level may result, when the meter actually does 985 run out of buffer space for usage data. In this case, the 986 meter and manager should agree on which usage data is of lower 987 priority - i.e. which usage data should be deliberately 988 flushed (even if without being reported) in order to make room 989 for higher priority information. 991 o GRANULARITY CONTROL AND GROUPING OF DATA BY MASKS 993 Granularity control is a catch-all for all the parameters that 994 can be tuned and traded to optimize the system's ability to 995 reliably account for and store information on all the traffic 996 (or as close to all the traffic as an administration 997 requires). Granularity 999 (a) controls flow-id granularities for each interface, 1001 (b) determines the number of buckets into which user traffic 1002 will be lumped together, 1004 (c) prioritizes or groups of these buckets into different 1005 reporting categories. 1007 Granularity rules are organized into a tree with decision 1008 points at each addressable protocol layer, starting with the 1009 physical interface. Each leaf on the decision tree also 1010 carries a "category" with it. 1012 o FLOW LIFETIME CONTROL 1014 Flow termination parameters include timeout parameters for 1015 obsoleting inactive flows and removing them from tables and 1016 maximum flow lifetimes. This is intertwined with reporting 1017 interval and granularity, and must be set in accordance with 1018 the other parameters. 1020 4.2.2 Management to Meter: (polls and control) 1022 SET HIGH WATER MARK 1024 A % value interpreted by the meter which tells the meter when 1026 Internet Accounting Working Group July 9, 1992 1028 to send a trap indicating that the management station should 1029 increase the polling interval. 1031 SET FLOOD MARK 1033 A % value interpreted by the meter to indicate how full the 1034 table SHOULD be before the meter considers panicking and 1035 dumping the contents of the meter to the management station in 1036 raw (e.g., SNMP OPAQUE) form. 0% indicates that that a trap 1037 should be sent each time a counter is incremented. 100% 1038 indicates that a trap should never be sent. 1040 SET FLOW TERMINATION PARAMETERS 1042 The meter should have the good sense in situations where lack 1043 of resources may cause data loss to purge flow records from 1044 its tables: 1046 (a) flows that have already been reported and show no activity 1047 since the last report 1049 (b) oldest flows, or 1051 (c) flows with the smallest number of unreported packets 1053 - INACTIVITY TIMEOUT The time in seconds since last packet 1054 seen (and last report) after which the flow may be terminated. 1056 - MAX LIFETIME Guidelines for the maximum lifetime of a flow. 1057 (Not mandatory, but the meter should make an effort at 1058 reporting time to purge flows that have had a lifetime greater 1059 than this value, even if it results in the instantaneous 1060 creation of a new flow with identical parameters. 1062 SET FLOW PRIORITY [ GROUP MASK] (mask is an 8-bit quantity) 1064 Tell meter which flows are considered "critical" - i.e. in a 1065 crisis which flows can least afford to lose data. Reporting 1066 masks set by the COLLECTION RULES TABLE. This is used to 1067 indicate precedence among other things. 1069 REPORT [ GROUP MASK (0 or default indicates report ALL)] 1071 Poll to meter indicating that a normal report of indicated 1072 flows should be made (i.e. any flow whose rule has indicated 1073 that it has a bit set which is set in the mask.) 1075 SET GRANULARITY [ RULE TABLE ] see RULE TABLE, next section. 1077 Internet Accounting Working Group July 9, 1992 1079 5.1 Rule Tables: Granularity Control 1081 A rule table is a sequence of numbered rules which describe the 1082 granularity at which a meter should count. It is structured to 1083 support a "decision tree" hierarchy. For example, some rules can be 1084 used at a high-level to identify a large subclass of packets, and 1085 other rules can be at a mid-level to further break down the subclass 1086 into finer subclasses, and still other rules can be "leaf" rules which 1087 actually identify individual flows (buckets). Note that some rule 1088 tables will consist of only a few rules (possibly just one) resulting 1089 in the definition of only a few flows (buckets). In general, there 1090 will be a hierarchy of rules, such that the outcome of matching a 1091 particular rule might be to go to yet another rule for further 1092 qualification. 1094 5.2 Classification Criteria 1096 The information upon which such classifications are made come from two 1097 sources: the data fragment (or packet) itself, and the path that the 1098 fragment traveled. The fragment itself specifies: 1100 o address of the packet's source 1102 o network address of the packet's ultimate network destination 1104 o Other attributes, such as protocol used or type-of-service 1105 fields. (These attributes are not supported below but could 1106 be added later). 1108 The path the packet traveled specifies: 1110 o the interface that the packet arrived on 1112 o the interface that the packet will leave on 1114 o the previous hop router/source address (address from layer n- 1115 1) 1117 o the next hop router/sink address (address from layer n-1) 1119 The rule table, then, provides a way to classify packets according to 1120 the above parameters. 1122 The rules use a form of "wild card" matching to allow entire "regions 1123 of address space", such as an entire source network, to be matched 1124 using a single rule. The wild card matching symbol notation is an 1125 asterisk (*). 1127 Leaf rules support a feature which allows a single leaf to be expanded 1128 into several buckets via an "individuate" mask. For example, if a 1129 Internet Accounting Working Group July 9, 1992 1131 leaf rule identifies all packets which arrived from a particular 1132 source IP address, rather than count all of those packets into a 1133 single bucket, it may be desirable to further subdivide those packets 1134 according to which "next hop" they used. In that case, the 1135 individuate mask would identify the "destination adjacent interface" 1136 as the field to differentiate on, causing packets with different 1137 values in those fields to be counted in separate buckets. 1139 Both the wild card matching mask and the individuate mask are simply 1140 short cuts. The same effect could be achieved without them but the 1141 rule table would become extremely large and the number of comparisons 1142 required might severely impact performance. 1144 5.3 Representation of Flow Identification in the Flow Record 1146 Once a packet has been classified and is ready to be counted, an 1147 appropriate flow record must either already exist or must be created. 1148 The flow record has a flexible format where unnecessary identification 1149 fields may be omitted. The determination of which fields of the flow 1150 record to use, and of what values to put in them, is specified by the 1151 leaf node of the rule table tree. 1153 The leaf rules may contain additional information, such as a 1154 subscriber ID, which is to be placed in the attribute section of the 1155 usage record. That is, if a particular flow matches the 1156 qualifications for the leaf rule, then the corresponding flow record 1157 should be marked not only with the qualifying identification fields, 1158 but also with the additional information. Using this feature, several 1159 leaf nodes may each carry the same subscriber ID value, such that the 1160 resulting usage flow records will each contain the same subscriber ID 1161 value which can then be used in post-processing or between collector 1162 and meter as a collection criterion. 1164 5.4 Standard Rule Tables 1166 Although the rule table is a flexible tool, it can also become very 1167 complex. The following standard rule tables should be sufficient for 1168 most applications: 1170 o ADJACENT SYSTEMS: tell the meter to records packets by the IP 1171 address of the Adjacent Systems (neighboring originator or 1172 next-hop). (Variants on this table are "report source" or 1173 "report sink" only.) This strategy might be used by a regional 1174 or backbone network which wants to know how much aggregate 1175 traffic flows to or from its subscriber networks. 1177 o END SYSTEMS: tell the meter to record packets by the IP 1178 address pair contained in the packet. (Variants on this table 1179 are "report source" or "report sink" only.) This strategy 1181 Internet Accounting Working Group July 9, 1992 1183 might be used by an End System network to get detailed host 1184 traffic matrix usage data. 1186 o HYBRID SYSTEMS: For one interface, report End Systems, for 1187 another interface report Adjacent Systems. This strategy 1188 might be used by an enterprise network to learn detail about 1189 local usage and use an aggregate count for the shared regional 1190 network. 1192 5.5 Rule Table Components 1194 The rule table is structured to allow decision-tree operations. Each 1195 rule begins with the specification of which field should be used for 1196 this rule's classification test. For example, the selected field 1197 might be "previous hop IP address". Each field may be further 1198 qualified by a corresponding field_mask. In this example, the 1199 intention might be to restrict the qualification to only look at the 1200 top two bytes of the previous hop IP address. The field_mask, then, 1201 would contain logical 1's corresponding to the subfields of interest 1202 and 0's otherwise. In this case, the field_mask 255.255.0.0 would be 1203 used. 1205 Having extracted the appropriate portion of the field, the next 1206 section of the rule attempts to match the selected field against 1207 specified values. Each value is represented as part of an "action 1208 set". There can be many action sets in a rule. Each action set 1209 specifies a value to match and further instructions should there be a 1210 match. If there is no match, then the next sequential rule is 1211 evaluated. 1213 5.6 Rule Table Definition 1215 The following is the rule table definition. 1217 -- 1218 -- The Rule Table 1219 -- 1221 -- FieldIdentifier ::= CHOICE { 1222 -- address [0] IMPLICIT Network-Address, 1223 -- mibVariable [1] IMPLICIT OBJECT IDENTIFIER 1224 -- } 1226 -- FieldValue ::= Opaque 1228 -- PatternMask ::= OCTET STRING 1229 Internet Accounting Working Group July 9, 1992 1231 -- Pattern ::= SEQUENCE { 1232 -- mask1 PatternMask, 1233 -- mask2 PatternMask 1234 -- } 1236 -- RuleAction ::= CHOICE { 1237 -- direct [0] IMPLICIT ENUMERATED { ignore(1), count(2) }, 1238 -- goto [1] IMPLICIT INTEGER rule number to jump to 1239 -- } 1241 RuleTable ::= SEQUENCE OF AcctRuleEntry. 1243 AcctRuleEntry ::= SEQUENCE { 1244 acctRuleIndex INTEGER, -- index 1245 acctRuleSelector INTEGER, -- what to select on 1246 acctRuleMask Opaque, -- the mask value 1247 acctRuleMatchedValue Opaque, -- the matched value 1248 acctRuleAction INTEGER, -- action to take 1249 acctRuleJumpIndex INTEGER -- where to go 1250 } 1252 acctRuleSelector 1253 INTEGER { source-interface(1), destination-interface(2), 1254 source-adjacent(3), destination-adjacent(4), 1255 source-network(5), destination-network(6)} 1256 DESCRIPTION "Defines the source of the value to match." 1258 acctRuleMask 1259 DESCRIPTION "The initial mask used to compute the desired value. 1260 Depending on the data type being prepared, this could either 1261 be an OCTET STRING, or an INTEGER." 1263 acctRuleMatchedValue 1264 DESCRIPTION "The resulting value to be matched for equality. 1265 Specifically, if the attribute chosen by the acctRuleSelector 1266 logically ANDed with the mask specified by the acctRuleMask 1267 equals the value specified in the acctRuleMatchedValue, then 1268 continue processing the table entry based on the action 1269 specified by the acctRuleAction entry. Otherwise, proceed to 1270 the next entry in the rule table." 1272 acctRuleAction INTEGER { ignore(1), leaf(2), goto(3) } 1273 DESCRIPTION "The action to be taken. If ignore(1), stop the search. 1274 If leaf(2), then count the flow based on the values set 1275 aside during the walk thru the rule table. 1276 Otherwise, if goto(3), then record the value of the 1277 attribute indicated by the acctRuleSelector, and 1278 use the value of the acctRuleJumpIndex to start the 1280 Internet Accounting Working Group July 9, 1992 1282 matching process at at new entry in the rule table." 1284 acctRuleJumpIndex INTEGER 1285 DESCRIPTION "index into the Rule table. Where to re-start the 1286 search. Must take on one of the values for acctRuleIndex." 1288 Notes: 1290 Caution must be taken to ensure that rule tables map into non-looping 1291 trees. 1293 When address tests are used (field = address type), perform tests on 1294 the interface number first, the link level address second, the network 1295 address third, and the attributes (if any are defined later) last. 1296 Within an address type, test the source address first and the 1297 destination address last. 1299 5.7 Meter to Management: (traps and responses) 1301 CONTROL PARAMETERS: 1303 DECLARE DATA LOSS Trap to let manager know that usage data 1304 is being lost. 1306 DECLARE HIGH WATER Trap to request that manager increase polling 1307 interval. (Used when number of flows increases.) 1309 DECLARE FLOOD / FLUSH Trap dumping the flow records currently 1310 being monitored by the meter. 1312 6.0 Between Management and Collector - Control Functions 1314 Interactions between the manager and the collector are left in the 1315 province of the collection protocol definition. 1317 7.0. Anticipated Collection Protocols 1319 SNMP An Internet Accounting Meter Services MIB is needed. The working 1320 group recommends that SNMP security services be used in conjunction 1321 with the MIB and suggests that a reliable datagram service or 1322 transport service be used if and when available. Also, the 1323 introduction of a table retrieval service would greatly ease 1324 implementation and improve efficiency. 1326 APPENDIX 1328 Internet Accounting Working Group July 9, 1992 1330 A.1 Network Characterization 1332 Internet users have extraordinarily diverse requirements. Networks 1333 differ in size, speed, throughput, and processing power, among other 1334 factors. There is a range of usage reporting capabilities and 1335 requirements. For usage reporting purposes, the Internet may be 1336 viewed as a continuum which changes in character as traffic passes 1337 through the following representative levels: 1339 International 1340 Backbones/National --------------------------- 1341 / \ 1342 Regional/MidLevel ----------- ------------- 1343 / \ \ / / \ 1344 Stub/Enterprise --- --- --- ---- ---- 1345 ||| ||| ||| |||| |||| 1346 End-Systems/Hosts xxx xxx xxx xxxx xxxx 1348 Note that mesh architectures can also be built out of these 1349 components, and that these are merely descriptive terms. The nature 1350 of a single network may encompass any or all of the descriptions 1351 below, although some networks can be clearly identified as a single 1352 type. 1354 BACKBONE networks are typically bulk carriers that connect other 1355 networks. Individual hosts (with the exception of network management 1356 devices and backbone service hosts) typically are not directly 1357 connected to backbones. 1359 REGIONAL networks are closely related to backbones, and differ only in 1360 size, the number of networks connected via each port, and geographical 1361 coverage. Regionals may have directly connected hosts, acting as 1362 hybrid backbone/stub networks. A regional network is a SUBSCRIBER to 1363 the backbone. 1365 STUB/ENTERPRISE networks connect hosts and local area networks. 1366 STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 1367 networks. 1369 END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above 1370 networks. 1372 Providing a uniform identification of the SUBSCRIBER in finer 1373 granularity than that of end-system, (e.g. user/account), is beyond 1374 the scope of the current architecture, although an optional field in 1375 the usage reporting record may carry system-specific "accountable 1376 (billable) party" labels so that meters can implement proprietary or 1377 non-standard schemes for the attribution of network traffic to 1378 Internet Accounting Working Group July 9, 1992 1380 responsible parties. 1382 A.2 Recommended Usage Reporting Capabilities 1384 Initial recommended usage reporting conventions are outlined here 1385 according to the following internet building blocks. It is important 1386 to understand what complexity reporting introduces at each network 1387 level. Whereas the hierarchy is described top-down in the previous 1388 section, reporting requirements are more easily addressed bottom-up. 1390 End-Systems 1391 Stub Networks 1392 Enterprise Networks 1393 Regional Networks 1394 Backbone Networks 1396 END-SYSTEMS are currently responsible for allocating network usage to 1397 end-users, if this capability is desired. From the internet protocol 1398 perspective, end-systems are the finest granularity that can be 1399 identified without protocol modifications. Even if a meter violated 1400 protocol boundaries and tracked higher-level protocols, not all 1401 packets could be correctly allocated by user, and the definition of 1402 user itself varies too widely from operating system to operating 1403 system (e.g. how to trace network usage back to users from shared 1404 processes). 1406 STUB and ENTERPRISE networks will usually collect traffic data either 1407 by end-system network address or network address pair if detailed 1408 reporting is required in the local area network. If no local 1409 reporting is required, they may record usage information in the exit 1410 router to track external traffic only. (These are the only networks 1411 which routinely use attributes to perform reporting at granularities 1412 finer than end-system or intermediate-system network address.) 1414 REGIONAL networks are intermediate networks. In some cases, 1415 subscribers will be enterprise networks, in which case the 1416 intermediate system network address is sufficient to identify the 1417 regional's immediate subscriber. In other cases, individual hosts or 1418 a disjoint group of hosts may constitute a subscriber. Then end- 1419 system network address pairs need to be tracked for those subscribers. 1420 When the source may be an aggregate entity (such as a network, or 1421 adjacent router representing traffic from a world of hosts beyond) and 1422 the destination is a singular entity (or vice versa), the meter is 1423 said to be operating as a HYBRID system. 1425 At the regional level, if the overhead is tolerable it may be 1426 advantageous to report usage both by intermediate system network 1427 address (e.g. adjacent router address) and by end-system network 1428 address or end-system network address pair. 1430 Internet Accounting Working Group July 9, 1992 1432 BACKBONE networks are the highest level networks operating at higher 1433 link speeds and traffic levels. The high volume of traffic will in 1434 most cases preclude detailed usage reporting. Backbone networks will 1435 usually account for traffic by adjacent routers' network addresses. 1437 Internet Accounting Working Group July 9, 1992