O. Heckmann V. Darlagiannis M. Karsten R. Steinmetz KOM, TU- Darmstadt Internet Draft Bob Briscoe Document: draft-heckmann-tdp-00.txt British Telecom Expires: August 2002 March 2002 Tariff Distribution Protocol (TDP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes a very flexible and efficient protocol for distributing price information (tariffs) inside an Internet Service Provider's management system and to its customers. It is designed to work with multiple QoS architectures, for example Intserv [2] and Diffserv [4]. It can also be used for dynamic pricing. It can use a number of different transport mechanisms, e.g. embedding tariff messages as policy objects in RSVP [9] messages. As tariffs can get very complex, it is possible but not necessary to send tariffs as code (e.g. Java). The draft also contains clear definitions of tariff and related terms. Table of Contents Tariff Distribution Protocol March 2002 Status of this Memo ..............................................1 Abstract .........................................................1 1 Background .....................................................2 1.1 Structure of this Draft .......................................3 2 Definitions ....................................................3 2.1 Service ......................................................3 2.2 Session ......................................................3 2.3 Session Characterization .....................................3 2.4 Charge and Charge Advice .....................................3 2.5 Price Coefficient ............................................3 2.6 Price ........................................................3 2.7 Tariff .......................................................4 2 Application scenarios ........................................4 4 The General Structure of TDP ...................................6 5 Representation sublayer ........................................6 5.1 Representation of Tariffs ......................................6 5.2 TDP Message Types and Interaction ..............................7 5.3 Specification of the Tariff Message ............................8 5.4 Request Message ...............................................11 6 Transfer Sublayer ...............................................11 6.1 TCP ...........................................................12 6.2 UDP multicast .................................................12 6.3 HTTP ..........................................................13 6.4 RSVP Policy Objects ...........................................13 7 Related Work ..................................................14 7.1 Open Settlement Protocol ......................................14 7.2 Internet Open Trading Protocol ................................14 References ......................................................15 Appendix A. Example Tariff components ...........................16 Appendix B. Tariff example ......................................16 Appendix C. Example of tariff message ...........................16 Appendix D. Definition of TariffMessage using XML Schema ........18 Author's Addresses ..............................................20 1 Background One important aspect of market managed networking is pricing. In a competitive, market managed, multi-service Internet, a vast variety of different tariffs will exist, many of them might be updated regularly. TDP is a protocol for the flexible and efficient distribution of even the most complex tariffs. Heckmann et al Experimental - Expires August 2002 Page 2 Tariff Distribution Protocol March 2002 1.1 Structure of this Draft This draft is structured as follows: After this background information, a clear definition of pricing related terms like tariff, price and charge is given. Then the general structure of the Tariff Distribution Protocol (TDP) itself is presented. It consists of two layers that are presented afterwards. In the seventh section related protocols and their relationship to TDP are discussed. The document closes with the references, authors addresses and a copyright statement. 2 Definitions 2.1 Service In the following context the word _service_ is used for a low- level network service that an ISP offers to its customers, e.g. the Intserv [2] Guaranteed Service [3] or a service build on the Diffserv [4] AF/EF PHB [5], [16]. 2.2 Session The term session is used to describe the actual invocation and usage of one clearly specified service. 2.3 Session Characterization Charging if typically done per session, so sessions have to be characterized quantitatively. The term _session characterization_ is used for a set of well defined quantitative parameters (the session characterization parameters) that describes all aspects of a session that are relevant for a tariff. Example parameters are duration, number of bytes or packets sent or received, guaranteed service parameters (rate, peak rate, bucket depth, etc.), number of received ECN marked packets, etc. 2.4 Charge and Charge Advice The amount of money the provider charges for a session is the _charge_, which is equal to the customer's costs for that session. A _charge advice_ is used for the amount of money that the customer must pay for a (fictional or real) session. The differences between charge and charge advice are subtle but important. The charge advice is the output of the tariff while the charge is the output of the provider's charging and accounting system and is passed on (eventually in aggregated form) to the billing system. An example from phone tariffs will clearify that: A customer can find out the costs for a one minute call (the session) he plans to make by looking at his mobile phone provider's tariff. That is the charge advice. Once he makes that call his provider's charging and accounting system (CAS) stores that the customer owes the provider a certain amount of money, that is the charge. 2.5 Price Coefficient A price coefficient is the partial derivative of charge advice with respect to one session characterization parameter. 2.6 Price If a session is characterized by only one parameter, there is only one price coefficient and this coefficient is what people Heckmann et al Experimental - Expires August 2002 Page 3 Tariff Distribution Protocol March 2002 often intuitively call price (money per minute, per kilo etc.). But following Encyclopedia Britannica [6], a price is _the amount of money that has to be paid to acquire a given product_, therefore equal to the charge advice. To avoid confusion the word price is used in this context only as a general term. 2.7 Tariff A tariff is a set of rules for calculating the charge advices for sessions of one service. Thus, the input of a tariff is a session characterization and the output is a charge advice. One might think that a tariff is the same as the set of price coefficients but this only holds true for the simplest cases (linear tariff algorithms) as the examples below will show. It is useful to distinguish inside the tariff between the tariff algorithm and the tariff parameters, (see Table 1). The algorithm describes how the session characterization parameters are combined with the tariff parameters in order to obtain the charge advice CA. +----------------------------+-------------------------------+ |Session characterization |t, u | |parameters | | |----------------------------+-------------------------------+ |Tariff parameters |a, b, c | |----------------------------+-------------------------------+ |Tariff algorithm |CA(t, u) = a*t+b*u^c | |----------------------------+-------------------------------+ |Price coefficients of t |d(CA(t, u))/dt = a | |----------------------------+-------------------------------+ |Price coefficients of u |d(CA(t, u))/du = b*c*u^(c-1) | +----------------------------+-------------------------------+ Table 1: Example Tariff An example is given in [22]. The example also shows that the tariff parameters are not necessarily the same as the price coefficients. If a tariff algorithm is non-linear, the price coefficients are no longer constant (see the price coefficient for u). It makes sense to distinguish between the tariff algorithm and the tariff parameters. In a good implementation this has to be done anyway to separate data and methods. It is also efficient, because typically the algorithm will not be changed as often as the tariff parameters and TDP allows to send updates of the tariff parameters only, thus reducing message size. 2 Application scenarios One application scenario is to use TDP to distribute tariff related information inside a provider's management plane. Figure Heckmann et al Experimental - Expires August 2002 Page 4 Tariff Distribution Protocol March 2002 1 shows the modules of an ISP's management plane that are typically involved in tariff distribution. Provider | Customer M +-----------+ +---------+ | +---------+ a |Enterprise | |Tariff | | |Price | n |Policy |------>|Directory|------------>|Reaction | a |Control | / \ +---------+ | | +---------+ g +-----------+ | | | | e | | \ / | m +-----------+ | | +----------+ | e |Price |--- | |Charging &| | n |Calculation|............|..|Accounting| | t +-----------+ | +----------+ | / \ | | | | | +-----------+ | | ---------------------------------------------|--------------- D P |Mediation | | | a a +-----------+ | | t t | | a h /----------------------------------------|-----------\ \----------------------------------------|-----------/ | | ---------------------------------------------|--------------- S S | | e i \ / | r g +-----------+ | v n |Bandwidth | | i a |Broker | | c l +-----------+ | e i | n | g | Figure 1: Architecture Another application scenario is to use TDP to distribute price information from a provider to its customers. In both scenarios the instance that possesses the tariff information is called the tariff sender and the instance that receives the tariff information is called the tariff receiver. A tariff can be set manually with the enterprise policy control module (EPC). In a dynamically priced Internet tariff changes are automated and then originate the price calculation module. This module uses several data sources as input for it's decisions, for example the CAS and the mediation module (which aggregates and correlates data from the network infrastructure). Heckmann et al Experimental - Expires August 2002 Page 5 Tariff Distribution Protocol March 2002 The tariff directory stores all tariffs and forwards them towards the CAS and - if it exists - the bandwidth broker (BB). Note that the CAS and the BB might be distributed systems consisting of a number of boxes. The customers can be end-users or other providers. They can be informed about the tariffs via a push mechanism (tariff directory sends tariffs and tariff updates) and/or a pull mechanism (end- system requests a certain tariff). If the customer is a provider, it can use the pricing information as a further input source for its own price calculation module. 4 The General Structure of TDP TDP can be divided into two sublayers. The highest sublayer (representation sublayer) describes the two basic message types of TDP, the tariff and the tariff request message. XML is used as representation format and to specify how tariffs and related metainformation are encoded. A compact binary version of the tariff message is also specified (see Figure 2). +--------------------------+ | XML | Binary | Representation |--------------------------+ | TCP | UDP | RSVP | HTTP | Transfer +--------------------------+ Figure 2: TDP Layers The transfer sublayer offers a variety of transfer mechanisms that can be used to transport the messages. In this draft four different transfer mechanisms are specified but TDP is open to more transfer mechanisms. 5 Representation sublayer 5.1 Representation of Tariffs Some current mobile phone tariffs show that tariffs can be very complex. They can include special discounts (for example 10% discount after the 10th minute) and often depend on the time of the day and the day of the week (weekend...). It is unrealistic to expect that all future multi-service Internet tariffs will fit into a standardized scheme. The protocol accounts for this with flexibility. It can include any description of a tariff and it's parameters. It can use any tariff definition language but also allows the use of other programming languages, like Java, instead. As the distributed tariffs should also be human-readable, a textual description of the algorithm and the parameters can also be included as plain text, HTML [10] and/or XML [11]. TDP also reflects the possibility that there might also be a number of _standardized_ tariffs, that is tariffs where the algorithm is known to all parties involved in the communication Heckmann et al Experimental - Expires August 2002 Page 6 Tariff Distribution Protocol March 2002 and therefore no code has ever to be sent around but the algorithm has to be identified in a globally unique way. 5.2 TDP Message Types and Interaction The protocol uses two basic kinds of messages: the tariff message that contains either a complete tariff (consisting of tariff algorithm plus tariff parameters) or a tariff update (consisting of new tariff parameters only) and the request message that is used to request a certain tariff (see Figure 1). +---------------+-----+ Request Message +-----+---------------+ | | |<----------------| | | | Tariff Sender | TDP | Tariff Message | TDP |Tariff Receiver| | | |---------------->| | | +---------------+-----+ +-----+---------------+ Figure 3: TDP Message Types The protocol can be used in two different modes, the pull and the push mode, both modes can also be combined (mixed mode). Sender and receiver agree upon the mode used by means outside the protocol. Tariff and request messages can be sent with different transfer mechansisms (see section 6). 5.2.1 Push mode In push mode only tariff messages are sent, the order and time interval is completely up to the sender. No tariff request messages are used. The user has to find out the tariffs by listening to the stream of tariff messages. 5.2.2 Pull mode In pull mode the tariff receiver requests a specific tariff or the tariff for a specific service by sending a request message that is answered by the tariff sender with a tariff message. A single tariff message can answer more than one request. Pull mode uses an asynchronous request/reply mechanism. A tariff receiver can send any number of requests directly one after the other while the answering tariff messages can be send in a different order, with a different transport mechanism and with different delays. 5.2.3 Mixed mode The protocol can also be used in mixed mode which is equal to pull mode but the tariff sender can also send tariff information that was not requested. Heckmann et al Experimental - Expires August 2002 Page 7 Tariff Distribution Protocol March 2002 5.3 Specification of the Tariff Message TDP uses a XML message format to describe its messages, allowing the reuse of existing code like XML parsers and validators, e.g. Apache [11]. An example tariff message is included in the Appendix B. The XML Schema [17] specification of a tariff message is also included in the Appendix D. 5.3.1 Provider Tag The provider is identified globally by using his domain name (2nd level domain) in the provider tag. There must be exactly one provider tag in each tariff message identifying the provider offering this tariff. With the optional name tag one or more human readable names can be included, this information should not be used instead of the domain name above, it can be used by applications with user interfaces. 5.3.2 Tariff Tag Each tariff has one unique tariff ID. The ID must be unique only inside the provider space, the provider is responsible for managing the IDs. The tariff ID is not the same as the service ID because one tariff could be used for more than one service and the other way around. The ID can be any string up to a length of 255 bytes. The tariff tag must include exactly one ID tag and can also include any number of optional name tags with human readable information that must not be relied on to identify the tariff uniquely. Each tariff message must include exactly one tariff tag. 5.3.3 Service Tag Each service the provider offers has one unique service ID. The ID must be unique only inside the provider space, the provider is responsible for managing the IDs. The ID can be any string up to a length of 255 bytes. The service tag must include exactly one ID tag and can also include any number of optional name tags with human readable information that must not be relied on to identify the service uniquely. Each tariff message must include one or more service tags. If more than one service tags are included the tariff described by the message must be able to calculate charge advices for all the listed services. 5.3.4 Algorithm Tag The algorithm tag describes the tariff algorithm. Each tariff message includes zero or one algorithm tags. If no algorithm tag is included, then the information in the message is usable only by senders that know the algorithm by other means (because the algorithm is standardized and known by everyone or because the Heckmann et al Experimental - Expires August 2002 Page 8 Tariff Distribution Protocol March 2002 algorithm was sent before and has not changed yet). This is called a tariff update. The algorithm tag includes exactly one version tag that contains a version number (integer). It can contain any number of valid tags that describe the time intervals in which the tariff is valid. The algorithm tag contains any number of description tags that describe the algorithm. The description tag has two attributes: content and referenced. The default value for content is _text/plain_ and for referenced is _true_. The description tag includes the algorithm itself in a form that is specified by the content attribute. The content attribute uses MIME-Types [20] [21]. If the referenced attribute is set to _true_ then the content of the description tag is a url that points to a remote document with the algorithm description. If referenced is set to _false_ then the algorithm description is included directly in the description tag body. The algorithm description is now specified for several content types, the protocol is open for more content types. 5.3.4.1 Algorithm Description for content-type _text/plain_ The algorithm description is included in a _text_ tag. At least one text tag has to be included, but more than one is possible. Every text tag must include the complete algorithm description, the content of the text tags - which can differ in the language used, etc. The attributes of the text tag are not further specified in this version of the draft. The content of the text tag must be plain text as specified in [20] [21]. 5.3.4.2 Algorithm Description for content-type _text/html_ The algorithm description is included in a _html_ tag. At least one html tag has to be included, but more than one is possible. Every html tag must include the complete algorithm description, the content of the html tags _ which can differ in the language used, html version used, etc. The attributes of the html tag are not further specified in this version of the draft. The content of the html tag must be HTML as specified in [10]. 5.3.4.3 Algorithm Description for content-type _text/xml_ The algorithm description is included in a _xml_ tag. At least one xml tag has to be included, but more than one is possible. Every xml tag must include the complete algorithm description, the content of the xml tags - which can differ in the language used, xml version used, etc. The attributes of the xml tag are not further specified in this version of the draft. The content of the xml tag must be XML as specified in [18]. 5.3.4.4 Algorithm Description for content-type _binary/java_ The algorithm description consists of any number of class tags, each including one java class needed for the tariff algorithm. Heckmann et al Experimental - Expires August 2002 Page 9 Tariff Distribution Protocol March 2002 Alternatively one jar (Java archive) tag can be used that contains a number of classes. The body of the description must include the name of the classes included that is the tariff algorithm and that will be executed. Each class tag has an obligatory name attribute that describes the name of the java class that is included. The attribute encoding describes how the class is encoded, for which the default value is _base64_ [20]. The optional compression attribute can be used to describe the compression algorithm used to compress the class before it was encoded with the method specified by the encoding attribute. The default is to use no compression, the default value for the compression attribute is therefore _NO_. 5.3.5 Parameters Tag The parameters tag includes the tariff parameters and related metainformation. The parameters tag must include exactly one version tag, the same rules as for the version tag, part of the algorithm tag, apply. The parameters tag can also include any number of valid tags, the same rules as for the valid tag, part of the algorithm tag, apply. The parameters tag includes any number of description tags, at least one description tag must be included. The description tags have a content attribute with the default value _text/plain_ and a referenced attribute with the default value _true_. The description tag includes the tariff parameters in a form that is specified by the content attribute. The content attribute uses MIME-Types [20] [21]. If the referenced attribute is set to _true_, then the content of the description tag is a url that points to a remote document with the tariff parameters description. If referenced is set to _false_ then the tariff parameters description is included directly in the description tag body. The tariff parameters description is now specified for several content types, the protocol is open for more content types. 5.3.5.1 Parameters Description for content-type _text/plain_ The tariff parameters description is included in a _text_ tag. At least one text tag has to be included, but more than one is possible. Every text tag must include the complete parameters description, the content of the text tags _ which can differ in the language used, etc. The attributes of the text tag are not further specified in this version of the draft. The content of the text tag must be plain text as specified in [20] [21]. 5.3.5.2 Parameters Description for content-type _binary_ The tariff parameters description is included in a _binary_ tag. At least one binary tag has to be included, but more than one is possible. Every binary tag must include the complete parameters, the content of the binary tags _ which can differ in the encoding used, etc. Each binary tag has an encoding attribute that Heckmann et al Experimental - Expires August 2002 Page 10 Tariff Distribution Protocol March 2002 describes the way the binary information is encoded in the xml message. The default value is _base64_ [20]. The content of the binary tag is a byte array that can be read by the algorithm code. The specification of this byte array is done by the author of the tariff algorithm. 5.3.6 Reference Tag If a tariff message is a direct answer to a request message it references this request message with one reference tag. Any number of reference tags can be included in a tariff message. The reference tag must include two tags, the sender tag that contains the IP address of the originator of the request message and the num tag that contains an integer that identifies the request message (as there might be more than one request messages from one IP address). The content from the reference tag must be exactly identical to the content of the reference tag in the according request message. 5.4 Request Message The second message type is the request message. It allows requesting either a special tariff or - in case that tariff receivers do not yet know, what tariff they are interested in - allows requesting tariffs for one service. Service discovery is outside the scope of TDP. The XML Schema specification for the request message and an example are in the Appendix D. 5.4.1 Reference Tag There must be exactly one reference tag in a request message. The reference tag identifies the request message and is repeated in the tariff message that answers this request message. The reference tag must include two tags, the sender tag that contains the IP address of the originator of the request message and the num tag that contains an integer that identifies the request message (as there might be more than one request messages from one IP address). 5.4.2 Request Tag There must be exactly one request tag in a request message. It specifies either the tariff that is requested or the service for which a tariff is requested. It includes either one tariff or one service tag. The tariff and the service tag include one further tag which can be an ID tag or a name tag. In the ID tag the tariff or service ID is entered and in the name tag the human readable name would be entered (see 5.3.2 and 5.3.3). 6 Transfer Sublayer Different transfer mechanisms can be used to send the messages of the representation sublayer (see section 5). Which ones are used by actual instances of the protocol are decided upon by means outside of the protocol (e.g. by an SLA). Heckmann et al Experimental - Expires August 2002 Page 11 Tariff Distribution Protocol March 2002 6.1 TCP Plain TCP connections offer a minimalistic reliable transport mechanism for the TDP messages. A small header is added to the tariff and request message: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PDU for TCP transport The Payload consists of exactly one tariff or request message. The length field describes the number of bytes in the payload. 6.2 UDP multicast In case UDP multicast is used the PDU takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Segm. Number | Total Segments| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Payload (or part thereof) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: PDU for UDP transport The Payload consists of the tariff or request message. The sender can divide the message into segments. This is necessary if the message is bigger than the maximum allowed message size of UDP [19] but the sender is free to fragment a message also for smaller message sizes. All segments get the same ID, they get a sequential segment number starting with 0. The _total segments_ field in the header is set to the total number of segments for that message (so a minimum of one is entered here). The sender has to make sure that two different tariff messages get two different IDs. An ID number can be reused after a timeout period of 2 times the maximum segment lifetime of TCP. Heckmann et al Experimental - Expires August 2002 Page 12 Tariff Distribution Protocol March 2002 6.3 HTTP The TDP request messages are sent as an HTTP [10] request message and the TDP tariff messages are sent as HTTP response messages. The message body carries the TDP request or the tariff message. 6.4 RSVP Policy Objects +-------------+-------------+-------------+-------------+ | Length | POLICY_DATA | 1 | +---------------------------+-------------+-------------+ | Data Offset | 0 (reserved) | +---------------------------+-------------+-------------+ | | // Option List // | | +-------------------------------------------------------+ | | // Policy Element List // | | +-------------------------------------------------------+ Figure 6: RSVP POLICY_DATA object +-------------+-------------+-------------+-------------+ | Length | P-Type | +---------------------------+---------------------------+ | | // Policy information (Opaque to RSVP) // | | +-------------------------------------------------------+ Figure 7: Policy Element 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Segm. Number | Total Segments| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TDP Message (or part thereof) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Policy Information Heckmann et al Experimental - Expires August 2002 Page 13 Tariff Distribution Protocol March 2002 The POLICY_DATA object as specified in [8] is listed in Figure 6. The TDP Message is embedded as policy information (Figure 7) in a policy element (Figure 8) as part of the policy element list of the RSVP POLICY DATA object. The Payload of the policy information consists of the tariff or request message. The sender can divide the message into segments. This is necessary if the message is bigger than the maximum allowed message size for policy information [8] but the sender is free to fragment a message also for smaller message sizes. All segments get the same ID, they get a sequential segment number starting with 0. The _total segments_ field in the header is set to the total number of segments for that message (so a minimum of one is entered here). The sender has to make sure that two different tariff messages get two different IDs. An ID number can be reused after a timeout period of 2 times the maximum segment lifetime of TCP. 7 Related Work We now describe two other related protocols and compare them with the Tariff Distribution Protocol presented in this paper. 7.1 Open Settlement Protocol The Open Settlement Protocol (OSP, [13]) is an ETSI TIPHON specification that describes a set of protocols to permit the exchange of inter-domain pricing, authorization and settlement information between Internet telephony operators. The pricing part overlaps with the Tariff Distribution Protocol presented in this paper, yet, there are a lot of differences. Both protocols are XML-based and both allow a binary format. While OSP uses HTTP only as underlying protocol, the Tariff Distribution Protocol allows different transport mechanisms. OSP can be used to exchange prices (OSP terminology) - expressed in the terminology of this work, OSP is restricted to very simple tariffs with one price coefficient (like the per-minute prices for phone calls). As OSP is more intended as settlement protocol between providers, it offers an explicit mechanism to accept or decline prices (pricing confirmation). It offers no mechanism to request a special tariff or a tariff for a given service. Summarizing, OSP offers broader capabilities but is far less powerful in the area of price communication and it is specialized for the IP telephony use case. 7.2 Internet Open Trading Protocol The IETF Internet Open Trading Protocol (IOTP) specification [14] describes a framework for payment protocols and uses XML over HTTP. This work is complementary to the Tariff Distribution Protocol as it is mostly concerned with the settlement, while the Tariff Distribution Protocol determines how the individual charges the bill consists of are calculated. Heckmann et al Experimental - Expires August 2002 Page 14 Tariff Distribution Protocol March 2002 References: [1] M3I Project, http://www.m3i.org/. [2] Braden R., Clark D., Shenker S., "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [3] Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [4] S. Blake, D. L. Black, M. A. Carlson, E. Davies, Z. Wang, and W. Experimental RFC, December 1998. Weiss, "RFC 2475 - An Architecture for Differentiated Services". [5] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, "RFC 2597 - Assured Forwarding PHB Group". Request for Comments, June 1999. [6] Encyclopaedia Britannica, http://www.britannica.com/. [7] Merriam Webster, http://www.m-w.com/. [8] S. Herzog, "RFC 2750 - RSVP Extensions for Policy Control", Standards Track, January 2000. [9] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. RFC 2205 - Resource ReSerVation Protocol (RSVP) _ version 1 functional specification. Standards Track RFC, September 1997. [10] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1", Standards Track, January 1997. [11] Apache XML Project, Apache Organisation, http://xml.apache.org/. [12] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, Dave Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note 08, May 2000. [13] European Telecommunications Standards Institute (ETSI), "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage exchange", ETSI TS 101 321 V2.1.1, August 2000 [14] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000. Heckmann et al Experimental - Expires August 2002 Page 15 Tariff Distribution Protocol March 2002 [15] X. Wang and H. Schulzrinne, "RNAP: A resource negotiation and pricing protocol", In International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77-- 93, Basking Ridge, New Jersey, June 1999. [16] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [17] David C. Fallside, " XML Schema Part 0: Primer", W3C Recommendation, 2 May 2001 [18] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6, October 2000 [19] J. Postel, "User Datagram Protocol", RFC 768, August 1980 [20] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996 [21] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996 [22] Oliver Heckmann, Vasilios Darlagiannis, Martin Karsten, and Ralf Steinmetz. A Price Communication Protocol for a Multi-Service Internet. In Informatik 2001 - Wirtschaft und Wissenschaft in der Network Economy - Visionen und Wirklichkeit (GI/OCG 2001), September 2001. Appendix A. Example Tariff components Session characterization parameters: t, u Tariff parameters: a, b, c Tariff algorithm: Price coefficient of t: Price coefficient of u: Appendix B. Tariff example Session characterization parameters: t, u Tariff parameters: a, b, c Tariff algorithm: CA(t, u)= a * t + b * u^c Price coefficient of t: d/dt(CA(t, u)) = a Price coefficient of u: d/du(CA(t, u)) = b * c * u^(c-1) Appendix C. Example of tariff message Heckmann et al Experimental - Expires August 2002 Page 16 Tariff Distribution Protocol March 2002 bt.com British Telecom ... 131 40 IntServ GS 3 20.01.00 ... ... ... 305 20000 Heckmann et al Experimental - Expires August 2002 Page 17 Tariff Distribution Protocol March 2002 ... http://www.bt.com/... 162.154.20.41 12 ... Appendix D. Definition of TariffMessage using XML Schema This is the root element of the schema Heckmann et al Experimental - Expires August 2002 Page 19 Tariff Distribution Protocol March 2002 Global ID Author's Addresses Oliver Hechmann Vasilios Darlagiannis Martin Karsten Ralf Steimetz KOM, TU-Darmstadt Merch str. 9 Phone: +49-6151-166150 Darmstadt, Germany Email: heckmann@kom.tu-darmstadt.de Bob Briscoe B54/74, BT Labs Martlesham Heath Ipswich, IP5 3RE Phone: +44 1473 645196 England Email: bob.briscoe@bt.com Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Heckmann et al Experimental - Expires August 2002 Page 20 Tariff Distribution Protocol March 2002 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Heckmann et al Experimental - Expires August 2002 Page 21