| I. Radisic Munich Network Management Team University of Munich Oettingenstr. 67 D-80538 Munich, Germany Phone: +49-89-2180-9167, Fax: -999167 radisic@informatik.uni-muenchen.de |
This fast-growing trend of outsourcing of services and service orientation in general has an immense impact on accounting management with new requirements coming up, e.g.: Usage-based and QoS-dependent charging is replacing flat-fee based approaches; service oriented accounting units reflecting service functionality are needed (e.g., transactions) to replace simple measurable accounting units (e.g., transmitted bytes); dynamic accounting systems which are adaptable during service operation should be used instead of static accounting systems. In consequence, a flexible accounting management system is required which is able to direct accounting systems with regard to changing needs evolving during service provisioning.
Additionally, todays accounting systems are implemented by various distributed components. Usually, charging and billing is carried out by so called billing systems that require information about service usage to calculate the total amount that has to be charged. Therefore, special metering software is used that delivers detailed data about service usage. Unfortunately, neither standard interfaces nor data formats have been adopted yet. Thus, communication between the various accounting components is still established by supporting proprietary interfaces or implementing gateways. Even worse, no standard management interfaces to control accounting systems have been established so far. As a consequence, introducing a new accounting system component into a provider's infrastructure today means to implement parts of the accounting management from scratch. Thus, accounting management becomes a time-consuming and error-prone task. Therefore, an integrated accounting management system is needed to be able to direct the various participating accounting components in a uniform way.
To be able to handle the aforementioned increasing complexity, the management tasks regarding accounting management have to be automated as far as possible. This allows to relieve administrators of repetitive management activities.
To sum up, a highly integrated, flexible and automated accounting management is required to accomplish the needs rising from the trend of service outsourcing. In this paper we propose the application of policy-based concepts on accounting management along with the complete service life cycle to realize the required management functionality. Using policies to direct the components involved in accounting a service allows to abstract from the distributed components realizing the accounting system in all life cycle phases. Hence, an accounting manager has a uniform view on accounting management and the requirement of integration is fulfilled. Additionally, the flexibility of the accounting management system is directly dependent on the flexibility of the policy language. Thus, the requirement of flexibility is fulfilled as long as the policy language is flexible in expressing the needed management actions. To achieve a higher degree of automation in change management regarding service accounting we additionally propose the application of meta-policies which control activation, deactivation, creation and deletion of accounting policies.
The remainder of the paper is organized as follows: In Section 2 a typical scenario is described to introduce the environment we focus on in this paper. In Section 3 we discuss related work. In order to investigate the required dynamic aspects of accounting management in outsourcing scenarios, we analyze in Section 4 interactions taking place and processes involved. Furthermore, this analysis is used to determine basic accounting entities. Afterwards, in Section 5 we present the architecture of our management solution which uses policy-based concepts to overcome the shortcomings of solutions developed so far. Finally, Section 6 concludes the paper by presenting open issues and further work.
A large german service provider (SP) operates a so-called Intranet Extranet Service Area (IESA) for an international assurance company. The IESA provides a connectivity service to the assurance company's Intranet Service Area (ISA) on the one side to the Internet on the other. Additionally, DNS and email service are provided to the assurance company. Assurance agencies and their employees that get in contact with the end customer (assurance holder) are the actual users of the IESA: they download up-to-date assurance forms, use specific assurance applications to calculate contracts from the ISA site, use an email account to get in contact with other agencies, and in fact use the Internet for non-business applications. On site of the assurance agencies ISDN dial-up routers are installed to establish the connection to the IESA. The assurance company demands a usage-based charging for the IESA, where charges for the ISA usage have to be separated from the charges for internet usage. The intention is that the assurance company is able to recover the costs for ``private'', non-business usage of the IESA from their agencies resp. employees.
To be able to assign metered usage data to specific employees and agencies the SP needs up-to-date information about all possible IESA users. Therefore, a user data rollout between the assurance company, which is aware of all possible users, and the provider has to be done frequently. To separate business from non-business IESA usage, usage data is collected from various sources: from a WWW proxy server, from several Dial-In Authentication Servers and from routers which establish the connection to the assurance company's ISA. WWW proxy usage data is always regarded as private usage whereas the remaining usage data is regarded as business usage. Afterwards, the usage data collector assigns the metered data to an accounting user ID and additionally decides whether usage data is cumulated to agencies or to single employees.
As previously mentioned in Section 1, standard interfaces have not been adopted by accounting components so far. Thus, in this case the SP had to implement various gateways and data translators between the components to set up the required accounting system. As a matter of fact, the high dynamics inside the assurance company resulted into several challenges regarding accounting management the SP had to cope with. For instance, the assurance company had participated in an enterprise fusion with another company which resulted into a new company structure. The customer demanded a varying tariff for the newly added agencies, so that new user groups had to be configured. Furthermore, the company demanded a QoS-dependent tariff for which new meters on client site had to be installed (one per Dial-Up router). Consequently, the collector software had to be reconfigured and new gateways had to be implemented. Additionally, every time a new user was introduced the corresponding meter had to be reconfigured. This becomes especially a costly and time-consuming task when automated tool support is missing and one has to deal with over 10.000 agencies and about 40.000 potential users. Moreover, the assurance company also demands customer-individual billing as well as hot-billing and -reporting for which the billing system needs to be exchanged. Plans for the future are to add new services to the IESA for which varying tariffs are demanded, too. Overall, due to the high dynamics resulting from change management and the missing support of the management tools, the SP had to partly reimplement the accounting system every time something changed that was relevant for accounting management. Besides, as automated tool-support is missing, accounting management became a complex and time-consuming task. Therefore, the SP demands means for accounting management which are able to cope with the high dynamics in todays outsourcing scenarios by considering the complete service life cycle and providing an integrated, adaptable view on accounting management.
Accounting Management is one of OSI's Systems Management Functional Areas and the appropriate standardization document [11] is specifying an accounting management architecture by introducing a usage metering, a charging and a billing component. The usage metering component is the only one which is investigated in more detail and for which managed objects are specified. The remaining parts are left for further study. TMN is adapting OSI's FCAPS for telecommunication services and mentions in [12] some relevant accounting function sets. For most of them specific management functions are not specified at all, while realization concerns are completely left out of consideration. In contrast, TINA-C presents in [6] a detailed description of required accounting management interactions. However, these are restricted to TINA-conform telecommunication services and management architectures and thus are not applicable to outsourcing scenarios in the focus of this paper. The IETF working group Authentication, Authorization and Accounting (AAA) has also adapted OSI's accounting architecture for IP (connectivity) services [1]. The main focus is centering around usage metering by specifying accounting protocols as well as accounting data formats. Furthermore, the non-profit organization IPDR is standardizing the so called Internet Protocol Detailed Record (IPDR) [10] and additionally a proper accounting protocol.
The research community has mainly been involved in developing new techniques and methods for pricing as well as in implementing an appropriate infrastructure to enable these pricing models. Intensive research has been made to accomplish dynamic pricing models like smart market and effective bandwidth for connection-oriented networks like ATM. [19] is based on the results of the ACTS project ``Charging and Accounting Schemes in Multiservice ATM Networks (CA$HMAN)'' and gives a good overview of the mathematical, theoretical foundations as well as current research in this field and additionally presents a prototypical implementation for automatic, intelligent agent based tariff negotiation. The application of dynamic pricing models in packet-switched networks like IP based on, e.g., DiffServ, is described in [13] and [20]. Furthermore, the EC funded project M3I ( www.m3i.org) is focusing on work around the field of resource management on basis of differential charging for multiple levels of service.
Our work presented in this paper was inspired by [7], in which a policy-based architecture for enforcing tariffs based on various pricing models is presented. Basically, a layered architecture is described where every single accounting software component of the usage phase is managed by applying appropriate policies. Overall, beside the fact that this work is considering only one phase of the service life cycle, it is concentrating on using DiffServ to implement and enforce tariffing policies. Thus, a specification of a policy language and a policy transformation for a general accounting management is missing which is in the focus of this paper.
In the following, we are presenting the afore mentioned process analysis that we carried out as a first major step towards a new solution For this purpose we give first a short description of service life cycle phases. Afterwards we describe our analysis of accounting sub-processes in combination with the service life cycle. Finally, in order to identify the most relevant accounting entities, we additionally analyze the information flows between the sub-processes.
In the following, we describe 7 life cycle phases (see Fig. 2) which represent an extension of the service life cycle proposed in [4]. In the Offer phase the provider submits a proposition consisting of a service description and a desired tariff for service usage. The customer is usually reviewing several propositions from various providers at the same time. The Negotiation phase deals with the process of concluding a contract between the provider and customer of a service. Usually, a contract contains details about service functionality, quality of service (QoS) and of course tariffs as well as penalties. Afterwards, the provider is implementing the agreed service functionality in the Implementation phase. In the Installation & Test phase all resources like, e.g., equipment, end systems, interfaces, applications, etc. that are needed to provide service functionality are installed and tested so that the service can start its operation. After the customer expresses the statement of acceptance regarding the service provisioning, the Operation phase of the service life cycle starts. Regarding accounting management, in case of usage-based tariffs the actual service usage has to be metered and an invoice has to be compiled and sent to the customer. The Change phase combines all interactions in regard to changing service functionality, service implementation and service management. Therefore, the change phase has to be seen in parallel to the Operation phase. The service life cycle ends with the Deinstallation phase within which the implementation's resources are released.
In the previous subsection we already mentioned entities which are either source, target or result of activities and consequently are objects which should be considered by the management system. Hence, we need to specify these entities in more detail. Fig. 4 gives an example of a simplified analysis of the reporting process. Relevant Entities are visualized by specifying their name near an arrow. An arrow pointing to an activity of a process expresses the input and an arrow leading out of an process expresses the output of the process and activities, resp. The result of our analysis is illustrated in Fig. 5 by refining the MNM service model [4]. In the following, we will describe an brief overview of the model elements.
First a customer and a provider agree on a service agreement about the provisioning a certain service. Besides the description of service functionality and quality-of-service (QoS) a service agreement contains a tariff which is a refinement of a tariff template. A tariff template is the result of the service analysis sub-process done by the accounting manager and contains all possible accountable units and a cost function for a given service. Therefore, when specifying a tariff usually accountable units simply have to be selected from the tariff template and a price function has to be ascertained. When it comes to service operation the actual service usage of a user has to be charged. For this purpose, the user is using a client to access the service. Furthermore, the accounting manager is sending an invoice which contains the total amount to be paid by the invoice recipient on the customer side. Additionally, the accounting manager compiles reports
sent to report recipients on customer side, which in contrast to invoices contain detailed data about service usage and the applied tariffs but no request for payment. The provider directs the accounting manager by, e.g., specifying a set of policies enforced by the accounting manager. The latter is realizing the accounting process and thus usually this role is taken by several accounting components like meters, collectors, billing systems, reporting tools etc. and the management system which controls these components.
The basic idea is that every accounting sub-process is managed by appropriate (accounting) management policies. Several advantages arise by using policies for this purpose: The needed abstraction of heterogenous accounting components is a ``built-in'' feature of policy-based concepts. The same is true for the needed integrated view on the managed objects. To automate management tasks that span more than one life cycle phase and thus span more than one sub-process we additionally need to express the sub-process transitions. Our idea is to express these transitions by concatenating the appropriate accounting policies. As we will show, some change management activities can not be expressed solely by enforcing a chain of existing accounting policies: Additionally the generation of new accounting policies that eventually replace existing ones is required. For this purpose we want to use the concept of meta-policies which basically provide the possibility to specify rules for creation, (de-)activation and deletion of policies.
In the following, we first present the developed policy-based management architecture and explain the design decisions made on basis of the analysis in Section 4. Finally, we describe the policy description language as well as the specification of accounting policies.
Management Architecture On the one hand we need to specify the elements of a policy description language (PDL) and on the other a management architecture that is capable of enforcing the specified policies. Hence, the specification of the policy-based management architecture determines the execution environment of policies. To fulfill the requirement of presenting one integrated view on accounting management, we introduce a mediation layer between the management system and the actual managed objects (i.e., the systems and applications implementing the accounting sub-processes). In this way, the management activities are executed on representatives of the managed objects and thus a uniform access on object interfaces during execution of policies is possible. The resulting policy-based accounting management architecture is depicted in Fig. 6. In order to increase the flexibility of the management environment we are modularizing the management application as well as the managed accounting system according to functionality classes. Regarding the management application we separated the functionality into operations which manipulate policies (like, e.g., creating and deleting policies) and into operations which enforce policies (i.e., interpreting the policy and executing the specified management actions). Regarding the accounting system we are using the sub-processes identified in 4.2 as a separation guideline: the functionality of every single sub-process is implemented by a separate module. When accessing the modules' interfaces within the mediation layer and thus calling a provided operation, the call is transformed to an appropriate call on the interface of the actual managed object. This could result into an API/SNMP/etc.-call as well as into altering a configuration file.
Implementation Details A reliable and secure accounting management system is the prerequisite for successful operation of an accounting system. Therefore, we decided to use the Mobile Agent System Architecture (MASA) [5] as our development and runtime environment. Basically, MASA can be separated into Agents providing a specific functionality and into the Agent System which provides the runtime environment for the Agents. MASA is completely written using Java/CORBA [3] and offers, as an MASIF [18] compliant agent system, several basic services like naming, notification and security. Additionally, to increase reliability of agents, a load balancing on basis of agent migration is possible. Following the design decisions described above, the accounting management system consists of two agents (see also Fig. 7): the Policy Factory Agent (PFA) and the Policy Enforcement Agent (PEA). The PFA offers an interface for creating, deleting, activating and deactivating accounting management policies as well as meta-policies. Furthermore, the PFA stores and retrieves policy objects and meta-policy objects which are specified in the policy description language (PDL) using XML. XML is used for this purpose, as by using a standard XML parser we do not need to implement a policy parser from scratch. In contrast to the PFA, the PEA controls and manages so-called policy enforcement objects (PEO) which are created just when a policy object is activated. A PEO is a CORBA object and reacts on received events by enforcing the specified management actions. In this case a PEO is executing CORBA calls using the CORBA Dynamic Invocation Interface (DII). Before executing management actions resp. invoking CORBA operations a PEO has to parse the policy. For this purpose a PEO uses a Policy Interpreter which is an adapted XML parser that evaluates the specified constraints. Basically, the Policy Interpreter returns ``true'' or ``false''. In case of ``true'' the PEO is firing the specified management activities. The mediation layer is implemented using various MASA (proxy) agents which represent the accounting system. These agents are either full-functional agents or-as in most cases-proxy agents for software products/components which offer the required functionality. Every agent implements an IDL interface which is corresponding to the sub-process' functionality. The IDL interface is developed by examining the sub-process interactions and activities from Section 4 in more detail. In case of a proxy agent a CORBA call at the agent's interface is transformed into appropriate instructions of the software component's interface. Thus, the underlying software components like billing systems can be exchanged without the need to neither reimplement the management system from scratch nor to respecify existing policies. All in all, from the manager's point of view an integrated, uniform view on accounting management is established.
POLICY id FOR subject ON
target ON EVENT events DO activities
CONSTRAINT constraints;
Specifying Policies As we want to manage every single accounting sub-process by applying appropriate policies, we have to basically find out what the subjects, targets, activities and constraints for every single sub-process are. In this paper we are concentrating on sub-processes which are mainly operated by IT resources and thus can be managed by an appropriate policy management system in an autonomous and automatic way. Therefore, the sub-process pricing as well as the sub-processes needed for pricing are left out in this step of policy specification as usually in outsourcing scenarios these sub-processes are mainly carried out by human interactions.
Table 1 summarizes the identified subjects and targets for the remaining sub-processes. Every table column represents one accounting entity identified in Fig. 5. The table rows represent policies managing specific sub-processes. For every single policy the created matrix contains exactly one circle representing the subject and exactly one cross representing the target. Additionally, several triangles were added representing that there is some kind of dependency between this specific policy and the marked accounting entity. These dependencies were identified during the analysis in Section 4.3 and are needed for specifying meta-policies, as we will show.
Obviously, policies for the sub-processes in the change phase are missing. As shown in our change management activity in Fig. 3 (i.e., adding a user), change activities often deliver the impulse for executing activities that usually belong to other sub-processes and consequently to other life cycle phases (e.g., installing/configuring a new meter, etc.). Overall, usually a chain of existing sub-processes is executed due to change management activities. Therefore, we need to take the sub-process transitions into account for managing the accounting process as a whole. As in our case sub-process transitions are enforced by events, we actually need to identify proper events for every transition. Specifying these events within the appropriate policy reveals the feasibility to express the execution of policy chains and thus the management of sub-process chains as especially needed in case of change management activities. Generic events generated by every sub-process are the start and the end of an activity.
However, some change activities can not be expressed solely by enforcing sub-process chains. Instead new policies need to be created which in some cases replace existing ones. Our research revealed that only changes affecting entities which are specified in the service agreement (i.e., the side independent part of table 1) might lead to creation of new policies. E.g., if there is a new charging formula for a group of users, a corresponding new charging policy has to be specified. In this case, the specification of meta-policies can help to declare which specific change activities result in creation/deletion/activation/deactivation of ``normal'' accounting policies. For this purpose we can reuse table 1 to analyze which policies are potentially affected by meta-policies: as circle/cross/triangle-symbols also express a dependency between an entity and the corresponding policy only those policies have to be checked where the column of a specific entity contains such a symbol. This immensely reduces the number of required tests.
Table 2 summarizes the elements of the policy description language for both the accounting policies as well as meta-policies in a semi-formal way.
| Policy | Sub-proccess-ID | Meta-Policy | ID |
| For | { entity{.association.entity}} | For | entity |
| On | { entity{.association.entity}} | On | Policy ID |
| On Event | {Activity.(started|ended)} | On Changes | newly added|existing (altered|deleted) |
| Do | {(target|object).IDL-Operation} | Do | create|delete|(de)activate Policy |
| Constraint | Boolean Expression | Constraint | Boolean Expression |
Table 2: Semi-formal presentation of policy description language
As shown in this paper, new requirements for accounting management evolve from the trend of service- and customer-orientation. In this paper, we have proposed the application of policy-based concepts to provide the required highly integrated, flexible and automatic accounting management which especially supports the dynamic aspects of change management. To achieve this, we have first analyzed the dynamic aspects of service accounting and its management from a process-oriented view. By identifying sub-processes and analyzing sub-process transitions we have derived relevant accounting entities which were used to compose an accounting service model. Afterwards, we have used the requirements to design a policy-based management architecture for accounting management. Finally, the process analysis as well as the accounting service model served as a source for design decisions regarding the policy language. As we use policies to manage every sub-process and process-transition involved in service accounting and additionally the concept of meta-policies, we achieved to meet the posed requirements.
We are about to finish a prototypical implementation of the described architecture. Several mediation agents like, e.g., for NeTraMet [2], Apache Log Files, etc. have already been realized. The policy interpreter on basis of an XML parser is on the way. We are planning to install an accounting management test bed based on the concepts presented in this paper on site of one of our cooperation partners to gain experience from real-life scenarios.
In the future, we will investigate the reuseability of policies and meta-policies with the goal of defining either policy schemes or a methodology for specifying accounting policies. Additionally, in order to reduce costs in accounting management we are also doing research on reusing accounting software components like usage collectors and billing systems for different customers, as up to now usually every component is exclusively dedicated to one customer. In this case ``clientele processing'' becomes one of the major requirements which have to be fulfilled.
Acknowledgment The author wishes to thank the members of the Munich Network Management (MNM) Team for helpful discussions and valuable comments on previous versions of the paper. The MNM Team directed by Prof. Dr. Heinz-Gerd Hegering is a group of researchers of the University of Munich, the Munich University of Technology, and the Leibniz Supercomputing Center of the Bavarian Academy of Sciences. Its web-server is located at http://wwwmnmteam.informatik.uni-muenchen.de .