Transcript PPT Version

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])
1
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
2
Network models
SINGLE ENTITY MODEL
MULTIPLE ENTITY MODEL
Content provider (CP) and
network provider (NP) functions
are realized by one company
Content providers and the network
providers are different companies
Content
provider function
Network
provider
function
AAA
Multicasting
QoS Mgt
edge
edge
Content
Provider A
Content
Provider N
AAA
AAA
Network Provider A
Multicasting and QoS Mgt
edge
edge
Hosts / Users
A user subscribes to
only one CP (NP)
Hosts / Users
A user may subscribe to
more than one Content Provider
3
Major Changes
- updated draft-hayashi-rac-issues-01.txt to draft-ietfmboned-rac-issues-00/01.txt based on WG comments.
- remove unnecessary overlap with the requirement draft (draft-ietfmboned-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)
4
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”
5
Issues with current architectures
•Current architectures do NOT fully cover requirements
IGMP/MLD with
AAA
Access
Control
Bandwidth Cooperation between
(QoS) Mgt. NP’s mcast/QoS and
CP-AAA
No: not
user
based
Yes
L2/L3 Auth. with Yes
Policy Download
Distinguish Fast Join
Users
and Leave
Yes but NP has to disclose NW
config. as user id. (e.g. RT address
& IF index) to CP to control
multicast.
No: Not ch. No: difficult to support
req. based floating IP address
(login/logo
ut base)
Yes
Yes
Yes
EtoE Unicast
Signaling (http
Auth. with
IGMP/MLD)
No: host
No: No cooperation
reconfiguration and
(EtoE controls pass
illicit JOIN is possible through NP)
Yes
No: EtoE
control
Delay
Multicast Key
Distribution with
AAA
No: host
No: No cooperation
reconfiguration and
(EtoE controls pass
illicit JOIN is possible through NP)
Yes
No: EtoE
control
Delay
(yes=satisfies the major requirements)
6
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 multipleentity networks.
7