As per Relevance of the word reporting, we have this rfc below:
Network Working Group C.
Request for Comments: 1272
D.
Meridian Technology
G.
November 1991
INTERNET ACCOUNTING:
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
1. Statement of
This document provides background information for the "
Accounting Architecture" and is the first of a three document set
Internet Accounting Background & Status (this document
Internet Accounting Architecture (under construction
Internet Accounting Meter Service (under construction
The focus at this time is on defining METER SERVICES and
REPORTING which provide basic semantics for measuring
utilization, a syntax, and a data reporting protocol. The intent
to produce a set of standards that is of practical use for
experimentation with usage reporting as an internet
mechanism
The architecture should be expandable as additional experience
gained. The short-term Internet Accounting solution is intended
merge with OSI and Autonomous Network Research Group (ANRG)
and be superseded by those efforts in the long term. The
accounting working groups are currently defining meter syntax
reporting protocols. The ANRG research group is
researching economic models and accounting tools for the
environment
Internet Accounting as described here does not wrestle with
applications of usage reporting, such as monitoring and
network policy; nor does it recommend approaches to billing or
such thorny issues as who pays for packet retransmission
This document provides background and tutorial information on
Mills, Hirsh, & Ruth [Page 1]
RFC 1272 Internet Accounting: Background November 1991
surrounding the architecture, or in a sense, an explanation
choices made in the Internet Accounting Architecture
2. Goals for a Usage Reporting
We have adopted the accounting framework and terminology used by
(ISO 7498-4 OSI Reference Model Part 4: Management Framework).
framework defines a generalized accounting management activity
includes calculations, usage reporting to users and providers
enforcing various limits on the use of resources. Our own
are considerably more modest in that we are defining an
to be used over the short- term (until ISO and ANRG have
pronouncement and standards) that is limited to network
REPORTING
The OSI accounting model defines three basic entities
1) the METER, which performs measurements and aggregates
results of those measurements
2) the COLLECTOR, which is responsible for the integrity
security of METER data in short-term storage and transit
3) the APPLICATION, which processes/formats/stores
data. APPLICATIONS implicitly manage METERS
This working group, then, is concerned with specifying the
of METERS and COLLECTORS, with little concern at this time
APPLICATIONS
3. The Usage Reporting
3.1. Motivation for Usage
The dominant motivations for usage reporting are
o Understanding/Influencing Behavior
Usage reporting provides feedback for the subscriber
his use of network resources. The subscriber can
understand his network behavior and measure the impact
modifications made to improve performance or
costs
o Measuring Policy Compliance
From the perspective of the network provider,
reports might show whether or not a subscriber is
compliance with the stated policies for quantity
Mills, Hirsh, & Ruth [Page 2]
RFC 1272 Internet Accounting: Background November 1991
network usage. Reporting alone is not sufficient
enforce compliance with policies, but reports
indicate whether it is necessary to develop
methods of enforcement
o Rational Cost Allocation/Recovery
Economic discipline can be used to penalize
network configuration/utilization as well as to
the efficient. It can be used to encourage bulk
at off hours. It can be used as a means to
operating costs in a zero-sum budget, and even be used
the basis for billing in a profit-making fee-for-
operation
The chief deterrent to usage reporting is the cost of
usage, which includes
o Reporting/collection overhead
This offers an additional source of computational
and network traffic due to the counting operations
managing the reporting system, collecting the
data, and storing the resulting counts.
increases with the accuracy and reliability of
accounting data
o Post-processing overhead
Resources are required to maintain the post-
tasks of maintaining the accounting database,
reports, and, if appropriate, distributing bills
collecting revenue, servicing subscribers
o Security overhead
The use of security mechanisms will increase the
cost of accounting. Since accounting collects
information about subscriber behavior on the network
since these counts may also represent a flow of money,
is necessary to have mechanisms to protect
information from unauthorized disclosure or manipulation
The balance between cost and benefit is regulated by the
of accounting information collected. This balance is policy
dependent. To minimize costs and maximize benefit, accounting
is limited to the minimum amount to provide the necessary
for the research and implementation of a particular policy
Mills, Hirsh, & Ruth [Page 3]
RFC 1272 Internet Accounting: Background November 1991
3.2. Network Policy and Usage
Accounting requirements are driven by policy. Conversely, policy
typically influenced by the available management/reporting tools
their cost. This section is NOT a recommendation for
practices, but intended to provide additional background
understanding the problems involved in implementing a simple
adequate usage reporting system
Since there are few tools adequate for any form of cost
and/or long-term monitoring there are few organizations that
proactive usage reporting in the Internet. Those that do
generally invented their own. But far and away the most
approach is to treat the cost of network operations as overhead
network reports limited to short-term, diagnostic intervention.
as the population and use of the Internet increases and diversifies
the complexity of paying for that usage also increases.
and funding mechanisms appropriate to non-profit organizations
restrict commercial use or require that "for profit" use
identified and billed separately from the non-profit use.
regulations may require verification of network connection or usage
Some portions of the Internet are distinctly "private", whereas
Internet segments are treated as public, shared infrastructure
The number of administrations operating in some connection with
Internet is exploding. The network "hierarchy" (backbone, regional
enterprise, stub network) is becoming deeper (more levels),
increasingly enmeshed (more cross-connections) and more
(different charters and usage patterns). Each of
administrations has different policies and by-laws about who may
an individual network, who pays for it, and how the payment
determined. Also, each administration balances the OVERHEAD costs
accounting (metering, reporting, billing, collecting) against
benefits of identifying usage and allocating costs
Some members of the Internet community are concerned that
introduction of usage reporting will encourage new billing
which are detrimental to the current Internet infrastructure (
it is also reasonable to assert that the current lack of
reporting may be detrimental as well). Caution and
must be the watch words as usage reporting is introduced.
before meters are used for active BILLING and ENFORCEMENT,
should first be used to
o UNDERSTAND USER
(learn to quantify and/or predict individual
aggregate traffic patterns over the long term),
Mills, Hirsh, & Ruth [Page 4]
RFC 1272 Internet Accounting: Background November 1991
o QUANTIFY NETWORK IMPROVEMENTS
(measure user and vendor efficiency in how
resources are consumed to provide end-user data
service)
o MEASURE COMPLIANCE WITH POLICY
Accounting policies for network traffic already exist. But they
usually based on network parameters which change seldom, if at all
Such parameters require little monitoring (the line speed of
physical connection, e.g.,Ethernet, 9600 baud, FDDI). The
to the network is then charged to the subscriber as a FLAT-
regardless of the amount of traffic passed across the connection
is similar to the monthly unlimited local service phone bill
Usage-insensitive access charges are sufficient in many cases,
can be preferable to usage-based charging in Internet environments
for financial, technical, and social reasons. Sample incentives
the FLAT-FEE billing approach are
o FINANCIAL
Predictable monthly charges. No overhead costs
counting packets and preparing usage-based reports
o TECHNICAL
Easing the sharing of resources. Eliminating
headaches of needing another layer of accounting in
servers which associate their usage with their clients'.
Examples of proxy servers which generate network
on behalf of the actual user or subscriber are
daemons, network file servers, and print spoolers
o SOCIAL
Treating the network as an unregulated
infrastructure with equal access and information sharing
Encouraging public-spirited behavior -- contributing
public mailing lists, information distribution, etc
In other cases USAGE-SENSITIVE charges may be preferred or
by a local administration's policy. Government regulations or
wishes of subscribers with low or intermittent traffic patterns
force the issue (note: FLAT FEES are beneficial for heavy
users. USAGE SENSITVE charges generally benefit the low-
user). Where usage-sensitive accounting is used, cost ceilings
floors may still be established by static parameters, such as "
size" for fixed connections or "connection time" for dial-
connection, to satisfy the need for some predictability
Mills, Hirsh, & Ruth [Page 5]
RFC 1272 Internet Accounting: Background November 1991
Different billing schemes may be employed depending on
measures of distance. For example, local network traffic may
flat-rate and remote internet traffic may be usage-based,
to the local and long distance billing policies adopted by
telephone companies
The ANRG is independently investigating policy models
infrastructure economics for billing and cost recovery
3.3. The Nature of Usage
Although the exact requirements for internet usage accounting
vary from one network administration to the next and will depend
policies and cost trade-offs, it is possible to characterize
problem in some broad terms and thereby bound it. Rather than try
solve the problem in exhaustive generality (providing for
imaginable set of accounting requirements), some assumptions
usage accounting are posited in order to make the problem
and to render implementations feasible. Since these assumptions
the basis for our architectural and design work, it is important
make them explicit from the outset and hold them up to the
of the Internet community
3.3.1. A Model for Internet
We begin with the assumption that there is a "network administrator
or "network administration" to whom internet accounting is
interest. He "owns" and operates some subset of the internet (one
more connected networks)that may be called his "
domain". This administrative domain has well defined boundaries
our domain
-------------------
/ | | | |
/ |
/ ------ /
Network A / | \ /
----- (diagonals \___/____
| | | cross admin. domain
boundaries
The network administrator is interested in 1) traffic within
boundaries and 2) traffic crossing his boundaries. Within
boundaries he may be interested in end-system to end-
accounting or accounting at coarser granularities (e.g.,
to department).
Mills, Hirsh, & Ruth [Page 6]
RFC 1272 Internet Accounting: Background November 1991
The network administrator is usually not interested in accounting
end-systems outside his administrative domain; his primary concern
accounting to the level of other ADJACENT (directly connected
administrative domains. Consider the viewpoint of the
for domain X of the internet. The idea is that he will send
adjacent administrative domain a bill (or other statement
accounting) for its use of his resources and it will send him a
for his use of its resources. When he receives an aggregate
from Network A, if he wishes to allocate the charges to end users
subsystems within his domain, it is HIS responsibility to
accounting data about how they used the resources of Network A.
the "user" is in fact another administrative domain, B, (on
behalf X was using A's resources) the administrator for X just
his counterpart in B a bill for the part of X's bill attributable
B's usage. If B was passing traffic for C, them B bills C for
appropriate portion X's charges, and so on, until the
percolate back to the original end user, say G. Thus,
administrator for X does not have to account for G's usage; he
has to account for the usage of the administrative domains
adjacent to himself
This paradigm of recursive accounting may, of course, be used
an administrative domain that is (logically) comprised of sub
administrative domains
The discussion of the preceding paragraphs applies to a general
topology, in which any Internet constituent domain may act as
service provider for any connected domain. Although the
topology is in fact such a mesh, there is a general hierarchy to
structure and hierarchical routing (when implemented) will make
logically hierarchical as far as traffic flow is concerned.
logical hierarchy permits a simplification of the usage
perspective
At the bottom of the service hierarchy a service-consuming host
on one of many "stub" networks. These are interconnected into
enterprise-wide extended LAN, which in turn receives
service, typically from a single attachment to a regional backbone
Regional backbones receive national transport services from
backbones such as NSFnet, Alternet, PSInet, CERFnet, NSInet,
Nordunet. In this scheme each level in the hierarchy has
constituency, a group for which usage reporting is germane, in
level underneath it. In the case of the NSFnet the
constituency, for accounting purposes at least, is the regional
(MIDnet, SURAnet,...). For the regionals it will be their
institutions; for the institutions, their stub networks; and for
stubs, their individual hosts
Mills, Hirsh, & Ruth [Page 7]
RFC 1272 Internet Accounting: Background November 1991
3.3.2. Implications of the
The significance of the model sketched above is that
accounting must be able to support accounting for
(intermediate) systems, as well as end-system accounting.
system accounting information cannot be derived from end-
accounting (even if complete end-system accounting were feasible
because traffic from an end-system may reach the
domain of interest through different adjacent domains, and it is
adjacent domain through which it passes that is of interest
The need to support accounting for adjacent intermediate
means that internet accounting will require information not
in internet protocol headers (these headers contain source
destination addresses of end-systems only). This information
come from lower layer protocols (network or link layer) or
configuration information for boundary components (e.g., "what
is connected to port 5 of this IP router").
4.
A METER is a process which examines a stream of packets on
communications medium or between a pair of media. The meter
aggregate counts of packets belonging to FLOWs between
entities (hosts/processes or aggregations of communicating
(domains)). The assignment of packets to flows may be done
executing a series of rules. Meters can reasonably be implemented
any of three environments -- dedicated monitors, in routers or
general-purpose systems
Meter location is a critical decision in internet accounting.
important criterion for selecting meter location is cost, i.e.,
REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST
IMPLEMENTATION
In the trade-off between overhead (cost of accounting) and detail
ACCURACY and RELIABILITY play a decisive role. Full accuracy
reliability for accounting purposes require that EVERY packet must
examined. However, if the requirement for accuracy and
is relaxed, statistical sampling may be more practical
sufficiently accurate, and DETAILED ACCOUNTING is not required
all. Accuracy and reliability requirements may be less
when the purpose of usage-reporting is solely to understand
behavior, for network design and performance tuning, or when
reporting is used to approximate cost allocations to users as
percentage of total fees
Overhead costs are minimized by accounting at the coarsest
Mills, Hirsh, & Ruth [Page 8]
RFC 1272 Internet Accounting: Background November 1991
GRANULARITY, i.e., using the greatest amount of AGGREGATION
to limit the number of accounting records generated, their size,
the frequency with which they are transmitted across the network
otherwise stored
The other cost factor lies in implementation. Implementation
necessitate the development and introduction of hardware and
components into the internet. It is important to design
architecture that tends to minimize the cost of these new components
4.1. Meter
In the model developed above, the Internet may be viewed as
hierarchical system of service providers and their
constituencies. In this scheme the service provider accounts for
activity of the constituents or service consumers. Meters should
placed to allow for optimal data collection for the
constituency and technology. Meters are most needed
administrative boundaries and data collected such that
provider and consumer are able to reconcile their activities
Routers (and/or bridges) are by definition and design
(topologically) at these boundaries and so it follows that the
generally convenient place to position accounting meters is in
near the router. But again this depends on the underlying transport
Whenever the service-providing network is broadcast (e.g., bus
based), not extended (i.e., without bridging or routing), then
placement is of no particular consequence. If one were
usage reports for a stub LAN, meters could reasonably be placed in
router, a dedicated monitor, or a host at any point on the LAN
Where an enterprise-wide network is a LAN, the same
holds. At the boundary between an enterprise and a regional network
however, in or near a router is an appropriate location for
that will measure the enterprise's network activity
Meters are placed in (or near) routers to count packets at
Internet Protocol Level. All traffic flows through two
metering points: hosts and routers (Internet packet switches).
are the ultimate source and sink of all traffic. Routers monitor
traffic which passes IN or OUT of each network. Motivations
selecting the routers as the metering points are
o Minimization of cost and overhead
(by concentrating the accounting function).
and minimize in terms of number of geographical
administrative regions, number of protocols monitored
and number of separate implementations modified. (
are too diverse and numerous for easy standardization
Mills, Hirsh, & Ruth [Page 9]
RFC 1272 Internet Accounting: Background November 1991
Routers concentrate traffic and are more homogeneous.)
o Traffic control
When and if usage sensitive quotas are involved,
in meter status (e.g., exceeding a quota) would result
an active influence on network traffic (the router
denying access). A passive measuring device
control network access in response to detecting state
o Intermediate system accounting
As discussed above, internet accounting includes
end-system and intermediate system accounting. Hosts
only end-system traffic; routers see both the end-
(internet source and destination) and the
intermediate systems
Therefore, meters should be placed at
o administrative
only for measuring inter-domain traffic
o stub
for measuring intra-domain traffic. For intra-
traffic, the requirement for performing accounting
almost every router is a disincentive for implementing
usage-based charging policy
4.2. Meter
Four possible types of metering technology are
o Network monitors
These measure only traffic WITHIN a single network.
include LAN monitors, X.25 call accounting systems
traffic monitors in bridges
o Line monitors
These count packets flowing across a circuit. They
be placed on inter-router trunks and on router ports
o Router-integral meters
These are meters located within a router, implemented
software. They count packets flowing through the router
o Router spiders
This is a set of line monitors that surround a router
measure traffic on all of its ports and coordinate
results
Mills, Hirsh, & Ruth [Page 10]
RFC 1272 Internet Accounting: Background November 1991
4.3. Meter
While topology argues in favor of meters in routers, granularity
security favor dedicated monitors. The GRANULARITY of
accountable entity (and its attributes) affects the amount
overhead incurred for accounting. Each entity/attribute/
interval combination is a separate meter. Each individual
takes up local memory and requires additional memory or
resources when the meter reports to the application. Memory is
limited resource, and there are cost implications to expanding
significantly or increasing the frequency of reporting. The
of concurrent flows open in a router is controlled
o the granularity of the accountable
o the granularity of the attributes and sub-categories
o
(the number of flows that can be stored concurrently,
limit which can also be expressed as the average
of flows existing at this granularity plus some delta
e.g., peak hour average plus one standard deviation,
...)
o the reporting
(the lifetime of an individual meter
There is a spectrum of granularity control which ranges
the following dimensions. (Most administrations will
choose a granularity somewhere in the middle of the spectrum.)
ENTITY: Entities range across the spectrum from the
granularity, PORT (a local view with a unique designation for
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
finest granularity defined here. Where verification is required
a network should be able to perform accounting at the
its subscribers use. Hosts are ultimately responsible
identifying the end user, since only the hosts have
access to user identification. This information could be
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
option, discussed in section 4.).
ATTRIBUTE: Each new attribute requires that an additional
be maintained for each entity. The coarsest granularity is
Mills, Hirsh, & Ruth [Page 11]
RFC 1272 Internet Accounting: Background November 1991
categorization of packets. The finest granularity would be
maintain state information about the higher-levels protocols
type of service being used by communicating processes across
network
VALUES: Values are the information which is recorded for
entity/attribute grouping. Usually values are counters, such
packet counts and byte counts. They may also be time stamps -
start time and stop time, or reasons for starting or
reporting
REPORTING INTERVAL: At the very finest level of granularity
each data packet might generate a separate accounting record.
report traffic at this level of detail would
approximately one packet of accounting information for every
packet sent. The reporting interval is then zero and no
will be needed for flow record storage. For a non-zero
interval flow records must be maintained in memory. Storage
stale (old, infrequent) flows may be recycled when their data
been reported. As the reporting interval increases, more
more stale records accumulate
The feasibility of a particular group of granularities
with the PERFORMANCE characteristics of the network (link speed
link bandwidth, router processing speed, router memory), as
as the COST of accounting balanced against the requirement
DETAIL. Since technological advances can quickly
current technical limitations, and since the policy structure
economics of the Internet are in flux, meters will be
with VARYING GRANULARITY which is regulated according to
traffic requirements of the individual network or
and technical limitations
4.4. Collection
There are two implicit assumptions about the nature of meters
traffic sources that they measure, both of which have
bearing on collectors
1. The matrix of communicating entity pairs is large
sparse and, moreover, network traffic exhibits
source, destination and attribute coherence - so that
can be quite compact
2. Meters can be configured to generate either a static
of variables whose values are incremented, or a stream
records that must be periodically transferred and
from the meter's memory
Mills, Hirsh, & Ruth [Page 12]
RFC 1272 Internet Accounting: Background November 1991
Meters can generate large, unstructured amounts of
and the essential collection issue revolves around
collection activities into an SNMP framework (or, to the
that this is not successful, specifying other
paradigms).
There are three major collection concerns
o data
o data
o local and remote collection
The prime security concern is preserving the confidentiality of
data. (See ISO 7498 Part 2, "Security Architecture," for
terminology used herein.) Given that accounting data are sensitive
the collector should be able (or may be required) to
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
and destination and provision for connection integrity (
connections are utilized). Other security services (e.g.,
to counter denial of service attacks) are not deemed necessary
internet accounting at this time. It is assumed that
services can be provided by SNMP and its mechanisms. (This
require further investigation.)
In order to have an accurate monitoring system, reliable delivery
data should be assured through one or more of
o an acknowledgement retransmission scheme
o redundant reporting to multiple collectors
o having backup storage located at the meter
There is a place for both application polling and meter traps
this scheme, but there are significant trade-offs associated
each
Polling means that the collection point has some control over
accounting data is sent, so that not all meters flood the
at once. However, polling messages, particularly when
with SNMP's GET-NEXT operator, add considerable overhead to
network. Meter traps are required in any case (whether or
polling is the preferred collection method), so that a meter may
itself of data when its cache is full
Mills, Hirsh, & Ruth [Page 13]
RFC 1272 Internet Accounting: Background November 1991
The fundamental collection trade-off will be between primary
secondary storage at the meter, coupled with an efficient bulk
transfer protocol, versus minimal storage at the meter and
network-bandwidth-consuming collection discipline
A final collection concern is whether packets should be counted
entry into a router or upon exit from a router. It is the nature
IP that not every packet received by a router is actually passed
an output port. The Internet Protocol allows routers to
packets (e.g., in times of congestion when the router cannot
the offered load); it is presumed that higher level protocols (e.g.,
TCP) will provide whatever reliable delivery service the user
necessary (by detecting non- delivery and retransmitting).
The question arises, therefore, whether an internet accounting
should count all packets offered to a router (since each
offered consumes some router resources) or just those that
finally passed by the router to a network (why should a user pay
undelivered packets?) Since there are good arguments for
position, we do not attempt to resolve this issue here. (It
be noted, however, that SMDS has chosen to count on exit only.)
Rather, we require that an internet accounting should provide
for counting packets either way -- on entry to or on exit from
router
5.
Here follows a series of examples to illustrate what data may be
interest to service providers and consumers in a number of
scenarios. In the illustrations that follow straight lines
interpreted as some sort of LAN. Diagonals are point- to-
links. Diamonds are routers. We assume that we are in a
protocol environment (IP).
5.1 A Single Segment
Consumers and providers on a single LAN service can utilize the
set of data: the contribution of individual hosts to total
load. A network accounting system measures flows between
host pairs. (On a broadcast LAN, e.g., an Ethernet, this can
accomplished by a single meter placed anywhere on the LAN.)
this data, costs for the network management activity can
apportioned to individual hosts or the departments that own/
the hosts
Alternately, flows can be kept by source only, rather than source
destination pairs
Mills, Hirsh, & Ruth [Page 14]
RFC 1272 Internet Accounting: Background November 1991
5.2 An Extended (Campus or Facility-Wide)
128.252.100.X 128.252.150.X 128.253.220.
+----------------+ +----------------+ +----------------+
| | |
| | |
/ \ / \ / \
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.
This is the first example in which the information that is
for service provider and consumer are not identical. The
consumers are now the individual subnets and the service provider
the facility-wide backbone. A service provider is interested
knowing the contribution of individual subnets to the total
of the backbone. In order to ascertain this, a meter on the
(the longest line in the center of the illustration) can keep
of flows between subnet pairs. Now the communications
individual hosts on adjacent subnets are aggregated into a
flow that measures activity between subnets
The service consumers, or subnets, might in turn want to keep
of the communications between individual hosts that use the
of the backbone. An accounting system on the backbone could
configured to monitor traffic among individual host pairs
Alternately an accounting system on each individual subnet could
track of local and "non-local" traffic. The observed data of the
sets of meters (one for the service provider and one for the
consumers) should have reconcilable data
Mills, Hirsh, & Ruth [Page 15]
RFC 1272 Internet Accounting: Background November 1991
5.3 A Regional
116.125
+-----------------+
|
+
/ \
116.125.10.10
\ /
/ + \
/ \
/ \
/ \
| + + |
| / \ / \ |
128.242 |----- 128.242.10.10 128.252.10.10 -----| 128.252
| \ / \ / |
| + + |
\ /
\ /
\ /
\ + /
/ \
124.110.10.10
\ /
+
+-----------------+
|
124.110
In this example we have a regional network consisting of a ring
point-to-point links that interconnect a collection of campus-
LANs. Again service provider and consumer have differing
and needs for accounting data. The service provider, the
network, again will be interested in the contribution of
individual network to the total traffic on the regional network
This interest might extend to include measure of individual
utilization, and not just total offered load to the network as
whole. In this latter case the service provider will require
meters be placed at one end or the other on each link. For
service consumer, the individual campus, relevant measures
include the contribution of individual subnets or hosts to the
"outbound" traffic. Meter(s) placed in (or at) the router
connects the campus- network to the regional network can perform
necessary measurement
Mills, Hirsh, & Ruth [Page 16]
RFC 1272 Internet Accounting: Background November 1991
5.4 A National
__________
|
+
| / \ |
|--+ 1 +--|
| \ / |
+
/ \
\ /
/ + \
/ \
_______ / \ _______
| / \ |
+ + + +
| / \ / \ / \ / \ |
|--+ 4 +----\ / 5 \ /-----+ 2 +-|
| \ / + + \ / |
+ \ / +
___|____ \ / ___|____
\ /
\ + /
/ \
\ /
+
| / \ |
|--+ 3 +--|
| \ / |
+
____|____
In this last case, the data that the service provider will want
collect is the traffic between regional networks. The flow
measures a regional network, or regional network pairs, is defined
the union of all member-campus network address spaces. This can
arrived at by keeping multiple individual network address flows
developing the regional network contribution as post-
activity, or by defining a flow that is the union of all the
addresses. (This is a cpu cycles for memory trade-off.) Note
if the service provider measures individual network contributions
then this data is, in
measure, the data that the service consumers would require
6. Future
This last section is the collector for ancillary issues that are
yet undefined or out of current scope
Mills, Hirsh, & Ruth [Page 17]
RFC 1272 Internet Accounting: Background November 1991
APPLICATIONS standards: Recommendations for storage, processing
reporting are left out for the moment. Storage and processing
accounting information is dependent on individual network policy
Recommendations for standardizing billing schemes would be premature
QUOTAS are a form of closed loop feedback that represent
interesting extension of usage reporting. But they will have to
until the basic accounting technology is reasonably defined and
been the subject of a reasonable amount of experimentation
SESSION ACCOUNTING: Detailed auditing of individual sessions
the internet (at level four or higher) will not be addressed
internet accounting. Internet accounting deals only with
traffic at the IP level
APPLICATION LEVEL ACCOUNTING: Service hosts and proxy agents have
do their own accounting for services, since the network
distinguish on whose behalf they are acting. Alternately, TCP/
port numbers could become an optional field in a meter, since
conjunction of a pair of IP addresses and port numbers occurring at
particular time uniquely identifies a pair of
processes
The USER has not yet been defined, since an IP option would have
be added to the IP header to provide for this. This option
probably contain two parts - a subscriber identification and a
sub-identification - to allow for the later introduction of
mechanisms which have both group and individual quotas.
subscriber is the fiscally responsible entity, for example
manager of a research group. In any case, routers must be able
fall back to accounting by host, since there will most certainly
hosts on the network which do not implement a new IP option in
timely fashion
7.
International Standards Organization (ISO), "
Framework," Part 4 of Information Processing Systems Open
Interconnection Basic Reference Model,ISO 7498-4, 1984.
International Standards Organization (ISO), "
Architecture," Part 2 of Information Processing Systems
Systems Interconnection Basic Reference Model,ISO 7498-2, 1984.
Mills, Hirsh, & Ruth [Page 18]
RFC 1272 Internet Accounting: Background November 1991
Security
Security issues are discussed in sections 2, 3 and 4.
Authors'
Cyndi
Bolt, Beranek, and
150 Cambridge Park
Cambridge, MA 02140
Phone: 617-873-4143
Email: cmills@bbn.
Donald
Meridian Technology
11 McBride Corporate Center
Suite 250
Chesterfield, MO 63005
Phone: 314-532-7708
Email: hirsh@meridian.
Gregory
Bolt, Beranek, and
150 Cambridge Park
Cambridge, MA 02140
Phone: 617-873-3150
Email: gruth@bbn.
Mills, Hirsh, & Ruth [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
