draft-ietf-mboned-maccnt-req-02.txt   draft-ietf-mboned-maccnt-req-03.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Internet Draft Haixiang He, Nortel
Document:draft-ietf-mboned-maccnt-req-02.txt Hiroaki Satou, NTT Document:draft-ietf-mboned-maccnt-req-03.txt Hiroaki Satou, NTT
Expires: June 18, 2006 Hiroshi Ohta, NTT Expires: July 14, 2006 Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
December 15, 2005 January 10, 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-02.txt> <draft-ietf-mboned-maccnt-req-03.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 page 1, line 38
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 June 18, 2006. This Internet-Draft will expire on July 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005) 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
accounting capabilities including quality-of-service (QoS) related accounting capabilities including quality-of-service (QoS) related
issues are listed. This I-D assumes that these capabilities can be issues are listed. Finally, cases for Content Delivery Services
realized by functions implemented at edges of a network based on (CDS) are described as application examples which could benefit
IGMP or MLD. Finally, cases for Content Delivery Services (CDS) from multicasting accounting and access control capabilities as
are described as application examples which could benefit 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.............................................5 3. Problem statement.............................................4
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)................6
4. General functional requirements for well managed IP 4. General AAA-related functional requirements for IP
multicasting..................................................6 multicasting..................................................6
5. Application example and its specific requirements............10 5. Application example and its specific requirements............10
5.1 IP Multicast-based Content Delivery Service (CDS): CP and 5.1 IP Multicast-based Content Delivery Service (CDS): CP and
NSP are different entities (companies)......................10 NSP are different entities (companies)......................10
5.1.1 Network model for Multicast Content Delivery Service......10 5.1.1 Network model for Multicast Content Delivery Service......10
5.1.2 Content Delivery Service Requirements.....................12 5.1.2 Content Delivery Service Requirements.....................12
5.1.2.1 Accounting Requirements.................................12 5.1.2.1 Accounting Requirements.................................12
5.1.2.2 Authorization Requirements..............................13 5.1.2.2 Authorization Requirements..............................13
5.1.2.3 Authentication Requirements.............................13 5.1.2.3 Authentication Requirements.............................13
5.2 IP Multicast-based Content Delivery Service (CDS): CP and 5.2 IP Multicast-based Content Delivery Service (CDS): CP and
NSP are the same entities (companies).......................14 NSP are the same entities (companies).......................14
6. Acknowledgements.............................................15 6. Acknowledgements.............................................15
7. IANA considerations..........................................15 7. IANA considerations..........................................15
8. Security considerations......................................15 8. Security considerations......................................15
9. Conclusion...................................................15 9. Conclusion...................................................15
Normative References............................................15 Normative References............................................15
Authors' Addresses..............................................15
Full Copyright Statement........................................17 Full Copyright Statement........................................17
Intellectual Property...........................................17 Intellectual Property...........................................17
Acknowledgement.................................................17
1. Introduction 1. Introduction
The intention of this memo is to define requirements related to This I-D will present general functional requirements related to
accounting, authentication and authorization issues for "well- accounting, authentication and authorization issues in IP
managed IP multicasting" services ("well-managed" defined at the multicasting networks. A multicast network which fulfills all of
end of this introduction). these requirements will be called a "fully AAA enabled" IP
multicasting network. Fulfillment of all or some of the
requirements will make possible more robust management of IP
multicasting networks, and as such these capabilities contribute 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 network
resources such as bandwidth or CPU processing power of the sender's resources such as bandwidth or CPU processing power of the sender's
server for cases where a large volume of information needs to be server for cases where a large volume of information needs to be
distributed to a large number of receivers. This trend can be distributed to a large number of receivers. This trend can be
observed both in enterprise use and in broadband services provided observed both in enterprise use and in broadband services provided
by network operator/service providers. 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.
skipping to change at page 4, line 14 skipping to change at page 4, line 16
used with user-based accounting capabilities, its applicability used with user-based accounting capabilities, its applicability
would be greatly widened. 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.
This I-D will present general functional requirements related to
accounting, authentication and authorization issues in IP
multicasting networks, and a multicast network which fulfills these
requirements will be called a "well managed" IP multicasting
network.
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.
User-based accounting: actions for grasping each user's behavior, User-based accounting: actions for grasping each user's behavior,
skipping to change at page 5, line 4 skipping to change at page 4, line 46
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).
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[1]) the server just feeds its
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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 useable 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 user
activity. The functional requirements do not require content 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 part
of a solution and if so, what other components (if any) would also of a solution and if so, what other components (if any) would also
be required. be required.
4. General functional requirements for well managed IP multicasting 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
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
skipping to change at page 7, line 12 skipping to change at page 7, line 12
(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. The network should be able
to reject any action requested from an ineligible user. 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 both at the physical port of the edge router or switch so groups at the physical port of the edge router or switch so that
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 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 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 servers
and multicast routers can be within the limit. and multicast routers can be within the limit.
skipping to change at page 11, line 50 skipping to change at page 11, line 50
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
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 multicast content. Because the user to permit the user to subscribe to multicast content. Because
CP and NSP are different entities, and the NSP generally does not the CP and NSP are different entities, and the NSP generally does
allow a CP to control (operate) the network resources of the NSP, not allow a CP to control (operate) the network resources of the
user authorization needs to be done by the CP and NSP independently. NSP, user authorization needs to be done by the CP and NSP
Since there is no direct connection to the user/network interface, independently. Since there is no direct connection to the
the CP cannot control the user/network interface. An end user may user/network interface, the CP cannot control the user/network
want to move to another place, or may want to change her/his device interface. An end user may want to move to another place, or may
(client) anytime without interrupting her/his reception of services. want to change her/his device (client) anytime without interrupting
As such, IP Multicast network should support portability her/his reception of services. As such, IP Multicast network
capabilities. 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
skipping to change at page 15, line 12 skipping to change at page 15, line 12
Fig.3 Example of CDS network configuration Fig.3 Example of CDS network configuration
6. Acknowledgements 6. Acknowledgements
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 Eckert
of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper, of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper,
Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T- Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T-
Systems, as well as the participants of the MBONED WG in general. Systems, as well as the participants of the MBONED WG in general.
Funding for the RFC Editor function is currently provided by the
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 for
multicast content delivery, with the goal of finding a solution multicast content delivery. Content Delivery Services with
implemented at edges of the network based on IGMP or MLD. Content different business models is cited as an application which could
Delivery Services with different business models is cited as an benefit from the capabilities of "well managed" IP multicasting
application which could benefit from the capabilities of "well described in this document.
managed" IP multicasting 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.
skipping to change at page 17, line 6 skipping to change at page 17, 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 Internet Society (2005). 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
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
skipping to change at page 17, line 44 skipping to change at line 759
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 any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf this standard. Please address the information to the IETF at ietf
ipr@ietf.org. ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 22 change blocks. 
44 lines changed or deleted 43 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/