Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel Networks Document: draft-hayashi-maccnt-01.txt Hiroaki Satou, NTT Expires: April 24, 2005 Hiroshi Ohta, NTT October 2004 Accounting Issues in Well Managed IP Multicasting Services Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2005 Copyright Notice Copyright (C) The Internet Society (2004) Hayashi, He, Satou, Ohta [Page 1] Internet Draft draft-hayashi-maccnt-01 October, 2005 Abstract This I-D describes problems on accounting issues in multicasting. General requirements for accounting capabilities including QoS related issues are listed. This I-D assumes that these capabilities can be realized by appropriate functions implemented at edges of a network based on IGMP or MLD. Such functions would log in a dedicated database information obtained from edge routers. Finally, a case for CDN services is described as an application example which could benefit from multicasting with accounting capabilities. It is proposed that this I-D be used as a starting point for further discussion on these issues. Table of contents Copyright Notice...................................................1 1. Introduction....................................................3 2. Problem statement...............................................4 3. Functional general requirements for well managed multicasting...5 4. Application example and its specific requirements...............6 4.1 IP Multicast-based Content Delivery Service (CDS)..............6 4.1.2 Content Delivery Service Requirements........................9 4.1.2.1 Accounting Requirements....................................9 4.1.2.2 Authorization Requirements.................................9 4.1.2.3 Authentication Requirements...............................10 4.1.3 Summary: Challenges for Multicast CDS.......................10 5. IANA considerations............................................11 6. Security considerations........................................11 7. Conclusion.....................................................11 Normative References..............................................11 Full Copyright Statement..........................................13 Intellectual Property.............................................13 Acknowledgement...................................................13 Hayashi, He, Satou, Ohta [Page 2] Internet Draft draft-hayashi-maccnt-01 October, 2005 1. Introduction The intention of this I-D is to initiate a discussion focused on accounting issues for well-managed IP multicasting services. The I-D proposes for the identified requirements to be taken on as a working item within the mboned WG. IP multicasting is becoming widely used as a method to save network resources such as bandwidth or CPU processing power of the sender's server for the cases where large volume of information needs to be distributed to a large number of receivers. This trend can be observed both in enterprise use and in broadband services provided by network operator/service providers. Distance learning within a university and in-house (in-company) sharing of multimedia information are examples of enterprise use. In these examples, sources generate high-bit rate (e.g., 6Mbit/s) streaming information. When the number of receivers becomes large, such systems do not scale well without multicasting. On the other hand, content delivery service (CDS) is an example of a broadband service provided by network operators/service providers. Distribution of movies and other video programs to each user are typical services. Each channel requires large bandwidth (e.g., 6Mbit/s) and operator/service providers need to provide many channels to make their service attractive. In addition, the number of receivers is large (e.g., more than a few thousands). The system to provide this service does not scale well without multicasting. As such, multicasting can be useful to make the network more scalable when a large volume of information needs to be distributed to a large number of receivers. However, multicasting according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting. Appropriate accounting of each user's actions is not possible with multicasting as it is with unicasting. Accounting consists of grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. Although multicasting has already been used in several applications, it is used in such a way that accounting is not necessary Without this capability in multicasting, information providers which desire the accounting capabilities are forced to use unicasting even when multicasting would otherwise be desirable from a bandwidth/ server resource perspective. If multicasting could be used with appropriate accounting capabilities, its applicability would be greatly widened. This I-D first describes problems on accounting issues in multicasting. Then the general requirements for this capability including QoS related issues are listed. This I-D assumes that these capabilities can be realized by appropriate functions implemented at Hayashi, He, Satou, Ohta [Page 3] Internet Draft draft-hayashi-maccnt-01 October, 2005 edges of a network based on IGMP or MLD. Such functions would record into a dedicated database information obtained from edge routers. Finally, an application example which could benefit from multicasting with accounting capabilities is shown. It is proposed that this I-D be used as a starting point for the discussion on these issues. 2. Problem statement 2.1 Accounting issues In unicast communications, the server (information source) can identify the client (information receiver) and permits connection only if the client is eligible when this type of access control is necessary. In addition, when necessary, the server can grasp what the client is doing (e.g., connecting to the server, starting reception, what information the client is receiving, terminating reception, disconnecting from the server). On the other hand, in multicast communication as in Fig.1, the server just feeds its information to the multicast router. Then, the multicast router replicates the information to distribute to the clients. According to the current standard (e.g., IGMPv3[1] or MLDv2[2]), the multicast router feeds the replicated information to any link which has at least one client requesting the information. In this process, no eligibility check is conducted. Any client can request to receive the information. In other words, sufficient accounting capabilities are not provided for multicasting by the current standard. +--------+ | client |\ +--------+ \ \+------+ +------+ +------+ +------+ +--------+ |Multi-| |Multi-| |Multi-| | | | client |---|cast |----|cast |----|cast |----|Server| +--------+ |router| |router| |router| | | /+------+ +------+ +------+ +------+ +--------+ / | client |/ +--------+ Fig.1 Example network for multicast communication This is the major reason why multicasting is only used for the cases where no accounting capabilities are necessary. However, more and more information is transferred over IP-based networks and some of some of these applications may require accounting capabilities: therefore it is easy to envision the requirement of supporting such Hayashi, He, Satou, Ohta [Page 4] Internet Draft draft-hayashi-maccnt-01 October, 2005 cases. For example, if one wants to charge for distributed information, accounting is needed. If the volume of information and number of client are large, it is beneficial to use multicasting from the network resource efficiency point of view. As such, the same level of accounting capabilities as unicast networks should be provided to multicast networks. 2.2 Relationships secure multicasting For content security, contents need to be encrypted. Key distribution functions are essential for this purpose. However, precise accounting is not possible. Since user behavior is represented by join/leave actions when the system is based on IGMP/MLD, detection of these actions is necessary for accounting. 3. Functional general requirements for well managed multicasting It seems beneficial to use IGMP or MLD for access controlling in multicast networks. However, from the consideration in section 2, there are issues in the following areas: (1) User identification Network should be able to identify each client so that necessary access controlling actions can be applied. (2) Access control Networks should be able to apply necessary access controlling actions when an eligible user requests. Networks should be able to reject any action requested from an ineligible user. (3) Accounting and billing Networks need to be able to grasp each client's behavior so that appropriate accounting and billing are possible. A client's behavior is represented by join/leave actions when the network is built based on IGMP. As such, it is necessary to detect each user's join/leave action in real time. Accounting and billing should be done tied with these join/leave action. (4) Service and terminal portability Hayashi, He, Satou, Ohta [Page 5] Internet Draft draft-hayashi-maccnt-01 October, 2005 Networks should accept for a user to receive a service from different places and/or with a different terminal device. (5) Support of ASM and SSM Both ASM (G), and SSM (S,G) should be supported as multicast models. (6) Accumulating logs Networks need database functions to realize accumulating logs from edge routers for appropriate accounting. (7) Appropriate admission control for join action For example, in order to maintain a predefined QoS level, an edge router should not accept a consequent "join" after a "leave" until the termination of the stream of the multicast group which was "left". This is essential to protect against e.g., multicast DoS attacks. (8) Quick reaction Accounting functions should not only meet requirement (7) but also should react quickly to user actions. Quick reactions are essential to provide attractive and easy-to-use services. Specific functional requirements for each application can be derived from above general requirements. An example is shown in the following section. 4. Application example and its specific requirements This section shows an application example which could benefit from multicasting. Then, specific functional requirements related to accounting capabilities are derived. 4.1 IP Multicast-based Content Delivery Service (CDS) Broadband access networks such as ADSL (Asymmetric Digital Subscriber Line) or FTTH (Fiber to the Home) have been deployed widely in recent years. Content delivery service (CDS) is expected to be a major Hayashi, He, Satou, Ohta [Page 6] Internet Draft draft-hayashi-maccnt-01 October, 2005 application provided through broadband access networks. Because many services like TV broadcasting require huge bandwidth (e.g., 6Mbit/s) and processing power at content server, IP multicast is used as an efficient delivery mechanism for CDS. One way to provide high quality CDS is to use closed networks ("walled-garden" model). 4.1.1 Network model for Multicast Content Delivery Service As shown in Fig.2, networks for CDS contain three different types of entities: Content Owners (COs), Network Service Provider (NSP), and end user clients. An NSP owns the network resources (infrastructure). It accommodates content owners on one side and accommodates end user clients on the other side. NSP provides the network for CDS to other two entities (i.e., COs and end user clients). A CO provides content to each end user client through the network of NSPs. NSPs are responsible for delivering the content to end user clients, and for controlling the network resources. Hayashi, He, Satou, Ohta [Page 7] Internet Draft draft-hayashi-maccnt-01 October, 2005 +-------------+ +-------------+ +-------------+ | CO | | CO | | CO | | #1 | | #2 | | #3 | | +---------+ | | +---------+ | | +---------+ | | | content | | | | content | | | | content | | | | server | | | | server | | | | server | | | +-------+-+ | | +----+----+ | | +-+-------+ | +----------\--+ +------|------+ +--/----------+ \ | / \ | / <- network/network interface \ | / +------------- \ ------ | ------ / ----+ | \ | / | | NSP +-+-----+-----+-+ | | | Provider Edge | | | +-------+-------+ | +--------------------+ | | |---| Information server | | \ | | +--------------------+ | +--+------+---+ | | | User Edge | | | +--+---+---+--+ | | / | \ | +------------- / --- | --- \ ----------+ / | \ / | \ <- user/network interface / | \ +---------++ +-----+----+ ++---------+ |client #a | |client #b | |client #c | +----------+ +----------+ +----------+ End user A End user B End user C Fig.2 Example of CDN network configuration NSP has the information server for all multicast channels, and a CO gives detail channel information (e.g., Time table of each channel) to the information server. An end user client gets the information from the information server. In this model, multicast is used in the NSP's CDN, and there are two different contracts. One is the contract between NSP and end user to permit user to access a basic network resources of NSP. Another one is between CO and end user to permit user to subscribe multicast content. Because CO and NSP are different entities and in general, NSP does not allow a CO to control (operate) the network resources of NSP, user authorization needs to be done by CO and NSP independently. Since there is no direct connection to the user/network interface, CO cannot control the user/network interface. An end user may want to move to another place, or may want to change her/his device (client) anytime without interrupting her/his receiving services. As such, IP Multicast network should support portability capabilities. Hayashi, He, Satou, Ohta [Page 8] Internet Draft draft-hayashi-maccnt-01 October, 2005 4.1.2 Content Delivery Service Requirements To have a successful business, there are some specific requirements for the IP Multicast-based content delivery service. 4.1.2.1 Accounting Requirements Since CO and NSP are different business entities, they need to share the profit. Such profit sharing business relationship requires accurate and near real-time accounting information about the end user clients' activity on accessing the content services. The accounting information should be per content/usage base to enable different billing and charging methods. The user accessing a particular content is represented by the user's activities of joining or leaving the corresponding multicast group/channel ( or ). In multicast networks, only NSPs can collect group joining or leaving activities through theirs last-hop multicast access edge devices in real-time. The NSPs can transfer the accounting information to related COs for them to generate final end user billing information. The normal AAA technology can be used to transfer the accounting information. To match the accounting information with a particular end user client, the end user client has to be authenticated. Usually the account information of an end user client for content access is maintained by the COs. An end user client may have different user accounts for different COs. The account is usually in the format of (username, password) so an end user client can access the content services from anywhere. For example, an end user client can access the CO from different NSPs. It should be noted that the user account used for content access can be different from the one used for network access maintained by NSPs. The NSP-CO model represents multi-domain AAA environment. There are plural cases of the model depending on trust relationship between NSP and CO, and additional service requirement such as a certain QoS level or service/terminal portability. A mechanism is necessary to allow CO and NSP to grasp each user's behavior independently. 4.1.2.2 Authorization Requirements The NSPs are responsible for delivering the content and are required to meet certain QoS levels or SLA (service level agreements). For example, video quality is very sensitive to packet losses. So if a NSP cannot meet the quality requirements due to limited network resources if it receives an additional user request, the NSP should Hayashi, He, Satou, Ohta [Page 9] Internet Draft draft-hayashi-maccnt-01 October, 2005 reject that end user client's access request instead of charging the user for bad services. In order to protect network resources against misuse/malicious access and maintain a QoS level, appropriate admission control function is necessary so that the NSP can accept or reject the request without degrading the QoS beyond the specified level. 4.1.2.3 Authentication Requirements There are two different aims of authentication. One is an authentication to network access, and another one is to each content. For the first case of authentication, NSP has a AAA server, and for the second case, each CO has a AAA server. In some cases, COs delegate (outsource) the operation of user authentication to NSPs. When NSP supports plural network services, we can not use an authentication mechanism of physical layer such as an 802.1X because NSP needs to independently operate (authenticate) each service. NSP authenticate a user request to multicast network resources, and COs independently authenticate a user request to their content (multicast group). Each entity (NSP and CO) has its own AAA server. Then a synchronization mechanism between authorization and group management is necessary. Each entity (NSP and COs) may have its own authentication server. NSP authenticates a client access to use a network resource, and a CO authenticates a client request to access to a multicast group. 4.1.3 Summary: Challenges for Multicast CDS The key is how a control process of group membership synchronizes with an AAA process (authentication, authorization and accounting). This depends on a network model which should be scalable and adaptable to any case of multicast CDN service. An important issue that discourages the wide deployment of IP multicast services is lack of multicast network management functions, especially an effective multicast accounting function. In IP multicast-based Internet TV, we should support a network model where many content owners provide their content to several NSPs which are different entities, and where each provider individually holds their customer information. In this model, keeping the consistency of accounting information in COs and NSPs becomes important. Effective user-based accounting information is critical in two aspects. On one hand, NSPs of commercial multicast services need to accurately identify the users and collect their usage information to generate correct billing information. On the other hand, some content Hayashi, He, Satou, Ohta [Page 10] Internet Draft draft-hayashi-maccnt-01 October, 2005 providers need to learn the content usage information. For example, in IP multicast based Internet TV services, NSPs need to know which TV program is being watched and how long a user watches so that they can charge the user based on the value of the TV program. In addition, content providers and TV program owners need to know the rating information (the number of viewers of a TV program) and how long they watch the TV program in order to generate appropriate advertisement revenue. 5. IANA considerations This I-D does not raise any IANA consideration issues. 6. Security considerations Accounting capabilities can be used to enhance the security of multicast networks by excluding ineligible clients from the networks. 7. Conclusion This I-D described problems on accounting issues in multicasting. The general requirements for this capability including QoS related issues were listed with the goal of finding a solution implemented at edges of a network based on IGMP or MLD. This capability assumes the existence of a database in the network dedicated to accumulating logs obtained from edge routers. Finally, a case for CDN services was described as an application example which could benefit from multicasting with accounting capabilities. It is proposed that this I-D be used as a starting point for the discussion on these issues. Normative References [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", RFC3376, October 2002. [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC3810, June 2004. Authors' Addresses Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone: +81 46 859 8790 Email: hayashi.tsunemasa@lab.ntt.co.jp Hayashi, He, Satou, Ohta [Page 11] Internet Draft draft-hayashi-maccnt-01 October, 2005 Haixiang He Nortel Networks 600 Technology Park Drive Billerica, MA 01801, USA Phone: +1 978 288 7482 Email: haixiang@nortelnetworks.com Hiroaki Satou NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 4683 Email : satou.hiroaki@lab.ntt.co.jp Hiroshi Ohta NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp Hayashi, He, Satou, Ohta [Page 12] Internet Draft draft-hayashi-maccnt-01 October, 2005 Full Copyright Statement Copyright (C) The Internet Society (2004). 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. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hayashi, He, Satou, Ohta [Page 13]