RFC 1672 (rfc1672) - Page 2 of 3
Accounting Requirements for IPng
Alternative Format: Original Text Document
RFC 1672 Accounting Requirements for IPng August 1994
responsible, i.e., willing to pay for, a packet. It would initially
be set by the host which originates the packet, hence at that stage
the tag would identify the user who sent it.
A tag could be changed at various points along a packet's path. This
could be done as part of the routing policy processing so as to
reflect changes of the party responsible over each section of the
path. For example:
user - provider tag identifies user
provider A - provider B tag identifies provider A
The tag could be used by accounting meters to identify the party
responsible for a traffic flow, without having to deduce this using
tables of rules. This should considerably simplify accounting for
transit traffic across intermediate networks.
Higher-layer (Session and Application) Accounting
At higher layers there is a clear need to measure accounting
variables and communicate them to various points along a packet's
path, for example an application server may wish to inform a client
about its usage of resources. A tag containing this information could
be read by meters at any point along the packet's path for charging
purposes, and could also be used by the client to inform the user of
charges incurred.
It would make the collection of accounting data much simpler if this
information was carried in a standard tag within each packet, rather
than having different protocols provide this service in differing
ways.
For 'old' applications which remain unaware of the tag field, a meter
could be placed at a gateway for the application's host. This
'gateway' meter could determine what the application is by watching
its streams of packets, then set an appropriate value in thir tag
fields.
Structure of the accounting tag
The two uses of tags outlined above must be able to coexist. Since
many - indeed most - of the packets will only carry a voucher, it
seems simplest to keep this as part of the routing tuple (see below).
For the application variables, a separate tag seems sensible. This
would simply contain a list of the variables. Having two tags in
this way would keep separate the management of routers and meters.
Brownlee