1 discussion issues on receiver access control in the current multicast protocols (update)...
TRANSCRIPT
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 ([email protected])Haixiang He ([email protected])Hiroaki Satou ([email protected])
Hiroshi Ohta([email protected])Susheela Vaidya ([email protected])
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
Network models
edge 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 edge
ContentProvider A
ContentProvider 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
AAAMulticastingQoS Mgt
AAA
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
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
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
Yes Yes 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
Yes No: Not ch. req. based (login/logout base)
No: difficult to support floating IP address
Yes 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)
Yes No: EtoE control Delay
Multicast Key Distribution with AAA
No: host reconfiguration and illicit JOIN is possible
No: No cooperation (EtoE controls pass through NP)
Yes No: EtoE control Delay
•Current architectures do NOT fully cover requirements
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.