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