idnits 2.17.1 draft-suzuki-res-resv-svc-arch-00.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-25) 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 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. 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 (November 25, 1996) is 10013 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) == Unused Reference: '4' is defined on line 874, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 878, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 May 25, 1997 November 25, 1996 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. 39 This document also studies technical and application models for a 40 commercial resource reservation service model, and clarifies an 41 architecture for the resource reservation setup protocol. Last, it 42 explains why ATM is an indispensable implementation technology for 43 the commercial resource reservation service, and investigates an 44 implementation method for a resource reservation setup protocol that 45 is based on ATM. 47 1. Introduction 49 With the development of new multimedia applications, such as voice, 50 audio, picture, and video communication, the demands on the resource 51 reservation service are increasing, especially as Internet traffic 52 volume grows explosively due to these applications. Therefore, 53 tariff systems for Internet service have tended to adopt measured 54 rate billing, and the resource reservation setup protocol [2, 3] is 55 increasingly important as a method for implementing measured rate 56 billing. 58 The resource reservation setup protocol [1] must support billing if 59 it is to be applied to the commercial Internet, especially measured 60 rate billing between interconnected Internet Service Providers (ISPs) 61 is needed. And to investigate the implementation method of the 62 resource reservation setup protocol in the commercial Internet 63 environment is also needed. 65 The purpose of this document is to clarify the architecture that 66 should be used for the resource reservation service for the 67 commercial Internet. First, this document explains the basis of the 68 tariff for current telecommunication and Internet services. Then it 69 clarifies problems in the billing for Internet service, and describes 70 how billing can be improved by using the resource reservation setup 71 protocol. 73 This document also studies technical and application models for a 74 commercial resource reservation service model, and clarifies an 75 architecture for the resource reservation setup protocol. Last, it 76 explains why ATM is an indispensable implementation technology for 77 the commercial resource reservation service, and investigates an 78 implementation method for a resource reservation setup protocol that 79 is based on ATM. 81 Incidentally, it is essential to examine billing based on business 82 administration issues, not technical ones. For example, on a 83 telephone service, it technically makes sense to charge the caller 84 when the user being called is on another line. This is because, 85 telephone switches were in operation when they notified the caller 86 that the number he called was busy. However, such a billing policy 87 is contrary to the customs of business. Readers should note that the 88 billing problems and solutions discussed in this document are not 89 only based on the technical viewpoint. 91 1.1 The Basis of the Tariff 93 Basic elements that determine the network tariff are distance, 94 bandwidth, time, and information volume. In many cases, the network 95 tariff reflects the link cost to some extent. 97 Note: In this document, distance means the distance between the 98 regions where users call from and to, not the actual length of the 99 physical links that connect users. In actual communication, a route 100 depends on network situations, so a charge based on the physical link 101 distance is inappropriate. 103 1.2 The Tariff in Telecommunication Services 105 Classifications of the basic styles of tariff systems in 106 telecommunication services and some examples are shown below. The 107 following classifications do not cover applied billing styles, for 108 example contents-based charging or premium charging such as the Dial 109 Q2 service of NTT, or the 900 telephone service. 111 o Flat-rate billing 113 - Leased line 114 In most cases, the tariff is based on distance and bandwidth. 116 - PVC-based frame relay and ATM 117 In most cases, the tariff is based on distance and bandwidth. 119 o Measured-rate billing 121 - Telephone 122 In most cases, the tariff is based on distance and time. 124 - Circuit switching 125 In most cases, the tariff is based on distance, bandwidth, and 126 time. 128 - SVC-based frame relay and ATM 129 In most cases, the tariff is based on distance, bandwidth, and 130 time, or information volume. 132 - X.25 packet switching 133 In most cases, the tariff is based on information volume. 135 Furthermore, measured rate billing is classified into calling- or 136 called-party billing. The basic charge style for telecommunication 137 service is calling-party billing. 139 o Calling-party billing 141 - Usual telephone service 143 o Called-party billing 145 - The Free Dial service of NTT and the 800 telephone service. 147 Basically, telecommunication service is designed for connection- 148 oriented, point-to-point, and bidirectional communication. In the 149 case of measured-rate billing, usually the calling or the called 150 party pays the bidirectional communication charge. In the case of 151 called-party billing, a function that allows incoming calls to be 152 accepted or refused based on the calling-party address, or a function 153 that restricts the calling-party addresses that are permitted to use 154 called-party billing, is indispensable. This is because, the 155 communication charge that a called party is willing to accept is 156 usually limited. 158 The current tendency in telecommunication-service tariff systems is 159 to change from measured-rate billing, which reflects link costs 160 accurately, to flat-rate billing, which simplifies the charging 161 system, and service tends to be provided by flat-rate billing inside 162 a single provider. The tariff for services between provider is 163 usually the sum of the individual providers charges. Flat-rate 164 billing, like that within a single provider, is not currently 165 realistic for services that cross providers. 167 1.3 Tariffs for Internet Service 169 Classifications of basic styles and examples of the tariff system for 170 Internet service are shown below. 172 o Flat-rate billing 174 - Internet access via leased line, PVC-based frame relay, or ATM 175 In most cases, the tariff is based on bandwidth. 177 o Measured-rate billing 179 - Dialup Internet access using a modem or N-ISDN 180 In most cases, the tariff is based on time. 182 - Internet access via leased line, PVC-based frame relay, or ATM 183 Some ISPs have adopted information-volume-based tariff systems. 185 Note: Dialup access charges in this document do not include the basic 186 telephone fee. 188 Until now, the tariff system for Internet access has mainly been 189 flat-rate billing, because measured-rate billing is technically 190 difficult to implement. However, the development of new multimedia 191 applications, such as voice, audio, picture, and video communication, 192 has caused the traffic over the Internet to increase explosively. 193 The cost of using the public network service is lower than when using 194 a private network system, if users can share equipment and lines. 195 However, if the traffic from all its users is at a steady high rate, 196 the cost advantage of the public network service is lost. Therefore, 197 Internet service tariff systems, although they use leased line 198 access, tend to adopt information-volume-based tariff systems. 200 2. Billing in the Resource Reservation Service 202 2.1 Problems of Billing in Internet Service 204 Basically, the tariff system for Internet service seems similar to 205 that for telecommunication service. However, note that the tariff 206 system for Internet service based on the access method from the user 207 site to the ISP, is not based on the end-to-end communication method. 208 The Internet is a connection less and unreliable communication, and 209 some users are beginning to use it for multicast communication. But, 210 the telecommunication is basically a connection-oriented, point-to- 211 point, and bidirectional form of communication, so telecommunication 212 and Intrenet communication are essentially different in some ways. 214 Current Internet service does not allow billing based on end-to-end 215 user site distance. This is because the structure of the IP address 216 is flat, rather than a layered structure that contains information 217 about the provider and region. So information about distance for 218 billing purpose cannot be obtained from the IP address directly. 220 Note: In this document, an address means an identifier, such as a 221 class A, B, or C IP address, that uniquely distinguishes an end 222 point. It does not means a group identifier such as a class D 223 address. 225 For Internet service, billing based on bandwidth can be provided, but 226 only for the line bandwidth between the user site and the ISP; it is 227 not based on the end-to-end user or application bandwidth, such as 228 the bandwidth in telecommunication services. 230 Current Internet service, except for the dialup access, does not 231 allow billing based on time because the IP is a connection less 232 communication, and timing information about the beginning and ending 233 of billing is too difficult to obtain. 235 Some current ISPs have adopted information-volume-based tariff 236 systems. However, this billing is based on the information volume of 237 IP packets that are sent to or received from the user site and the 238 ISP. Again, because the IP is a connection less and unreliable 239 communication, it is too difficult to provide billing based on the 240 information volume of IP packets that are actually used between end- 241 to-end users or applications. 243 It is not impossible to provide both user billing, and application 244 provider billing over the Internet when particular services are used. 245 These forms of billing are equivalent to calling- and called-party 246 billing in telecommunication service. However, obtaining the timing 247 information about the beginning and ending of application usage at 248 the IP layer is too difficult because the IP is a connection less 249 communication. To have billing based on usage time, the service 250 application responsible for the bill must identify the user and 251 monitor the usage. Also a billing process, where part of the billing 252 is transferred from the user to the service provider, must be 253 implemented. As a result, the billing system complexity is 254 increased. 256 2.2 Improved Billing Using the Resource Reservation Setup Protocol 258 As explained above, billing for current commercial Internet service 259 has many problems, but a resource reservation setup protocol may 260 solve these problems. 262 For example, the resource reservation setup protocol ensures the 263 availability of end-to-end network resources, so billing based on 264 bandwidth (FlowSpec) between user sites may be possible. Also, the 265 resource reservation setup protocol explicitly shows the resource 266 acquire and release timings, so billing based on time may be 267 feasible. 269 The resource reservation setup protocol also guarantees QoS based on 270 the FlowSpec, so billing based on the information volume that is 271 actually used between end-to-end users or applications may also be 272 feasible. Furthermore, there is a possibility that the billing for 273 each IP flow can be distributed to ether the sender or the receiver. 275 However, the resource reservation setup protocol cannot solve the 276 problem of how billing can be based on distance because the flat 277 structure of the IP address does not change and it is still 278 impossible to obtain information about distance for billing from the 279 IP address directly even when the resource reservation setup protocol 280 is used. 282 3. Model of a Commercial Resource Reservation Service 284 3.1 Technical Model of the Resource Reservation Service 286 This subsection looks at unreliable, unidirectional, and tree 287 structured multicast architecture as a technical model for a resource 288 reservation service. For the time being, the QoS to all receivers is 289 assumed to be the same. The following section examines heterogeneous 290 QoS and filter spec. 292 +---+ 293 | S | 294 +---+ 295 +-----------------/---\-----------------+ 296 | a / \ b | 297 | / \ | 298 | / ISP-A /\ | 299 | / / \ | 300 | / c / \ d | 301 +-----------/--------/------\-----------+ 302 +---+ +-------+ +---+ 303 |R1 | |router | |R2 | 304 +---+ +-------+ +---+ 305 +-----------------/---\-----------------+ 306 | e / \ f | 307 | / \ | 308 | / ISP-B /\ | 309 | / / \ | 310 | / g / \ h | 311 +-----------/--------/------\-----------+ 312 +---+ +---+ +---+ 313 |R3 | |R4 | |R5 | 314 +---+ +---+ +---+ 316 Fig. 3.1: Resource Reservation Service Model. 318 As shown in Fig. 3.1, ISP-A and ISP-B are interconnected, a sender S 319 and receivers R1 and R2 belong to ISP-A, and receivers R3, R4, and R5 320 belong to ISP-B. This subsection studies the receiver billing and 321 the sender billing resource reservation service with this model. 323 3.1.1 Receiver billing 325 When the resource reservation service is provided under receiver 326 billing, the problem is how to bill for the shared links, such as b, 327 c, and f. The shared link cost must be distributed and billed to 328 receivers based on some rule. 330 One solution inside a single ISP is to adopt a tariff system that 331 does not depend on how the links shared between receivers. Billing 332 that is based on the cost of the links that make up the multicast 333 tree is equivalent to billing based on distance. Therefore, billing 334 that does not depend on the link sharing approach is equivalent to 335 billing that is not based on distance. This means the billing can be 336 based on bandwidth (FlowSpec), time, and information volume. 338 For example, if an interconnected destination ISP is regarded as a 339 receiver, ISP-A bills to R1, R2 and ISP-B, and ISP-B bills to R3, R4, 340 and R5 [1]. The billing from ISP-A to ISP-B is distributed based on 341 some rule, and is added to the base charge in ISP-B. If a large 342 number of users join the multicast and the statistical tendency of 343 network utilization is known, it is possible to provide this type of 344 tariff system, although it does not accurately reflect communication 345 costs. 347 Another solution is to distribute the shared link cost among the 348 receivers that share the link. For example, the cost of link b would 349 be shared by R2, R3, R4 and R5. This method does reflect accurate 350 communication costs. However, in practice it is difficult to 351 implement the billing system since the complexity of computing the 352 cost of the shared link, located near a sender like b, is increased 353 because the receiver can dynamically join and leave the multicast 354 tree. 356 Therefore, in the case of receiver billing, if many users join the 357 multicast and the statistical tendency of network utilization is 358 known, billing based on bandwidth (FlowSpec), time, and information 359 volume can be provided. 361 3.1.2 Sender billing 363 When the resource reservation service is provided under the sender 364 billing, the problem due to the shared link is avoided, because there 365 is no need to distribute the shared link cost. In the above model, 366 the sender would be billed for the link costs from a to h. 368 Therefore, with sender billing, billing based on accurate link costs 369 can be provided. Billing based on the link cost is equivalent to 370 billing based on distance. However, information about distance for 371 billing cannot be obtained from the IP address directly. Therefore, 372 a database that can extract information about distance from the 373 destination IP address is needed to enable billing based on the link 374 cost. 376 This is also true for receiver billing: if a number of users join the 377 multicast and the statistical tendency of network utilization is 378 known, it is possible to provide billing based on bandwidth 379 (FlowSpec), time, and information volume. That is, the sender pays 380 for the billing to R1, R2, and ISP-B in ISP-A, and to R3, R4, and R5 381 in ISP-B. 383 Therefore, with sender billing, if a database is implemented that can 384 extract information about distance for billing from the destination 385 IP address, it will be possible to provide billing based on distance, 386 bandwidth (FlowSpec), time, and information volume. And if many 387 users join the multicast and the statistical tendency of network 388 utilization is known, it will also be possible to provide billing 389 based on bandwidth (FlowSpec), time, and information volume. 391 3.2 Application Model for the Resource Reservation Service 393 This subsection examines the following multimedia applications to 394 develop an application model for the resource reservation service. 396 o Broadcast-type application model 398 o Advertisement-type application model 400 o Conference-type application model 402 Methods of implementing the application model using the technical 403 model described in the previous subsection are also examined. 405 3.2.1 Broadcast-type application model 407 We assume that the broadcast-type application model has the following 408 features. 410 o The application provider broadcasts to receivers using the 411 multicast, and, in practice, the application is open to the public. 413 o Many receivers subscribe to the broadcast, and the statistical 414 tendency of network utilization is known. 416 o Joining the multicast tree is initiated from the receiver. 418 o The receiver pays the full amount billed. 420 o The billing is based on information volume or bandwidth (FlowSpec) 421 and time, and not on distance. 423 Features of this model correspond to receiver billing in the 424 technical model, so it is appropriate for this model to be supported 425 by it. Therefore, receiver billing based on bandwidth (FlowSpec) and 426 time, or information volume can be provided. 428 3.2.2 Advertisement-type application model 430 We assume that the advertisement-type application model has the 431 following features. 433 o The application provider advertises to receivers using the 434 multicast, and, in practice, the application is open to the public. 436 o Many receivers subscribe to the advertisement, and the statistical 437 tendency of network utilization is known. 439 o Joining the multicast tree is initiated from the receiver side. 441 o The application provider pays the full amount billed. 443 o A function that restricts the region in which the receiver is 444 permitted to join, or a function that decides whether to accept or 445 refuse the joining request based on the IP address of the receiver 446 or based on the tariff to be billed, is indispensable. This is 447 because the communication charge that is acceptable to an 448 application provider is usually limited. 450 Features of this model roughly correspond to sender billing in the 451 technical model, so it is appropriate for this model to be supported 452 by it. But this model needs a function that restricts the region in 453 which the receiver is permitted to join, or a function that decides 454 whether to accept or refuse the joining request based on the IP 455 address of the receiver or based on the tariff to be billed. 457 If the region that the receiver is permitted to join is simply 458 restricted by the ISP boundary, the model can be implemented by 459 restricting the IP flow forwarding between ISPs. 461 But if the decision to accept or refuse the joining request is based 462 on the IP address of the receiver or based on the tariff to be 463 billed, a database that can extract information about permission or 464 distance for billing from the destination IP address is needed. In 465 the resource reservation setup protocol, a procedure that supports 466 this kind of processing is also needed. 468 However, if this procedure is processed only by the sender, and the 469 number of receivers significantly increases, saturation of the sender 470 protocol processing may occur. Therefore, an intermediate node is 471 needed inside the multicast tree, and this intermediate node will 472 decide whether to accept or refuse the joining request. 474 Therefore, in the advertisement-type application model, if the region 475 that the receiver is permitted to join is simply restricted by the 476 ISP boundary, it is appropriate for this model to be supported by the 477 sender billing in the technical model. Thus, sender billing based on 478 bandwidth (FlowSpec) and time, or information volume, can be 479 provided. 481 If the decision to accept or refuse the joining request is based on 482 the IP address of the receiver or based on the tariff to be billed, 483 in addition to the sender billing in the technical model, a database, 484 that can extract information about permission or distance for billing 485 from the destination IP address is needed. In the resource 486 reservation setup protocol, a procedure that supports this process is 487 also needed. In this case, it can be provided by sender billing 488 based on distance, bandwidth (FlowSpec) and time, or information 489 volume. 491 3.2.3 Conference-type application model. 493 We assume that the conference-type application model has the 494 following features. 496 o The conference is held by a small number of participants. 498 o The statistical tendency of network utilization in the conference 499 depends on each conference style and the tendency is hard to 500 estimate. 502 o Joining the conference is initiated by each participant. That is 504 - Joining the multicast tree from an existing participant or 505 receiving information from the conference server is initiated by 506 the receiver. 508 - Construction of the multicast tree for existing participants or 509 information sent to the conference server is initiated by the 510 sender. 512 o Management of conference participants is indispensable. A function 513 that can decide to accept or refuse a participation request based 514 on the IP address of the potential participant, or a similar 515 function is needed. 517 To avoid establishing an unreasonably expensive tariff for short 518 distance communications, this model needs billing based on accurate 519 link costs, because the tendency of network utilization is hard to 520 estimate. 522 Therefore, in this model, in addition to the sender billing from the 523 technical model, a database that can extract information about 524 permission and distance for billing from the destination IP address 525 is needed. In the resource reservation setup protocol, a procedure 526 that supports this process is also needed. In this case, it can be 527 provided by sender billing based on distance, bandwidth (FlowSpec) 528 and time, or information volume. 530 3.3 Architecture of the Resource Reservation Setup Protocol 532 A combination of the billing side and the reserve initiating side in 533 the resource reservation setup protocol based on the above studies is 534 shown in Table 3.1. 536 Table 3.1: Combination of Billing and Reserve Initiating Sides. 538 +---------------+---------------+---------------+ 539 | Application | Billing Side |Initiating Side| 540 +===============+===============+===============+ 541 | Broadcast | Receiver | Receiver | 542 +---------------+---------------+---------------+ 543 | Advertisement | Sender | Receiver | 544 +---------------+---------------+---------------+ 545 | Conference | Sender |Sender,Receiver| 546 +---------------+---------------+---------------+ 548 In addition to supporting all combinations of the billing side and 549 the reserve initiating side shown above, the commercial resource 550 reservation service must satisfy the following requirements for 551 sender billing. 553 o A function is needed that restricts the region that a receiver is 554 permitted to join, or that decides whether to accept or refuse the 555 joining request based on the receiver IP address and/or on the 556 tariff to be billed. 558 o If the application is open to the public, an intermediate node that 559 decides whether to accept or refuse the joining request is needed 560 inside the multicast tree. 562 A resource reservation setup protocol that satisfies these 563 requirements can be achieved with the following sender initiation 564 architecture. 566 o The basis of the resource reservation setup protocol is sender 567 initiation. That is, as shown in Fig. 3.2, the sender explicitly 568 designates the receiver address, sends a resource reservation setup 569 message (SETUP), and constructs the multicast tree. 571 +---+ 572 +--------| S |--------+ 573 | +---+ | 574 +--------|--------/-|-\--------|--------+ 575 | | / | \ | | 576 | | / | \ | | 577 | SETUP / SETUP /\ SETUP | 578 | | / | / \ | | 579 | | / | / \ | | 580 +--------|--/------ | ------\--|--------+ 581 +-V-+ +---V---+ +-V-+ 582 |R1 | | | |R2 | 583 +---+ |router | +---+ 584 +------| |------+ 585 | +-------+ | 586 +--------|--------/-|-\--------|--------+ 587 | | / | \ | | 588 | | / | \ | | 589 | SETUP / SETUP /\ SETUP | 590 | | / | / \ | | 591 | | / | / \ | | 592 +--------|--/------ | ------\--|--------+ 593 +-V-+ +-V-+ +-V-+ 594 |R3 | |R4 | |R5 | 595 +---+ +---+ +---+ 597 Fig. 3.2: Sender Initiation. 599 o In the case of receiver initiation, as shown in Fig. 3.3, the 600 receiver explicitly sends the joining request message (JOIN), and 601 if the sender accepts it, the sender sends a resource reservation 602 setup message to the receiver. 604 +---+ 605 | S | 606 +A--+ 607 +-----------------/|-|\-----------------+ 608 | / | | \ | 609 | / | | \ | 610 | JOIN| |SETUP | 611 | / | | / \ | 612 | / | |/ \ | 613 +-----------/------|-|------\-----------+ 614 +---+ +----V--+ +---+ 615 |R1 | | | |R2 | 616 +---+ |router | +---+ 617 +-------> | 618 | +---- +-------+ 619 +-------|-|-------/---\-----------------+ 620 | | | / \ | 621 | | | / \ | 622 | JOIN| |SETUP /\ | 623 | | | / / \ | 624 | | | / / \ | 625 +-------|-|-/--------/------\-----------+ 626 +--V+ +---+ +---+ 627 |R3 | |R4 | |R5 | 628 +---+ +---+ +---+ 630 Fig. 3.3: Receiver Initiation. 632 o However, if the application is open to the public, as shown in Fig. 633 3.4, the intermediate node inside the multicast tree that decides 634 whether to accept or refuse the joining request, may send a 635 resource reservation setup message as a response to the joining 636 request message. 638 +---+ 639 | S | 640 +---+ 641 +-----------------/---\-----------------+ 642 | / \ | 643 | / \ | 644 | / /\ | 645 | / / \ | 646 | / / \ | 647 +-----------/--------/------\-----------+ 648 +---+ +-------+ +---+ 649 |R1 | | | |R2 | 650 +---+ | node | +---+ 651 +-------> | 652 | +---- +-------+ 653 +-------|-|-------/---\-----------------+ 654 | | | / \ | 655 | | | / \ | 656 | JOIN| |SETUP /\ | 657 | | | / / \ | 658 | | | / / \ | 659 +-------|-|-/--------/------\-----------+ 660 +--V+ +---+ +---+ 661 |R3 | |R4 | |R5 | 662 +---+ +---+ +---+ 664 Fig. 3.4: Intermediate Node. 666 4. Implementation Method of the Resource Reservation Setup Protocol 668 4.1 Datalink Media for the Commercial Resource Reservation Service 670 The resource reservation setup protocol can designate the end-to-end 671 resource to be reserved, but the datalink layer actually has 672 responsibility for reservation and QoS control. Current datalink 673 media that can control QoS are ATM, PPP over SDH/SONET with packet 674 scheduler, serial line with packet scheduler, IEEE 802.9 isoEthernet, 675 IEEE 802.12 100VG-Any LAN, and Ethernet/Token Ring with IEEE 802.1p. 676 The I/O channel media are IEEE 1394 and Universal Serial Bus. Inside 677 the user site, these media may be used. 679 However, every node in the commercial resource reservation service 680 backbone will have to handle between 1,000 and 10,000 IP flows 681 initiated by users. To handle such a large volume of IP flow, the IP 682 flow must be processed by hardware on a high-speed line interface 683 such as SDH/SONET. 685 The SDH/SONET hierarchy is defined as being a four times rate, 155M, 686 622M, 2.4G, and 10G bps. However, in an actual network, there is a 687 strong possibility that a 622 Mbps line cannot handle all of the 688 traffic, but there is no demand for a 2.4 Gbps line speed. In the 689 commercial WAN environment, the intermediate-speed link, which is not 690 supported by SDH/SONET, is provided by the ATM connection on the 691 SDH/SONET. So, the use of ATM enables economical networks that can 692 meet the traffic demand. After all, if, and only if, PPP over 693 SDH/SONET is implemented by hardware, there is a possibility that 694 speeds equivalent to ATM speeds can be attained over SDH/SONET, but 695 economically this is entirely inappropriate for commercial network 696 service. 698 If SVC ATM is used as the datalink media of the resource reservation 699 service, it may be possible to solve the problem that prevents 700 billing based on distance without needing a database, that can 701 extract information about distance for billing from the destination 702 IP address. In this case, the E.164/NSAP, which are layered 703 structure addresses and which contain information about provider and 704 region, can be used. 706 Therefore, ATM is an indispensable implementation technology for the 707 commercial resource reservation service, and there is no room for any 708 other selection. The remainder of this section examines an 709 implementation method of the resource reservation setup protocol 710 based on ATM. 712 4.2 Mapping of ATM VC and IP Flow 714 An IP flow and an ATM VC must be mapped one-to-one, and must not 715 aggregate multiple IP flows to single ATM VC, because ATM itself has 716 the traffic control function. It is only wasteful to control both 717 the ATM-layer and the IP-layer traffic, and has no effect other than 718 to raise equipment cost and increase processing overhead. 720 An IP flow also must not be divided among multiple ATM VCs. 721 Synchronization between multiple ATM VCs to the same destination is 722 not guaranteed. Therefore, synchronized information would be needed 723 between ATM VCs, and this causes unnecessary overhead, decreases the 724 reliability of the IP flow, and wastes network resources. 726 4.3 Dynamic QoS Changes 728 The need to change QoS in an ATM system is a serious problem. Part 729 of the ITU-T SCS2 signaling protocol, Q.2963.1 specifies a procedure 730 to change the peak rate, but this is not sufficient as a procedure to 731 change QoS. Also, signaling procedures in ATM Forum UNI 3.1/4.0 do 732 not support QoS changes. ITU-T traffic control recommendation I.371 733 and ATM Forum UNI 3.1/4.0 do not specify traffic behavior during QoS 734 changing. The only possibility is ABT, which is defined in I.371 and 735 supports QoS changes initiated by F5 OAM. Unfortunately, the current 736 ABT supports point-to-point connection only. 738 Therefore, current ATM standards cannot support QoS changes in 739 practice. There is a possibility that QoS changes can be supported 740 in the resource reservation service by releasing old ATM connections 741 and establishing new ones, but this method causes the following 742 problems. 744 o Network overload may be caused by call processing. 746 o Since call processing is closely related to ATM billing, the 747 billing system complexity is increased. 749 o New calls are not always successfully established. 751 It is also feasible to establish new ATM connections and then release 752 old ones, but this method causes the following problems. 754 o The current ATM NIC for WS/PC does not support a large number of 755 QoS VCs. 757 o Although it is only temporary, old and new VCs exist 758 simultaneously, which increases the complexity of the billing 759 system. 761 o New calls are not always successfully established. Especially, 762 there is a possibility that only part of point-to-multipoint call 763 will be reestablished successfully. This increases the complexity 764 of exception processing. 766 Therefore, QoS changes by signaling are impractical under current ATM 767 standards, but should be supported after ATM standards specify it. 768 ITU-T SG11 and SG13 and ATM Forum SIG SWG and TM SWG should specify a 769 procedure for dynamic QoS changes and traffic behavior during QoS 770 changing. Additional research on point-to-multipoint ABT is also 771 needed. 773 4.4 Heterogeneous QoS 775 Heterogeneous QoS, which not always the same at each receivers, is 776 not supported by ATM point-to-multipoint connection. Originally, the 777 concept of heterogeneous QoS was introduced to support hierarchical 778 coded IP flow. But as described in [6], it should be supported by a 779 presentation layer, and it is not responsible for the network and 780 transport layers. In single-node operation, IP packet discarding 781 based on contents is needed to support an IP flow that has 782 heterogeneous QoS. But the network and transport layer cannot 783 support such processing. 785 When multiple receivers require different QoS, it does not make sense 786 to establish a point-to-multipoint VC based on the largest QoS 787 request. 789 However a point-to-multipoint VC is established based on the maximum 790 QoS, when a receiver that requests a larger QoS joins the multicast 791 tree, or when the receiver that requested the largest QoS leaves the 792 tree, and the QoS of the VC must be changed. However, current ATM 793 standards cannot support such QoS changes. 795 Also it does not have any advantage in terms of the tariff. The 796 billing for a resource reservation service may be based on the QoS 797 acquired in the ATM layer, which may be larger than the QoS requested 798 in the IP layer. Therefore, to use the QoS from the ATM layer is 799 obviously better for the IP flow. 801 As explained above, current ATM standards cannot support 802 heterogeneous QoS, and it does not offer any advantage in terms of 803 tariff. 805 4.5 Filter Spec 807 ATM does not support a function, that merges information from various 808 VCs, such as filter spec. It should also be supported by a 809 presentation layer, and is not responsible for the network and 810 transport layers. 812 5. Conclusions 814 This document clarified the followings in terms of an architecture 815 for the resource reservation setup protocol. 817 o The basis of the resource reservation setup protocol is sender 818 initiation. That is, the sender explicitly designates the receiver 819 address, sends a resource reservation setup message and constructs 820 a multicast tree. 822 o In the case of receiver initiation, the receiver explicitly sends a 823 joining request message; if the sender accepts it, the sender sends 824 a resource reservation setup message to the receiver. 826 o However, if the application is open to the public, an intermediate 827 node inside the multicast tree decides whether to accept or refuse 828 the joining request, and may send a resource reservation setup 829 message as a response to the joining request message. 831 ATM is an indispensable implementation technology for the commercial 832 resource reservation service, and the following were clarified in 833 terms of an implementation method of the resource reservation setup 834 protocol based on ATM. 836 o An IP flow and an ATM VC must be mapped one-to-one. 838 o In practice, current ATM standards cannot support dynamic QoS 839 changes. Such changes should be supported after the ATM standard 840 specifies it. 842 o Current ATM standards cannot support heterogeneous QoS, which also 843 does not have any advantage in terms of tariff. The hierarchical 844 coded IP flow should be supported by the presentation layer. 846 o Filter spec should be supported by the presentation layer. 848 Finally, if the billing policies of ISPs are fundamentally different 849 from each other in the commercial resource reservation service, it 850 will be difficult to achieve smooth interconnection. Therefore, the 851 author believes that ISPs need to conclude agreements or to clarify 852 recommendations concerning minimum common billing policies for the 853 resource reservation service, especially on the definition of 854 distance for billing purpose. 856 6. Security Considerations 858 Security considerations are not discussed in this document. 860 References 862 [1] S. Herzog, "Accounting and Access Control Policies for 863 Resource Reservation Protocols," Internet Draft, June 1996, 864 . 866 [2] R. Braden Ed., "Resource ReSerVation Protocol (RSVP)-Version 1 867 Functional Specification," Internet Draft, October 1996, . 870 [3] L. Delgrossi and L. Berger, Ed., "Internet Stream Protocol 871 Version 2 (ST2) Protocol Specification - Version ST2+," RFC 1819, 872 August 1995. 874 [4] S. Berson and L. Berger, "IP Integrated Services with RSVP 875 over ATM," Internet Draft, September 1996, . 878 [5] M. Borden and M. Garrett, "Interoperation of Controlled-Load 879 and Guaranteed-Service with ATM," Internet Draft, September 1996, 880 . 882 [6] K. Sebayashi and H. Uose, "ATM Multicast Communications Method 883 with Receiver-initiated QoS Guarantee," Global Information 884 Infrastructure Evolution, ISBN 90-5199-290-4, IOS Press, 1996. 886 Acknowledgments 888 This document is based on my discussions with many colleagues at 889 NTT. I would like to specially thank Hiroshi Ishikawa, Sadahiko 890 Kanou, Masaru Nishi, Satoshi Takamatsu, and Hideaki Arai of the 891 NTT Network Strategy Planning Dept., and also Hisao Uose of the 892 NTT Multimedia Networks Labs. for their valuable comments. 894 Also section 4 of this document is based on various discussions 895 during NTT Multimedia Joint Project with NACSIS. I would like to 896 thank Prof. Shoichiro Asano of National Center for Science 897 Information Systems for his invaluable advice in this area. 899 Author's Address 901 Muneyoshi Suzuki 902 NTT Multimedia Networks Laboratories 903 3-9-11, Midori-cho 904 Musashino-shi, Tokyo 180, Japan 906 Phone: +81-422-59-2119 907 Fax: +81-422-59-3203 908 EMail: suzuki@nal.ecl.net