draft-ietf-mboned-maccnt-req-05.txt   draft-ietf-mboned-maccnt-req-06.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Internet Draft Haixiang He, Nortel
Document:draft-ietf-mboned-maccnt-req-05.txt Hiroaki Satou, NTT Document:draft-ietf-mboned-maccnt-req-06.txt Hiroaki Satou, NTT
Intended Status: Informational Hiroshi Ohta, NTT Intended Status: Informational Hiroshi Ohta, NTT
Expires: March 22, 2008 Susheela Vaidya, Cisco Systems Expires: December 22, 2008 Susheela Vaidya, Cisco Systems
September 19, 2007 June 20, 2008
Requirements for Multicast AAA coordinated between Content Requirements for Multicast AAA coordinated between Content
Provider(s) and Network Service Provider(s) <draft-ietf-mboned- Provider(s) and Network Service Provider(s) <draft-ietf-mboned-
maccnt-req-05.txt> maccnt-req-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any 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 aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working groups.
groups. Note that other groups may also distribute working Note that other groups may also distribute working documents as
documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in 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 March 22, 2008.
Copyright Notice
Copyright (C) The IETF Copyright (C) The IETF Trust (2007). This
document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights. Trust (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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 IP multicasting. The scope of the requirements access control for IP multicasting. The scope of the requirements
is limited to cases that Authentication, Accounting and is limited to cases that Authentication, Accounting and
Authorization (AAA) functions are coordinated between Content Authorization (AAA) functions are coordinated between Content
Provider(s) and Network Service Provider(s). General requirements Provider(s) and Network Service Provider(s). General requirements
for accounting and admission control capabilities including for accounting and admission control capabilities including
quality-of-service (QoS) related issues are listed. This memo quality-of-service (QoS) related issues are listed. This memo
assumes that these capabilities can be realized by functions assumes that these capabilities can be realized by functions
implemented at edges of a network based on IGMP or MLD. Finally, implemented at edges of a network based on IGMP or MLD. Finally,
cases for Content Delivery Services (CDS) are described as cases for Content Delivery Services (CDS) are described as
application examples which could benefit from multicasting application examples which could benefit from multicasting
accounting and access control capabilities as described in the accounting and access control capabilities as described in this
memo. memo.
This memo defines requirements related to AAA issues for multi- This memo defines requirements related to AAA issues for multi-
entity provider models in which the network service provider and entity provider models in which the network service provider and
content provider cooperate to provide CDS and various related AAA content provider cooperate to provide CDS and various related AAA
functions for purposes such as protecting and accounting for the functions for purposes such as protecting and accounting for the
access to content and network resources. The requirements are access to content and network resources. The requirements are
generally not relevant to cases in which there is not a reason to generally not relevant to cases in which there is not a reason to
share AAA functions between separate entities. share AAA functions between separate entities.
skipping to change at page 3, line 42 skipping to change at page 3, line 42
10. Conclusion..................................................21 10. Conclusion..................................................21
Normative References............................................22 Normative References............................................22
Authors' Addresses..............................................23 Authors' Addresses..............................................23
Full Copyright Statement........................................24 Full Copyright Statement........................................24
Intellectual Property...........................................24 Intellectual Property...........................................24
Expiration......................................................25 Expiration......................................................25
Acknowledgement.................................................25 Acknowledgement.................................................25
1. Introduction 1. Introduction
This memo will present general functional requirements related to This memo presents general functional requirements related to
accounting, access control and admission control issues in IP accounting, access control and admission control issues in IP
multicasting networks. A multicast network which fulfills all of multicasting networks. A multicast network which fulfills all of
these requirements will be called a "fully AAA and QoS enabled" IP these requirements is called a "fully AAA and QoS enabled" IP
multicasting network. Fulfillment of all or some of the multicasting network here. 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. multicasting networks.
IP multicasting is becoming widely used as a method to save IP multicasting is becoming widely used as a method to save
network resources such as bandwidth or CPU processing power of the network resources such as bandwidth or CPU processing power of the
sender's server for cases where a large volume of information sender's server for cases where a large volume of information
needs to be distributed to a very large number of receivers at a needs to be distributed to a very large number of receivers at a
given data speed. This trend can be observed both in enterprise given data speed. This trend can be observed both in enterprise
use and in broadband services provided by network operator/service use and in broadband services provided by network operator/service
providers. 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 streaming information. When the number of receivers becomes large,
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 providers. Distribution of movies and other video programs to
each user are typical services. Each channel requires large each user is a typical service. Each channel requires large
bandwidth (e.g., 6Mbit/s) and operator/service providers need to bandwidth (e.g., 6Mbit/s) and operator/service providers need to
provide many channels to make their service attractive. In provide many channels to make their service attractive. In
addition, the number of receivers is large (e.g., more than a few addition, the number of receivers is large (e.g., more than a few
thousands). The system to provide this service does not scale thousands). A system to provide this service does not scale well
well without multicasting. without multicasting.
As such, multicasting can be useful to make the network more As such, multicasting can be useful to make a network more
scalable when a large volume of information needs to be scalable when a large volume of information needs to be
distributed to a large number of receivers. However, multicasting distributed to a large number of receivers. However, multicasting
according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has
drawbacks compared to unicasting when one applies it to commercial drawbacks compared to unicasting when one applies it to commercial
services. Accounting of each user's actions is not possible with services. Accounting of each user's actions is not possible with
multicasting as it is with unicasting. Accounting consists of multicasting as it is with unicasting. Accounting consists of
grasping each user's behavior, when she/he starts/stops to receive grasping each user's behavior, when she/he starts/stops to receive
a channel, which channel she/he receives, etc. a channel, which channel she/he receives, etc.
There are limitations to the application of multicasting in usage There are limitations to the application of multicasting in usage
skipping to change at page 9, line 19 skipping to change at page 9, line 19
(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
can be applied. Also, it is necessary to identify the user's can be applied. Also, it is necessary to identify the user's
receiver (e.g. IP address) of each request (e.g., join/leave) for receiver (e.g. IP address) of each request (e.g., join/leave) for
per host tracking purposes. per host tracking 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 which receivers (end hosts) are actually receiving the information.
information. The sender must rely on the information from the The sender must rely on the information from the multicasting
multicasting routers. This can be complicated if the sender and routers. This can be complicated if the sender and routers are
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, for unicast this issue can be resolved e.g. For comparisons sake, for unicast this issue can be resolved e.g.
by using RSVP in some cases. by using RSVP in some cases.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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 of entities: Content Provider (CP), Network Service Provider (NSP),
(NSP), and user clients. An NSP owns the network resources and user clients. An NSP owns the network resources
(infrastructure). It accommodates content providers on one side (infrastructure). It accommodates content providers on one side
and accommodates user clients on the other side. NSP provides the and accommodates user clients on the other side. NSP provides the
network for CDS to two other entities (i.e., CPs and user network for CDS to two other entities (i.e., CPs and user clients).
clients). A CP provides content to each user through the network A CP provides content to each user through the network of NSPs.
of NSPs. NSPs are responsible for delivering the content to user NSPs are responsible for delivering the content to user clients,
clients, and for controlling the network resources. and for controlling the network resources.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| CP | | CP | | CP | | CP | | CP | | CP |
| #1 | | #2 | | #3 | | #1 | | #2 | | #3 |
| +---------+ | | +---------+ | | +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | content | | | | content | | | | content | | | | content | | | | content | | | | content | |
| | server | | | | server | | | | server | | | | server | | | | server | | | | server | |
| +-------+-+ | | +----+----+ | | +-+-------+ | | +-------+-+ | | +----+----+ | | +-+-------+ |
+----------\--+ +------|------+ +--/----------+ +----------\--+ +------|------+ +--/----------+
\ | / \ | /
skipping to change at page 16, line 38 skipping to change at page 16, line 38
/ | \ / | \
/ | \ <- user/network interface / | \ <- user/network interface
/ | \ / | \
+---------++ +-----+----+ ++---------+ +---------++ +-----+----+ ++---------+
|client #a | |client #b | |client #c | |client #a | |client #b | |client #c |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
User A User B User C User A User B 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 The NSP provides the information server for all multicast channels,
channels, and a CP gives detailed channel information (e.g., Time and a CP gives detailed channel information (e.g., Time table of
table of each channel) to the information server. An end-user each channel) to the information server. An end-user client gets
client gets the information from the information server. In this the information from the information server. In this model,
model, multicasting is used in the NSP's CDS network, and there multicasting is used in the NSP's CDS network, and there are two
are two different contracts. One is the contract between the NSP different contracts. One is the contract between the NSP and the
and the user which permits the user to access the basic network user which permits the user to access the basic network resources
resources of the NSP. Another contract is between the CP and user of the NSP. Another contract is between the CP and user to permit
to permit the user to subscribe to multicast content. Because the the user to subscribe to multicast content. Because the CP and NSP
CP and NSP are different entities, and the NSP generally does not are different entities, and the NSP generally does not allow a CP
allow a CP to control (operate) the network resources of the NSP, to control (operate) the network resources of the NSP, user
user authorization needs to be done by the CP and NSP authorization needs to be done by the CP and NSP independently.
independently. Since there is no direct connection to the Since there is no direct connection to the user/network interface,
user/network interface, the CP cannot control the user/network the CP cannot control the user/network interface. A user may want
interface. A user may want to move to another place, or may want to move to another place, or may want to change her/his device
to change her/his device (client) any time without interrupting (client) any time without interrupting her/his reception of
her/his reception of services. As such, IP Multicast network services. As such, IP Multicast network should support
should support portability capabilities. portability capabilities.
5.1.2 Content Delivery Service Requirements 5.1.2 Content Delivery Service Requirements
Below are listed specific requirements to support common business Below are listed specific requirements to support common business
cases/ contractual arrangements for the IP Multicast-based Content cases/ contractual arrangements for the IP Multicast-based Content
Delivery Service. Delivery Service.
5.1.2.1 Accounting Requirements 5.1.2.1 Accounting Requirements
An NSP may have different contractual agreements with various CPs An NSP may have different contractual agreements with various CPs
skipping to change at page 18, line 10 skipping to change at page 18, line 10
their user edges. The NSPs can transfer the accounting information their user edges. The NSPs can transfer the accounting information
to related CPs for them to generate user billing information. to related CPs for them to generate user billing information.
Existing standard AAA technology may be used to transfer the Existing standard AAA technology may be used to transfer the
accounting information. accounting information.
To match the accounting information with a particular user, the To match the accounting information with a particular user, the
user has to be authenticated. Usually the account information of a user has to be authenticated. Usually the account information of a
user for content access is maintained by the CP. A user may have user for content access is maintained by the CP. A user may have
different user accounts for different CPs.(e.g. user_a@cp#1 and different user accounts for different CPs.(e.g. user_a@cp#1 and
user_b@cp#2) The account is usually in the format of (username, user_b@cp#2) The account is usually in the format of (username,
password) so an user can access the content services from password) so an user can access the content services from anywhere.
anywhere. For example, an user can access the CP from different For example, an user can access the CP from different NSPs.(e.g. a
NSPs.(e.g. a fixed line NSP and a mobile NSP). It should be noted fixed line NSP and a mobile NSP). It should be noted that the user
that the user account used for content access can be different account used for content access can be different from the one used
from the one used for network access maintained by NSPs. 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 between the NSP and CP, and additional service requirements such
as 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 A mechanism is necessary to allow a CP and NSP to grasp each
user's 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
skipping to change at page 19, line 25 skipping to change at page 19, line 25
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 access. For the first case of authentication, NSP has a AAA server,
server, and for the second case, each CP has a AAA server. In some and for the second case, each CP has a AAA server. In some cases,
cases, CPs delegate (outsource) the operation of user CPs delegate (outsource) the operation of user authentication to
authentication to NSPs. NSPs.
As such, in addition to network access, multicast access by a user As such, in addition to network access, multicast access by a user
also needs to be authenticated. Content authentication should also needs to be authenticated. Content authentication should
support the models where: 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 CP the CP
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
skipping to change at page 21, line 10 skipping to change at page 21, line 10
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
User A User B User C User A User B User C
Fig.3 Example of CDS network configuration Fig.3 Example of CDS network configuration
6. Acknowledgments 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 to Pekka Savola of Netcore Ltd., Daniel Alvarez, and Toerless
Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of
Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai
Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Empresas,
Empresas, Marshall Eubanks of Multicast Techno, Stephen Rife of Marshall Eubanks of Multicast Techno, Stephen Rife of NTT and
NTT and David Meyer in his role as mboned WG chair, as well as David Meyer in his role as mboned WG chair, as well as their
their thanks to the participants of the MBONED WG in general. thanks to the participants of the MBONED WG in general.
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 memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
8. Security Considerations 8. Security Considerations
skipping to change at page 24, line 6 skipping to change at page 24, line 6
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights. therein, the authors retain all their rights.
"This document and the information contained herein are provided Disclaimer
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.". OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be available; any license under such rights might or might not be available;
nor does it represent that it has made any independent effort nor does it represent that it has made any independent effort
to identify any such rights. Information on the procedures with to identify any such rights. Information on the procedures with
skipping to change at page 25, line 5 skipping to change at page 25, line 7
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be proprietary rights that may cover technology that may be
required to implement this standard. Please address the required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org. information to the IETF at ietf-ipr@ietf.org.
Expiration
This Internet-Draft will expire on March 22, 2008.
Acknowledgement Acknowledgement
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.
 End of changes. 25 change blocks. 
77 lines changed or deleted 64 lines changed or added

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