Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland
Cyndi Mills
BBN Systems and Technologies
Greg Ruth
GTE Laboratories, Inc
Mar 1995
Accounting: Usage Reporting Architecture
<draft-brownlee-acct-arch-report-01.txt>
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.
Contents
1 Statement of Purpose and Scope 3
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 . . . . . . . . . . . . . . . . 8
2.7 One METER to multiple COLLECTORs . . . . . . . . . . . . . . . 8
2.8 Between MANAGERs (MANAGER - MANAGER) . . . . . . . . . . . . . 8
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
3 Usage Reporting Components 9
3.1 Meters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Flows and Reporting Granularity . . . . . . . . . . . . . . . . 10
3.3 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 13
4 Meter Services 13
4.1 Between Meter and Collector - Usage Data Transmission . . . . . 14
4.2 Polling, Interval Reporting, Traps . . . . . . . . . . . . . . 15
4.3 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 16
4.4 Rolling Counters, Timestamps, and Report-in-One-Bucket-Only . . 17
4.5 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 18
4.6 Usage Record Content Description . . . . . . . . . . . . . . . 20
5 Between Management and Meter - Control Functions and Exceptions 21
5.1 Management to Meter: (polls and control) . . . . . . . . . . . 23
5.2 Rule Tables: Granularity Control . . . . . . . . . . . . . . . 24
5.3 Classification Criteria . . . . . . . . . . . . . . . . . . . . 24
5.4 Representation of Flow Identification in the Flow Record . . . 25
5.5 Standard Rule Tables . . . . . . . . . . . . . . . . . . . . . 25
5.6 Rule Table Components . . . . . . . . . . . . . . . . . . . . . 26
5.7 Rule Table Description . . . . . . . . . . . . . . . . . . . . 27
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 32
12 Author's Addresses 32
Brownlee, Mills, Ruth [Page 2]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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 Mar 1995
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 Mar 1995
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 Mar 1995
- 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 Mar 1995
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 Mar 1995
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 rule
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 might 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 Mar 1995
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 Mar 1995
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 Mar 1995
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 for the flow, 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 Mar 1995
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 Mar 1995
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
(FLOW REORDS). 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 Mar 1995
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.
In normal operation the meter will be running a rule file which provides
the required degree of flow reporting granularity, and the collector(s)
will collect the flow data often enough to allow the meter's garbage
collector to maintain a stable level of memory usage.
If traffic levels suddenly increase to the point where the the amount of
available flow memory starts to decrease the meter should switch to an
emerggency rule set, which has been designed to provide similar flow
information at a coarser degree of granularity. This should reduce the
rate at which flows are created, allowing the collector to catch up.
The manager should be responsible for determining when traffic levels
have returned to normal, and when to switch back to the normal rule
file.
In the worst case traffic may increase to the point where the meter is
in danger of running completely out of flow memory. The meter
implementor must decide how to handle this, for example by switching to
a default (extremely coarse granularity) rule set, by sending a trap to
the manager, or by attempting dump flow data to the collector.
Users of the Internet Accounting system should analyse their
requirements carefully and assess for themselves whether it is more
important to attempt to collect flow data at normal granularity
(increasing the collection frequency as needed to keep up with traffic
volumes), or to accept flow data with a coarser granularity. Similarly,
it may be acceptable to loose flow data for a short time in return for
being sure that the meter keeps running properly, i.e. is not
overwhelmed by rising traffic levels.
Brownlee, Mills, Ruth [Page 14]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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
may be necessary 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.
- 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
These may be used for threshold reporting or purely as an exception
mechanism. The meter senses a threshold condition and
spontaneously sends a trap to the network manager, indicating that
an exception condition has occurred.
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
Brownlee, Mills, Ruth [Page 15]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
- 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.
4.3 Handling Increasing Traffic Levels
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 (see next section).
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 switch
to an EMERGENCY RULE SET so as to increase the granularity of flow
Brownlee, Mills, Ruth [Page 16]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
collection and decrease the rate at which new flows are created. When
the manager, either as part of a regular poll or via a trap, becomes
aware that the meter is using its emergency rule set, it should decrease
the interval between collections. The meter should also increase its
efforts to recover flow memory so as to reduce the number of of idle
flows in memory. When the situation returns to normal, the manager may
request the meter to switch back to its normal rule set.
4.4 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
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
Brownlee, Mills, Ruth [Page 17]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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)
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.5 Exception Conditions
Exception conditions are more difficult, particularly when the meter
runs out of buffer space. Since, to prevent accounting twice for a
Brownlee, Mills, Ruth [Page 18]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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
could 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:
- 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.
Brownlee, Mills, Ruth [Page 19]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
4.6 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,
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 {
Brownlee, Mills, Ruth [Page 20]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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
}
TransportAddress ::= 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
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
Brownlee, Mills, Ruth [Page 21]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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).
- 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
Brownlee, Mills, Ruth [Page 22]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
"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
to switch to its emergency rule set, so as to increase the granularity
of the flows and conserve the meter's flow memory. Once this has
heppened, the manager may also change the polling frequency or the
meter's control parameters (so as to increase the rate at which the
meter can recover memory from idle flows).
If the high traffic levels persist, the meter's normal rule set may have
to be rewritten to permanently reduce the reporting granularity.
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.
Brownlee, Mills, Ruth [Page 23]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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.
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 ().
Brownlee, Mills, Ruth [Page 24]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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.
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:
Brownlee, Mills, Ruth [Page 25]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
- 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.
- 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
Brownlee, Mills, Ruth [Page 26]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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.
- PUSHPKTTO: Allows the meter to use information from the packet to
differentiate a set of flows. Such a set of flows is referred to
as a set of 'tally' flows. another specified rule.
- COUNT: Count this packet in the flow identified by the rules which
succeeded, and executed pushto or pushpktto actions.
- IGNORE: This packet has been recognised, but is not to be counted.
- RETRY: This packet has not been recognised, but the meter should
attempt to match it again (see below).
The Rule Table is fully specified in the Internet Accounting MIB [4].
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).
Brownlee, Mills, Ruth [Page 27]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
A more complicated case can occur when a packet is part of a set of
tally flows. Consider a tally set 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.
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
has switched to its emergency rule set.
Used when the 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.
Brownlee, Mills, Ruth [Page 28]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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.
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.
Brownlee, Mills, Ruth [Page 29]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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
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
Brownlee, Mills, Ruth [Page 30]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
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.
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., "Meter Services MIB," Internet Draft,
'Working draft' to become an RFC.
Brownlee, Mills, Ruth [Page 31]
INTERNET-DRAFT Accounting: Usage Reporting Architecture Mar 1995
11 Security Considerations
Security issues are not discussed in detail in this document.
12 Author's Addresses
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]