idnits 2.17.1 draft-ietf-mboned-maccnt-req-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2010) is 4988 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2975' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 673, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-09 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned T. Hayashi, 3 Internet-Draft H. Satou, 4 Intended status: Informational H. Ohta 5 Expires: February 25, 2011 NTT 6 H.He 7 Nortel 8 S. Vaidya 9 Cisco Systems, Inc. 10 August 24, 2010 12 Requirements for Multicast AAA coordinated between Content Provider(s) 13 and Network Service Provider(s) 14 draft-ietf-mboned-maccnt-req-10 16 Abstract 18 This memo presents requirements in the area of accounting and access 19 control for IP multicasting. The scope of the requirements is 20 limited to cases where Authentication, Accounting and Authorization 21 (AAA) functions are coordinated between Content Provider(s) and 22 Network Service Provider(s). 24 In order to describe the new requirements of a multi-entity Content 25 Deliver System(CDS) using multicast, the memo presents three basic 26 business models: 1) the Content Provider and the Network Provider are 27 the same entity, 2) the Content Provider(s) and the Network 28 Provider(s) are separate entities and users are not directly billed, 29 and 3) the Content Provider(s) and the Network Provider(s) are 30 separate entities and users are billed based on content consumption 31 or subscriptions. The requirements of these three models are listed 32 and evaluated as to which aspects are already supported by existing 33 technologies and which aspects are not. 35 General requirements for accounting and admission control 36 capabilities including quality-of-service (QoS) related issues are 37 listed and the constituent logical functional components are 38 presented. 40 This memo assumes that the capabilities can be realized by 41 integrating AAA functionalities with a multicast CDS system, with 42 IGMP/MLD at the edge of the network. 44 Status of this Memo 45 This Internet-Draft is submitted to IETF in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt. 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html. 64 This Internet-Draft will expire on February 25, 2011. 66 1. Introduction 68 Broadband access networks such as ADSL (Asymmetric Digital Subscriber 69 Line) or FTTH (Fiber to the Home) have been deployed widely in recent 70 years. Content Delivery Service (CDS) is expected to be a major 71 application provided through broadband access networks. Because many 72 services such as television broadcasting require huge bandwidth 73 (e.g., 6Mbit/s) and processing power at the content server(s), IP 74 multicast is used as an efficient delivery mechanism for CDS. 76 A single entity may design and be responsible for a system that 77 covers the various common high-level requirements of a multicasting 78 CDS such as 1) content serving, 2) the infrastructure to multicast 79 it, 3) network and content access control mechanisms. For cases in 80 which the business model includes the direct billing of users, the 81 single provider of both content and network services has sufficient 82 data in its control to bill users based on their content consumption. 83 Furthermore it is possible to tie access to the network and QoS based 84 on a user's contract status. Therefore current technologies support 85 the single entity case. 87 Often, however, the content provision and network provision roles are 88 split between separate entities. Commonly, Content Providers (CP) do 89 not build and maintain their own multicast network infrastructure as 90 this is not their primary business area. Instead, CPs often purchase 91 transport and management services from network service providers. 92 This memo lists the requirements of a business model in which the NSP 93 provides CDS using multicast as one such contractible service. 95 The direct revenue source for the multiple entity provider is a 96 defining aspect of the business model which often has implications on 97 requirements for the technologies that support the system. There are 98 cases such as the the advertising-based model where billing end-users 99 is not done and therefore accounting of content consumption can be 100 anonymous and/or in aggegrate. In these cases the requirements of 101 the business model for accounting for billing purposes are already 102 supported by existing technologies. However, the NSP can not 103 guarantee high quality transmission on a per-content basis with 104 existing technologies. 106 There is also the business model in which the individual user of 107 multicasted contents is the source of revenue for both consumed 108 content and network resources. In this model the NSP wants to 109 receive the appropriate fees for multicast services and the NSP 110 undertakes collecting bills as a proxy for the CPs. The NSP may 111 provide high quality service by admission control. Current standards 112 do not fully support this model and this memo will list the 113 requirements which need to be supported. 115 2. Definitions and Abbreviations 117 2.1. Definitions 119 Authentication: action for identifying a user as a genuine one. 121 Authorization: action for giving permission for a user to access 122 content or the network. 124 Eligible user: Users may be eligible (permitted) to access 125 resources because of the attributes they have (e.g., delivery may 126 require possession of the correct password or digital 127 certificate), their equipment has (e.g., content may only be 128 eligible to players that can decode H.264 or 3GPP streams), their 129 access network has (e.g., HDTV content may only be eligible to 130 users with 10 Mbps or faster access line), or because of where 131 they are in network topology (e.g., HDTV content may not be 132 eligible for users across congested links) or in actual geography 133 (e.g., content may only be licensed for distribution to certain 134 countries), and, of course, a mix of attributes may be required 135 for eligibility or ineligibility. 137 User: In this document user refers to a requester and a recipient 138 of multicast data, termed a viewer in CDS. 140 User-based accounting: actions for grasping each user's behavior, 141 when she/he starts/stops to receive a channel, which channel 142 she/he receives, etc. 144 2.2. Abbreviations 146 AAA: Authentication, Accounting and Authorization 148 ASM: Any-Source Multicast 150 CDS: Content Delivery Service 152 CP: Content Provider 154 IGMP: Internet Group Management Protocol 156 MLD: Multicast Listener Discovery 158 NSP: Network Service Provider 160 SSM: Source Specific Multicast 162 QoS: Quality of Service 164 3. Current Business Models 166 3.1. Single entity model where CP and NSP are the same entity 168 One existing business model is that of a single entity responsible 169 for both content and network service provision which bills its users 170 based on content provision. (See figure below.) 171 +-----------------------------------------------------+ 172 | +---------+ | 173 | | Content | | 174 | | Server | | 175 | +----+----+ | 176 | | | 177 | CP+NSP +-------+-------+ | 178 | | Provider Edge | | 179 | +-------+-------+ | 180 | | | 181 | | | 182 | +-------------+ | 183 | | User Edge | | 184 | +--+---+---+--+ | 185 | / | \ | 186 +----------- / --- | --- \ ---------------------------+ 187 / | \ 188 / | \ <- user/network interface 189 / | \ 190 +---------++ +-----+----+ ++---------+ 191 |Client #A | |Client #B | |Client #C | 192 +----------+ +----------+ +----------+ 193 User A User B User C 195 Example of CDS network configuration 197 Figure 1 199 In this model the network can query a content-policy-enabled AAA 200 server within its own domain at the time a user requests content. 201 The network can provide the AAA server with information such as user 202 identity, device identity, the requested content (channel), 203 geographic information, method of network connection, etc. that might 204 be required for the content provision authorization decision. It is 205 therefore possible to configure a network to deny network access 206 based on the content policy decision. 208 In this model there are no issues of mapping user identities between 209 different entity domains. The provider has access to the information 210 on which user accessed from which point on what device. Furthermore 211 as network provider they can record not only when a user joined or 212 left a certain channel, but also if packets were actually delivered. 213 Moreover, there are no inter-entity security and privacy concerns 214 between the CP and NSP. 216 The single entity network service and content provider also knows the 217 content schedules for various channels. This is important not only 218 for time and content-sensitive authorization decisions but also for 219 providing meaningful billing details to end users. 221 3.2. Multiple entity model without direct content-based billing 223 An additional model for delivering contents over a CDS is the 224 advertising-based model where billing end-users is not done. In this 225 model the four different roles may be filled by separate entities: 226 Content Provider (CP), Network Service Provider (NSP), user clients, 227 and advertising sponsors. In the general case of this business 228 model, insofar as the advertiser does not require user-based metrics 229 the accounting of content consumption can be anonymous and/or in 230 aggregrate and can be off-line from the multicast-with-AAA CDS system 231 itself. Therefore this model does not require any new standards to 232 provide user-based accounting for a multi-entity CDS using multicast 233 with AAA. (Providing this data in near real-time and inline would 234 entail further requirements which can be dealt with in a separate 235 memo if necessary.) 237 A more complex version of this business model is conceivable in which 238 a CP may require a user to enter into a subscription contract, even 239 when the user does not get billed for content consumption. For 240 example, a CP may value individual data because it allows it to 241 supply the advertisers with rich, user-segmented data and charge a 242 higher premium. In that case the requirements of the next section 243 "CDS with direct billing of the end user" are generally applicable 244 because of the need to link the user data which the CP has to the 245 actual viewing (or stream downloading) data that the NSP has. 247 4. Proposed Model: Multity-entity CDS 249 In this model the networks for CDS contain three different types of 250 entities: Content Provider (CP), Network Service Provider (NSP), and 251 user clients. An NSP owns the network resources (infrastructure). 252 It accommodates content providers on one side and accommodates user 253 clients on the other side. NSP provides the network for CDS to two 254 entities (i.e., CPs and user clients). A CP provides content to each 255 user through the network of NSPs and charges users for content. NSPs 256 are responsible for delivering the content to user clients, and for 257 controlling the network resources. A NSP charges a user or a CP for 258 network usage. A NSP may charge users for content as a proxy of the 259 CP. 261 +-------------+ +-------------+ +-------------+ 262 | CP | | CP | | CP | 263 | #1 | | #2 | | #3 | 264 | +---------+ | | +---------+ | | +---------+ | 265 | | Content | | | | Content | | | | Content | | 266 | | Server | | | | Server | | | | Server | | 267 | +-------+-+ | | +----+----+ | | +-+-------+ | 268 +----------\--+ +------|------+ +--/----------+ 269 \ | / 270 \ | / <- network/network 271 \ | / interface 272 +------------- \ ------ | ------ / ----+ 273 | \ | / | 274 | NSP +-+-----+-----+-+ | 275 | | Provider Edge | | 276 | +-------+-------+ | 277 | | | 278 | | | 279 | +--+------+---+ | 280 | | User Edge | | 281 | +--+---+---+--+ | 282 | / | \ | 283 +------------- / --- | --- \ ----------+ 284 / | \ 285 / | \ <- user/network interface 286 / | \ 287 +---------++ +-----+----+ ++---------+ 288 |Client #A | |Client #B | |client #C | 289 +----------+ +----------+ +----------+ 290 User A User B User C 292 Example of CDS network configuration 294 Figure 2 296 The CP provides detailed channel information (e.g., Time table of 297 each channel) to the information server which is either managed by 298 the NSP or CP. An end-user client gets the information from the 299 information server. In this model, multicasting is used in the NSP's 300 CDS network, and there are two different contracts. One is the 301 contract between the NSP and the user which permits the user to 302 access the basic network resources of the NSP. Another contract is 303 between the CP and user to permit the user to subscribe to multicast 304 content. Because the CP and NSP are different entities, and the NSP 305 generally does not allow a CP to control (operate) the network 306 resources of the NSP, user authorization needs to be done by the CP 307 and NSP independently. Since there is no direct connection to the 308 user/network interface, the CP cannot control the user/network 309 interface. A user may want to move to another place, or may want to 310 change her/his device (client) any time without interrupting her/his 311 reception of services. 313 4.1. Information Required by Entities to Support the Proposed Business 314 Model 316 User identification and Authentication: 318 The network should be able to identify and authenticate each user 319 when they attempt to access the service requesting content. This 320 user identification is required for: 322 authorization for content consumption eligibility 324 user tracking for billing based on actual content consumption 325 and network resource usage 327 With current protocols (IGMP/MLD), the sender cannot distinguish 328 which receivers (end hosts) are actually receiving the 329 information. The sender must rely on the information from the 330 multicasting routers. This can be complicated if the sender and 331 routers are maintained by different entities. Furthermore, the 332 current user associated with receiver must be identified. 334 User Authorization: 336 The network, at its option, should be able to authorize a user's 337 access to content or a multicast group, so as to meet any demands 338 by a CP to prevent content access by ineligible users. 340 Sharing Programming data: 342 NSP needs a mechanism to receive channel programming data from the 343 CP in order to provide the information to the user at channel 344 selection time and also for somehow logging or recording what 345 programming content has been streamed to the user. In some cases 346 the CP may contract the NSP to bill the user as a proxy for the 347 CP. In this case there needs to be a mechanism for supplying the 348 user-based viewing history with human-meaningful channel data to 349 the end-user. 351 Content usage information by user: 353 For billing and auditing purposes the CP needs the NSP to provide 354 it with detailed per-user usage behavior indicating what content 355 was consumed from when to when. There needs to be a mechanism to 356 supply the user-based viewing history from the NSP to the CP. If 357 the CP is selling on an on-demand model, or tiered subscription 358 basis or supplies some sort of online account statement this 359 history needs to be fed back to the CP in near real-time. To 360 assemble such data on user behavior, it is necessary to precisely 361 log information such as who (host/user) is accessing what content 362 at what time (join action) until what time (leave action). The 363 result of the access-control decision (e.g. results of 364 authorization) would also be valuable information. The desired 365 degree of logging precisions would depend on the application used. 367 Notification to Users of the Result of the Join Request: 369 It should be possible to provide information to the user about the 370 status of his/her join request(granted/denied/other). Such 371 information can be used to give meaningful feedback to the user. 373 5. Admission Control for Multicasting 375 In order to guarantee certain QoS it is important for network 376 providers (at their option) to be able to protect their network 377 resources from being wasted, (either maliciously or accidentally). 378 The NSP should be able to apply appropriate access controlling 379 actions based on user eligibility status: 381 The network should be able to apply necessary access controlling 382 actions when an eligible user requests an action (such as a join 383 or a leave.) 385 The network should be able to reject any action requested from an 386 ineligible user. 388 In order to maintain a predefined QoS level, depending on the NSP's 389 policy, a user edge should be able to control the number of streams 390 it serves to a user, and total bandwidth consumed to that user. For 391 example if the number of streams being served to a certain user has 392 reached the limit defined by the NSP's policy, then the user edge 393 should not accept a subsequent "join" until one of the existing 394 streams is terminated. Similarly, if the NSP is controlling by per- 395 user bandwidth consumption, then a subsequent "join" should not be 396 accepted if delivery of the requested stream would push the consumed 397 bandwidth over the NSP policy-defined limit. 399 The network may need to control the combined bandwidth for all 400 channels at the physical port of the edge router or switch so that 401 these given physical entities are not overflowed with traffic. This 402 entails being able to control the number of channels delivered, the 403 bandwidth for each channel and the combined bandwidth for all 404 channels. 406 6. Reauthorization/ deauthorization requirements 408 A mechanism for periodic reauthorization of users who have already 409 joined a channel stream should be supported. The reauthorization 410 could be an authorization check based on the NSP's eligibility 411 requirements and/or could involve the NSP querying the CP for 412 reauthorization of a user. 414 A mechanism for deauthorization should be supported for cases in 415 which a user is deemed ineligible by the NSP and/or CP at the time of 416 a reauthorization check. If a NSP revokes authorization for the 417 network for a user it should force a leave, and record details of the 418 leave (including the time and reason for the forced leave.) If a CP 419 revokes authorization to content for a user the CP signals to the NSP 420 to cease streaming to that user. An example usage case for 421 deauthorizing a user is one where a user has a subscription or has 422 paid for a certain amount of content and has reached that limit. In 423 some models, it is conceivable that a CP could communicate the 424 parameters for de-authorization to the NSP at the time of the 425 original join's authorization so as to make NSP->CP reauthorization 426 requests unnecessary. 428 7. Performance requirements 430 Channel Join Latency and Leave Latency 432 Commercial implementations of IP multicasting are likely to have 433 strict requirements in terms of user experience. Join latency is the 434 time between when a user sends a "join" request and when the 435 requested data streaming first reaches the user. Leave latency is 436 the time between when a user sends a "leave" signal and when the 437 network stops streaming to the user. Leave and Join latencies impact 438 the acceptable user experience for fast channel surfing. In an IP-TV 439 application, users are not going to be receptive to a slow response 440 time when changing channels. If there are policies for controlling 441 the number of simultaneous streams a user may access then channel 442 surfing will be determined by the join and leave latencies. 443 Furthermore, leave affects resource consumption: with a low "leave 444 latency" network providers could minimize streaming content when 445 there are no audiences. It is important that any overhead for 446 authentication, authorization, and access-control be minimized at the 447 times of joining and leaving multicast channels so as to achieve join 448 and leave latencies acceptable in terms of user experience. For 449 example this is important in an IP-TV application, because users are 450 not going to be receptive to a slow response time when changing 451 channels. 453 8. Concomitant requirements 455 Scalability 457 Solutions that are used for AAA and QoS enabled IP multicasting 458 should scale enough to support the needs of content providers and 459 network operators. NSP's multicast access and QoS policies should be 460 manageable for large scale users. (e.g. millions of users, thousands 461 of edge-routers) 463 Service and Terminal Portability: 465 Depending on the service, networks should allow for a user to receive 466 a service from different places and/or with a different terminal 467 device. 469 Deployable as Alternative to Unicast 471 IP Multicasting would ideally be available as an alternative to IP 472 unicasting when the "on-demand" nature of unicasting is not required. 473 Therefore interfaces to multicasting should allow for easy 474 integration into CDS systems that support unicasting. Especially 475 equivalent interfaces for authorization, access control and 476 accounting capabilities should be provided. 478 Support of ASM and SSM 480 Both ASM (G), and SSM (S,G) should be supported as multicast models. 482 Support for Tunneled Multicast 484 The AAA requirements specified in this document should apply to both 485 end-to-end native multicast and to tunnel-enabled multicast, such as 486 AMT multicast: [I-D.ietf-mboned-auto-multicast] 488 Small Impact on the Existing Products 490 Impact on the existing products (e.g., protocols, software, etc.) 491 should be as minimal as possible. Ideally the NSP should be able to 492 use the same infrastructure (such as access control) to support 493 commercial multicast services for the so called "triple play" 494 services: voice (VoIP), video, and broadband Internet access 495 services. When a CP requires the NSP to provide a level of QoS 496 surpassing "best effort" delivery or to provide special services 497 (e.g., to limited users with specific attributes), certain parameters 498 of the CDS may be defined by a contractual relation between the NSP 499 and the CP. However, just as for best-effort unicast, multicast 500 allows for content sourced by CPs without a contractual relation with 501 the NSP. Therefore, solutions addressing the requirements defined in 502 this memo should not make obsolete multicasting that does not include 503 AAA features. NSPs may offer tiered services, with higher QOS, 504 accounting, authentication, etc., depending on contractual relation 505 with the CPs. It is therefore important that Multicast AAA and QoS 506 functions be as modular and flexible as possible. 508 Multicast Replication 510 The above requirements should also apply if multicast replication is 511 being done on an access-node (e.g. DSLAMs or OLTs). 513 9. Constituent Logical Functional Components 515 Below is a diagram of a AAA enabled multicasting network, including 516 the logical components within the various entities. 518 +-------------------------------+ 519 | user | 520 |+- - - - - - - - - - - - - - -+| 521 || CPE || 522 || || 523 |+- - - - - | - - - - - - - - -+| 524 +-----------|-------------------+ 525 | 526 -------|------ IFa 527 | 528 +-----------|-----------------------+ 529 | NSP | | 530 | | | 531 |+- - - - - |- - _+ + - - - - - + | 532 || | | | | | | 533 | +------|-+ | +--------+ | 534 || | AN | | | | | MACF || | 535 | | | | | | | 536 || +------|-+ | | | +---|----+| | 537 | | | | | | 538 | | | | IFd----- | | 539 | | | IFb | | | 540 || +------|---+ | | | +---|----+| | 541 | | |---|---| mAAA | | 542 || | NAS | | | | |(MACF *)|| | * optional 543 | +----------+ | +--------+ | 544 ||+- - - - - - - -+ - - |- - - - -+ | 545 +-----------------------|-----------+ 546 | 547 -------|------ IFc 548 | 549 +-----------------------|-------+ 550 | CP +---------+ | 551 | | CP-AAA | | 552 | +---------+ | 553 +-------------------------------+ 555 AAA enabled multicasting network with admission control 557 Figure 3 559 The user entity includes the CPE (Customer Premise Equipment) which 560 connects the receiver (s). 562 The NSP (Network Service Provider) includes the transport system and 563 a logical element for multicast AAA functionality. The TS (transport 564 system) is comprised of the access node and NAS (Network Access 565 Server) An AN (Access Node) may be connected directly to mAAA or a 566 NAS relays AAA information between an AN and a mAAA. Descriptions of 567 AN and its interfaces are out of the scope for this memo. The 568 multicast AAA function may be provided by a mAAA which may include 569 the function that downloads Join access control lists to the NAS 570 (this function is referred to as the conditional access policy 571 control function.) 573 Interface between mAAA and NAS 575 The interface between mAAA and the NAS is labeled IFb in Figure 3. 576 Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA 577 replies. The mAAA may push conditional access policy to the NAS. 579 CP-AAA 581 The content provider may have its own AAA server which has the 582 authority over access policy for its contents. 584 Interface between user and NSP 586 The interface between the user and the NSP is labeled IFa in Figure 587 3. Over IFa the user makes a multicasting request to the NSP. The 588 NSP may in return forward multicast traffic depending on the NSP and 589 CP's policy decisions. 591 Interface between NSP and CP 593 The interface between the NSP and CP is labeled IFc. Over IFc the 594 NSP requests to the CP-AAA for access to contents and the CP replies. 595 CP may also send conditional access policy over this interface for 596 AAA-proxying. 598 The NSP may also include a component that provides network resource 599 management (e.g. QoS management), as described in section 5, 600 "Admission Control for Multicasting". Resource management and 601 admission control is provided by MACF (Multicast Admission Control 602 Function). This means that, before replying to the user's multicast 603 request, the mAAA queries the MACF for a network resource access 604 decision over the interface IFd. The MACF is responsible for 605 allocating network resources for forwarding multicast traffic. MACF 606 also receives Leave information from NAS so that MACF releases 607 corresponding reserved resources. 609 10. Acknowledgments 611 The authors of this draft would like to express their appreciation to 612 Christian Jacquenet of France Telecom whose contributions to the "AAA 613 Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework] 614 largely influenced this draft; Pekka Savola of Netcore Ltd.; Daniel 615 Alvarez, and Toerless Eckert of Cisco Systems; Sam Sambasivan of 616 AT&T; Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper; 617 Tom Anschutz and Steven Wright of BellSouth; Nicolai Leymann of 618 T-Systems; Bill Atwood of Concordia University; Carlos Garcia Braschi 619 of Telefonica Empresas; Mark Altom, Andy Huang, Tom Imburgia, Han 620 Nguyen, Doug Nortz of ATT Labs; Marshall Eubanks in his role as 621 mboned WG chair; Ron Bonica in his role as Director as the Operations 622 and Management Area; Stephen Rife of Digital Garage and David Meyer 623 in his former role as mboned WG chair as well as their thanks to the 624 participants of the MBONED WG in general. 626 Funding for the RFC Editor function is currently provided by the 627 Internet Society. 629 11. IANA Considerations 631 This memo does not raise any IANA consideration issues. 633 12. Security Considerations 635 Accounting capabilities can be used to enhance the security of 636 multicast networks by excluding ineligible clients from the networks. 638 These requirements are not meant to address encryption issues. Any 639 solution meeting these requirements should allow for the 640 implementation of encryption such as MSEC on the multicast data. 642 13. Privacy considerations 644 Any solution which meets these requirements should weigh the benefits 645 of user-based accounting with the privacy considerations of the user. 646 For example solutions are encouraged when applicable to consider 647 encryption of the content data between the content provider and the 648 user in such a way that the Network Provider does not know the 649 contents of the channel. 651 14. Conclusion 653 This memo describes general requirements for providing AAA and QoS 654 enabled IP multicasting services in multi-entity models. A few 655 models are evaluated with regard to their support by current 656 technologies. The "multi-entity CDS with direct billing of the end 657 user" model is presented and requirements for information sharing 658 between entities and requirements for admission control to enable 659 guaranteeing of QoS are derived. Performance requirements and 660 concomitant requirements are also presented. 662 15. References 664 15.1. Normative References 666 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 667 Accounting Management", RFC 2975, October 2000. 669 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 670 Thyagarajan, "Internet Group Management Protocol, Version 671 3", RFC 3376, October 2002. 673 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 674 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 676 15.2. Informative References 678 [I-D.ietf-mboned-auto-multicast] 679 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 680 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 681 (AMT)", draft-ietf-mboned-auto-multicast-09 (work in 682 progress), June 2008. 684 Authors' Addresses 686 Tsunemasa Hayashi 687 Nippon Telegraph and Telephone Corporation 688 1-1 Hikarino'oka 689 Yokosuka-shi, Kanagawa 239-0847 690 Japan 692 Phone: +81 46 859 8790 693 Email: hayashi.tsunemasa@lab.ntt.co.jp 694 Hiroaki Satou 695 Nippon Telegraph and Telephone Corporation 696 3-9-11 Midoricho 697 Musashino-shi, Tokyo 180-8585 698 Japan 700 Phone: +81 422 59 4683 701 Email: satou.hiroaki@lab.ntt.co.jp 703 Hiroshi Ohta 704 Nippon Telegraph and Telephone Corporation 705 3-9-11 Midoricho 706 Musashino-shi, Tokyo 180-8585 707 Japan 709 Phone: +81 422 59 3617 710 Email: ohta.hiroshi@lab.ntt.co.jp 712 Haixiang He 713 Nortel 714 600 Technology Park Drive 715 Billerica, MA 01801 716 USA 718 Phone: +1 978 288 7482 719 Email: haixiang@nortel.com 721 Susheela Vaidya 722 Cisco Systems, Inc. 723 170 W. Tasman Drive 724 San Jose, CA 95134 725 USA 727 Phone: +1 408 525 1952 728 Email: svaidya@cisco.com 730 Copyright and License Notice 732 Copyright (c) 2010 IETF Trust and the persons identified as the 733 document authors. All rights reserved. 735 This document is subject to BCP 78 and the IETF Trust's Legal 736 Provisions Relating to IETF Documents 737 (http://trustee.ietf.org/license-info) in effect on the date of 738 publication of this document. Please review these documents 739 carefully, as they describe your rights and restrictions with respect 740 to this document. Code Components extracted from this document must 741 include Simplified BSD License text as described in Section 4.e of 742 the Trust Legal Provisions and are provided without warranty as 743 described in the Simplified BSD License. 745 This document may contain material from IETF Documents or IETF 746 Contributions published or made publicly available before November 747 10, 2008. The person(s) controlling the copyright in some of this 748 material may not have granted the IETF Trust the right to allow 749 modifications of such material outside the IETF Standards Process. 750 Without obtaining an adequate license from the person(s) controlling 751 the copyright in such materials, this document may not be modified 752 outside the IETF Standards Process, and derivative works of it may 753 not be created outside the IETF Standards Process, except to format 754 it for publication as an RFC or to translate it into languages other 755 than English.