1

Accounting, Authentication and Authorization Issues in “Well Managed” IP Multicasting Services

<draft-ietf-mboned-maccnt-req-01.txt>

November 9, 2005

Tsunemasa Hayashi (hayashi.tsunemasa@lab.ntt.co.jp)Haixiang He (haixiang@nortel.com)

Hiroaki Satou (satou.hiroaki@lab.ntt.co.jp)Hiroshi Ohta(ohta.hiroshi@lab.ntt.co.jp)Susheela Vaidya (svaidya@cisco.com)

2

Outline

• Introduce/ review “well managed IP multicasting”

• Updates since the version <draft-hayashi-maccnt-02.txt> (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, progra

mming 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” <draft-hayashi-rac-issues-00.txt>.

– 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 4.2.2 and 4.2.3 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 ee 2. Protect content from

illicit access2. Protect content from illicit access

1. Accurate tracking (accounting)of Join/Leave by user, by group1. Accurate tracking (accounting)of Join/Leave by user, by group

MoveWith

device

4. End user should be able to access CDN from anywhere4. 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)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

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.

6. Shorten the time from order to service provision. Service provision on-demand is one of the goals of service providers.

13

Content Provideror

ISP

Content Provideror

ISP

Architecture example

Network Provider

End User End User

edge router

Content Provideror

ISPContent

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