Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel Networks Document: draft-hayashi-maccnt-00.txt Hiroaki Satou, NTT Expires: February 2005 Hiroshi Ohta, NTT August 2004 Accounting Issue in Well Managed IP Multicasting Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. Abstract This I-D describes problems on accounting issues in multicasting. The general requirements for accounting capabilities are listed. Finally, case for CDN services is described as an application example which could get benefit from multicasting with accounting capabilities. It is proposed that this I-D be used as a starting point of the discussion on these issues. Hayashi, He, Satou, Ohta [Page 1] Internet Draft draft-hayashi-maccnt-00 February, 2005 Table of contents 1. Introduction....................................................2 2. Problem statement...............................................3 3. Functional general requirements for well managed multicasting...4 4. Application example and its specific requirements...............5 4.1 IP Multicast-based Content Delivery Service (CDS)..............5 4.1.2 Content Delivery Service Requirements........................7 4.1.2.1 Accounting Requirements....................................7 4.1.2.2 Authorization Requirements.................................7 4.1.2.3 Authentication Requirements...............................8 4.1.3 Summary: Challenges for Multicast CDS........................8 5. IANA considerations.............................................9 6. Security considerations.........................................9 7. Conclusion......................................................9 Normative References...............................................9 1. Introduction The intention of this I-D is to initiate the discussion on especially accounting issues related to well-managed IP multicasting services and to invite people to participate a potential IETF BoF/WG to discuss these issues and find solutions for them. IP multicasting is becoming widely used as a method to save network resources such as bandwidth or CPU processing power at 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) multimedia information sharing 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, the system to share this type of information does not scale well without multicasting. On the other hand, content delivery service (CDS) is an example of broadband services provided by network operator/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 Hayashi, He, Satou, Ohta [Page 2] Internet Draft draft-hayashi-maccnt-00 February, 2005 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 large volume of information needs to be distributed to a large number of receivers. However, multicasting according to current standard has drawbacks compared to unicasting. Appropriate accounting of each user is not possible when multicasting is used while it is possible under 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. When accounting capabilities are necessary, unicasting is used instead of multicasting although a lot of network resources (e.g., bandwidth, CPU processing power, etc.) could be saved with multicasting in some applications. If multicasting can be used with appropriate accounting capabilities, its applicability would be widen much. This I-D first describes problems on accounting issues in multicasting. Then the requirements for accounting capabilities are listed. 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 of the discussion on these issues. 2. Problem statement In unicast communications, server (information source) can identify the client (information receiver) and permits connection only if the client is eligible when this type of checking is necessary. In addition, when necessary, the server can grasp what the client is doing (e.g., connecting to the server, starts reception, what information is the client receiving, terminates reception, disconnects 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, multicast router replicates the information to distribute 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, no accounting capabilities are provided for multicasting by the current standard. Hayashi, He, Satou, Ohta [Page 3] Internet Draft draft-hayashi-maccnt-00 February, 2005 +--------+ | 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, it can easily be envisaged that multicasting is required to be applied to communications which need accounting capabilities because more and more information is transferred over the IP-based networks and some of them may require accounting capabilities. For example, if one want 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, same level of accounting capabilities as unicast networks should be provided to multicast networks. 3. Functional general requirements for well managed multicasting To realize well managed multicasting, following capabilities are required: (1) Network should be able to identify each client when eligible user access, and should be able to reject to connect ineligible clients. (2) Network can grasp each client's behavior. For example, network should be able to detect: - that the client connects to the network, - that the client starts receiving certain information, - that the information which the client is receiving, - that the client terminates receiving the information, - that the client disconnects from the network. (3) Mobility functions should be supported as an option so that users can use the service from anywhere. Hayashi, He, Satou, Ohta [Page 4] Internet Draft draft-hayashi-maccnt-00 February, 2005 (4) Both ASM (G), and SSM (S,G) should be supported as multicast models. 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 can get 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 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 5] Internet Draft draft-hayashi-maccnt-00 February, 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, a 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 other place, or may want to change her/his device (client) anytime without interrupting her/his receiving services. As such, IP Multicast network should support mobility capabilities. Hayashi, He, Satou, Ohta [Page 6] Internet Draft draft-hayashi-maccnt-00 February, 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 QoS for NSP or ubiquitous for users. 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 level 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 7] Internet Draft draft-hayashi-maccnt-00 February, 2005 reject that end user clientÙs access request instead of charging the user for bad services. QoS control, e.g. priority control or admission control, is important for multicast CDN. Function to protect network resources from misuse of it is needed. When NSP controls QoS, userÙs access request has to be authorized after NSP has confirmed that the NSP can accept 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 authenticate a client access to use a network resource, and a CO authenticate 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 the 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 Hayashi, He, Satou, Ohta [Page 8] Internet Draft draft-hayashi-maccnt-00 February, 2005 correct billing information. On the other hand, some content 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 accounting capabilities were listed. Finally, a case for CDN services was described as an application example which could get benefit from multicasting with accounting capabilities. It is proposed that this I-D be used as a starting point of 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. Hayashi, He, Satou, Ohta [Page 9] Internet Draft draft-hayashi-maccnt-00 February, 2005 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 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 10]