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