idnits 2.17.1 draft-rfced-info-suzuki-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 10, 1998) is 9565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT 2 Network Working Group Muneyoshi Suzuki 3 INTERNET DRAFT NTT 4 Category: Informational February 10, 1998 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 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To learn the current status of any Internet-Draft, please check 24 the "1id-abstracts.txt" listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 1. Introduction 33 With the development of new multimedia applications, such as voice, 34 audio, picture, and video communication, the demands on the resource 35 reservation service are increasing, especially as Internet traffic 36 volume grows explosively due to these applications. Therefore, 37 tariff systems for Internet service have tended to adopt measured 38 rate billing, and the resource reservation setup protocol [1, 2] is 39 increasingly important as a method for implementing measured rate 40 billing. The resource reservation setup protocol must support 41 billing if it is to be applied to the commercial Internet, especially 42 measured rate billing between interconnected Internet Service 43 Providers (ISPs) is needed. 45 The purpose of this document is to clarify the architecture that 46 should be used for the resource reservation service for the 47 commercial Internet. First, this document explains the basis of the 48 tariff for current telecommunication and Internet services. Then it 49 clarifies problems in the billing for Internet service, and describes 50 how billing can be improved by using the resource reservation setup 51 protocol. Finally, it also studies technical and application models 52 for a commercial resource reservation service model, and clarifies an 53 architecture for the resource reservation setup protocol. 55 Incidentally, it is essential to examine billing based on business 56 administration issues, not technical ones. For example, on a 57 telephone service, it technically makes sense to charge the caller 58 when the user being called is on another line. This is because, 59 telephone switches were in operation when they notified the caller 60 that the number he called was busy. However, such a billing policy 61 is contrary to the customs of business. Readers should note that the 62 billing problems and solutions discussed in this document are not 63 only based on the technical viewpoint. 65 2. The Basis of the Tariff 67 Basic elements that determine the network tariff are distance, 68 bandwidth, time, and information volume. In many cases, the network 69 tariff reflects the link cost to some extent. 71 In this document, distance means the distance between the regions 72 where users call from and to, not the actual length of the physical 73 links that connect users. In actual communication, a route depends 74 on network situations, so a charge based on the physical link 75 distance is inappropriate. 77 2.1 The Tariff in Telecommunication Services 79 Classifications of the basic styles of tariff systems in 80 telecommunication services and some examples are shown below. The 81 following classifications do not cover applied billing styles, for 82 example contents-based charging or premium charging such as the Dial 83 Q2 service of NTT, or the 900 telephone service. 85 o Flat-rate billing 87 - Leased line 88 In most cases, the tariff is based on distance and bandwidth. 90 - PVC-based frame relay and ATM 91 In most cases, the tariff is based on distance and bandwidth. 93 o Measured-rate billing 95 - Telephone 96 In most cases, the tariff is based on distance and time. 98 - Circuit switching 99 In most cases, the tariff is based on distance, bandwidth, and 100 time. 102 - SVC-based frame relay and ATM 103 In most cases, the tariff is based on distance, bandwidth, and 104 time, or information volume. 106 - X.25 packet switching 107 In most cases, the tariff is based on information volume. 109 Furthermore, measured rate billing is classified into calling- or 110 called-party billing. The basic charge style for telecommunication 111 service is calling-party billing. 113 o Calling-party billing 115 - Usual telephone service 117 o Called-party billing 119 - The Free Dial service of NTT and the 800 telephone service. 121 Basically, telecommunication service is designed for connection- 122 oriented, point-to-point, and bidirectional communication. In the 123 case of measured-rate billing, usually the calling or the called 124 party pays the bidirectional communication charge. In the case of 125 called-party billing, a function that allows incoming calls to be 126 accepted or refused based on the calling-party address, or a function 127 that restricts the calling-party addresses that are permitted to use 128 called-party billing, is indispensable. This is because, the 129 communication charge that a called party is willing to accept is 130 usually limited. 132 The current tendency in telecommunication-service tariff systems is 133 to change from measured-rate billing, which reflects link costs 134 accurately, to flat-rate billing, which simplifies the charging 135 system, and service tends to be provided by flat-rate billing inside 136 a single provider. The tariff for services between provider is 137 usually the sum of the individual providers charges. Flat-rate 138 billing, like that within a single provider, is not currently 139 realistic for services that cross providers. 141 2.2 Tariffs for Internet Service 143 Classifications of basic styles and examples of the tariff system for 144 Internet service are shown below. 146 o Flat-rate billing 148 - Internet access via leased line, PVC-based frame relay, or ATM 149 In most cases, the tariff is based on bandwidth. 151 o Measured-rate billing 153 - Dialup Internet access using a modem or N-ISDN 154 In most cases, the tariff is based on time. 156 - Internet access via leased line, PVC-based frame relay, or ATM 157 Some ISPs have adopted information-volume-based tariff systems. 159 Note: Dialup access charges in this document do not include the basic 160 telephone fee. 162 Until now, the tariff system for Internet access has mainly been 163 flat-rate billing, because measured-rate billing is technically 164 difficult to implement. However, the development of new multimedia 165 applications, such as voice, audio, picture, and video communication, 166 has caused the traffic over the Internet to increase explosively. 167 The cost of using the public network service is lower than when using 168 a private network system, if users can share equipment and lines. 169 However, if the traffic from all its users is at a steady high rate, 170 the cost advantage of the public network service is lost. Therefore, 171 Internet service tariff systems, although they use leased line 172 access, tend to adopt information-volume-based tariff systems. 174 3. Billing in the Resource Reservation Service 176 3.1 Problems of Billing in Internet Service 178 Basically, the tariff system for Internet service seems similar to 179 that for telecommunication service. However, note that the tariff 180 system for Internet service based on the access method from the user 181 site to the ISP, is not based on the end-to-end communication method. 182 The Internet is a connection less and unreliable communication, and 183 some users are beginning to use it for multicast communication. But, 184 the telecommunication is basically a connection-oriented, point-to- 185 point, and bidirectional form of communication, so telecommunication 186 and Intrenet communication are essentially different in some ways. 188 Current Internet service does not allow billing based on end-to-end 189 user site distance. This is because the structure of the IP address 190 is flat, rather than a layered structure that contains information 191 about the provider and region. So information about distance for 192 billing purpose cannot be obtained from the IP address directly. 194 Note: In this document, an address means an identifier, such as a 195 class A, B, or C IP address, that uniquely distinguishes an end 196 point. It does not means a group identifier such as a class D 197 address. 199 For Internet service, billing based on bandwidth can be provided, but 200 only for the line bandwidth between the user site and the ISP; it is 201 not based on the end-to-end user or application bandwidth, such as 202 the bandwidth in telecommunication services. 204 Current Internet service, except for the dialup access, does not 205 allow billing based on time because the IP is a connection less 206 communication, and timing information about the beginning and ending 207 of billing is too difficult to obtain. 209 Some current ISPs have adopted information-volume-based tariff 210 systems. However, this billing is based on the information volume of 211 IP packets that are sent to or received from the user site and the 212 ISP. Again, because the IP is a connection less and unreliable 213 communication, it is too difficult to provide billing based on the 214 information volume of IP packets that are actually used between end- 215 to-end users or applications. 217 It is not impossible to provide both user billing, and application 218 provider billing over the Internet when particular services are used. 219 These forms of billing are equivalent to calling- and called-party 220 billing in telecommunication service. However, obtaining the timing 221 information about the beginning and ending of application usage at 222 the IP layer is too difficult because the IP is a connection less 223 communication. To have billing based on usage time, the service 224 application responsible for the bill must identify the user and 225 monitor the usage. Also a billing process, where part of the billing 226 is transferred from the user to the service provider, must be 227 implemented. As a result, the billing system complexity is 228 increased. 230 3.2 Improved Billing Using the Resource Reservation Setup Protocol 232 As explained above, billing for current commercial Internet service 233 has many problems, but a resource reservation setup protocol may 234 solve these problems. 236 For example, the resource reservation setup protocol ensures the 237 availability of end-to-end network resources, so billing based on 238 bandwidth (FlowSpec) between user sites may be possible. Also, the 239 resource reservation setup protocol explicitly shows the resource 240 acquire and release timings, so billing based on time may be 241 feasible. 243 The resource reservation setup protocol also guarantees QoS based on 244 the FlowSpec, so billing based on the information volume that is 245 actually used between end-to-end users or applications may also be 246 feasible. Furthermore, there is a possibility that the billing for 247 each IP flow can be distributed to ether the sender or the receiver. 249 However, the resource reservation setup protocol cannot solve the 250 problem of how billing can be based on distance because the flat 251 structure of the IP address does not change and it is still 252 impossible to obtain information about distance for billing from the 253 IP address directly even when the resource reservation setup protocol 254 is used. 256 4. Technical Model of the Resource Reservation Service 258 This section looks at an unreliable, unidirectional, and tree- 259 structured multicast architecture as a technical model for a resource 260 reservation service. The QoS to all receivers is assumed to be the 261 same, and flow merging is not examined. 263 +---+ 264 | S | 265 +---+ 266 +-----------------/---\-----------------+ 267 | a / \ b | 268 | / \ | 269 | / ISP-A /\ | 270 | / / \ | 271 | / c / \ d | 272 +-----------/--------/------\-----------+ 273 +---+ +-------+ +---+ 274 |R1 | |router | |R2 | 275 +---+ +-------+ +---+ 276 +-----------------/---\-----------------+ 277 | e / \ f | 278 | / \ | 279 | / ISP-B /\ | 280 | / / \ | 281 | / g / \ h | 282 +-----------/--------/------\-----------+ 283 +---+ +---+ +---+ 284 |R3 | |R4 | |R5 | 285 +---+ +---+ +---+ 287 Fig. 4.1: Resource Reservation Service Model. 289 As shown in Fig. 4.1, ISP-A and ISP-B are interconnected, a sender S 290 and receivers R1 and R2 belong to ISP-A, and receivers R3, R4, and R5 291 belong to ISP-B. The links shown in Fig. 4.1 represent the logical 292 links that connect the regions which decide the tariff, not the 293 physical links that connect users. This section studies the receiver 294 billing and the sender billing resource reservation service with this 295 model. 297 4.1 Receiver Billing 299 When the resource reservation service is provided under receiver 300 billing, the problem is how to bill for the shared links, such as b, 301 c, and f. The shared link cost must be distributed and billed to 302 receivers based on some rule. 304 One solution inside a single ISP is to adopt a tariff system that 305 does not depend on how the links shared between receivers. Billing 306 that is based on the cost of the links that make up the multicast 307 tree is equivalent to billing based on distance. Therefore, billing 308 that does not depend on the link sharing approach is equivalent to 309 billing that is not based on distance. This means the billing can be 310 based on bandwidth (FlowSpec), time, and information volume. 312 For example, if an interconnected destination ISP is regarded as a 313 receiver, ISP-A bills to R1, R2 and ISP-B, and ISP-B bills to R3, R4, 314 and R5 [3]. The billing from ISP-A to ISP-B is distributed based on 315 some rule, and is added to the base charge in ISP-B. If a large 316 number of users join the multicast and the statistical tendency of 317 network utilization is known, it is possible to provide this type of 318 tariff system, although it does not accurately reflect communication 319 costs. 321 Another solution is to distribute the shared link cost among the 322 receivers that share the link. For example, the cost of link b would 323 be shared by R2, R3, R4 and R5. This method does reflect accurate 324 communication costs. However, in practice it is difficult to 325 implement the billing system since the complexity of computing the 326 cost of the shared link, located near a sender like b, is increased 327 because the receiver can dynamically join and leave the multicast 328 tree. 330 Therefore, in the case of receiver billing, if many users join the 331 multicast and the statistical tendency of network utilization is 332 known, billing based on bandwidth (FlowSpec), time, and information 333 volume can be provided. 335 4.2 Sender Billing 337 When the resource reservation service is provided under the sender 338 billing, the problem due to the shared link is avoided, because there 339 is no need to distribute the shared link cost. In the above model, 340 the sender would be billed for the link costs from a to h. 342 Therefore, with sender billing, billing based on accurate link costs 343 can be provided. Billing based on the link cost is equivalent to 344 billing based on distance. However, information about distance for 345 billing cannot be obtained from the IP address directly. Therefore, 346 a database that can extract information about distance from the 347 destination IP address is needed to enable billing based on the link 348 cost. 350 This is also true for sender billing: if a number of users join the 351 multicast and the statistical tendency of network utilization is 352 known, it is possible to provide billing based on bandwidth 353 (FlowSpec), time, and information volume. That is, the sender pays 354 for the billing to R1, R2, and ISP-B in ISP-A, and to R3, R4, and R5 355 in ISP-B. 357 Therefore, with sender billing, if a database is implemented that can 358 extract information about distance for billing from the destination 359 IP address, it will be possible to provide billing based on distance, 360 bandwidth (FlowSpec), time, and information volume. And if many 361 users join the multicast and the statistical tendency of network 362 utilization is known, it will also be possible to provide billing 363 based on bandwidth (FlowSpec), time, and information volume. 365 5. Application Model for the Resource Reservation Service 367 This section examines the following multimedia applications to 368 develop an application model for the resource reservation service. 370 o Broadcast-type application model 372 o Advertisement-type application model 374 o Conference-type application model 376 Methods of implementing the application model using the technical 377 model described in the previous section are also examined. 379 5.1 Broadcast-type Application Model 381 We assume that the broadcast-type application model has the following 382 features. 384 o The application provider broadcasts to receivers using the 385 multicast, and, in practice, the application is open to the public. 387 o Many receivers subscribe to the broadcast, and the statistical 388 tendency of network utilization is known. 390 o Joining the multicast tree is initiated from the receiver. 392 o The receiver pays the full amount billed. 394 o The billing is based on information volume or bandwidth (FlowSpec) 395 and time, and not on distance. 397 Features of this model correspond to receiver billing in the 398 technical model, so it is appropriate for this model to be supported 399 by it. Therefore, receiver billing based on bandwidth (FlowSpec) and 400 time, or information volume can be provided. 402 5.2 Advertisement-type Application Model 404 We assume that the advertisement-type application model has the 405 following features. 407 o The application provider advertises to receivers using the 408 multicast, and, in practice, the application is open to the public. 410 o Many receivers subscribe to the advertisement, and the statistical 411 tendency of network utilization is known. 413 o Joining the multicast tree is initiated from the receiver side. 415 o The application provider pays the full amount billed. 417 o A function that restricts the region in which the receiver is 418 permitted to join, or a function that decides whether to accept or 419 refuse the joining request based on the IP address of the receiver 420 or based on the tariff to be billed, is indispensable. This is 421 because the communication charge that is acceptable to an 422 application provider is usually limited. 424 Features of this model roughly correspond to sender billing in the 425 technical model, so it is appropriate for this model to be supported 426 by it. But this model needs a function that restricts the region in 427 which the receiver is permitted to join, or a function that decides 428 whether to accept or refuse the joining request based on the IP 429 address of the receiver or based on the tariff to be billed. 431 If the region that the receiver is permitted to join is simply 432 restricted by the ISP boundary, the model can be implemented by 433 restricting the IP flow forwarding between ISPs. 435 But if the decision to accept or refuse the joining request is based 436 on the IP address of the receiver or based on the tariff to be 437 billed, a database that can extract information about permission or 438 distance for billing from the destination IP address is needed. In 439 the resource reservation setup protocol, a procedure that supports 440 this kind of processing is also needed. 442 However, if this procedure is processed only by the sender, and the 443 number of receivers significantly increases, saturation of the sender 444 protocol processing may occur. Therefore, an intermediate node is 445 needed inside the multicast tree, and this intermediate node will 446 decide whether to accept or refuse the joining request. 448 Therefore, in the advertisement-type application model, if the region 449 that the receiver is permitted to join is simply restricted by the 450 ISP boundary, it is appropriate for this model to be supported by the 451 sender billing in the technical model. Thus, sender billing based on 452 bandwidth (FlowSpec) and time, or information volume, can be 453 provided. 455 If the decision to accept or refuse the joining request is based on 456 the IP address of the receiver or based on the tariff to be billed, 457 in addition to the sender billing in the technical model, a database, 458 that can extract information about permission or distance for billing 459 from the destination IP address is needed. In the resource 460 reservation setup protocol, a procedure that supports this process is 461 also needed. In this case, it can be provided by sender billing 462 based on distance, bandwidth (FlowSpec) and time, or information 463 volume. 465 5.3 Conference-type Application Model 467 We assume that the conference-type application model has the 468 following features. 470 o The conference is held by a small number of participants. 472 o The statistical tendency of network utilization in the conference 473 depends on each conference style and the tendency is hard to 474 estimate. 476 o Joining the conference is initiated by each participant. That is 478 - Joining the multicast tree from an existing participant or 479 receiving information from the conference server is initiated by 480 the receiver. 482 - Construction of the multicast tree for existing participants or 483 information sent to the conference server is initiated by the 484 sender. 486 o Management of conference participants is indispensable. A function 487 that can decide to accept or refuse a participation request based 488 on the IP address of the potential participant, or a similar 489 function is needed. 491 To avoid establishing an unreasonably expensive tariff for short 492 distance communications, this model needs billing based on accurate 493 link costs, because the tendency of network utilization is hard to 494 estimate. 496 Therefore, in this model, in addition to the sender billing from the 497 technical model, a database that can extract information about 498 permission and distance for billing from the destination IP address 499 is needed. In the resource reservation setup protocol, a procedure 500 that supports this process is also needed. In this case, it can be 501 provided by sender billing based on distance, bandwidth (FlowSpec) 502 and time, or information volume. 504 6. Architecture of the Resource Reservation Setup Protocol 506 Combinations of the billing side and the initiating side in a joining 507 request in the resource reservation setup protocol based on the above 508 studies are shown in Table 6.1. 510 Table 6.1: Combinations of Billing and Initiating Sides of Joining Request. 512 +---------------+---------------+---------------+ 513 | Application | Billing Side |Initiating Side| 514 +===============+===============+===============+ 515 | Broadcast | Receiver | Receiver | 516 +---------------+---------------+---------------+ 517 | Advertisement | Sender | Receiver | 518 +---------------+---------------+---------------+ 519 | Conference | Sender |Sender,Receiver| 520 +---------------+---------------+---------------+ 522 In addition to supporting all the above combinations of the billing 523 side and the initiating side in a joining request, the commercial 524 resource reservation service must satisfy the following requirements 525 for sender billing. 527 o A function is needed that restricts the region that a receiver is 528 permitted to join, or that decides whether to accept or refuse the 529 joining request based on the receiver IP address and/or on the 530 tariff to be billed. 532 o If the application is open to the public, an intermediate node that 533 decides whether to accept or refuse the joining request is needed 534 inside the multicast tree. 536 To achieve the combination of a sender billed and receiver initiated 537 joining request, the resource reservation setup protocol must support 538 a resource reservation procedure that is initiated by acceptance of a 539 joining request from a receiver. Therefore, the following sender 540 initiation basis protocol is a natural architecture for the 541 commercial resource reservation service. 543 o The basis of the resource reservation setup protocol is sender 544 initiation. That is, as shown in Fig. 6.1, the sender explicitly 545 designates the receiver address, sends a resource reservation setup 546 message (SETUP), and constructs the multicast tree. 548 +---+ 549 +--------| S |--------+ 550 | +---+ | 551 +--------|--------/-|-\--------|--------+ 552 | | / | \ | | 553 | | / | \ | | 554 | SETUP / SETUP /\ SETUP | 555 | | / | / \ | | 556 | | / | / \ | | 557 +--------|--/------ | ------\--|--------+ 558 +-V-+ +---V---+ +-V-+ 559 |R1 | | | |R2 | 560 +---+ |router | +---+ 561 +------| |------+ 562 | +-------+ | 563 +--------|--------/-|-\--------|--------+ 564 | | / | \ | | 565 | | / | \ | | 566 | SETUP / SETUP /\ SETUP | 567 | | / | / \ | | 568 | | / | / \ | | 569 +--------|--/------ | ------\--|--------+ 570 +-V-+ +-V-+ +-V-+ 571 |R3 | |R4 | |R5 | 572 +---+ +---+ +---+ 574 Fig. 6.1: Sender Initiation. 576 o In the case of receiver initiation, as shown in Fig. 6.2, the 577 receiver explicitly sends the joining request message (JOIN), and 578 if the sender accepts it, the sender sends a resource reservation 579 setup message to the receiver. 581 +---+ 582 | S | 583 +A--+ 584 +-----------------/|-|\-----------------+ 585 | / | | \ | 586 | / | | \ | 587 | JOIN| |SETUP | 588 | / | | / \ | 589 | / | |/ \ | 590 +-----------/------|-|------\-----------+ 591 +---+ +----V--+ +---+ 592 |R1 | | | |R2 | 593 +---+ |router | +---+ 594 +-------> | 595 | +---- +-------+ 596 +-------|-|-------/---\-----------------+ 597 | | | / \ | 598 | | | / \ | 599 | JOIN| |SETUP /\ | 600 | | | / / \ | 601 | | | / / \ | 602 +-------|-|-/--------/------\-----------+ 603 +--V+ +---+ +---+ 604 |R3 | |R4 | |R5 | 605 +---+ +---+ +---+ 607 Fig. 6.2: Receiver Initiation. 609 o However, if the application is open to the public, as shown in Fig. 610 6.3, the intermediate node inside the multicast tree that decides 611 whether to accept or refuse the joining request, may send a 612 resource reservation setup message as a response to the joining 613 request message. 615 +---+ 616 | S | 617 +---+ 618 +-----------------/---\-----------------+ 619 | / \ | 620 | / \ | 621 | / /\ | 622 | / / \ | 623 | / / \ | 624 +-----------/--------/------\-----------+ 625 +---+ +-------+ +---+ 626 |R1 | | | |R2 | 627 +---+ | node | +---+ 628 +-------> | 629 | +---- +-------+ 630 +-------|-|-------/---\-----------------+ 631 | | | / \ | 632 | | | / \ | 633 | JOIN| |SETUP /\ | 634 | | | / / \ | 635 | | | / / \ | 636 +-------|-|-/--------/------\-----------+ 637 +--V+ +---+ +---+ 638 |R3 | |R4 | |R5 | 639 +---+ +---+ +---+ 641 Fig. 6.3: Intermediate Node. 643 7. Conclusions 645 This document studied technical and application models of the 646 resource reservation service, and clarified the followings in terms 647 of an architecture for the resource reservation setup protocol. 649 o The basis of the resource reservation setup protocol is sender 650 initiation. That is, the sender explicitly designates the receiver 651 address, sends a resource reservation setup message and constructs 652 a multicast tree. 654 o In the case of receiver initiation, the receiver explicitly sends a 655 joining request message; if the sender accepts it, the sender sends 656 a resource reservation setup message to the receiver. 658 o However, if the application is open to the public, an intermediate 659 node inside the multicast tree decides whether to accept or refuse 660 the joining request, and may send a resource reservation setup 661 message as a response to the joining request message. 663 Finally, if the billing policies of ISPs are fundamentally different 664 from each other in the commercial resource reservation service, it 665 will be difficult to achieve smooth interconnection. Therefore, the 666 author believes that ISPs need to conclude agreements or to clarify 667 recommendations concerning minimum common billing policies for the 668 resource reservation service, especially on the definition of 669 distance for billing purpose. 671 References 673 [1] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 674 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 675 August 1995. 677 [2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1 678 Functional Specification," RFC 2205, September 1997. 680 [3] S. Herzog, "Policy Control for RSVP: Architectural Overview," 681 Internet Draft, November 1996, . 684 Acknowledgments 686 This document is based on my discussions with many colleagues at 687 NTT. I would like to specially thank Hiroshi Ishikawa, Sadahiko 688 Kanou, Masaru Nishi, Satoshi Takamatsu, and Hideaki Arai of the 689 NTT Network Strategy Planning Dept., and also Hisao Uose of the 690 NTT Multimedia Networks Labs. for their valuable comments. 692 And I would also like to especially thank Joel Halpern and James 693 Watt of Newbridge Networks for their valuable comments and 694 suggestions. 696 Also this document is based on various discussions during NTT 697 Multimedia Joint Project with NACSIS. I would like to thank 698 Professor Shoichiro Asano of the National Center for Science 699 Information Systems for his invaluable advice in this area. 701 Author's Address 703 Muneyoshi Suzuki 704 NTT Multimedia Networks Laboratories 705 3-9-11, Midori-cho 706 Musashino-shi, Tokyo 180, Japan 708 Phone: +81-422-59-2119 709 Fax: +81-422-59-3203 710 EMail: suzuki@nal.ecl.net 712 Full Copyright Statement 714 "Copyright (C) The Internet Society (1997). All Rights Reserved. 716 This document and translations of it may be copied and furnished to 717 others, and derivative works that comment on or otherwise explain it 718 or assist in its implmentation may be prepared, copied, published and 719 distributed, in whole or in part, without restriction of any kind, 720 provided that the above copyright notice and this paragraph are 721 included on all such copies and derivative works. However, this 722 document itself may not be modified in any way, such as by removing 723 the copyright notice or references to the Internet Society or other 724 Internet organizations, except as needed for the purpose of 725 developing Internet standards in which case the procedures for 726 copyrights defined in the Internet Standards process must be 727 followed, or as required to translate it into languages other than 728 English. 730 The limited permissions granted above are perpetual and will not be 731 revoked by the Internet Society or its successors or assigns. 733 This document and the information contained herein is provided on an 734 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 735 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 736 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 737 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 738 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 740 INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT