Internet Engineering Task Force Nevil Brownlee INTERNET DRAFT The University of Auckland Cyndi Mills BBN Systems and Technologies Greg Ruth GTE Laboratories, Inc November 1994 Expires in six months Accounting: Usage Reporting Architecture Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. This Internet Draft is a product of the Internet Accounting Working Group of the IETF. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or any other Internet Draft. Abstract This document describes an architecture for the reporting of network traffic flows, discusses how this relates to an overall network accounting architecture, and describes how it can be used within the Internet. INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Contents 1 Statement of Purpose and Scope 2 2 Internet Accounting Framework 4 2.1 Internet Accounting Model . . . . . . . . . . . . . . . . . . . 5 2.2 Between METER and COLLECTOR . . . . . . . . . . . . . . . . . . 6 2.3 Between MANAGER and METER . . . . . . . . . . . . . . . . . . . 6 2.4 Between NETWORK MANAGER and COLLECTOR . . . . . . . . . . . . . 7 2.5 Between COLLECTORs (COLLECTOR - COLLECTOR) . . . . . . . . . . 7 2.6 Multiple METERs to a COLLECTOR . . . . . . . . . . . . . . . . 7 2.7 One METER to multiple COLLECTORs . . . . . . . . . . . . . . . 8 2.8 Between MANAGERs (MANAGER - MANAGER) . . . . . . . . . . . . . 8 3 Usage Reporting Components 8 3.1 Meters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Flows and Reporting Granularity . . . . . . . . . . . . . . . .10 3.3 Usage Records, Flow Data Files . . . . . . . . . . . . . . . .12 4 Meter Services 13 4.1 Between Meter and Collector - Usage Data Transmission . . . . .14 4.2 Polling, Interval Reporting, Traps . . . . . . . . . . . . . .14 4.3 Rolling Counters, Timestamps, and Report-in-One-Bucket-Only . .16 4.4 Exception Conditions . . . . . . . . . . . . . . . . . . . . .18 4.5 Usage Record Content Description . . . . . . . . . . . . . . .19 5 Between Management and Meter - Control Functions and Exceptions 20 5.1 Management to Meter: (polls and control) . . . . . . . . . . .22 5.2 Rule Tables: Granularity Control . . . . . . . . . . . . . . .23 5.3 Classification Criteria . . . . . . . . . . . . . . . . . . . .23 5.4 Representation of Flow Identification in the Flow Record . . .24 5.5 Standard Rule Tables . . . . . . . . . . . . . . . . . . . . .25 5.6 Rule Table Components . . . . . . . . . . . . . . . . . . . . .26 5.7 Rule Table Description . . . . . . . . . . . . . . . . . . . .26 5.8 Meter to Management: (traps and responses) . . . . . . . . . .28 6 Between Management and Collector - Control Functions 28 7 Anticipated Collection Protocols 28 8 APPENDIX 29 8.1 Network Characterisation . . . . . . . . . . . . . . . . . . .29 8.2 Recommended Usage Reporting Capabilities . . . . . . . . . . .30 9 Acknowledgments 31 10 References 31 11 Security Considerations 31 12 Author's Address 32 Brownlee, Mills, Ruth [Page 2] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 1 Statement of Purpose and Scope This document describes an architecture for Internet usage reporting which provides that: - Connectionless network usage information is presented to collection and processing applications (e.g. billing) in a standardised format. - The usage reporting protocol structure can be consistently applied to any protocol/application at any network layer (MULTI-LAYER, e.g. network, transport, application layers). - Usage reporting units are defined in such a way that the units are valid for multiple networking protocol stacks and that usage reporting protocol implementations are useful in MULTI-PROTOCOL environments. - A near-term framework for usage reporting is established to encourage experimentation with Internet accounting; results and effectiveness can be compared across multiple implementations now. The usage reporting architecture specifies common metrics for measuring usage in an Internet environment. By using the same metrics, usage data can be exchanged and compared across multiple platforms. Usage data can be used for: - Attribution of network usage to subscribers, - Quantification of network performance, - Usage-based policy enforcement, and - Usage-based cost recovery (billing) This document focuses on the attribution of connectionless network service usage to subscribers as a required building block for the other services. The usage reporting architecture is deliberately structured so that specific-protocol implementations may extend coverage to multi-protocol environments and to other protocol layers, such as usage reporting for application-level services. Use of the same model for both network- and application-level billing may simplify the development of generic billing/statistics applications which process and/or correlate any or all levels of usage information. Brownlee, Mills, Ruth [Page 3] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 This document is NOT A PROTOCOL SPECIFICATION. It specifies and structures the information that a usage reporting protocol needs to collect, describes requirements that such a protocol must meet, and outlines tradeoffs. For performance reasons, it may be desirable to use traffic information gathered through usage reporting in lieu of similar network statistics. Although the quantification of network performance is not the primary purpose of this architecture, the usage data may serve a dual purpose. Policy-based routing and access control policies require mechanisms which answer the question: "who may use the network for what purpose." Tighter coordination between usage reporting and access control are needed to enable the use of real-time controls such as quotas. This architecture does not cover enforcement at this time. Quotas are a means for information to be transferred from the usage reporting system to network management's access control function for the purpose of enforcement, i.e. limits placed on usage. A complete implementation of quotas may involve real-time distributed interactions between meters, the quota system, and access control. Enforcement of quotas is beyond the scope of the near-term architecture. The cost recovery structure decides "who pays for what." The major issue here is how to construct a tariff (who gets billed, how much, for which things, based on what information, etc). Tariff issues include fairness, predictability (how well can subscribers forecast their network charges), practicality (of gathering the data and administering the tariff), incentives (e.g. encouraging off-peak use), and cost recovery goals (100% recovery, subsidisation, profit making). These issues are not covered here, although usage data reporting is one possible component of a comprehensive billing system. Background information explaining why this approach was selected is provided by "Internet Accounting: Background (RFC 1272)" [1]. Individual collection protocol documents will address precise formats, e.g. MIB (management information base) specifications for SNMP. 2 Internet Accounting Framework The accounting framework and terminology used by OSI Accounting Management is applicable here. The OSI reference model [2] defines the scope of OSI accounting as follows: "Accounting management is the set of facilities which enables charges to be established for the use of managed objects and Brownlee, Mills, Ruth [Page 4] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 costs to be identified for the use of those managed objects. Accounting management is the set of facilities to (a) inform users of costs incurred or resources consumed, (b) enable accounting limits to be set for the use of managed objects, and (c) enable costs to be combined where multiple managed objects are invoked to achieve a given communication objective." Usage reporting mechanisms satisfy the measurement of "resources consumed" in (a). Pricing, i.e. establishing the cost of using these resources, is left to billing applications which are not covered here. Quotas are the mechanism for enforcing (b). Combining costs (c) is achieved through the post-processing of usage data by accounting applications (not covered here). The near-term architecture describes usage reporting only. Other aspects of an overall architecture are left for future extension or replacement by a long-term Internet accounting architecture. The following sections outline a model of Internet accounting, specifically the usage reporting function, which is further refined throughout this document. 2.1 Internet Accounting Model The Internet accounting model draws from working drafts of the OSI accounting model. It separates accounting functions into the parts shown below. NETWORK MANAGER ------------------ / \ \ / \ \ / \ \ / \ \ METER <-----> COLLECTOR <-----> APPLICATION - NETWORK MANAGER (or simply, MANAGER): The network manager is responsible for the control of the meter and collector, and determines and identifies backup collectors and managers as required. The manager manages the topology of the networks and relationships between entities in the network. Frequently the manager also acts as a collector. Brownlee, Mills, Ruth [Page 5] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 - METER: The meter performs the measurement and aggregates the results. Some characteristics of the meter are implementation- specific. The meter is where traffic is measured and usage data "generated." - COLLECTOR: The collector is responsible for the integrity and security of data during transport from the meter to the application. This responsibility includes accurate and preferably unforgeable recording of the accountable (billable) party identity. The collector is the recipient of the usage data. - APPLICATION: The application manipulates the usage data in accordance with policy, and determines the need for information from the metering devices. Standard information required for performing the collection of usage information of meters can be viewed as the product of protocol exchanges: 2.2 Between METER and COLLECTOR The data which travels this path is the usage record itself. The purpose of all the other exchanges is to manage the proper execution of this exchange. Usage record format is described in this section. Usage records which travel from meter to collector consist of items such as meter id, address list, attribute list, and values (e.g. packet counts, byte counts, and timestamps). In general, the collector generates no traffic to the meter but polls. The collector may know characteristics of the interfaces which are being metered through other means. Most notably, if an interface is accounting on a statistical basis the collector should at least know the average sampling rate and preferably be able to set the sampling rate to control the accounting process. (Sampling algorithms are not prescribed by the architecture; however it should be noted that any sampling techniques must be accompanied by documentation verifying adequate security and statistical validity before adoption.) 2.3 Between MANAGER and METER The manager is responsible for controlling the meter. Meter management consists of commands which start/stop usage reporting, manage the exchange between meter and collector(s) (to whom do meters report the data they collect, set reporting intervals and timers), and set reporting granularities. Brownlee, Mills, Ruth [Page 6] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Although most of the control information consists of commands to the meter, the meter may need to inform the manager of unanticipated conditions and meter responses to time-critical situations, such as buffer overflows. 2.4 Between NETWORK MANAGER and COLLECTOR These parallel the manager to meter exchange, permitting feedback on collection performance and controlling access to the collected traffic statistics. 2.5 Between COLLECTORs (COLLECTOR - COLLECTOR) A CASCADE of collectors is formed when one collector aggregates information from other intermediate collectors. ----- COLLECTOR A ----- / \ / \ -- COLLECTOR B -- COLLECTOR C / | \ / | \ / | \ / | \ COLLECTOR D COLLECTOR E COLLECTOR F METER C1 METER C2 METER C3 | | | METER D1 METER E1 METER F1 Collectors exchange data with other collectors only when cascading is in effect (hierarchical reporting) or collection systems are voluntarily exchanging data for cross-verification or merging incomplete data sets (both examples of peer reporting). One method of cascading reporting is for the collector closer to the actual meter to behave as a meter with regard to the aggregating (closer to the root) collector, using the METER to COLLECTOR exchange to relay data towards the root. The preferred method is file transfer. A generic usage reporting file format for data exchange between collection systems has yet to be specified, e.g. a version or offshoot of AMA similar to the modifications made for SMDS accounting. Since redundant reporting may be used in order to increase the reliability of usage data, exchanges among multiple entities must be considered as well. Brownlee, Mills, Ruth [Page 7] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 2.6 Multiple METERs to a COLLECTOR Several uniquely identified meters report to one or more collectors. Meters are identified by the collection protocol or by a header within each usage message from the meter to the collector. A collector must be able to accept data in varying granularities. Collectors may receive reports on the progress of packets at various metering points along the path which the packet travels. When the collected data is processed or analysed, parallel information from the network management system may be required in order to determine which meter recorded the entry (or exit) point of the packet to (from) the network. 2.7 One METER to multiple COLLECTORs Meters may report the same information to multiple collectors for the purposes of redundancy. If synchronised collections are required, this can be achieved by having the manager switch the meter back and forth between two identical rules sets (with different rule set ids), and requesting collection of the old rule set's flow data by all collectors after each switch. This would produce identical 'snapshots' of the usage records at each collector. The architecture does not, however, require multiple collectors to be synchronised, nor to use the same reporting frequency. For example one collector could collect flow data every 15 minutes, while another (backup) collector collected it every two hours. Note that if collections are not synchronised, it is unlikely that usage records from two different collectors will agree exactly. Each Network management will have to decide whether the flexibility of asynchronous collection is offset by the loss of precision for interval reporting. 2.8 Between MANAGERs (MANAGER - MANAGER) Synchronisation between multiple management systems is the province of network management protocols. This usage reporting architecture specifies only the network management controls necessary to perform the usage reporting function and does not address the more global issues of simultaneous or interleaved (possibly conflicting) commands from multiple network management stations or the process of transferring control from one network management station to another. Brownlee, Mills, Ruth [Page 8] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 3 Usage Reporting Components The usage reporting architecture specifies a means for collecting information about network usage in connectionless Internet environments. Usage is reported on connectionless protocol packets sent at the link layer. For example, in the OSI protocol suite, the packets being counted are OSI CLNP datagrams. In the Internet Protocol Suite, the packets are IP datagrams. More precisely, the packets being counted are datagram fragments - the individual units in which the connectionless network protocol carries data, known as Protocol Data Units or PDUs. Routing protocol traffic may also be counted. Connection-oriented protocols can be reported under the usage reporting architecture as well. The following sections define: - Meters - Flows and reporting granularity - Usage records 3.1 Meters Meters count quantities (VALUES) and attribute them to ACCOUNTABLE ENTITIES. The accountable entity may be a network subscriber, a host system, a network, etc., depending on the granularity specified by the meter's manager. The approach to usage reporting at the network level outlined here assumes that routers or traffic monitors throughout the Internet are instrumented with meters to measure traffic. Issues surrounding the choice of meter placement are discussed in the Internet Accounting Background RFC [1]. The purpose of defining meters at the Internet level is to devise a way of succinctly aggregating entity usage information. Since IP service is connectionless, there is by definition no way to tell whether a datagram with a particular source/destination combination is part of a stream of packets or not. However, protocols which contain flow identifiers may provide enough state information to identify a stream or flow uniquely. Each packet is completely independent. In order to provide fully detailed reporting about the actions of entities on the network, a separate usage record would have to be maintained for each packet detailing the usage information. This would result in a very high level Brownlee, Mills, Ruth [Page 9] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 of overhead, possibly as high as one packet of usage information for each packet of data. Therefore, usage aggregation provides an economical and practical way to measure internetwork traffic and ascribe it to a network subscriber. 3.2 Flows and Reporting Granularity For the purpose of usage reporting we define the concept of a FLOW, which is an artificial logical equivalent to a call or connection. A flow is a portion of traffic, delimited by a start and stop time, that is attributable to a particular accountable entity. Values (packet counts, byte counts, etc.) associated with a flow are aggregate quantities reflecting events which take place in the DURATION between the start and stop times. The start time of a flow is fixed for a given flow; the end time may increase with the age of the flow. +---------------------------------------------------------------------+ | Sample Entity [Attributes] Values | +---------------------------------------------------------------------+ | 10.1.0.1 IP/UDP Packets, Bytes, Start/Stop Time | +---------------------------------------------------------------------+ GRANULARITY is the "control knob" by which an application and/or the meter can trade off the overhead associated with performing usage reporting for the level of detail supplied. A coarser granularity means a greater level of aggregation; finer granularity means a greater level of detail. Thus, the size and number of flows measured at a meter can be regulated by changing the granularity of the accountable entity, the attributes, or time intervals. Flows are like an adjustable pipe - many fine granularity streams can carry the data with each stream accounted for individually, or data can be bundled in one coarse granularity pipe. Flow granularity is controlled by adjusting the level of detail at which the following are reported: - The accountable entity - The categorisation of packets (attributes) - The lifetime/duration of a flow (the reporting interval) Settings for these granularity factors may vary from meter to meter. Also, they may be static (established by definition or agreement) or Brownlee, Mills, Ruth [Page 10] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 dynamic (set by a control protocol). The granularity of ACCOUNTABLE ENTITIES is primarily specified by the ADDRESS LIST associated with a flow. That is, a flow's address list determines a subset of the traffic visible to the meter by specifying restrictions on the set of entities associated with that traffic. Beyond the local-area (i.e. for Internet traffic which crosses administrative boundaries) the following three types of address specifiers should be used to identify flows: - Source address of the packets - Destination address of the packets - Source/destination address pair of the packets For example, if a flow's address list is specified as "source address = IP address 10.1.0.1," then all IP packets from that address are counted in that flow. If a flow's address list is specified as "source address = IP address 10.1.0.1, destination address = IP address 26.1.0.1" then only IP packets from 10.1.0.1 to 26.1.0.1 are counted in that flow. When source/destination address pairs are used to designate flows, the set of flow data is referred to as a TRAFFIC MATRIX. The addresses appearing in a flow's address list may include one or more of the following types: - The INTERFACE NUMBER of the meter, i.e. the port on which the meter measured the traffic. Together with a unique address for the meter this uniquely identifies a particular physical-level port. - The ADJACENT ADDRESS, which is the media address of the source or destination host for a traffic flow. As an example, for Ethernet LANs [3] this is a six-octet Media Access Control (MAC) address which uniquely identifies a network interface. For a host connected to the same LAN segment as the meter the adjacent address will be the host's MAC address. For hosts on other LAN segments it will be the MAC address of the adjacent (upstream or downstream) router carrying the traffic flow. - The PEER ADDRESS, which identifies the source or destination of the PEER-LEVEL packet. The form of a peer address will depend on the network-layer protocol in use. - The TRANSPORT ADDRESS, which identifies the source or destination port. Brownlee, Mills, Ruth [Page 11] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Reporting by adjacent intermediate sources and destinations or simply by meter interface (most useful when the meter is embedded in a router) supports hierarchical Internet reporting schemes as described in the background RFC 1272 [1]. That is, it allows backbone and regional networks to measure usage to just the next lower level of granularity (i.e. to the regional and stub/enterprise levels, respectively), with the final breakdown according to end user performed by the stub/enterprise networks. In cases where network addresses are dynamically allocated (e.g. mobile subscribers), further subscriber identification will be necessary for accurate accounting. Therefore, provision is made to further specify the accountable entity through the use of an optional SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated with a particular flow either through a static rule table or through proprietary means within the meter. Granularity of accountable entities is further specified by additional ATTRIBUTES. These attributes include characteristics such as traffic priority or other type of service characteristics. User-level reporting is not addressed at this time, since it requires the addition of an IP option to identify the user, although the addition of a user-id as an entity at a later date is not precluded by this architecture. This model can be continued at levels above the transport level, such as application for TCP/IP networks or session/presentation/application for OSI networks. For local-area reporting (within an administration), flows between subscriber entities can be subdivided into finer granularity by specifying ATTRIBUTES associated with the measured traffic. Attributes are not described here, however a sample IP attribute is: - QUALITY OF SERVICE: An internet header contains type of service bits, which indicate that the router should give the packet precedence for throughput, reliability, or delay. For example, for a flow with a flow id including throughput in its attributes, only datagrams which explicitly request high throughput would be counted. The set of rules controlling the reporting granularity is known as the COLLECTION RULE SET. As will be shown, the collection rules form an integral part of the reported information - i.e. the recorded usage information cannot be properly interpreted without a definition of the rules used to collect that information. It is expected that the collection rules will change rather infrequently; nonetheless, the rule Brownlee, Mills, Ruth [Page 12] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 set in effect at any time must be identifiable via a RULE SET ID. 3.3 Usage Records, Flow Data Files A USAGE RECORD contains the descriptions of and values for one or more flows. Quantities are counted in terms of number of packets and number of bytes per flow. Each usage record contains the entity identifier of the meter (a network address), a time stamp and a list of reported flows. A collector will build up a file of usage records by regularly collecting flow data from a meter. Such a file is called a FLOW DATA FILE. Flow data is moved from meter to collector via a series of protocol exchanges between them. The details of this depend on the Meter Services MIB, [4]. If the meter's granularity is fine (many small streams), many such exchanges may be required to a complete set of traffic flow information. A usage record contains the following information in some form: +-------------------------------------------------------------------+ | RECORD IDENTIFIERS: | | Meter Id (& digital signature if required) | | Timestamp | | Collection Rules ID | +-------------------------------------------------------------------+ | FLOW IDENTIFIERS: | COUNTERS | | Address List | Packet Count | | Subscriber ID (Optional) | Byte Count | | Attributes (Optional) | Flow Start/Stop Time | +-------------------------------------------------------------------+ The flow data is collected by the meter (e.g. in a router) as memory permits and recovered at the reporting intervals by collectors where the data is stored more permanently as usage records in flow data files. The processing of flow data files by later applications is beyond the scope of this document. 4 Meter Services This section describes the operation and control of meters. The Meter Services MIB document [4] specifies the exact format in which information is reported; this section describes the information that can be derived from the data reported by the collection system and Brownlee, Mills, Ruth [Page 13] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 characterises the demands placed on the collection and control protocols. Similarly, meter placement is discussed in the Internet Accounting Background document [1]. 4.1 Between Meter and Collector - Usage Data Transmission The usage record contents are the raison d'etre of the system. The accuracy, reliability, and security of transmission are the primary concerns of the meter/collector exchange. Since errors may occur on networks, and Internet packets may be dropped, some mechanism for ensuring that the usage information is transmitted intact is needed. The reliability of the collection protocol under light, normal, and extreme loads should be understood before selecting among collection methods. 4.2 Polling, Interval Reporting, Traps Accounting protocols may use polling algorithms or interval reporting to collect accounting data. In either case, to maintain completeness, it is important to have a trap mechanism to help deal with boundary conditions. - POLLING The collector sends a poll to the meter to indicate that the meter should respond with the requested flow data. The poll should contain a "piggyback ack," indicating that the collector has received the last message. Such acknowledgments would allow the meter to recognise (and later discard) completed flow records. Even where polling is used, meters under duress should be able to signal this using spontaneous traps. - INTERVAL REPORTING The meter spontaneously generates usage information at intervals pre-specified by the manager. Even though the meter sends the data, some form of acknowledgment from the collection host with retransmission, or transmission via fully redundant paths to fully redundant collection hosts, must be used to provide reliability. Since the meter may wish to wait for an acknowledgment before flushing buffers, traps are still a necessary emergency mechanism. - TRAPS Brownlee, Mills, Ruth [Page 14] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 These may be used for threshold reporting or purely as an exception mechanism. The meter senses a threshold condition and spontaneously fires a trap to the network manager, indicating that an exception condition has occurred. The manager should respond by requesting the meter to change rule sets - i.e. to switch to an EMERGENCY RULE SET - and by requesting one or more collectors to retrieve the earlier rule set's usage record (which will allow the meter to discard the completed flow records). It would also be possible for a meter to send flow records as a trap, thereby dumping its current flow records to a collector. If the meter was attempting this as a response to high traffic levels and/or fine granularity of flows, dumping flow records seems likely to exacerbate the situation. This use of traps is therefore not recommended. In any case, the following scenarios must be considered: - A poll or acknowledgment from the collector to the meter is lost, - A message containing usage data from the meter to the collector is lost, or - The meter fills its buffers faster than the collector(s) empty them. POLLING and INTERVAL reporting differ in that POLLING gives control of the precise timing to the COLLECTION host and INTERVAL reporting gives this control to the METER. Either end may want to have this control for load-balancing purposes, but it can't be had by both. SNMP favours POLLING over INTERVAL reporting as a mechanism. The SNMP trap mechanism is available for the meter as a load-balancing emergency mechanism. The collection host should send acknowledgments to the meter anyway, and polls are messages on which acknowledgments can piggyback. The following discussion assumes that a POLLING algorithm is used with TRAPS as an emergency mechanism. The network manager controls the scheduled interval. Therefore the collector and the meter request changes in reporting interval or granularity through their exchanges with the network management entity, and the network management entity arbitrates the default interval and granularity. (Minor or short-term deviations and load spikes are handled through the regular polling and trap mechanisms). Brownlee, Mills, Ruth [Page 15] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Under normal polling conditions the collection host specifies which set of usage records it wants to receive, and the meter provides them. The poll contains an acknowledgment, which the meter may use to flag reported and acknowledged records from its buffers. By using rolling counters in the meters, if a usage report is lost, the next report should contain information on the open flows. The meter's decision as to when an idle (closed) flow may be deleted, and its memory recovered, will depend on a number of parameters set by the manager, including: - The number of collectors (identified by network address) picking up usage records from this meter. - The minimum idle time. A flow is considered inactive if no packets from it are seen for at least this time. - The 'high-water' setting, which specifies a percentage of the meter's available memory. If memory usage rises above the high-water mark the meter should increase its efforts to find idle flows and recover their memory. 4.3 Rolling Counters, Timestamps, and Report-in-One-Bucket-Only Once an usage record is sent the decision needs to be made whether to clear any existing flow records or whether to maintain them and add to the counts when recording subsequent traffic on the same flow. The second method, called rolling counters, is recommended and has several advantages. Its primary advantage is that it provides greater reliability - the system can now often survive the loss of some usage records. The next usage record will very often contain yet another reading of many the same flow buckets which were in the lost usage record. The "continuity" of data provided by rolling counters can also supply information used for "sanity" checks on the data itself, to guard against errors in calculations. The use of rolling counters does introduce a new problem: how to distinguish a follow-on flow record from a new flow record. Consider the following example. CONTINUING FLOW OLD FLOW, then NEW FLOW. start time = 1 start time = 1 Usage record N: flow count=2000 flow count=2000 (done) start time = 1 start time = 5 Brownlee, Mills, Ruth [Page 16] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Usage record N+1: flow count=3000 new flow count = 3000 Total count: 3000 5000 In the continuing flow case, the same flow was reported when its count was 2000, and again at 3000: the total count to date is 3000. In the OLD/NEW case, the old flow had a count of 2000. Its record was then stopped (perhaps because of temporary idleness, or MAX LIFETIME rules), but then more traffic on with the same characteristics came so a new flow record was started and it quickly reached a count of 3000. The total flow count from both the old and new records is 5000. The flow START TIMESTAMP attribute is sufficient to resolve this. In the example above, the CONTINUING FLOW flow record in the second usage record has an old FLOW START timestamp, while the NEW FLOW contains a recent FLOW START timestamp. Each packet is counted in one and only one usage record, so as to avoid multiple counting of a single packet (prevent double billing). The record of a single usage flow is informally called a "bucket." If multiple, sometimes overlapping, records of usage information are required (aggregate, individual, etc), the network manager should collect the counts in sufficiently detailed granularity so that aggregate and combination counts can be reconstructed in post-processing of the raw usage data. For example, consider a meter from which it is required to record both "total packets coming in interface #1" and "total packets arriving from any interface sourced by IP address = a.b.c.d." Although a bucket can be declared for each case, it is not clear how to handle a packet which satisfies both criteria. It must only be counted once. By default it will be counted in the first bucket for which it qualifies, and not in the other bucket. Further, it is not possible to reconstruct this information by post-processing. The solution in this case is to define not two, but THREE buckets, each one collecting a unique combination of the two criteria: Bucket 1: Packets which came in interface 1, AND sourced by IP address a.b.c.d Bucket 2: Packets which came in interface 1, AND NOT sourced by IP address a.b.c.d Bucket 3: Packets which did NOT come in interface 1, AND sourced by IP address a.b.c.d (Bucket 4: Packets which did NOT come in interface 1, AND NOT sourced by IP address a.b.c.d) Brownlee, Mills, Ruth [Page 17] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 The desired information can now be reconstructed by post-processing. "Total packets coming in interface 1" can be found by adding buckets 1 & 2, and "Total packets sourced by IP address a.b.c.d" can be found by adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly required since its information is not of interest, but it is supplied here in parentheses for completeness. 4.4 Exception Conditions Exception conditions are more difficult, particularly when the meter runs out of buffer space. Since, to prevent accounting twice for a single packet, packets can only be counted in a single flow at any given time, discarding records will result in the loss of information. The mechanisms to deal with this are as follows: Meter Outages: In case of impending meter outages (controlled crashes, etc.) the meter should send a trap to the network management system. The manager can then request one or more collectors to pick up the usage record from the meter. Following an uncontrolled meter outage such as a power failure, the meter could send a trap to the network management system indicating that it has restarted. The manager could then download the meter's correct rule set and advise the collector(s) that the meter is running again. Alternatively, the collector may discover from its regular poll that a meter has failed and restarted. It could then advise the manager of this, instead of relying on a trap from the meter. Collector Outages: If the collection system is down or isolated, the meter should try to inform the network management system of its failure to communicate with the collection system. Usage data is maintained in the flows' rolling counters, and can be recovered when the collector is restarted. Management Outages: If the network management system does not appear to be responding, the meter should continue reporting, and the collector(s) should keep gathering usage records. Buffer problems: First, the network manager is informed by trap that there is too much usage data. This can usually be attributed to the interaction between the following controls: Brownlee, Mills, Ruth [Page 18] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 - The reporting interval is too infrequent, - The reporting granularity is too fine, or - The throughput/bandwidth of circuits carrying the usage data is too low. The network manager may change any of these parameters in response to the meter (or collector's) plea for help. The meter may also switch to an emergency rule set to reduce the number of concurrent flows as memory runs out. 4.5 Usage Record Content Description The usage record is described below. Each flow is defined by a list of attribute values, the most important of which are its end-point addresses. These addresses have several components, one or more for each of the network layers. At the link layer there is the ADJACENT address, i.e. the Media Access Control (MAC) address of the host (if it is on the same network segment) or its adjacent ('previous hop' or 'next hop') router. At the network layer we have the PEER address, e.g. IP, CLNP, DECNET, etc. At the transport layer we have the IP port number, AppleTalk port number, etc. Flow are bi-directional, with one set of counters for source-to-destination packets and another for destination-to-source packets. The choice as to which end-point is the 'source' may be determined by the meter's current rule set, or left to the meter to decide. In the latter case the flow's source will usually be the source of the first packet from the flow seen by the meter. The Usage Record has a header containing default values for the flow records within it. Although collection protocols may have varying restrictions on format which make this structure impractical, the data delivered by the collection protocol should be complete enough that the following information can be reconstructed. This organisation of data is selected to illustrate how this architecture can be expanded. UsageRecord ::= SEQUENCE OF FlowRecord -- Data for individual flows FlowRecord ::= SEQUENCE { RuleTab RuleTableID, -- ID of RuleTable in effect FragmentScale INTEGER (1..127), -- Counts divided by 2**n OctetScale INTEGER (1..127), -- Counts divided by 2**n Flow FlowID, Brownlee, Mills, Ruth [Page 19] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Values FlowData } FlowID ::= SEQUENCE { Source AddressList OPTIONAL, -- Must have source, dest Destination AddressList OPTIONAL, -- or both SubscriberID AddressList OPTIONAL -- Other attributes such as TOS (type-of-service) } -- could be added here later -- The address list construct -- In future, might include address for any layer in the protocol -- stack (session, presentation, application) AddressList ::= SEQUENCE { Interface INTEGER OPTIONAL, AdjacentAddress NetWorkAddress OPTIONAL, PeerAddress NetWorkAddress OPTIONAL, TransportAddress TransportAddress OPTIONAL, ApplicationAddress OCTET STRING OPTIONAL, SubscriberId OCTET STRING OPTIONAL } NetWorkAddress ::= CHOICE { MACAddress IMPLICIT OCTET STRING, IPAddress IMPLICIT IPAddress, NSAPAddress IMPLICIT OCTET STRING, IPXAddress IMPLICIT OCTET STRING, DECnetAddress IMPLICIT OCTET STRING } Transport`Address ::= CHOICE { IPPort INTEGER (1..65535) -- For IP flows } FlowData ::= BEGIN acctFlowToOctets Counter, -- Source-to-Dest acctFlowToPDUs Counter, acctFlowFromOctets Counter, -- Dest-to-Sourcce acctFlowFromPDUs Counter, acctFlowFirstTime TimeTicks, acctFlowLastTime TimeTicks } Timeticks :: = CHOICE { [0] TimeTicks -- 1/100s of a second since base time } -- base time since boot time or other base time -- established between meter, manager, and collector Brownlee, Mills, Ruth [Page 20] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 5 Between Management and Meter - Control Functions and Exceptions Because there are a number of parameters that must be set for Internet usage reporting to function properly, and viable settings may change as a result of network traffic characteristics, it is desirable to have dynamic network management, as opposed to static meter configurations. Many of these operations have to do with space tradeoffs - if memory at the meter is exhausted, either the reporting interval must be decreased or a coarser granularity of aggregation must be used so that more data fits into less space. Increasing the reporting interval effectively stores data in the meter; usage data in transit is limited by the effective bandwidth of the virtual link between the meter and the collector, and since these limited network resources are usually also used to carry user data (the purpose of the network), the level of usage reporting traffic should be kept to an affordable fraction of the bandwidth. ("Affordable" is a policy decision made by the network administration). At any rate, it must be understood that the operations below do not represent the setting of independent variables; on the contrary, each of the values set has a direct and measurable effect on the behaviour of the other variables. Network management operations follow: - NETWORK MANAGEMENT and COLLECTOR IDENTIFICATION The network management station should ensure that meters report to the correct set of collection stations, and take steps to prevent unauthorised access to usage information. The collection stations so identified should be prepared to poll if necessary and accept data from the appropriate meters. Alternate collection stations may be identified in case both the primary network management station and the primary collection station are unavailable. Similarly, alternate network management stations may be identified. - REPORTING INTERVAL CONTROL The usual reporting interval should be selected to cope with normal traffic patterns. However, it may be possible for a meter to exhaust its memory during traffic spikes even with a correctly set reporting interval. Some mechanism must be available for the meter to tell the network management station that it is in danger of exhausting its memory (by declaring a "high water" condition), and for the network management station to arbitrate (by decreasing the polling interval, letting nature take its course, or by telling the meter to ask for help sooner next time). - DUMP CONTROL Brownlee, Mills, Ruth [Page 21] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 At some level of buffer usage it may be agreed that usage data is endangered, i.e. may be lost due to lack of memory. In this case, the meter needs to know at what level of buffer usage it should start to send warning traps to the network manager. Since this is a complex calculation which includes bandwidth and delay characteristics of the network, as well as the processing rate of the collector, it is assumed that the network management station is best able to determine the correct algorithm with the help of the meter and collector. A second panic level may result, when the meter actually does run out of buffer space for usage data. In this case, the meter and manager should agree on the action to be taken. Possible actions include changing to an 'emergency' rule set (with coarser granularity than the normal one), and requesting the collector(s) to collect data from the meter immediately so that the old flows can be marked as 'idle' and their memory recovered. - GRANULARITY CONTROL Granularity control is a catch-all for all the parameters that can be tuned and traded to optimise the system's ability to reliably account for and store information on all the traffic (or as close to all the traffic as an administration requires). Granularity - Controls flow-id granularities for each interface, and - Determines the number of buckets into which user traffic will be lumped together. Granularity rules are organised into a tree with decision points at each addressable protocol layer, starting with the physical interface. Each leaf on the decision tree also carries a "category" with it. - FLOW LIFETIME CONTROL Flow termination parameters include timeout parameters for obsoleting inactive flows and removing them from tables and maximum flow lifetimes. This is intertwined with reporting interval and granularity, and must be set in accordance with the other parameters. 5.1 Management to Meter: (polls and control) SET HIGH WATER MARK A percentage value interpreted by the meter which tells the meter when Brownlee, Mills, Ruth [Page 22] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 to send a trap indicating that the meter is running short of free memory. The manager may change the polling frequency, the meter's rule set, or the meter's control parameters (so as to increase the rate at which the meter can recover memory from idle flows). SET FLOW TERMINATION PARAMETERS The meter should have the good sense in situations where lack of resources may cause data loss to purge flow records from its tables. Such records may include: - Flows that have already been reported to all of the current set of collectors, and show no activity since the last report - Oldest flows, or - Flows with the smallest number of unreported packets SET INACTIVITY TIMEOUT This is the time in seconds since the last packet was seen (and last reported) for a flow. After this time the flow may be terminated. SET GRANULARITY [ RULE TABLE ] See RULE TABLE, next section. 5.2 Rule Tables: Granularity Control A rule table is a sequence of numbered rules which describe the granularity at which a meter should count. It is structured to support a "decision tree" hierarchy. For example, some rules can be used at a high-level to identify a large subclass of packets, and other rules can be at a mid-level to further break down the subclass into finer subclasses, and still other rules can be "leaf" rules which actually identify individual flows (buckets). Note that some rule tables will consist of only a few rules (possibly just one) resulting in the definition of only a few flows (buckets). In general, there will be a hierarchy of rules, such that the outcome of matching a particular rule might be to go to yet another rule for further qualification. Brownlee, Mills, Ruth [Page 23] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 5.3 Classification Criteria The information upon which such classifications are made come from two sources; the data fragment (or packet) itself, and the path the fragment travels. The fragment itself specifies: - Address of the packet's source - Network address of the packet's ultimate network destination - Other attributes, such as protocol-used or type-of-service. (These attributes are not supported below but could be added later). The path the packet travelled specifies: - The interface that the packet arrived on - The interface that the packet will leave on - The previous hop router/source address (address from layer n-1) - The next hop router/sink address (address from layer n-1) The rule table, then, provides a way to classify packets according to the above parameters. The rules use a form of "wild card" matching to allow entire "regions of address space," such as an entire source network, to be matched using a single rule. The wild card matching symbol notation is an asterisk (). The rule table includes provisions for matching subroutines which allow a more flexible form of matching. Leaf rules support a feature which allows a single leaf to be expanded into several buckets via a tally (or "individuate") mask. For example, if a leaf rule identifies all packets which arrived from a particular source IP address, rather than count all of those packets into a single bucket, those packets may be subdivided according to which "previous hop" they used. In that case, the tally mask would identify the "destination adjacent address" as the attribute to differentiate on, causing packets with different values in those attributes to be counted in separate buckets. The wild card matching mask, the tally mask, and the ability to provide rule matching subroutines are simply short cuts. The same effect could be achieved without them but the rule table would become extremely large and the number of comparisons required would impact performance. Brownlee, Mills, Ruth [Page 24] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 5.4 Representation of Flow Identification in the Flow Record Once a packet has been classified and is ready to be counted, an appropriate flow record must either already exist or must be created. The flow record has a flexible format where unnecessary identification attributes may be omitted. The determination of which attributes of the flow record to use, and of what values to put in them, is specified by the leaf node of the rule table tree. The leaf rules may contain additional information, such as a subscriber ID, which is to be placed in the attribute section of the usage record. That is, if a particular flow matches the qualifications for the leaf rule, then the corresponding flow record should be marked not only with the qualifying identification attributes, but also with the additional information. Using this feature, several leaf nodes may each carry the same subscriber ID value, such that the resulting usage flow records will each contain the same subscriber ID value which can then be used in post-processing or between collector and meter as a collection criterion. 5.5 Standard Rule Tables Although the rule table is a flexible tool, it can also become very complex. The following list gives examples of rule tables for common applications: - PROTOCOL TYPE: The meter records packets by protocol type. This will be the default rule table for Accounting Meters. - ADJACENT SYSTEMS: The meter records packets by the MAC address of the Adjacent Systems (neighbouring originator or next-hop). (Variants on this table are "report source" or "report sink" only.) This strategy might be used by a regional or backbone network which wants to know how much aggregate traffic flows to or from its subscriber networks. - END SYSTEMS: The meter records packets by the IP address pair contained in the packet. (Variants on this table are "report source" or "report sink" only.) This strategy might be used by an End System network to get detailed host traffic matrix usage data. - TRANSPORT TYPE: The meter records packets by transport address; for IP packets this provides usage information for the various IP services. Brownlee, Mills, Ruth [Page 25] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface report End Systems, for another interface report Adjacent Systems. This strategy might be used by an enterprise network to learn detail about local usage and use an aggregate count for the shared regional network. 5.6 Rule Table Components The rule table is structured to allow decision-tree operations. Each rule begins with the specification of which attribute should be used for this rule's classification test. For example, the selected attribute might be "Source IP address." Each attribute may be further qualified by a corresponding ATTRIBUTE MASK. In this example, the intention might be to restrict the qualification to only look at the top two bytes of the IP address. The attribute mask, then, would contain logical 1's corresponding to the subattributes of interest and 0's otherwise. In this case the attribute mask 255.255.0.0 would be used. Having extracted the appropriate portion of the attribute, the next section of the rule attempts to match the selected attribute against a specified value. If the match succeeds, the rule specifies the action to be taken; another rule may be executed so as to further classify the packet, or it may be counted in a bucket corresponding to the rules which it has matched. If there is no match, then the next sequential rule is evaluated. Note that rule tables will often need to match a given portion of an attribute with a list of possible values. This situation will appear in the rule table as a group of consecutive rules with the same attribute and mask; a meter should recognise this and take steps to optimise its comparisons so as to avoid repeated sequential searches. 5.7 Rule Table Description The rule table is conceptually a table with one row for each rule, whose components are described above. The actions include: - PUSHTO: Record the matching of this rule and switch to another specified rule. - COUNT: Count this packet in the flow identified by the rules which succeeded, and executed pushto actions. - TALLY: This packet belongs to one of a set of flows; a leaf node of the rule table specifies a further masked comparison which will Brownlee, Mills, Ruth [Page 26] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 identify members of the tally set. - AGGREGATE: This packet belongs to a set of flows, the details of which we are not interested in. A leaf node of the rule table specifies the attribute values for a single aggregate flow which includes all members of the aggregate set. - SUCCEED: This packet has been recognised, but is not to be counted. - FAIL: This packet has not been recognised, but the meter may attempt to match it again (see below). The Rule Table is fully specified in the Internet Accounting MIB [4]. In the MIB the leaf nodes for tally and aggregate actions are stored in an ACTION TABLE. Action table entries are used by the meter as prototype flows; for an aggregate action the entry provides values for all the flow attributes, for a tally action it provides masks for distinguishing members of the tally set and values for other attributes. Flow attributes are divided into two groups: 'source' and 'destination' attributes, corresponding to the source and destination fields in packet headers. If, for example, the rules specify a match for Source IP Address = a.b.c.d and Destination IP Address = w.x.y.z, then packets flowing from a.b.c.d to w.x.y.z will be matched. Flows, however, are bi-directional, hence the meter must be able to recognise packets flowing from w.x.y.z to a.b.c.d as part of this flow. One way to do this is to have the meter make several attempts at matching each packet, as follows: - Attempt to match the packet as it appears. If this succeeds, perform the action specified in the rule. - Attempt to match the packet with its 'source' and 'destination' attributes interchanged. If this succeeds, perform the action (remembering that the attributes have been interchanged, hence the destination-to-source counters may be incremented rather than the source-to-destination ones). A more complicated case can occur when a packet is part of a set of tally flows. Consider a tally with Source IP Address = 130.216.*.*, Destination IP Address = 130.216.*.*, and a packet with Source = 130.216.3.1, Destination = 130.216.7.5. When this flow is first seen by the meter, assume it is added to the tally set as 130.216.3.1-to-130.216.7.5. Later, when a return packet is seen, it will be recognised as part of the tally set, but one which hasn't been seen before. The meter should not add such a packet to the tally set at this point, since it might match with its direction reversed. It should be added to the tally set only if it fails the second match. Brownlee, Mills, Ruth [Page 27] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 Caution must be taken to ensure that rule tables map into non-looping trees. A manager should test rule tables to verify their lack of potential loops before downloading them to a meter! 5.8 Meter to Management: (traps and responses) CONTROL PARAMETERS: DECLARE HIGH WATER Trap to inform manager that the meter id running short of memory. Used when number of flows increases unexpectedly. DECLARE FLOOD Trap to inform manager that the meter has so little free memory that it may not be able to create any new flow records, which would therefore not be counted. 6 Between Management and Collector - Control Functions Interactions between the manager and the collector are left in the province of the collection protocol definition. 7 Anticipated Collection Protocols SNMP SNMP provides a convenient way to specify the meter, and to control it. It can also be used to retrieve data from the meter, provided that care is taken by the collector to be sure that every SNMP message sent by the collector produces an acceptable response from the meter. An Internet Accounting Meter Services MIB is described in [4]; in this MIB considerable efforts have been made to provide efficient ways to collect the flow data. The working group recommends that the security services of SNMPv2 be used in conjunction with the MIB, and suggests that a reliable datagram service or transport service be used if and when available. Brownlee, Mills, Ruth [Page 28] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 8 APPENDIX 8.1 Network Characterisation Internet users have extraordinarily diverse requirements. Networks differ in size, speed, throughput, and processing power, among other factors. There is a range of usage reporting capabilities and requirements. For usage reporting purposes, the Internet may be viewed as a continuum which changes in character as traffic passes through the following representative levels: International | Backbones/National --------------- / \ Regional/MidLevel ---------- ---------- / \ \ / / \ Stub/Enterprise --- --- --- ---- ---- ||| ||| ||| |||| |||| End-Systems/Hosts xxx xxx xxx xxxx xxxx Note that mesh architectures can also be built out of these components, and that these are merely descriptive terms. The nature of a single network may encompass any or all of the descriptions below, although some networks can be clearly identified as a single type. BACKBONE networks are typically bulk carriers that connect other networks. Individual hosts (with the exception of network management devices and backbone service hosts) typically are not directly connected to backbones. REGIONAL networks are closely related to backbones, and differ only in size, the number of networks connected via each port, and geographical coverage. Regionals may have directly connected hosts, acting as hybrid backbone/stub networks. A regional network is a SUBSCRIBER to the backbone. STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone networks. END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above networks. Providing a uniform identification of the SUBSCRIBER in finer granularity than that of end-system, (e.g. user/account), is beyond the scope of the current architecture, although an optional attribute in the Brownlee, Mills, Ruth [Page 29] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 usage reporting record may carry system-specific "accountable (billable) party" labels so that meters can implement proprietary or non-standard schemes for the attribution of network traffic to responsible parties. 8.2 Recommended Usage Reporting Capabilities Initial recommended usage reporting conventions are outlined here according to the following Internet building blocks. It is important to understand what complexity reporting introduces at each network level. Whereas the hierarchy is described top-down in the previous section, reporting requirements are more easily addressed bottom-up. End-Systems Stub Networks Enterprise Networks Regional Networks Backbone Networks END-SYSTEMS are currently responsible for allocating network usage to end-users, if this capability is desired. From the Internet Protocol perspective, end- systems are the finest granularity that can be identified without protocol modifications. Even if a meter violated protocol boundaries and tracked higher- level protocols, not all packets could be correctly allocated by user, and the definition of user itself varies too widely from operating system to operating system (e.g. how to trace network usage back to users from shared processes). STUB and ENTERPRISE networks will usually collect traffic data either by end- system network address or network address pair if detailed reporting is required in the local area network. If no local reporting is required, they may record usage information in the exit router to track external traffic only. (These are the only networks which routinely use attributes to perform reporting at granularities finer than end-system or intermediate-system network address.) REGIONAL networks are intermediate networks. In some cases, subscribers will be enterprise networks, in which case the intermediate system network address is sufficient to identify the regional's immediate subscriber. In other cases, individual hosts or a disjoint group of hosts may constitute a subscriber. Then end- system network address pairs need to be tracked for those subscribers. When the source may be an aggregate entity (such as a network, or adjacent router representing traffic from a world of hosts beyond) and the destination is a singular entity (or vice versa), the meter is said to be operating as a HYBRID system. Brownlee, Mills, Ruth [Page 30] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 At the regional level, if the overhead is tolerable it may be advantageous to report usage both by intermediate system network address (e.g. adjacent router address) and by end-system network address or end-system network address pair. BACKBONE networks are the highest level networks operating at higher link speeds and traffic levels. The high volume of traffic will in most cases preclude detailed usage reporting. Backbone networks will usually account for traffic by adjacent routers' network addresses. 9 Acknowledgments This document was produced under the auspices of the IETF's Accounting Working Group with assistance from SNMP and SAAG working groups. 10 References [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian Technology Corporation, November 1991. [2] International Standards Organisation (ISO), "Management Framework," Part 4 of Information Processing Systems Open Systems Interconnection Basic Reference Model, ISO 7498-4, 1994. [3] IEEE 802.3/ISO 8802-3 Information Processing Systems - Local Area Networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2nd edition, September 21, 1990. [4] Brownlee, N., Mills, C. and Ruth, G., "Meter Services MIB" Internet Draft, 'Working draft' to become an RFC. 11 Security Considerations Security issues are not discussed in detail in this document. Brownlee, Mills, Ruth [Page 31] INTERNET-DRAFT Accounting: Usage Reporting Architecture Nov 1994 12 Author's Address Nevil Brownlee The University of Auckland Phone: 64 9 373 7599 x8941 E-mail: n.brownlee @auckland.ac.nz Cyndi Mills BBN Systems and Technologies Phone: 1 617 873 4143 E-mail: cmills@bbn.com Greg Ruth GTE Laboratories, Inc Phone: 1 617 466 2448 E-mail: gruth@gte.com Brownlee, Mills, Ruth [Page 32]