Browse Prior Art Database

Accounting Requirements for IPng (RFC1672)

IP.com Disclosure Number: IPCOM000002509D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2005-May-22
Document File: 4 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

N. Brownlee: AUTHOR

Abstract

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 big-internet@munnari.oz.au mailing list.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

Network Working Group                                        N. Brownlee
Request for Comments: 1672                    The University of Auckland
Category: Informational                                      August 1994


                    Accounting Requirements for IPng

Status of this Memo

   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.

Abstract

   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 big-internet@munnari.oz.au mailing list.

Summary

   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.

Background

   The Internet 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.

   Brian Carpenter [1] 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

Brownlee                                                        [Page 1]
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  ...