Transcript Accounting Issues in Well Managed IP Multicasting Services

Accounting, Authentication and Authorization Issues in
“Well Managed” IP Multicasting Services
<draft-ietf-mboned-maccnt-req-01.txt>
November 9, 2005
Tsunemasa Hayashi ([email protected])
Haixiang He ([email protected])
Hiroaki Satou ([email protected])
Hiroshi Ohta([email protected])
Susheela Vaidya ([email protected])
1
Outline
• Introduce/ review “well managed IP
multicasting”
• Updates since the version <draft-hayashimaccnt-02.txt> (IETF-62)
• Proposal/ next steps
2
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
3
IP multicasting – content provider and user expectations
• 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)
4
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-issues00.txt>.
– Requirements items were concentrated to this
Draft.
• Editorial changes were done reflecting
feedback.
5
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.
6
EXTRA SLIDES
7
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
8
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"
9
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-racissues-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"
10
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 (highquality, premium/fee-based)
• Companion I-D shows applicability of
currently available solutions in detail.
11
Well managed IP multicasting
1. Accurate tracking (accounting)
of Join/Leave by user, by group
Content server
5. Content key should be delivered to
cover each user receiving period.
Charging should be based on user
reception, not on key holding period
Advanced multicast CDN
3. Support preview to
each group (Content)
router
6. Shorten the
time from order
to service
provision.
Service provision
on-demand is
one of the goals
of service
providers.
Edge node
e
Shared Media
Content key
e
e
Move
With
device
e
2. Protect content from
illicit access
Illegal user
User may move and change devices.
4. End user should be able
to access CDN from anywhere
12
Architecture example
• 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.
There can be more than one content provider
Content
Content Provider
Content Provider
Content Provider
or
or
or ISP
ISP
ISP
Share for the network provider (usage-based)
Share for the content provider (usage-based)
border router
(provider edge)
Network Provider
edge router
End User
End User
13