INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT
Network Working Group Muneyoshi Suzuki
INTERNET DRAFT NTT
Category: Informational February 10, 1998
Architecture of the Resource Reservation Service
for the Commercial Internet
<draft-rfced-info-suzuki-00.txt>
Status of This Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
1. Introduction
With the development of new multimedia applications, such as voice,
audio, picture, and video communication, the demands on the resource
reservation service are increasing, especially as Internet traffic
volume grows explosively due to these applications. Therefore,
tariff systems for Internet service have tended to adopt measured
rate billing, and the resource reservation setup protocol [1, 2] is
increasingly important as a method for implementing measured rate
billing. The resource reservation setup protocol must support
billing if it is to be applied to the commercial Internet, especially
measured rate billing between interconnected Internet Service
Providers (ISPs) is needed.
The purpose of this document is to clarify the architecture that
should be used for the resource reservation service for the
commercial Internet. First, this document explains the basis of the
tariff for current telecommunication and Internet services. Then it
clarifies problems in the billing for Internet service, and describes
how billing can be improved by using the resource reservation setup
protocol. Finally, it also studies technical and application models
for a commercial resource reservation service model, and clarifies an
architecture for the resource reservation setup protocol.
Incidentally, it is essential to examine billing based on business
administration issues, not technical ones. For example, on a
telephone service, it technically makes sense to charge the caller
when the user being called is on another line. This is because,
Suzuki Informational [Page 1]
telephone switches were in operation when they notified the caller
that the number he called was busy. However, such a billing policy
is contrary to the customs of business. Readers should note that the
billing problems and solutions discussed in this document are not
only based on the technical viewpoint.
2. The Basis of the Tariff
Basic elements that determine the network tariff are distance,
bandwidth, time, and information volume. In many cases, the network
tariff reflects the link cost to some extent.
In this document, distance means the distance between the regions
where users call from and to, not the actual length of the physical
links that connect users. In actual communication, a route depends
on network situations, so a charge based on the physical link
distance is inappropriate.
2.1 The Tariff in Telecommunication Services
Classifications of the basic styles of tariff systems in
telecommunication services and some examples are shown below. The
following classifications do not cover applied billing styles, for
example contents-based charging or premium charging such as the Dial
Q2 service of NTT, or the 900 telephone service.
o Flat-rate billing
- Leased line
In most cases, the tariff is based on distance and bandwidth.
- PVC-based frame relay and ATM
In most cases, the tariff is based on distance and bandwidth.
o Measured-rate billing
- Telephone
In most cases, the tariff is based on distance and time.
- Circuit switching
In most cases, the tariff is based on distance, bandwidth, and
time.
- SVC-based frame relay and ATM
In most cases, the tariff is based on distance, bandwidth, and
time, or information volume.
Suzuki Informational [Page 2]
- X.25 packet switching
In most cases, the tariff is based on information volume.
Furthermore, measured rate billing is classified into calling- or
called-party billing. The basic charge style for telecommunication
service is calling-party billing.
o Calling-party billing
- Usual telephone service
o Called-party billing
- The Free Dial service of NTT and the 800 telephone service.
Basically, telecommunication service is designed for connection-
oriented, point-to-point, and bidirectional communication. In the
case of measured-rate billing, usually the calling or the called
party pays the bidirectional communication charge. In the case of
called-party billing, a function that allows incoming calls to be
accepted or refused based on the calling-party address, or a function
that restricts the calling-party addresses that are permitted to use
called-party billing, is indispensable. This is because, the
communication charge that a called party is willing to accept is
usually limited.
The current tendency in telecommunication-service tariff systems is
to change from measured-rate billing, which reflects link costs
accurately, to flat-rate billing, which simplifies the charging
system, and service tends to be provided by flat-rate billing inside
a single provider. The tariff for services between provider is
usually the sum of the individual providers charges. Flat-rate
billing, like that within a single provider, is not currently
realistic for services that cross providers.
2.2 Tariffs for Internet Service
Classifications of basic styles and examples of the tariff system for
Internet service are shown below.
o Flat-rate billing
- Internet access via leased line, PVC-based frame relay, or ATM
In most cases, the tariff is based on bandwidth.
Suzuki Informational [Page 3]
o Measured-rate billing
- Dialup Internet access using a modem or N-ISDN
In most cases, the tariff is based on time.
- Internet access via leased line, PVC-based frame relay, or ATM
Some ISPs have adopted information-volume-based tariff systems.
Note: Dialup access charges in this document do not include the basic
telephone fee.
Until now, the tariff system for Internet access has mainly been
flat-rate billing, because measured-rate billing is technically
difficult to implement. However, the development of new multimedia
applications, such as voice, audio, picture, and video communication,
has caused the traffic over the Internet to increase explosively.
The cost of using the public network service is lower than when using
a private network system, if users can share equipment and lines.
However, if the traffic from all its users is at a steady high rate,
the cost advantage of the public network service is lost. Therefore,
Internet service tariff systems, although they use leased line
access, tend to adopt information-volume-based tariff systems.
3. Billing in the Resource Reservation Service
3.1 Problems of Billing in Internet Service
Basically, the tariff system for Internet service seems similar to
that for telecommunication service. However, note that the tariff
system for Internet service based on the access method from the user
site to the ISP, is not based on the end-to-end communication method.
The Internet is a connection less and unreliable communication, and
some users are beginning to use it for multicast communication. But,
the telecommunication is basically a connection-oriented, point-to-
point, and bidirectional form of communication, so telecommunication
and Intrenet communication are essentially different in some ways.
Current Internet service does not allow billing based on end-to-end
user site distance. This is because the structure of the IP address
is flat, rather than a layered structure that contains information
about the provider and region. So information about distance for
billing purpose cannot be obtained from the IP address directly.
Note: In this document, an address means an identifier, such as a
class A, B, or C IP address, that uniquely distinguishes an end
point. It does not means a group identifier such as a class D
address.
Suzuki Informational [Page 4]
For Internet service, billing based on bandwidth can be provided, but
only for the line bandwidth between the user site and the ISP; it is
not based on the end-to-end user or application bandwidth, such as
the bandwidth in telecommunication services.
Current Internet service, except for the dialup access, does not
allow billing based on time because the IP is a connection less
communication, and timing information about the beginning and ending
of billing is too difficult to obtain.
Some current ISPs have adopted information-volume-based tariff
systems. However, this billing is based on the information volume of
IP packets that are sent to or received from the user site and the
ISP. Again, because the IP is a connection less and unreliable
communication, it is too difficult to provide billing based on the
information volume of IP packets that are actually used between end-
to-end users or applications.
It is not impossible to provide both user billing, and application
provider billing over the Internet when particular services are used.
These forms of billing are equivalent to calling- and called-party
billing in telecommunication service. However, obtaining the timing
information about the beginning and ending of application usage at
the IP layer is too difficult because the IP is a connection less
communication. To have billing based on usage time, the service
application responsible for the bill must identify the user and
monitor the usage. Also a billing process, where part of the billing
is transferred from the user to the service provider, must be
implemented. As a result, the billing system complexity is
increased.
3.2 Improved Billing Using the Resource Reservation Setup Protocol
As explained above, billing for current commercial Internet service
has many problems, but a resource reservation setup protocol may
solve these problems.
For example, the resource reservation setup protocol ensures the
availability of end-to-end network resources, so billing based on
bandwidth (FlowSpec) between user sites may be possible. Also, the
resource reservation setup protocol explicitly shows the resource
acquire and release timings, so billing based on time may be
feasible.
Suzuki Informational [Page 5]
The resource reservation setup protocol also guarantees QoS based on
the FlowSpec, so billing based on the information volume that is
actually used between end-to-end users or applications may also be
feasible. Furthermore, there is a possibility that the billing for
each IP flow can be distributed to ether the sender or the receiver.
However, the resource reservation setup protocol cannot solve the
problem of how billing can be based on distance because the flat
structure of the IP address does not change and it is still
impossible to obtain information about distance for billing from the
IP address directly even when the resource reservation setup protocol
is used.
4. Technical Model of the Resource Reservation Service
This section looks at an unreliable, unidirectional, and tree-
structured multicast architecture as a technical model for a resource
reservation service. The QoS to all receivers is assumed to be the
same, and flow merging is not examined.
+---+
| S |
+---+
+-----------------/---\-----------------+
| a / \ b |
| / \ |
| / ISP-A /\ |
| / / \ |
| / c / \ d |
+-----------/--------/------\-----------+
+---+ +-------+ +---+
|R1 | |router | |R2 |
+---+ +-------+ +---+
+-----------------/---\-----------------+
| e / \ f |
| / \ |
| / ISP-B /\ |
| / / \ |
| / g / \ h |
+-----------/--------/------\-----------+
+---+ +---+ +---+
|R3 | |R4 | |R5 |
+---+ +---+ +---+
Fig. 4.1: Resource Reservation Service Model.
Suzuki Informational [Page 6]
As shown in Fig. 4.1, ISP-A and ISP-B are interconnected, a sender S
and receivers R1 and R2 belong to ISP-A, and receivers R3, R4, and R5
belong to ISP-B. The links shown in Fig. 4.1 represent the logical
links that connect the regions which decide the tariff, not the
physical links that connect users. This section studies the receiver
billing and the sender billing resource reservation service with this
model.
4.1 Receiver Billing
When the resource reservation service is provided under receiver
billing, the problem is how to bill for the shared links, such as b,
c, and f. The shared link cost must be distributed and billed to
receivers based on some rule.
One solution inside a single ISP is to adopt a tariff system that
does not depend on how the links shared between receivers. Billing
that is based on the cost of the links that make up the multicast
tree is equivalent to billing based on distance. Therefore, billing
that does not depend on the link sharing approach is equivalent to
billing that is not based on distance. This means the billing can be
based on bandwidth (FlowSpec), time, and information volume.
For example, if an interconnected destination ISP is regarded as a
receiver, ISP-A bills to R1, R2 and ISP-B, and ISP-B bills to R3, R4,
and R5 [3]. The billing from ISP-A to ISP-B is distributed based on
some rule, and is added to the base charge in ISP-B. If a large
number of users join the multicast and the statistical tendency of
network utilization is known, it is possible to provide this type of
tariff system, although it does not accurately reflect communication
costs.
Another solution is to distribute the shared link cost among the
receivers that share the link. For example, the cost of link b would
be shared by R2, R3, R4 and R5. This method does reflect accurate
communication costs. However, in practice it is difficult to
implement the billing system since the complexity of computing the
cost of the shared link, located near a sender like b, is increased
because the receiver can dynamically join and leave the multicast
tree.
Therefore, in the case of receiver billing, if many users join the
multicast and the statistical tendency of network utilization is
known, billing based on bandwidth (FlowSpec), time, and information
volume can be provided.
Suzuki Informational [Page 7]
4.2 Sender Billing
When the resource reservation service is provided under the sender
billing, the problem due to the shared link is avoided, because there
is no need to distribute the shared link cost. In the above model,
the sender would be billed for the link costs from a to h.
Therefore, with sender billing, billing based on accurate link costs
can be provided. Billing based on the link cost is equivalent to
billing based on distance. However, information about distance for
billing cannot be obtained from the IP address directly. Therefore,
a database that can extract information about distance from the
destination IP address is needed to enable billing based on the link
cost.
This is also true for sender billing: if a number of users join the
multicast and the statistical tendency of network utilization is
known, it is possible to provide billing based on bandwidth
(FlowSpec), time, and information volume. That is, the sender pays
for the billing to R1, R2, and ISP-B in ISP-A, and to R3, R4, and R5
in ISP-B.
Therefore, with sender billing, if a database is implemented that can
extract information about distance for billing from the destination
IP address, it will be possible to provide billing based on distance,
bandwidth (FlowSpec), time, and information volume. And if many
users join the multicast and the statistical tendency of network
utilization is known, it will also be possible to provide billing
based on bandwidth (FlowSpec), time, and information volume.
5. Application Model for the Resource Reservation Service
This section examines the following multimedia applications to
develop an application model for the resource reservation service.
o Broadcast-type application model
o Advertisement-type application model
o Conference-type application model
Methods of implementing the application model using the technical
model described in the previous section are also examined.
Suzuki Informational [Page 8]
5.1 Broadcast-type Application Model
We assume that the broadcast-type application model has the following
features.
o The application provider broadcasts to receivers using the
multicast, and, in practice, the application is open to the public.
o Many receivers subscribe to the broadcast, and the statistical
tendency of network utilization is known.
o Joining the multicast tree is initiated from the receiver.
o The receiver pays the full amount billed.
o The billing is based on information volume or bandwidth (FlowSpec)
and time, and not on distance.
Features of this model correspond to receiver billing in the
technical model, so it is appropriate for this model to be supported
by it. Therefore, receiver billing based on bandwidth (FlowSpec) and
time, or information volume can be provided.
5.2 Advertisement-type Application Model
We assume that the advertisement-type application model has the
following features.
o The application provider advertises to receivers using the
multicast, and, in practice, the application is open to the public.
o Many receivers subscribe to the advertisement, and the statistical
tendency of network utilization is known.
o Joining the multicast tree is initiated from the receiver side.
o The application provider pays the full amount billed.
o A function that restricts the region in which the receiver is
permitted to join, or a function that decides whether to accept or
refuse the joining request based on the IP address of the receiver
or based on the tariff to be billed, is indispensable. This is
because the communication charge that is acceptable to an
application provider is usually limited.
Suzuki Informational [Page 9]
Features of this model roughly correspond to sender billing in the
technical model, so it is appropriate for this model to be supported
by it. But this model needs a function that restricts the region in
which the receiver is permitted to join, or a function that decides
whether to accept or refuse the joining request based on the IP
address of the receiver or based on the tariff to be billed.
If the region that the receiver is permitted to join is simply
restricted by the ISP boundary, the model can be implemented by
restricting the IP flow forwarding between ISPs.
But if the decision to accept or refuse the joining request is based
on the IP address of the receiver or based on the tariff to be
billed, a database that can extract information about permission or
distance for billing from the destination IP address is needed. In
the resource reservation setup protocol, a procedure that supports
this kind of processing is also needed.
However, if this procedure is processed only by the sender, and the
number of receivers significantly increases, saturation of the sender
protocol processing may occur. Therefore, an intermediate node is
needed inside the multicast tree, and this intermediate node will
decide whether to accept or refuse the joining request.
Therefore, in the advertisement-type application model, if the region
that the receiver is permitted to join is simply restricted by the
ISP boundary, it is appropriate for this model to be supported by the
sender billing in the technical model. Thus, sender billing based on
bandwidth (FlowSpec) and time, or information volume, can be
provided.
If the decision to accept or refuse the joining request is based on
the IP address of the receiver or based on the tariff to be billed,
in addition to the sender billing in the technical model, a database,
that can extract information about permission or distance for billing
from the destination IP address is needed. In the resource
reservation setup protocol, a procedure that supports this process is
also needed. In this case, it can be provided by sender billing
based on distance, bandwidth (FlowSpec) and time, or information
volume.
5.3 Conference-type Application Model
We assume that the conference-type application model has the
following features.
o The conference is held by a small number of participants.
Suzuki Informational [Page 10]
o The statistical tendency of network utilization in the conference
depends on each conference style and the tendency is hard to
estimate.
o Joining the conference is initiated by each participant. That is
- Joining the multicast tree from an existing participant or
receiving information from the conference server is initiated by
the receiver.
- Construction of the multicast tree for existing participants or
information sent to the conference server is initiated by the
sender.
o Management of conference participants is indispensable. A function
that can decide to accept or refuse a participation request based
on the IP address of the potential participant, or a similar
function is needed.
To avoid establishing an unreasonably expensive tariff for short
distance communications, this model needs billing based on accurate
link costs, because the tendency of network utilization is hard to
estimate.
Therefore, in this model, in addition to the sender billing from the
technical model, a database that can extract information about
permission and distance for billing from the destination IP address
is needed. In the resource reservation setup protocol, a procedure
that supports this process is also needed. In this case, it can be
provided by sender billing based on distance, bandwidth (FlowSpec)
and time, or information volume.
6. Architecture of the Resource Reservation Setup Protocol
Combinations of the billing side and the initiating side in a joining
request in the resource reservation setup protocol based on the above
studies are shown in Table 6.1.
Suzuki Informational [Page 11]
Table 6.1: Combinations of Billing and Initiating Sides of Joining Request.
+---------------+---------------+---------------+
| Application | Billing Side |Initiating Side|
+===============+===============+===============+
| Broadcast | Receiver | Receiver |
+---------------+---------------+---------------+
| Advertisement | Sender | Receiver |
+---------------+---------------+---------------+
| Conference | Sender |Sender,Receiver|
+---------------+---------------+---------------+
In addition to supporting all the above combinations of the billing
side and the initiating side in a joining request, the commercial
resource reservation service must satisfy the following requirements
for sender billing.
o A function is needed that restricts the region that a receiver is
permitted to join, or that decides whether to accept or refuse the
joining request based on the receiver IP address and/or on the
tariff to be billed.
o If the application is open to the public, an intermediate node that
decides whether to accept or refuse the joining request is needed
inside the multicast tree.
To achieve the combination of a sender billed and receiver initiated
joining request, the resource reservation setup protocol must support
a resource reservation procedure that is initiated by acceptance of a
joining request from a receiver. Therefore, the following sender
initiation basis protocol is a natural architecture for the
commercial resource reservation service.
Suzuki Informational [Page 12]
o The basis of the resource reservation setup protocol is sender
initiation. That is, as shown in Fig. 6.1, the sender explicitly
designates the receiver address, sends a resource reservation setup
message (SETUP), and constructs the multicast tree.
+---+
+--------| S |--------+
| +---+ |
+--------|--------/-|-\--------|--------+
| | / | \ | |
| | / | \ | |
| SETUP / SETUP /\ SETUP |
| | / | / \ | |
| | / | / \ | |
+--------|--/------ | ------\--|--------+
+-V-+ +---V---+ +-V-+
|R1 | | | |R2 |
+---+ |router | +---+
+------| |------+
| +-------+ |
+--------|--------/-|-\--------|--------+
| | / | \ | |
| | / | \ | |
| SETUP / SETUP /\ SETUP |
| | / | / \ | |
| | / | / \ | |
+--------|--/------ | ------\--|--------+
+-V-+ +-V-+ +-V-+
|R3 | |R4 | |R5 |
+---+ +---+ +---+
Fig. 6.1: Sender Initiation.
Suzuki Informational [Page 13]
o In the case of receiver initiation, as shown in Fig. 6.2, the
receiver explicitly sends the joining request message (JOIN), and
if the sender accepts it, the sender sends a resource reservation
setup message to the receiver.
+---+
| S |
+A--+
+-----------------/|-|\-----------------+
| / | | \ |
| / | | \ |
| JOIN| |SETUP |
| / | | / \ |
| / | |/ \ |
+-----------/------|-|------\-----------+
+---+ +----V--+ +---+
|R1 | | | |R2 |
+---+ |router | +---+
+-------> |
| +---- +-------+
+-------|-|-------/---\-----------------+
| | | / \ |
| | | / \ |
| JOIN| |SETUP /\ |
| | | / / \ |
| | | / / \ |
+-------|-|-/--------/------\-----------+
+--V+ +---+ +---+
|R3 | |R4 | |R5 |
+---+ +---+ +---+
Fig. 6.2: Receiver Initiation.
Suzuki Informational [Page 14]
o However, if the application is open to the public, as shown in Fig.
6.3, the intermediate node inside the multicast tree that decides
whether to accept or refuse the joining request, may send a
resource reservation setup message as a response to the joining
request message.
+---+
| S |
+---+
+-----------------/---\-----------------+
| / \ |
| / \ |
| / /\ |
| / / \ |
| / / \ |
+-----------/--------/------\-----------+
+---+ +-------+ +---+
|R1 | | | |R2 |
+---+ | node | +---+
+-------> |
| +---- +-------+
+-------|-|-------/---\-----------------+
| | | / \ |
| | | / \ |
| JOIN| |SETUP /\ |
| | | / / \ |
| | | / / \ |
+-------|-|-/--------/------\-----------+
+--V+ +---+ +---+
|R3 | |R4 | |R5 |
+---+ +---+ +---+
Fig. 6.3: Intermediate Node.
7. Conclusions
This document studied technical and application models of the
resource reservation service, and clarified the followings in terms
of an architecture for the resource reservation setup protocol.
o The basis of the resource reservation setup protocol is sender
initiation. That is, the sender explicitly designates the receiver
address, sends a resource reservation setup message and constructs
a multicast tree.
o In the case of receiver initiation, the receiver explicitly sends a
joining request message; if the sender accepts it, the sender sends
Suzuki Informational [Page 15]
a resource reservation setup message to the receiver.
o However, if the application is open to the public, an intermediate
node inside the multicast tree decides whether to accept or refuse
the joining request, and may send a resource reservation setup
message as a response to the joining request message.
Finally, if the billing policies of ISPs are fundamentally different
from each other in the commercial resource reservation service, it
will be difficult to achieve smooth interconnection. Therefore, the
author believes that ISPs need to conclude agreements or to clarify
recommendations concerning minimum common billing policies for the
resource reservation service, especially on the definition of
distance for billing purpose.
References
[1] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
August 1995.
[2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1
Functional Specification," RFC 2205, September 1997.
[3] S. Herzog, "Policy Control for RSVP: Architectural Overview,"
Internet Draft, November 1996, <draft-ietf-rsvp-policy-arch-
01.ps>.
Acknowledgments
This document is based on my discussions with many colleagues at
NTT. I would like to specially thank Hiroshi Ishikawa, Sadahiko
Kanou, Masaru Nishi, Satoshi Takamatsu, and Hideaki Arai of the
NTT Network Strategy Planning Dept., and also Hisao Uose of the
NTT Multimedia Networks Labs. for their valuable comments.
And I would also like to especially thank Joel Halpern and James
Watt of Newbridge Networks for their valuable comments and
suggestions.
Also this document is based on various discussions during NTT
Multimedia Joint Project with NACSIS. I would like to thank
Professor Shoichiro Asano of the National Center for Science
Information Systems for his invaluable advice in this area.
Suzuki Informational [Page 16]
Author's Address
Muneyoshi Suzuki
NTT Multimedia Networks Laboratories
3-9-11, Midori-cho
Musashino-shi, Tokyo 180, Japan
Phone: +81-422-59-2119
Fax: +81-422-59-3203
EMail: suzuki@nal.ecl.net
Full Copyright Statement
"Copyright (C) The Internet Society (1997). 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 implmentation 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
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."
Suzuki Informational [Page 17]
INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT