Architecture of the Resource Reservation Service for the Commercial Internet
Expired & archived
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|Send notices to||(None)|
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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, 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.
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)