Browse Prior Art Database

Method for Implementing Accounting in an Agent using a Generic Subtree

IP.com Disclosure Number: IPCOM000110923D
Original Publication Date: 1994-Jan-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 141K

Publishing Venue

IBM

Related People

Chen, DD: AUTHOR [+2]

Abstract

A method for implementing accounting in an Agent using a generic subtree is disclosed. A generic accounting subtree of objects is defined. This subtree exists at the Agent, and is retrievable/modifiable by the Manager. The Agent (and Manager) are able to develop ONE copy of the modules which maintain the vast majority of accounting objects. Only a small number of routing protocol-specific modules will ever need to be written. This method offers significant advantages over traditional methodologies. It can be easily used in providing accounting data for any routing protocol, and is independent of the actual network management protocol.

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

Method for Implementing Accounting in an Agent using a Generic Subtree

      A method for implementing accounting in an Agent using a
generic subtree is disclosed.  A generic accounting subtree of
objects is defined.  This subtree exists at the Agent, and is
retrievable/modifiable by the Manager.  The Agent (and Manager) are
able to develop ONE copy of the modules which maintain the vast
majority of accounting objects.  Only a small number of routing
protocol-specific modules will ever need to be written.  This method
offers significant advantages over traditional methodologies.  It can
be easily used in providing accounting data for any routing protocol,
and is independent of the actual network management protocol.

      One of the key network management functions for any routing
protocol is accounting.  Customers have long required routing
protocols to provide accounting data.  This accounting data is
typically then used as input into the customers' billing,
performance, capacity planning and/or problem determination
applications.

      Traditionally, Agents have implemented routing protocol
accounting functions by defining a group of control-objects and
data-objects.  The Manager then uses the control-objects for
operational tasks (start accounting/stop accounting) and the
data-objects to gather the actual accounting records.

      The structure (ordering of) the accounting objects are routing
protocol-specific and the Agent's underlying record storage media(s)
are not surfaced to the Manager.  This methodology has lead to:

1.  Redundant development efforts by the Agent and Manager for each
    new accounting type.  Since the objects are protocol-specific and
    inconsistently structured, the Agent and Manager have to develop
    a completely new set of code to provide an accounting function
    for another routing protocol.

2.  Storage concerns for the Agent (and Manager).  Since completely
    new modules and control blocks are needed for each new accounting
    type, the amount of storage required by the Agent to provide
    accounting functions grows exponentially.

3.  The Manager is forced to retrieve the accounting data
    interactively due to lack of knowledge about the Agent's
    recording media.  For example, if the Manager was aware the Agent
    was using a data file as a storage media, the Manager would have
    the option of retrieving the accounting data through bulk data
    transfer, e.g., file transfer.

4.  Performance concerns for the Agent (and Manager).  Added
    processing is needed to execute each routing protocol's
    accounting code.  The processing requirements are further
    exacerbated by requiring an interactive retrieval of the
    accounting data.

      To address the problems associated with traditional ways of
implementing an accounting function in an Agent, a new method was
developed.  This method uses the fol...