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