home *** CD-ROM | disk | FTP | other *** search
Text File | 1996-11-26 | 45.3 KB | 1,232 lines |
-
-
- Network Working Group Muneyoshi Suzuki
- INTERNET DRAFT NTT
- Expires May 25, 1997 November 25, 1996
-
-
- Architecture of the Resource Reservation Service
- for the Commercial Internet
- <draft-suzuki-res-resv-svc-arch-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), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
- Abstract
-
- 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.
-
- This document also studies technical and application models for a
- commercial resource reservation service model, and clarifies an
- architecture for the resource reservation setup protocol. Last, it
- explains why ATM is an indispensable implementation technology for
- the commercial resource reservation service, and investigates an
- implementation method for a resource reservation setup protocol that
- is based on ATM.
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 1]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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 [2, 3] is
- increasingly important as a method for implementing measured rate
- billing.
-
- The resource reservation setup protocol [1] 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. And to investigate the implementation method of the
- resource reservation setup protocol in the commercial Internet
- environment is also 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.
-
- This document also studies technical and application models for a
- commercial resource reservation service model, and clarifies an
- architecture for the resource reservation setup protocol. Last, it
- explains why ATM is an indispensable implementation technology for
- the commercial resource reservation service, and investigates an
- implementation method for a resource reservation setup protocol that
- is based on ATM.
-
- 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.
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 2]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 1.1 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.
-
- Note: 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.
-
-
- 1.2 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.
-
- - 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.
-
-
-
- Suzuki Expires May, 1997 [Page 3]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 1.3 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.
-
- 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.
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 4]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 2. Billing in the Resource Reservation Service
-
- 2.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.
-
- 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.
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 5]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 2.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.
-
- 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.
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 6]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 3. Model of a Commercial Resource Reservation Service
-
- 3.1 Technical Model of the Resource Reservation Service
-
- This subsection looks at unreliable, unidirectional, and tree
- structured multicast architecture as a technical model for a resource
- reservation service. For the time being, the QoS to all receivers is
- assumed to be the same. The following section examines heterogeneous
- QoS and filter spec.
-
- +---+
- | S |
- +---+
- +-----------------/---\-----------------+
- | a / \ b |
- | / \ |
- | / ISP-A /\ |
- | / / \ |
- | / c / \ d |
- +-----------/--------/------\-----------+
- +---+ +-------+ +---+
- |R1 | |router | |R2 |
- +---+ +-------+ +---+
- +-----------------/---\-----------------+
- | e / \ f |
- | / \ |
- | / ISP-B /\ |
- | / / \ |
- | / g / \ h |
- +-----------/--------/------\-----------+
- +---+ +---+ +---+
- |R3 | |R4 | |R5 |
- +---+ +---+ +---+
-
- Fig. 3.1: Resource Reservation Service Model.
-
- As shown in Fig. 3.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. This subsection studies the receiver billing and
- the sender billing resource reservation service with this model.
-
-
-
- Suzuki Expires May, 1997 [Page 7]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 3.1.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 [1]. 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.
-
-
- 3.1.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.
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 8]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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 receiver 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.
-
-
- 3.2 Application Model for the Resource Reservation Service
-
- This subsection 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 subsection are also examined.
-
-
- 3.2.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.
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 9]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 3.2.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.
-
- 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.
-
-
-
- Suzuki Expires May, 1997 [Page 10]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 3.2.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.
-
- o The statistical tendency of network utilization in the conference
- depends on each conference style and the tendency is hard to
- estimate.
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 11]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 3.3 Architecture of the Resource Reservation Setup Protocol
-
- A combination of the billing side and the reserve initiating side in
- the resource reservation setup protocol based on the above studies is
- shown in Table 3.1.
-
- Table 3.1: Combination of Billing and Reserve Initiating Sides.
-
- +---------------+---------------+---------------+
- | Application | Billing Side |Initiating Side|
- +===============+===============+===============+
- | Broadcast | Receiver | Receiver |
- +---------------+---------------+---------------+
- | Advertisement | Sender | Receiver |
- +---------------+---------------+---------------+
- | Conference | Sender |Sender,Receiver|
- +---------------+---------------+---------------+
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 12]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- In addition to supporting all combinations of the billing side and
- the reserve initiating side shown above, 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.
-
- A resource reservation setup protocol that satisfies these
- requirements can be achieved with the following sender initiation
- architecture.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 13]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- o The basis of the resource reservation setup protocol is sender
- initiation. That is, as shown in Fig. 3.2, 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. 3.2: Sender Initiation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 14]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- o In the case of receiver initiation, as shown in Fig. 3.3, 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. 3.3: Receiver Initiation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 15]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- o However, if the application is open to the public, as shown in Fig.
- 3.4, 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. 3.4: Intermediate Node.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 16]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 4. Implementation Method of the Resource Reservation Setup Protocol
-
- 4.1 Datalink Media for the Commercial Resource Reservation Service
-
- The resource reservation setup protocol can designate the end-to-end
- resource to be reserved, but the datalink layer actually has
- responsibility for reservation and QoS control. Current datalink
- media that can control QoS are ATM, PPP over SDH/SONET with packet
- scheduler, serial line with packet scheduler, IEEE 802.9 isoEthernet,
- IEEE 802.12 100VG-Any LAN, and Ethernet/Token Ring with IEEE 802.1p.
- The I/O channel media are IEEE 1394 and Universal Serial Bus. Inside
- the user site, these media may be used.
-
- However, every node in the commercial resource reservation service
- backbone will have to handle between 1,000 and 10,000 IP flows
- initiated by users. To handle such a large volume of IP flow, the IP
- flow must be processed by hardware on a high-speed line interface
- such as SDH/SONET.
-
- The SDH/SONET hierarchy is defined as being a four times rate, 155M,
- 622M, 2.4G, and 10G bps. However, in an actual network, there is a
- strong possibility that a 622 Mbps line cannot handle all of the
- traffic, but there is no demand for a 2.4 Gbps line speed. In the
- commercial WAN environment, the intermediate-speed link, which is not
- supported by SDH/SONET, is provided by the ATM connection on the
- SDH/SONET. So, the use of ATM enables economical networks that can
- meet the traffic demand. After all, if, and only if, PPP over
- SDH/SONET is implemented by hardware, there is a possibility that
- speeds equivalent to ATM speeds can be attained over SDH/SONET, but
- economically this is entirely inappropriate for commercial network
- service.
-
- If SVC ATM is used as the datalink media of the resource reservation
- service, it may be possible to solve the problem that prevents
- billing based on distance without needing a database, that can
- extract information about distance for billing from the destination
- IP address. In this case, the E.164/NSAP, which are layered
- structure addresses and which contain information about provider and
- region, can be used.
-
- Therefore, ATM is an indispensable implementation technology for the
- commercial resource reservation service, and there is no room for any
- other selection. The remainder of this section examines an
- implementation method of the resource reservation setup protocol
- based on ATM.
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 17]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 4.2 Mapping of ATM VC and IP Flow
-
- An IP flow and an ATM VC must be mapped one-to-one, and must not
- aggregate multiple IP flows to single ATM VC, because ATM itself has
- the traffic control function. It is only wasteful to control both
- the ATM-layer and the IP-layer traffic, and has no effect other than
- to raise equipment cost and increase processing overhead.
-
- An IP flow also must not be divided among multiple ATM VCs.
- Synchronization between multiple ATM VCs to the same destination is
- not guaranteed. Therefore, synchronized information would be needed
- between ATM VCs, and this causes unnecessary overhead, decreases the
- reliability of the IP flow, and wastes network resources.
-
-
- 4.3 Dynamic QoS Changes
-
- The need to change QoS in an ATM system is a serious problem. Part
- of the ITU-T SCS2 signaling protocol, Q.2963.1 specifies a procedure
- to change the peak rate, but this is not sufficient as a procedure to
- change QoS. Also, signaling procedures in ATM Forum UNI 3.1/4.0 do
- not support QoS changes. ITU-T traffic control recommendation I.371
- and ATM Forum UNI 3.1/4.0 do not specify traffic behavior during QoS
- changing. The only possibility is ABT, which is defined in I.371 and
- supports QoS changes initiated by F5 OAM. Unfortunately, the current
- ABT supports point-to-point connection only.
-
- Therefore, current ATM standards cannot support QoS changes in
- practice. There is a possibility that QoS changes can be supported
- in the resource reservation service by releasing old ATM connections
- and establishing new ones, but this method causes the following
- problems.
-
- o Network overload may be caused by call processing.
-
- o Since call processing is closely related to ATM billing, the
- billing system complexity is increased.
-
- o New calls are not always successfully established.
-
- It is also feasible to establish new ATM connections and then release
- old ones, but this method causes the following problems.
-
- o The current ATM NIC for WS/PC does not support a large number of
- QoS VCs.
-
- o Although it is only temporary, old and new VCs exist
- simultaneously, which increases the complexity of the billing
-
-
-
- Suzuki Expires May, 1997 [Page 18]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- system.
-
- o New calls are not always successfully established. Especially,
- there is a possibility that only part of point-to-multipoint call
- will be reestablished successfully. This increases the complexity
- of exception processing.
-
- Therefore, QoS changes by signaling are impractical under current ATM
- standards, but should be supported after ATM standards specify it.
- ITU-T SG11 and SG13 and ATM Forum SIG SWG and TM SWG should specify a
- procedure for dynamic QoS changes and traffic behavior during QoS
- changing. Additional research on point-to-multipoint ABT is also
- needed.
-
-
- 4.4 Heterogeneous QoS
-
- Heterogeneous QoS, which not always the same at each receivers, is
- not supported by ATM point-to-multipoint connection. Originally, the
- concept of heterogeneous QoS was introduced to support hierarchical
- coded IP flow. But as described in [6], it should be supported by a
- presentation layer, and it is not responsible for the network and
- transport layers. In single-node operation, IP packet discarding
- based on contents is needed to support an IP flow that has
- heterogeneous QoS. But the network and transport layer cannot
- support such processing.
-
- When multiple receivers require different QoS, it does not make sense
- to establish a point-to-multipoint VC based on the largest QoS
- request.
-
- However a point-to-multipoint VC is established based on the maximum
- QoS, when a receiver that requests a larger QoS joins the multicast
- tree, or when the receiver that requested the largest QoS leaves the
- tree, and the QoS of the VC must be changed. However, current ATM
- standards cannot support such QoS changes.
-
- Also it does not have any advantage in terms of the tariff. The
- billing for a resource reservation service may be based on the QoS
- acquired in the ATM layer, which may be larger than the QoS requested
- in the IP layer. Therefore, to use the QoS from the ATM layer is
- obviously better for the IP flow.
-
- As explained above, current ATM standards cannot support
- heterogeneous QoS, and it does not offer any advantage in terms of
- tariff.
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 19]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 4.5 Filter Spec
-
- ATM does not support a function, that merges information from various
- VCs, such as filter spec. It should also be supported by a
- presentation layer, and is not responsible for the network and
- transport layers.
-
-
- 5. Conclusions
-
- This document 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
- 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.
-
- ATM is an indispensable implementation technology for the commercial
- resource reservation service, and the following were clarified in
- terms of an implementation method of the resource reservation setup
- protocol based on ATM.
-
- o An IP flow and an ATM VC must be mapped one-to-one.
-
- o In practice, current ATM standards cannot support dynamic QoS
- changes. Such changes should be supported after the ATM standard
- specifies it.
-
- o Current ATM standards cannot support heterogeneous QoS, which also
- does not have any advantage in terms of tariff. The hierarchical
- coded IP flow should be supported by the presentation layer.
-
- o Filter spec should be supported by the presentation layer.
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 20]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
-
- 6. Security Considerations
-
- Security considerations are not discussed in this document.
-
-
- References
-
- [1] S. Herzog, "Accounting and Access Control Policies for
- Resource Reservation Protocols," Internet Draft, June 1996,
- <draft-ietf-rsvp-policy-arch-00.ps>.
-
- [2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1
- Functional Specification," Internet Draft, October 1996, <draft-
- ietf-rsvp-spec-14.ps>.
-
- [3] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
- Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
- August 1995.
-
- [4] S. Berson and L. Berger, "IP Integrated Services with RSVP
- over ATM," Internet Draft, September 1996, <draft-ietf-issll-atm-
- support-01.ps>.
-
- [5] M. Borden and M. Garrett, "Interoperation of Controlled-Load
- and Guaranteed-Service with ATM," Internet Draft, September 1996,
- <draft-issll-intserv-atm-mapping-01.txt>.
-
- [6] K. Sebayashi and H. Uose, "ATM Multicast Communications Method
- with Receiver-initiated QoS Guarantee," Global Information
- Infrastructure Evolution, ISBN 90-5199-290-4, IOS Press, 1996.
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 21]
-
- INTERNET DRAFT draft-suzuki-res-resv-svc-arch-00.txt November, 1996
-
-
- 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.
-
- Also section 4 of this document is based on various discussions
- during NTT Multimedia Joint Project with NACSIS. I would like to
- thank Prof. Shoichiro Asano of National Center for Science
- Information Systems for his invaluable advice in this area.
-
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Suzuki Expires May, 1997 [Page 22]
-
-