idnits 2.17.1 draft-suzuki-res-resv-svc-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 1997) is 9691 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Muneyoshi Suzuki 3 INTERNET DRAFT NTT 4 Expires April 14, 1998 October 14, 1997 6 Architecture of the Resource Reservation Service 7 for the Commercial Internet 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The purpose of this document is to clarify the architecture that 31 should be used for the resource reservation service for the 32 commercial Internet. 34 First, this document explains the basis of the tariff for current 35 telecommunication and Internet services. Then it clarifies problems 36 in the billing for Internet service, and describes how billing can be 37 improved by using the resource reservation setup protocol. Finally, 38 it also studies technical and application models for a commercial 39 resource reservation service model, and clarifies an architecture for 40 the resource reservation setup protocol. 42 1. Introduction 44 With the development of new multimedia applications, such as voice, 45 audio, picture, and video communication, the demands on the resource 46 reservation service are increasing, especially as Internet traffic 47 volume grows explosively due to these applications. Therefore, 48 tariff systems for Internet service have tended to adopt measured 49 rate billing, and the resource reservation setup protocol [1, 2] is 50 increasingly important as a method for implementing measured rate 51 billing. The resource reservation setup protocol must support 52 billing if it is to be applied to the commercial Internet, especially 53 measured rate billing between interconnected Internet Service 54 Providers (ISPs) is needed. 56 The purpose of this document is to clarify the architecture that 57 should be used for the resource reservation service for the 58 commercial Internet. First, this document explains the basis of the 59 tariff for current telecommunication and Internet services. Then it 60 clarifies problems in the billing for Internet service, and describes 61 how billing can be improved by using the resource reservation setup 62 protocol. Finally, it also studies technical and application models 63 for a commercial resource reservation service model, and clarifies an 64 architecture for the resource reservation setup protocol. 66 Incidentally, it is essential to examine billing based on business 67 administration issues, not technical ones. For example, on a 68 telephone service, it technically makes sense to charge the caller 69 when the user being called is on another line. This is because, 70 telephone switches were in operation when they notified the caller 71 that the number he called was busy. However, such a billing policy 72 is contrary to the customs of business. Readers should note that the 73 billing problems and solutions discussed in this document are not 74 only based on the technical viewpoint. 76 2. The Basis of the Tariff 78 Basic elements that determine the network tariff are distance, 79 bandwidth, time, and information volume. In many cases, the network 80 tariff reflects the link cost to some extent. 82 In this document, distance means the distance between the regions 83 where users call from and to, not the actual length of the physical 84 links that connect users. In actual communication, a route depends 85 on network situations, so a charge based on the physical link 86 distance is inappropriate. 88 2.1 The Tariff in Telecommunication Services 90 Classifications of the basic styles of tariff systems in 91 telecommunication services and some examples are shown below. The 92 following classifications do not cover applied billing styles, for 93 example contents-based charging or premium charging such as the Dial 94 Q2 service of NTT, or the 900 telephone service. 96 o Flat-rate billing 98 - Leased line 99 In most cases, the tariff is based on distance and bandwidth. 101 - PVC-based frame relay and ATM 102 In most cases, the tariff is based on distance and bandwidth. 104 o Measured-rate billing 106 - Telephone 107 In most cases, the tariff is based on distance and time. 109 - Circuit switching 110 In most cases, the tariff is based on distance, bandwidth, and 111 time. 113 - SVC-based frame relay and ATM 114 In most cases, the tariff is based on distance, bandwidth, and 115 time, or information volume. 117 - X.25 packet switching 118 In most cases, the tariff is based on information volume. 120 Furthermore, measured rate billing is classified into calling- or 121 called-party billing. The basic charge style for telecommunication 122 service is calling-party billing. 124 o Calling-party billing 126 - Usual telephone service 128 o Called-party billing 130 - The Free Dial service of NTT and the 800 telephone service. 132 Basically, telecommunication service is designed for connection- 133 oriented, point-to-point, and bidirectional communication. In the 134 case of measured-rate billing, usually the calling or the called 135 party pays the bidirectional communication charge. In the case of 136 called-party billing, a function that allows incoming calls to be 137 accepted or refused based on the calling-party address, or a function 138 that restricts the calling-party addresses that are permitted to use 139 called-party billing, is indispensable. This is because, the 140 communication charge that a called party is willing to accept is 141 usually limited. 143 The current tendency in telecommunication-service tariff systems is 144 to change from measured-rate billing, which reflects link costs 145 accurately, to flat-rate billing, which simplifies the charging 146 system, and service tends to be provided by flat-rate billing inside 147 a single provider. The tariff for services between provider is 148 usually the sum of the individual providers charges. Flat-rate 149 billing, like that within a single provider, is not currently 150 realistic for services that cross providers. 152 2.2 Tariffs for Internet Service 154 Classifications of basic styles and examples of the tariff system for 155 Internet service are shown below. 157 o Flat-rate billing 159 - Internet access via leased line, PVC-based frame relay, or ATM 160 In most cases, the tariff is based on bandwidth. 162 o Measured-rate billing 164 - Dialup Internet access using a modem or N-ISDN 165 In most cases, the tariff is based on time. 167 - Internet access via leased line, PVC-based frame relay, or ATM 168 Some ISPs have adopted information-volume-based tariff systems. 170 Note: Dialup access charges in this document do not include the basic 171 telephone fee. 173 Until now, the tariff system for Internet access has mainly been 174 flat-rate billing, because measured-rate billing is technically 175 difficult to implement. However, the development of new multimedia 176 applications, such as voice, audio, picture, and video communication, 177 has caused the traffic over the Internet to increase explosively. 178 The cost of using the public network service is lower than when using 179 a private network system, if users can share equipment and lines. 180 However, if the traffic from all its users is at a steady high rate, 181 the cost advantage of the public network service is lost. Therefore, 182 Internet service tariff systems, although they use leased line 183 access, tend to adopt information-volume-based tariff systems. 185 3. Billing in the Resource Reservation Service 187 3.1 Problems of Billing in Internet Service 189 Basically, the tariff system for Internet service seems similar to 190 that for telecommunication service. However, note that the tariff 191 system for Internet service based on the access method from the user 192 site to the ISP, is not based on the end-to-end communication method. 193 The Internet is a connection less and unreliable communication, and 194 some users are beginning to use it for multicast communication. But, 195 the telecommunication is basically a connection-oriented, point-to- 196 point, and bidirectional form of communication, so telecommunication 197 and Intrenet communication are essentially different in some ways. 199 Current Internet service does not allow billing based on end-to-end 200 user site distance. This is because the structure of the IP address 201 is flat, rather than a layered structure that contains information 202 about the provider and region. So information about distance for 203 billing purpose cannot be obtained from the IP address directly. 205 Note: In this document, an address means an identifier, such as a 206 class A, B, or C IP address, that uniquely distinguishes an end 207 point. It does not means a group identifier such as a class D 208 address. 210 For Internet service, billing based on bandwidth can be provided, but 211 only for the line bandwidth between the user site and the ISP; it is 212 not based on the end-to-end user or application bandwidth, such as 213 the bandwidth in telecommunication services. 215 Current Internet service, except for the dialup access, does not 216 allow billing based on time because the IP is a connection less 217 communication, and timing information about the beginning and ending 218 of billing is too difficult to obtain. 220 Some current ISPs have adopted information-volume-based tariff 221 systems. However, this billing is based on the information volume of 222 IP packets that are sent to or received from the user site and the 223 ISP. Again, because the IP is a connection less and unreliable 224 communication, it is too difficult to provide billing based on the 225 information volume of IP packets that are actually used between end- 226 to-end users or applications. 228 It is not impossible to provide both user billing, and application 229 provider billing over the Internet when particular services are used. 230 These forms of billing are equivalent to calling- and called-party 231 billing in telecommunication service. However, obtaining the timing 232 information about the beginning and ending of application usage at 233 the IP layer is too difficult because the IP is a connection less 234 communication. To have billing based on usage time, the service 235 application responsible for the bill must identify the user and 236 monitor the usage. Also a billing process, where part of the billing 237 is transferred from the user to the service provider, must be 238 implemented. As a result, the billing system complexity is 239 increased. 241 3.2 Improved Billing Using the Resource Reservation Setup Protocol 243 As explained above, billing for current commercial Internet service 244 has many problems, but a resource reservation setup protocol may 245 solve these problems. 247 For example, the resource reservation setup protocol ensures the 248 availability of end-to-end network resources, so billing based on 249 bandwidth (FlowSpec) between user sites may be possible. Also, the 250 resource reservation setup protocol explicitly shows the resource 251 acquire and release timings, so billing based on time may be 252 feasible. 254 The resource reservation setup protocol also guarantees QoS based on 255 the FlowSpec, so billing based on the information volume that is 256 actually used between end-to-end users or applications may also be 257 feasible. Furthermore, there is a possibility that the billing for 258 each IP flow can be distributed to ether the sender or the receiver. 260 However, the resource reservation setup protocol cannot solve the 261 problem of how billing can be based on distance because the flat 262 structure of the IP address does not change and it is still 263 impossible to obtain information about distance for billing from the 264 IP address directly even when the resource reservation setup protocol 265 is used. 267 4. Technical Model of the Resource Reservation Service 269 This section looks at an unreliable, unidirectional, and tree- 270 structured multicast architecture as a technical model for a resource 271 reservation service. The QoS to all receivers is assumed to be the 272 same, and flow merging is not examined. 274 +---+ 275 | S | 276 +---+ 277 +-----------------/---\-----------------+ 278 | a / \ b | 279 | / \ | 280 | / ISP-A /\ | 281 | / / \ | 282 | / c / \ d | 283 +-----------/--------/------\-----------+ 284 +---+ +-------+ +---+ 285 |R1 | |router | |R2 | 286 +---+ +-------+ +---+ 287 +-----------------/---\-----------------+ 288 | e / \ f | 289 | / \ | 290 | / ISP-B /\ | 291 | / / \ | 292 | / g / \ h | 293 +-----------/--------/------\-----------+ 294 +---+ +---+ +---+ 295 |R3 | |R4 | |R5 | 296 +---+ +---+ +---+ 298 Fig. 4.1: Resource Reservation Service Model. 300 As shown in Fig. 4.1, ISP-A and ISP-B are interconnected, a sender S 301 and receivers R1 and R2 belong to ISP-A, and receivers R3, R4, and R5 302 belong to ISP-B. The links shown in Fig. 4.1 represent the logical 303 links that connect the regions which decide the tariff, not the 304 physical links that connect users. This section studies the receiver 305 billing and the sender billing resource reservation service with this 306 model. 308 4.1 Receiver Billing 310 When the resource reservation service is provided under receiver 311 billing, the problem is how to bill for the shared links, such as b, 312 c, and f. The shared link cost must be distributed and billed to 313 receivers based on some rule. 315 One solution inside a single ISP is to adopt a tariff system that 316 does not depend on how the links shared between receivers. Billing 317 that is based on the cost of the links that make up the multicast 318 tree is equivalent to billing based on distance. Therefore, billing 319 that does not depend on the link sharing approach is equivalent to 320 billing that is not based on distance. This means the billing can be 321 based on bandwidth (FlowSpec), time, and information volume. 323 For example, if an interconnected destination ISP is regarded as a 324 receiver, ISP-A bills to R1, R2 and ISP-B, and ISP-B bills to R3, R4, 325 and R5 [3]. The billing from ISP-A to ISP-B is distributed based on 326 some rule, and is added to the base charge in ISP-B. If a large 327 number of users join the multicast and the statistical tendency of 328 network utilization is known, it is possible to provide this type of 329 tariff system, although it does not accurately reflect communication 330 costs. 332 Another solution is to distribute the shared link cost among the 333 receivers that share the link. For example, the cost of link b would 334 be shared by R2, R3, R4 and R5. This method does reflect accurate 335 communication costs. However, in practice it is difficult to 336 implement the billing system since the complexity of computing the 337 cost of the shared link, located near a sender like b, is increased 338 because the receiver can dynamically join and leave the multicast 339 tree. 341 Therefore, in the case of receiver billing, if many users join the 342 multicast and the statistical tendency of network utilization is 343 known, billing based on bandwidth (FlowSpec), time, and information 344 volume can be provided. 346 4.2 Sender Billing 348 When the resource reservation service is provided under the sender 349 billing, the problem due to the shared link is avoided, because there 350 is no need to distribute the shared link cost. In the above model, 351 the sender would be billed for the link costs from a to h. 353 Therefore, with sender billing, billing based on accurate link costs 354 can be provided. Billing based on the link cost is equivalent to 355 billing based on distance. However, information about distance for 356 billing cannot be obtained from the IP address directly. Therefore, 357 a database that can extract information about distance from the 358 destination IP address is needed to enable billing based on the link 359 cost. 361 This is also true for sender billing: if a number of users join the 362 multicast and the statistical tendency of network utilization is 363 known, it is possible to provide billing based on bandwidth 364 (FlowSpec), time, and information volume. That is, the sender pays 365 for the billing to R1, R2, and ISP-B in ISP-A, and to R3, R4, and R5 366 in ISP-B. 368 Therefore, with sender billing, if a database is implemented that can 369 extract information about distance for billing from the destination 370 IP address, it will be possible to provide billing based on distance, 371 bandwidth (FlowSpec), time, and information volume. And if many 372 users join the multicast and the statistical tendency of network 373 utilization is known, it will also be possible to provide billing 374 based on bandwidth (FlowSpec), time, and information volume. 376 5. Application Model for the Resource Reservation Service 378 This section examines the following multimedia applications to 379 develop an application model for the resource reservation service. 381 o Broadcast-type application model 383 o Advertisement-type application model 385 o Conference-type application model 387 Methods of implementing the application model using the technical 388 model described in the previous section are also examined. 390 5.1 Broadcast-type Application Model 392 We assume that the broadcast-type application model has the following 393 features. 395 o The application provider broadcasts to receivers using the 396 multicast, and, in practice, the application is open to the public. 398 o Many receivers subscribe to the broadcast, and the statistical 399 tendency of network utilization is known. 401 o Joining the multicast tree is initiated from the receiver. 403 o The receiver pays the full amount billed. 405 o The billing is based on information volume or bandwidth (FlowSpec) 406 and time, and not on distance. 408 Features of this model correspond to receiver billing in the 409 technical model, so it is appropriate for this model to be supported 410 by it. Therefore, receiver billing based on bandwidth (FlowSpec) and 411 time, or information volume can be provided. 413 5.2 Advertisement-type Application Model 415 We assume that the advertisement-type application model has the 416 following features. 418 o The application provider advertises to receivers using the 419 multicast, and, in practice, the application is open to the public. 421 o Many receivers subscribe to the advertisement, and the statistical 422 tendency of network utilization is known. 424 o Joining the multicast tree is initiated from the receiver side. 426 o The application provider pays the full amount billed. 428 o A function that restricts the region in which the receiver is 429 permitted to join, or a function that decides whether to accept or 430 refuse the joining request based on the IP address of the receiver 431 or based on the tariff to be billed, is indispensable. This is 432 because the communication charge that is acceptable to an 433 application provider is usually limited. 435 Features of this model roughly correspond to sender billing in the 436 technical model, so it is appropriate for this model to be supported 437 by it. But this model needs a function that restricts the region in 438 which the receiver is permitted to join, or a function that decides 439 whether to accept or refuse the joining request based on the IP 440 address of the receiver or based on the tariff to be billed. 442 If the region that the receiver is permitted to join is simply 443 restricted by the ISP boundary, the model can be implemented by 444 restricting the IP flow forwarding between ISPs. 446 But if the decision to accept or refuse the joining request is based 447 on the IP address of the receiver or based on the tariff to be 448 billed, a database that can extract information about permission or 449 distance for billing from the destination IP address is needed. In 450 the resource reservation setup protocol, a procedure that supports 451 this kind of processing is also needed. 453 However, if this procedure is processed only by the sender, and the 454 number of receivers significantly increases, saturation of the sender 455 protocol processing may occur. Therefore, an intermediate node is 456 needed inside the multicast tree, and this intermediate node will 457 decide whether to accept or refuse the joining request. 459 Therefore, in the advertisement-type application model, if the region 460 that the receiver is permitted to join is simply restricted by the 461 ISP boundary, it is appropriate for this model to be supported by the 462 sender billing in the technical model. Thus, sender billing based on 463 bandwidth (FlowSpec) and time, or information volume, can be 464 provided. 466 If the decision to accept or refuse the joining request is based on 467 the IP address of the receiver or based on the tariff to be billed, 468 in addition to the sender billing in the technical model, a database, 469 that can extract information about permission or distance for billing 470 from the destination IP address is needed. In the resource 471 reservation setup protocol, a procedure that supports this process is 472 also needed. In this case, it can be provided by sender billing 473 based on distance, bandwidth (FlowSpec) and time, or information 474 volume. 476 5.3 Conference-type Application Model 478 We assume that the conference-type application model has the 479 following features. 481 o The conference is held by a small number of participants. 483 o The statistical tendency of network utilization in the conference 484 depends on each conference style and the tendency is hard to 485 estimate. 487 o Joining the conference is initiated by each participant. That is 489 - Joining the multicast tree from an existing participant or 490 receiving information from the conference server is initiated by 491 the receiver. 493 - Construction of the multicast tree for existing participants or 494 information sent to the conference server is initiated by the 495 sender. 497 o Management of conference participants is indispensable. A function 498 that can decide to accept or refuse a participation request based 499 on the IP address of the potential participant, or a similar 500 function is needed. 502 To avoid establishing an unreasonably expensive tariff for short 503 distance communications, this model needs billing based on accurate 504 link costs, because the tendency of network utilization is hard to 505 estimate. 507 Therefore, in this model, in addition to the sender billing from the 508 technical model, a database that can extract information about 509 permission and distance for billing from the destination IP address 510 is needed. In the resource reservation setup protocol, a procedure 511 that supports this process is also needed. In this case, it can be 512 provided by sender billing based on distance, bandwidth (FlowSpec) 513 and time, or information volume. 515 6. Architecture of the Resource Reservation Setup Protocol 517 Combinations of the billing side and the initiating side in a joining 518 request in the resource reservation setup protocol based on the above 519 studies are shown in Table 6.1. 521 Table 6.1: Combinations of Billing and Initiating Sides of Joining Request. 523 +---------------+---------------+---------------+ 524 | Application | Billing Side |Initiating Side| 525 +===============+===============+===============+ 526 | Broadcast | Receiver | Receiver | 527 +---------------+---------------+---------------+ 528 | Advertisement | Sender | Receiver | 529 +---------------+---------------+---------------+ 530 | Conference | Sender |Sender,Receiver| 531 +---------------+---------------+---------------+ 533 In addition to supporting all the above combinations of the billing 534 side and the initiating side in a joining request, the commercial 535 resource reservation service must satisfy the following requirements 536 for sender billing. 538 o A function is needed that restricts the region that a receiver is 539 permitted to join, or that decides whether to accept or refuse the 540 joining request based on the receiver IP address and/or on the 541 tariff to be billed. 543 o If the application is open to the public, an intermediate node that 544 decides whether to accept or refuse the joining request is needed 545 inside the multicast tree. 547 To achieve the combination of a sender billed and receiver initiated 548 joining request, the resource reservation setup protocol must support 549 a resource reservation procedure that is initiated by acceptance of a 550 joining request from a receiver. Therefore, the following sender 551 initiation basis protocol is a natural architecture for the 552 commercial resource reservation service. 554 o The basis of the resource reservation setup protocol is sender 555 initiation. That is, as shown in Fig. 6.1, the sender explicitly 556 designates the receiver address, sends a resource reservation setup 557 message (SETUP), and constructs the multicast tree. 559 +---+ 560 +--------| S |--------+ 561 | +---+ | 562 +--------|--------/-|-\--------|--------+ 563 | | / | \ | | 564 | | / | \ | | 565 | SETUP / SETUP /\ SETUP | 566 | | / | / \ | | 567 | | / | / \ | | 568 +--------|--/------ | ------\--|--------+ 569 +-V-+ +---V---+ +-V-+ 570 |R1 | | | |R2 | 571 +---+ |router | +---+ 572 +------| |------+ 573 | +-------+ | 574 +--------|--------/-|-\--------|--------+ 575 | | / | \ | | 576 | | / | \ | | 577 | SETUP / SETUP /\ SETUP | 578 | | / | / \ | | 579 | | / | / \ | | 580 +--------|--/------ | ------\--|--------+ 581 +-V-+ +-V-+ +-V-+ 582 |R3 | |R4 | |R5 | 583 +---+ +---+ +---+ 585 Fig. 6.1: Sender Initiation. 587 o In the case of receiver initiation, as shown in Fig. 6.2, the 588 receiver explicitly sends the joining request message (JOIN), and 589 if the sender accepts it, the sender sends a resource reservation 590 setup message to the receiver. 592 +---+ 593 | S | 594 +A--+ 595 +-----------------/|-|\-----------------+ 596 | / | | \ | 597 | / | | \ | 598 | JOIN| |SETUP | 599 | / | | / \ | 600 | / | |/ \ | 601 +-----------/------|-|------\-----------+ 602 +---+ +----V--+ +---+ 603 |R1 | | | |R2 | 604 +---+ |router | +---+ 605 +-------> | 606 | +---- +-------+ 607 +-------|-|-------/---\-----------------+ 608 | | | / \ | 609 | | | / \ | 610 | JOIN| |SETUP /\ | 611 | | | / / \ | 612 | | | / / \ | 613 +-------|-|-/--------/------\-----------+ 614 +--V+ +---+ +---+ 615 |R3 | |R4 | |R5 | 616 +---+ +---+ +---+ 618 Fig. 6.2: Receiver Initiation. 620 o However, if the application is open to the public, as shown in Fig. 621 6.3, the intermediate node inside the multicast tree that decides 622 whether to accept or refuse the joining request, may send a 623 resource reservation setup message as a response to the joining 624 request message. 626 +---+ 627 | S | 628 +---+ 629 +-----------------/---\-----------------+ 630 | / \ | 631 | / \ | 632 | / /\ | 633 | / / \ | 634 | / / \ | 635 +-----------/--------/------\-----------+ 636 +---+ +-------+ +---+ 637 |R1 | | | |R2 | 638 +---+ | node | +---+ 639 +-------> | 640 | +---- +-------+ 641 +-------|-|-------/---\-----------------+ 642 | | | / \ | 643 | | | / \ | 644 | JOIN| |SETUP /\ | 645 | | | / / \ | 646 | | | / / \ | 647 +-------|-|-/--------/------\-----------+ 648 +--V+ +---+ +---+ 649 |R3 | |R4 | |R5 | 650 +---+ +---+ +---+ 652 Fig. 6.3: Intermediate Node. 654 7. Conclusions 656 This document studied technical and application models of the 657 resource reservation service, and clarified the followings in terms 658 of an architecture for the resource reservation setup protocol. 660 o The basis of the resource reservation setup protocol is sender 661 initiation. That is, the sender explicitly designates the receiver 662 address, sends a resource reservation setup message and constructs 663 a multicast tree. 665 o In the case of receiver initiation, the receiver explicitly sends a 666 joining request message; if the sender accepts it, the sender sends 667 a resource reservation setup message to the receiver. 669 o However, if the application is open to the public, an intermediate 670 node inside the multicast tree decides whether to accept or refuse 671 the joining request, and may send a resource reservation setup 672 message as a response to the joining request message. 674 Finally, if the billing policies of ISPs are fundamentally different 675 from each other in the commercial resource reservation service, it 676 will be difficult to achieve smooth interconnection. Therefore, the 677 author believes that ISPs need to conclude agreements or to clarify 678 recommendations concerning minimum common billing policies for the 679 resource reservation service, especially on the definition of 680 distance for billing purpose. 682 References 684 [1] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 685 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 686 August 1995. 688 [2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1 689 Functional Specification," RFC 2205, September 1997. 691 [3] S. Herzog, "Policy Control for RSVP: Architectural Overview," 692 Internet Draft, November 1996, . 695 Acknowledgments 697 This document is based on my discussions with many colleagues at 698 NTT. I would like to specially thank Hiroshi Ishikawa, Sadahiko 699 Kanou, Masaru Nishi, Satoshi Takamatsu, and Hideaki Arai of the 700 NTT Network Strategy Planning Dept., and also Hisao Uose of the 701 NTT Multimedia Networks Labs. for their valuable comments. 703 And I would also like to especially thank Joel Halpern and James 704 Watt of Newbridge Networks for their valuable comments and 705 suggestions. 707 Also this document is based on various discussions during NTT 708 Multimedia Joint Project with NACSIS. I would like to thank 709 Professor Shoichiro Asano of the National Center for Science 710 Information Systems for his invaluable advice in this area. 712 Author's Address 714 Muneyoshi Suzuki 715 NTT Multimedia Networks Laboratories 716 3-9-11, Midori-cho 717 Musashino-shi, Tokyo 180, Japan 719 Phone: +81-422-59-2119 720 Fax: +81-422-59-3203 721 EMail: suzuki@nal.ecl.net