home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-suzuki-res-resv-svc-arch-00.txt < prev    next >
Text File  |  1996-11-26  |  46KB  |  1,232 lines
  1.  
  2.  
  3. Network Working Group                                   Muneyoshi Suzuki
  4. INTERNET DRAFT                                                       NTT
  5. Expires May 25, 1997                                   November 25, 1996
  6.  
  7.  
  8.             Architecture of the Resource Reservation Service
  9.                       for the Commercial Internet
  10.                 <draft-suzuki-res-resv-svc-arch-00.txt>
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet-Drafts as reference
  22.    material or to cite them other than as "work in progress".
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  26.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. Abstract
  32.  
  33.    The purpose of this document is to clarify the architecture that
  34.    should be used for the resource reservation service for the
  35.    commercial Internet.
  36.  
  37.    First, this document explains the basis of the tariff for current
  38.    telecommunication and Internet services.  Then it clarifies problems
  39.    in the billing for Internet service, and describes how billing can be
  40.    improved by using the resource reservation setup protocol.
  41.  
  42.    This document also studies technical and application models for a
  43.    commercial resource reservation service model, and clarifies an
  44.    architecture for the resource reservation setup protocol.  Last, it
  45.    explains why ATM is an indispensable implementation technology for
  46.    the commercial resource reservation service, and investigates an
  47.    implementation method for a resource reservation setup protocol that
  48.    is based on ATM.
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Suzuki                     Expires May, 1997                    [Page 1]
  55.  
  56. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  57.  
  58.  
  59. 1. Introduction
  60.  
  61.    With the development of new multimedia applications, such as voice,
  62.    audio, picture, and video communication, the demands on the resource
  63.    reservation service are increasing, especially as Internet traffic
  64.    volume grows explosively due to these applications.  Therefore,
  65.    tariff systems for Internet service have tended to adopt measured
  66.    rate billing, and the resource reservation setup protocol [2, 3] is
  67.    increasingly important as a method for implementing measured rate
  68.    billing.
  69.  
  70.    The resource reservation setup protocol [1] must support billing if
  71.    it is to be applied to the commercial Internet, especially measured
  72.    rate billing between interconnected Internet Service Providers (ISPs)
  73.    is needed.  And to investigate the implementation method of the
  74.    resource reservation setup protocol in the commercial Internet
  75.    environment is also needed.
  76.  
  77.    The purpose of this document is to clarify the architecture that
  78.    should be used for the resource reservation service for the
  79.    commercial Internet.  First, this document explains the basis of the
  80.    tariff for current telecommunication and Internet services.  Then it
  81.    clarifies problems in the billing for Internet service, and describes
  82.    how billing can be improved by using the resource reservation setup
  83.    protocol.
  84.  
  85.    This document also studies technical and application models for a
  86.    commercial resource reservation service model, and clarifies an
  87.    architecture for the resource reservation setup protocol.  Last, it
  88.    explains why ATM is an indispensable implementation technology for
  89.    the commercial resource reservation service, and investigates an
  90.    implementation method for a resource reservation setup protocol that
  91.    is based on ATM.
  92.  
  93.    Incidentally, it is essential to examine billing based on business
  94.    administration issues, not technical ones.  For example, on a
  95.    telephone service, it technically makes sense to charge the caller
  96.    when the user being called is on another line.  This is because,
  97.    telephone switches were in operation when they notified the caller
  98.    that the number he called was busy.  However, such a billing policy
  99.    is contrary to the customs of business. Readers should note that the
  100.    billing problems and solutions discussed in this document are not
  101.    only based on the technical viewpoint.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Suzuki                     Expires May, 1997                    [Page 2]
  111.  
  112. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  113.  
  114.  
  115. 1.1 The Basis of the Tariff
  116.  
  117.    Basic elements that determine the network tariff are distance,
  118.    bandwidth, time, and information volume.  In many cases, the network
  119.    tariff reflects the link cost to some extent.
  120.  
  121.    Note: In this document, distance means the distance between the
  122.    regions where users call from and to, not the actual length of the
  123.    physical links that connect users.  In actual communication, a route
  124.    depends on network situations, so a charge based on the physical link
  125.    distance is inappropriate.
  126.  
  127.  
  128. 1.2 The Tariff in Telecommunication Services
  129.  
  130.    Classifications of the basic styles of tariff systems in
  131.    telecommunication services and some examples are shown below.  The
  132.    following classifications do not cover applied billing styles, for
  133.    example contents-based charging or premium charging such as the Dial
  134.    Q2 service of NTT, or the 900 telephone service.
  135.  
  136.    o Flat-rate billing
  137.  
  138.      - Leased line
  139.        In most cases, the tariff is based on distance and bandwidth.
  140.  
  141.      - PVC-based frame relay and ATM
  142.        In most cases, the tariff is based on distance and bandwidth.
  143.  
  144.    o Measured-rate billing
  145.  
  146.      - Telephone
  147.        In most cases, the tariff is based on distance and time.
  148.  
  149.      - Circuit switching
  150.        In most cases, the tariff is based on distance, bandwidth, and
  151.        time.
  152.  
  153.      - SVC-based frame relay and ATM
  154.        In most cases, the tariff is based on distance, bandwidth, and
  155.        time, or information volume.
  156.  
  157.      - X.25 packet switching
  158.        In most cases, the tariff is based on information volume.
  159.  
  160.    Furthermore, measured rate billing is classified into calling- or
  161.    called-party billing.  The basic charge style for telecommunication
  162.    service is calling-party billing.
  163.  
  164.  
  165.  
  166. Suzuki                     Expires May, 1997                    [Page 3]
  167.  
  168. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  169.  
  170.  
  171.    o Calling-party billing
  172.  
  173.      - Usual telephone service
  174.  
  175.    o Called-party billing
  176.  
  177.      - The Free Dial service of NTT and the 800 telephone service.
  178.  
  179.    Basically, telecommunication service is designed for connection-
  180.    oriented, point-to-point, and bidirectional communication.  In the
  181.    case of measured-rate billing, usually the calling or the called
  182.    party pays the bidirectional communication charge.  In the case of
  183.    called-party billing, a function that allows incoming calls to be
  184.    accepted or refused based on the calling-party address, or a function
  185.    that restricts the calling-party addresses that are permitted to use
  186.    called-party billing, is indispensable.  This is because, the
  187.    communication charge that a called party is willing to accept is
  188.    usually limited.
  189.  
  190.    The current tendency in telecommunication-service tariff systems is
  191.    to change from measured-rate billing, which reflects link costs
  192.    accurately, to flat-rate billing, which simplifies the charging
  193.    system, and service tends to be provided by flat-rate billing inside
  194.    a single provider.  The tariff for services between provider is
  195.    usually the sum of the individual providers charges.  Flat-rate
  196.    billing, like that within a single provider, is not currently
  197.    realistic for services that cross providers.
  198.  
  199.  
  200. 1.3 Tariffs for Internet Service
  201.  
  202.    Classifications of basic styles and examples of the tariff system for
  203.    Internet service are shown below.
  204.  
  205.    o Flat-rate billing
  206.  
  207.      - Internet access via leased line, PVC-based frame relay, or ATM
  208.        In most cases, the tariff is based on bandwidth.
  209.  
  210.    o Measured-rate billing
  211.  
  212.      - Dialup Internet access using a modem or N-ISDN
  213.        In most cases, the tariff is based on time.
  214.  
  215.      - Internet access via leased line, PVC-based frame relay, or ATM
  216.        Some ISPs have adopted information-volume-based tariff systems.
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Suzuki                     Expires May, 1997                    [Page 4]
  223.  
  224. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  225.  
  226.  
  227.    Note: Dialup access charges in this document do not include the basic
  228.    telephone fee.
  229.  
  230.    Until now, the tariff system for Internet access has mainly been
  231.    flat-rate billing, because measured-rate billing is technically
  232.    difficult to implement.  However, the development of new multimedia
  233.    applications, such as voice, audio, picture, and video communication,
  234.    has caused the traffic over the Internet to increase explosively.
  235.    The cost of using the public network service is lower than when using
  236.    a private network system, if users can share equipment and lines.
  237.    However, if the traffic from all its users is at a steady high rate,
  238.    the cost advantage of the public network service is lost.  Therefore,
  239.    Internet service tariff systems, although they use leased line
  240.    access, tend to adopt information-volume-based tariff systems.
  241.  
  242.  
  243. 2. Billing in the Resource Reservation Service
  244.  
  245. 2.1 Problems of Billing in Internet Service
  246.  
  247.    Basically, the tariff system for Internet service seems similar to
  248.    that for telecommunication service.  However, note that the tariff
  249.    system for Internet service based on the access method from the user
  250.    site to the ISP, is not based on the end-to-end communication method.
  251.    The Internet is a connection less and unreliable communication, and
  252.    some users are beginning to use it for multicast communication.  But,
  253.    the telecommunication is basically a connection-oriented, point-to-
  254.    point, and bidirectional form of communication, so telecommunication
  255.    and Intrenet communication are essentially different in some ways.
  256.  
  257.    Current Internet service does not allow billing based on end-to-end
  258.    user site distance.  This is because the structure of the IP address
  259.    is flat, rather than a layered structure that contains information
  260.    about the provider and region.  So information about distance for
  261.    billing purpose cannot be obtained from the IP address directly.
  262.  
  263.    Note: In this document, an address means an identifier, such as a
  264.    class A, B, or C IP address, that uniquely distinguishes an end
  265.    point.  It does not means a group identifier such as a class D
  266.    address.
  267.  
  268.    For Internet service, billing based on bandwidth can be provided, but
  269.    only for the line bandwidth between the user site and the ISP; it is
  270.    not based on the end-to-end user or application bandwidth, such as
  271.    the bandwidth in telecommunication services.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Suzuki                     Expires May, 1997                    [Page 5]
  279.  
  280. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  281.  
  282.  
  283.    Current Internet service, except for the dialup access, does not
  284.    allow billing based on time because the IP is a connection less
  285.    communication, and timing information about the beginning and ending
  286.    of billing is too difficult to obtain.
  287.  
  288.    Some current ISPs have adopted information-volume-based tariff
  289.    systems.  However, this billing is based on the information volume of
  290.    IP packets that are sent to or received from the user site and the
  291.    ISP.  Again, because the IP is a connection less and unreliable
  292.    communication, it is too difficult to provide billing based on the
  293.    information volume of IP packets that are actually used between end-
  294.    to-end users or applications.
  295.  
  296.    It is not impossible to provide both user billing, and application
  297.    provider billing over the Internet when particular services are used.
  298.    These forms of billing are equivalent to calling- and called-party
  299.    billing in telecommunication service.  However, obtaining the timing
  300.    information about the beginning and ending of application usage at
  301.    the IP layer is too difficult because the IP is a connection less
  302.    communication.  To have billing based on usage time, the service
  303.    application responsible for the bill must identify the user and
  304.    monitor the usage.  Also a billing process, where part of the billing
  305.    is transferred from the user to the service provider, must be
  306.    implemented.  As a result, the billing system complexity is
  307.    increased.
  308.  
  309.  
  310. 2.2 Improved Billing Using the Resource Reservation Setup Protocol
  311.  
  312.    As explained above, billing for current commercial Internet service
  313.    has many problems, but a resource reservation setup protocol may
  314.    solve these problems.
  315.  
  316.    For example, the resource reservation setup protocol ensures the
  317.    availability of end-to-end network resources, so billing based on
  318.    bandwidth (FlowSpec) between user sites may be possible.  Also, the
  319.    resource reservation setup protocol explicitly shows the resource
  320.    acquire and release timings, so billing based on time may be
  321.    feasible.
  322.  
  323.    The resource reservation setup protocol also guarantees QoS based on
  324.    the FlowSpec, so billing based on the information volume that is
  325.    actually used between end-to-end users or applications may also be
  326.    feasible.  Furthermore, there is a possibility that the billing for
  327.    each IP flow can be distributed to ether the sender or the receiver.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Suzuki                     Expires May, 1997                    [Page 6]
  335.  
  336. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  337.  
  338.  
  339.    However, the resource reservation setup protocol cannot solve the
  340.    problem of how billing can be based on distance because the flat
  341.    structure of the IP address does not change and it is still
  342.    impossible to obtain information about distance for billing from the
  343.    IP address directly even when the resource reservation setup protocol
  344.    is used.
  345.  
  346.  
  347. 3. Model of a Commercial Resource Reservation Service
  348.  
  349. 3.1 Technical Model of the Resource Reservation Service
  350.  
  351.    This subsection looks at unreliable, unidirectional, and tree
  352.    structured multicast architecture as a technical model for a resource
  353.    reservation service.  For the time being, the QoS to all receivers is
  354.    assumed to be the same. The following section examines heterogeneous
  355.    QoS and filter spec.
  356.  
  357.                                   +---+
  358.                                   | S |
  359.                                   +---+
  360.                 +-----------------/---\-----------------+
  361.                 |              a /     \ b              |
  362.                 |               /       \               |
  363.                 |              / ISP-A  /\              |
  364.                 |             /        /  \             |
  365.                 |            /      c /    \ d          |
  366.                 +-----------/--------/------\-----------+
  367.                        +---+    +-------+    +---+
  368.                        |R1 |    |router |    |R2 |
  369.                        +---+    +-------+    +---+
  370.                 +-----------------/---\-----------------+
  371.                 |              e /     \ f              |
  372.                 |               /       \               |
  373.                 |              / ISP-B  /\              |
  374.                 |             /        /  \             |
  375.                 |            /      g /    \ h          |
  376.                 +-----------/--------/------\-----------+
  377.                        +---+      +---+      +---+
  378.                        |R3 |      |R4 |      |R5 |
  379.                        +---+      +---+      +---+
  380.  
  381.               Fig. 3.1: Resource Reservation Service Model.
  382.  
  383.    As shown in Fig. 3.1, ISP-A and ISP-B are interconnected, a sender S
  384.    and receivers R1 and R2 belong to ISP-A, and receivers R3, R4, and R5
  385.    belong to ISP-B.  This subsection studies the receiver billing and
  386.    the sender billing resource reservation service with this model.
  387.  
  388.  
  389.  
  390. Suzuki                     Expires May, 1997                    [Page 7]
  391.  
  392. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  393.  
  394.  
  395. 3.1.1 Receiver billing
  396.  
  397.    When the resource reservation service is provided under receiver
  398.    billing, the problem is how to bill for the shared links, such as b,
  399.    c, and f.  The shared link cost must be distributed and billed to
  400.    receivers based on some rule.
  401.  
  402.    One solution inside a single ISP is to adopt a tariff system that
  403.    does not depend on how the links shared between receivers.  Billing
  404.    that is based on the cost of the links that make up the multicast
  405.    tree is equivalent to billing based on distance.  Therefore, billing
  406.    that does not depend on the link sharing approach is equivalent to
  407.    billing that is not based on distance.  This means the billing can be
  408.    based on bandwidth (FlowSpec), time, and information volume.
  409.  
  410.    For example, if an interconnected destination ISP is regarded as a
  411.    receiver, ISP-A bills to R1, R2 and ISP-B, and ISP-B bills to R3, R4,
  412.    and R5 [1].  The billing from ISP-A to ISP-B is distributed based on
  413.    some rule, and is added to the base charge in ISP-B.  If a large
  414.    number of users join the multicast and the statistical tendency of
  415.    network utilization is known, it is possible to provide this type of
  416.    tariff system, although it does not accurately reflect communication
  417.    costs.
  418.  
  419.    Another solution is to distribute the shared link cost among the
  420.    receivers that share the link.  For example, the cost of link b would
  421.    be shared by R2, R3, R4 and R5.  This method does reflect accurate
  422.    communication costs.  However, in practice it is difficult to
  423.    implement the billing system since the complexity of computing the
  424.    cost of the shared link, located near a sender like b, is increased
  425.    because the receiver can dynamically join and leave the multicast
  426.    tree.
  427.  
  428.    Therefore, in the case of receiver billing, if many users join the
  429.    multicast and the statistical tendency of network utilization is
  430.    known, billing based on bandwidth (FlowSpec), time, and information
  431.    volume can be provided.
  432.  
  433.  
  434. 3.1.2 Sender billing
  435.  
  436.    When the resource reservation service is provided under the sender
  437.    billing, the problem due to the shared link is avoided, because there
  438.    is no need to distribute the shared link cost.  In the above model,
  439.    the sender would be billed for the link costs from a to h.
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. Suzuki                     Expires May, 1997                    [Page 8]
  447.  
  448. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  449.  
  450.  
  451.    Therefore, with sender billing, billing based on accurate link costs
  452.    can be provided.  Billing based on the link cost is equivalent to
  453.    billing based on distance.  However, information about distance for
  454.    billing cannot be obtained from the IP address directly.  Therefore,
  455.    a database that can extract information about distance from the
  456.    destination IP address is needed to enable billing based on the link
  457.    cost.
  458.  
  459.    This is also true for receiver billing: if a number of users join the
  460.    multicast and the statistical tendency of network utilization is
  461.    known, it is possible to provide billing based on bandwidth
  462.    (FlowSpec), time, and information volume.  That is, the sender pays
  463.    for the billing to R1, R2, and ISP-B in ISP-A, and to R3, R4, and R5
  464.    in ISP-B.
  465.  
  466.    Therefore, with sender billing, if a database is implemented that can
  467.    extract information about distance for billing from the destination
  468.    IP address, it will be possible to provide billing based on distance,
  469.    bandwidth (FlowSpec), time, and information volume.  And if many
  470.    users join the multicast and the statistical tendency of network
  471.    utilization is known, it will also be possible to provide billing
  472.    based on bandwidth (FlowSpec), time, and information volume.
  473.  
  474.  
  475. 3.2 Application Model for the Resource Reservation Service
  476.  
  477.    This subsection examines the following multimedia applications to
  478.    develop an application model for the resource reservation service.
  479.  
  480.    o Broadcast-type application model
  481.  
  482.    o Advertisement-type application model
  483.  
  484.    o Conference-type application model
  485.  
  486.    Methods of implementing the application model using the technical
  487.    model described in the previous subsection are also examined.
  488.  
  489.  
  490. 3.2.1 Broadcast-type application model
  491.  
  492.    We assume that the broadcast-type application model has the following
  493.    features.
  494.  
  495.    o The application provider broadcasts to receivers using the
  496.      multicast, and, in practice, the application is open to the public.
  497.  
  498.  
  499.  
  500.  
  501.  
  502. Suzuki                     Expires May, 1997                    [Page 9]
  503.  
  504. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  505.  
  506.  
  507.    o Many receivers subscribe to the broadcast, and the statistical
  508.      tendency of network utilization is known.
  509.  
  510.    o Joining the multicast tree is initiated from the receiver.
  511.  
  512.    o The receiver pays the full amount billed.
  513.  
  514.    o The billing is based on information volume or bandwidth (FlowSpec)
  515.      and time, and not on distance.
  516.  
  517.    Features of this model correspond to receiver billing in the
  518.    technical model, so it is appropriate for this model to be supported
  519.    by it.  Therefore, receiver billing based on bandwidth (FlowSpec) and
  520.    time, or information volume can be provided.
  521.  
  522.  
  523. 3.2.2 Advertisement-type application model
  524.  
  525.    We assume that the advertisement-type application model has the
  526.    following features.
  527.  
  528.    o The application provider advertises to receivers using the
  529.      multicast, and, in practice, the application is open to the public.
  530.  
  531.    o Many receivers subscribe to the advertisement, and the statistical
  532.      tendency of network utilization is known.
  533.  
  534.    o Joining the multicast tree is initiated from the receiver side.
  535.  
  536.    o The application provider pays the full amount billed.
  537.  
  538.    o A function that restricts the region in which the receiver is
  539.      permitted to join, or a function that decides whether to accept or
  540.      refuse the joining request based on the IP address of the receiver
  541.      or based on the tariff to be billed, is indispensable.  This is
  542.      because the communication charge that is acceptable to an
  543.      application provider is usually limited.
  544.  
  545.    Features of this model roughly correspond to sender billing in the
  546.    technical model, so it is appropriate for this model to be supported
  547.    by it.  But this model needs a function that restricts the region in
  548.    which the receiver is permitted to join, or a function that decides
  549.    whether to accept or refuse the joining request based on the IP
  550.    address of the receiver or based on the tariff to be billed.
  551.  
  552.    If the region that the receiver is permitted to join is simply
  553.    restricted by the ISP boundary, the model can be implemented by
  554.    restricting the IP flow forwarding between ISPs.
  555.  
  556.  
  557.  
  558. Suzuki                     Expires May, 1997                   [Page 10]
  559.  
  560. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  561.  
  562.  
  563.    But if the decision to accept or refuse the joining request is based
  564.    on the IP address of the receiver or based on the tariff to be
  565.    billed, a database that can extract information about permission or
  566.    distance for billing from the destination IP address is needed.  In
  567.    the resource reservation setup protocol, a procedure that supports
  568.    this kind of processing is also needed.
  569.  
  570.    However, if this procedure is processed only by the sender, and the
  571.    number of receivers significantly increases, saturation of the sender
  572.    protocol processing may occur.  Therefore, an intermediate node is
  573.    needed inside the multicast tree, and this intermediate node will
  574.    decide whether to accept or refuse the joining request.
  575.  
  576.    Therefore, in the advertisement-type application model, if the region
  577.    that the receiver is permitted to join is simply restricted by the
  578.    ISP boundary, it is appropriate for this model to be supported by the
  579.    sender billing in the technical model.  Thus, sender billing based on
  580.    bandwidth (FlowSpec) and time, or information volume, can be
  581.    provided.
  582.  
  583.    If the decision to accept or refuse the joining request is based on
  584.    the IP address of the receiver or based on the tariff to be billed,
  585.    in addition to the sender billing in the technical model, a database,
  586.    that can extract information about permission or distance for billing
  587.    from the destination IP address is needed.  In the resource
  588.    reservation setup protocol, a procedure that supports this process is
  589.    also needed.  In this case, it can be provided by sender billing
  590.    based on distance, bandwidth (FlowSpec) and time, or information
  591.    volume.
  592.  
  593.  
  594. 3.2.3 Conference-type application model.
  595.  
  596.    We assume that the conference-type application model has the
  597.    following features.
  598.  
  599.    o The conference is held by a small number of participants.
  600.  
  601.    o The statistical tendency of network utilization in the conference
  602.      depends on each conference style and the tendency is hard to
  603.      estimate.
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614. Suzuki                     Expires May, 1997                   [Page 11]
  615.  
  616. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  617.  
  618.  
  619.    o Joining the conference is initiated by each participant. That is
  620.  
  621.      - Joining the multicast tree from an existing participant or
  622.        receiving information from the conference server is initiated by
  623.        the receiver.
  624.  
  625.      - Construction of the multicast tree for existing participants or
  626.        information sent to the conference server is initiated by the
  627.        sender.
  628.  
  629.    o Management of conference participants is indispensable.  A function
  630.      that can decide to accept or refuse a participation request based
  631.      on the IP address of the potential participant, or a similar
  632.      function is needed.
  633.  
  634.    To avoid establishing an unreasonably expensive tariff for short
  635.    distance communications, this model needs billing based on accurate
  636.    link costs, because the tendency of network utilization is hard to
  637.    estimate.
  638.  
  639.    Therefore, in this model, in addition to the sender billing from the
  640.    technical model, a database that can extract information about
  641.    permission and distance for billing from the destination IP address
  642.    is needed.  In the resource reservation setup protocol, a procedure
  643.    that supports this process is also needed.  In this case, it can be
  644.    provided by sender billing based on distance, bandwidth (FlowSpec)
  645.    and time, or information volume.
  646.  
  647.  
  648. 3.3 Architecture of the Resource Reservation Setup Protocol
  649.  
  650.    A combination of the billing side and the reserve initiating side in
  651.    the resource reservation setup protocol based on the above studies is
  652.    shown in Table 3.1.
  653.  
  654.       Table 3.1: Combination of Billing and Reserve Initiating Sides.
  655.  
  656.            +---------------+---------------+---------------+
  657.            |  Application  | Billing Side  |Initiating Side|
  658.            +===============+===============+===============+
  659.            |   Broadcast   |   Receiver    |   Receiver    |
  660.            +---------------+---------------+---------------+
  661.            | Advertisement |    Sender     |   Receiver    |
  662.            +---------------+---------------+---------------+
  663.            |   Conference  |    Sender     |Sender,Receiver|
  664.            +---------------+---------------+---------------+
  665.  
  666.  
  667.  
  668.  
  669.  
  670. Suzuki                     Expires May, 1997                   [Page 12]
  671.  
  672. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  673.  
  674.  
  675.    In addition to supporting all combinations of the billing side and
  676.    the reserve initiating side shown above, the commercial resource
  677.    reservation service must satisfy the following requirements for
  678.    sender billing.
  679.  
  680.    o A function is needed that restricts the region that a receiver is
  681.      permitted to join, or that decides whether to accept or refuse the
  682.      joining request based on the receiver IP address and/or on the
  683.      tariff to be billed.
  684.  
  685.    o If the application is open to the public, an intermediate node that
  686.      decides whether to accept or refuse the joining request is needed
  687.      inside the multicast tree.
  688.  
  689.    A resource reservation setup protocol that satisfies these
  690.    requirements can be achieved with the following sender initiation
  691.    architecture.
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726. Suzuki                     Expires May, 1997                   [Page 13]
  727.  
  728. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  729.  
  730.  
  731.    o The basis of the resource reservation setup protocol is sender
  732.      initiation.  That is, as shown in Fig. 3.2, the sender explicitly
  733.      designates the receiver address, sends a resource reservation setup
  734.      message (SETUP), and constructs the multicast tree.
  735.  
  736.                                   +---+
  737.                          +--------| S |--------+
  738.                          |        +---+        |
  739.                 +--------|--------/-|-\--------|--------+
  740.                 |        |       /  |  \       |        |
  741.                 |        |      /   |   \      |        |
  742.                 |      SETUP   /  SETUP /\   SETUP      |
  743.                 |        |    /     |  /  \    |        |
  744.                 |        |   /      | /    \   |        |
  745.                 +--------|--/------ | ------\--|--------+
  746.                        +-V-+    +---V---+    +-V-+
  747.                        |R1 |    |       |    |R2 |
  748.                        +---+    |router |    +---+
  749.                          +------|       |------+
  750.                          |      +-------+      |
  751.                 +--------|--------/-|-\--------|--------+
  752.                 |        |       /  |  \       |        |
  753.                 |        |      /   |   \      |        |
  754.                 |      SETUP   /  SETUP /\   SETUP      |
  755.                 |        |    /     |  /  \    |        |
  756.                 |        |   /      | /    \   |        |
  757.                 +--------|--/------ | ------\--|--------+
  758.                        +-V-+      +-V-+      +-V-+
  759.                        |R3 |      |R4 |      |R5 |
  760.                        +---+      +---+      +---+
  761.  
  762.                        Fig. 3.2: Sender Initiation.
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782. Suzuki                     Expires May, 1997                   [Page 14]
  783.  
  784. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  785.  
  786.  
  787.    o In the case of receiver initiation, as shown in Fig. 3.3, the
  788.      receiver explicitly sends the joining request message (JOIN), and
  789.      if the sender accepts it, the sender sends a resource reservation
  790.      setup message to the receiver.
  791.  
  792.                                   +---+
  793.                                   | S |
  794.                                   +A--+
  795.                 +-----------------/|-|\-----------------+
  796.                 |                / | | \                |
  797.                 |               /  | |  \               |
  798.                 |              JOIN| |SETUP             |
  799.                 |             /    | | /  \             |
  800.                 |            /     | |/    \            |
  801.                 +-----------/------|-|------\-----------+
  802.                        +---+    +----V--+    +---+
  803.                        |R1 |    |       |    |R2 |
  804.                        +---+    |router |    +---+
  805.                         +------->       |
  806.                         | +---- +-------+
  807.                 +-------|-|-------/---\-----------------+
  808.                 |       | |      /     \                |
  809.                 |       | |     /       \               |
  810.                 |   JOIN| |SETUP        /\              |
  811.                 |       | |   /        /  \             |
  812.                 |       | |  /        /    \            |
  813.                 +-------|-|-/--------/------\-----------+
  814.                        +--V+      +---+      +---+
  815.                        |R3 |      |R4 |      |R5 |
  816.                        +---+      +---+      +---+
  817.  
  818.                       Fig. 3.3: Receiver Initiation.
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838. Suzuki                     Expires May, 1997                   [Page 15]
  839.  
  840. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  841.  
  842.  
  843.    o However, if the application is open to the public, as shown in Fig.
  844.      3.4, the intermediate node inside the multicast tree that decides
  845.      whether to accept or refuse the joining request, may send a
  846.      resource reservation setup message as a response to the joining
  847.      request message.
  848.  
  849.                                   +---+
  850.                                   | S |
  851.                                   +---+
  852.                 +-----------------/---\-----------------+
  853.                 |                /     \                |
  854.                 |               /       \               |
  855.                 |              /        /\              |
  856.                 |             /        /  \             |
  857.                 |            /        /    \            |
  858.                 +-----------/--------/------\-----------+
  859.                        +---+    +-------+    +---+
  860.                        |R1 |    |       |    |R2 |
  861.                        +---+    | node  |    +---+
  862.                         +------->       |
  863.                         | +---- +-------+
  864.                 +-------|-|-------/---\-----------------+
  865.                 |       | |      /     \                |
  866.                 |       | |     /       \               |
  867.                 |   JOIN| |SETUP        /\              |
  868.                 |       | |   /        /  \             |
  869.                 |       | |  /        /    \            |
  870.                 +-------|-|-/--------/------\-----------+
  871.                        +--V+      +---+      +---+
  872.                        |R3 |      |R4 |      |R5 |
  873.                        +---+      +---+      +---+
  874.  
  875.                        Fig. 3.4: Intermediate Node.
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894. Suzuki                     Expires May, 1997                   [Page 16]
  895.  
  896. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  897.  
  898.  
  899. 4. Implementation Method of the Resource Reservation Setup Protocol
  900.  
  901. 4.1 Datalink Media for the Commercial Resource Reservation Service
  902.  
  903.    The resource reservation setup protocol can designate the end-to-end
  904.    resource to be reserved, but the datalink layer actually has
  905.    responsibility for reservation and QoS control.  Current datalink
  906.    media that can control QoS are ATM, PPP over SDH/SONET with packet
  907.    scheduler, serial line with packet scheduler, IEEE 802.9 isoEthernet,
  908.    IEEE 802.12 100VG-Any LAN, and Ethernet/Token Ring with IEEE 802.1p.
  909.    The I/O channel media are IEEE 1394 and Universal Serial Bus.  Inside
  910.    the user site, these media may be used.
  911.  
  912.    However, every node in the commercial resource reservation service
  913.    backbone will have to handle between 1,000 and 10,000 IP flows
  914.    initiated by users.  To handle such a large volume of IP flow, the IP
  915.    flow must be processed by hardware on a high-speed line interface
  916.    such as SDH/SONET.
  917.  
  918.    The SDH/SONET hierarchy is defined as being a four times rate, 155M,
  919.    622M, 2.4G, and 10G bps.  However, in an actual network, there is a
  920.    strong possibility that a 622 Mbps line cannot handle all of the
  921.    traffic, but there is no demand for a 2.4 Gbps line speed.  In the
  922.    commercial WAN environment, the intermediate-speed link, which is not
  923.    supported by SDH/SONET, is provided by the ATM connection on the
  924.    SDH/SONET.  So, the use of ATM enables economical networks that can
  925.    meet the traffic demand.  After all, if, and only if, PPP over
  926.    SDH/SONET is implemented by hardware, there is a possibility that
  927.    speeds equivalent to ATM speeds can be attained over SDH/SONET, but
  928.    economically this is entirely inappropriate for commercial network
  929.    service.
  930.  
  931.    If SVC ATM is used as the datalink media of the resource reservation
  932.    service, it may be possible to solve the problem that prevents
  933.    billing based on distance without needing a database, that can
  934.    extract information about distance for billing from the destination
  935.    IP address.  In this case, the E.164/NSAP, which are layered
  936.    structure addresses and which contain information about provider and
  937.    region, can be used.
  938.  
  939.    Therefore, ATM is an indispensable implementation technology for the
  940.    commercial resource reservation service, and there is no room for any
  941.    other selection.  The remainder of this section examines an
  942.    implementation method of the resource reservation setup protocol
  943.    based on ATM.
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950. Suzuki                     Expires May, 1997                   [Page 17]
  951.  
  952. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  953.  
  954.  
  955. 4.2 Mapping of ATM VC and IP Flow
  956.  
  957.    An IP flow and an ATM VC must be mapped one-to-one, and must not
  958.    aggregate multiple IP flows to single ATM VC, because ATM itself has
  959.    the traffic control function.  It is only wasteful to control both
  960.    the ATM-layer and the IP-layer traffic, and has no effect other than
  961.    to raise equipment cost and increase processing overhead.
  962.  
  963.    An IP flow also must not be divided among multiple ATM VCs.
  964.    Synchronization between multiple ATM VCs to the same destination is
  965.    not guaranteed.  Therefore, synchronized information would be needed
  966.    between ATM VCs, and this causes unnecessary overhead, decreases the
  967.    reliability of the IP flow, and wastes network resources.
  968.  
  969.  
  970. 4.3 Dynamic QoS Changes
  971.  
  972.    The need to change QoS in an ATM system is a serious problem.  Part
  973.    of the ITU-T SCS2 signaling protocol, Q.2963.1 specifies a procedure
  974.    to change the peak rate, but this is not sufficient as a procedure to
  975.    change QoS.  Also, signaling procedures in ATM Forum UNI 3.1/4.0 do
  976.    not support QoS changes.  ITU-T traffic control recommendation I.371
  977.    and ATM Forum UNI 3.1/4.0 do not specify traffic behavior during QoS
  978.    changing.  The only possibility is ABT, which is defined in I.371 and
  979.    supports QoS changes initiated by F5 OAM.  Unfortunately, the current
  980.    ABT supports point-to-point connection only.
  981.  
  982.    Therefore, current ATM standards cannot support QoS changes in
  983.    practice.  There is a possibility that QoS changes can be supported
  984.    in the resource reservation service by releasing old ATM connections
  985.    and establishing new ones, but this method causes the following
  986.    problems.
  987.  
  988.    o Network overload may be caused by call processing.
  989.  
  990.    o Since call processing is closely related to ATM billing, the
  991.      billing system complexity is increased.
  992.  
  993.    o New calls are not always successfully established.
  994.  
  995.    It is also feasible to establish new ATM connections and then release
  996.    old ones, but this method causes the following problems.
  997.  
  998.    o The current ATM NIC for WS/PC does not support a large number of
  999.      QoS VCs.
  1000.  
  1001.    o Although it is only temporary, old and new VCs exist
  1002.      simultaneously, which increases the complexity of the billing
  1003.  
  1004.  
  1005.  
  1006. Suzuki                     Expires May, 1997                   [Page 18]
  1007.  
  1008. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  1009.  
  1010.  
  1011.      system.
  1012.  
  1013.    o New calls are not always successfully established.  Especially,
  1014.      there is a possibility that only part of point-to-multipoint call
  1015.      will be reestablished successfully.  This increases the complexity
  1016.      of exception processing.
  1017.  
  1018.    Therefore, QoS changes by signaling are impractical under current ATM
  1019.    standards, but should be supported after ATM standards specify it.
  1020.    ITU-T SG11 and SG13 and ATM Forum SIG SWG and TM SWG should specify a
  1021.    procedure for dynamic QoS changes and traffic behavior during QoS
  1022.    changing.  Additional research on point-to-multipoint ABT is also
  1023.    needed.
  1024.  
  1025.  
  1026. 4.4 Heterogeneous QoS
  1027.  
  1028.    Heterogeneous QoS, which not always the same at each receivers, is
  1029.    not supported by ATM point-to-multipoint connection.  Originally, the
  1030.    concept of heterogeneous QoS was introduced to support hierarchical
  1031.    coded IP flow.  But as described in [6], it should be supported by a
  1032.    presentation layer, and it is not responsible for the network and
  1033.    transport layers.  In single-node operation, IP packet discarding
  1034.    based on contents is needed to support an IP flow that has
  1035.    heterogeneous QoS.  But the network and transport layer cannot
  1036.    support such processing.
  1037.  
  1038.    When multiple receivers require different QoS, it does not make sense
  1039.    to establish a point-to-multipoint VC based on the largest QoS
  1040.    request.
  1041.  
  1042.    However a point-to-multipoint VC is established based on the maximum
  1043.    QoS, when a receiver that requests a larger QoS joins the multicast
  1044.    tree, or when the receiver that requested the largest QoS leaves the
  1045.    tree, and the QoS of the VC must be changed.  However, current ATM
  1046.    standards cannot support such QoS changes.
  1047.  
  1048.    Also it does not have any advantage in terms of the tariff.  The
  1049.    billing for a resource reservation service may be based on the QoS
  1050.    acquired in the ATM layer, which may be larger than the QoS requested
  1051.    in the IP layer.  Therefore, to use the QoS from the ATM layer is
  1052.    obviously better for the IP flow.
  1053.  
  1054.    As explained above, current ATM standards cannot support
  1055.    heterogeneous QoS, and it does not offer any advantage in terms of
  1056.    tariff.
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062. Suzuki                     Expires May, 1997                   [Page 19]
  1063.  
  1064. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  1065.  
  1066.  
  1067. 4.5 Filter Spec
  1068.  
  1069.    ATM does not support a function, that merges information from various
  1070.    VCs, such as filter spec.  It should also be supported by a
  1071.    presentation layer, and is not responsible for the network and
  1072.    transport layers.
  1073.  
  1074.  
  1075. 5. Conclusions
  1076.  
  1077.    This document clarified the followings in terms of an architecture
  1078.    for the resource reservation setup protocol.
  1079.  
  1080.    o The basis of the resource reservation setup protocol is sender
  1081.      initiation.  That is, the sender explicitly designates the receiver
  1082.      address, sends a resource reservation setup message and constructs
  1083.      a multicast tree.
  1084.  
  1085.    o In the case of receiver initiation, the receiver explicitly sends a
  1086.      joining request message; if the sender accepts it, the sender sends
  1087.      a resource reservation setup message to the receiver.
  1088.  
  1089.    o However, if the application is open to the public, an intermediate
  1090.      node inside the multicast tree decides whether to accept or refuse
  1091.      the joining request, and may send a resource reservation setup
  1092.      message as a response to the joining request message.
  1093.  
  1094.    ATM is an indispensable implementation technology for the commercial
  1095.    resource reservation service, and the following were clarified in
  1096.    terms of an implementation method of the resource reservation setup
  1097.    protocol based on ATM.
  1098.  
  1099.    o An IP flow and an ATM VC must be mapped one-to-one.
  1100.  
  1101.    o In practice, current ATM standards cannot support dynamic QoS
  1102.      changes.  Such changes should be supported after the ATM standard
  1103.      specifies it.
  1104.  
  1105.    o Current ATM standards cannot support heterogeneous QoS, which also
  1106.      does not have any advantage in terms of tariff.  The hierarchical
  1107.      coded IP flow should be supported by the presentation layer.
  1108.  
  1109.    o Filter spec should be supported by the presentation layer.
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118. Suzuki                     Expires May, 1997                   [Page 20]
  1119.  
  1120. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  1121.  
  1122.  
  1123.    Finally, if the billing policies of ISPs are fundamentally different
  1124.    from each other in the commercial resource reservation service, it
  1125.    will be difficult to achieve smooth interconnection.  Therefore, the
  1126.    author believes that ISPs need to conclude agreements or to clarify
  1127.    recommendations concerning minimum common billing policies for the
  1128.    resource reservation service, especially on the definition of
  1129.    distance for billing purpose.
  1130.  
  1131.  
  1132. 6. Security Considerations
  1133.  
  1134.    Security considerations are not discussed in this document.
  1135.  
  1136.  
  1137. References
  1138.  
  1139.       [1] S. Herzog, "Accounting and Access Control Policies for
  1140.       Resource Reservation Protocols," Internet Draft, June 1996,
  1141.       <draft-ietf-rsvp-policy-arch-00.ps>.
  1142.  
  1143.       [2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1
  1144.       Functional Specification," Internet Draft, October 1996, <draft-
  1145.       ietf-rsvp-spec-14.ps>.
  1146.  
  1147.       [3] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol
  1148.       Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819,
  1149.       August 1995.
  1150.  
  1151.       [4] S. Berson and L. Berger, "IP Integrated Services with RSVP
  1152.       over ATM," Internet Draft, September 1996, <draft-ietf-issll-atm-
  1153.       support-01.ps>.
  1154.  
  1155.       [5] M. Borden and M. Garrett, "Interoperation of Controlled-Load
  1156.       and Guaranteed-Service with ATM," Internet Draft, September 1996,
  1157.       <draft-issll-intserv-atm-mapping-01.txt>.
  1158.  
  1159.       [6] K. Sebayashi and H. Uose, "ATM Multicast Communications Method
  1160.       with Receiver-initiated QoS Guarantee," Global Information
  1161.       Infrastructure Evolution, ISBN 90-5199-290-4, IOS Press, 1996.
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174. Suzuki                     Expires May, 1997                   [Page 21]
  1175.  
  1176. INTERNET DRAFT   draft-suzuki-res-resv-svc-arch-00.txt    November, 1996
  1177.  
  1178.  
  1179. Acknowledgments
  1180.  
  1181.       This document is based on my discussions with many colleagues at
  1182.       NTT.  I would like to specially thank Hiroshi Ishikawa, Sadahiko
  1183.       Kanou, Masaru Nishi, Satoshi Takamatsu, and Hideaki Arai of the
  1184.       NTT Network Strategy Planning Dept., and also Hisao Uose of the
  1185.       NTT Multimedia Networks Labs. for their valuable comments.
  1186.  
  1187.       Also section 4 of this document is based on various discussions
  1188.       during NTT Multimedia Joint Project with NACSIS.  I would like to
  1189.       thank Prof. Shoichiro Asano of National Center for Science
  1190.       Information Systems for his invaluable advice in this area.
  1191.  
  1192.  
  1193. Author's Address
  1194.  
  1195.       Muneyoshi Suzuki
  1196.       NTT Multimedia Networks Laboratories
  1197.       3-9-11, Midori-cho
  1198.       Musashino-shi, Tokyo 180, Japan
  1199.  
  1200.       Phone: +81-422-59-2119
  1201.       Fax:   +81-422-59-3203
  1202.       EMail: suzuki@nal.ecl.net
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230. Suzuki                     Expires May, 1997                   [Page 22]
  1231.  
  1232.