Jun 30, 1999 - actions including service level agreements as well as charging and accounting for service provision. It is the goal of this document to describe ...
CATI Charging and Accounting Technology for the Internet SNF SPP Projects 5003-054559/1 and 5003-054560/1
Integration of Charging and Accounting into Internet Models and VPN Gabriel Dermler, IBM Research/Zurich Research Laboratory George Fankhauser, Burkhard Stiller, TIK/ETH Zurich Torsten Braun, Manuel Günter, IAM/Univeristity of Bern Helmut Kneer, University of Zurich
Workpackage and Task: Deliverable Identifier: Status: Version: Revision: Reviewed by: Due Date: Delivery Date:
WP3T2 CATI-IBM-DN-I-004-1.5 Public 1.4 – Torsten Braun 30.6.1999 30.6.1999
1. Introduction Providing service differentiation for Internet based communication has been at the heart of intense work within the Internet community. While the definition of services and the development of required support technologies has lead to various proposals, this work has mainly been conducted in technical terms without considering required support for business related aspects such as charging and accounting for network services. These aspects naturally arise, as soon as users have the choice of selecting between different, i.e. better and worse, service offers from Internet service providers. In order to control service selection, appropriate approaches for usage-sensitive charging are required which go beyond the traditional flat fee based charging for Internet access. Quality of Service based communication, as developed within the Integrated Services (IntServ) working group of the IETF, provides a basic approach for service differentiation. IntServ supports the exchange of flows between applications running on distributed hosts, while basing differentiation on individual flow characteristics. More recently and in response to criticism concerning the scalability of the IntServ approach, Differentiated Services (DiffServ, [1]) have been proposed. Unlike IntServ, DiffServ was explicitly designed to restrict service differentiation within the network based on a very limited (some proposals say two) number of network element behaviors. IntServ and DiffServ concepts and mechanisms form the fundament of the work done within the CATI project. Service differentiation as offered by IntServ to end-users is taken as much into account as DiffServ based concepts for differentiating services within the network. CATI uses available IntServ and DiffServ concepts and augments them by required support for business oriented actions including service level agreements as well as charging and accounting for service provision. It is the goal of this document to describe the overall CATI approach in a unified manner. For this, the document first presents a conceptual framework which was used to structure charged end-to-end service delivery ([8]). Based on this, the various topics and issues are described which are dealt with in the project. In large parts, the document has an overview character introducing relevant issues and referencing corresponding detail documents worked out in the project. The remainder of the document is structured into three parts. In a first part, the IntServ and DiffServ approaches to service delivery are shortly reviewed. In a second part, a business oriented structuring of charged end-to-end service delivery is presented as a conceptual framework. Various topics of CATI work are introduced in the context of this framework. In particular, the approaches towards end-to-end flow set-up and VPN usage are introduced along with charging related aspects. In the third part, “horizontal issues” such as pricing and security are shortly presented as they apply to work done in CATI. Also, the application scenarios are shortly reviewed which are to show the functionality developed.
2. Internet Service Models for QoS Support 2.1 Integrated Services (IntServ) IntServ defines a framework allowing networks to support QoS for unidirectional flows generated by applications running on hosts ([3], [4], [5]). With Controlled and Guaranteed Service two services are given differing in the provided QoS semantics. Both of them address data loss with respect to the traffic specified for a flow, while, in addition, Guaranteed Service includes guarantees concerning end-to-end delays.
2
G. Dermler
IntServ requires a flow set-up phase prior to data transmission. The RSVP protocol has been specified to coordinate this phase in an end-to-end fashion. RSVP allows sender and receivers of a flow to specify desired flow traffic and QoS features (loss, delay) and propagates this information along the router sequence foreseen for transmission. RSVP relies on the existence of appropriate admission control and resource allocation mechanisms at each router which ensure that QoS features can be granted for the flow when traversing the router. However, RSVP is independent of specific admission control and allocation realizations. Similarly, RSVP relies on the existence of a routing mechanism at each router allowing it to find a path between sending and receiving hosts, while being independent of specific implementations. From the outset, IntServ together with RSVP have been targeting data transport support for flows generated by applications. Despite of many additional advanced features built in (e.g. receiver orientation, multicast capability, loss and delay control, soft state, etc.), IntServ has been severely criticized for requiring support according to this fine flow granularity throughout the network. Per-flow state at each employed router imposes high overhead in particular in backbone parts of the Internet and has been shown to lead to severe scalability problems.
2.2 Differentiated Services (DiffServ) DiffServ [1] has been a direct response to the scalability problem of IntServ. DiffServ pursues a minimalist approach towards the state to be kept within routers. Instead of supporting potentially for each flow a particular treatment, DiffServ defines a limited number of service levels (Per-HopBehaviors, PHBs) which can be applied within a router. DiffServ assumes that all traffic is marked in order to indicate the PHB to be applied at a router. For this, the DS byte of the IP header is used. The DiffServ architecture rests on a network model with a domain as its main concept ( Figure 1). A domain is an interconnected set of routers with a common set of PHBs implemented on each router and a common service provisioning policy. A domain has a well-defined boundary delimiting boundary and interior routers. Interior routers classify arriving traffic according to the DS code-point (contained in the DS byte) of a data packet and apply the corresponding PHB to the packet. Boundary routers classify arriving traffic based on the DS code-point and possibly the (source, destination) address information contained in the packet headers. Boundary routers can serve both as ingress and egress points for a domain, depending on whether they handle incoming or outgoing streams.1 DiffServ provides services to DiffServ users with respect to streams entering a domain. The conception of such services rests on several basic means. First, it is assumed that traffic marked with the same DS code-point is treated at all interior routers according to the same PHB. This ensures that within a domain PHBs are applied coherently. Second, an incoming stream may be associated with a service level agreement (SLA) making sure that only foreseen traffic enters a domain and makes use of available resources. An SLA basically identifies a stream (by a classification rule), specifies the amount of expected traffic as well as the service level to be applied. An SLA is set up prior to data transmission. During data transmission, stream traffic is monitored according to the SLA, and, in case of non-conformance, stream packets can be conditioned (e.g. delayed or dropped).
1. We refer to an incoming resp. outgoing stream as the data packets isolated by a classification rule at an ingress resp. egress router. Note that the current DiffServ model considers unidirectional streams only. 3
G. Dermler
BB1
SLA
SLA
BB2
BB3 B
ISP1
ISP2
ISP3
Host Boundary Routers BB
Bandwidth Broker FIGURE 1. DiffServ Network Model
Third, the DiffServ concept assumes that a control model is in place allocating resources in the context of SLAs. In some cases, this control can be assumed to be provided outside the DiffServ model, as is, for instance, the case for application level control limiting the number of flows exchanged in a domain. If such control cannot be assumed, resource protection and allocation has to be provided by DiffServ networks. In [2], agents, termed Bandwidth Brokers (BB), are foreseen as the entities responsible for bandwidth allocation for SLAs. As such, BBs have knowledge of available resources and, by monitoring granted resource allocations, are able to determine the extent to which additional SLAs can be accepted. In order to provide a service across several domains, SLAs have to be available in a nested fashion. Figure 1 shows an example for an SLA set up bw. ISP1 and ISP2 for a stream destined to a final destination B. In order to honor the SLA, ISP2 has itself to set up an SLA with ISP3. By defining appropriate PHBs, SLA specifications and resource control models, various services can be provided to DiffServ users. Based on the introduced BB approach, in [2] two services have been considered in addition to best-effort service. The Assured service was designed to provide soft guarantees in the sense that stream traffic will be transmitted with high probability. In contrast, Premium Service was developed to support guarantees with respect to a peak rate specified for a stream, while keeping delay for traversing DiffServ domains within low bounds.
2.3 IntServ over DiffServ IntServ over DiffServ is motivated by combining IntServ's end-to-end service with DiffServ's simplicity. Both features are very attractive and an integrated IntServ/DiffServ solution promises to combine the advantage without bearing the overhead of IntServ at the core network level. Two alternatives for interoperability between Intserv and Diffserv are mentioned in [9] and [13]. The approach relevant for our work assumes a model in which peripheral stub networks are RSVP and Intserv aware. These are interconnected by DiffServ networks that appear as a single network to the RSVP nodes. Hosts attached to the peripheral IntServ networks signal to each other for per-flow resource requests across the DiffServ networks. Standard RSVP processing is applied within the IntServ peripheral networks. RSVP signaling messages are carried transparently through the DiffServ networks. 4
G. Dermler
Devices at the boundaries between the IntServ and the DiffServ networks process the RSVP messages and provide admission control based on the availability of appropriate resources within the DiffServ network [9]. Multiple IntServ flows which exist in peripheral networks are aggregated into a behavior aggregate (i.e. stream) at the boundary of the DiffServ network. Border Routers
CPN 1
ISP B
ISP A
Sender
CPN 2 Receiver
Edge Routers Bandwidth Broker FIGURE 2. IntServ/DiffServ Sceanrio
When an RSVP request for IntServ arrives at the boundary of a DiffServ network, RSVP style admission control is applied based on the amount of resources requested in the IntServ FlowSpec and the availability of DiffServ at the corresponding service level. If admission control succeeds, the the aggregating router marks traffic on the IntServ flow, for the appropriate differentiated service level. The RSVP/Intserv over DiffServ approach is especially suitable for providing quantitative end-toend services. The use of RSVP signaling provides admission control to the DiffServ network, based on resource availability and policy decisions. Figure 2 shows an example of a combined IntServ/DiffServ scenario as it is used within the CATI project. RSVP messages are processed by the end systems and the edge routers only. After a PATH message arrives at the receiver, it returns a RESV message towards the sender. Edge router 2 (the edge router of CPN 2) reserves the resources for the customer premises network 2 (CPN 2) and forwards the RESV message to edge router 1 (the edge router of CPN 1). Here the most important actions occur in the scenario. Edge router 1 has to check whether the requested bandwidth can be granted to the flow [11]. For this purpose, he can check the available bandwidth using a local admission control data base or by communicating with the bandwidth broker of its own domain (BB CPN1). This one might have sufficient resources allocated and answer the request immediately with a positive response. If not, BB CPN1 might have to ask the BB of the adjacent ISP (in this case BB ISP1) whether sufficient bandwidth is available or whether additional bandwidth can be allocated. BB ISP1 again may answer this request directly or after some message exchange with further downstream BBs. At some time, BB ISP1 returns some positive or negative answer back to BB CPN1, and CPN1 returns this answer to the edge router 1. An implementation of such a scheme is described in [14].
5
G. Dermler
3. Charged Service Delivery and its Structuring in CATI 3.1 Business Entities Providing Data Transfer Services Very much as the Internet can be seen as structured into networks of different types from a technical point of view (e.g. access, backbone networks), at a business oriented level, the Internet can be seen as consisting of Internet Service Providers (ISPs) acting as autonomous business entities for delivering data transfer services to their customers. Every provider employs a (set of) network(s) to support this goal.
EndCustomer
Customer Premises Network
Access ISP
Customer Premises Network
Core ISP
...
Core ISP
EndCustomer
Access ISP
FIGURE 3. Business Entities
We distinguish two types of ISPs. Access ISPs (A-ISP) connect end-systems (hosts) employed by end-customers to the Internet and give them the ability to make use of data transfer across the Internet. In contrast, a core ISP (C-ISP) provides for data transfer services towards access ISPs and their customers. Core ISPs are typically used in the backbone of the Internet extending the reach of access ISPs (and their customers) to a global level. Thus, end-to-end communication between end-systems passes through involved access ISPs and a number of core ISPs interconnecting the latter ( Figure 3). Organizations such as companies or administration agencies typically operate a customer premises network (CPN) providing for data transfer between their end-systems. From an end-system point of view, CPNs appear to be similar to access ISPs, since they enable access to the Internet. Given that policy enforcement is easier when based on internal organization rules, such networks may apply any specific access policies, making them appear to be different from commercial ISPs. In order to support data transfer for its customers, an ISP has to consider two aspects. First, it has to be ensured that the physical means (e.g. access routers, links) are installed by which its customers (hosts or other ISPs) are connected to its network. Second, the ISP has to provide the data transfer services by which ISP customers can send data to other Internet locations. In this document, we assume that physical connectivity is given by definition (e.g. based on long-term agreements) and focus on the transfer services supporting end-to-end communication with QoS.2
2. Often, a distinction is made between internet and network service providers, referring to the former as an entity providing Internet access to end-customers and referring to the latter as an entity providing network access resp. connectivity to end-customers resp. internet service providers. Focusing on data transfer services, in this paper we consider an ISP strictly in the defined sense, i.e. in its role of providing (IP level QoS enhanced) data transfer services. As such, we see ISPs as servicing end-customers as well as other ISPs. Also, restricting ourselves to data transfer service aspects, we do not deal with questions as to from whom and how ISPs acquire network resources. 6
G. Dermler
3.2 Service Agreements for Data Transfer CATI work is based on the service models introduced by IntServ resp. DiffServ. In particular, we target services supporting transfer of a specific bandwidth with QoS properties such as low delays. Correspondingly, we reuse the notions of flow resp. stream (or aggregated flow) in order to denote the service items dealt with from a business perspective. Typically, we refer to a flow as the service item provided („sold“ and „purchased“) by an A-ISP to end-customers, while we refer to a stream (or aggregated flow) as the service item provided between ISPs. From a business angle, the provision of a service is linked to an agreement describing the service item sold resp. purchased along with additional regulations concerning pricing and payments. In the following, we describe two different agreement types which we use in the project to flexibly support the provision of data transfer services. 3.2.1 Service Level Agreements between ISPs In order to support QoS based end-to-end communication, it is necessary that involved ISPs can give corresponding guarantees for streams they exchange among themselves. In order to describe services which are available, i.e. can be contracted, Service Level Agreements (SLAs) as suggested by DiffServ can be employed as a base. According to [1] such SLAs include: 1. classification rule for the stream 2. specification of the traffic the customer ISP is allowed to send to the selling ISP 3. service level to be applied (e.g. best-effort, Premium Service: bandwidth, delay) An SLA is established between a customer ISP requesting an SLA and a selling ISP offering the SLA.3 The stream classification rule is required by the selling ISP in order to identify the traffic to which the SLA specifications shall be applied. Recall that DiffServ allows for stream traffic classifications based on the DS byte and source and destination information contained in the header of arriving data packets. The specified traffic describes the traffic covered by the SLA and can for instance be done using a token bucket model. The service level identifies the QoS characteristics offered to the customer, e.g. Premium Service with guaranteed bandwidth and low delay. Within CATI we request additional parameters to be part of an SLA. In order to capture security support (e.g. encryption) for data communication within VPNs (see 3.3.2), a Quality of Privacy parameter is included. Given that we consider SLAs as part of a business oriented framework, we foresee an SLA to cover also: (a) the agreed on price, (b) a payment method, (c) definition of non-compliance of service delivery and corresponding reimbursement, (d) monitoring of service delivery compliance and (e) an SLA duration indication. Put together, the SLA description assumed within CATI contains 4: 1. classification rule for the stream 2. specification of the traffic the customer ISP is allowed to send to the selling ISP 3. Quality of Service to be applied (e.g. best-effort, Premium Service: bandwidth, delay) 4. Quality of Privacy to be applied (e.g. encrypted/not-encrypted, secure/unsecure transmission) 3. In this paper, we use the term SLA to denote agreements between ISPs only. 4. The given list indicates the SLA aspects CATI work is concerned with. 7
G. Dermler
5. agreed on price 6. payment method 7. definition of non-compliance and reimbursement 8. monitoring method for service compliance 9. duration 10. service scope . SLA Service Scopes The current description of the DiffServ SLA concept ([1]) does not state specific requirements towards the physical extent of service coverage. As pointed out in [9], various definitions can be envisaged towards this end. For instance, an SLA may denote the characteristics of service across just one ISP’s domain. Other SLAs may define service coverage up to the access points of destination hosts. Also, SLAs may be defined in a directed way, in the sense that they concern a service towards a single destination or a limited set hereof. In contrast, undirected SLAs can be used to cover service towards any possible destination location. We use the term “service scope” ([9]) to denote the extent of service coverage defined by an SLA. For the scenarios considered by CATI we distinguish three types of SLAs based on their scope definition (Figure 4): SLA 3: AISP1-CISP1 * cls. rule: to EC2 * traffic, QoS * scope: I1, E4 * price * payment method
EC 1
I1
Access ISP 1
SLA 2: AISP1-CISP2 * cls. rule: to A-ISP2 * traffic, QoS * scope: I2, E3 * price * payment method
Core ISP 1
I2
SLA 1: CISP1-CISP2 * cls. rule: to A-ISP2 * traffic, QoS * scope: I3, E3 * price * payment method
Core ISP 2
I3
Access ISP 2
E3 I4
EC 2
E4
scope of AS-SLA1 scope of AS-SLA2 scope of H-SLA3 FIGURE 4. SLA Semantics
AS-SLAs. An AS-SLA features service coverage between an entry point of an ISP and the entry point of an end domain, where the end domain corresponds to either an access ISP or a customer premises network (CPN). Given that the administrative domain of an ISP or CPN typically corresponds to what is called in the Internet world an Autonomous System (AS), an AS-SLA denotes service coverage up to a “final” AS servicing attached hosts. There are several justifications for considering ASSLAs within the project.
8
G. Dermler
First, AS-SLAs are directed, i.e. they concern communication towards a limited set of destination hosts. Thus, they allow a more precise prediction of traffic than undirected SLAs (which potentially cover communication to all existing destinations). Second, AS-SLAs consider all traffic sent towards a destination AS as just one aggregate. In consequence, the number of SLAs an ISP has to keep track of is of the same order as the number of existing AS (currently in the order of approx. 10000). Third, handling of a large number of AS related entries is already being done within the Internet for routing purposes (see argument in Appendix I and [16]). Finally, not extending the scope to the hosts attached to the end-domain, allows an access ISP or a CPN on the destination side to decide on admission of single flows (see H-SLAs below). H-SLAs. Such SLAs have a scope stretching from an entry point of an access ISP to an egress point of a remote ISP to which (exactly) a host is connected. Thus, an H-SLA represents the communication pipe between exactly two hosts. H-SLAs exist in conjunction with AS-SLAs only (see below). X-SLAs. Such SLAs cover service up to all potential destinations, i.e. they are neither directed nor limited in reach. As an example, in Figure 4, three SLAs are depicted. In SLA2, a traffic of 10 MBit/sec has been specified which can be sent from A-ISP1 to C-ISP2 towards A-ISP2, while guaranteeing a maximum delay of 100 msec. The SLA scope defines these parameters for a stream entering at a scope begin point (I2) and a scope end point (I4). In SLA1, a stream of 20 MBit/sec is defined which can be sent from C-ISP1 to C-ISP2 towards A-ISP2 with a maximum delay of 50 msec. In this case, the SLA scope was specified to extend from I3 to I4. Traffic and delay limits are to be seen in this context. Finally, SLA3 specifies a stream which can be sent from A-ISP1 to C-ISP1 towards EC2 with a maximum delay of 150 msec. Its scope was defined to extend from I1 to E4. H-SLA and AS-SLA Relationship There is a fundamental difference between H-SLAs and AS-SLAs, even though both of them may cover service delivery between two access ISPs (e.g. AS-SLA1 and H-SLA3 in above figure). While an AS-SLA is an agreement between two adjacent ISPs (resp. a CPN and an ISP), an H-SLA is an agreement set up between two access ISPs (resp. CPNs). Access ISP 1
EC 1
I0
E0 I1
Core ISP 1
Core ISP 2
E1 I2
Access ISP 2
I4
EC 2
E4
req AS-SLA req AS-SLA req H-SLA ack H-SLA FIGURE 5. H-SLA Set-Up
When setting up an H-SLA, an AS-SLA must be available ensuring that data transfer can take place across core ISPs. In the figure above a possible sequence of actions is depicted. Here, A-ISP1 first sets up an AS-SLA with C-ISP1 with a scope end point at I4. Then, it sets up an H-SLA with the 9
G. Dermler
remote A-ISP2. Note that during transmission of data towards EC2, the classification rule of ASSLA ensures correct classification at I1, while the classification rule of the H-SLA is enforced by AISP4 at I4. End-to-end Traffic Agreements (EETA) When setting up SLAs between ISPs, there is a clear responsibility for payments: the buyer of an SLA is in charge of paying for it. Insofar, the sequence of SLAs used in support of end-to-end communication automatically reflects the sequence of responsibilities for payment and the directions of payment flow. When looking at flows exchanged between hosts the situation may be more complex due to the possibility of sharing the charge for a flow between the two end-customers. The concept is a generalization of the well known “reverse charging” used in the telephony world, where a callee may take over the charge for a call. Charge sharing for a flow is more flexible in that it allows the two end-customers to agree on any specific sharing scheme, e.g. requiring the sender to pay for 30 % and the receiver for 70 % of the charge. Some additional mechanism has to exist in order to indicate and enforce the distributed responsibilities for paying for a flow. Taking additionally into account that an end-customer ideally has to deal with its access ISP only (and never with remote access ISPs or even core ISPs)5, we request that several EETAs are employed to describe the distributed responsibility for payments. H-SLA * bw. ISP1, ISP2 * flow id * bwidth, QoS * price (100 c/m) * net charge flow
EETA * bw. EC1, ISP1 * flow id * flow dest (EC2) * bwdith, QoS * price (100 c/m) * charge (30 c/m)
EC 1
Access ISP 1
EETA * bw. EC2, ISP2 * flow id * flow src (EC1) * bwdith, QoS * price (100 c/m) * charge (70 c/m)
Access ISP 2
EC 2
FIGURE 6. EETA Usage Example
In the case depicted above a flow is set up which is transmitted from EC1 to EC2. As a result several EETAs are instantiated. Each of the two end-customers engages in an EETA with its access ISP specifying the flow including the two end-customers as well as the agreed on price and charge sharing scheme. In the example it is assumed that a price of 100 cents/min has been derived for setting up the flow, given that ISP1 resp. ISP2 request 10 resp. 90 cents/min. The two end-customers are supposed to have agreed on a charge sharing scheme of 30/70 for the sending resp. receiving side. The two EETAs then denote the following semantics:
5. Typically, an end-customer has anyway a long-term subscription relationship with his ISP. The discussion of details of such relationships (which may be similar to the access SLAs currently in use) is out of the scope of this paper. 10
G. Dermler
EETA 1 commits - ISP 1 to providing the flow between customers 1 and 2 with the requested QoS and price (100) - end-customer 1 to paying its charge share of 30 cents/min for the flow to ISP1 and ISP2 while confirming - to EC1 that EC2 has committed to pay its charge share EETA 2 commits - ISP 2 to providing the flow between customers 1 and 2 with the requested QoS and price (100) - end-customer 2 to paying its charge share of 70 cents/min for the flow to ISP1 and ISP2 while confirming - to EC2 that EC1 has committed to pay its charge share . Note that each EETA shields its end-customer from the access ISP of the other side (and any possibly existing core ISPs). 3.2.2 Coupling EETAs and SLAs for Flow Set-Up Both EETAs and a H-SLA with a scope reaching between source and destination access ISPs are required when setting up a flow between two hosts. While the H-SLA is necessary in order to provide the “pipe” for the flow traffic envisaged (with desired QoS characteristics), the EETAs are required to indicate to end-customers both that the pipe exists and that charge distribution has been accepted by all end-customers. In particular, one has to note that EETAs and SLAs involve fundamentally different parties. EETA1
Access ISP 1
EC 1
I0
EETA3
H-SLA(E4)
E0 I1
Core ISP 1
Core ISP 2
E1 I2
Core ISP 3
I3
Access ISP 2
E3 I4
EC 2
E4
FIGURE 7. Agreements required for a Flow Set-Up
3.3 Service Delivery Scenarios and Issues in CATI 3.3.1 RSVP based Flow Set-up and Charging Two different charging schemes are investigated in the CATI project. The first one is related to SLAs exchanged between different ISP domains (cf. in Section 3.2.1). Charging is performed on a course grained level, i.e. fees are paid dependent on the allocated aggregated bandwidth, duration of the allocation, and other parameters. The second charging scheme is performed on flow level using new RSVP objects that allow new and more advanced payment methods. RSVP determines one choice of signalling QoS requirements of single flows in an end-to-end fashion. As soon as the usage of resources becomes exclusive for the user or application performing the reservation, the question of charging for such an exclusive usage arises. Depending on the networking infrastructure and the networking model available, the signalling of flow requirements are different. As outlined in the internal CATI document [27], the IntServ or the DiffServ approach and their combinations are required to be considered for signalling purposes. However, how the basic principles for charging operate is described in the following. 11
G. Dermler
Two alternative approaches for charging these resources or the IP flow, abstractly termed Internet connection, in general are feasible. The first choice uses extensions for the RSVP protocol [12] which is able to carry information on the payment scheme applied, more specifically, information that determines the user's willingness to pay. This information may be used to charge for services in an account-based fashion, where the Access ISP maintains an account for the user and accumulates the charges over a certain period of time. The details of these accounts and its usage may be determined during flow set-up, and may be part of the End-to-end-traffic-agreement (EETA). Of course, this type of charging is performed quite similarly in the current telephone network, however, many details in this comparison are different. In the second choice, RSVP is used as well, but the sender pays money to the ISP by sending authenticated objects to be used for paying the currently used service. This approach as developed in the MicPart project of SNF SPP ElCom avoids the generation of a monthly invoice, it avoids any type of account-based information to be stored at the ISP's sided, and does not require a pre-paid account to be maintained. Only the objects containing electronic cash [12] are used to determine the willingness-to-pay and its payment at the same time. Any RSVP router on receiving such an RSVP object including charging or payment information, it has to perform some kind of policy control, probably with the help of some external policy server that checks whether the reservation request can be accepted based on the fact whether the user has paid or will pay for the flow reservation as well for his data transfer later on. Therefore, the flowbased charging functions should be located downstream in the view of the edge router in Figure 2, e.g. between the edge router 1 and the border router of ISP1. The use of RSVP is possible in two different solutions. One covers the homogeneous IntServ environment, where all RSVP messages are exchanged in an end-to-end fashion and all routers in the Internet are RSVP-aware. However, this may not be the complete future view of the Internet. Therefore, a mixture of RSVP-aware and non-RSVP-aware may exist. This scenario does not cause problems with respect to the developed RSVP charging extensions, since the non-RSVP-aware routers will ignore these extensions, explicitly the charging object in an RSVP message, and forward the message without any processing concerning its content. In a heterogeneous environment of IntServ and DiffServ clouds being interconnected to form the Internet, the only realistic scenario will show IntServ clouds at the edges of this Internet. Therefore, the EETA and its contents is based in the IntServ cloud and the EETA performs all the required RSVP signalling while interoperating between the end-customer and the Access ISP. Core ISPs will not be bothered by any type of single flow state, even not a soft state. The flow set-up in this case is based on the EETA/H-SLA combination to determine the end-to-end QoS for this flow. If micro-payments are used as described above, the flow of money is similar to the flow of data. In case of an account-based scheme, the Access ISP maintains the money and uses it accordingly for further SLA required for interconnecting his network with other ISP's networks. 3.3.2 Customizable VPN Service One main goal of CATI concerns the development of a management system for configurable VPN [17] services. The most popular use of VPN is a transparently secure data transfer service between two remote CPNs (called CPN-VPN in this document). VPNs use public networks (here the Internet) but protect their traffic from public access. The technique for doing so is tunneling combined with encryption. In order for an ISP to provide such a VPN service to its customers, the SLA framework can be used.
12
G. Dermler
The customer establishes an SLA with its access ISP describing the desired VPN. The description includes which subnets (possibly located in different countries) should be connected together via the VPN. The VPN provider (the customers access network) then has to set up an SLA with each access ISPs of these remote locations, describing what kind of tunnel they have to set up. The scope of these SLAs is similar to the semantics of the AS-SLA introduced above in the sense that it contains a classification rule (what traffic has to be routed through the VPN) that is not on the host level, but on the network level (subnet). Unlike QoS related AS-SLAs, pure VPN service SLAs do not need the collaboration with intermediary core networks. The pure VPN SLAs are established solely at two levels: first the user SLA with the VPN provider, then the SLAs between the VPN provider and the providers of the remote tunnel endpoints. This is reasonable because the intermediate ISPs have nothing to do with the VPN traffic but to forward it. Work (classification, tunneling, encryption) is only done at the tunnel endpoints. Note, that the tunnel endpoints must be as close as possible to the involved CPNs (at their access ISPs), because the VPN traffic is protected only within the tunnel. CATI set out to bring QoS to VPNs, because this is a key factor in making a VPN service competitive. For QoS provisioning the intermediate ISPs must be involved as well. Here, we need the fullblown SLA mechanisms as described in the earlier sections. We aim to combine and automate the VPN SLA mechanisms and the QoS SLA mechanism as described in [13]. If the ISPs offer QoS services for traffic aggregation at the same or even lower granularity as the traffic aggregation of a VPN, then the two services can be combined smoothly. Thus, an administrator of a CPN can setup a QoS VPN by establishing an SLA with the composite service server of his access ISP (see also [13]). This server will then establish an VPN AS-SLA with the access provider of each remote tunnel endpoint as described above. To offer QoS for the customer, it will establish an X-SLA (or also AS-SLA) between the upstream ISP(s) towards the remote tunnel endpoints. The datails of this approach are described in [13]. Note, that the implementation of CPN-VPN with QoS is much harder if the ISPs provide QoS mechanism at a finer granularity than at the autonomous system level. This is because the traffic aggregated in a VPN is encrypted and cannot be classified any more. However, DiffServ markings are not hidden and can be used. A Generic Broker Architecture for Configurable Services The VPN research in CATI focuses on CPN-VPN using the Internet Protocol Security Architecture (IPSec) and Differentiated Services to provide QoS. In order to allow ISPs to provide such QoS VPNs as a new and value-added service we designed a generic broker architecture for configurable Internet services [13]. The architecture coordinates services offered by the different autonomous systems. The brokers negotiate and manage SLAs. The services are configurable via SLA negotiation. The details of the communication mechanism between the brokers (the broker signaling) is subject to current and future CATI research (see e.g. [18]). In our implementation work we focus on X-SLAs for QoS and AS-SLAs for security. As mentioned before, the composition of both services is done by an instance called Composite Service Server. H-SLA and VPNs When a CPN-VPN is established and working, the traffic between hosts in the VPN can be finetuned with additional mechanisms. VPN providers could offer the possibility to set up a H-SLA
13
G. Dermler
between hosts participating the VPN. Such a solution requires, that each ISP that controls a tunnel endpoint, is capable to apply the requested policy to the VPN traffic. Another useful application for an H-SLA in conjunction with VPN is the connection of roaming users. Beside of the CPN-VPN there is also interest in VPN solutions that allow remote users to connect securely to their VPN. If such a user wants QoS, this will be specified with a special type of an H-SLA. However, unlike in the ‘H-SLA over VPN’ case, such H-SLAs (like any plain H-SLA) would require resource allocation in the core networks for possibly millions of host. Charging and Accounting for VPNs A VPN service as such, and especially a QoS-VPN service are advanced Internet services which call for a more elaborate charging scheme than flat-fee based charging. The charging is handled via SLAs, which describe the price and conditions for a VPN service. The price can depend on the usage of the service, the service parameters (e.g. the security level) and it can contain a flat-fee component. Externally, the charging and accounting for the VPN service will rely on the charging and accounting mechanism used in the SLA framework. Internally, the VPN traffic is fed by different traffic sources within the involved CPNs. There, more fine grained, resource allocation based charging and accounting mechanisms can be deployed. 3.3.3 SLA Trading AS-SLA Trading The problem of SLA negotiation (see AS-SLA definition, 3.2.1) is solved quite pragmatically today. SLAs are set up by operators using traditional communication methods (phone, fax, snail mail). This results in a large overhead per agreement and restrains providers changing the SLAs too often. Therefore, todays SLA are usually setup on a long-term time scale. Another issue is traffic fluctuation. Due to the rather static SLAs significant overprovisioning (for peak hours) has to be implemented in order to provide a good Internet service. Finally, the traffic's destination is handled in a very approximate way: it is either destined for a known peering partner or it is sent to the transit backbone provider (except for the TEN155 link, this corresponds to SWITCH's situation). SLA trading is a simple approach to automate such negotiation to create an electronic market for network resources. It requires a protocol that transports SLA offers and can finally be used to seal contracts. Security can be implemented by traditional digital signatures due to the bilateral nature of the negotiation process. Furthermore, trading entities are needed at each ISP. In its purest form, SLA trading will be completely automated and driven by the demand of customers (peer ISPs and/or local users). SLA trading is also related to QoS-routing. Combining service provisioning and route selection at the inter-domain level local optimization algorithms in traders can come to the same result as a traditional QoS-routing algorithm, e.g. shortest-widest path computation [15]. However, SLA trading is a more relaxed concept in the sense that different, heterogenous algorithms may be applied at different traders. Of course, this local degree of freedom comes at the expense of global sub-optimality. Within CAT, suitable concepts and algorithms for trading AS-SLAs were inverstigated. They are described in [16]. 14
G. Dermler
Usage of X-SLAs X-SLAs are introduced to CATI by adapting the DiffServ philosophy of a simple and scalable mechanism for QoS provisioning in the core networks. For each link between two autonomous systems, there are SLAs describing the profile of DiffServ traffic distinguished by classes and direction (inbound or outbound). In-profile traffic (traffic sticking to the parameters agreed upon in the SLA) entering the autonomous system (AS) will experience the agreed upon per-hop behavior. Explicitly, this is only guaranteed locally. From that perspective the scope of X-SLA is local to the ISP. However, users want end-to-end QoS. Therefore, we propose a notification mechanism for X-SLAs allowing for implicit end-to-end QoS. Upon changes in an inbound X-SLA, the ISP must notify peers that will probably be involved in the change. For scalability reasons, not every X-SLA change triggers such notifications. Notifications may need to be recursively propagated through different AS, but this propagation is also limited. Thus, the notifications are an essential part of a very coarse grained (heavily aggregated) QoS mechanism. X-SLAs contain no scope information. Their implicit scope is the DiffServ-Internet and is ensured by the limited notification mechanism. In [19] we showed, that such a limited notification is feasible using intelligent brokers and statistical measurements. The big advantage of X-SLAs is that they need less signaling than the other SLA mechanisms and that X-SLAs are very limited in numbers. Per inbound and outbound link, there is only as many SLAs as service classes exist (to date e.g. 3 for DiffServ).
4. Additional Aspects Considered for Charging and Accounting Besides the description of the integrative approach for charging and accounting in the Internet and VPN models, a number of special functionality and dedicated aspects are required to be further studied in detail. Therefore, the following subsections briefly outline important areas, which are covered in other deliverables of the CATI project.
4.1 Pricing The commercialization of the Internet determines a driving force to price Internet services appropriately. However, a major problem arises, since the pricing always is based on a business model, which is set by an Internet Service Provider (ISP). Therefore, the study of pricing models must be undertaken in a matter which allows ISPs to choose from a range of different pricing models, while these models characteristics and features are well known and a-priori determined explicitly. CATI follows an approach to investigate pricing models independently of an ISP's business model to be able to identify clearly the technical and economic advantages of the pricing model as such. A future set of studies is required to investigate the implementation of particular pricing models in ISP's business environments and certain market situations. However, to be able to achieve a valid set of requirements posed on pricing models, CATI started an evaluation of related work [24]. In addition, to obtain a a certain level of economic efficiency in pricing models applicable to the Internet, a dynamic pricing scheme for multi-class multi-provider Internet connections has been developed[25]. Since it is still under further detailed study, any details concerning its features and characteristics will be delivered in a later stage of the CATI project. Summarizing the current state, pricing models as they exist today, remain on a quite theoretical level and showing less implementation evaluations or investigations. The first known approach on imple15
G. Dermler
menting a market-based price setting based on second price auctions (generalized Vickrey auctions) has been reported. Of course, static pricing models, such as the well-known telephone tariff structures provide an alternative pricing scheme. However, it remains unclear up to now, whether a dynamic pricing scheme or a static pricing scheme will be the correct scheme to be implemented for Internet services. Since users prefer to achieve the best service for the lowest price, which should be predictable, the ISP's point of view obviously drives towards a revenue maximization component. These quite orthogonal requirements and its investigation in well-defined scenarios may lead to a mixture of pricing models in the Internet, having certain services being offered at a flat fee approach (static pricing), such as for e-mail, and other services such as high-quality video services being offered on a usage-based scale applying congestion-sensitive and dynamic pricing schemes.
4.2 Security A security architecture was developed within this project. The purpose of a security architecture is to identify assets and possible threats and to design a concept for a secure exchange of data between business parties. Business transactions that occur during the reservation, delivery, and payment of a service have to be protected from threats and thus have to be performed securely. The security architecture is based on the business model [20] and the trust model [21] and considers security requirements for an E-commerce scenario. The business model describes the process and the environment of the business scenario whereas the trust model explores the trust relationship between the different business parties. The scenario within CATI considers several involved parties (business entities) as described in chapter 3.1 (of the integration paper). The security architecture was divided up into three different views, namely a reservation view, service view, and clearing view. The views arose from the business model and consider different phases in the whole business process. The communication between the business entities (end-customer, ESP, and several ISPs) was separated into different flows, a data flow that contains the payload of the transfer service, and a management and control information (MCI) flow. The flows were investigated within different connections. The flows of a transfer service pass through network connections from business entity to business entity. These connections were analyzed and security requirements were determined based on the five categories of security, confidentiality, integrity, availability, non-repudiation, and authenticity [22].
4.3 Application Scenarios In order to demonstrate the developed charging functionality two demonstrator scenarios will be developed within the project. An IP phone will be provided on top of the service realized by the charging and accounting protocol by which applications can set up flows. Charging and accounting functionality will be made visible at the user interface of the IP phone indicating selected QoS, agreed on price and cost sharing scheme. In a second demonstrator the IP phone will be used as part of an electronic business scenario where a WWW-based service, besides offering electronic (e.g. audio) products, allows customers to contact salespersons (e.g. for free). The two scenarios are described at more detail in [7].
5. Final Observations Offering different services within a single services integrated network requires besides their technical characterization a notion of charging these services. Based on the two IETF proposals on Inte-
16
G. Dermler
grated Services (IntServ) and Differentiated Services (DiffServ) the CATI project investigates and designs approaches for integrating charging functionality in today’s Internet. Since the future of both of these approaches is locally restricted 6, quite unclear7, and even challenging8 at the same time. Even though the definition of exact services besides the best-effort service still distinguishes between IntServ and DiffServ services, the current discussion shows at least that there will be type of service which is better that the traditional best-effort service. As soon as these service offerings need to be part of an Internet Service Provider's (ISP) business model in an open market, the clear distinction of these services is essential. In addition, it comprises not the IP services as such any more, but must include lower level services (e.g., the access) and higher level services (e.g., Web-hosting, mail, or Virtual Private Network) as well. An increasing value chain for services can be seen as follows. The basic service provides Internet access only, which means that the flow of IP packets must be ensured in some way, sometimes delivering Quality-of-Service (QoS) issues, some other times providing a best effort type of service only. The second higher value of an Internet service includes the provision of a service which includes specific end-customer's or customer premises network's requirements. This may encompass a Virtual Private Network (VPN) support or the provision of a managed bandwidth service with a specified guarantee limit. Finally, the highest level of value may be visible in a complete business solution which is provided from the ISP to an end-customer or the operator of a customer premises network. Depending on the ISP's role in the market or his business model at least these distinguishable levels of service provisioning in an open market are visible. The notion of Service Level Agreements (SLA) and End-to-end Traffic Agreements (EETA) exactly describes the information necessary to determine the value of the service. In addition, a certain set of protocols or functions deals with their automated communication between end-customers and ISPs. Of course, the service complexity increases, particularly ranging from a pure Internet access to the complete business solution. The service opportunities and even higher values are envisioned in dedicated solutions for strategic businesses, virtual enterprises, or electronic commerce-based companies. Particularly, the stringent requirements of reliable, fault-tolerant, and some sort of real-time service will challenge the provision of Internet services. This becomes even more difficult, if the interconnection of multiple ISPs determine the delivery chain of IP packets. The vision of a future automated Internet access and services market may encounter ISPs and their service provisioning based on a particular service model which identifies the service characteristics and assigns values to each of these characteristics. These values are represented in pricing models which in turn are applied to charge for ISP services. Depending on the structure of a service and its usage in a given environment the pricing models chosen may show a flat-fee structure or a usagesensitive component or some suitable combination. The functions, mechanisms, and protocols provided for offering multiple services in an open market need to cope with these stringent economic restrictions expressed in various pricing models. If todays technology is able to support this variety
6. IntServ is usually considered of not being scalable to a large number of states to be maintained per flow. However, the proposed signalling protocol RSVP may serve as protocol in the local domain, to signal traffic characteristics to the backbone network only. 7. The future of DiffServ is based on the basic idea to provide aggregated Quality-of-Service. However, it seems that a certain type of mechanisms already known from the Asynchronous Transfer Mode (ATM) will be re-invented or applied, while trying to avoid the use of too much state per networking domain. 8. The combination of IntServ and DiffServ as they are known today determine a valid approach for end-to-end service provisioning in an multi-ISP Internet. 17
G. Dermler
and flexibility in a generalized fashion is an open questions, however, the CATI results intend to show and demonstrate that a service-independent and efficient manner exists to price and provide Internet services selectively.
6. References [1] S. Blake et al.: An Architecture for Differentiated Services, RFC 2475, Dec 1998. [2] K. Nichols et al.: A Two-Bit Differentiated Services Architecture for the Internet, Internet Draft, Apr 1999. [3] J. Wroclawski: The Use of RSVP with IETF Integrated Services, RFC 2210, Sep 1997. [4] J. Wroclawski: Specification of the Controlled-Load Network Element Service , RFC 2211, Sep 1997. [5] S. Shenker et al.: Specification of Guaranteed Quality of Service, RFC 2212, Sep. 1997. [6] Y. Rekhter at al.: A Border Gateway Protocol (BGP-4), RFC 1771, March 1995. [7] G. Dermler: CATI Application Sceanrios, CATI eliverable CATI-IBM-DN-P-001-1.2, Junn 1999. [8] G. Dermler: A Business Perspective to Structuring QoS enabled Communication and Charging, CATI deliverable CATI-IBM-DN-I-003-1.0, May 1999. [9] [Y. Bernet et al.: A Framework for Differentiated Services, Internet Draft, Feb. 1999. [10] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin: Resource Reservation Protocol (RSVP); RFC 2205, September, 1997. [11] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie: Integrated Services Operation Over Diffserv Networks, InternetDraft, June 1999 [12] G. Joller, B. Stiller, G. Fankhauser, N. Weiler: Charging, Payment, and Pricing APIs for Network Resource Reservations based on RSVP Signaling, CATI Deliverale ID: CATI-TIK-DN-P-0091.2, December 31, 1998 [13] T. Braun, M. Günter, M. Kasumi, I. Khalil: "Virtual Private Network Architecture", CATI deliverale, January 1999 [14] R. Balmer, T. Braun, F. Baumgartner, M. Günter, I. Khalil: Virtual Private Network and Qualityof-Service Management Implementation, CATI deliverable CATI-IAM-DN-P-001-1.1, June 30, 1999 [15] Z. Wang and J. Crowcroft, "Routing algorithms for supporting resource reservation," IEEE JSAC, 1996.
18
G. Dermler
[16] George Fankhauser, David Schweikert, Bernhard Plattner, "Service Level Agreement Trading for the Differentiated Services Architecture", TIK Technical Report No. 59, July 1999. [17] T. Braun, and M. Günter: Virtuell aber Real - Virtuelle Private Netze und deren Basistechnologien; NET - Zeitschrift für Kommunikationsmanagement, Hütig Fachverlage, April, 1999. [18] T. Braun, F. Baumgartner and M. Günter: Broker Signaling Protocol ; CATI-IAM-DN-I-0010.1, March, 1999. [19] M. Günter and T. Braun: Evaluation of Bandwidth Broker Signaling; Tech. Rep. IAM-99-002, May, 1999. [20] Kneer H., Zurfluh U., Matt C. (1999): Business Model, CATI-UZH-DN-I-001-2.0 [21] Weiler N. (1998): Trust Model, CATI-TIK-DN-L-010-2.0 [22] Kneer H., Zurfluh U., Matt C. (1999): Security Architecture, CATI-UZH-DN-I-002-3.0 [23] - H. Kneer, U. Zurfluh, C. Matt: _Business Roles and Relationships", Deliverable ID: CATIUZH-DN-P-003-1.0, May 6, 1999. [24] P. Reichl, S. Leinen, B. Stiller: _Pricing Models for Internet Services", Deliverable ID: CATITIKSWI-DN-P-008-2.2, March 17, 1999. [25] P. Reichl, G. Fankhauser, B. Stiller: _Dynamic Pricing Schemes for Multi-class Multi-provider Internet Connections", Deliverable ID: CATI-TIK-DN-P-012-3.0, June 17, 1999. [26] N. Weiler, G. Joller, B. Stiller, G. Fankhauser: _Trust Model", _Deliverable ID: CATI-TIK-DNP-010-2.0, May 28, 1999. [27] G. Joller, G. Fankhauser, B. Stiller: _Signalling for Integrated Services (IntServ) and Differentiated Servivces (DiffServ) in CATI", Deliverable ID: CATI-TIK-DN-I-011-0.8 (internal), January 26, 1999.
19
G. Dermler
7. Appendix A short argument is included in order to justify the usage of AS-SLAs in CATI. The so-called External Border Gateway Protocol (EBGP) routing model ([6]) is currently used within the Internet in order to perform routing between the administrative domains represented by CATI. An AS has boundary routers (border gateways) which keep track of the routes required to forward traffic to other AS. Routing is done towards destination AS to which hosts are connected. In principle, for each possible destination AS, an EBGP router may keep an entry indicating along which AS path traffic has to be routed. Since the association between an arriving IP packet and its destination AS can be established by using the network address part of the packet header, EBGP provides all information for selecting the required AS path. Were EGBP AS to coincide with DiffServ domains9, the scalability issue for SLA usage (with respect to storage) is of the same order, if SLAs provide service coverage to the ingress of destination AS only (but not to the final host destinations themselves). Under this assumption and given that around 10000 AS exist in today’s Internet, SLA handling becomes much more manageable compared with the case that for each destination a separate SLA is stored.
9. Note that both AS and DiffServ consider domains as concepts for aggregating networks under a joint administration rule. 20
G. Dermler
