Re: Accounting Architecture

kc@upeksa.sdsc.edu Mon, 14 March 1994 22:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15243; 14 Mar 94 17:17 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15235; 14 Mar 94 17:17 EST
Received: from wugate.wustl.edu by CNRI.Reston.VA.US id aa26112; 14 Mar 94 17:17 EST
Received: by wugate.wustl.edu (5.67b+/WUSTL-0.3) with SMTP id AA21420; Mon, 14 Mar 1994 16:07:50 -0600
Message-Id: <199403142207.AA21420@wugate.wustl.edu>
Date: Mon, 14 Mar 1994 14:07:42 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: kc@upeksa.sdsc.edu
X-Orig-Sender: "ONC List Processor V0.2" <listserv@wugate.wustl.edu>
Reply-To: accounting-wg@wugate.wustl.edu
To: accounting-wg@wugate.wustl.edu
Errors-To: accounting-wg-errors@wugate.wustl.edu
Subject: Re: Accounting Architecture

  
do you think you might get
this on a channel of the mbone
for those that would like to attend remotely?

tnx,
k
  Hi Everyone,
  
  The Internet Accounting BOF that Nevil Brownlee and Cyndi Mills are
  chairing on March 30th in the IETF meeting in Seattle will focus, among 
  other things, on the following charter for a workgroup (the fifth agenda item): 
  5. Proposed Charter (i.e. Goals) for this WG
       * Informational RFC on Internet Accounting Architecture
       * Informational RFC for Meter Services MIB
       * Internet Draft on Accounting Collector Requirements
  	 + Format of flow data files
  	 + Protocols for managing collection; starting, restarting,
  	      names for data files, ...
       * Internet Draft on Accounting Manager Requirements
  	 + Format for Accounting Rule files
  	 + Language(s) for specifying flows
       * "Economics" issues
  	 + Survey of cost sharing/recovery schemes currently in use
  
  The purpose of this posting is to briefly introduce the AMADNS work
  effort that has been going on over the last two years at Bellcore.
  This effort is closely related to the proposed WG charter, and 
  might be of interest to the BOF participants. 
  
  AMADNS is designed to provide network and service usage data transfer, 
  processing, and management capabilities. The concepts embedded 
  in AMADNS as well as many of the specific features 
  are compatible with the concepts and architecture defined for the 
  Internet Accounting Architecture and implemented in NeTraMet, and the two 
  systems complement each other very nicely. Specifically,
  the file based interface and associated procedures have been defined in
  detail for AMADNS and the approach may be applicable to the
  definition of the Collector and the Collector Application interface. 
  
  The following describes the AMADNS architecture and some of its key 
  characteristics.
  
  
  System Architecture:
  
  AMADNS is composed of Data Servers, one or more Data Processing and
  Management Systems (DPMSs), one or more System Managers and the various
  interfaces to these components. The logical architecture of AMADNS is shown 
  in the diagram below:
  
    __________         ______         _________________       ___________
   |Generating|_______|Data  |_______|Data Processing &|_____|Applications|
   |System    |       |Server|       |Management System|     |            |
    __________         ______         _________________        __________
                           \           /
                            \ ________/
                             | System |
                             | Manager|
                              ________
  
  AMADNS connects the source of the usage data (Generating Systems) with 
  its destination (the Applications) in a flexible and scalable way. 
  
  - Generating Systems generate the usage data. They may include switches, 
    routers, other network systems, information servers, and any third party 
    services. These systems serve an equivalent role to that of the
    Meters in the Internet Accounting Architecture.
  
  - Data Servers receive formatted data records from the Generating Systems
    soon after they are generated.  A Data Server stores the records
    in files (after possible filtering and reformatting) and sends them 
    to a DPMS. The Data Servers serve an equivalent role to that of the
    Collectors in the Internet Accounting Architecture.
  
  - DPMSs perform specialized processing (e.g., aggregation, 
    correlation, reformatting) on the data as required by the
    applications, place the processed data in files, and transfer the
    files to applications. They serve an equivalent role to that of the
    Applications in the Internet Accounting Architecture.
  
  - Applications are the destination of usage data. The primary
    Application is billing. Other Applications include fraud detection,
    marketing and customer network management.
  
  - System Managers manage the Data Servers and DPMS components of
    AMADNS. The System Manager would serve the role of the Manager
    in the Internet Accounting Architecture.
  
  
  AMADNS System Characteristics:
  
  1. Sender-initiated and receiver-initiated data transfer through an
     end-to-end logical data path. This maximizes data transfer flexibility.
     The Data Server - DPMS Interface is used to transfer files between 
     the Data Server (sender) and the DPMS (receiver) and the DPMS - 
     Application Interface is used to transfer files between the DPMS (sender) 
     and the Application (receiver). In both cases, both senders and receivers 
     are capable of initiating a file transfer based on user settable time 
     schedules, time periods, volume of data available, and manual requests.  
  
  2. Near real-time data availability which enables AMADNS Applications to 
     gain access to usage data within 15 minutes after it was generated. 
     Some time-sensitive Applications (e.g., fraud detection, near real 
     time billing) require data access of this type. In AMADNS, time 
     schedules and other trigger events enable files to be sent as frequently 
     as desired.
     
  3. Standard protocols for file transfer, network management, and remote 
     login are employed across the component interfaces.  At the upper 
     layer, FTP and Telnet are used across the Data Server - DPMS 
     interface, FTP is used across the DPMS - Application
     interface, and SNMP, FTP, and Telnet are used for the interface
     to a System Manager. TCP, UDP, and IP are used to support these protocols.
     Usage data to be transferred over the Generating System - Data Server 
     interface is passed directly through TCP. This approach for the
     Generating System - Data Server interface is different from that defined 
     for the Meter-Collector interface in the Internet Accounting 
     Architecture which uses SNMP for usage data transfer. 
  
  4. Specialized data processing is supported to satisfy Applications'
     needs (e.g., data correlation and aggregation). Data Servers and
     DPMSs provide the mechanisms that enable specialized processing modules
     to be integrated into their operations. A standard software execution
     environment is supported by these system components to facilitate the
     development, integration, and porting of specialized processing
     modules.    
  
  5. Standard system management to ensure the efficient operation of a
     system composed of heterogeneous machines and to facilitate the 
     reconfiguration and maintenance of such a system. System Managers
     manage Data Servers and DPMSs, providing administrators with
     an overall view of the system and enabling them to control each
     managed component.  
  
  
  The Generic Requirements that define the AMADNS components and
  interfaces are completed and available to the community. 
  Generic Requirements are equivalent to industry standards.
  
  We will be happy to provide any technical information regarding AMADNS 
  either prior to or during the BOF meeting. Also, we will be happy to assist
  in adapting any aspect of the AMADNS work to help the WG reach its goals.
  
  
  See you in Seattle,
  
  Shoshi Loeb  and  Mike Kogut
  (201) 829-4528   (908) 748-5222
  Bellcore