draft-ietf-mboned-maccnt-req-03.txt   draft-ietf-mboned-maccnt-req-04.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Internet Draft Haixiang He, Nortel
Document:draft-ietf-mboned-maccnt-req-03.txt Hiroaki Satou, NTT Document:draft-ietf-mboned-maccnt-req-04.txt Hiroaki Satou, NTT
Expires: July 14, 2006 Hiroshi Ohta, NTT Expires: August 12, 2006 Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
January 10, 2006 February 8, 2006
Requirements for Accounting, Authentication and Authorization in Requirements for Accounting, Authentication and Authorization in
Well Managed IP Multicasting Services Well Managed IP Multicasting Services
<draft-ietf-mboned-maccnt-req-03.txt> <draft-ietf-mboned-maccnt-req-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 38 skipping to change at line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 14, 2006. This Internet-Draft will expire on August 12, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006) Copyright (C) The Internet Society (2006)
Abstract Abstract
This memo presents requirements in the area of accounting and This memo presents requirements in the area of accounting and
access control for multicasting. General requirements for access control for multicasting. General requirements for
Hayashi, He, Satou, Ohta and Vaidya [Page 1.]
accounting capabilities including quality-of-service (QoS) related accounting capabilities including quality-of-service (QoS) related
issues are listed. Finally, cases for Content Delivery Services issues are listed. Finally, cases for Content Delivery Services
(CDS) are described as application examples which could benefit (CDS) are described as application examples which could benefit
from multicasting accounting and access control capabilities as from multicasting accounting and access control capabilities as
described in the I-D. It is proposed that this I-D be used as a described in the I-D. It is proposed that this I-D be used as a
starting point for further discussion on these issues. starting point for further discussion on these issues.
Table of contents Table of Contents
Copyright Notice.................................................1 Copyright Notice..................................................1
1. Introduction..................................................2 1. Introduction...................................................2
2. Definitions and Abbreviations.................................4 2. Definitions and Abbreviations..................................4
2.1 Definitions..................................................4 2.1 Definitions...................................................4
2.2 Abbreviations................................................4 2.2 Abbreviations.................................................4
3. Problem statement.............................................4 3. Problem Statement..............................................5
3.1 Accounting issues...........................................5 3.1 Accounting Issues............................................5
3.2 Relationship with secure multicasting (MSEC)................6 3.2 Relationship with Secure Multicasting (MSEC).................7
4. General AAA-related functional requirements for IP 3.3 Regarding Access Media and User Separation...................7
multicasting..................................................6 4. General AAA-related Functional Requirements for IP Multicast...7
5. Application example and its specific requirements............10 5. Application Example and its Specific Requirements.............13
5.1 IP Multicast-based Content Delivery Service (CDS): CP and 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP
NSP are different entities (companies)......................10 are different entities (companies)...............................13
5.1.1 Network model for Multicast Content Delivery Service......10 5.1.1 Network Model for Multicast Content Delivery Service.......13
5.1.2 Content Delivery Service Requirements.....................12 5.1.2 Content Delivery Service Requirements......................15
5.1.2.1 Accounting Requirements.................................12 5.1.2.1 Accounting Requirements..................................15
5.1.2.2 Authorization Requirements..............................13 5.1.2.2 Authorization Requirements...............................16
5.1.2.3 Authentication Requirements.............................13 5.1.2.3 Authentication Requirements..............................17
5.2 IP Multicast-based Content Delivery Service (CDS): CP and 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP
NSP are the same entities (companies).......................14 are the same entities (companies)................................17
6. Acknowledgements.............................................15 6. Acknowledgments...............................................18
7. IANA considerations..........................................15 7. IANA Considerations...........................................19
8. Security considerations......................................15 8. Security Considerations.......................................19
9. Conclusion...................................................15 9. Conclusion....................................................19
Normative References............................................15 Normative References.............................................19
Authors' Addresses..............................................15 Authors' Addresses...............................................20
Full Copyright Statement........................................17 Full Copyright Statement.........................................21
Intellectual Property...........................................17 Intellectual Property............................................21
1. Introduction 1. Introduction
This I-D will present general functional requirements related to This I-D will present general functional requirements related to
accounting, authentication and authorization issues in IP accounting, authentication and authorization issues in IP
multicasting networks. A multicast network which fulfills all of multicasting networks. A multicast network which fulfills all of
Hayashi, He, Satou, Ohta and Vaidya [Page 2.]
these requirements will be called a "fully AAA enabled" IP these requirements will be called a "fully AAA enabled" IP
multicasting network. Fulfillment of all or some of the multicasting network. Fulfillment of all or some of the
requirements will make possible more robust management of IP requirements will make possible more robust management of IP
multicasting networks, and as such these capabilities contribute to multicasting networks, and as such these capabilities contribute
the provision of well-managed IP multicasting services. to the provision of well-managed IP multicasting services.
IP multicasting is becoming widely used as a method to save network IP multicasting is becoming widely used as a method to save
resources such as bandwidth or CPU processing power of the sender's network resources such as bandwidth or CPU processing power of the
server for cases where a large volume of information needs to be sender's server for cases where a large volume of information
distributed to a large number of receivers. This trend can be needs to be distributed to a large number of receivers. This trend
observed both in enterprise use and in broadband services provided can be observed both in enterprise use and in broadband services
by network operator/service providers. provided by network operator/service providers.
Distance learning within a university and in-house (in-company) Distance learning within a university and in-house (in-company)
sharing of multimedia information are examples of enterprise use. sharing of multimedia information are examples of enterprise use.
In these examples, sources generate high-bit rate (e.g., 6Mbit/s) In these examples, sources generate high-bit rate (e.g., 6Mbit/s)
streaming information. When the number of receivers becomes large, streaming information. When the number of receivers becomes large,
such systems do not scale well without multicasting. such systems do not scale well without multicasting.
On the other hand, a Content Delivery Service (CDS) is an example On the other hand, a Content Delivery Service (CDS) is an example
of a broadband service provided by network operators/service of a broadband service provided by network operators/service
providers. Distribution of movies and other video programs to each providers. Distribution of movies and other video programs to each
user are typical services. Each channel requires large bandwidth user are typical services. Each channel requires large bandwidth
(e.g., 6Mbit/s) and operator/service providers need to provide many (e.g., 6Mbit/s) and operator/service providers need to provide
channels to make their service attractive. In addition, the number many channels to make their service attractive. In addition, the
of receivers is large (e.g., more than a few thousands). The number of receivers is large (e.g., more than a few thousands).
system to provide this service does not scale well without The system to provide this service does not scale well without
multicasting. multicasting.
As such, multicasting can be useful to make the network more As such, multicasting can be useful to make the network more
scalable when a large volume of information needs to be distributed scalable when a large volume of information needs to be
to a large number of receivers. However, multicasting according to distributed to a large number of receivers. However, multicasting
current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has
compared to unicasting when one applies it to commercial services. drawbacks compared to unicasting when one applies it to commercial
Accounting of each user's actions is not possible with multicasting services. Accounting of each user's actions is not possible with
as it is with unicasting. Accounting consists of grasping each multicasting as it is with unicasting. Accounting consists of
user's behavior, when she/he starts/stops to receive a channel, grasping each user's behavior, when she/he starts/stops to receive
which channel she/he receives, etc. a channel, which channel she/he receives, etc.
IP multicasting can be used to distribute free material efficiently, IP multicasting can be used to distribute free material
but there are limitations to multicasting in usage models where efficiently, but there are limitations to multicasting in usage
usage accounting is necessary, such as many commercial applications.
These limitations have prevented the widespread deployment of Hayashi, He, Satou, Ohta and Vaidya [Page 3.]
multicasting. Alternatively, one could develop and use a models where usage accounting is necessary, such as many
proprietary solution to address this issue. However, non-standard commercial applications. These limitations have prevented the
solutions have drawbacks in terms of interoperability or cost of widespread deployment of multicasting. Alternatively, one could
development and maintenance. develop and use a proprietary solution to address this issue.
However, non-standard solutions have drawbacks in terms of
interoperability or cost of development and maintenance.
Without accounting capability in multicasting, information Without accounting capability in multicasting, information
providers desiring accounting capability are forced to use providers desiring accounting capability are forced to use
unicasting even when multicasting would otherwise be desirable from unicasting even when multicasting would otherwise be desirable
a bandwidth/server resource perspective. If multicasting could be from a bandwidth/server resource perspective. If multicasting
used with user-based accounting capabilities, its applicability could be used with user-based accounting capabilities, its
would be greatly widened. applicability would be greatly widened.
This I-D first describes problems on accounting issues in This I-D first describes problems on accounting issues in
multicasting. Then the general requirements for this capability multicasting. Then the general requirements for this capability
including QoS related issues are listed. Finally, application including QoS related issues are listed. Finally, application
examples which could benefit from multicasting with accounting examples which could benefit from multicasting with accounting
capabilities are shown. It is proposed that this I-D be used as a capabilities are shown. It is proposed that this I-D be used as a
starting point for a discussion on these issues. starting point for a discussion on these issues.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
Authentication: action for identifying a user as a genuine one. Authentication: action for identifying a user as a genuine one.
Authorization: action for giving permission for a user to access Authorization: action for giving permission for a user to access
content or the network. content or the network.
Eligible user: Users may be eligible (permitted) to access
resources because of the attributes they have (e.g., delivery may
require possession of the correct password or digital certificate),
their equipment has (e.g., content may only be eligible to players
that can decode H.264 or 3GPP streams), their edge network has
(e.g., HD content may only be eligible to users with 10 Mbps or
faster edge connections), or because of where they are in network
topology (e.g., HD content may not be eligible for users across
congested links) or in actual geography (e.g., content may only be
Hayashi, He, Satou, Ohta and Vaidya [Page 4.]
licensed for distribution to certain countries), and, of course, a
mix of attributes may be required for eligibility or ineligibility.
User-based accounting: actions for grasping each user's behavior, User-based accounting: actions for grasping each user's behavior,
when she/he starts/stops to receive a channel, which channel she/he when she/he starts/stops to receive a channel, which channel
receives, etc. she/he receives, etc.
2.2 Abbreviations 2.2 Abbreviations
ASM: Any-Source Multicast ASM: Any-Source Multicast
CDS: Content Delivery Service CDS: Content Delivery Service
CP: Content Provider CP: Content Provider
IGMP: Internet Group Management Protocol IGMP: Internet Group Management Protocol
MLD: Multicast Listener Discovery MLD: Multicast Listener Discovery
NSP: Network Service Provider NSP: Network Service Provider
SSM: Single-Source Multicast SSM: Single-Source Multicast
QoS: Quality of Service QoS: Quality of Service
3. Problem statement 3. Problem Statement
3.1 Accounting issues
3.1 Accounting Issues
In unicast communications, the server (information source) can In unicast communications, the server (information source) can
identify the client (information receiver) and only permits identify the client (information receiver) and only permits
connection by an eligible client when this type of access control connection by an eligible client when this type of access control
is necessary. In addition, when necessary, the server can grasp is necessary. In addition, when necessary, the server can grasp
what the client is doing (e.g., connecting to the server, starting what the client is doing (e.g., connecting to the server, starting
reception, what information the client is receiving, terminating reception, what information the client is receiving, terminating
reception, disconnecting from the server). reception, disconnecting from the server).
Hayashi, He, Satou, Ohta and Vaidya [Page 5.]
On the other hand, in multicast communication with current On the other hand, in multicast communication with current
standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its standards (e.g., IGMPv3[1] or MLDv2[2]) the server just feeds its
information to the multicast router [as in Fig.1]. Then, the information to the multicast router [as in Fig.1]. Then, the
multicast router replicates the data to any link which has at least multicast router replicates the data to any link which has at
one client requesting the information. In this process, no least one client requesting the information. In this process, no
eligibility check is conducted. Any client can receive information eligibility check is conducted. Any client can receive information
just by requesting it. In other words, the current standards do just by requesting it. In other words, the current standards do
not provide multicasting with authorization or access control not provide multicasting with authorization or access control
capabilities sufficient to meet the requirements of accounting. capabilities sufficient to meet the requirements of accounting.
+--------+ +--------+
| user |\ | user |\
+--------+ \ +--------+ \
\+------+ +------+ +------+ +------+ \+------+ +------+ +------+ +------+
+--------+ |Multi-| |Multi-| |Multi-| | | +--------+ |Multi-| |Multi-| |Multi-| | |
| user |---|cast |----|cast |----|cast |----|Server| | user |---|cast |----|cast |----|cast |----|Server|
+--------+ |router| |router| |router| | | +--------+ |router| |router| |router| | |
/+------+ +------+ +------+ +------+ /+------+ +------+ +------+ +------+
+--------+ / +--------+ /
| user |/ | user |/
+--------+ +--------+
Fig.1 Example network for multicast communication Fig.1 Example network for multicast communication
This is the major reason why multicasting is only used for cases This is the major reason why multicasting is only used for cases
where no user-based accounting capabilities are necessary. However, where no user-based accounting capabilities are necessary.
since more and more information is transferred over IP-based However, since more and more information is transferred over IP-
networks and some of these applications may require accounting based networks and some of these applications may require
capabilities, it is easy to envision the requirement of supporting accounting capabilities, it is easy to envision the requirement of
such cases. For example, accounting is needed if one wants to supporting such cases. For example, accounting is needed if one
charge for distributed information on a non-flat-fee basis. If the wants to charge for distributed information on a non-flat-fee
volume of information and number of clients are large, it is basis. If the volume of information and number of clients are
beneficial to use multicasting for purposes of network resource large, it is beneficial to use multicasting for purposes of
efficiency. network resource efficiency.
As such, the same level of user-based accounting capabilities as As such, the same level of user-based accounting capabilities as
provided in unicast networks should be provided in multicast provided in unicast networks should be provided in multicast
networks. networks.
3.2 Relationship with secure multicasting (MSEC) Hayashi, He, Satou, Ohta and Vaidya [Page 6.]
3.2 Relationship with Secure Multicasting (MSEC)
In many cases, content encryption (e.g. MSEC) is an effective In many cases, content encryption (e.g. MSEC) is an effective
method for preventing unauthorized access to original content (in method for preventing unauthorized access to original content (in
other words, the ability to decode data to return it to its other words, the ability to decode data to return it to its
generally useable form.) This I-D presents requirements for generally usable form.) This I-D presents requirements for
multicasting networks in the areas of 1) access control to prevent multicasting networks in the areas of 1) access control to prevent
unauthorized access to the network, and 2) accounting to grasp user unauthorized access to the network, and 2) accounting to grasp
activity. The functional requirements do not require content user activity. The functional requirements do not require content
encryption although it might solve some of the related problems. encryption although it might solve some of the related problems.
At this point, it is not yet clear whether encryption would be part At this point, it is not yet clear whether encryption would be
of a solution and if so, what other components (if any) would also part of a solution and if so, what other components (if any) would
be required. also be required.
4. General AAA-related functional requirements for IP multicasting 3.3 Regarding Access Media and User Separation
The requirements defined in this memo apply to solutions that
provide user separation either through physical separation
provided by dedicated access media between the user and multicast
router (see Fig. 1) or else through logical separation in cases
of shared physical access media (e.g. using VLAN). However, IP
multicast solutions with shared Layer 2 access media between the
user and multicast router and no logical user separation (e.g.
Ethernet with shared links and no VLAN) are out of scope of this
memo. Nevertheless, some of the requirements in this memo defined
for multicasting may also be relevant to multicasting over links
without either physical or logical user separation. Therefore in
the interest of modularity and flexibility, solutions addressing
the requirements of this memo may also take into account
application to multicasting without such user separation.
4. General AAA-related Functional Requirements for IP Multicasting
In consideration of the issues presented in section 3, the In consideration of the issues presented in section 3, the
following requirements have been derived: following requirements have been derived:
(1) User identification (1) User identification
The network should be able to identify each user when they attempt The network should be able to identify each user when they attempt
to access the service so that necessary access controlling actions to access the service so that necessary access controlling actions
Hayashi, He, Satou, Ohta and Vaidya [Page 7.]
can be applied. Also, it is necessary to identify the source can be applied. Also, it is necessary to identify the source
(user) of each request (e.g., join/leave) for user accounting (user) of each request (e.g., join/leave) for user accounting
purposes. purposes.
With current protocols (IGMP/MLD), the sender cannot distinguish With current protocols (IGMP/MLD), the sender cannot distinguish
which receivers (end hosts) are actually receiving the information. which receivers (end hosts) are actually receiving the information.
The sender must rely on the information from the multicasting The sender must rely on the information from the multicasting
routers. This can be complicated if the sender and routers are routers. This can be complicated if the sender and routers are
maintained by different entities. maintained by different entities.
(2) Issue of network resource protection (2) Issue of Network Resource Protection
In order to guarantee certain QoS it is important for network In order to guarantee certain QoS it is important for network
providers to be able to protect their network resources from being providers to be able to protect their network resources from being
wasted, (either maliciously or accidentally). wasted, (either maliciously or accidentally).
For comparisons sake, in the case of unicast this issue can be For comparisons sake, in the case of unicast this issue can be
resolved e.g. by using RSVP. resolved e.g. by using RSVP.
(2.1) Access control (2.1) Access control
The network should be able to apply necessary access controlling The network should be able to apply necessary access controlling
actions when an eligible user requests. The network should be able actions when an eligible user requests an action (such as a join
to reject any action requested from an ineligible user. or a leave.) The network should be able to reject any action
requested from an ineligible user.
(2.2) Control mechanism to support bandwidth of multicast stream (2.2) Control mechanism to support bandwidth of multicast stream
from a physical port of edge router or switch from a physical port of edge router or switch
The network may need to control the combined bandwidth for all The network may need to control the combined bandwidth for all
groups at the physical port of the edge router or switch so that groups at the physical port of the edge router or switch so that
these given physical entities are not overflowed with traffic. these given physical entities are not overflowed with traffic.
(2.3) Control mechanism of number of groups delivered from a (2.3) Control mechanism of number of groups delivered from a
physical port of edge router and switch physical port of edge router and switch
If an NSP desires to guarantee a certain level of QoS to CP and the Hayashi, He, Satou, Ohta and Vaidya [Page 8.]
receivers, it is necessary that the NSP be able to control the If an NSP desires to guarantee a certain level of QoS to CP and
the receivers, it is necessary that the NSP be able to control the
number of groups delivered from a physical port of an edge router number of groups delivered from a physical port of an edge router
and a switch so that the combined bandwidth between content servers and a switch so that the combined bandwidth between content
and multicast routers can be within the limit. servers and multicast routers can be within the limit.
For comparisons sake, in the case of unicast this issue can be For comparisons sake, in the case of unicast this issue can be
resolved e.g. by using RSVP. resolved e.g. by using RSVP.
(3) User authentication (3) User Authentication
The network should be able to authenticate a user. The network should be able to authenticate a user.
(4) User authorization (4) User Authorization
The network, at its option, should be able to authorize a user's The network, at its option, should be able to authorize a user's
access to content or a multicast group, so as to meet any demands access to content or a multicast group, so as to meet any demands
by a CP to prevent content access by ineligible users. In the case by a CP to prevent content access by ineligible users. In the case
that the NSP may wish to provide a service based on guaranteed that the NSP may wish to provide a service based on guaranteed
delivery, the NSP would not want to waste its network resources on delivery, the NSP would not want to waste its network resources on
ineligible users. Eligibility can be defined in several ways. The ineligible users.
definition of an "eligible user" should be discussed further.
(5) Accounting and billing (5) Accounting and Billing
In many commercial multicast situations, NSPs would like to be able In many commercial multicast situations, NSPs would like to be
to precisely grasp network resource consumption and CPs would like able to precisely grasp network resource consumption and CPs would
to be able to precisely grasp the content consumption by end-users. like to be able to precisely grasp the content consumption by end-
Such information might be used for identifying highly viewed users. Such information might be used for identifying highly
content for advertising revenue, ratings calculations, programming viewed content for advertising revenue, ratings calculations,
decisions, etc., as well as billing and auditing purposes. Also programming decisions, etc., as well as billing and auditing
content and network providers may wish to provide users with access purposes. Also content and network providers may wish to provide
to their usage history. users with access to their usage history.
To assemble such an understanding of end-user behavior, it is To assemble such an understanding of end-user behavior, it is
necessary to precisely log information such as who (host/user) is necessary to precisely log information such as who (host/user) is
accessing what content at what time (join action) until what time accessing what content at what time (join action) until what time
(leave action). The result of the access-control decision (e.g. (leave action). The result of the access-control decision (e.g.
results of authorization) would also be valuable information. The results of authorization) would also be valuable information. The
Hayashi, He, Satou, Ohta and Vaidya [Page 9.]
desired degree of logging precisions would depend on the desired degree of logging precisions would depend on the
application used. application used.
(5.1) How to share user information (5.1) How to share user information
For commercial multicast applications it is important for NSP and For commercial multicast applications it is important for NSP and
CP to be able to share information regarding user's behaviour (as CP to be able to share information regarding user's behaviour (as
described in (5) in standardized ways. described in (5) in standardized ways.
(6) Notification to users of the result of the join request (6) Notification to Users of the Result of the Join Request
It should be possible to provide information to the user about the It should be possible to provide information to the user about the
status of his/her join request(granted/denied/other). status of his/her join request(granted/denied/other).
(7) Service and terminal portability (7) Service and Terminal Portability
Depending on the service, networks should allow for a user to Depending on the service, networks should allow for a user to
receive a service from different places and/or with a different receive a service from different places and/or with a different
terminal device. terminal device.
(8) Support of ASM and SSM (8) Support of ASM and SSM
Both ASM (G), and SSM (S,G) should be supported as multicast models. Both ASM (G), and SSM (S,G) should be supported as multicast
models.
(9) Admission control for join action (9) Admission Control for Join Action
In order to maintain a predefined QoS level, depending on the NSP's In order to maintain a predefined QoS level, depending on the
policy, an edge router should be able to control the number of NSP's policy, an edge router should be able to control the number
streams it serves to a user, and total bandwidth consumed to that of streams it serves to a user, and total bandwidth consumed to
user. For example if the number of streams being served to a that user. For example if the number of streams being served to a
certain user has reached the limit defined by the NSP's policy, certain user has reached the limit defined by the NSP's policy,
then the edge router should not accept a subsequent "join" until then the edge router should not accept a subsequent "join" until
one of the existing streams is terminated. Similarly, if the NSP one of the existing streams is terminated. Similarly, if the NSP
is controlling by per-user bandwidth consumption, then a subsequent is controlling by per-user bandwidth consumption, then a
"join" should not be accepted if delivery of the requested stream subsequent "join" should not be accepted if delivery of the
would push the consumed bandwidth over the NSP policy-defined limit.
Hayashi, He, Satou, Ohta and Vaidya [Page 10.]
requested stream would push the consumed bandwidth over the NSP
policy-defined limit.
(10) Channel Join Latency and Leave Latency (10) Channel Join Latency and Leave Latency
Commercial implementations of IP multicasting are likely to have Commercial implementations of IP multicasting are likely to have
strict requirements in terms of user experience. Join latency is strict requirements in terms of user experience. Join latency is
the time between when a user sends a "join" request and when the the time between when a user sends a "join" request and when the
requested data streaming first reaches the user. Leave latency is requested data streaming first reaches the user. Leave latency is
the time between when a user sends a "leave" signal and when the the time between when a user sends a "leave" signal and when the
network stops streaming to the user. network stops streaming to the user.
Leave and Join latencies impact the acceptable end-user experience Leave and Join latencies impact the acceptable end-user experience
for fast channel surfing. In an IP-TV application, users are not for fast channel surfing. In an IP-TV application, users are not
going to be receptive to a slow response time when changing going to be receptive to a slow response time when changing
channels. If there are policies for controlling the number of channels. If there are policies for controlling the number of
simultaneous streams a user may access then channel surfing will be simultaneous streams a user may access then channel surfing will
determined by the join and leave latencies. be determined by the join and leave latencies.
Furthermore, leave affects resource consumption: with a low "leave Furthermore, leave affects resource consumption: with a low "leave
latency" network providers could minimize streaming content when latency" network providers could minimize streaming content when
there are no audiences. there are no audiences.
It is important that any overhead for authentication, authorization, It is important that any overhead for authentication,
and access-control be minimized at the times of joining and leaving authorization, and access-control be minimized at the times of
multicast groups so as to achieve join and leave latencies joining and leaving multicast groups so as to achieve join and
acceptable in terms of user experience. For example this is leave latencies acceptable in terms of user experience. For
important in an IP-TV application, because users are not going to example this is important in an IP-TV application, because users
be receptive to a slow response time when changing channels. are not going to be receptive to a slow response time when
changing channels.
(11) Scalability (11) Scalability
Solutions that are used for well managed IP multicasting should Solutions that are used for well managed IP multicasting should
scale enough to support the needs of content providers and network scale enough to support the needs of content providers and network
operators. operators.
(12) Small impact on the existing products (12) Small Impact on the Existing Products
Hayashi, He, Satou, Ohta and Vaidya [Page 11.]
Impact on the existing products (e.g., protocols, software, etc.) Impact on the existing products (e.g., protocols, software, etc.)
should be as minimal as possible. should be as minimal as possible.
Ideally the NSP should be able to use the same infrastructure (such Ideally the NSP should be able to use the same infrastructure
as access control) to support commercial multicast services for the (such as access control) to support commercial multicast services
so called "triple play" services: voice (VoIP), video, and for the so called "triple play" services: voice (VoIP), video, and
broadband Internet access services. broadband Internet access services.
(13) Deployable as alternative to Unicast When a CP requires the NSP to provide a level of QoS surpassing
"best effort" delivery or to provide special services (e.g., to
limited users with specific attributes), certain parameters of the
CDS may be defined by a contractual relation between the NSP and
the CP. However, just as for best-effort unicast, multicast allows
for content sourced by CPs without a contractual relation with the
NSP. Therefore, solutions addressing the requirements defined in
this memo should not make multicasting without AAA features
obsolete. NSPs may offer tiered services, with higher
QOS,accounting, authentication, etc., depending on contractual
relation with the CPs. It is therefore important that Multicast
AAA and QoS functions be as modular and flexible as possible.
(13) Deployable as Alternative to Unicast
IP Multicasting would ideally be available as an alternative to IP IP Multicasting would ideally be available as an alternative to IP
unicasting when the "on-demand" nature of unicasting is not unicasting when the "on-demand" nature of unicasting is not
required. Therefore interfaces to multicasting should allow for required. Therefore interfaces to multicasting should allow for
easy integration into CDS systems that support unicasting. easy integration into CDS systems that support unicasting.
Especially equivalent interfaces for authorization, access control Especially equivalent interfaces for authorization, access control
and accounting capabilities should be provided. and accounting capabilities should be provided.
(14) Multicast replication (14) Multicast Replication
The above requirements should also apply if multicast replication The above requirements should also apply if multicast replication
is being done on an access-node (e.g. DSLAMs or OLTs). is being done on an access-node (e.g. DSLAMs or OLTs).
Specific functional requirements for each application can be Specific functional requirements for each application can be
derived from the above general requirements. An example is shown derived from the above general requirements. An example is shown
in the section 5. in the section 5.
5. Application example and its specific requirements Hayashi, He, Satou, Ohta and Vaidya [Page 12.]
5. Application Example and its Specific Requirements
This section shows an application example which could benefit from This section shows an application example which could benefit from
multicasting. Then, specific functional requirements related to multicasting. Then, specific functional requirements related to
user-based accounting capabilities are derived. user-based accounting capabilities are derived.
5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are
different entities (companies) different entities (companies)
Broadband access networks such as ADSL (Asymmetric Digital Broadband access networks such as ADSL (Asymmetric Digital
Subscriber Line) or FTTH (Fiber to the Home) have been deployed Subscriber Line) or FTTH (Fiber to the Home) have been deployed
skipping to change at page 10, line 42 skipping to change at line 517
require huge bandwidth (e.g., 6Mbit/s) and processing power at require huge bandwidth (e.g., 6Mbit/s) and processing power at
content server, IP multicast is used as an efficient delivery content server, IP multicast is used as an efficient delivery
mechanism for CDS. mechanism for CDS.
One way to provide high quality CDS is to use closed networks One way to provide high quality CDS is to use closed networks
("walled-garden" model). ("walled-garden" model).
This subsection shows an example where CP and NSP are different This subsection shows an example where CP and NSP are different
entities (companies). entities (companies).
5.1.1 Network model for Multicast Content Delivery Service 5.1.1 Network Model for Multicast Content Delivery Service
As shown in Fig.2, networks for CDS contain three different types As shown in Fig.2, networks for CDS contain three different types
of entities: Content Provider (CP), Network Service Provider (NSP), of entities: Content Provider (CP), Network Service Provider (NSP),
and end user clients. An NSP owns the network resources and end user clients. An NSP owns the network resources
(infrastructure). It accommodates content providers on one side and (infrastructure). It accommodates content providers on one side
accommodates end user clients on the other side. NSP provides the and accommodates end user clients on the other side. NSP provides
network for CDS to two other entities (i.e., CPs and end user the network for CDS to two other entities (i.e., CPs and end user
clients). A CP provides content to each end-user client through the clients). A CP provides content to each end-user client through
network of NSPs. NSPs are responsible for delivering the content to the network of NSPs. NSPs are responsible for delivering the
end user clients, and for controlling the network resources. content to end user clients, and for controlling the network
resources.
Hayashi, He, Satou, Ohta and Vaidya [Page 13.]
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| CP | | CP | | CP | | CP | | CP | | CP |
| #1 | | #2 | | #3 | | #1 | | #2 | | #3 |
| +---------+ | | +---------+ | | +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | content | | | | content | | | | content | | | | content | | | | content | | | | content | |
| | server | | | | server | | | | server | | | | server | | | | server | | | | server | |
| +-------+-+ | | +----+----+ | | +-+-------+ | | +-------+-+ | | +----+----+ | | +-+-------+ |
+----------\--+ +------|------+ +--/----------+ +----------\--+ +------|------+ +--/----------+
\ | / \ | /
\ | / <- network/network \ | / <- network/network
skipping to change at page 11, line 48 skipping to change at line 570
End user A End user B End user C End user A End user B End user C
Fig.2 Example of CDS network configuration Fig.2 Example of CDS network configuration
The NSP provides the information server for all multicast channels, The NSP provides the information server for all multicast channels,
and a CP gives detailed channel information (e.g., Time table of and a CP gives detailed channel information (e.g., Time table of
each channel) to the information server. An end-user client gets each channel) to the information server. An end-user client gets
the information from the information server. In this model, the information from the information server. In this model,
multicast is used in the NSP's CDS network, and there are two multicast is used in the NSP's CDS network, and there are two
different contracts. One is the contract between the NSP and the different contracts. One is the contract between the NSP and the
Hayashi, He, Satou, Ohta and Vaidya [Page 14.]
end user which permits the user to access the basic network end user which permits the user to access the basic network
resources of the NSP. Another contract is between the CP and end resources of the NSP. Another contract is between the CP and end
user to permit the user to subscribe to multicast content. Because user to permit the user to subscribe to multicast content. Because
the CP and NSP are different entities, and the NSP generally does the CP and NSP are different entities, and the NSP generally does
not allow a CP to control (operate) the network resources of the not allow a CP to control (operate) the network resources of the
NSP, user authorization needs to be done by the CP and NSP NSP, user authorization needs to be done by the CP and NSP
independently. Since there is no direct connection to the independently. Since there is no direct connection to the
user/network interface, the CP cannot control the user/network user/network interface, the CP cannot control the user/network
interface. An end user may want to move to another place, or may interface. An end user may want to move to another place, or may
want to change her/his device (client) anytime without interrupting want to change her/his device (client) anytime without
her/his reception of services. As such, IP Multicast network interrupting her/his reception of services. As such, IP Multicast
should support portability capabilities. network should support portability capabilities.
5.1.2 Content Delivery Service Requirements 5.1.2 Content Delivery Service Requirements
To have a successful business providing multicast, there are some To have a successful business providing multicast, there are some
specific requirements for the IP Multicast-based Content Delivery specific requirements for the IP Multicast-based Content Delivery
Service. Service.
5.1.2.1 Accounting Requirements 5.1.2.1 Accounting Requirements
Since the CP and NSP are different business entities, they need to Since the CP and NSP are different business entities, they need to
share the revenue. Such a revenue sharing business relationship share the revenue. Such a revenue sharing business relationship
requires accurate and near real-time accounting information about requires accurate and near real-time accounting information about
the end user clients' activity on accessing the content services. the end user clients' activity on accessing the content services.
The accounting information should be per content/usage-base to The accounting information should be per content/usage-base to
enable varied billing and charging methods. enable varied billing and charging methods.
The user accessing particular content is represented by the user's The user accessing particular content is represented by the user's
activities of joining or leaving the corresponding multicast activities of joining or leaving the corresponding multicast
group/channel (<g> or <s,g>). In multicast networks, only NSPs can group/channel (<g> or <s,g>). In multicast networks, only NSPs can
collect group joining or leaving activities in real-time through collect group joining or leaving activities in real-time through
their last-hop multicast access edge devices. The NSPs can transfer their last-hop multicast access edge devices. The NSPs can
the accounting information to related CPs for them to generate end transfer the accounting information to related CPs for them to
user billing information. The normal AAA technology can be used to generate end user billing information. The normal AAA technology
transfer the accounting information. can be used to transfer the accounting information.
To match the accounting information with a particular end-user To match the accounting information with a particular end-user
client, the end-user client has to be authenticated. Usually the client, the end-user client has to be authenticated. Usually the
Hayashi, He, Satou, Ohta and Vaidya [Page 15.]
account information of an end-user client for content access is account information of an end-user client for content access is
maintained by the CP. An end user client may have different user maintained by the CP. An end user client may have different user
accounts for different CPs. The account is usually in the format of accounts for different CPs. The account is usually in the format
(username, password) so an end user client can access the content of (username, password) so an end user client can access the
services from anywhere. For example, an end user client can access content services from anywhere. For example, an end user client
the CP from different NSPs. It should be noted that the user can access the CP from different NSPs. It should be noted that the
account used for content access can be different from the one used user account used for content access can be different from the one
for network access maintained by NSPs. used for network access maintained by NSPs.
The NSP-CP model represents a multi-domain AAA environment. There The NSP-CP model represents a multi-domain AAA environment. There
are plural cases of the model depending on the trust relationship are plural cases of the model depending on the trust relationship
between the NSP and CP, and additional service requirements such as between the NSP and CP, and additional service requirements such
a certain QoS level guarantee or service/terminal portability. as a certain QoS level guarantee or service/terminal portability.
A mechanism is necessary to allow a CP and NSP to grasp each user's A mechanism is necessary to allow a CP and NSP to grasp each
behavior independently. user's behavior independently.
Another requirement related to accounting is the ability to notify Another requirement related to accounting is the ability to notify
a user when accounting really starts. When a "free preview" a user when accounting really starts. When a "free preview"
capability is supported, accounting may not start at the same time capability is supported, accounting may not start at the same time
as the user's joining of the stream. as the user's joining of the stream.
5.1.2.2 Authorization Requirements 5.1.2.2 Authorization Requirements
The NSPs are responsible for delivering content and are required to The NSPs are responsible for delivering content and are required to
meet certain QoS levels or SLA (service level agreements). For meet certain QoS levels or SLA (service level agreements). For
skipping to change at page 13, line 31 skipping to change at line 653
existing (i.e., already joined) user for bad services. For example, existing (i.e., already joined) user for bad services. For example,
if an access line is shared by several users, an additional user's if an access line is shared by several users, an additional user's
join may cause performance degradation for other users. If the join may cause performance degradation for other users. If the
incoming user is the first user on an edge node, this will initiate incoming user is the first user on an edge node, this will initiate
the transmission of data between the multicast router and the edge the transmission of data between the multicast router and the edge
node and this extra network traffic may cause performance node and this extra network traffic may cause performance
degradation. There may also be policies that do not necessarily degradation. There may also be policies that do not necessarily
give highest priority to the "first-come" users, and these should give highest priority to the "first-come" users, and these should
also be considered. also be considered.
Hayashi, He, Satou, Ohta and Vaidya [Page 16.]
In order to protect network resources against misuse/malicious In order to protect network resources against misuse/malicious
access and maintain a QoS level, appropriate admission control access and maintain a QoS level, appropriate admission control
function for traffic policing purposes is necessary so that the NSP function for traffic policing purposes is necessary so that the NSP
can accept or reject the request without degrading the QoS beyond can accept or reject the request without degrading the QoS beyond
the specified level. the specified level.
5.1.2.3 Authentication Requirements 5.1.2.3 Authentication Requirements
There are two different aims of authentication. One is There are two different aims of authentication. One is
authentication for network access, and another one is for content authentication for network access, and another one is for content
access. For the first case of authentication, NSP has a AAA server, access. For the first case of authentication, NSP has a AAA server,
and for the second case, each CP has a AAA server. In some cases, and for the second case, each CP has a AAA server. In some cases,
CPs delegate (outsource) the operation of user authentication to CPs delegate (outsource) the operation of user authentication to
NSPs. NSPs.
As such, in addition to network access, multicast group access by a As such, in addition to network access, multicast group access by
user also needs to be authenticated. Content authentication should a user also needs to be authenticated. Content authentication
support the models where: should support the models where:
- authentication for multicast content is outsourced to the - authentication for multicast content is outsourced to the
NSP. NSP.
- authentication for multicast content access is operated by - authentication for multicast content access is operated by
the content provider the content provider
5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are
the same entities (companies) the same entities (companies)
Another application example is the case where the content provider Another application example is the case where the content provider
(CP) and network service provider (NSP) are the same entity (CP) and network service provider (NSP) are the same entity
(company) as shown in Fig. 3. In the case that the CP and NSP are (company) as shown in Fig. 3. In the case that the CP and NSP are
the same entity, some of the requirements indicated in 4.1 are not the same entity, some of the requirements indicated in 4.1 are not
skipping to change at page 14, line 23 skipping to change at line 692
(company) as shown in Fig. 3. In the case that the CP and NSP are (company) as shown in Fig. 3. In the case that the CP and NSP are
the same entity, some of the requirements indicated in 4.1 are not the same entity, some of the requirements indicated in 4.1 are not
required. required.
This model does not require the following items: This model does not require the following items:
- Communication method between sender (server) and user (end - Communication method between sender (server) and user (end
host). Since they belong to the same company, they can use host). Since they belong to the same company, they can use
all the available information. all the available information.
Hayashi, He, Satou, Ohta and Vaidya [Page 17.]
- Methods to share user-related information between network - Methods to share user-related information between network
providers and content providers. providers and content providers.
+-----------------------------------------------------+ +-----------------------------------------------------+
| +---------+ | | +---------+ |
| | content | | | | content | |
| | server | | | | server | |
| +----+----+ | | +----+----+ |
| | | | | |
| CP+NSP +-------+-------+ | | CP+NSP +-------+-------+ |
| | Provider Edge | | | | Provider Edge | |
skipping to change at page 15, line 4 skipping to change at line 720
+----------- / --- | --- \ ---------------------------+ +----------- / --- | --- \ ---------------------------+
/ | \ / | \
/ | \ <- user/network interface / | \ <- user/network interface
/ | \ / | \
+---------++ +-----+----+ ++---------+ +---------++ +-----+----+ ++---------+
|user #a | |user #b | |user #c | |user #a | |user #b | |user #c |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
End user A End user B End user C End user A End user B End user C
Fig.3 Example of CDS network configuration Fig.3 Example of CDS network configuration
6. Acknowledgements
6. Acknowledgments
The authors of this draft would like to express their appreciation The authors of this draft would like to express their appreciation
to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert to Pekka Savola of Netcore Ltd., Daniel Alvarez, and Toerless
of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper, Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of
Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T- Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai
Systems, as well as the participants of the MBONED WG in general. Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Empresas,
Marshall Eubanks of Multicast Techno, Stephen Rife of NTT and
David Meyer in his role as mboned WG chair, as well as their
thanks to the participants of the MBONED WG in general.
Hayashi, He, Satou, Ohta and Vaidya [Page 18.]
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
7. IANA considerations 7. IANA Considerations
This I-D does not raise any IANA consideration issues. This I-D does not raise any IANA consideration issues.
8. Security considerations 8. Security Considerations
Accounting capabilities can be used to enhance the security of Accounting capabilities can be used to enhance the security of
multicast networks by excluding ineligible clients from the multicast networks by excluding ineligible clients from the
networks. networks.
9. Conclusion 9. Conclusion
This I-D describes general requirements for providing "well This I-D describes general requirements for providing "well
managed" IP multicasting services. It lists issues related to managed" IP multicasting services. It lists issues related to
accounting, authentication, authorization and admission control for accounting, authentication, authorization and admission control
multicast content delivery. Content Delivery Services with for multicast content delivery. Content Delivery Services with
different business models is cited as an application which could different business models is cited as an application which could
benefit from the capabilities of "well managed" IP multicasting benefit from the capabilities of "well managed" IP multicasting
described in this document. described in this document.
It is proposed that this document be used as a starting point for It is proposed that this document be used as a starting point for
discussing requirements for "well managed" IP multicasting services. discussing requirements for "well managed" IP multicasting
services.
Normative References Normative References
[1] B. Cain, et. al., "Internet Group Management Protocol, Version [1] B. Cain, et. al., "Internet Group Management Protocol, Version
3", RFC3376, October 2002. 3", RFC3376, October 2002.
[2] R. Vida, et. al., "Multicast Listener Discovery Version 2 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC3810, June 2004. (MLDv2) for IPv6", RFC3810, June 2004.
Hayashi, He, Satou, Ohta and Vaidya [Page 19.]
Authors' Addresses Authors' Addresses
Tsunemasa Hayashi Tsunemasa Hayashi
NTT Network Innovation Laboratories NTT Network Innovation Laboratories
1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
Phone: +81 46 859 8790 Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp Email: hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He Haixiang He
Nortel Nortel
skipping to change at page 17, line 4 skipping to change at line 799
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
Phone: +81 422 59 3617 Phone: +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Susheela Vaidya Susheela Vaidya
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Drive San Jose, CA 95134 170 W. Tasman Drive San Jose, CA 95134
Phone: +1 408 525 1952 Phone: +1 408 525 1952
Email: svaidya@cisco.com Email: svaidya@cisco.com
Hayashi, He, Satou, Ohta and Vaidya [Page 20.]
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
skipping to change at page 17, line 29 skipping to change at line 826
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the IETF's procedures with respect to such rights. Information on the procedures with respect to rights
rights in IETF Documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be required
this standard. Please address the information to the IETF at ietf to implement this standard. Please address the information to the
ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Hayashi, He, Satou, Ohta and Vaidya [Page 21.]
 End of changes. 77 change blocks. 
176 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/