CATI Scenario and Architecture

Transcription

1 CATI Charging and Accounting Technology for the Internet SNF SPP Projects /1 and /1 CATI Scenario and Architecture Gabriel Dermler IBM Research Division, Zürich Laboratories Workpackage and Task: WP3T2 Deliverable Identifier: CATI-IBM-DN-I Status: Internal Version: 1.0 Revision: 4 Reviewed by: Due Date: Delivery Date:

2 Abstract This document provides a description of scenarios and architectural aspects delimiting an overall framework for design and implementation within the CATI project. The document presents application scenarios to be used for demonstrating project results and discusses the functionality to be expected at a charging and accounting API. The role of QoS provisioning and that of VPN usage are contrasted to each other and an architectural model is introduced describing economic relationships between an Internet Service Provider (ISP) and its customers. Signalling scenarios both for this and the general case of communication involving several ISPs are being discussed within a companion paper which, together with this document, will provide the base for the final architecture definition. CATI Scenario and Architecture 2 G. Dermler

3 1. Introduction In its first part, this paper presents the application scenarios to be used for demonstrating CATI project results. Besides formulating requirements at the application level (what shall users be able to do with the application) its main focus is to encircle the appropriate support which is to be expected from a CATI system at an appropriate API. Two models are introduced, one trying to keep as much functions as possible at the application level, and one assuming the introduction of a generic (i.e. application independent) connection grouping concept at the network level. In the second part, QoS provisioning and the usage of Virtual Private Networks (VPNs) within the CATI scenarios are discussed. In particular, it is stated that QoS support and support for VPNs shall be provided and demonstrated as orthogonal concepts. In the third part, a supply chain underlying the CATI project is described. Three service providers - network operator, internet service provider (ISP) and electronic commerce provider (e-sp) - are identified and interrelated in an overall architecture within which both the major business relationships and the main service control flows can be defined. Major aspects of a final architecture are discussed in detail in other documents. Communication across several ISPs is being discussed - along with implications for charging and accounting and signalling scenarios - in a companion document on Approaches for the Integration of Charging and Accounting into Internet Models and VPN, while the elaboration of the VPN desgin is presented in the document on the Virtual Private Network Architecture. 2. Application Scenarios 2.1 IP Telephony User Requirements The scenario involves two users A and B wishing to conduct a simple (voice) telephone call. User A is supposed to dial user B indicating his name and the desired telephony QoS level, where a QoS level can be selected individually for each direction. The telephony application translates the latter into transport level QoS requirements which are used to set up the (two) connections between the two parties. For a call set-up the following requirements can be stated: R1. The caller and the callee should have a common knowledge of which cost is implied by a call and how this cost is going to be divided between them. The following schemes are easy to imagine: (a) cost attributed to the caller, (b) to the callee, (c) attribution is split up, e.g. 60:40 to the caller resp. callee. R2. Both caller and callee shall be allowed to provide a user profile in order to let the network take information such as person identity or role into account, when deciding on admitting connections resp. calculating a cost. R3. Both the callee and the caller should be able to refuse the call, depending on the implied cost or the foreseen cost distribution scheme. CATI Scenario and Architecture 3 G. Dermler

4 R4. Ideally, both call participants should be able to dynamically change QoS in a call as well as the cost division scheme. QoS changes allow users to lower their cost for instance when noticing that a call lasts longer than planned. R5. Both call participants shall receive bills including a call description, QoS, duration and their respective cost share. Such bills are sent after the call has been terminated, i.e. not in real- time. R6. Ideally, real-time cost information showing the accumulated cost of an ongoing call shall be presented to both call participants. This indication shall reflect the used cost division scheme. All above requirements relate to a call 1. At the network level a call encompasses two connections each with QoS and cost attributes. The call notion used states that (a) the two connections may have their individual QoS (b) the cost of a call represents the sum of the costs found for the two connections (c) only the acceptance of a call set-up by the caller and callee should confirm the desire to use the connections implied Connection Grouping It is obvious that a call notion has to be provided within a telephony application. At the same time the charging and accounting API of CATI initially targeted isolated channel set-up only. In this case all call related functions have to be performed within the application itself leading to a more involved call set-up action sequence. Call Set-Up & Cost Connection Grouping Call Set-Up & Cost Connection Grouping Application Level Single Connection Set-Up, Charging and Accounting Network Level First, the two connections have to be set up at least to the point where cost information for using them is derived. Then the cost information has to be aggregated for acceptance by the caller and the callee. Only when the call (cost and cost division) acceptance is confirmed, can the two connections be definitely confirmed with respect to reservation and charging. For achieving agreement on both sides of the call an application level protocol may be implied. Furthermore, real time cost information delivered by the network will relate to single connections only; again cost aggregation for a call is required at the application level. On the other side, grouping of connections for a call in the sense mentioned above (see previous requirements 1-6) does not depend on any application semantics, so it could be well supported at the 1. Put more generally, a call is a special case of a session which may consist of any number of connections connecting users in most various ways. CATI Scenario and Architecture 4 G. Dermler

5 network level as well. This would require some mechanisms in addition to RSVP allowing to aggregate cost for a connection group, relay this information to the application side, etc E-Commerce Scenario E-SP and E-Customer Requirements The second scenario demonstrates the usage of IP telephony within a commercial scenario involving an e-commerce service provider (e-sp) and e-commerce customer (e-customer). The e-sp is assumed to offer products via WWW. The e-customer can download WWW pages and select products and put them into his basket. Prior to ordering the products the e-customer can click on the WWW-page to contact a sales person in order to get special purchase conditions, clarify technical aspects of goods, etc. For this communication the IP phone is employed. The latter can be done according to the control features described in the previous section. For instance, the e-customer may want to pre-listen a CD recording before buying it, for this a connection with an appropriate QoS would be set up. Another e-customer may want to keep communication cost low, so that it selects a rather modest quality. From the e-sp s point of view, in particular the varying cost distribution schemes may play a role. To encourage customers to purchase goods, it could offer free-of-charge advising. Limitations such as with respect to time (five minutes free of charge, then the customer pays the charge, fully or partially) are supported, since the e-sp can trigger a cost division change at any time. All of these requirements are covered by the requirements R1-R6 mentioned in Given the buyer/seller relationship between the e-sp and the e-customer, additional requirements may exist, which however will not be considered further within the CATI project: R7. an e-sp shall be able to control the amount of cost information which is made available to the e- customer, e.g. only the cost which has to be taken over by the customer R8. an e-sp shall be allowed to indicate that (call) connections are belonging to an electronic commerce transaction between an e-sp and an e-customer. In the most simple case this includes a string description of the transaction which allows to indicate the context within which a connection is used (e.g. to be used on bills reflecting cost for the network usage). In more complex cases, this knowledge may be exploited within the network for deriving e-commerce transaction specific schemes for assigning network resources and charging for them. Communication required for WWW page downloads implies network traffic which may also be subject to charging. In order to guarantee a minimum QoS for downloads and for page requests in reverse direction a bidirectional communication relationship similar to a call could be set up defining individual minimal QoS for the downstream and the upstream direction. All page downloads could then use the same connection to the e-customer and be therefore charged. An extreme case would be to set up connections without making reservations, but initializing the charging mechanisms for all following traffic using the connection. A special problem arises with regard to initially accessing an e-sp. In order to be able to get into contact with the e-sp, a customer usually must have acquired access to the ISP. An alternative would be to allow an e-sp to set up initial access rights for potential customers, by informing the ISP accordingly. These access rights would be checked whenever a customer tries to reach an e-sp. Also the access rights may fix the connection QoS by which the customer may contact the e-sp. CATI Scenario and Architecture 5 G. Dermler

6 2.2.2 Connection Grouping Grouping connection pairs in the context of a call (as described in 2.1) is required whenever telephony is used within an e-commerce scenario as described in In order to provide grouping for all communication taking place within an e-commerce transaction (see R8 from above) a second grouping level is necessary requiring a group id and string description to be associated with it. In analogy to grouping for calls or for e-commerce transactions may be realized on the application or the network level. In order to support R7 from above, exclusive grouping at the application level is not appropriate, if it implies that all cost information relating to involved connections is provided to both sides of the transaction. 2.3 Application Programming Interface Grouping at the Application Level In this case the CATI system is to provide an API with a connection as the main abstraction. No notion of a connection group is supported. The API shall include methods such as: F1. connection set-up request from an initiator (QoS, descriptionstring 1, user profile) F2. set-up indication to the initiator and responder(qos, cost) F3. acceptance/reject response by initiator and responder F4. connection QoS change request from initiator or responder (new QoS, user profile) F5. connection QoS change indication(new QoS, cost) F6. acceptance/reject response by initiator and responder F7. request real-time cost feedback for a connection F8. real-time indication of accumulated cost for a connection Such an API indicates to the initiator and responder of a connection the price implied for setting up the connection. Setting up a call amounts to setting up a connection pair with opposite data transfer directions. Both sides are informed about the prices for both connections. Recognizing that they belong to the same call context requires an appropriate protocol at the application level. In case of telephony, this is done by interpreting exchanged H.323 protocol messages indicating which connection belongs to which call. Given that a conference may involve many connections, not all of which involve all terminals, price information may be given in a scattered fashion. For aggregating the prices for a conference set-up, an additional protocol is required to sum up prices and distribute the information to all involved parties for acceptance. This kind of protocol is also required, if price information for connections of a call is not made available at both sides of the call (i.e. if F2 is not fulfilled with respect to the responder). As the conceptually simplest mechanism, each terminal may send its information to all other terminals Grouping Support at the Network Level In this case the CATI system is to provide an API relying on both a connection and a group notion. The API shall include methods such as: 1. The descriptionstring is used for adding textual information to the accounting record of the connection. CATI Scenario and Architecture 6 G. Dermler

7 F9. set up a group defining attributes like (a) user rights to request cost information, adding/delete connections from the group, etc. (b) type and string description of e-commerce transaction for the group F10-F15. similar to F1-F6, but including a group Id. F16. request real-time cost feedback for a connection or connection group F17. real-time indication of accumulated cost to authorized users Deriving that a connection belongs to a certain call (more generally: a conference) still requires application level support, i.e. the application has to indicate the network which connection belongs to which (network) connection group. Price aggregation for a group would then be done at the network level, whereby appropriate mechanisms would have to be elaborated. Within CATI, support for connection groups will not be pursued further. 3. QoS Provisioning and Usage of Virtual Private Networks 3.1 QoS Support for Connections Applications using the CATI system shall be provided with QoS based network connections. The usage of such connections should not be depending on the usage of VPNs defined to provide special support for closed user groups. This is due to at least the following reasons: (a) Both telephony and e-commerce applications target in most cases open user communities. (b) An underlying ISP providing support for QoS in the context of a VPN should be able to provide that support generally for all connections by applying the same mechanisms that are used for realizing QoS within a VPN context. As for QoS, charging and accounting for network connections shall be provided as a basic service, irrespective of VPN usage. 3.2 VPN Usage VPNs shall be supported for applications as an orthogonal concept to QoS. Within the CATI project, VPNs shall be provided to applications with the following semantics: C1. Closed user group properties: only specified users are allowed to make use of the VPN. C2. Privacy: non VPN users do not receive data sent within an VPN. C3. Prereserved resources: a certain amount of bandwidth is guaranteed to be provided to a VPN at any time. C4. Charging and Accounting: for a VPN purchase, charging should be similar as charging for setting up a person-to-person call. Depending on the VPN requestor specification, admission of connections to the VPN can be granted with varying degrees of connection pricing, from free usage of connections to heavily priced connections. VPNs are set up by Internet Service Providers to support applications. They are visible at the application level in the sense that only certain application traffic is entitled to make use of the VPN. This can be achieved for instance by using certain port numbers, traffic class identifiers, etc. CATI Scenario and Architecture 7 G. Dermler

8 A VPN may be set up at the request of a specific application, e. g. an e-sp desiring VPN connectivity to a number of e-customers. A VPN may also be set up to support an application class, e.g. all telephony traffic within a user group. In both cases participants can be added to a VPN or removed from it. 3.3 CATI Scenarios To be Demonstrated Scenarios with QoS Support Both the telephony and the e-commerce applications shall be demonstrated stressing the CATI support for QoS and charging and accounting in the context of network connections. These demonstrations shall not include VPNs at the application layer Scenarios with VPN Support The telephony and e-commerce scenarios shall be demonstrated when VPNs are used in addition. To make the scenarios convincing, closed groups of users have to be defined who require special VPN properties, such as a high probability of successful connection set-up for a desired QoS. Within the IP telephony scenario a VPN may be set up to interconnect e. g. the maintenance staff within a company with distributed locations. The VPN shall allow them to make telephone calls to each other with a desired QoS and a high level of call set-up success. To make efficient use of bandwidth, calls shall be priced according to the QoS used. Within the e-commerce scenario a VPN may be set up to support an e-sp delivering its service to its customers. The VPN shall allow the e-sp to service a reasonable number of customers at any time. To make efficient use of bandwidth available to access the e-sp, communication to the e-sp is priced according to the QoS used. 4. Supply Chain Model In the following a supply chain of services is described consisting of a network provider, an ISP and an e-sp. The supply chain incorporates major processes described in the project definition and structures their interworking both technically and with respect to business relationships (see Figures 1 and 2). A Network Service Provider operates a network consisting of a backbone which can be accessed through various edge control points. The nw-sp offers (as a product) a link-layer-vpn (ll-vpn) which can be used by an ISP to interconnect its (ISP) edge devices and routers. Such a VPN is not visible to applications and is not to be confused with the VPNs described in Section 3. Its purpose is to allow an ISP to provide QoS for the connections set up between its edge control points. Insofar, the a ll-vpn provides a special solution for realizing QoS at the IP level. The current state of discussion in the project is that ll-vpn will not be considered. The Internet Service Provider offers two basic services. One service allows the set-up of QoS enabled connections, to which charging and accounting is applied. The service is offered via an API like the one described in Section 1. To realize this service the ISP may either make use of ll-vpns (see above) or employ some other QoS support mechanisms (e.g. Differentiated Services). In the latter case functions for connection admission control have to be implemented at least within the ISP CATI Scenario and Architecture 8 G. Dermler

9 edge control points. Preferably, admission control should take into account information about the global state of the ISP s network (edge routers, internal routers, links). The second service of an ISP allows the set-up of ISP-VPNs as described in Section 3. The service is offered via a VPN server and allows to define the user group for a ISP-VPN, the corresponding traffic pattern as well as the pricing scheme to be applied for setting up connections across the ISP- VPN. To regulate access to a VPN, the ISP performs at its edge control points (a) access control based on the user group definition of a VPN and (b) admission control based on load considerations and the defined pricing scheme. ISP edge control points are the points where costs for requested connections are derived. They serve as the base for collecting charging and accounting information. The Electronic Commerce Provider offers goods which can be electronically purchased by accessing the service site via the ISP. The e-provider (as well as its customers) can set up QoS based connections by using the corresponding ISP service. Connections are subject to charging by the ISP. 1 In addition, an e-sp can purchase a VPN from an ISP by indicating the desired VPN properties (see above). In particular, it may subscribe all potential customers as VPN participants. E-provider and e-customers can set up QoS based connections in the context of a VPN by using the corresponding ISP service. The ISP regulates connection set-up by employing the mentioned access and admission controls. Figures 1,2 and 3 separate the mentioned service providers in the supply chain and indicate the basic transactions between them. Two cases are considered separately. Figure 1 reflects the case when QoS based connections are used, without involving ISP-VPNs, while Figures 2 and 3 correspond to the case that such VPNs are used as well. Scenarios with QoS Support Figure 1 shows the following transactions resp. control data flows: Flow 1: interaction to define a ll-vpn as a product including pricing Flow 2: interaction to purchase a ll-vpn Flow 3: interaction to define the pricing model for QoS enabled connections Flow 4: interaction to set up (buy) such a connection Flow 5: indication of real-time charging information Flow 6: indication of accounting information for connections Flow 7: indication of aggregated accounting information for further processing (e.g. billing) Scenarios with ISP-VPN Usage Figures 2 and 3 shows the following control flows: Flow 1: as above Flow 2: as above Flow 3: interaction to define ISP-VPNs as a product including pricing Flow 4: interaction to buy an ISP-VPN Flow 5: interaction to set up an ISP-VPN 1. Chariging for content is not dealt with within CATI. CATI Scenario and Architecture 9 G. Dermler

10 Flow 6: interaction for the set-up (purchase) of a QoS enabled connection within a VPN Flow 7: indication of real-time charging information for used connections Flow 8: indication of accounting information for connections of a VPN Flow 9: indication of aggregated accounting information for further processing (e. g. billing) CATI Scenario and Architecture 10 G. Dermler

11 E - Service Provider E - Service Customer 4a 5a 4c 5b ISP Management Interface 3a ISP Access & Pricing Cntrl 3b Edge Admission Edge Accoun ting 3b Edge Admission Edge Accoun ting 7 Aggregate Accounting 6a 4b 6b NW Management Interface 1a NW VPN Pricing Cntrl NW-VPN 2a 2b NW - Edge 2c NW - Edge Figure1-11 -

12 E - Service Provider E - Service Customer 4 ISP Management Interface 3 ISP VPN Pricing Cntrl ISP-VPN Set-Up Cntrl 5a ISP - Edge 5b ISP - Edge Aggregate Accounting 2b NW Management Interface 1 NW VPN Pricing Cntrl NW-VPN Set-Up Cntrl 2c NW - Edge 2c NW - Edge Figure

13 E - Service Provider E - Service Customer 6a 7a 6c 7b ISP Management Interface ISP-VPN Pricing Cntrl ISP-VPN Set-Up Cntrl VPN Access and Admission Edge Accoun ting VPN Access and Admission Edge Accoun ting 9 Aggregate Accounting 6b 8a 8b NW Management Interface NW-VPN Pricing Cntrl NW-VPN Set-Up Cntrl NW - Edge NW - Edge Figure