idnits 2.17.1 draft-ietf-mboned-maccnt-req-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 RFC 3978 Section 5.4 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 10, 2006) is 6681 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 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-03.txt Hiroaki Satou, NTT 5 Expires: July 14, 2006 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 January 10, 2006 10 Requirements for Accounting, Authentication and Authorization in 11 Well Managed IP Multicasting Services 12 14 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 14, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006) 43 Abstract 45 This memo presents requirements in the area of accounting and 46 access control for multicasting. General requirements for 47 accounting capabilities including quality-of-service (QoS) related 48 issues are listed. Finally, cases for Content Delivery Services 49 (CDS) are described as application examples which could benefit 50 from multicasting accounting and access control capabilities as 51 described in the I-D. It is proposed that this I-D be used as a 52 starting point for further discussion on these issues. 54 Table of contents 56 Copyright Notice.................................................1 57 1. Introduction..................................................2 58 2. Definitions and Abbreviations.................................4 59 2.1 Definitions..................................................4 60 2.2 Abbreviations................................................4 61 3. Problem statement.............................................4 62 3.1 Accounting issues...........................................5 63 3.2 Relationship with secure multicasting (MSEC)................6 64 4. General AAA-related functional requirements for IP 65 multicasting..................................................6 66 5. Application example and its specific requirements............10 67 5.1 IP Multicast-based Content Delivery Service (CDS): CP and 68 NSP are different entities (companies)......................10 69 5.1.1 Network model for Multicast Content Delivery Service......10 70 5.1.2 Content Delivery Service Requirements.....................12 71 5.1.2.1 Accounting Requirements.................................12 72 5.1.2.2 Authorization Requirements..............................13 73 5.1.2.3 Authentication Requirements.............................13 74 5.2 IP Multicast-based Content Delivery Service (CDS): CP and 75 NSP are the same entities (companies).......................14 76 6. Acknowledgements.............................................15 77 7. IANA considerations..........................................15 78 8. Security considerations......................................15 79 9. Conclusion...................................................15 80 Normative References............................................15 81 Authors' Addresses..............................................15 82 Full Copyright Statement........................................17 83 Intellectual Property...........................................17 85 1. Introduction 87 This I-D will present general functional requirements related to 88 accounting, authentication and authorization issues in IP 89 multicasting networks. A multicast network which fulfills all of 90 these requirements will be called a "fully AAA enabled" IP 91 multicasting network. Fulfillment of all or some of the 92 requirements will make possible more robust management of IP 93 multicasting networks, and as such these capabilities contribute to 94 the provision of well-managed IP multicasting services. 96 IP multicasting is becoming widely used as a method to save network 97 resources such as bandwidth or CPU processing power of the sender's 98 server for cases where a large volume of information needs to be 99 distributed to a large number of receivers. This trend can be 100 observed both in enterprise use and in broadband services provided 101 by network operator/service providers. 103 Distance learning within a university and in-house (in-company) 104 sharing of multimedia information are examples of enterprise use. 105 In these examples, sources generate high-bit rate (e.g., 6Mbit/s) 106 streaming information. When the number of receivers becomes large, 107 such systems do not scale well without multicasting. 109 On the other hand, a Content Delivery Service (CDS) is an example 110 of a broadband service provided by network operators/service 111 providers. Distribution of movies and other video programs to each 112 user are typical services. Each channel requires large bandwidth 113 (e.g., 6Mbit/s) and operator/service providers need to provide many 114 channels to make their service attractive. In addition, the number 115 of receivers is large (e.g., more than a few thousands). The 116 system to provide this service does not scale well without 117 multicasting. 119 As such, multicasting can be useful to make the network more 120 scalable when a large volume of information needs to be distributed 121 to a large number of receivers. However, multicasting according to 122 current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks 123 compared to unicasting when one applies it to commercial services. 124 Accounting of each user's actions is not possible with multicasting 125 as it is with unicasting. Accounting consists of grasping each 126 user's behavior, when she/he starts/stops to receive a channel, 127 which channel she/he receives, etc. 129 IP multicasting can be used to distribute free material efficiently, 130 but there are limitations to multicasting in usage models where 131 usage accounting is necessary, such as many commercial applications. 132 These limitations have prevented the widespread deployment of 133 multicasting. Alternatively, one could develop and use a 134 proprietary solution to address this issue. However, non-standard 135 solutions have drawbacks in terms of interoperability or cost of 136 development and maintenance. 138 Without accounting capability in multicasting, information 139 providers desiring accounting capability are forced to use 140 unicasting even when multicasting would otherwise be desirable from 141 a bandwidth/server resource perspective. If multicasting could be 142 used with user-based accounting capabilities, its applicability 143 would be greatly widened. 145 This I-D first describes problems on accounting issues in 146 multicasting. Then the general requirements for this capability 147 including QoS related issues are listed. Finally, application 148 examples which could benefit from multicasting with accounting 149 capabilities are shown. It is proposed that this I-D be used as a 150 starting point for a discussion on these issues. 152 2. Definitions and Abbreviations 154 2.1 Definitions 156 Authentication: action for identifying a user as a genuine one. 158 Authorization: action for giving permission for a user to access 159 content or the network. 161 User-based accounting: actions for grasping each user's behavior, 162 when she/he starts/stops to receive a channel, which channel she/he 163 receives, etc. 165 2.2 Abbreviations 167 ASM: Any-Source Multicast 169 CDS: Content Delivery Service 171 CP: Content Provider 173 IGMP: Internet Group Management Protocol 175 MLD: Multicast Listener Discovery 177 NSP: Network Service Provider 179 SSM: Single-Source Multicast 181 QoS: Quality of Service 183 3. Problem statement 184 3.1 Accounting issues 186 In unicast communications, the server (information source) can 187 identify the client (information receiver) and only permits 188 connection by an eligible client when this type of access control 189 is necessary. In addition, when necessary, the server can grasp 190 what the client is doing (e.g., connecting to the server, starting 191 reception, what information the client is receiving, terminating 192 reception, disconnecting from the server). 194 On the other hand, in multicast communication with current 195 standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its 196 information to the multicast router [as in Fig.1]. Then, the 197 multicast router replicates the data to any link which has at least 198 one client requesting the information. In this process, no 199 eligibility check is conducted. Any client can receive information 200 just by requesting it. In other words, the current standards do 201 not provide multicasting with authorization or access control 202 capabilities sufficient to meet the requirements of accounting. 204 +--------+ 205 | user |\ 206 +--------+ \ 207 \+------+ +------+ +------+ +------+ 208 +--------+ |Multi-| |Multi-| |Multi-| | | 209 | user |---|cast |----|cast |----|cast |----|Server| 210 +--------+ |router| |router| |router| | | 211 /+------+ +------+ +------+ +------+ 212 +--------+ / 213 | user |/ 214 +--------+ 216 Fig.1 Example network for multicast communication 218 This is the major reason why multicasting is only used for cases 219 where no user-based accounting capabilities are necessary. However, 220 since more and more information is transferred over IP-based 221 networks and some of these applications may require accounting 222 capabilities, it is easy to envision the requirement of supporting 223 such cases. For example, accounting is needed if one wants to 224 charge for distributed information on a non-flat-fee basis. If the 225 volume of information and number of clients are large, it is 226 beneficial to use multicasting for purposes of network resource 227 efficiency. 229 As such, the same level of user-based accounting capabilities as 230 provided in unicast networks should be provided in multicast 231 networks. 233 3.2 Relationship with secure multicasting (MSEC) 235 In many cases, content encryption (e.g. MSEC) is an effective 236 method for preventing unauthorized access to original content (in 237 other words, the ability to decode data to return it to its 238 generally useable form.) This I-D presents requirements for 239 multicasting networks in the areas of 1) access control to prevent 240 unauthorized access to the network, and 2) accounting to grasp user 241 activity. The functional requirements do not require content 242 encryption although it might solve some of the related problems. 243 At this point, it is not yet clear whether encryption would be part 244 of a solution and if so, what other components (if any) would also 245 be required. 247 4. General AAA-related functional requirements for IP multicasting 249 In consideration of the issues presented in section 3, the 250 following requirements have been derived: 252 (1) User identification 254 The network should be able to identify each user when they attempt 255 to access the service so that necessary access controlling actions 256 can be applied. Also, it is necessary to identify the source 257 (user) of each request (e.g., join/leave) for user accounting 258 purposes. 260 With current protocols (IGMP/MLD), the sender cannot distinguish 261 which receivers (end hosts) are actually receiving the information. 262 The sender must rely on the information from the multicasting 263 routers. This can be complicated if the sender and routers are 264 maintained by different entities. 266 (2) Issue of network resource protection 268 In order to guarantee certain QoS it is important for network 269 providers to be able to protect their network resources from being 270 wasted, (either maliciously or accidentally). 272 For comparisons sake, in the case of unicast this issue can be 273 resolved e.g. by using RSVP. 275 (2.1) Access control 276 The network should be able to apply necessary access controlling 277 actions when an eligible user requests. The network should be able 278 to reject any action requested from an ineligible user. 280 (2.2) Control mechanism to support bandwidth of multicast stream 281 from a physical port of edge router or switch 283 The network may need to control the combined bandwidth for all 284 groups at the physical port of the edge router or switch so that 285 these given physical entities are not overflowed with traffic. 287 (2.3) Control mechanism of number of groups delivered from a 288 physical port of edge router and switch 290 If an NSP desires to guarantee a certain level of QoS to CP and the 291 receivers, it is necessary that the NSP be able to control the 292 number of groups delivered from a physical port of an edge router 293 and a switch so that the combined bandwidth between content servers 294 and multicast routers can be within the limit. 296 For comparisons sake, in the case of unicast this issue can be 297 resolved e.g. by using RSVP. 299 (3) User authentication 301 The network should be able to authenticate a user. 303 (4) User authorization 305 The network, at its option, should be able to authorize a user's 306 access to content or a multicast group, so as to meet any demands 307 by a CP to prevent content access by ineligible users. In the case 308 that the NSP may wish to provide a service based on guaranteed 309 delivery, the NSP would not want to waste its network resources on 310 ineligible users. Eligibility can be defined in several ways. The 311 definition of an "eligible user" should be discussed further. 313 (5) Accounting and billing 315 In many commercial multicast situations, NSPs would like to be able 316 to precisely grasp network resource consumption and CPs would like 317 to be able to precisely grasp the content consumption by end-users. 318 Such information might be used for identifying highly viewed 319 content for advertising revenue, ratings calculations, programming 320 decisions, etc., as well as billing and auditing purposes. Also 321 content and network providers may wish to provide users with access 322 to their usage history. 324 To assemble such an understanding of end-user behavior, it is 325 necessary to precisely log information such as who (host/user) is 326 accessing what content at what time (join action) until what time 327 (leave action). The result of the access-control decision (e.g. 328 results of authorization) would also be valuable information. The 329 desired degree of logging precisions would depend on the 330 application used. 332 (5.1) How to share user information 334 For commercial multicast applications it is important for NSP and 335 CP to be able to share information regarding user's behaviour (as 336 described in (5) in standardized ways. 338 (6) Notification to users of the result of the join request 340 It should be possible to provide information to the user about the 341 status of his/her join request(granted/denied/other). 343 (7) Service and terminal portability 345 Depending on the service, networks should allow for a user to 346 receive a service from different places and/or with a different 347 terminal device. 349 (8) Support of ASM and SSM 351 Both ASM (G), and SSM (S,G) should be supported as multicast models. 353 (9) Admission control for join action 355 In order to maintain a predefined QoS level, depending on the NSP's 356 policy, an edge router should be able to control the number of 357 streams it serves to a user, and total bandwidth consumed to that 358 user. For example if the number of streams being served to a 359 certain user has reached the limit defined by the NSP's policy, 360 then the edge router should not accept a subsequent "join" until 361 one of the existing streams is terminated. Similarly, if the NSP 362 is controlling by per-user bandwidth consumption, then a subsequent 363 "join" should not be accepted if delivery of the requested stream 364 would push the consumed bandwidth over the NSP policy-defined limit. 366 (10) Channel Join Latency and Leave Latency 368 Commercial implementations of IP multicasting are likely to have 369 strict requirements in terms of user experience. Join latency is 370 the time between when a user sends a "join" request and when the 371 requested data streaming first reaches the user. Leave latency is 372 the time between when a user sends a "leave" signal and when the 373 network stops streaming to the user. 375 Leave and Join latencies impact the acceptable end-user experience 376 for fast channel surfing. In an IP-TV application, users are not 377 going to be receptive to a slow response time when changing 378 channels. If there are policies for controlling the number of 379 simultaneous streams a user may access then channel surfing will be 380 determined by the join and leave latencies. 382 Furthermore, leave affects resource consumption: with a low "leave 383 latency" network providers could minimize streaming content when 384 there are no audiences. 386 It is important that any overhead for authentication, authorization, 387 and access-control be minimized at the times of joining and leaving 388 multicast groups so as to achieve join and leave latencies 389 acceptable in terms of user experience. For example this is 390 important in an IP-TV application, because users are not going to 391 be receptive to a slow response time when changing channels. 393 (11) Scalability 395 Solutions that are used for well managed IP multicasting should 396 scale enough to support the needs of content providers and network 397 operators. 399 (12) Small impact on the existing products 401 Impact on the existing products (e.g., protocols, software, etc.) 402 should be as minimal as possible. 404 Ideally the NSP should be able to use the same infrastructure (such 405 as access control) to support commercial multicast services for the 406 so called "triple play" services: voice (VoIP), video, and 407 broadband Internet access services. 409 (13) Deployable as alternative to Unicast 411 IP Multicasting would ideally be available as an alternative to IP 412 unicasting when the "on-demand" nature of unicasting is not 413 required. Therefore interfaces to multicasting should allow for 414 easy integration into CDS systems that support unicasting. 415 Especially equivalent interfaces for authorization, access control 416 and accounting capabilities should be provided. 418 (14) Multicast replication 420 The above requirements should also apply if multicast replication 421 is being done on an access-node (e.g. DSLAMs or OLTs). 423 Specific functional requirements for each application can be 424 derived from the above general requirements. An example is shown 425 in the section 5. 427 5. Application example and its specific requirements 429 This section shows an application example which could benefit from 430 multicasting. Then, specific functional requirements related to 431 user-based accounting capabilities are derived. 433 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 434 different entities (companies) 436 Broadband access networks such as ADSL (Asymmetric Digital 437 Subscriber Line) or FTTH (Fiber to the Home) have been deployed 438 widely in recent years. Content Delivery Service (CDS) is expected 439 to be a major application provided through broadband access 440 networks. Because many services such as television broadcasting 441 require huge bandwidth (e.g., 6Mbit/s) and processing power at 442 content server, IP multicast is used as an efficient delivery 443 mechanism for CDS. 445 One way to provide high quality CDS is to use closed networks 446 ("walled-garden" model). 448 This subsection shows an example where CP and NSP are different 449 entities (companies). 451 5.1.1 Network model for Multicast Content Delivery Service 453 As shown in Fig.2, networks for CDS contain three different types 454 of entities: Content Provider (CP), Network Service Provider (NSP), 455 and end user clients. An NSP owns the network resources 456 (infrastructure). It accommodates content providers on one side and 457 accommodates end user clients on the other side. NSP provides the 458 network for CDS to two other entities (i.e., CPs and end user 459 clients). A CP provides content to each end-user client through the 460 network of NSPs. NSPs are responsible for delivering the content to 461 end user clients, and for controlling the network resources. 463 +-------------+ +-------------+ +-------------+ 464 | CP | | CP | | CP | 465 | #1 | | #2 | | #3 | 466 | +---------+ | | +---------+ | | +---------+ | 467 | | content | | | | content | | | | content | | 468 | | server | | | | server | | | | server | | 469 | +-------+-+ | | +----+----+ | | +-+-------+ | 470 +----------\--+ +------|------+ +--/----------+ 471 \ | / 472 \ | / <- network/network 473 \ | / interface 474 +------------- \ ------ | ------ / ----+ 475 | \ | / | 476 | NSP +-+-----+-----+-+ | 477 | | Provider Edge | | 478 | +-------+-------+ | +-----------------+ 479 | | |---| Information | 480 | | | | server | 481 | +--+------+---+ | +-----------------+ 482 | | User Edge | | 483 | +--+---+---+--+ | 484 | / | \ | 485 +------------- / --- | --- \ ----------+ 486 / | \ 487 / | \ <- user/network interface 488 / | \ 489 +---------++ +-----+----+ ++---------+ 490 |client #a | |client #b | |client #c | 491 +----------+ +----------+ +----------+ 492 End user A End user B End user C 494 Fig.2 Example of CDS network configuration 496 The NSP provides the information server for all multicast channels, 497 and a CP gives detailed channel information (e.g., Time table of 498 each channel) to the information server. An end-user client gets 499 the information from the information server. In this model, 500 multicast is used in the NSP's CDS network, and there are two 501 different contracts. One is the contract between the NSP and the 502 end user which permits the user to access the basic network 503 resources of the NSP. Another contract is between the CP and end 504 user to permit the user to subscribe to multicast content. Because 505 the CP and NSP are different entities, and the NSP generally does 506 not allow a CP to control (operate) the network resources of the 507 NSP, user authorization needs to be done by the CP and NSP 508 independently. Since there is no direct connection to the 509 user/network interface, the CP cannot control the user/network 510 interface. An end user may want to move to another place, or may 511 want to change her/his device (client) anytime without interrupting 512 her/his reception of services. As such, IP Multicast network 513 should support portability capabilities. 515 5.1.2 Content Delivery Service Requirements 517 To have a successful business providing multicast, there are some 518 specific requirements for the IP Multicast-based Content Delivery 519 Service. 521 5.1.2.1 Accounting Requirements 523 Since the CP and NSP are different business entities, they need to 524 share the revenue. Such a revenue sharing business relationship 525 requires accurate and near real-time accounting information about 526 the end user clients' activity on accessing the content services. 527 The accounting information should be per content/usage-base to 528 enable varied billing and charging methods. 530 The user accessing particular content is represented by the user's 531 activities of joining or leaving the corresponding multicast 532 group/channel ( or ). In multicast networks, only NSPs can 533 collect group joining or leaving activities in real-time through 534 their last-hop multicast access edge devices. The NSPs can transfer 535 the accounting information to related CPs for them to generate end 536 user billing information. The normal AAA technology can be used to 537 transfer the accounting information. 539 To match the accounting information with a particular end-user 540 client, the end-user client has to be authenticated. Usually the 541 account information of an end-user client for content access is 542 maintained by the CP. An end user client may have different user 543 accounts for different CPs. The account is usually in the format of 544 (username, password) so an end user client can access the content 545 services from anywhere. For example, an end user client can access 546 the CP from different NSPs. It should be noted that the user 547 account used for content access can be different from the one used 548 for network access maintained by NSPs. 550 The NSP-CP model represents a multi-domain AAA environment. There 551 are plural cases of the model depending on the trust relationship 552 between the NSP and CP, and additional service requirements such as 553 a certain QoS level guarantee or service/terminal portability. 555 A mechanism is necessary to allow a CP and NSP to grasp each user's 556 behavior independently. 558 Another requirement related to accounting is the ability to notify 559 a user when accounting really starts. When a "free preview" 560 capability is supported, accounting may not start at the same time 561 as the user's joining of the stream. 563 5.1.2.2 Authorization Requirements 565 The NSPs are responsible for delivering content and are required to 566 meet certain QoS levels or SLA (service level agreements). For 567 example, video quality is very sensitive to packet loss. So if an 568 NSP cannot meet the quality requirements due to limited network 569 resources if it accepts an additional user request, the NSP should 570 reject that end user's access request to avoid charging the 571 existing (i.e., already joined) user for bad services. For example, 572 if an access line is shared by several users, an additional user's 573 join may cause performance degradation for other users. If the 574 incoming user is the first user on an edge node, this will initiate 575 the transmission of data between the multicast router and the edge 576 node and this extra network traffic may cause performance 577 degradation. There may also be policies that do not necessarily 578 give highest priority to the "first-come" users, and these should 579 also be considered. 581 In order to protect network resources against misuse/malicious 582 access and maintain a QoS level, appropriate admission control 583 function for traffic policing purposes is necessary so that the NSP 584 can accept or reject the request without degrading the QoS beyond 585 the specified level. 587 5.1.2.3 Authentication Requirements 589 There are two different aims of authentication. One is 590 authentication for network access, and another one is for content 591 access. For the first case of authentication, NSP has a AAA server, 592 and for the second case, each CP has a AAA server. In some cases, 593 CPs delegate (outsource) the operation of user authentication to 594 NSPs. 596 As such, in addition to network access, multicast group access by a 597 user also needs to be authenticated. Content authentication should 598 support the models where: 599 - authentication for multicast content is outsourced to the 600 NSP. 602 - authentication for multicast content access is operated by 603 the content provider 605 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 606 the same entities (companies) 608 Another application example is the case where the content provider 609 (CP) and network service provider (NSP) are the same entity 610 (company) as shown in Fig. 3. In the case that the CP and NSP are 611 the same entity, some of the requirements indicated in 4.1 are not 612 required. 614 This model does not require the following items: 616 - Communication method between sender (server) and user (end 617 host). Since they belong to the same company, they can use 618 all the available information. 620 - Methods to share user-related information between network 621 providers and content providers. 622 +-----------------------------------------------------+ 623 | +---------+ | 624 | | content | | 625 | | server | | 626 | +----+----+ | 627 | | | 628 | CP+NSP +-------+-------+ | 629 | | Provider Edge | | 630 | +-------+-------+ +--------------------+ | 631 | | | Information server | | 632 | | +--------------------+ | 633 | +-------------+ | 634 | | User Edge | | 635 | +--+---+---+--+ | 636 | / | \ | 637 +----------- / --- | --- \ ---------------------------+ 638 / | \ 639 / | \ <- user/network interface 640 / | \ 641 +---------++ +-----+----+ ++---------+ 642 |user #a | |user #b | |user #c | 643 +----------+ +----------+ +----------+ 644 End user A End user B End user C 646 Fig.3 Example of CDS network configuration 648 6. Acknowledgements 650 The authors of this draft would like to express their appreciation 651 to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert 652 of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper, 653 Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T- 654 Systems, as well as the participants of the MBONED WG in general. 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society. 659 7. IANA considerations 661 This I-D does not raise any IANA consideration issues. 663 8. Security considerations 665 Accounting capabilities can be used to enhance the security of 666 multicast networks by excluding ineligible clients from the 667 networks. 669 9. Conclusion 671 This I-D describes general requirements for providing "well 672 managed" IP multicasting services. It lists issues related to 673 accounting, authentication, authorization and admission control for 674 multicast content delivery. Content Delivery Services with 675 different business models is cited as an application which could 676 benefit from the capabilities of "well managed" IP multicasting 677 described in this document. 678 It is proposed that this document be used as a starting point for 679 discussing requirements for "well managed" IP multicasting services. 681 Normative References 683 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 684 3", RFC3376, October 2002. 686 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 687 (MLDv2) for IPv6", RFC3810, June 2004. 689 Authors' Addresses 691 Tsunemasa Hayashi 692 NTT Network Innovation Laboratories 693 1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 694 Phone: +81 46 859 8790 695 Email: hayashi.tsunemasa@lab.ntt.co.jp 697 Haixiang He 698 Nortel 699 600 Technology Park Drive Billerica, MA 01801, USA 700 Phone: +1 978 288 7482 701 Email: haixiang@nortel.com 703 Hiroaki Satou 704 NTT Network Service Systems Laboratories 705 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 706 Phone: +81 422 59 4683 707 Email: satou.hiroaki@lab.ntt.co.jp 709 Hiroshi Ohta 710 NTT Network Service Systems Laboratories 711 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 712 Phone: +81 422 59 3617 713 Email: ohta.hiroshi@lab.ntt.co.jp 715 Susheela Vaidya 716 Cisco Systems, Inc. 717 170 W. Tasman Drive San Jose, CA 95134 718 Phone: +1 408 525 1952 719 Email: svaidya@cisco.com 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2006). 725 This document is subject to the rights, licenses and restrictions 726 contained in BCP 78, and except as set forth therein, the authors 727 retain all their rights. 729 This document and the information contained herein are provided on 730 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 731 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 732 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 733 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 734 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 735 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 736 PARTICULAR PURPOSE. 738 Intellectual Property 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed 742 to pertain to the implementation or use of the technology 743 described in this document or the extent to which any license 744 under such rights might or might not be available; nor does it 745 represent that it has made any independent effort to identify any 746 such rights. Information on the IETF's procedures with respect to 747 rights in IETF Documents can be found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use 752 of such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository 754 at http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at ietf 760 ipr@ietf.org.