1. 1 Discussion Issues on Receiver Access Control in the Current Multicast Protocols (Update) draft-ietf-mboned-rac-issues-01.txt November 9th, 2005 Tsunemasa Hayashi (hayashi.tsunemasa@lab.ntt.co.jp) Haixiang He (haixiang@nortelnetworks.com) Hiroaki Satou (satou.hiroaki@lab.ntt.co.jp) Hiroshi Ohta(ohta.hiroshi@lab.ntt.co.jp) Susheela Vaidya (svaidya@cisco.com)

2. 2 Introduction Key Point: In our experience, many issues raised in the I-D are NOT currently well covered by existing standards. Goal: In multiple-entity networks, to achieve the same capabilities such as access control & accounting used in unicast content delivery while taking advantage of multicasting’s resource efficiencies To achieve admission control

3. 3 Network models edge Content provider function Network provider function Hosts / Users Content provider (CP) and network provider (NP) functions are realized by one company SINGLE ENTITY MODEL edge Content Provider A Content Provider N Network Provider A Content providers and the network providers are different companies MULTIPLE ENTITY MODEL A user may subscribe to more than one Content Provider A user subscribes to only one CP (NP) Hosts / Users AAA Multicasting and QoS Mgt AAA Multicasting QoS Mgt AAA

4. 4 Major Changes -updated draft-hayashi-rac-issues-01.txt to draft-ietf- mboned-rac-issues-00/01.txt based on WG comments. -remove unnecessary overlap with the requirement draft (draft-ietf- mboned-mac-req-01.txt) -4.1 Access limits and resource issues -4.3 Capability to distinguish between users -change the title of 5.2 to clarify the method -“IGMP/MLD plus L2/L3 Authentication with Access Control Policy “ -add detail description to “IGMP/MLD with unicast control “ in 6.1 -malicious users may send join in disregard of unicast control -add detail description to “L2/L3 authentication with access control policy” in 6.4 Maintain guaranteed QoS -NW login/out based QoS control, not stream request based (Continued on next slide)

5. 5 Major Changes (continued) -remove 6.8 “Triple Play capability, compared by architecture” -Capability of triple play is independent of architecture. -add 6.8 “Comparison summary ” -To clarify arguments of this I-D -add draft-ietf-mboned-mac-req-01.txt to “Normative References”

6. 6 Issues with current architectures (yes=satisfies the major requirements) Access Control Bandwidth (QoS) Mgt. Cooperation between NP’s mcast/QoS and CP-AAA Distinguish Users Fast Join and Leave IGMP/MLD with AAA No: not user based YesYes but NP has to disclose NW config. as user id. (e.g. RT address & IF index) to CP to control multicast. Yes L2/L3 Auth. with Policy Download YesNo: Not ch. req. based (login/logo ut base) No: difficult to support floating IP address Yes EtoE Unicast Signaling (http Auth. with IGMP/MLD) No: host reconfiguration and illicit JOIN is possible No: No cooperation (EtoE controls pass through NP) YesNo: EtoE control Delay Multicast Key Distribution with AAA No: host reconfiguration and illicit JOIN is possible No: No cooperation (EtoE controls pass through NP) YesNo: EtoE control Delay Current architectures do NOT fully cover requirements

7. 7 CONCLUSION Key Point: - Currently many operational issues raised in the I-D are NOT perfectly covered by existing standards. Goals: -In multiple-entity networks, -to achieve same operational capabilities such as access control & accounting used in unicast content delivery while taking advantage of multicasting’s resource efficiencies -To achieve admission control capabilities. Next Steps: -To update this I-D reflecting comments in ML and this meeting -To start discussion on multicast AAA frameworks for multiple- entity networks.