[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
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]