RFC 1272
Internet Accounting: Background
RFC 1272: INTERNET ACCOUNTING: BACKGROUND 🎀
Okay bestie, here are the vitals first 💅. This is RFC 1272, Internet Accounting: Background. C. Mills (BBN), D. Hirsh (Meridian Technology Corporation), and G. Ruth (BBN) wrote it for the Network Working Group, and it's dated November 1991 🗓️. It's purely informational, so it's giving background to the Internet community and doesn't specify an Internet standard 📚. The header doesn't list any RFCs it obsoletes or updates 🦋.
Status of this Memo
Okay so this memo is just here to provide information for the Internet community 💌. It does not specify an Internet standard. Distribution of this memo is unlimited 🌸.
1. Statement of Purpose ✨
This doc gives background for the "Internet Accounting Architecture," and it's the first of a three-doc set 📚:
Internet Accounting Background & Status (this document)
Internet Accounting Architecture (under construction)
Internet Accounting Meter Service (under construction)The main focus right now is defining METER SERVICES and USAGE REPORTING 💖. These give you the basic semantics for measuring network utilization, plus a syntax and a data reporting protocol. The goal is a set of standards that's actually practical for early experiments with usage reporting as an internet accounting mechanism 🧪.
The architecture is meant to be expandable as more experience comes in 🌱. The short-term Internet Accounting solution is supposed to merge with OSI and Autonomous Network Research Group (ANRG) efforts, and in the long term those efforts take over 👑. Meanwhile, the OSI accounting working groups are defining meter syntax and reporting protocols, and the ANRG research group is researching economic models and accounting tools for the Internet environment 🔬.
Internet Accounting as described here does not get into the applications of usage reporting, like monitoring and enforcing network policy. It also doesn't recommend billing approaches, and it doesn't touch the messy stuff like who pays for packet retransmission 🙈.
Basically, this document is background and tutorial info on the issues around the architecture. It's an explanation of the choices made in the Internet Accounting Architecture ✨.
2. Goals for a Usage Reporting Architecture ✨
The team adopted the accounting framework and terminology from OSI (ISO 7498-4 OSI Reference Model Part 4: Management Framework) 🧠. That framework covers a generalized accounting management activity: calculations, usage reporting to users and providers, and enforcing various limits on resource use. Our ambitions are way more modest, honestly 🥺. We're defining an architecture for the short term (until ISO and ANRG have a final pronouncement and standards) that's limited to network USAGE REPORTING only.
The OSI accounting model defines three basic entities 💅:
- the METER, which performs measurements and aggregates the results of those measurements;
- the COLLECTOR, which is responsible for the integrity and security of METER data in short-term storage and transit; and
- the APPLICATION, which processes/formats/stores METER data. APPLICATIONS implicitly manage METERS.
So this working group is focused on specifying the attributes of METERS and COLLECTORS, with little concern for APPLICATIONS at this point 🎯.
3. The Usage Reporting Function ✨
3.1. Motivation for Usage Reporting 💖
Okay, so the dominant motivations for usage reporting are 👑:
- Understanding/Influencing Behavior. Usage reporting gives the subscriber feedback on how they use network resources. The subscriber can understand their network behavior better and measure the impact of changes made to improve performance or cut costs 🦋.
- Measuring Policy Compliance. From the network provider's side, usage reports might show whether a subscriber is following the stated policies on how much network usage they're allowed. Reporting alone isn't enough to enforce compliance, but the reports can show whether it's necessary to build additional enforcement methods 🔍.
- Rational Cost Allocation/Recovery. Economic discipline can penalize inefficient network configuration or utilization, and it can reward the efficient ones too 💸. It can encourage bulk transfers during off hours. It can be a way to allocate operating costs in a zero-sum budget, and it can even be the basis for billing in a profit-making fee-for-service operation 🌈.
The chief deterrent to usage reporting is the cost of measuring usage 😭. That includes:
- Reporting/collection overhead. This adds extra computational load and network traffic from the counting operations, managing the reporting system, collecting the reported data, and storing the resulting counts. The overhead grows as the accounting data gets more accurate and reliable 📈.
- Post-processing overhead. Resources are needed for the post-processing tasks: maintaining the accounting database, generating reports, and, if appropriate, distributing bills, collecting revenue, and servicing subscribers 🧾.
- Security overhead. Using security mechanisms will raise the overall cost of accounting. Accounting collects detailed information about subscriber behavior on the network, and those counts may also represent a flow of money. So it's necessary to have mechanisms that protect accounting information from unauthorized disclosure or manipulation 🔐. This part is so serious, bestie 💀.
The balance between cost and benefit is set by the GRANULARITY of the accounting information collected ⚖️. That balance depends on policy. To keep costs low and benefit high, accounting detail stays limited to the minimum amount needed to provide the information required for researching and implementing a particular policy 🌸.
3.2. Network Policy and Usage Reporting 💅✨
Okay bestie, accounting requirements are driven by policy 📋. But ngl, it works the other way too: policy is usually shaped by what management and reporting tools are available and how much they cost 💸. This section is NOT a recommendation for billing practices 🙅♀️. It's here to give you extra background so you can understand the problems involved in building a simple, adequate usage reporting system 🎀.
Since there are few tools that are adequate for any form of cost recovery and/or long-term monitoring, there are few organizations that practice proactive usage reporting on the Internet 😭. Those that do have generally invented their own. But far and away the most common approach is to treat the cost of network operations as overhead, with network reports limited to short-term, diagnostic intervention 🔧. But as the population and use of the Internet increases and diversifies, the complexity of paying for that usage also increases 📈. Subsidies and funding mechanisms appropriate to non-profit organizations often restrict commercial use or require that "for profit" use be identified and billed separately from the non-profit use 💼. Tax regulations may require verification of network connection or usage 🧾. Some portions of the Internet are distinctly "private", whereas other Internet segments are treated as public, shared infrastructure 🌈.
The number of administrations operating in some connection with the Internet is exploding 🤯. The network "hierarchy" (backbone, regional, enterprise, stub network) is becoming deeper (more levels), increasingly enmeshed (more cross-connections) and more diversified (different charters and usage patterns) 🌸. Each of these administrations has different policies and by-laws about who may use an individual network, who pays for it, and how the payment is determined 📜. Also, each administration balances the OVERHEAD costs of accounting (metering, reporting, billing, collecting) against the benefits of identifying usage and allocating costs ⚖️.
Some members of the Internet community are concerned that the introduction of usage reporting will encourage new billing policies which are detrimental to the current Internet infrastructure (though it is also reasonable to assert that the current lack of usage reporting may be detrimental as well) 🤔. Caution and experimentation must be the watch words as usage reporting is introduced 👀. Well before meters are used for active BILLING and ENFORCEMENT, they should first be used to:
- UNDERSTAND USER BEHAVIOR (learn to quantify and/or predict individual and aggregate traffic patterns over the long term),
- QUANTIFY NETWORK IMPROVEMENTS (measure user and vendor efficiency in how network resources are consumed to provide end-user data transport service) and
- MEASURE COMPLIANCE WITH POLICY.
Accounting policies for network traffic already exist 📚. But they are usually based on network parameters which change seldom, if at all 🐢. Such parameters require little monitoring (the line speed of a physical connection, e.g., Ethernet, 9600 baud, FDDI). The connection to the network is then charged to the subscriber as a FLAT-FEE regardless of the amount of traffic passed across the connection, and is similar to the monthly unlimited local service phone bill 📞.
Usage-insensitive access charges are sufficient in many cases, and can be preferable to usage-based charging in Internet environments, for financial, technical, and social reasons. Sample incentives for the FLAT-FEE billing approach are:
- FINANCIAL: Predictable monthly charges. No overhead costs for counting packets and preparing usage-based reports. 💰
- TECHNICAL: Easing the sharing of resources. Eliminating the headaches of needing another layer of accounting in proxy servers which associate their usage with their clients'. Examples of proxy servers which generate network traffic on behalf of the actual user or subscriber are mail daemons, network file servers, and print spoolers. 🛠️
- SOCIAL: Treating the network as an unregulated public infrastructure with equal access and information sharing. Encouraging public-spirited behavior -- contributing to public mailing lists, information distribution, etc. 🫶
In other cases USAGE-SENSITIVE charges may be preferred or required by a local administration's policy. Government regulations or the wishes of subscribers with low or intermittent traffic patterns may force the issue (note: FLAT FEES are beneficial for heavy network users. USAGE SENSITIVE charges generally benefit the low-volume user). Where usage-sensitive accounting is used, cost ceilings and floors may still be established by static parameters, such as "pipe size" for fixed connections or "connection time" for dial-up connection, to satisfy the need for some predictability 🎯.
Different billing schemes may be employed depending on network measures of distance. For example, local network traffic may be flat-rate and remote internet traffic may be usage-based, analogous to the local and long distance billing policies adopted by the telephone companies 🌍.
The ANRG is independently investigating policy models and infrastructure economics for billing and cost recovery 🔍.
3.3. The Nature of Usage Accounting 🦋
Although the exact requirements for internet usage accounting will vary from one network administration to the next and will depend on policies and cost trade-offs, it is possible to characterize the problem in some broad terms and thereby bound it. Rather than try to solve the problem in exhaustive generality (providing for every imaginable set of accounting requirements), some assumptions about usage accounting are posited in order to make the problem tractable and to render implementations feasible. Since these assumptions form the basis for our architectural and design work, it is important to make them explicit from the outset and hold them up to the scrutiny of the Internet community 🧐.
3.3.1. A Model for Internet Accounting 🧩
We begin with the assumption that there is a "network administrator" or "network administration" to whom internet accounting is of interest. He "owns" and operates some subset of the internet (one or more connected networks) that may be called his "administrative domain". This administrative domain has well defined boundaries.
our domain X
-------------------
/ | | | |
/ | C
/ ------ /
Network A / | \ /
----- (diagonals \___/____
| | | cross admin. domain B
boundaries)The network administrator is interested in 1) traffic within his boundaries and 2) traffic crossing his boundaries. Within his boundaries he may be interested in end-system to end-system accounting or accounting at coarser granularities (e.g., department to department).
The network administrator is usually not interested in accounting for end-systems outside his administrative domain; his primary concern is accounting to the level of other ADJACENT (directly connected) administrative domains. Consider the viewpoint of the administrator for domain X of the internet. The idea is that he will send each adjacent administrative domain a bill (or other statement of accounting) for its use of his resources and it will send him a bill for his use of its resources. When he receives an aggregate bill from Network A, if he wishes to allocate the charges to end users or subsystems within his domain, it is HIS responsibility to collect accounting data about how they used the resources of Network A. If the "user" is in fact another administrative domain, B, (on whose behalf X was using A's resources) the administrator for X just sends his counterpart in B a bill for the part of X's bill attributable to B's usage. If B was passing traffic for C, then B bills C for the appropriate portion of X's charges, and so on, until the charges percolate back to the original end user, say G. Thus, the administrator for X does not have to account for G's usage; he only has to account for the usage of the administrative domains directly adjacent to himself. 🔁
This paradigm of recursive accounting may, of course, be used WITHIN an administrative domain that is (logically) comprised of sub-administrative domains.
The discussion of the preceding paragraphs applies to a general mesh topology, in which any Internet constituent domain may act as a service provider for any connected domain. Although the Internet topology is in fact such a mesh, there is a general hierarchy to its structure and hierarchical routing (when implemented) will make it logically hierarchical as far as traffic flow is concerned. This logical hierarchy permits a simplification of the usage accounting perspective. 🌐
At the bottom of the service hierarchy a service-consuming host sits on one of many "stub" networks. These are interconnected into an enterprise-wide extended LAN, which in turn receives Internet service, typically from a single attachment to a regional backbone. Regional backbones receive national transport services from national backbones such as NSFnet, Alternet, PSInet, CERFnet, NSInet, or Nordunet. In this scheme each level in the hierarchy has a constituency, a group for which usage reporting is germane, in the level underneath it. In the case of the NSFnet the natural constituency, for accounting purposes at least, is the regional nets (MIDnet, SURAnet,...). For the regionals it will be their member institutions; for the institutions, their stub networks; and for the stubs, their individual hosts. 🏫
3.3.2. Implications of the Model 💜
The significance of the model sketched above is that Internet accounting must be able to support accounting for adjacent (intermediate) systems, as well as end-system accounting. Adjacent system accounting information cannot be derived from end-system accounting (even if complete end-system accounting were feasible) because traffic from an end-system may reach the administrative domain of interest through different adjacent domains, and it is the adjacent domain through which it passes that is of interest. Main character energy, fr. 🌈
The need to support accounting for adjacent intermediate systems means that internet accounting will require information not present in internet protocol headers (these headers contain source and destination addresses of end-systems only). This information may come from lower layer protocols (network or link layer) or from configuration information for boundary components (e.g., "what system is connected to port 5 of this IP router"). 🔌✨
4. Meters 🎀
Okay bestie, so a METER is basically a process that watches a stream of packets on a communications medium (or between a pair of media) 👀 and keeps aggregate counts of packets belonging to FLOWs between communicating entities. Those entities can be hosts/processes or aggregations of communicating hosts (domains) 💅. Packets get sorted into flows by running a series of rules. Meters can be built in any of three environments: dedicated monitors, routers, or general-purpose systems 🧚.
Meter location is a huge decision in internet accounting 😭. One big criterion is cost, which means REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST OF IMPLEMENTATION 💸.
Then there's the trade-off between overhead (the cost of accounting) and detail, and ACCURACY and RELIABILITY play a decisive role 🔥. For full accuracy and reliability, EVERY packet must be examined. But if you relax that requirement, statistical sampling may be more practical and sufficiently accurate, and DETAILED ACCOUNTING is not required at all 🌸. Accuracy and reliability requirements may be less stringent when usage reporting is only meant to understand network behavior, for network design and performance tuning, or when it's used to approximate cost allocations to users as a percentage of total fees ✨.
Overhead costs go down when you account at the coarsest acceptable GRANULARITY, meaning you use the greatest amount of AGGREGATION possible. That limits the number of accounting records generated, their size, and how often they're transmitted across the network or otherwise stored 📦.
The other cost factor is implementation 🛠️. Implementation will necessitate developing and introducing hardware and software components into the internet, so it's important to design an architecture that tends to minimize the cost of these new components. Main character architecture, fr 💖.
4.1. Meter Placement 📍
In the model we built above, the Internet may be viewed as a hierarchical system of service providers and their corresponding constituencies 🌈. In this scheme the service provider accounts for the activity of its constituents, or service consumers. Meters should be placed so they allow for optimal data collection for the relevant constituency and technology. They're most needed at administrative boundaries, and the data collected should let the service provider and consumer reconcile their activities 🤝.
Routers (and/or bridges) are, by definition and design, placed topologically at these boundaries, so the most generally convenient spot for accounting meters is in or near the router. But again, this depends on the underlying transport 🚦. Whenever the service-providing network is broadcast (e.g., bus-based) and not extended (i.e., without bridging or routing), meter placement is of no particular consequence 🙈. If you were generating usage reports for a stub LAN, meters could reasonably go in a router, a dedicated monitor, or a host at any point on the LAN. The same observation holds when an enterprise-wide network is a LAN. At the boundary between an enterprise and a regional network, though, in or near a router is an appropriate spot for meters that measure the enterprise's network activity 🏢.
Meters get placed in (or near) routers to count packets at the Internet Protocol Level 🦋. All traffic flows through two natural metering points: hosts and routers (Internet packet switches). Hosts are the ultimate source and sink of all traffic. Routers monitor all traffic which passes IN or OUT of each network. Here's why routers win as metering points 👑:
- Minimization of cost and overhead. (By concentrating the accounting function.) Centralize and minimize in terms of the number of geographical or administrative regions, the number of protocols monitored, and the number of separate implementations modified. (Hosts are too diverse and numerous for easy standardization. Routers concentrate traffic and are more homogeneous.)
- Traffic control. When and if usage sensitive quotas are involved, changes in meter status (e.g., exceeding a quota) would result in an active influence on network traffic (the router starts denying access). A passive measuring device cannot control network access in response to detecting state 🚫.
- Intermediate system accounting. As discussed above, internet accounting includes both end-system and intermediate system accounting. Hosts see only end-system traffic. Routers see both the end-systems (internet source and destination) and the adjacent intermediate systems 🧠.
So, meters should be placed at:
- administrative boundaries, only for measuring inter-domain traffic;
- stub networks, for measuring intra-domain traffic. For intra-domain traffic, the requirement for performing accounting at almost every router is a disincentive for implementing a usage-based charging policy 😬.
4.2. Meter Types 🧩
Four possible types of metering technology are:
- Network monitors: These measure only traffic WITHIN a single network. They include LAN monitors, X.25 call accounting systems and traffic monitors in bridges 📡.
- Line monitors: These count packets flowing across a circuit. They would be placed on inter-router trunks and on router ports 🔌.
- Router-integral meters: These are meters located within a router, implemented in software. They count packets flowing through the router 💻.
- Router spiders: This is a set of line monitors that surround a router, measure traffic on all of its ports and coordinate the results 🕷️.
4.3. Meter Structure 🕸️
While topology argues in favor of meters in routers, granularity and security favor dedicated monitors 🔐. The GRANULARITY of the accountable entity (and its attributes) affects how much overhead accounting creates. Each entity/attribute/reporting interval combination is a separate meter. Each individual meter takes up local memory and requires additional memory or network resources when the meter reports to the application. Memory is a limited resource, and there are cost implications to expanding memory significantly or increasing the frequency of reporting 💸. The number of concurrent flows open in a router is controlled by:
- the granularity of the accountable entity
- the granularity of the attributes and sub-categories of packets
- memory (the number of flows that can be stored concurrently, a limit which can also be expressed as the average number of flows existing at this granularity plus some delta, e.g., peak hour average plus one standard deviation, or ...)
- the reporting interval (the lifetime of an individual meter) ⏳
There's a whole spectrum of granularity control across the following dimensions. (Most administrations will probably choose a granularity somewhere in the middle of the spectrum 🌸.)
ENTITY: Entities range across the spectrum from the coarsest granularity, PORT (a local view with a unique designation for the subscriber port through which packets enter and exit "my" network), through NETWORK and HOST, to USER (not defined here) 🚪. The port is the minimum granularity of accounting. HOST is the finest granularity defined here. Where verification is required, a network should be able to perform accounting at the granularity its subscribers use. Hosts are ultimately responsible for identifying the end user, since only the hosts have unambiguous access to user identification. This information could be shared with the network, but it is the host's responsibility to do so, and there is no mechanism in place at this time (e.g., an IP option, discussed in section 4.) 🙅♀️.
ATTRIBUTE: Each new attribute requires that an additional flow be maintained for each entity. The coarsest granularity is NO categorization of packets. The finest granularity would be to maintain state information about the higher-levels protocols or type of service being used by communicating processes across the network 🔍.
VALUES: Values are the information which is recorded for each entity/attribute grouping. Usually values are counters, such as packet counts and byte counts. They may also be time stamps (start time and stop time), or reasons for starting or stopping reporting 🧾.
REPORTING INTERVAL: At the very finest level of granularity, each data packet might generate a separate accounting record. To report traffic at this level of detail would require approximately one packet of accounting information for every data packet sent. The reporting interval is then zero and no memory will be needed for flow record storage. For a non-zero reporting interval, flow records must be maintained in memory. Storage for stale (old, infrequent) flows may be recycled when their data has been reported. As the reporting interval increases, more and more stale records accumulate 🗂️.
The feasibility of a particular group of granularities varies with the PERFORMANCE characteristics of the network (link speed, link bandwidth, router processing speed, router memory), as well as the COST of accounting balanced against the requirement for DETAIL 🎢. Technological advances can quickly obsolete current technical limitations, and the policy structure and economics of the Internet are still in flux. So meters will be defined with VARYING GRANULARITY, regulated according to the traffic requirements of the individual network or administration and its technical limitations 🌈✨.
4.4. Collection Issues 📥
okay so there are two implicit assumptions about meters and the traffic they measure, and both totally matter for collectors 💅
- The matrix of communicating entity pairs is large but sparse and, moreover, network traffic exhibits considerable source, destination and attribute coherence - so that lists can be quite compact.
- Meters can be configured to generate either a static set of variables whose values are incremented, or a stream of records that must be periodically transferred and removed from the meter's memory.
Meters can generate large, unstructured amounts of information, and the essential collection issue revolves around mapping collection activities into an SNMP framework (or, to the extent that this is not successful, specifying other collection paradigms) 🧚
There are three major collection concerns:
- data confidentiality
- data integrity
- local and remote collection control
The prime security concern is preserving the confidentiality of usage data 🔒 (See ISO 7498 Part 2, "Security Architecture," for security terminology used herein.) Given that accounting data are sensitive, the collector should be able (or may be required) to provide confidentiality for accounting data at the point of collection, through transmission and up to the point where the data is delivered. The delivery function may also require authentication of the origin and destination and provision for connection integrity (if connections are utilized). Other security services (e.g., measures to counter denial of service attacks) are not deemed necessary for internet accounting at this time. It is assumed that security services can be provided by SNMP and its mechanisms. (This will require further investigation.) 🫶
In order to have an accurate monitoring system, reliable delivery of data should be assured through one or more of:
- an acknowledgement retransmission scheme;
- redundant reporting to multiple collectors;
- having backup storage located at the meter.
There is a place for both application polling and meter traps within this scheme, but there are significant trade-offs associated with each 🤔
Polling means that the collection point has some control over when accounting data is sent, so that not all meters flood the collector at once. However, polling messages, particularly when structured with SNMP's GET-NEXT operator, add considerable overhead to the network. Meter traps are required in any case (whether or not polling is the preferred collection method), so that a meter may rid itself of data when its cache is full 🗑️
The fundamental collection trade-off will be between primary and secondary storage at the meter, coupled with an efficient bulk-transfer protocol, versus minimal storage at the meter and a network-bandwidth-consuming collection discipline. It's giving big decision energy 👑
A final collection concern is whether packets should be counted on entry into a router or upon exit from a router. It is the nature of IP that not every packet received by a router is actually passed to an output port. The Internet Protocol allows routers to discard packets (e.g., in times of congestion when the router cannot handle the offered load); it is presumed that higher level protocols (e.g., TCP) will provide whatever reliable delivery service the user deems necessary (by detecting non-delivery and retransmitting) 🔁
The question arises, therefore, whether an internet accounting system should count all packets offered to a router (since each packet offered consumes some router resources) or just those that are finally passed by the router to a network (why should a user pay for undelivered packets?) 🤷♀️ Since there are good arguments for either position, we do not attempt to resolve this issue here. (It should be noted, however, that SMDS has chosen to count on exit only.) Rather, we require that an internet accounting should provide ability for counting packets either way -- on entry to or on exit from a router. Both sides get a seat at the table ✨
5. Examples ✨
Here follows a series of examples to illustrate what data may be of interest to service providers and consumers in a number of different scenarios. In the illustrations that follow, straight lines are interpreted as some sort of LAN. Diagonals are point-to-point links. Diamonds are routers. We assume that we are in a homogeneous protocol environment (IP) 🎀
5.1. A Single Segment LAN
Consumers and providers on a single LAN service can utilize the same set of data: the contribution of individual hosts to total network load. A network accounting system measures flows between individual host pairs. (On a broadcast LAN, e.g., an Ethernet, this can be accomplished by a single meter placed anywhere on the LAN.) Using this data, costs for the network management activity can be apportioned to individual hosts or the departments that own/manage the hosts 🧾
Alternately, flows can be kept by source only, rather than source-destination pairs.
5.2. An Extended (Campus or Facility-Wide) LAN 🏫
128.252.100.X 128.252.150.X 128.253.220.X
+----------------+ +----------------+ +----------------+
| | |
| | |
/ \ / \ / \
128.252.100.10 128.252.150.10 128.253.220.10
\ / \ / \ /
| | |
+--+-+----------------------+-+----------------------+-+-+
| | |
/ \ / \ / \
128.252.130.10 128.252.120.10 128.253.140.10
\ / \ / \ /
| | |
| | |
+-----------------+ +-----------------+ +----------------+
128.252.130.X 128.252.120.X 128.253.140.XThis is the first example in which the information that is germane for service provider and consumer are not identical. The service consumers are now the individual subnets and the service provider is the facility-wide backbone. A service provider is interested in knowing the contribution of individual subnets to the total traffic of the backbone. In order to ascertain this, a meter on the backbone (the longest line in the center of the illustration) can keep track of flows between subnet pairs. Now the communications between individual hosts on adjacent subnets are aggregated into a single flow that measures activity between subnets 🌈
The service consumers, or subnets, might in turn want to keep track of the communications between individual hosts that use the services of the backbone. An accounting system on the backbone could be configured to monitor traffic among individual host pairs. Alternately, an accounting system on each individual subnet could keep track of local and "non-local" traffic. The observed data of the two sets of meters (one for the service provider and one for the service consumers) should have reconcilable data 🧩
5.3. A Regional Network 🌍
116.125
+-----------------+
|
+
/ \
116.125.10.10
\ /
/ + \
/ \
/ \
/ \
| + + |
| / \ / \ |
128.242 |----- 128.242.10.10 128.252.10.10 -----| 128.252
| \ / \ / |
| + + |
\ /
\ /
\ /
\ + /
/ \
124.110.10.10
\ /
+
+-----------------+
|
124.110In this example we have a regional network consisting of a ring of point-to-point links that interconnect a collection of campus-wide LANs. Again, service provider and consumer have differing interests and needs for accounting data. The service provider, the regional network, again will be interested in the contribution of each individual network to the total traffic on the regional network. This interest might extend to include measure of individual link utilization, and not just total offered load to the network as a whole. In this latter case the service provider will require that meters be placed at one end or the other on each link. For the service consumer, the individual campus, relevant measures would include the contribution of individual subnets or hosts to the total "outbound" traffic. Meter(s) placed in (or at) the router that connects the campus network to the regional network can perform the necessary measurement 🦋
5.4. A National Backbone 🇺🇸✨
Here's the big national picture 🗺️
__________
|
+
| / \ |
|--+ 1 +--|
| \ / |
+
/ \
\ /
/ + \
/ \
_______ / \ _______
| / \ |
+ + + +
| / \ / \ / \ / \ |
|--+ 4 +----\ / 5 \ /-----+ 2 +-|
| \ / + + \ / |
+ \ / +
___|____ \ / ___|____
\ /
\ + /
/ \
\ /
+
| / \ |
|--+ 3 +--|
| \ / |
+
____|____Okay so in this last case, the data the service provider wants to collect is the traffic between regional networks 💅 A flow that measures a regional network (or a pair of them) is the union of all its member campus network address spaces. You can get there two ways. Option one: keep a bunch of separate network address flows and build the regional number as post-processing. Option two: define one flow that's the union of all the relevant addresses from the start. (It's a cpu cycles for memory trade-off, so pick your fighter 🧠)
Also, if the service provider measures each network's contribution individually, that data is, like, mostly the data the service consumers would want anyway ✨
6. Future Issues 🔮
This last section is the junk drawer 🗂️ for ancillary issues that are either still undefined or out of current scope.
APPLICATIONS standards: storage, processing, and reporting recommendations are left out for the moment 🙅♀️ How accounting info gets stored and processed depends on each network's own policy. And standardizing billing schemes would be premature, so not yet, bestie 💅
QUOTAS are a form of closed loop feedback, and ngl they're a super interesting extension of usage reporting 🤩 But they have to wait until the basic accounting technology is reasonably defined and has had a reasonable amount of experimentation.
SESSION ACCOUNTING: detailed auditing of individual sessions across the internet (at level four or higher) is not going to be addressed by internet accounting. It only deals with measuring traffic at the IP level 📡
APPLICATION LEVEL ACCOUNTING: service hosts and proxy agents have to do their own accounting for services, because the network can't tell on whose behalf they're acting 🫠 Alternately, TCP/UDP port numbers could become an optional field in a meter. Why? Because a pair of IP addresses plus port numbers occurring at a particular time uniquely identifies a pair of communicating processes 🎯
The USER hasn't been defined yet 🫣 since that would need a new IP option added to the IP header. This option would probably have two parts: a subscriber identification and a user sub-identification, so later quota mechanisms can have both group and individual quotas. The subscriber is the fiscally responsible entity, like the manager of a research group 💼 Either way, routers must be able to fall back to accounting by host, because there will most certainly be hosts that don't implement a new IP option in a timely fashion 💀
7. References 📚
International Standards Organization (ISO), "Management Framework," Part 4 of Information Processing Systems Open Systems Interconnection Basic Reference Model,ISO 7498-4, 1984.
International Standards Organization (ISO), "Security Architecture," Part 2 of Information Processing Systems Open Systems Interconnection Basic Reference Model,ISO 7498-2, 1984.
Security Considerations 🔐
Security is a big deal here, bestie 😭 Security issues are discussed in sections 2, 3 and 4, so go re-read those and take notes 📝
Authors' Addresses 💌
Cyndi Mills
Bolt, Beranek, and Newman
150 Cambridge Park Drive
Cambridge, MA 02140
Phone: 617-873-4143
Email: cmills@bbn.com
Donald Hirsh
Meridian Technology Corporation
11 McBride Corporate Center Drive
Suite 250
Chesterfield, MO 63005
Phone: 314-532-7708
Email: hirsh@meridian.uucp
Gregory Ruth
Bolt, Beranek, and Newman
150 Cambridge Park Drive
Cambridge, MA 02140
Phone: 617-873-3150
Email: gruth@bbn.com📦 where this page comes from
- ietf: rfc1272 1991-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms