Accounting Requirements for IPng (RFC1672)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2005-May-22
Internet Society Requests For Comment (RFCs)
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the firstname.lastname@example.org mailing list.
Network Working Group N.
Request for Comments: 1672 The University of Auckland
Category: Informational August 1994
Accounting Requirements for IPng
Status of this Memo
provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the email@example.com mailing list.
This white paper
discusses accounting requirements for IPng. It
recommends that all IPng packets carry accounting tags, which would
vary in size. In the simplest case a tag would simply be a voucher
identifying the party responsible for the packet. At other times tags
should also carry other higher-level accounting information.
Accounting Model - described in RFC 1272 - specifies how
accounting information is structured, and how it is collected for use
by accounting aplications. The model is very general, with
accounting variables being defined for various layers of a protocol
stack. The group's work has so far concentrated on the lower layers,
but the model can be extended simply by defining the variables
required, e.g., for session and application layers.
 suggests that IPng packets should carry
authenticated (source, destination, transaction) triplets, which
could be used for policy-based routing and accounting. The following
sections explain how the transaction field - hereafter called an
'accounting tag' - could be used.
Lower-layer (Transport) Accounting
At the lower
(network) layers the tag would simply be a voucher. This
means it is an arbitrary string which identifies the party
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:
provider tag identifies user
provider A - provider B ...