idnits 2.17.1 draft-ietf-mboned-maccnt-req-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 12, 2009) is 5584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Tsunemasa Hayashi, NTT 3 Internet Draft Haixiang He, Nortel 4 Document:draft-ietf-mboned-maccnt-req-07.txt Hiroaki Satou, NTT 5 Intended Status: Informational Hiroshi Ohta, NTT 6 Expires: July 16, 2009 Susheela Vaidya, Cisco Systems 8 January 12, 2009 10 Requirements for Multicast AAA coordinated between Content 11 Provider(s) and Network Service Provider(s) 14 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 16, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. 49 Abstract 51 This memo presents requirements in the area of accounting and 52 access control for IP multicasting. The scope of the 53 requirements is limited to cases that Authentication, 54 Accounting and Authorization (AAA) functions are coordinated 55 between Content Provider(s) and Network Service Provider(s). 56 General requirements for accounting and admission control 57 capabilities including quality-of-service (QoS) related issues 58 are listed. This memo assumes that these capabilities can be 59 realized by functions implemented at edges of a network based 60 on IGMP or MLD. Finally, cases for Content Delivery Services 61 (CDS) are described as application examples which could benefit 62 from multicasting accounting and access control capabilities as 63 described in this memo. 65 This memo defines requirements related to AAA issues for multi- 66 entity provider models in which the network service provider and 67 content provider cooperate to provide CDS and various related AAA 68 functions for purposes such as protecting and accounting for the 69 access to content and network resources. The requirements are 70 generally not relevant to cases in which there is not a reason to 71 share AAA functions between separate entities. 73 Table of Contents 75 1. Introduction..................................................3 76 2. Definitions and Abbreviations.................................5 77 2.1 Definitions..................................................5 78 2.2 Abbreviations................................................6 79 3. Problem Statement.............................................6 80 3.1 Accounting Issues...........................................6 81 3.2 Relationship with Secure Multicasting (MSEC)................8 82 3.3 Regarding Access Media and User Separation..................8 83 4. General AAA-related Functional Requirements for IP Multicasting 84 .................................................................9 85 5. Application Example and its Specific Requirements............14 86 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP 87 are different entities (companies)..............................14 88 5.1.1 Network Model for Multicast Content Delivery Service......15 89 5.1.2 Content Delivery Service Requirements.....................17 90 5.1.2.1 Accounting Requirements.................................17 91 5.1.2.2 Authorization Requirements..............................18 92 5.1.2.3 Authentication Requirements.............................19 93 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP 94 are the same entities (companies)...............................19 95 6. Acknowledgments..............................................21 96 7. IANA Considerations..........................................21 97 8. Security Considerations......................................21 98 9. Privacy considerations.......................................21 99 10. Conclusion..................................................21 100 Normative References............................................22 101 Authors' Addresses..............................................23 103 1. Introduction 105 This memo presents general functional requirements related to 106 accounting, access control and admission control issues in IP 107 multicasting networks. A multicast network which fulfills all of 108 these requirements is called a "fully AAA and QoS enabled" IP 109 multicasting network here. Fulfillment of all or some of the 110 requirements will make possible more robust management of IP 111 multicasting networks. 113 IP multicasting is becoming widely used as a method to save 114 network resources such as bandwidth or CPU processing power of the 115 sender's server for cases where a large volume of information 116 needs to be distributed to a very large number of receivers at a 117 given data speed. This trend can be observed both in enterprise 118 use and in broadband services provided by network operator/service 119 providers. 121 Distance learning within a university and in-house (in-company) 122 sharing of multimedia information are examples of enterprise use. 123 In these examples, sources generate high-bit rate (e.g., 6Mbit/s) 124 streaming information. When the number of receivers becomes large, 125 such systems do not scale well without multicasting. 127 On the other hand, a content delivery service (CDS) is an example 128 of a broadband service provided by network operators/service 129 providers. Distribution of movies and other video programs to 130 each user is a typical service. Each channel requires large 131 bandwidth (e.g., 6Mbit/s) and operator/service providers need to 132 provide many channels to make their service attractive. In 133 addition, the number of receivers is large (e.g., more than a few 134 thousands). A system to provide this service does not scale well 135 without multicasting. 137 As such, multicasting can be useful to make a network more 138 scalable when a large volume of information needs to be 139 distributed to a large number of receivers. However, multicasting 140 according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has 141 drawbacks compared to unicasting when one applies it to commercial 142 services. Accounting of each user's actions is not possible with 143 multicasting as it is with unicasting. Accounting consists of 144 grasping each user's behavior, when she/he starts/stops to receive 145 a channel, which channel she/he receives, etc. 147 There are limitations to the application of multicasting in usage 148 models where user-based accounting is necessary, such as is the 149 case with many commercial applications. These limitations have 150 prevented the widespread deployment of multicasting. Development 151 and use of proprietary solutions to address such issues is an 152 alternative to providing standardized solutions. However, non- 153 standard solutions have drawbacks in terms of interoperability or 154 cost of development and maintenance. 156 Without accounting capability in multicasting, information 157 providers desiring accounting capability are forced to use 158 unicasting even when multicasting would otherwise be desirable 159 from a bandwidth/server resource perspective. If multicasting 160 could be used with user-based accounting capabilities, its 161 applicability would be greatly widened. 163 This memo first describes problems on accounting issues in 164 multicasting. Then the general requirements for this capability 165 including QoS related issues are listed. Finally, application 166 examples which could benefit from multicasting with accounting 167 capabilities are shown. 169 2. Definitions and Abbreviations 171 2.1 Definitions 173 Authentication: action for identifying a user as a genuine one. 175 Authorization: action for giving permission for a user to access 176 content or the network. 178 Eligible user: Users may be eligible (permitted) to access 179 resources because of the attributes they have (e.g., delivery may 180 require possession of the correct password or digital 181 certificate), their equipment has (e.g., content may only be 182 eligible to players that can decode H.264 or 3GPP streams), their 183 access network has (e.g., HDTV content may only be eligible to 184 users with 10 Mbps or faster access line), or because of where 185 they are in network topology (e.g., HDTV content may not be 186 eligible for users across congested links) or in actual geography 187 (e.g., content may only be licensed for distribution to certain 188 countries), and, of course, a mix of attributes may be required 189 for eligibility or ineligibility. 191 User: In this document user refers to a requester and a recipient 192 of multicast data, termed a viewer in CDS. 194 User-based accounting: actions for grasping each user's behavior, 195 when she/he starts/stops to receive a channel, which channel 196 she/he receives, etc. 198 2.2 Abbreviations 200 AAA: Authentication, Accounting and Authorization 202 ASM: Any-Source Multicast 204 CDS: Content Delivery Service 206 CP: Content Provider 208 IGMP: Internet Group Management Protocol 210 MLD: Multicast Listener Discovery 212 NSP: Network Service Provider 214 SSM: Source Specific Multicast 216 QoS: Quality of Service 218 3. Problem Statement 220 3.1 Accounting Issues 222 In unicast communications, the server (information source) can 223 identify the client (information receiver) and only permits 224 connection by an eligible client when this type of access control 225 is necessary. In addition, when necessary, the server can grasp 226 what the client is doing (e.g., connecting to the server, starting 227 reception, what information the client is receiving, terminating 228 reception, disconnecting from the server). 230 On the other hand, in multicast communication with current 231 standards (e.g., IGMPv3[1] or MLDv2[2]) the server just feeds its 232 information to the multicast router [as in Fig.1]. Then, the 233 multicast router replicates the data to any link which has at 234 least one client requesting the information. In this process, 235 no eligibility check is conducted. Any client can receive 236 information just by requesting it. 238 It is envisioned that there are many large-scale content 239 distribution applications transferred over IP-based networks that 240 can leverage multicasting technologies to meet their scalability 241 requirements for clients and data volume, and that some of these 242 applications require user-based accounting capabilities similar to 243 available with unicast networks. For example, accounting is needed 244 if one wants to charge for distributed information on a non-flat- 245 fee basis. The current standards do not provide multicasting with 246 authorization or access control capabilities sufficient to meet 247 the requirements of accounting. 249 |--- user ----|------------NSP------------------|-----CP---| 251 +--------+ 252 | user |\ 253 +--------+ \ 254 \+------+ +------+ +------+ +------+ 255 +--------+ |Multi-| |Multi-| |Multi-| | | 256 | user |---|cast |----|cast |----|cast |----|Server| 257 +--------+ |router| |router| |router| | | 258 /+------+ +------+ +------+ +------+ 259 +--------+ / 260 | user |/ 261 +--------+ 263 Fig.1 Example network for multicast communication 265 As such, the same level of user-based accounting capabilities as 266 provided in unicast networks should be provided in multicast 267 networks. 269 3.2 Relationship with Secure Multicasting (MSEC) 271 In many cases, content encryption (e.g. MSEC) is an effective 272 method for preventing unauthorized access to original content (in 273 other words, the ability to decode data to return it to its 274 generally usable form.) This memo presents requirements for 275 multicasting networks in the areas of 1) access control to prevent 276 unauthorized usage of network resources (link bandwidth, router's 277 processing power, etc.) , and 2) accounting to grasp user activity 278 in a NSP. The functional requirements do not require content 279 encryption although it might solve some of the content related 280 problems. At this point, it is not yet clear whether encryption 281 would be part of a solution and if so, what other components (if 282 any) would also be required. Multicast streams generally consume 283 large amounts of bandwidth for extended periods of time. 284 Additionally, some multicast streams may have high-priority 285 depending on a NSP's policy. NSP does not want to let ineligible 286 users waste large amounts of bandwidth: for example encryption 287 protects against content viewing but NSP desires protection 288 against DoS attacks of ineligible users wasting network resources, 289 even if it is encrypted. Content encryption and multicast access 290 control should both be able to coexist for more robust security. 292 3.3 Regarding Access Media and User Separation 294 The requirements defined in this memo apply to solutions that 295 provide user separation either through physical separation 296 provided by dedicated access media between the user and multicast 297 router (see Fig. 1) or else through logical separation in cases 298 of shared physical access media (e.g. using VLAN). However, IP 299 multicast solutions with shared Layer 2 access media between the 300 user and multicast router and no logical user separation (e.g. 301 Ethernet with shared links and no VLAN) are out of scope of this 302 memo. Nevertheless, some of the requirements in this memo defined 303 for multicasting may also be relevant to multicasting over links 304 without either physical or logical user separation. Therefore in 305 the interest of modularity and flexibility, solutions addressing 306 the requirements of this memo may also take into account 307 application to multicasting without such user separation. 309 4. General AAA-related Functional Requirements for IP Multicasting 311 In consideration of the issues presented in section 3, the 312 following requirements have been derived: 314 (1) User identification 316 The network should be able to identify each user when they attempt 317 to access the service so that necessary access controlling actions 318 can be applied. Also, it is necessary to identify the user's 319 receiver (e.g. IP address) of each request (e.g., join/leave) for 320 per host tracking purposes. 322 With current protocols (IGMP/MLD), the sender cannot distinguish 323 which receivers (end hosts) are actually receiving the information. 324 The sender must rely on the information from the multicasting 325 routers. This can be complicated if the sender and routers are 326 maintained by different entities. 328 (2) Issue of Network Resource Protection 330 In order to guarantee certain QoS it is important for network 331 providers to be able to protect their network resources from being 332 wasted, (either maliciously or accidentally). 334 For comparisons sake, for unicast this issue can be resolved e.g. 335 by using RSVP in some cases. 337 (2.1) Access control 339 The network should be able to apply necessary access controlling 340 actions when an eligible user requests an action (such as a join 341 or a leave.) The network should be able to reject any action 342 requested from an ineligible user. 344 (2.2) Control mechanism to support bandwidth of multicast stream 345 from a physical port of edge router or switch 347 The network may need to control the combined bandwidth for all 348 channels at the physical port of the edge router or switch so that 349 these given physical entities are not overflowed with traffic. 351 (2.3) Control mechanism of number of channels delivered from a 352 physical port of edge router and switch 354 If an NSP desires to guarantee a certain level of QoS to CP and 355 the receivers, it is necessary that the NSP be able to control the 356 number of channels delivered from a physical port of an edge 357 router and a switch in cases that there is a limit to the number 358 of packet copies and/or number of channels that can be handled by 359 multicast routers. 361 For comparisons sake, for unicast this issue can be resolved e.g. 362 by using RSVP in some cases. 364 (3) User Authentication 366 The network should be able to authenticate a user. 368 (4) User Authorization 370 The network, at its option, should be able to authorize a user's 371 access to content or a multicast group, so as to meet any demands 372 by a CP to prevent content access by ineligible users. In the 373 case that the NSP may wish to provide a service based on 374 guaranteed delivery, the NSP would not want to waste its network 375 resources on ineligible users. 377 (5) Accounting and Billing 379 In many commercial multicast situations, NSPs would like to be 380 able to precisely grasp network resource consumption and CPs would 381 like to be able to precisely grasp the content consumption by 382 users. Such information might be used for identifying highly 383 viewed content for advertising revenue, ratings calculations, 384 programming decisions, etc., as well as billing and auditing 385 purposes. Also content and network providers may wish to provide 386 users with access to their usage history. 388 To assemble such an understanding of user behavior, it is 389 necessary to precisely log information such as who (host/user) is 390 accessing what content at what time (join action) until what time 391 (leave action). The result of the access-control decision (e.g. 392 results of authorization) would also be valuable information. The 393 desired degree of logging precisions would depend on the 394 application used. 396 (5.1) How to share user information 398 For commercial multicast applications it is important for NSP and 399 CP to be able to share information regarding user's behaviour (as 400 described in (5) in standardized ways. 402 (6) Notification to Users of the Result of the Join Request 404 It should be possible to provide information to the user about the 405 status of his/her join request(granted/denied/other). 407 (7) Service and Terminal Portability 409 Depending on the service, networks should allow for a user to 410 receive a service from different places and/or with a different 411 terminal device. 413 (8) Support of ASM and SSM 415 Both ASM (G), and SSM (S,G) should be supported as multicast 416 models. 418 (9) Admission Control for Join Action 419 In order to maintain a predefined QoS level, depending on the 420 NSP's policy, a user edge should be able to control the number of 421 streams it serves to a user, and total bandwidth consumed to that 422 user. For example if the number of streams being served to a 423 certain user has reached the limit defined by the NSP's policy, 424 then the user edge should not accept a subsequent "join" until one 425 of the existing streams is terminated. Similarly, if the NSP is 426 controlling by per-user bandwidth consumption, then a subsequent 427 "join" should not be accepted if delivery of the requested stream 428 would push the consumed bandwidth over the NSP policy-defined 429 limit. 431 (10) Channel Join Latency and Leave Latency 433 Commercial implementations of IP multicasting are likely to have 434 strict requirements in terms of user experience. Join latency is 435 the time between when a user sends a "join" request and when the 436 requested data streaming first reaches the user. Leave latency is 437 the time between when a user sends a "leave" signal and when the 438 network stops streaming to the user. 440 Leave and Join latencies impact the acceptable user experience for 441 fast channel surfing. In an IP-TV application, users are not going 442 to be receptive to a slow response time when changing channels. 443 If there are policies for controlling the number of simultaneous 444 streams a user may access then channel surfing will be determined 445 by the join and leave latencies. 447 Furthermore, leave affects resource consumption: with a low 448 "leave latency" network providers could minimize streaming content 449 when there are no audiences. 451 It is important that any overhead for authentication, 452 authorization, and access-control be minimized at the times of 453 joining and leaving multicast channels so as to achieve join and 454 leave latencies acceptable in terms of user experience. For 455 example this is important in an IP-TV application, because users 456 are not going to be receptive to a slow response time when 457 changing channels. 459 (11) Scalability 461 Solutions that are used for AAA and QoS enabled IP multicasting 462 should scale enough to support the needs of content providers and 463 network operators. NSP's multicast access and QoS policies should 464 be manageable for large scale users. (e.g. millions of users, 465 thousands of edge-routers) 467 (12) Small Impact on the Existing Products 469 Impact on the existing products (e.g., protocols, software, etc.) 470 should be as minimal as possible. 472 Ideally the NSP should be able to use the same infrastructure 473 (such as access control) to support commercial multicast services 474 for the so called "triple play" services: voice (VoIP), video, and 475 broadband Internet access services. 477 When a CP requires the NSP to provide a level of QoS surpassing 478 "best effort" delivery or to provide special services (e.g., to 479 limited users with specific attributes), certain parameters of the 480 CDS may be defined by a contractual relation between the NSP and 481 the CP. However, just as for best-effort unicast, multicast 482 allows for content sourced by CPs without a contractual relation 483 with the NSP. Therefore, solutions addressing the requirements 484 defined in this memo should not make obsolete multicasting that 485 does not include AAA features. NSPs may offer tiered services, 486 with higher QOS, accounting, authentication, etc., depending on 487 contractual relation with the CPs. It is therefore important that 488 Multicast AAA and QoS functions be as modular and flexible as 489 possible. 491 (13) Deployable as Alternative to Unicast 493 IP Multicasting would ideally be available as an alternative to IP 494 unicasting when the "on-demand" nature of unicasting is not 495 required. Therefore interfaces to multicasting should allow for 496 easy integration into CDS systems that support unicasting. 498 Especially equivalent interfaces for authorization, access control 499 and accounting capabilities should be provided. 501 (14) Multicast Replication 503 The above requirements should also apply if multicast replication 504 is being done on an access-node (e.g. DSLAMs or OLTs). 506 Specific functional requirements for each application can be 507 derived from the above general requirements. An example is shown 508 in the section 5. 510 5. Application Example and its Specific Requirements 512 This section shows an application example which could benefit from 513 multicasting. Then, specific functional requirements related to 514 user-based accounting capabilities are derived. 516 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 517 different entities (companies) 519 Broadband access networks such as ADSL (Asymmetric Digital 520 Subscriber Line) or FTTH (Fiber to the Home) have been deployed 521 widely in recent years. Content Delivery Service (CDS) is expected 522 to be a major application provided through broadband access 523 networks. Because many services such as television broadcasting 524 require huge bandwidth (e.g., 6Mbit/s) and processing power at 525 content server, IP multicast is used as an efficient delivery 526 mechanism for CDS. 528 One way to provide high quality CDS is to use closed networks 529 ("walled-garden" model). 531 This subsection shows an example where CP and NSP are different 532 entities (companies). 534 5.1.1 Network Model for Multicast Content Delivery Service 536 As shown in Fig.2, networks for CDS contain three different types 537 of entities: Content Provider (CP), Network Service Provider (NSP), 538 and user clients. An NSP owns the network resources 539 (infrastructure). It accommodates content providers on one side 540 and accommodates user clients on the other side. NSP provides the 541 network for CDS to two other entities (i.e., CPs and user clients). 542 A CP provides content to each user through the network of NSPs. 543 NSPs are responsible for delivering the content to user clients, 544 and for controlling the network resources. 546 +-------------+ +-------------+ +-------------+ 547 | CP | | CP | | CP | 548 | #1 | | #2 | | #3 | 549 | +---------+ | | +---------+ | | +---------+ | 550 | | content | | | | content | | | | content | | 551 | | server | | | | server | | | | server | | 552 | +-------+-+ | | +----+----+ | | +-+-------+ | 553 +----------\--+ +------|------+ +--/----------+ 554 \ | / 555 \ | / <- network/network 556 \ | / interface 557 +------------- \ ------ | ------ / ----+ 558 | \ | / | 559 | NSP +-+-----+-----+-+ | 560 | | Provider Edge | | 561 | +-------+-------+ | +-----------------+ 562 | | |---| Information | 563 | | | | server | 564 | +--+------+---+ | +-----------------+ 565 | | User Edge | | 566 | +--+---+---+--+ | 567 | / | \ | 568 +------------- / --- | --- \ ----------+ 569 / | \ 570 / | \ <- user/network interface 571 / | \ 572 +---------++ +-----+----+ ++---------+ 573 |client #a | |client #b | |client #c | 574 +----------+ +----------+ +----------+ 575 User A User B User C 577 Fig.2 Example of CDS network configuration 579 The NSP provides the information server for all multicast channels, 580 and a CP gives detailed channel information (e.g., Time table of 581 each channel) to the information server. An end-user client gets 582 the information from the information server. In this model, 583 multicasting is used in the NSP's CDS network, and there are two 584 different contracts. One is the contract between the NSP and the 585 user which permits the user to access the basic network resources 586 of the NSP. Another contract is between the CP and user to permit 587 the user to subscribe to multicast content. Because the CP and NSP 588 are different entities, and the NSP generally does not allow a CP 589 to control (operate) the network resources of the NSP, user 590 authorization needs to be done by the CP and NSP independently. 591 Since there is no direct connection to the user/network interface, 592 the CP cannot control the user/network interface. A user may want 593 to move to another place, or may want to change her/his device 594 (client) any time without interrupting her/his reception of 595 services. As such, IP Multicast network should support 596 portability capabilities. 598 5.1.2 Content Delivery Service Requirements 600 Below are listed specific requirements to support common business 601 cases/ contractual arrangements for the IP Multicast-based Content 602 Delivery Service. 604 5.1.2.1 Accounting Requirements 606 An NSP may have different contractual agreements with various CPs 607 or various legal obligations in different locations. One possible 608 business relationship between a CP and NSP is that of a revenue 609 sharing which could be on a per content/usage-base. A solution 610 should support varied billing and charging methods to satisfy both 611 common legal and business/financial requirements to deploy 612 multicasting services: this requires accurate and near real-time 613 accounting information about the user clients' activity accessing 614 the content services. 615 The user accessing particular content is represented by the user's 616 activities of joining or leaving the corresponding multicast 617 group/channel (<(*,g)> or (s,g)). In multicast networks, only NSPs 618 can collect joining or leaving activities in real-time through 619 their user edges. The NSPs can transfer the accounting information 620 to related CPs for them to generate user billing information. 621 Existing standard AAA technology may be used to transfer the 622 accounting information. 624 To match the accounting information with a particular user, the 625 user has to be authenticated. Usually the account information of a 626 user for content access is maintained by the CP. A user may have 627 different user accounts for different CPs.(e.g. user_a@cp#1 and 628 user_b@cp#2) The account is usually in the format of (username, 629 password) so an user can access the content services from anywhere. 630 For example, an user can access the CP from different NSPs.(e.g. a 631 fixed line NSP and a mobile NSP). It should be noted that the user 632 account used for content access can be different from the one used 633 for network access maintained by NSPs. 635 The NSP-CP model represents a multi-domain AAA environment. There 636 are plural cases of the model depending on the trust relationship 637 between the NSP and CP, and additional service requirements such 638 as a certain QoS level guarantee or service/terminal portability. 640 A mechanism is necessary to allow a CP and NSP to grasp each 641 user's behavior independently. 643 Another requirement related to accounting is the ability to notify 644 a user when accounting really starts. When a "free preview" 645 capability is supported, accounting may not start at the same time 646 as the user's joining of the stream. 648 Any solution addressing the requirements of this memo should 649 consider the Interdomain accounting issues presented in RFC-2975 650 [3]. It is especially important to consider that the CP and NSP 651 as separate administrative entities can not be assumed to trust 652 one another. The solution should be robust enough to handle 653 packet loss between entity domains and assure for data integrity. 654 In addition any solution should take into consideration common 655 legal or financial requirements requiring confidential archiving 656 of usage data. 658 5.1.2.2 Authorization Requirements 660 The NSPs are responsible for delivering content and are generally 661 required to meet certain QoS levels or SLA (service level 662 agreements). For example, video quality is very sensitive to packet 663 loss. So if an NSP --due to limited network resources -- cannot 664 meet quality requirements if it accepts an additional user request, 665 the NSP should reject that user's access request to avoid charging 666 the existing (i.e., already-joined) user for bad services. For 667 example, if an access line is shared by several users, an 668 additional user's join may cause performance degradation for other 669 users. If the incoming user is the first user on a user edge, this 670 will initiate the transmission of data between the provider edge 671 and the user edge and this extra network traffic may cause 672 performance degradation. There may also be policies that do not 673 necessarily give highest priority to the "first-come" users, and 674 these should also be considered. 676 In order to protect network resources against misuse/malicious 677 access and maintain a QoS level, appropriate admission control 678 function for traffic policing purposes is necessary so that the NSP 679 can accept or reject the request without degrading the QoS beyond 680 the specified level. 682 5.1.2.3 Authentication Requirements 684 There are two different aims of authentication. One is 685 authentication for network access, and another one is for content 686 access. For the first case of authentication, NSP has a AAA server, 687 and for the second case, each CP has a AAA server. In some cases, 688 CPs delegate (outsource) the operation of user authentication to 689 NSPs. 691 As such, in addition to network access, multicast access by a user 692 also needs to be authenticated. Content authentication should 693 support the models where: 694 - authentication for multicast content is outsourced to the 695 NSP. 696 - authentication for multicast content access is operated by 697 the CP 699 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 700 the same entities (companies) 702 Another application example is the case where the content provider 703 (CP) and network service provider (NSP) are the same entity 704 (company) as shown in Fig. 3. In the case that the CP and NSP are 705 the same entity, some of the requirements indicated in 4.1 are not 706 required. 708 This model does not require the following items: 710 - Communication method between sender (content server) and 711 user. Since they belong to the same company, they can use 712 all the available information. 714 - Methods to share user-related information between NSPs and 715 CPs. 716 +-----------------------------------------------------+ 717 | +---------+ | 718 | | content | | 719 | | server | | 720 | +----+----+ | 721 | | | 722 | CP+NSP +-------+-------+ | 723 | | Provider Edge | | 724 | +-------+-------+ +--------------------+ | 725 | | | Information server | | 726 | | +--------------------+ | 727 | +-------------+ | 728 | | User Edge | | 729 | +--+---+---+--+ | 730 | / | \ | 731 +----------- / --- | --- \ ---------------------------+ 732 / | \ 733 / | \ <- user/network interface 734 / | \ 735 +---------++ +-----+----+ ++---------+ 736 |Client #a | |client #b | |client #c | 737 +----------+ +----------+ +----------+ 738 User A User B User C 740 Fig.3 Example of CDS network configuration 742 6. Acknowledgments 744 The authors of this draft would like to express their appreciation 745 to Pekka Savola of Netcore Ltd., Daniel Alvarez, and Toerless 746 Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of 747 Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai 748 Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Empresas, 749 Marshall Eubanks of Multicast Techno, Stephen Rife of NTT and 750 David Meyer in his role as mboned WG chair, as well as their 751 thanks to the participants of the MBONED WG in general. 753 Funding for the RFC Editor function is currently provided by the 754 Internet Society. 756 7. IANA Considerations 758 This memo does not raise any IANA consideration issues. 760 8. Security Considerations 762 Accounting capabilities can be used to enhance the security of 763 multicast networks by excluding ineligible clients from the 764 networks. 766 These requirements are not meant to address encryption issues. 767 Any solution meeting these requirements should allow for the 768 implementation of encryption such as MSEC on the multicast data. 770 9. Privacy considerations 772 Any solution which meets these requirements should weigh the 773 benefits of user-based accounting with the privacy considerations 774 of the user. For example solutions are encouraged when applicable 775 to consider encryption of the content data between the content 776 provider and the user in such a way that the Network Provider does 777 not know the contents of the channel. 779 10. Conclusion 780 This memo describes general requirements for providing AAA and QoS 781 enabled IP multicasting services. It lists issues related to 782 accounting, authentication, authorization and admission control 783 for multicast content delivery. Content Delivery Services with 784 different business models are cited as the type of application 785 which could benefit from the capabilities of AAA and QoS enabled 786 IP multicasting described in this document. 788 Normative References 790 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 791 3", RFC3376, October 2002. 793 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 794 (MLDv2) for IPv6", RFC3810, June 2004. 796 [3] Aboba B , et. al., "Introduction to Accounting Management", 797 RFC 2975, October 2000. 799 Authors' Addresses 801 Tsunemasa Hayashi 802 NTT Network Innovation Laboratories 803 1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 804 Phone: +81 46 859 8790 805 Email: hayashi.tsunemasa@lab.ntt.co.jp 807 Haixiang He 808 Nortel 809 600 Technology Park Drive Billerica, MA 01801, USA 810 Phone: +1 978 288 7482 811 Email: haixiang@nortel.com 813 Hiroaki Satou 814 NTT Network Service Systems Laboratories 815 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 816 Phone: +81 422 59 4683 817 Email: satou.hiroaki@lab.ntt.co.jp 819 Hiroshi Ohta 820 NTT Network Service Systems Laboratories 821 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 822 Phone: +81 422 59 3617 823 Email: ohta.hiroshi@lab.ntt.co.jp 825 Susheela Vaidya 826 Cisco Systems, Inc. 827 170 W. Tasman Drive San Jose, CA 95134 828 Phone: +1 408 525 1952 829 Email: svaidya@cisco.com