Arrow: A Flexible Architecture for an Accounting and. Charging Infrastructure in the Next Generation Internet. George Fankhauser, Burkhard Stiller, Bernhard ...
Arrow: A Flexible Architecture for an Accounting and Charging Infrastructure in the Next Generation Internet George Fankhauser, Burkhard Stiller, Bernhard Plattner Computer Engineering and Networks Laboratory, TIK Swiss Federal Institute of Technology, ETH Zürich, Gloriastrasse 35, CH–8092 Zürich, Switzerland Phone: +41 1 632 [7017 | 7016 | 7000], Fax: +41 1 632 1035 E-Mail: [gfa | stiller | plattner] @ tik.ee.ethz.ch
Abstract Current pricing and charging methods for the Internet are not based on actual usage of this service which leads to unfairness and more important, it does not deliver the right signals through financial incentives to network providers to upgrade critical links of their networks. The development of new multimedia applications and the convergence to an integrated services network will foster the tremendous growth of the Internet even more. With the Next Generation Internet not only technical services like bandwidth reservation will be introduced, but also new applications will emerge within the Internet. Charging the Internet in a fashion that provides feedback to users and providers has been proposed since the early ‘90s, however only a few implementations and real-world examples are known today. This is due to subsidizing the Internet in its early stages and due to a technical development that did not care much about charging. With the recent redesign of the Internet protocol suite and discussions on multiple service classes in the Internet, architectures for charging and accounting have to be revisited, too. Economic models for the Internet cannot be tested fully and validated in non-real-world environments, because of the unknown user behavior. With this uncertainty over what models and pricing schemes to choose, it is evident that a specific charging and accounting platform will never be accepted by the community. In this paper a novel and flexible architecture for charging and accounting is proposed that provides a wide range of mechanisms and lets researchers experiment in an environment as close as possible to the targeted system. As a first step four different pricing schemes are described and qualitatively assessed on the proposed platform. One of the economic models is based on different service classes including reservation and recalculates prices dynamically depending on the traffic situation. Keywords: Charging, Accounting, Pricing, Economic Models, Resource Reservation, Service Class Model, Quality-ofService (QoS), Communication Protocols, Internet, IPng/IPv6.
1. Introduction As the public funding of the Internet is currently being reduced and will cease completely in the near future, communication services being provided for Internet users will change. Interactive services and applications requiring high data-rates will not work satisfactory on overloaded links and even regular http-service or ftp can be annoyingly slow at peak-hours. To circumvent such situations, applications provide low-end options, e.g., chat programs instead of audio, to deliver services. The end-user is happy to receive a minimal quality at all instead of specifying what the information, presentation and duration of transmission is worth to him. Users should be able to favor one good over the other by buying it and the same mechanism would give service providers a clear picture of what links and services show real demand. It is more than doubtful if high-end services like telephony or video services based on reservations can be successfully deployed without using a sound economic model. The Next Generation Internet (NGI) initiative comprises a wide range of proposed service enhancements [Whit96]. It should provide for interactive media to promote education and entertainment programs and offer more bandwidth for applications in health care, research, and engineering. On the technical level, the most important novelties are the streamlined IPv6 protocol [DeHi95] with an 128 bit address space and new reservation based service classes. Additionally, a Resource Reservation Protocol (RSPV) [ZDES93] is intended to support guaranteed communication services. The goals for the NGI, which means new sorts of traffic requirements, higher bandwidth, and a new suite of protocols, influences the work of charging and accounting significantly.
1.1 Charging and Accounting in Integrated Services Packet Networks An infrastructure for charging and accounting is proposed throughout this paper. The developed concepts apply to the general notion of Integrated Services Packet Networks (ISPN), providing packet-based communication services. As a realistic example, technical and structural details are explained with reference to the Internet. Instead of refining the above mentioned reasons why future packet network architectures will benefit from charging, firstly, the reasons why a technical basis for charging has not been introduced in today’s popular packet-based protocols like the Internet Protocol (IP) are discussed.
First Berlin Internet Economics Workshop 97, October 24 – 25, 1997.
• Cost/bandwidth overhead: IP has been designed with the main goal of efficiency in mind; and it was government funded first. In addition, bandwidth was very limited as well as the number of users.
• Efficiency: The design for efficiency did not allow for any additional control overhead per packet or byte due to low speed routers and hosts, which lead to extremely high costs in processing non-data related information.
• Single service class: The initial goal was to send any type of information at any time and to keep the links always alive. Due to a single traffic type being communicated, a single service class model was sufficient.
• No Quality-of-Service (QoS): Flat service models include no QoS due to the only service provided by packetbased networks: best effort services. As a data stream is split into a number of packets, these packet traverse the network without any interrelation. However, modern data streams, e.g., for multimedia data such as audio or video, a timing relation between packets is mandatory to retain the original data stream behavior.
• Missing applications with a need for advanced QoS and service classes: As multimedia applications like streaming video, Internet telephony, or virtual environments using synchronous data streams evolved, traditional and mostly asynchronous communication services, such as e-mail, news, or file transfer, could not remain in a single service class.
• Lack of electronic payment systems: As charging and accounting requires the transmission of sensitive user data, e.g., payments, balances, or usage patterns, questions concerning the secure transmission of these data arise. Therefore, this can only be done thanks to recent advances in security research. Most of these topics that favored a minimalist charging solution, even a non-charging solution at all, for the Internet and its communication services, and will dramatically change in the very near future. Still, relying on Moore’s Law, processing capacity in routers and hosts has increased by a factor of more than 100 since the first routers were deployed on the ARPANET. Based on Hennessy’s observation of performance gains for microprocessors the actual speedup for the last 20 years is about 400 [Henn90]. Although traffic and, therefore, routing load increases on these devices, a better situation is obtained regarding processing and monitoring of traffic flows. The elegant and simple design of IP, providing a single best-effort service class, is still attractive, but has shown its drawbacks, when new interactive media services were introduced. On one hand, the attempt to design adaptive multimedia applications [Erik94] showed some advances, but still does not match the quality of paying customer’s demands. On the other hand, high quality transmissions over dedicated lines and reserved capacity are limited to those few users connected to such networks. Recent advances in resource reservation techniques, such as RSVP [ZDES93], running on top of the Internet Protocol, are very promising, but from the economic point of view, they will not be able to solve the problem of congested and overloaded networks in peak hours and on links with high demand. Once these reservation protocols are widespread, only a few users will be able to get admission and most requests have to be rejected, since users who pay flat-rate or low connection time charges will always try to get a better or the best QoS. Users’ behavior will be purely greedy, as human beings are always interested in getting the most. Because of the cost in maintaining traditional networks for audio and video services, such as telephony, broadcast, cable, and satellite, and the much faster growth of packet data networks, a transition can be seen from old traditional services to ISPNs. Recently obtained numbers of about 4% annual growth for telephony networks vs. 40% growth for data networks [Tenn96] will make the shift of traditional services necessary due to higher maintenance cost per bandwidth required at telecommunication providers 1. This is based on the fact that maintenance and personnel cost increase slower than bandwidth. When the majority of telephone connections will be made over packet switched data networks, at the latest it has to be faced the problem of guaranteeing services to customers that were used to pay and of course to receive a stable and expected QoS. Obviously, the increasing demand for packet-based services will result in an increased congestion of network resources, particularly, if these communication services are cheaper or even free of charge.
1.2 The Need for a Flexible Charging and Accounting Infrastructure Following these recognized changing demeanor of Internet users, the only solution for providing a stable and suitable network for all users is to charge communication services. However, this simple answer does not supply the technical solution on charging. It is required to exactly determine mechanisms that are needed to implement the variety of charging methods and economic models suitable for packet-based communications. The ‘ideal’ economic model has not been found yet, and it is not known how complex it may be or what charging information will be needed. For example, it is not clear if and how frequent the charging platform must recalculate
1. Data collected by the World Trade Organization and the International Telecommunication Union show a worldwide subscriber growth of 6% per year (9% per year with mobile phones) for phone lines between 1990 and 1996 [Wire97].
2
prices and on what type of traffic or traffic information the price decision is based. The Smart Market model [MaVa94] for example imposes an additional load on routers, when congestion occurs by auctioning off queueing priorities. Other models will introduce an additional load at all times but keep the prices fixed. Charging and pricing is, depending on the models used, also changing with the load on a network or with the configuration changes on the network’s topology. Many theoretical studies have been produced, some are based on service class models [SCEH96], [CESZ91], and [CSEZ93] and others on auction-based priority models. However, the implementations in some countries or organizations with high link costs due to their geographic circumstances are rather simple in contrast to theoretical approaches. These implementations are based on statistical sampling of user data due to the expensive measurement in terms of a true packet count, e.g., per end-user. In connection-oriented networks, including virtual connections, like X.25 or ATM (Asynchronous Transfer Mode), charging and accounting is much simpler, but the models applied are based on fixed prices depending on the time of using a connection and its duration. Available implementations of these methods are significantly specialized and highly optimized, such as built into the softand hardware kernel of switches or routers [EMVa95]. A traditional example provides the telephone network. Assuming the dramatic ongoing evolution of multimedia applications and their stimulating communication services, a multi-service class model for a packet network is essential. However, a very difficult problem has to be faced. If a scheme that is fair and driven by users bandwidth consumption is intended, metering, monitoring, accounting, charging, and billing of network transport services or, generally, communication support services have to be provided efficiently for all types of traffic. Network related issues, however, are not sufficient. Economic models are required to determine clearly the dependence between mechanisms that ascertain the price for a communication service in a particular situation and parameters that are technologically monitorable to specify this situation sufficiently. For instance, if a congestion can be detected at a certain point of time (networking issue), a per service class increase of its price (economic issue) has to specify the demand and supply situation. Therefore, economic models have to be based on network models, i.e. on the goods they describe. Nevertheless, internally they may offer different methods, e.g., fixed price vs. auction-based pricing vs. time-of-day pricing. The network model itself implies charging mechanisms. From best-effort to hard guaranteed services and from connection-oriented to connectionless traffic, these different service and traffic behaviors must be supported integratively. In addition, as the ultimate economic model has not yet been described, implemented, and tested, assuming fixed and rigid models, methods, and mechanisms is quite dangerous. Investments in routers and their hard- and software are high and they take months or even years to be installed on the Internet. This product propagation delay increases the total cost for such operations and it is very difficult to be estimated correctly. Assuming that the shift towards an integrated services network will happen and the more efficient way of charging for the service classes separately will be chosen, it is also quite probable that charging mechanisms used will differ. For example, reservations made via RSVP attach a flow-label to all datagrams. This label reduces the charging overhead significantly. In contrast, traditional best-effort services will not include such a label and may have to be charged by sampling packets.
1.3 An Integrated Platform for Charging and Accounting Infrastructure To provide such a platform, several well-known and some emerging techniques are studied for their suitability. The methods used, base on Internet standards wherever possible. Of course, many new and testing-platform specific features will be added, but in a controlled and modular fashion. The proposed architecture Arrow for an integrated platform for charging and accounting is placed on an IPv6 toolkit Crossbow [DWDA97] which provides for an implementation and testbed with basic IPv6 functionality. In addition, it offers runtime reconfigurability and loadable modules to inject low-level functionality like filters, monitors, and schedulers into the core of hosts and routers protocol stacks (kernel space). To implement a charging policy a similar module mechanism is available at a higher layer in user space. The transport of modules across the network could be foreseen in an Active Network type of fashion, but is still under consideration. All these mechanisms are targeted to routers and switches which will implement the larger part of charging and accounting systems. Nevertheless, certain charging techniques will also require hosts to manipulate packets at lower layers, e.g., tagging or insertion of electronic payments, and will take advantage of Crossbow. It has to be noted that any time-consuming activities per packet within routers have to be omitted for performance reasons, whereas hosts may take advantage of the full capabilities of existing and future end-to-end protocols. Once charged, this information has to be collected to be used for billing purposes. To transport control information for charging, including current prices and accounting records, a flexible control protocol is used. Part of this information/functionality is accessible via an application programming interface that is used by clients for, e.g., pricing feedback, by servers for, e.g., reverse charging, by routers for, e.g., control, prices, and accounting records, 3
and accounting/controlling systems. The implementation of this control protocol may be based on distributed object technology, particularly due to its suitability for handling data remotely by a set of well-known methods.
1.4 Outline This paper is structured as follows. Section 2 presents an overview of related work covering network models, charging and accounting infrastructures, and economic models summarizing pricing, accounting, and billing mechanisms as charging-relevant mechanisms. A few typical economic models are selected for a classification by their requirements. Section 3 discusses a detailed description of the charging and accounting infrastructure, its components, and an example of how a development platform is implemented for experimenting with charging and accounting. Moreover, Section 4 outlines the developed economic model, maps it onto the versatile charging and accounting infrastructure and, additionally, discusses the possible use of existing economic models in the designed infrastructure. Finally, Section 5 draws preliminary conclusions and briefly touches future work.
2. Related Work Frameworks for charging and accounting include two different models, the network model and the economic model. Both are supported by the infrastructure required to obtain accounting and charging information which includes local mechanisms, such as filter and monitors, as well as global protocols, such as for collecting charging information, and electronic payment systems.
2.1 Network Model Network models in use within related work concern packet-based networks. They define the types of nodes being used in these networks and certain topology and functionalities. Initial brief definitions are required to follow a concise comparison of various approaches. Due to the focus on packet-based networks, network nodes are referred to as routers and are sometimes called switches. They exchange data across the network, involving one or many routers on its route. Data belonging to a particular data source and being interrelated in terms of certain Quality-of-Service (QoS) requirements define a flow. Flows may be identified by a unique flow label, visible to hosts and routers by some identification tag or number. The next generation version of the Internet Protocol, IPv6 [BrMa95], [DeHi95], serves this identification possibility. Application
Application Communication Protocols (End-to-End)
QoS
Reservation Protocols
Reservation Protocols
Reservation Protocols
QoS
Flow(s)
Flow(s)
Flow(s)
Flow(s)
Host
Router
Router
Host
Figure 1. Components of the network model QoS requirements are specified by applications, such as throughput, reliability, and delay, and may be needed to be translated into network-relevant parameters. If guarantees are required for a specific flow, resource reservation is required within the host and the network. Omitting the task of reserving resources within hosts, which is a local matter only, this leads to a demand for resource reservation protocols, such as the protocol RSVP [ZDES93]. These reservation protocols ask for the reservation of resources within the network, specifically on routers, e.g., in terms of link bandwidth, buffers, and processing time. A local resource manager, similar to the one available in hosts, deals with this requests and accepts or rejects them. Having this infrastructure in place allows for the delivery of a variety of communication services, in conjunction with communication protocols responsible for data transport and resource management protocols. This covers as within traditional communication systems besteffort services and, newly achieved, guaranteed services. Depending on the strategies utilized, deterministic or hard guarantees as well as statistic or soft guarantees can be obtained from applications.
2.1.1 Infrastructure for Charging and Accounting Charging and accounting requires support within routers and hosts. This support is of local and remote matter, including filters and monitors, schedulers and policy modules as shown in Figure 2. Application programming interfaces (API) are required to collect relevant data monitored within the router or a host. In addition, charging and accounting protocols define the architecture to be integrated into current network and communication proto4
cols. The mechanisms used for charging and accounting will be discussed bottom-up with some cross references between the layers or mechanisms used in several layers. Applications
API
API Admission Control
Reservation
Price Determination
API
API
Accounting
Billing
Policing Filtering
Monitoring
Scheduling
Charging
API: Application Programming Interface
Figure 2. General model of the infrastructure for charging and accounting
2.1.2 Reservation Reservation application programming interfaces (API) define the set of QoS parameters that model a possible reservation request. In addition, a specific reservation model outlines the mechanisms required for implementing the reservation and corresponding access control functions. Admission control is necessary to avoid congestion of the network by checking flow requests in advance before admitting them network access. Normally, this admission control and the reservation is based on traffic characteristics the requesting flow demands. Defining a common agreement between a host and the network, which may be the nearest router, a traffic contract is setup. Specifications obtained in this contract are used from the network to police the actual application’s behavior. The current version of a resource reservation protocol within a packet-based network, particularly the Internet, is the above mentioned RSVP [ZDES93], which does not specify QoS parameters, but a set of mechanisms that provide the potential to reserve resources for all kinds of current and future flow characteristics. This concept of virtual connections with specific requirements follows in principle the one adopted within the older ST-II protocol. Current semantics of the RSVP reservation model define a token bucket scheme with a maximal message transfer unit size [Wroc96]. Besides the token bucket size and rate, a peak rate, the minimum policing unit and the maximum datagram size are defined. These parameters encompass a traffic specification, being part of a traffic contract. In addition, a receiver specification with a rate and a slack term are included. For the cell-based approach, the Asynchronous Transfer Mode (ATM) provides similarly to RSVP a connectionoriented technology for defining QoS parameters that allow for the reservation of resources within the network. The ITU-T Recommendation I.356 [I.356] enlists some parameters that define implicitly necessary resources requested for. These parameters encompass exemplarily cell error ratio, cell loss ratio, cell misinsertion rate, cell transfer delay, and cell delay variation.
2.1.3 Monitoring and Filtering Charging is based on metering the usage of network resources. Monitoring describes the lowest layer of the infrastructure required where, information is gathered about what happens in a network. In the packet-based network architecture, e.g., the Internet, monitoring is based on packets or datagrams that travel independently through the network. These packets contain information about the amount of data transferred and allow to count the number of bytes sent. Monitoring packets itself is not difficult. It rather depends on the processing that is done on these packets and, therefore, sampling the packets may be an alternative to strictly counting packets. These mechanisms are quite common and are used to implement volume-based charging. Other models concentrate on priority or congestion resolution which requires the monitoring layer to obtain information about many packets, e.g., those in a full input queue, on certain conditions. The information required by charging and accounting and these conditions must be freely configurable. Packets must not only be counted or presented to the upper layers, they must also be filtered which means the important information must be extracted from the packet. This may range from a priority bit to electronic-money stored in the packet. IPv6 in conjunction with RSVP will use a meaningful flow-label. The presence of a flow allows a router to filter and count packets that belong to a certain reservation, normally a service class which is distinguished from the usual best-effort packets in terms of resources required and, as later on discussed, of prices for these resources.
2.1.4 Policy Modules and Schedulers Price determination is included in exchangeable policy modules which comprise more or less complexity depending on the pricing model used, e.g., dynamic vs. static prices. Pricing may also require statistical information 5
about the network load or remote input, when pricing information is received from a server or calculated in a distributed fashion. The results have to be made available to the charging modules and the accounting API for a possible export to other hosts and routers. In order to enforce the policy module’s price decision which traffic to prioritize, a scheduler is needed that interfaces to low level mechanisms like direct queue control and does understand the meaning of price tags and possible service class information attached to packets.
2.1.5 Charging and Accounting The process of detecting the particular utilization of network resources is referred to as accounting. This includes tasks such as recording an item or a certain resource as an expense, debt, obligation, or liability. The task of charging defines the accumulation of accounted for information and an individual association with a consumer or user. Systems for recording and summarizing business and financial transactions and analyzing, verifying, and reporting these results are potentially included. A global consolidation of per consumer accounted information is termed controlling. This may be used for invoicing, but also planning and budgeting. The actual charging happens, when the monitored and filtered resource is charged to someone’s account. This may be just a temporary holding of information to summarize resource usage or a long-living database to obtain statistics of the resource usage itself. In the context of the basic Internet protocols the association between account and packet is based on the sender/destination address pair, a sender/destination port pair, or the flow-label. The port assignment is not very relevant, since there are only a few well-known ports that feature a particular service class, e.g., e-mail based on Simple Mail Transfer Protocol (SMTP). In addition, further problems occur. Forwarding messages by a mail daemon prevents end-to-end charging. Addresses may be used to charge for host-to-host traffic or the granularity is increased to subnets. However, a general solution has not been defined yet. Therefore, additional options in headers, e.g., IPv6 options may contain priority information, user authentication/identification, or payment information, can be used for charging and accounting purposes.
2.1.6 Billing Finally, the task of sending an invoice to a customer on a periodic basis is referred to as billing. This process is initiated by charging, accounting, or controlling, depending on the level of aggregation and cycle length of the billing periods, such as the total amount of business or investments within a given period. From traditional paperbased billing with a high cost-overhead to modern micro-payment schemes to wire smallest amounts of money between parties, many billing options are available and can, besides performance issues, hidden behind a general software interface (API). Even stamp-like approaches with electronic money attached to data packets are considered, however, here the problem of refunding has to be faced in case of non-conforming behavior compared to the traffic and service contract.
2.2 Economic Models A classification of economic models regarding their technical prerequisites, such as number of buffers, size of memory, code, scheduler algorithm applied, and filters in use, determines the interdependency between a particular network model, including host and router architectures, and the parameters utilized in the economic model. However, before these interdependencies are discussed, three important mechanisms within economic models are introduced first and pricing models within related work are discussed regarding their infrastructural needs.
2.2.1 Price Determination If the price to be paid in each available service class is not fixed, the charging platform may need to react to each packet which arrives or may take samples. In addition, if new flows are created indicating a traffic change also, the charging platform has to determine a price that reflects the current real-time or averaged resource usage and a fair market price. The calculation of a new price may only depend on local information as within the Smart Market model (cf. Paragraph 2.2.4.2), but pricing schemes are not excluded a priori that propose centralized or distributed, i.e. remote, price determination. Deciding which packets receive priority handling in case of insufficient resources, requires information from the monitoring modules. After the decision is made low-level modules, such as queues and typically packet schedulers, make this decision happen. All variable priced models may wish to give the price feedback to users or applications to let them decide, whether they want to continue the communications at the current price or whether they have to change it.
2.2.2 Accounting Accounting is the collection and aggregation of charging information, usually determined in monetary units. For simple setups charging can produce directly the correct sums due. For real-life networks with multiple hops and
6
complicated structures, accounting becomes a necessity. Basically, the accounting task collects what was summarized by the charging mechanism and resets these temporary accounts. Important for the platform is the frequency with which accounting is performed. The fact, if accounting is centralized or distributed, has an impact on the charging and accounting platform, too, but information centralization occurs at latest at user accounts. Accounting granularity can be viewed as a trade-off between the cost and performance of provider’s accounting systems and cost incurred to users in the form of additional fees or inconvenient or unclear billing information.
2.2.3 Billing Billing can be performed at several levels. One can think of billing packets directly or paying for stamps that are attached to the packets. Such an extreme would require a lowest-overhead micro-payment scheme. At the layer or boundary of charging and accounting, billing is possible from each node which moves the accounting duty to the user’s account and still has a significant overhead. When these amounts are collected first and an aggregated bill, e.g., per service used or per time-quantum, is sent to the user, the billing overhead is reduced by introducing additional accounting activities.
2.2.4 Economic Models for the Internet In this subsection a brief overview is given on technical requirements for theoretical pricing models. 2.2.4.1 A Priority Based Pricing Scheme A priority-based multiple service class network architecture with separate fixed prices set for each class is proposed in [CESZ91] and [CSEZ93]. The IPv4 protocol header defines bits to distinguish priority classes and even offers two bits for future usage [Post81]. These four service classes described offer the combination of two properties: Traffic may be prioritized in queues to reduce latency and packets may not be dropped from congested queues as long as there are other packets without having this bit set. Prices for these service classes correspond to the number of priority bits set (0 to 2) plus an amount for the lowest priority service class. Since prices are fixed over a considerable period of time no special policy or price determination module is needed. For flexibility, simple pricing updates, e.g., infrequent ones via an accounting protocol, are sufficient. For this type of model, packet schedulers which implement the priority ordering and drop/no-drop decisions require an efficient implementation. The actual charging needs the same priority information, e.g., from tagged packets or separate queues, and the association identification to map the packet- or byte-count to a temporary account. 2.2.4.2 The Smart Market Model A model has been developed that calculates prices by conducting second price auctions for packets arriving at a congested router [MaVa94]. The goods available are the slots in the queue of the output interface. While service classes are not introduced explicitly, a fine grained priority scheme is automatically created by choosing different monetary values for different packets. In contrast to fixed price models, a Smart Market reevaluates prices for each packet which arrives in a router in case of congestion. The mechanisms needed to implement the model include a header-processor that extracts the bid from the packet and forwards it to the packet scheduler and policy module which holds the auction among competing requests for transmission. Once a packet is allowed to pass through the router the monetary value determined by the auction is charged to the account associated with the packet. 2.2.4.3 Expected Capacity Allocation Model A pricing model as proposed in [Clar95] is based on a contract between user and provider for a specified bandwidth, the expected capacity. Some of those ideas were revisited for a new proposal termed Edge Pricing [SCEH96]. At network access points actual traffic is metered and tagged according to the conformance or nonconformance to the contract. Packets are either in or out of the specified envelope of the expected capacity. Although this model charges traffic only that causes congestion (other traffic is covered by a flat-rate), all metered packets must be tagged with in or out labels. Later, when a router becomes congested, these tags are examined and packets being out trigger a congestion indication which is sent back to the traffic source. In this case, priority queuing could be implemented, but was abandoned to preserve simplicity of the implementation. The process of tagging packets being in determines the user profile and may take several forms and implementations. Network users are charged directly for their profile which determines how many packets and in what intervals are tagged in.
7
3. A Flexible Infrastructure for Charging and Accounting The charging and accounting infrastructure Arrow has been designed defining an architecture and its components. A framework introduces the network and service class model in use on which economic models resides. Arrow is refined by a policy and a processing layer that are supported by the accounting protocol and required application programming interfaces for accounting, reservation, and billing. Finally, these concepts are applied to a development platform that is based on Crossbow.
3.1 Framework Overview The network model for the defined framework covers the principles as depicted in Figure 3(a). The considered network consists of a core network, including an arbitrary number of routers and an arbitrary but fixed number of access networks. Each of this access networks owns a dedicated router that interconnects the access network with the core. The core network may be a public backbone network and access networks may be of private administration. A typical network configuration connects several local area access networks with hosts to the core network. The two types of networks have very different technical and economic characteristics. Service Class
Access Network Host
Best-effort / Priorities
Core Network
(a)
Low
Host
(b)
Figure 3. (a) A typical network configuration
High
Guaranteed
Soft
Hard
(Statistical)
(Deterministic)
(b) A general service class model
The service class model covers different classes of traffic being supported. Two top-level classes are distinguished, the best-effort classes and guaranteed service classes. The best-effort service is further divided between 1 and n priorities and the guaranteed classes offer 1 to n levels of guarantee, specifically soft to hard or statistical to deterministic guarantees. As an example for these studies a model with four classes combines variety with low complexity (cf. Figure 3(b)). It includes the deterministically guaranteed service class, the statistical service class, a high-priority best-effort service class, and a low-priority service class. Every packet being sent across network boundaries belongs to a certain flow that determines explicitly which service class it belongs to. For instance, RSVP allows for the determination of flows with an explicit flow label that in turn expresses a specific service class. Based on these classes of flow labels, every router maintains different queues for incoming packets according to the number of service classes. A packet scheduler within the router forwards packets according to their overall priority which is determined due to the following order. The priority of deterministically guaranteed services is always higher than of statistically guaranteed services which, in turn, is always higher than high-priority besteffort services and in turn higher than low-priority best-effort service. Within these queues a First-In First-Out scheme is applied, keeping the sequence of incoming packets untouched per service class. Finally, the economic model resides on top of the network model, which bases on an infrastructure that provides for efficient metering and scheduling by injection of arbitrary modules for charging and accounting mechanisms as well as policy modules. It has to be noted that the economic model is freely selectable, if the relevant parameters, such as bandwidth, delay, or error-rate, required for input are obtained from the network model. Even more, the economic model may be different for the above mentioned core and access networks. Due to a statistical gain achieved on high-speed backbone links, a number of meaningful parameters may be achieved that is not available within the small access networks. Therefore, a flat rate access price may be determined for the local bandwidth consumed and a differently defined pricing scheme may be applied, e.g., a time-based, usage-based, volumebased, or destination-based.
3.2 Architectural Components Components used for such a network and service class model are discussed. Across the network, for hosts, routers, and accounting systems three layers implement the functionality for charging and accounting. Firstly, the accounting protocol and API layer implements the communication between routers and accounting systems to collect the charged information and between hosts and routers to forward out-of-band pricing information, e.g., price feedback. Secondly, a policy layer located in routers and in some cases also in hosts implements the pricing models, and thirdly, a processing layer contains various low level modules like filters and schedulers. 8
3.2.1 Accounting Protocols and Relevant APIs Assuming the style of a control protocol in packet-based networks, the accounting protocol is used to exchange the following information:
• Accounting records are exchanged between charging systems (routers) and accounting systems. Such records may contain the identification of flows, the current resource usage, or particular user information associated with this flow. Further information elements are under study.
• Since the association of traffic and chargeable entities comprising of users or corporations is dynamically changing information, this must be transmitted by the accounting protocol also. Furthermore, this information is critical in terms of security and requires proper authentication and secure transport.
• For pricing models that assume a fixed or a base-price, pricing information must be transmitted initially or on a regular basis. Dynamic algorithms that do not operate on local pricing information require this feature, too. The reservation API which uses a reservation protocol of the integrated services network such as RSVP provides the functionality to specify the service class which is mapped to the proper QoS parameters. For RSVP, the proposed API [BrHo97] and its correspondence with service classes [Wroc96] can be used for charging reservation based network services. Billing APIs are mainly used to translate accounted information into financial transactions. Depending on the overhead of the billing it is applied more or less frequently. If billing was very inexpensive, routers could charge and bill in the same cycle which would eliminate accounting. In practice, however, such a scheme is not realistic and billing is fed with data from the accounting entities. APIs and protocols utilized in the area of electronic commerce are applicable for various billing schemes. For example, DigiCash’s Ecash offers a coin-based scheme with customer anonymity [Chau92]. However, verification of this cyber-money is required and the potential for duplicated information still exists. The advantage for including such a billing scheme is due to the possibility to integrate electronic money in the infrastructure.
3.2.2 Policy Layer Policy modules are used for the dynamic price determination. Economic models based on auctions or traffic-statistics require such modules to determine the current prices. This dynamic information is transferred via accounting protocols, used in other systems, and required in the lower layer modules like the packet scheduler. It has to be mentioned that the content of information being handled in the policy layer is based on parameters indicating the current network status (networking issue) and the pricing scheme (economic issue) applied. The network status may simply be defined by, e.g., an overload factor or bandwidth usage. Pricing information may be based as explained above, e.g., on data volume, resource usage, or service classes. In addition, statistic modules keep track of the bandwidth used and allocated to service classes and flows. They are supported by a monitor within the host or router to obtain relevant numbers and utilization information. Again, economic models may recalculate their prices on this basis, e.g., traffic mean values over a certain time.
3.2.3 Processing Layer The processing layer consists of small, ideally optimized for performance, modules that work directly on packet data. To monitor traffic, packet filters provide a mechanism to detect packets early that fulfill a given set of conditions. Successfully detected packets receive additional information which facilitates later processing. Depending on how these conditions are set up, simple tag matching or table lookups are sufficient for filtering. However, the extraction of more complex information like IP options is also provided. Hosts as well as routers also provide for the inverse function of filtering, the insertion of tags. The general notion of tags refers to various kinds of packet header information like the IPv6 flow label or IP options. Tags to be applied depend on the application itself or on the type of access network. In any case, at the boundary between a private and a public network that is charged for, the router has to perform tagging of incoming packets to determine all flows traversing the core network. Finally, packet schedulers are embedded between resources they manage, such as queue control or switch control, and policy modules that may influence the scheduling decisions. Since packet schedulers are involved actively in the process of forwarding packets
3.3 A Development Platform Based on Crossbow This section describes the blueprint for the charging and accounting platform Arrow based on Crossbow [DWDA97]. The toolkit is built for general protocol testing and is used as a framework for testing and implementing charging and accounting in an IPv6 based network and provides necessary mechanisms for hosts and routers.
9
It provides a modular, but also efficient platform to load protocol modules into a NetBSD kernel running an IPv6 stack. Besides the IPv6 protocol stack the toolkit engine, as depicted in Figure 4(a), offers a module control unit and an association identification unit as pre-loaded components. Efficiency, modularity, and development convenience are achieved by module interfaces that are available in userand in kernel-space. Although access to packet data in user-space is much slower and not intended to be used for fully operational modules, the productivity gain while developing modules is significant.
Admission Control
Switch Control
Billing
Pricing
RSVP
Admission Control
Switch Control
API
API
Accounting
Traffic Generator
RSVP
Pricing
API
User Model
API
QoS Control Program
Applications
API
The basic idea of the toolkit is to detect flows as packets travel through the system. These flows consist of a sender and destination address and port-number, the input interface, and the protocol. Modules like filters, option processors, or charging modules are attached to the flow through the module control unit which in turn is programmed from the user-space control programs. If a reservation based service class is used, flows correspond to the flowlabel of the IPv6 packet.
Message Bus
User Space
User Space
Kernel Space
Kernel Space
(a)
ATM
(b)
Ethernet
Figure 4. (a) The architecture of Crossbow
Charging
Statistics
Policing Tagging
Ext. Head.
HSF: Hierarchical Scheduler Framework PS: Packet Scheduler
PS PS
Options
HSF
Flow Detection Filtering
Module2
Module1
IPv6
Association Identification
Module Control
Toolkit Engine
Association Identification Module Control
Scheduling
IPv6
Toolkit Engine
Socket & Transport Layer
Socket & Transport Layer
HSF PS PS
Host/Router/Switch Platform
(b) The Arrow charging and accounting architecture
The Arrow charging and accounting architecture based on Crossbow is divided along the user-kernel-space line as depicted in Figure 4(b). User-space programs implement the accounting protocol and API layer and portions of the policy layer (cf. Paragraphs 3.2.1 and 3.2.2). Between modules running in user-space two groups are further distinguished. Needed modules in a productive charging and accounting environment are pricing, accounting, billing, reservation, and admission control. Modules like traffic generators that implement a user model in terms of application requirements and financial capacity are treated like ordinary applications and rely on public APIs only. These types of modules are used mostly for testing and research. For such purposes, i.e. if billing information is rerouted, the billing module may be replaced by a monitor module that logs the output of tests and simulations. User modules communicate between each other through an RPC-based message bus. Communication between these high-level modules and the toolkit engine is established through a special socket type which is similar to the generalized routing sockets (PF_ROUTE). This solution was favored over a device driver or system calls, because the kernel part that provides for access to the kernel, i.e. the protocol stack and socket layer, is changed anyway. Modules running in kernel-space are part of the toolkit engine and implement the processing layer (cf. Paragraph 3.2.3). They encompass filters, option and extension-header processors, tagging modules needed for write access to the packet header, statistics collectors, and charging modules only. They operate directly on packets and are attached to a flow. A special kind of toolkit modules are schedulers which embed into the hierarchical scheduler framework (HSF). General methods like priority queues are part of the HSF. Kernel modules also serve the purpose of policy and statistics modules. Even they do not need to access packets directly, they are sufficiently often called by toolkit modules to justify their tight integration into the kernel. Again, such modules also run in user-space, e.g., for development and testing, and may be moved to kernel-space at any time. Charging based on flows that are detected and listed is an efficient technique. It is also proposed in [BMRu97] with the distinction that it proposes a rather general metering architecture for multiple protocols. In the context of Arrow, the association identification unit is designed to support flexible aggregation and multiple levels of indirection to accommodate most notions of accountable entities and accounting methods. Testing pricing models depends always on the load produced by users or traffic generators and on the configuration of the network. While the load is easily variable by introducing more and different traffic generators using synthetically generated traffic or captured traffic data, the configuration of the network is difficult and for larger topologies also very time consuming. For simulation tests, the Crossbow toolkit allows to configure hosts and routers with an arbitrary number of virtual interfaces which allows to build large virtual networks. 10
4. Implementation of Economic Models In this chapter economic models are discussed regarding their qualitative behavior in the Arrow charging and accounting infrastructure. A novel model is proposed first and the models described in Subsection 2.2 are applied to the framework afterwards. As far as these models are specified, a proposal is given on how to implement them and possible bottlenecks are discussed.
4.1 A Novel Economic Model The proposed network model provides four service classes as discussed in Subsection 2.1. A deterministically guaranteed service class (DG), a statistically guaranteed service class (SG), a best-effort service class with high priority (HP), and best-effort service class with low priority (LP). For the two guaranteed service classes an algorithm for resource reservation exists and the network architecture contains an admission control algorithm that determines which connection request to grant and which to deny. A connection request for a deterministically or statistically guaranteed service class is only granted, if no existing deterministic or statistic guaranteed connection is hurt. Best-effort service class packets are always admitted to the network, but they get passed along only, if no existing deterministically or statistically guaranteed connection is hurt (cf. Subsection 3.1). A portion of these algorithms is not only a test for admission in terms of network QoS parameters, but also a test in terms of payments. New connections set up by users that do not express their willingness to pay the current price are not admitted. A detailed description of the procedure applied to reserved traffic flows follows in Subsection 4.2. The price for a communication service depends on the price for the application and, if the network is congested, on a time-variable traffic factor [Müll97]. The base price for an application A is determined by the product of the base price for the required service class SC = {DG, SG, HP, LP} of the application and its data volume: applicationprice ( A ) = baseprice SC ⋅ throughput ( A ) ⋅ connectiontime ( A )
(1)
Base prices for service classes are expressed as monetary unit/bit with pricing relations of DG>SG> HP>LP. The traffic factor in a congested network depends on the difference between the actual throughput in a service class and the fairly allocated bandwidth to that service class at the time t. Fairly allocated means that the individual flows’ requested bandwidth at certain time is divided by the total bandwidth of all requests. The resulting bandwidth per service class is thus calculated by reducing the requests linearly by an overbooking ratio: totaldemand overbookingratio = ----------------------------------------------------availablebandwidth
(2)
requestedbandwidth SC bandwidth SC = -----------------------------------------------------------overbookingratio
(3)
Since the allocation of bandwidth starts with deterministic guarantees and ends with low priority traffic, it is possible that actual throughput in a certain service class deviates from the bandwidth allocated initially to that class. This difference between actual throughput used by all the communication partners of a single service class is compared with the bandwidth allocated to that service class. ∆bandwidth SC = throughput SC – bandwidth SC
(4)
A positive results indicates strong demand and provides a basis to calculate the traffic factor. To prevent the network from congestion, a penalty-function is applied, when the actual throughput is higher than the allocated bandwidth, resulting in higher prices. Therefore, the traffic factor is defined as: ˙ penaltyfunction ( ∆bandwidth SC ) ∆bandwidth SC > 0 trafficfactor SC = 1 ∆bandwidth SC ≤ 0
(5)
As an example, the following penalty function could be used, but any function raising faster than a linear one is applicable in practice, since the traffic factor is bigger than one, if and only if, the network is congested, else it is set to one and the preset base-prices apply. penaltyfunction ( x ) = ( x + 1 )
2
(6)
Applying Equations 1 and 5, the price for a communication service at time t, price(A,t) is given by the product of the price for the application and the traffic factor: price ( A, t )
= trafficfactor SC ( A ) ( t ) ⋅ applicationprice ( A ) 11
(7)
Base prices and bounds for different service classes have to be fixed quantitatively. Since this is depending on the user behavior and on the configuration of the network itself, these base prices have to be studied by simulation and observation of existing networks. It is noteworthy that the preset base prices are not required to remain the same over a longer period of time. For example, the common practice of setting time-of-day dependent prices could be used to offer more predictability, while the application of the traffic factor allows for short term pricing and overload avoidance, changing time-of-day prices let customers approximate their expenses better.
4.2 Implementation on Arrow To implement this pricing model on Arrow, different mechanisms are involved at the same time. The model distinguishes priorities for best-effort traffic and different levels of guarantees for reserved traffic flows. In Arrow’s simple model, the lower priority service class corresponds to best-effort traffic. High priority traffic is marked as such by tagging packets with a priority bit. This is performed at hosts which send packets. At routers along the path, packets are forwarded to the destination, incoming packets must be classified by filters (to implement the priority scheduling), and accounted for to charge the fees. For priority traffic, traffic factors for the two classes are calculated as floating averages changing with every arriving packet. Although overhead for per-packet charging seems high, most of the work must be done anyway. Classification and association with addresses, ports and interfaces is used for scheduling. The actual overhead is the association with an account to charge the packet. Furthermore, this accounting information has to be set up beforehand by the accounting protocol which includes authentication. Periodically, there is also a billing step which drains the temporary accounts at each router. The basic problem is rather the frequency at which this overhead occurs. It is proportional to the product of the number of hops on the traffics path and the number of packets sent. With a typical average packet size of about 200 Byte in today’s Internet, the cost to charge priority-based traffic is unfortunately very high compared to the worth it constitutes. Routers that charge for reservations need to filter and classify packets. In any case, a flow is associated with an RSVP-flow based on the flow label in IPv6 or a virtual flow for IPv4, and packets are fed into two queues which are operated separately by a specialized packet scheduler. In addition, routers must implement the reservation protocol and the admission control module. The traffic for each service class is monitored by a separate statistics module to calculate the traffic factor. This metering of traffic volume is one of the most problematic tasks in routers, especially on backbone links having packet rates in the millions per second and bit rates in the range of some Gbit/s. This problem can be eliminated, however, when reservations are used. Reserved resources describe the traffic volume (even if a statistical measure is used) and pin the path for a longer period. This allows for almost zero-overhead measurement on the backbone: Traffic metering is only performed at the edge of the networks, e.g., at ISPs, and by means of a control protocol. Meter messages are transferred to routers which charge for already accumulated volumes. The pricing information for application requirements (base prices) is fed into the system via an accounting protocol and the API to the charging module which can calculate actual prices from the amount of traffic, the traffic factor, and base-prices.
4.3 Applying Other Economic Models to Arrow This section gives a short description of architectural and implementation issues of pricing schemes described in Paragraph 2.2.4. Although none of these models include reservations, this shows the flexibility of the Arrow architecture and the potential as a future experimental platform.
4.3.1 A Priority-based Pricing Scheme As described in Paragraph 2.2.4.1 the priority-based pricing scheme model uses two bits in the IPv4 header to distinguish four service classes. For IPv6 the priority field or the flow label with a preceding message announcing the priority for a certain flow could be used to implement this pricing scheme. Host and routers using Arrow modules need to implement the following functionality:
• Applications setup a tagging module for their priority within the toolkit engine to mark all outgoing packets. • Using a static pricing scheme, the user level pricing module on routers receives current prices for all service classes via the accounting protocol or via the accounting API locally.
• Once packets arrive at routers, they are filtered and passed on to a priority packet scheduler. Successfully forwarded packets finally need to be charged according to the service class utilized. This type of pricing scheme could be implemented using standard modules from Arrow except for the charging module. However, due to the static price setup, the charging module’s functionality is quite simple. 12
4.3.2 The Smart Market Model To implement the Smart Market model in IPv6, the header must convey the bid-value for the auction in case of congestion. Because the range of the bid-values is usually longer than a few bits, a solution is to use IPv6 hop-byhop options (extension header 0) to forward bidding information with a TLV (Type-Length-Value) encoding. Note that this could be more critical in IPv4 with its 64 Byte header limitation which also comprises all options. Arrow modules used for a possible implementation are the following:
• Hosts need an option processor which fills in bid-values specified by applications or users. • Routers need a similar module to extract bids in case of congestion. Then, the scheduler, or more precisely a policy module conducts the auction to determine the price that the n highest bidders will pay (n is the queue length) and the scheduler allows these packets to be transmitted.
• The high-level pricing module in user-space is superfluous for the bidding process, but serves as a feedback link to inform the user about the cost.
• For successfully transmitted packets the charging module calculates the packet fee at the current price. The overhead for the price determination is rather high, since it is performed on a per-packet basis. Similar to volume-based sampling schemes, this model could also be implemented in a variation using packet sampling.
4.3.3 Expected Capacity Allocation Model The Expected Capacity Allocation model features also a form of prioritization of single packets. A single bit is needed to tag packets being in or out of the envelope of the allocated capacity (cf. Paragraph 2.2.4.3). This method could be mapped to the following Arrow modules:
• Routers at access networks create the envelope or user profile. This function could be specified as a policy module which needs to observe the users traffic flow (statistics module) and employs a tagging module to set the in/out bit. This procedure is applied to all packets.
• In addition, hosts can tag packets of lower importance with the out-bit which is never upgraded. • Routers inside the core network work in traditional best-effort mode. No priorities are applied, but in the case of congestion, a push-back message is sent to the sender if the packet is out. Packets inside the envelope do not generate push-back messages. This model is different, because it does not charge packets directly. It rather sets a price for the envelope set by a user which reduces the charging overhead significantly. The tagging of all packets according to the users contract is simpler than charging all packets, because it does not need to lookup any association identification tables.
5. Conclusions and Outlook The flexible architecture for charging and accounting Arrow has been proposed in this paper. The design of this framework separates high-level administrative tasks which have no special performance requirements from timecritical processing tasks that need direct packet access. The work on charging and accounting focussed on basic functionality. Charging and accounting relevant user modules, e.g., accounting or billing APIs, have been treated conceptually. Basic modules of Crossbow are almost completed and allow to implement charging modules. Three pricing models from the literature and a novel proposal of a pricing scheme have been selected and it has been described conceptually, how they could be implemented on Arrow. Although these models share many features, they are different to see the potential of the testbed for the implementation of future economic models. The proposed economic model covers an approach to develop a pricing scheme that is neither too simple nor too expensive for efficient implementation. Simulations or network tests are under its way to obtain actual numbers how the base prices of the four service classes should be set. Therefore, the qualitative analysis has shown that two major reasons favor charging of reserved resources. (1) It is technically feasible to implement charging with lowest overhead by using reservation style flows. (2) Since reserved resources are the most expensive ones, the focus is drawn on these pricy service classes. These reasons leave the economic question, if a mixed scheme of usage based pricing of reservations and flat-rated (or even free) best-effort traffic is a viable solution. Future work will be conducted in several fields. While the toolkit engine of Crossbow is nearly completed, Arrow higher-level modules including the APIs have to be implemented. The development platform will be refined in parallel with the goal to provide an efficient and flexible system to apply economic models on an NGI system and to implement and test new economic models. In addition, further developments will focus on quantitative terms of 13
pricing models as load distribution between service classes and real-world prices for various Internet services. Finally, some of related work models and the outlined development will be implemented for a range of situations with differing network load and different configurations. Depending on the adoption of IPv6, tests in a wide area range are being considered. In the long run, conclusive results from these tests are expected to be able to extract a pricing scheme that produces the best approximation of market prices at lowest infrastructural costs possible.
Acknowledgments The authors would like to thank the Crossbow team at ETH Zürich, Switzerland and Washington University, St. Louis, Missouri, U.S.A. for the discussions that helped to provide a modular development platform for Arrow.
References [BrMa95]
S. Bradner, A. Mankin: The Recommendation for the IP Next Generation Protocol; Request for Comments, RFC 1752, Internet Engineering Task Force, January 1995. [BrHo97] R. Braden, D. Hoffman: RAPI - An RSVP Application Programming Interface; Internet Draft, June 1997. [BSSh94] R. Braden, D. D. Clark, S. Shenker: Integrated Services in the Internet Architecture: An Overview; Request for Comments, RFC 1633, Internet Engineering Task Force, June 1994. [BMRu97] N. Brownlee, C. Mills, G. Ruth: Traffic Flow Measurement: Architecture; Request for Comments, RFC 2063, Internet Engineering Task Force, January 1997. [CaGu94] M. Carter, G. Guthrie: Pricing Internet: The New Zealand Experience; Department of Economics, University of Canterbury, Christchurch, New Zealand, December 1994. [CESZ91] R. Cocchi, D. Estrin, S. Shenker, L. Zhang: A Study of Priority Pricing in Multiple Service Class Networks; ACM Computer Communication Review, Vol. 21, No. 4, September 1991, pp 123-130. [Chau92] D. Chaum: Achieving Electronic Privacy; Scientific American, August 1992, pp 96-100. [Clar95] D. D. Clark: A Model for Cost Allocation and Pricing in the Internet; MIT Workshop on Internet Economics, March 1995. [CSEZ93] R. Cocchi, S. Shenker, D. Estrin, L. Zhang: Pricing in Computer Networks: Motivation, Formulation and Example; IEEE/ACM Transactions on Networking, Vol. 1, No. 6, December 1993, pp. 614-627. [DeHi95] S. Deering, R. Hinden: Internet Protocol, Version 6 (IPv6) Specification; Request for Comments, RFC 1883, Internet Engineering Task Force, December 1996. [DWDA97] D. Decasper, M. Waldvogel, Z. Dittia, H. Adiseshu, G. Parulkar, B. Plattner: Crossbow - A Toolkit for Integrated Services over Cell-Switched IPv6; Proceedings of the IEEE ATM'97 Workshop, Lisboa, Portugal, June 1997. [EMVa95] R. J. Edell, N. McKeown, P. P. Varaiya: Billing Users and Pricing for TCP; IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7, September 1995, pp 1162-1175. [Erik94] [EsZh90] [Henn90] [I.356] [MaVa94] [Müll97] [PKFe92] [Post81] [SCEH96] [Shen95] [Tenn96] [Wroc96] [Wire97] [Whit96] [ZDES93]
H. Eriksson: MBONE: The Multicast Backbone; Communications of the ACM, Vol. 37, No. 8, August 1994, pp 54-60. D. Estrin, L. Zhang: Design Considerations for Usage Accounting and Feedback in Internetworks; ACM Computer Communication Review, Vol. 20, No. 5, October 1990, pp 56-66. J. L. Hennessy: Computer Architecture, A Quantitative Approach; Morgan Kaufmann Publishers, San Mateo, California, U.S.A., 1990. International Telecommunication Union: B-ISDN ATM Layer Cell Transfer Performance; Recommendation I.356, November 1993. J. K. MacKie-Mason, H. R. Varian: Pricing the Internet; Technical Report, University of Michigan, Michigan, U.S.A., February 1994. M. Müller: Analyse und Entwurf von Tarifierungsmodellen für Kommunikationsdienste; Term Work, Institut für Technische Informatik und Kommunikationsnetze, TIK, ETH Zürich, Switzerland, Juni 1997. C. Parris, S. Keshav, D. Ferrari: A Framework for the Study of Pricing in Integrated Networks; Technical Report TR-92-016, International Computer Science Institute, Berkeley, California, U.S.A., March 1992. J. Postel: Internet Protocol, DARPA Internet Program Protocol Specification; Request for Comments, RFC 791, Internet Engineering Task Force, September 1981. S. Shenker, D. Clark, D. Estrin, S. Herzog: Pricing in Computer Networks: Reshaping the Research Agenda; ACM Computer Communication Review, Vol. 26, No. 2, April 1996, pp 19 – 43. S. Shenker: Service Models and Pricing Policies for an Integrated Services Internet; MIT Workshop on Internet Economics, March 1995. D. Tennenhouse: Personal communication; November 21, 1996. J. Wroclawski: The Use of RSVP with IETF Integrated Services; Internet Draft, September 1996. Wired Magazine: Raw Data: More Phones, More Money; No. 5.06, June 1997, p 80. The White House, Office of the Press Secretary: Background on Clinton-Gore Administrations Next-Generation Internet Initiative; Press Release, October 1996. L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala: RSVP: A New Resource Reservation Protocol; IEEE Networks Magazine, Vol. 31, No. 9, September 1993, pp 8-18.
14
