Open Interfaces and Databases of a Modular Internet Charge Calculation and Accounting System Burkhard Stiller1, Jan Gerke1, Hasan1, Peter Reichl2, Placi Flury1 1
Computer Engineering and Networks Laboratory TIK, Swiss Federal Institute of Technology, ETH Zurich, Switzerland 2 Telecommunications Research Center Vienna FTW, Vienna, Austria [stiller|gerke|hasan|flury]@tik.ee.ethz.ch and
[email protected]
Abstract — While Differentiated Services (DiffServ) offer a suitable technology support for Quality-of-Service (QoS) in multi-service networks, appropriate and technically feasible pricing schemes are lacking, mainly to provide an incentive for customers to choose efficiently among various service classes. This paper presents the basics of an implementation of recent developments in the area of charging differentiated services, in detail an Internet Charge Calculation and Accounting System (ICCAS), including its modular architecture, components, open interfaces, and databases. Finally, the explicit application of the newly developed Cumulus Pricing Scheme (CPS) onto the ICCAS and DiffServ is discussed as a suitabe example use. Keywords — Internet Charging, Open System Interfaces, Differentiated Services, Cumulus Pricing.
1
accounting data and tariffs to be applied by ICCAS-internal data bases. On the other hand, a DiffServ-capable charging scheme termed Cumulus Pricing Scheme (CPS) is reviewed and applied. CPS provides a flat-fee type user interface, but in contrast to classical flat rate it offers incentives that drive the user to act economically efficient with respect to resource usage and related service pricing. The major synergy of these two parts, technology and pricing model, becomes visible as soon as CPS is applied to identify probable over- or underutilization of different service classes. Due to space restrictions here, related work is discussed in [4], [5], [9], and [10].
2
Introduction
The Differentiated Services (DiffServ) architecture [1] for Internet backbones provides a technology in support of multiple service classes and Quality-of-Service (QoS). Avoiding a single per-flow handling, aggregates of application flows are mapped onto an appropriate service class and every packet is marked accordingly. However, as soon as this distinction into service classes exists, an incentive for the customer to choose the “right” (i.e. best-suited) class is required for customers. Among these incentives, the price to be paid for the utilization of a particular communication service plays a major role. Moreover, since the exchange of IP packets will not happen only between single customers and Internet Service Providers (ISP), this will be valid between ISPs as well as between ISPs and Customer Premises Networks (CPN). In each of these cases, the exchange of data and traffic based on service classes is supported by Service Level Agreements (SLA) [11], which form the technical and legal container for inter-provider and provider-customer relationships. Since the level of QoS can vary, SLAs are to be negotiable. This paper discusses the implementation of differentiated services charging and proposes a solution in two parts. On one hand, suitable charging technology in terms of an Internet Charging Calculation and Accounting System (ICCAS) is presented and discussed in closer detail with respect to interfaces and interactions between the customer, the ISP, and the network technology. The developed prototype manages
A Modular Internet Charge Calculation and Accounting System
A charging system for the Internet maintains data records, which contain information on service usage and costs to be paid for. An Internet Charging System has been developed by the authors within the M3I project [6], [9], where its core performs major functions of accounting, charge calculation, session control, and contract control. This core is referred to as the Charge Calculation and Accounting System (ICCAS).
2.1
ICCAS Architecture and Components
The ICCAS architecture and its basic components are presented in Figure 1. ICCAS-internal entities consist of a charge calculation, an accounting, a customer support, and a user support component. The separation of the ICCAS into these components increases the required degree of flexibility, since they can be distributed and replicated physically. On one hand, the Accounting Information Path (AIP) deals with the flow of pure charging-relevant data. On the other hand, the Control Policy Path (CPP) is used to manage and configure the ICCAS and those entities involved with the processing of charging data. These two paths differ mainly in the order and direction they process data. The accounting component receives all metered and mediated usage data and is responsible for storing it. It must provide these stored data to other ICCAS components and interfaces for further processing, feedback, or statistic evaluation. The charge calculation component processes the accounted for usage data. It calculates
appropriate charges for resource usage applying a tariff, communicated by the pricing component. To be able to determine the charges fully, it needs input from the user support, e.g., user identifications. Since a customer is not the same as a user, e.g., one customer might pay bills of several users, a customer defines the role which negotiates a contract with the ISP. The content of this contract, e.g., number of users covered by the contract and their names and accounts as well as SLAs, are managed within the customer support. While the customer support component is responsible for keeping all contract information the user support component is responsible for ensuring that those contracts are kept. On one hand, this means that any user requests are blocked if they are not covered by the contract of the customer, who pays for the user. On the other hand, it has to be ensured that a service requested by a user is delivered to her, if the contract allows it.
cient, yet extensible. The data exchanged across this interface (cf. Figure 2) will include one of the following alternatives, depending on the particular scenario: (a) A hand-over of data gathered by metering. (b) A hand-over of data that have been mediated based on the particular inputs from the enterprise policy control. This may result in the dedicated specification of specialized data to be required for the ICCAS, some special aggregation of these data, or even the neglect of data resulting from the gathering process. IC C A S I-M A G E N E R A L
M e d ia tio n
U S A G E
S E R V IC E
E n te r p r is e P o lic y C o n tr o l In te r fa c e
B illin g In te r fa c e
fa m ily
ID
S o u r c e /D e s tin a tio n D a te
A c c o u n tin g
D u r a tio n V o lu m e Q o S C o n tra c t C o n tra c t C h a n g e C o n tra c t B re a k
e x a m p le fa m ily m e m b e rs
Figure 2: Mediation-Accounting Interface (I-MA) C h a r g e C a lc u la tio n
C o n tra c t C o n tro l
A c c o u n tin g
U s e r S u p p o rt
D a ta C o lle c tio n
S e s s io n C o n tro l
C u s to m e r D B
S e r v ic e In te r fa c e
F e e d b a c k In te r fa c e
C h a rg e D B
Due to the fact that the type of data for I-MA and the Interface Mediation-Pricing are similar, only differing in size, number of data records, or frequency of exchange, a similar type of protocol is defined. According to the message sequence chart in Figure 3, configuration data to indicate the level of aggregation are transferred once to the mediation component.
C u s to m e r S u p p o rt
T a r iff A p p lic a tio n
A c c o u n tin g D B
S e s s io n D B
Mediation
ICCAS Configuration
Setting of parameters
M e d ia tio n In te r fa c e
P r ic e In te r fa c e
Q o S In te r fa c e
H o s t/G a te w a y A g e n t In te r fa c e
Periodic transmission of metering data
Metering Data
Data Request
A c c o u n tin g in fo r m a tio n p a th
Transmission of metering data upon request
C o n tr o l/p o lic y p a th
Metering Data
Figure 1: ICCAS Architecture in Detail Figure 3: I-MA Message Sequence Chart
2.2
Open ICCAS Interfaces
All interfaces between these components are designed to act (1) as protocols, allowing for open communication between two remote entities of the component, or (2) as software interfaces, reflecting the deliberate architectural decision to place the interaction between those components within a common address space. •
Mediation-Accounting Interface I-MA (AIP): Usage data, which have been mediated after the data gathering has been performed, need to be transferred to the ICCAS. Therefore, a protocol is designed which defines rules and transmission units for transferring mediated data to the accounting component. Since the anticipated load for this interface will be high, the protocol must be highly effi-
•
Billing-ICCAS Interface I-BI (AIP): This interface between the ICCAS and a billing component provides the access of billing institutions. It supports facilities to clearly identify customers and enterprises in financial terms and is responsible for accessing economic accounting tasks. Furthermore, it identifies the offered service. This is done by giving it an ID (corresponding to the one in the charging data base) and by attaching all requested for characteristics of the service. The service contract ID and the costs are as well passed to the interface. The contract can be used by the billing component to legitimate and detail a list of costs. According to Figure 4, the I-BI needs to receive not only charges for each customer to create a bill, but also all Cumulus Points for a current billing
period (cf. Section 3 and [9] for the Cumulus Pricing Scheme). The numbers of Cumulus Points to be sent are calculated in the charge calculation component. ICCAS
Charge Calculation-Pricing I-CP (AIP): Pricing is responsible for setting the prices used by the charge calculation component, therefore, this interface is used to send the calculated prices to the charge calculation component. The ICCAS requires input from the pricing component, in particular details on prices and tariffs for services. A generic way to exchange this price information between different participants is defined, allowing for the widest scope of information, yet efficient transmission. Charge calculation-relevant details for this protocol encompass the following ones: (a) Memory-efficient data structure for prices and tariffs. (b) Processing-efficient data structures (context-free) for prices and tariffs. (c) Inclusion of customer and/or user identification information for prices and tariffs. Since the pricing does not reflect a full and selfexisting component as such, rather a well-defined means for communicating prices and tariffs across networks and between components, the software-based interfaces between the “hosting” component and the pricing component are of local matter for these components only.
M I-CP 3 I-4
P r ic e
p r ic e - lis t
M
A
S
3 I - 1 6 I-FI
A C C
c c o u n t in g t e m p la t e s h a r g in g t e m p la t e s A v o lu m e s
C
P r ic e a Pricing lc u la t io n
c c o u n t in g
Figure 6: Feedback-ICCAS Interface (I-FI)
ulus Points
C A S
P r ic e C Pricing a lc u la tio n
Figure 5: Charge Calculation Pricing Interface (I-CP) •
A
Charge Data & Cum
Figure 4: I-BI Message Sequence Chart
C h a r g in g
h a r g in g
F e e d b a c k
Billing System
Periodic transmission of charging information
•
C
C
Feedback Interface I-FI (AIP): To set suitable prices the pricing component uses price models with various input variables. Some price models need usage or charge information as input variables, hence, these can be communicated to the pricing component via this interface. The feedback interface provides the necessary input for the pricing component to adapt and change prices according to the current network status. The feedback represents the status of the network in terms of resource usage, i.e. quantitative usage given by the amount and characteristic of the accounting and charging records, as well as in terms of the current charging and accounting policy.
•
QoS Interface (CPP): To provide services to the customer it is necessary to control the QoS component of routers. This interface can be used to set QoS parameters of routers, depending on the technology in place.
•
Enterprise Policy Control Interface (CPP): This is the interface for changing parameters of the ICCAS after the system has been deployed. By using this interface the enterprise policy control can install new services or request and receive charging or accounting data.
•
Service Interface (CPP): This interface can be used to read service definitions out of the service directory.
•
Host/Gateway Agent Interface (CPP): This interface is responsible for the optional communication with the customer. Mainly, this includes the selection of services the customer can use or the transfer of a feedback signal form the service provider to a user. This interface is open for future enhancements.
2.3
ICCAS Databases
Based on the description above, the following entities for storage purposes are identified, whose relationships are shown in the entity relationship diagram of Figure 7. Customers, users (accounts), contracts, sessions, resource usage, accounting data, charges, and bills are distinguished. They are required to perform ICCAS’s tasks. It is important to note that ISPs do not form an entity themselves due to the fact that each ISP will operate its own ICCAS. The initial set of attributes for each entity (marked boldface below) is defined as follows, while the primary key is set in italics. Additional attributes for entities may be added at a later stage. •
Customers: CustomerID, Customer’s Personal Information.
•
Users: UserID(Account).
•
Contracts: ContractID, QoSSpec, Tariff, ContractStatus.
•
Sessions: SessionID, TrafficDescriptor, StartTime, EndTime.
•
Resource Usage: MeteringHost, MeteringTime, TrafficDescriptor, ResourceUsage, MeasuredQoS.
•
Accounting Data: AccountingHost, TimeStamp, MeteringHost, MeteringTime, TrafficDescriptor, Resource-
Usage, MeasuredQoS, SessionStartFlag, SessionEndFlag, ChargedFlag. •
•
Charges: ChargingHost, TimeStamp, CustomerID, ContractID, UserID(Account), TrafficDescriptor, TotalResourceUsage, SessionQoS, ChargedTimeInterval, TariffApplied, Charge. Bills: BillingNo, BillingPeriod, CustomerID, User ID (Account), TotalResourceUsage, TariffApplied, Charge. 1 consumes
n
n Sessions
runs
1
1
accounted for
Resource Usage
Users (Accounts)
n
1
n 1 contains
Accounting Data
1 n produces
encompasses
n used to calculate
1
1 Charges
n
1 applies
n Contracts
1 bound to
Customers
1
n 1 details
n Bills
receives
Figure 7: Entity Relationships for ICCAS Databases Each of these entities can be represented as a single database table. By organizing the implementation of these entity attributes (except the bills entity), they are grouped into four different databases: Session Database, Customer Database, Accounting Database, and Charging Database. Each of these databases offers a certain set of functions. The Session Database contains all session descriptions that are finished already as well as those still running. A particular session is determined uniquely by a traffic descriptor and a start time. In case of IP traffic, the traffic descriptor can be made up of source and destination addresses, source and destination port numbers, and the service class the traffic belongs to. All sessions entities belong to this database. The Customer Database contains information on each customer who has contract(s) with the ISP. This information includes contract related information and customer’s personal information. Contract related informations cover particularly the agreed services, measured items, the tariff to be applied, and the legal issues. All customers, users, and contracts entities belong to this database. The Accounting Database saves all records collected through the mediation interface, which reflect the resource usage of sessions run by users. The resource usage and accounting data entities belong to this database. Finally, the Charging Database is used to save the charges calculated
by applying the agreed upon tariff to the accounted for data for each session of the users/customers. This database includes the charges entity.
3
Applying the Cumulus Pricing Scheme
The Cumulus Pricing Scheme (CPS) recently has been established [7], [9]. The driving rationale behind its design can be summarized as follows: Users generally appear to have a strong inclination towards flat-rate schemes, therefore, CPS originally offers a flat tariff, which has to be agreed upon in an initial traffic contract between customer and ISP, the so-called “CP Contract” (CPC) that may show the form of an SLA. This CPC contracts the size of expected resource requirements. On the other hand, pure flat-rate schemes have turned out to be infeasible, as they do not include any economic incentives. Hence, CPS allows the charge rate to be changed, if there is an obvious imbalance between the CPC and the actual resource usage. Again, for reasons of user acceptance, this imbalance is signalled repeatedly to the user, using so-called Cumulus Points (CP), which indicate over- or underutilization of resources with respect to the initial requirement’s declaration and are typically assigned on a rather long time-scale, e.g., monthly. Hence, the CP assignment takes place according to the so-called “CP Rule”[9], if the actual resource usage violates thresholds stated in the SLA, and the assignment should be based on monitoring of resource usage, where the manner in which measurements are performed is entirely up to the ISP. Receiving CPs requires no immediate reaction on the user side, i.e. the flat-rate remains stable, although the resource usage currently does not meet the original expectation. CPs appear in two flavors: red ones for over- and green ones for underutilization. They may be specified either as relative or absolute ones. They are accumulated over time. Eventually, if this accumulation violates a different threshold, a second rule, the “Reaction Rule”, states the imbalance between declaration and actual usage and urges the customer and the ISP to start a CPC renegotiation. Summarizing, the CPC fixes expected resource usage and a respective flat-rate. The actual consumption is monitored and in case of exceeding the initial specification, the user receives a monthly feedback in form of CPs. After a negotiated duration of n months, the accumulated balance of CPs may exceed the reaction threshold, thus, eventually requiring ISP and customer to adapt the CPC accordingly. Besides these essential determinations of CPS parameters and thresholds, which are depending on the application scenario and its SLAs, the ICCAS can be supported by existing technology. There are several products available, which are able to fulfill a subset of charging system functions, while
another important subset of functions has been implemented. A close networking hardware dependency is observed for the metering component. E.g., NetFlow [3] is able to collect and transmit flow data, if they are metered at Cisco routers. The open software solution NeTraMet [2] performs metering functions for a desktop computer. To handle information gained by the metering and process mediation tasks, the Smart Internet Usage (SIU) package [8] can be applied. SIU is able to access NetFlow routers directly and can be adapted to access a NeTraMet meter via the Simple Network Management Protocol (SNMP). However, one of the major restrictions imposed by these systems is the non-existence of a real-time capability, required for short-termed, feedback-driven, and usage-based pricing schemes. Measuring data only in the time-scale of seconds or even minutes, however, is not a problem with the integration of the ICCAS, DiffServ, and CPS. While the CPS has been designed with the end-customer and providers in mind, it also offers the major advantage to be implementable with metering technology available today, since it merely presupposes the existence of tools and means for metering and accounting traffic data without posing any critical requirement on their granularity (even if it is straightforward that fine-granular measurements will yield more precise results). Therefore, these longer time-scales due to technical feasibility do not yield a problem for CPS. Finally, the following considerations are to be taken into account in order to set up effective databases for the scenario of DiffServ with CPS: •
The traffic descriptor that is used to identify a certain traffic of a session comprises of source and destination IP addresses, source and destination port numbers, and DiffServ Code Points.
•
Users can be assigned fixed IP addresses to map sessions to users, otherwise dynamic IP addresses have to be saved together with the user identification each time this user initiates a session.
•
CPS thresholds are part of the contract information, which are to be stored together with the agreed upon service classes in the customer database.
•
Cumulus Points are calculated on a per-customer basis and stored in the charging database.
4
Summary and Conclusions
Driven by the need to charge for differentiated services separately and due to the support of transparent pricing models, a modular and flexible Charge Calculation and Accounting System for the Internet is required. The ICCAS developed so far, fulfills the core functionalities for charging Internet services
as well as for maintaining customer and contract-related data. Open interfaces for this ICCAS enable the interaction with different metering technology, a variety of user feedback schemes, many pricing models, and various billing systems. The ICCAS-internal databases implemented offer an extensible approach for the support of different Internet service parameters. As shown by the example application of the CPS scheme onto the ICCAS, these features of the ICCAS perform accordingly. Concluding this work, charging support for an ISP and its offered Internet services becomes a must as soon as differentiated services with varying QoS guarantees are offered and an economic incentive for their use is required. Future work on the ICCAS will follow an optimization of its implementation to allow for real-time feedback signals. Acknowledgements This work has been performed partially in the framework of the EU IST project Market Managed Multi-service Internet (M3I, IST-1999-11429), where the ETH Zürich has been funded by the Swiss Bundesministerium für Bildung und Wissenschaft, Bern, No. 99.0536, and partially in the framework of the Austrian Kplus Competence Center Program. References [1]
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. An Architecture for Differentiated Services; Internet Engineering Task Force, RFC 2475, December 1998. [2] N. Brownlee: Traffic Flow Measurement: Experiences with NeTraMet; Internet Engineering Task Force, RFC 2123, March 1997. [3] Cisco Systems: Service Providers New World News - Pricing for Profitability; Packet, Cisco Systems, 3rd Quarter 2000, pp 35 – 39. [4] R. Cocchi, D. Estrin, S. Shenker, L. Zhang: Pricing in Computer Networks: Motivation, Formulation and Example; IEEE/ACM Transactions on Networking, Vol. 1, No. 6, December 1993, pp 61 – 627. [5] R. Edell, P. P. Varaiya: Providing Internet Access: What we learn from the INDEX trial; Keynote Talk Infocom’99 New York, INDEX Project Report #99-010W. URL: http://www.index.berkeley.edu/99-010W. [6] M3I: Market Managed Multi-service Internet; 5th Framework EU Project No. IST-1999-11429, URL: http://www.m3i.org, July 2001. [7] P. Reichl, P. Flury, J. Gerke, B. Stiller: How to Overcome the Feasibility Problem for Tariffing Internet Services: The Cumulus Pricing Scheme; International Conference on Communications (ICC’01), Helsinki, Finland, June 11-15, 2001, pp 2079-2083. [8] SIU: Smart Internet Usage; Hewlett Packard, http://communications.hp.com/smartinternet/, January 2001. [9] B. Stiller, P. Reichl. J. Gerke, P. Flury: A Generic and Modular Internet Charging System for the Cumulus Pricing Scheme; Journal of Network and Systems Management, Vol. 3, No. 9, September 2001, pp 293-325. [10] B. Stiller, P. Reichl, S. Leinen: Pricing and Cost Recovery for Internet Services: Practical Review, Classification, and Application of Relevant Models; Netnomics - Economic Research and Electronic Networking, Vol. 3, No. 2, September 2001, pp 149-171. [11] B. Teitelbaum, P. Chimento: QBone Bandwidth Broker Work Group. URL: http://qbone.ctit.utwente.nl/BBroker/, Juli 2001.
