1 Accounting, Authentication and Authorization Issues in “Well Managed” IP Multicasting Services November 9, 2005 Tsunemasa Hayashi Haixiang He Hiroaki Satou Hiroshi Susheela Vaidya

2 Outline Introduce/ review “well managed IP multicasting” Updates since the version (IETF-62) Proposal/ next steps

3 IP multicasting – network operator’s expectations Network operators want –to have the same management capabilities as unicast while expecting network resource efficiency from multicasting –to apply it to information distribution services (e.g., CDN, video/audio streaming) –to create value-added services for which they can charge –to build a manageable network on which they can grasp what is happening

4 Content providers want –Affordable infrastructure/ service provision –High reliability and good QoS –Controlled access to content + protected content –Detailed usage info (for billing, advertising, programming decisions, etc.) End users want –Reliable service –Portability –Low latency –Quick feedback (about usage) IP multicasting – content provider and user expectations

5 draft-ietf-mboned-maccnt-req-01.txt : updates Updates: Requirements list was refined: –Removed duplication between this draft and “Multicast Issues Draft”. –Requirements items were concentrated to this Draft. Editorial changes were done reflecting feedback.

6 Status/ Proposal/ Next Steps Status: Feedback from ML and IETF sessions has been reflected. New comments received recently. Actions for this I-D: Address the comments and publish the revised draft. Go to Last Call with the revised draft. In addition to this ID, next steps should include: Start discussion on framework for “well managed IP multicasting” as proposed by another draft Find solutions which meet the requirements.

7 EXTRA SLIDES

8 General requirements for well managed multicasting Primary requirements User identification –User authentication/authorization –Accounting and billing Admission control for join/leave actions Access control Network resource protection/bandwidth management Notification to users of the results of their requests Service and terminal portability Quick reaction Derived requirements Support of ASM and SSM Scalability Small impact on the existing products

9 Details on updates A 4(1) added paragraph about problem of sender not being able to distinguish which receivers are actually receiving sent data. 4(2) rearranged points under larger category of "Issue of network resource protection." –added subsections and about bandwidth control for the physical port of edge router or the links between routers and between content servers and multicast routers 4(5) replaced text for the "Accounting and Billing" section with text from draft-hayashi-rac-issues-00.txt 4(6) added section "Notification to users of the result of the join request"

10 Details on updates B 4(9) changed title of section from "Quick Reaction" to “Channel Leave Latency” –adopted much of the text from draft-hayashi-rac- issues-00.txt. 4(12) section “Small impact on the existing products”: Added paragraph stating that there should not be an impact on "triple play" services 4(13) Added section "Deployable as alternative to Unicast"

11 IP multicasting – currently available solutions No accounting capabilities are provided by the current standard (based on IGMP/MLD) –Network cannot identify receivers –Network cannot grasp user activities (when they joined and left) –Network cannot authenticate/authorize users Any user can join without any eligibility check Not sufficient for carrier-class services (high- quality, premium/fee-based) Companion I-D shows applicability of currently available solutions in detail.

12 Well managed IP multicasting e e e 2. Protect content from illicit access 1. Accurate tracking (accounting) of Join/Leave by user, by group Move With device 4. End user should be able to access CDN from anywhere Illegal user User may move and change devices. e Advanced multicast CDN Content key Shared Media 3. Support preview to each group (Content) router Edge node 5. Content key should be delivered to cover each user receiving period. Charging should be based on user reception, not on key holding period Content server 6. Shorten the time from order to service provision. Service provision on-demand is one of the goals of service providers.

13 Content Provider or ISP Content Provider or ISP Architecture example Network Provider End User edge router Content Provider or ISP Content Share for the network provider (usage-based) border router (provider edge) Network operator and content providers cooperate to provide a service. They need to share the content revenue CSP/ISP and NSP can be different entities or the same entity. Both architectures need to be studied. Share for the content provider (usage-based) There can be more than one content provider