Open Charging and QoS Interfaces for IP Telephony
Burkhard Stiller, George Fankhauser, Gabriela Joller, Peter Reichl, Nathalie Weiler
Computer Engineering and Networks Laboratory TIK, ETH Zürich, Gloriastrasse 35, CH – 8092 Zürich, Switzerland, E-Mail: [ stiller | gfa | joller | reichl | weiler ]@tik.ee.ethz.chAbstract
IP (Internet Protocol) Telephony requires the support of guaranteed services and charging to provide a valu-able service for potential customers. It has to be consid-ered carefully, that the quality of long-distance telephony calls via the Internet is heavily affected by the load of the links which the call has to traverse. As these different quality requirements of users will exist, the Internet has to support different service classes. Therefore, an advanced services network model is required.
In turn, and that is the main motivation for this work, if at least two traffic classes will exist in the Internet, there must be the right incentive for any user to choose the traf-fic class which optimally fits his requirements and will be the most efficient one in terms of prices to be payed. Therefore, the integration of charging and Quality-of-Ser-vice (QoS) interfaces for IP telephony are important to stimulate future use of the Internet. This papers gives a first overview of OCIT (Open Charging Interfaces for IP Telephony), an experimental platform for standards-based IP phones that are enhanced with QoS and charg-ing support.
1
Introduction
Since public Internet access is determined by a high growth rate, the usage of this communication network for more than just traditional data applications increases as well. IP telephony is an example for advanced services on the Internet of the near future. IP (Internet Protocol) Tele-phony is one of the Internet applications which become popular for the following reasons. On one hand, the inte-gration of traditional well-known voice applications – e.g., the phone as an external device – with widespread data communication technology based on the Internet offers the potential for developing highly-integrated com-puter-based telephony applications. On the other hand, the costs for using conventional telephone network calls are quite high for long-distance and the international con-nections. IP Telephony promises to save considerable resources by multiplexing voice and data over the same network. However, audio quality in a pure best-effort net-work has been observed to become quite poor, especially in congested periods. It requires Quality-of-Service (QoS) support for network service to obtain an audio quality
which is similar to the one of a conventional phone call. In addition, compared to standard telephony, charging for services in the packet-based Internet remains still an open issue [13]. Suitable pricing models have to be developed for an application in the IP telephony domain. These models have to be integrated into current IP implementa-tions to allow for a practical charging and accounting approach for calls and services.
An off-the-shelf IP telephony product has been selected as an application base for the work presented in this paper. This selection is based on a survey of IP tele-phony products with respect to a potential integration of QoS and pricing interfaces into Application Programming Interfaces (API) [11]. The presented platform is called OCIT, “Open Charging Interfaces for IP Telephony”. It has been extended by an open charging and QoS inter-face. The charging interface and implementation has been developed from scratch, based on pre-investigated pricing model parameters and requirements including static and dynamic pricing approaches. The QoS interface uses a quasi-standard of a resource reservation protocol inter-face, namely RSVP (Resource Reservation Protocol). Based on a set of QoS parameters of this protocol and a particular user profile for telephony specifications, appro-priate cost and QoS mapping functions have been defined and evaluated in a prototype implementation. These map-ping functions allow for a range of QoS parameters to be specified. However, only a subset of these parameters is relevant and applicable to different costs models. RSVP has been extended with charging and accounting func-tionality, such as pricing information or price requests depending on the type of pricing model applied.
This paper is organized as follows. Section 2 intro-duces the networking model environment applied within this work. Based on these basics the design of the open charging and QoS interfaces are presented in Section 3. The implementation description in Section 4 is followed by conclusions in Section 5.
2
Environment
The networking environment chosen for OCIT is influenced by current and recent developments in the Internet. Particularly, IP forms the basis for the applica-tion of an IP phone. Since the convenapplica-tional Public Switched Telephone Network (PSTN) has already offered
voice service for several decades and is wide-spread, IP telephony is required to interact with this established net-work. Therefore, telephony devices, i.e., conventional phones, will be used in future communication in addition to Personal Computers (PC) or workstations. This already shows the need for an integrated hardware device for dealing with voice calls. In addition, exchange points of calls may be located within the PSTN or in the Internet, based on the kind of connectivity the user currently uses. Therefore, scenarios to be distinguished are (1) phone-to-phone, (2) phone-to-PC or PC-to-phone-to-phone, or (3) PC-to-PC communications. Details on these different cases and the problems to be solved can be found in [11]. In any of these scenarios, the question of charging phone calls requires the exchange of information at various points. However, due to the complete lack of any charging approaches in the current Internet, the problem to be solved is restricted in a first approach at this point to the pure PC-to-PC communication scenario, where no tradi-tional PSTN is involved, but a service integrated Internet is required. The IP telephony product used for this work is Netmeeting [12].
2.1 Internet Service Models
The current network model for the Internet is a pure best-effort network, since connectivity and ease of deployment have been the major driving forces in the Internet’s first days. However, as already mentioned, ser-vice integration becomes essential, especially for com-mercialized Internet usage. It is worth discussing this trend under different perspectives, e.g., ease-of-use, free availability, or globalization for everyone. However, the work described in this paper is concerned only with the technical implementation.
Service integration within the Internet is discussed for two cases: the Integrated Services model (IntServ) [3] and the Differentiated Services model (DiffServ) [2]. IntServ is based on the explicit reservation of network and end-system resources on hosts and routers to allow for the guarantee of services, particularly the guarantee of a pre-defined or negotiated set of QoS parameter values. The Resource Reservation Protocol RSVP [8] has been devel-oped in order to replace the ST-II reservation protocol due to its sender-based scheme, where different multicast receivers could not be supported efficiently. It allows for the specification of resources to be reserved as well as information to be exchanged concerning ongoing reserva-tions between participating hosts and routers. An RSVP signalling channel is used for setting up a specific path between sender and receiver. This path is determined by a set of QoS parameter values corresponding to sender’s and receiver’s requirements. Using a routing protocol resources are reserved along this path from the sender to the receiver. Especially, the RSVP signalling is used to
reserve resources along the path according to flow specifi-cations which require these resources.
Another approach to provide different Internet ser-vices is provided in terms of a backbone technology called DiffServ. While IntServ handles IP packets based on pre-negotiated data flow requirements, DiffServ ser-vices are based on contracted parameters which are pre-defined in terms of service profile [4]. These profiles allow for the marking of packets to be sent as in-profile, if profile limits are not violated. Otherwise, out-of-profile packets may be discarded within the DiffServ backbone, if congested periods occur. In addition, the idea for the backbone network includes the fact that these profiles are valid for a number of aggregated flows, showing similar behaviors and requirements. Since work in the IETF started at the end of 1997 and the proposed charging and QoS interfaces for IP telephony is based on available sig-nalling protocols in 1998 – and still there is no interopera-ble or feasiinteropera-ble DiffServ signalling today – features, functions, and interfaces at the host side will remain very similar to the solution discussed below [1].
3
Design Basics
The OCIT protocol architecture for IP telephony applications is based on the Integrated Services (IntServ) protocol stack to achieve the possible control of user requirements by means of a resource reservation protocol. Based on this protocol layering as depicted in Figure 1 the developed APIs for the IP telephony include the setting of user-driven parameters for telephony quality and the charging information (cf. Section 4.5 below).
Based on the availability of protocols and systems in support of IntServ, the Crossbow toolkit [5] provides a suitable design environment. Developed for the experi-mentation and impleexperi-mentation of Next Generation Inter-net protocols, IntServ mechanisms such as a packet classifier or packet filtering and scheduling on the host’s and router’s implementation platform have been investi-gated for their suitability for multimedia data transport and processing. Within this IP telephony work, the design and implementation environment has been applied to the Netmeeting IP Telephony application, the use of RSVP, and appropriate developed extensions for open charging
FIGURE 1. Protocol and System Architecture
RSVP (enhanced)
IP Protocol Reservation and Charging API
Netmeeting IP Telephony Application
Telephony Data QoS and
Data Charging
and QoS interfaces. For these reasons, the implementation of a simple version of RSVP as well as the porting of the full ISI RSVP implementation [8] to Crossbow, provide the excellent position for the design, implementation, and evaluation of IP telephony feature extensions in terms of the developed open charging and QoS interfaces.
3.1 Protocol Extensions
Current RSVP implementations do not support the exchange of charging or accounting information. RSVP used for OCIT has been extended by appropriate pricing and payment objects [7]. Figure 2 displays the objects necessary for the system extensions described in this paper.
These additional RSVP objects include:
• PRICE: This object is used for exchanging information on the current market price for reservations. Each hops adds its own current market price for the reservation to the price received from the previous hop. The sum is forwarded to the next hop. At the end of the chain, this sum amounts to the total price for the reservation queried.
• PAYER: The receiver-driven protocol RSVP should not allow only for receiver-payments, but should include both sender- and receiver- payments as well as a split of this payment between sender and receiver, e.g., according to a certain sender-to-receiver percentage measure. The system described in this paper uses the PAYER field to define the percentage payed by the sender and which optionally can be modified by the receiver.
• REQTYPE: This RSVP object is used with the semantics of distinguishing price queries for a specific reservation from the reservation message itself. • BID: The pricing models used include as one of the
options a pricing auction. The value of the BID field defines the actual bid, i.e. a value of ‘1’ is equivalent to 100% of the actual market price.
• PROVIDER: Certain payment systems implement the necessary security for transactions using provider keys. The PROVIDER field is used for storing such information.
3.2 Pricing Schemes
Two different dynamic pricing models have been implemented for OCIT. The “Smart Market” model [10] where each router regularly performs an n-fold second price auction (the resources are sold to the n highest bid-ders for the unit price bidder n+1 is willing to pay) has been refined in order to distribute the signalling overhead over time and to avoid reservation delays for routes com-prising several links. Hence, our “Delta Auction” approach processes requests as soon as they arrive whereas actual reservations are still performed after regu-lar periods of time [7]. Note that the resulting resource distribution turns out to be identical to the simple auction model. A second pricing model is based on offering dif-ferent service classes and charging an application the basic price of the respective class multiplied by a factor which increases quadratically as soon as the current throughput of the class excesses its allocated bandwidth.
Concerning the billing approach chosen, charging records are being collected within the router for every user. As it is described later in the implementation (cf. Section 4.4), the financial information as well as data on the IP telephone call are presented to the user within his user interface.
4
Implementation
The implementation of OCIT integrates charging into a network QoS framework and end-to-end resource reser-vations into an IP telephony application. The results obtained are based on experiments with two different pricing models, where the dynamic pricing method covers congestion-sensitive and usage-based components: • Prices based on auctions and
• Prices based on duration, quality, and data volume. For a qualified practical deployment, a graphical user interface is included in the system to offer all IP tele-phony users a set of QoS parameters and their pre-defined values as well as a feedback for current charges for the ongoing or finished call. This feedback mechanism defines an important aspect of user satisfaction evalua-tions, since a clearly subjective rating of IP telephony quality achieved and currently price charged are obtained.
4.1 Implementation Testbed
As an implementation platform for OCIT, a mix of off-the-shelf components and experimental systems has been chosen. Basically, the “edge” of the network is pop-ulated by personal computers (PC) using commercially
7 Length 2 0 Type IP Header RSVP Body R S V P Header R S V P Objects Pricing Objects PRICE Length 2 1 Type P A Y E R Length 2 2 Type R E Q T Y P E Length 2 3 Type BID Length 2 4 Type PROVIDER
available IP telephony software while the “core” of the network is built using experimental router platforms (cf. Figure 3). PCs are running Windows NT version 4.0 and Netmeeting as IP telephony software. This end-system setup is enhanced with telephony hardware connecting real handsets and a special version of the RSVP signalling software enhanced with charging functionality. It has to be noted that RSVP on these PCs does provide the neces-sary end-to-end signalling and charging solution, but does not implement traffic control, i.e. it does not reserve real network resources. Assuming overprovisioning in LAN-networks this functionality has been neglected intention-ally. Figure 3 shows a typical Internet telephony setup with the sender or caller (S), Internet Service Providers (ISP), and a receiver or callee (R). Standard H.323 mes-sages [9] are routed through a gatekeeper (G). A billing server is used for off-line collection of invoice data. Finally, ingress- (I) and egress-routers (E) at ISPs are responsible for RSVP signalling and collection of accounting data.
The core of the network is built on routers based on the NetBSD Unix operating system using the implemen-tation of router plug-ins [5] which implement fair queue-ing for appropriate traffic control and RSVP enhanced with charging to allow ISPs to enhance admission control with payments.
4.2 Signalling Phases
The introduction of dynamic QoS pricing schemes into a flat-fee based communication network like the Internet requires the possibility for an evaluation of actual market prices in order to judge as a user the following two aspects:
• Whether to make a reservation at all or • Which QoS class to choose.
Therefore, an additional, but optional phase has been introduced for OCIT, particularly keeping the current RSVP signalling phase-wise untouched. This so-called query phase introduces a second set of path and
reserva-tion messages for a complete call before the standard path and reservation messages are being exchanged. As a result of this extension, there are two phases for handling reservations (cf. Figure 4, grey shaded area).The query phase is considered optional and the reservation phase mandatory.
4.2.1 PATH Message
In conventional RSVP, the PATH message is used to determine the path for a flow. The sender sends a PATH message towards the receiver and the packet is routed through the network. Each hop on the path not only for-wards the PATH message, but also uses and modifies the PHOP_ADDRESS entry, determining the previous hop. The PHOP_ADDRESS of the received packet is stored as part of soft state in the router and maintained for a certain period. For the packet sent to the next hop, this entry is replaced by the hop’s own address. This results in a soft state chain for specific flows along the path from sender to receiver.
The semantics of the PATH message for the query phase is quite similar as for a standard RSVP reservation phase. The only difference is the new REQTYPE object which is used at the receiver to reply with the correct RESV message extension concerning the calculation of the current price (cf. below).
4.2.2 RESV Message
Due to the receiver-based reservation characteristics of RSVP, the actual reservation is made by the receiver by sending a RESV message back to the sender. This RESV message travels along exactly the same path in reverse order as the PATH message making use of each soft state PHOP_ADDRESS set on each router. On the arrival of a
FIGURE 3. A Typical Internet IP Telephony Setup
ISP 1 ISP n S I1 E1 In En R G B Audio Stream Billing Information RSVP with Charging H.323 Messages
FIGURE 4. The Two RSVP Phases.
Caller Gatekeeper Router at
ISP Billing Callee
[H.323] [H.323] [RSVP Quote Request] [H.323] [RSVP Quote] [H.323] [RSVP Quote Request] [flow id] [flow id] [RSVP Quote] [RSVP PATH] [RSVP RESV] [RSVP PATH] [RSVP RESV] [Billing Message]
RESV message, the forwarding router reacts by reserving the requested resources for the particular flow if available. The standard compliant result is a reserved path from sender to receiver.
For an optional price query the RESV message is extended by the REQTYPE object. Further on, additional objects are used for exchanging pricing information. Thus, each router on the path updates the entries accord-ing to their local pricaccord-ing characteristics, i.e. actual price for the requested reservation on the particular hop. This allows for the calculation of a price information for sender requests only. This price may change during the actual reservation in case of dynamic pricing models applied, since the market situation may have changed. During the regular reservation phase, this pricing calcula-tion is performed again, determining the final price for the upcoming reservation period as defined in the RSVP stan-dard.
4.3 A Signalling System for OCIT
The implementation platform of OCIT centers around a signalling system that integrates existing standards pro-tocols as well as new signalling propro-tocols that are needed for charging purposes. Figure 4 shows the integration of H.323, RSVP, and custome protocol extensions in a mes-sage sequence chart. As shown in Figure 5 the unmodified Netmeeting application is redirecting its H.323 signalling messages [9] to a gatekeeper which is usually located in the access providers network. The gatekeeper implements a fully functional H.323 proxy which allows for the anal-ysis of all H.323 protocol elements. It is used to detect the audio flow’s properties, in particular its bandwidth requirements and its flow-id consisting of the IP addresses, port numbers, and transport protocol
identifi-cation. This flow related information is signalled back to the end-systems where it is used to initiate appropriate resource reservations using the local RSVP API. Although there is a version of Netmeeting supporting native RSVP we chose to intercept H.323 messages in order to be application independent and to use our own RSVP version enhanced with charging objects on the end-systems. Note that the IP phone and the charging related processes on the end-system are completely decoupled. As depicted in Figure 5, an H.323 gatekeeper [9] with a proxy protocol stack is used to detect the flow-id of calls. On top of RSVP, charging messages signal the resource usage of each user to the ISPs.
The caller and callee processes, running in parallel to the IP phone applications, use the standard RSVP API to signal resource reservations. Also integrated into the caller and callee process are charging functions which are visible to the user. In the current prototype system no real and secure payment scheme has been implemented, there-fore accounting information such as money spent is dis-played only but not debited from a user’s account. Charging relevant information is embedded into an exten-sion of the RSVP API and further transported using opaque object extension in the RESV and PATH mes-sages (cf. Section 3).
4.4 API Extensions
As an extension of the Application Programming Interface (API) an approach using simple Java applets has been selected. It reflects the decoupling of H.323 signal-ling (session setup) and RSVP (resource reservation and charging) and offers the advantage of being able to inter-operate with almost any commercial IP telephony prod-uct. The disadvantage of this approach might be a slightly
FIGURE 5. Signalling Architecture of an Off-the-shelf IP Phone Supported by RSVP-based Reservations.
RSVP daemon IP Stack Audio RSVP + Charging RSVP daemon IP Stack Audio RSVP + Charging RSVP daemon IP Stack Caller Callee Router at ISP H.323 Proxy H.323 Gateway at ISP H.323 H.323 H.323 User Interface Caller Process RSVP API User Interface IP Phone Callee Process RSVP API H.323 Audio IP Phone Audio H.323 Accounting Database IP Stack
user unfriendly system due to its lack of complete integra-tion, but it is considered sufficient serving as a prototype. This prototype is complemented by appropriate user interfaces as described in Section 4.5 below.
QoS support is implemented in a very simple fashion: Using Netmeeting’s codec dialog [12], a voice coder is selected with its respective bandwidth requirements. Via the H.323 proxy, these requirements are automatically translated into RSVP flowspecs by the caller and callee processes (cf. Figure 5).
Charging support is a little more complicated and fully implemented in the Java applets for the caller and callee processes. According to the charging protocol used, dynamic market prices queried are displayed at the user interface (cf. Figure 7). Once a user decides to initiate a call, billing records are continuously displayed at the UI.
4.5 User Interfaces
The user of an IP telephony application will remain a human user. Therefore, the human user will identify his or her requirements in terms of QoS parameters of the IP telephony application in use. Due to the fact that these requirements should not be expressed (only) by technical means, since the user may not be aware of bandwidth, delay, or error rates in any network in use, an easy-to-use and simple user interface for expressing his or her needs is essential. Fortunately, in a certain sense, IP telephony provides a single service, called the telephony service based on an Internet and it is concerned with audio data transmission. Therefore, two interactions between human user and application are required:
• Selection of destination address and • Choice of audio quality.
Obviously, the selection of the destination may be chosen from the user or selected from a local database. As the destination format for a participant’s address the Domain Name System (DNS) name of the machine can be chosen. However, before the establishment of an IP telephony call, the choice of the audio quality has to be determined from the human user. This audio quality cur-rently is independent of technical parameters at the user interface level. Therefore, it offers different levels of qual-ity as indicated in Figure 6.
From 5 kbit/s to 64 kbit/s very low to telephone qual-ity levels can be selected. Providing an efficient and direct mapping between these user-level QoS – the user-driven selection of a codec – and underlying network QoS, a static mapping is implemented based on the resulting Codec data rates which Netmeeting is able to support. This results in the use of different bandwidth which are being handled from the reservation protocol afterwards.
Based on these two selections and choices the estab-lishment of an IP telephony call is initiated, particularly requesting the selected quality from the network.
How-ever, as expressed above, the communication costs involved in this call should be determined – at least the user should be made aware of the current price to be payed for this call and he or she explicitly has to accept or reject the call’s price. For this reasons, a second window pops up and summarizes the destination selected and the quality chosen (this time including the technical band-width parameter for information only) in addition to the current price. This price has been determined at that point in time, when the initiation has been submitted by press-ing “OK”.
Of course, based on the pricing model in use, the price always will remain the same in static pricing models or it will adapt to the market price, if dynamic or congestion-sensitive pricing schemes are applied. This price is valid for the next complete reservation period of this call, as used from RSVP. By acknowledging this price, the resource reservation is performed and the final call is established in full. A price feedback is provided within the main window to allow for a user-driven decision on the acceptance of the current price for all periodically upcoming reservation periods.
Finally, after the completion of the IP telephony appli-cation, the user is informed on all details of the IP tele-phony call. These details are included into the original window of the IP telephony call setup (cf. Figure 7). Bill-ing information includes the followBill-ing details:
• Sender’s DNS name,
• Destination’s DNS name and IP address, • Number of reservation periods utilized, • Separate prices per reservation period, • Duration of the full call in seconds, and • Total price for the full call.
Depending on the price models applied and the policy chosen, these information may be omitted partially. How-ever, minimal informations are required to set up a correct bill, which encounter the destination’s IP address, the duration of the call, and its total price.
FIGURE 6. Selecting Audio Quality Through Netmeeting’s Codec Dialog
In the case of automatic bidding mechanisms in dynamic markets a last step can improve the future per-ceived performance for users. Based on per-user profiles and simple feedback information (cf. Figure 8), strategies may be shifted between conservative or aggressive behav-ior. Figure 8 shows an experimental implementation of such a feature asking for a simple feedback from the user concerning delay, audio quality, and overall satisfaction.
5
Results and Conclusions
The results of this work show that the integration of commercial applications, such as the Netmeeting IP tele-phony, standard protocols, such as RSVP and H.323, and experimental protocol extensions, such as the charging
extensions applied to RSVP, are possible. This is espe-cially valid and promising for signalling protocols, since the charging and pricing tasks to be performed require the use of existing protocol architectures.
Important to mention is the fact that the design of a user interface can cover this signalling complexity to a certain degree, except for the need of specifying the callee and the quality requested for. However, exactly these two issues are the only ones a user is interested in. As shown before, the quality selection is based on the explicit user-driven Netmeeting’s Codec selection. Still, this requires an unnecessary degree of technical complexity visible at the user interface and should be avoided in future imple-mentations.
In addition, concerning the economic dimensions of this work, complex pricing functions can be abstracted away from the user completely. If a highly dynamic pric-ing scheme or a pure flat fee pricpric-ing scheme are intended, all signalling protocol extensions handle these matters transparently. With respect to the billing required, this work assumed the existence of a traditional billing sys-tem. Although from a research point of view, clever pay-ment systems are needed, particularly in case of electronic payments with, e.g., digital cash.
All of the features described above have been mented in a prototypical manner. The resulting imple-mentation and the described system were composed out of several experiments and studies conducted in the TIK laboratory. Therefore, a product-like implementation will integrate all different windows of the user interfaces in a single one, it will hide away Netmeeting’s codec selec-tion, and will simplify the signalling processes in terms of a to be defined signalling architecture integrating network layer signalling (RSVP) and application layer signalling (H.323) as proposed in appendix II of the H.323 recom-mendation [9].
Future work on the OCIT architecture will provide an interface to payment systems. Thus, the IP telephony ser-vice can be paid for in a secure and convenient manner. We currently develop a micro-payment system for on-line correlated payments supporting multiple sellers as needed in an IP telephony application with continuous charging. JavaCards, i.e. JAVA based smartcards, are used as con-tainers of the digital money and the necessary secret information. Furthermore, in addition to the implemented pricing models, different approaches are investigated in order to provide a complete validation of the prototype presented above. Although the charging approach already works transparently over different network clouds, e.g., LANs without resource reservation and accounting, it has to be investigated how the behavior of RSVP-based charging will be, if it is used in conjunction with Differ-entiated Services-based (DiffServ) transit networks. Appropriate pricing at the edges of DiffServ network clouds as well as RSVP message forwarding are major topics in this field.
FIGURE 7. Resulting Billing Information
Acknowledgments
Thanks are addressed to a number of TIK students, namely M. Foser, S. Kniess, L. Mysyrowicz, R. Ritler, P. Tscharner, S. Tufekovic, and C. Vögtli, who imple-mented and evaluated IP telephony scenarios.
This work has been performed partly in the frame-work of the project Charging and Accounting Technology for the Internet - CATI (CAPIV 5003-054559/1 and MEDeB 5003-054560/1) which has been funded by the Swiss National Science Foundation, SNF, Berne, Switzer-land. The authors like to acknowledge the discussions on relevant aspects with their CATI colleagues.
References
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: An Architecture for Differentiated Serv-ices; RFC 2475, December 1998
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin: Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification; RFC 1633, Internet Engi-neering Task Force, Internet EngiEngi-neering Task Force, September 1997.
[3] R. Braden, D. D. Clark, S. Shenker: Integrated Serv-ices in the Internet Architecture: An Overview; Request for Comments, RFC 1633, Internet Engi-neering Task Force, June 1994.
[4] D. D. Clark and W. Fang: Explicit Allocation of Best-Effort Packet Delivery Service; IEEE/ACM Transac-tions on Networking, Vol. 6, No. 4, August 1998.
[5] D. Decasper, Z. Dittia, G. Parulkar, B. Plattner: Router Plugins - A Modular and Extensible Software Framework for Modern High Performance Inte-grated Services Routers; ACM Computer Communi-cation Review (SIGCOMM’98), Vol. 28, No. 4, 1998 [6] D. Decasper, M. Waldvogel, Z. Dittia, H. Adiseshu, G. Parulkar, B. Plattner: Crossbow - A Toolkit for Integrated Services over Cell-Switched IPv6; Pro-ceedings of the IEEE ATM'97 Workshop, Lisboa, Portugal, June 1997.
[7] G. Fankhauser, B. Stiller, C. Vögtli, B. Plattner: Res-ervation-based Charging in an Integrated Services Network. 4th INFORMS Telecommunications Con-ference, Bocca Raton, Florida, U.S.A., March 1998. [8] ISI implementation of RSVP, URL: ftp://ftp.isi.edu/
rsvp/release/rsvpd.rel4.1a4.tar.Z.
[9] ITU-T Recommendation H.323: Series H: Audiovis-ual and Multimedia Systems, Infrastructure of Audio-visual Services – Systems and Terminal Equipment for Audiovisual Services, Packet-based Multimedia Communications Systems; February 1998.
[10] J. K. MacKie-Mason, H. Varian: Pricing the Internet. Technical Report, University of Michigan, U.S.A., February 1994.
[11] L. Mysyrowicz: Interfaces for IP Telephony in Sup-port of QoS and Charging; Student Thesis, Compu-ter Engineering and Networks Laboratory TIK, ETH Zürich, Switzerland, February 1998.
[12] Netmeeting, URL: http://www.microsoft.com/net-meeting.
[13] B. Stiller, G. Fankhauser, B. Plattner, N., Weiler: Charging and Accounting for Integrated Internet Services – State of the Art, Problems, and Trends; INET’98, The Internet Summit, Geneva, Switzer-land, July 21 – 24, 1998.
