Network Working Group H. Deng Internet-Draft China Mobile Intended status: Standards Track P. Yang Expires: May 8, 2008 Hitachi (China) R&D Corporation Q. Wu Tsinghua Univ. November 5, 2007 Problem Statement and Requirement: Mobile Multicast draft-deng-multimob-ps-mobilemulticast-00 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Deng, et al. Expires May 8, 2008 [Page 1] Internet-Draft PS-MC Mobile-TV November 2007 Abstract This document discusses the problem and requirement of multicast solution in the mobile networks. One current issue in mobile multicast solution has been raised and requirements of mobile IPTV on multicast mobility will also be summarized especially for some mechanisms such as the tunneling, service capability and security discussion which is basis of supporting the mobile IPTV applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements on multicast mobility management for mobile IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. (Mobile) IPTV multicast framework . . . . . . . . . . . . 5 2.2. Service Requirements Mobile IPTV multicast delivery . . . 5 2.3. Correspondence Mobile IPv6 to support Multicast for mobile IPTV? . . . . . . . . . . . . . . . . . . . . . . . 7 3. One Problem about Mobile Multicast . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Deng, et al. Expires May 8, 2008 [Page 2] Internet-Draft PS-MC Mobile-TV November 2007 1. Introduction While more and more operators begin to provide the wireless broadband network systems, the needs for multicast and and broadcast service in mobile network become more and more promising. Recently IPTV might become one of the killer applications for mobile network. Mobile IPTV service is a kind of A/V services which are combined with interactive data for the related or supplementary information of A/V program using bi-directional wireless broadband links. User can enjoy the downlink A/V stream and access more detailed or value-added information via uplink simultaneously. Mobile IPTV service, which is also described as place-shifting IPTV service in [IPTV.SR.SC], basically is to ensure continuous and original IPTV experiences for the users who move to the other place from where he or she originally subscribed for. As specified in [IPTV.SR.SC], mobile IPTV (place-shifting) could be divided into two categories, depending on who is taking care of redistributing the IPTV traffic: The subscriber-based solution requires the device of subsrcriber to redistributes traffic to the place where the user is currently located. The network-based one need the service provider send the IPTV traffic to the moved place. while mobile IPTV users handover from one network domain to another network domain, the network side should guarantee the service continuity and smoothness. Mobile IPTV service is a mass multimedia group communication service. It has more requirements on network bandwidth and QoS/QoE compared with best effort data services. As desribed in [Schmidt07], multicast is optimal to support this kind of group communication service in mobile network. The problems and survey could be found in [Schmidt07]. This document only discusses the problems and requirement of mobile multicast. In the IPv6 network, Mobile IPv6 (MIPv6)[RFC3775] is the basic way to support mobility. It allows the mobile nodes(MN) to maintain the reachability while moving in the IPv6 network. After registration to home agent(HA), the packets destined to MN could be routed correctly by using the end-to-end tunnel, while MN is away from the home network. MIPv6 has some other extensions (HMIP6 [RFC4140], FMIP6 [RFC4068], PMIP6 [Gundavelli07])for different application schemes. MIPv6 has two methods for multicast. [Schmidt07] has already analysis on the Prons and Cons of these two ways. Besides the MIP camp, there are some specific multicast solutions in Deng, et al. Expires May 8, 2008 [Page 3] Internet-Draft PS-MC Mobile-TV November 2007 3GPP(MBMS)[MBMS] and 3GPP2 network(BCMCS)[BCMCS]. There is the possiblity that access gateway may experience the overload to support this kind of services. Anyhow, In the real deployment, BCMCS/MBMS may not always available anywhere in operators' cellular network,they could also support the mobile IPTV services in cellular networks. Deng, et al. Expires May 8, 2008 [Page 4] Internet-Draft PS-MC Mobile-TV November 2007 2. Requirements on multicast mobility management for mobile IPTV 2.1. (Mobile) IPTV multicast framework [IPTV.MC.FR] and [IPTV.FR] make detailed description on IPTV architecture and multicast framewroks. Mobile IPTV content delivery infrastructure may consists of four different layers, i.e. Content Source, Core, Metro(Edge), and Access. Content source is where IPTV service contents are originated and they can be placed in either inside or outside of delivery infrastructure. Core is service/ network provider_is backbone infrastructure. Metro, in other words Aggregation or Edge, is where it connects and aggregates between core and access. Access is user domain that includes last mile. The transport profile of Mobile IPTV are shown in the picture below: Wired or Wireless | | +.........................................+ +----------+ | . Mobile IPTV Transport Profile . | Mobile | V . +--------+ +------+ +------+ . | IPTV |---------| Access |------| Edge |------| Core | . | Terminal | . +--------+ +------+ +------+ . +----------+ . // || || . . // || || . . +-------------+ || || . . | Content |==============|| || . . | Source | || . . +-------------+ || . +................\\...................||..+ \\ || +----------------+ || | content source |== +----------------+ Besides the functions showen in the picture above, multicast delivery control functions are needed for the Mobile IPTV Transport profile. They may be responsible for the multicast tree managerment, membership management, authentication and authorization of members, QoS management, load and traffic mamangement 2.2. Service Requirements Mobile IPTV multicast delivery [IPTV.SR.REQ] specified the service requirements of (Mobile) IPTV. [IPTV.QoE.REQ] gives the requirements related to QoS and QoE. Mobile IPTV service includes multiple type of services, such as video, audio, data(captures, EPG, etc.). Video service need much bandwidth Deng, et al. Expires May 8, 2008 [Page 5] Internet-Draft PS-MC Mobile-TV November 2007 and also should be a service with high service quality. Network should implement traffic control for high priority multicast traffic to ensure the QOS of multicast. Specifically, following functions should be supported in the mobile network: (1)Total Multicast Bandwidth: access node should be able to control on total bandwidth of a user port that can be used for multicast service; (2)Current Available Bandwidth: the access node should be able to aware of current available bandwidth that can be used for multicast service, specifically, can be total multicast bandwidth consumed multicast bandwidth; (3)Connection Admission Control (CAC): It is required that Connection Admission Control supported in Access network based on available resources. When end user subscribes to a multicast stream, access network will perform CAC: check if current available resources are enough for the new service subscription. The resources can be bandwidth, connection number and user service privilege profile. (4) Network Attachment Control: The attachment control should be supported by the multicast control function and multicast replication function. The multicast control function should build the privilege table for multicast users, and the multicast replication function should forward multicast media content to users which have the privilege of IPTV multicast services. (5) Packet loss: depending on the bit rate and video/audio profiles, the video and audio streams have different levels of sensitiveness on packet loss. [IPTV.QoE.REQ] gives the detail of packet loss requirements for all kinds of real-time mobile IPTV media streams. The multicast mobile network should gurantee not only the duration of single error, but also the total packet loss rate. Besides the packet loss at radio interface, the multicast handoff will also incur some packet loss. (6) Packet priority: considering the video/audio compression characteristics, different packets may have different importance. It is recommended to provide better guarantee for important packets. (7) Synchronization: Mobile IPTV services is also an integrated service with synchronized multiple streams. Although the service provider and the terminal may have some solution to maintain synchronized streams, the mobile network may also incur delay and jitter. So, the mobile multicast should provide some machenism to ensure the synchronization of mobile IPTV streams. Deng, et al. Expires May 8, 2008 [Page 6] Internet-Draft PS-MC Mobile-TV November 2007 (8) Notification: there are some mobile IPTV service events, which will trigger notification messages. The multicast mobile network should understand such kind of notifications and make the actions accordingly. In this sense, a notifiction solution among the nodes of multicast mobile network mya be useful. 2.3. Correspondence Mobile IPv6 to support Multicast for mobile IPTV? Many works have made the analysis on the multicast solution in mobile IPv6. [Schmidt07] has the summary of all the related works. In this document, the analysis on multicast of mobile IPv6 will be made only based on mobile IPTV. The Home Agent(HA) may be part of the core function in the mobile IPTV framework. The edge function normally coould be considered as the access gateway(AGW) in the deployment of mobile IPv6 in mobile network. Bandwidth efficiency: The advantage of the bi-directional tunneling solution is its simplicity and the transparency of handover to the multicast operation. This approach is inefficient because of the tunnel overhead and delay. The multiple unicasting tunneling problem for multicast between HA and MN should be solved to improve the bandwidth efficientcy. In the deployment of mobile IPv6 in wireless network (cellular, WLAN or WIMAX), HA (core) is relatively close to the AGW(Edge). So, the delay issue because of triangle tunneling may not be so severe. Packet loss: the mobile IPTV services consist of real-time video/ audio streams. So, the short delay/seamless multicast handoff of mobile IPv6 is surely useful. Synchronization: the requirements include the synchronization among all the nodes of mobile IPv6 and the synchronization between the mobile IPTV streams. Firstly, a precise time reference is needed in the multicast mobile network. Secondly, the synchronization information is necessary in the mobile IPTV streams. Lastly, some notification messages may be useful to share some time-based mobile IPTV events among mobile IPv6 nodes. It's also useful for precise mobile IPTV and multicast network charging.Proxy Mobile IPv6 has some basic requirement about synchronization between LMA and MAG for several considerations. Notification: it's recommended to have some notification machenism in mobile IPv6. It's useful to do synchronous actions for incoming mobile IPTV service events. Deng, et al. Expires May 8, 2008 [Page 7] Internet-Draft PS-MC Mobile-TV November 2007 3. One Problem about Mobile Multicast The current MBMS which is defined in 3GPP [MBMS] may experience overload for each network entity such as access gateway and broadcast/multicast server, in the case of mobile node frequently join and quit from the multicast group, multicast service announcement may also need to be reconsidered. Deng, et al. Expires May 8, 2008 [Page 8] Internet-Draft PS-MC Mobile-TV November 2007 4. Security Considerations Multicast security is one of the most crucial issues in mobile IPTV service such that it is required to provide security capabilities to protect mobile IPTV multicast network from any malicious attempts caused by multicast security holes. Security itself is too diverse to break down to the specific multicast purpose; however functional requirements of multicast security for each network elements should be clearly defined and should provide capabilities along with the definitions. As specified in [IPTV.SEC], the mobile IPTV security requirements may have following aspects: - IPTV architecture is required to be robust against denial of service attacks targeting any multicast mechanisms. - Multicast system architecture is required to provide a mechanism of multicast protocol adjacency authentication in order to establish a reliable peer. - Multicast system architecture is required to provide an admission control mechanism to regulate any multicast events. - Multicast system architecture is required to be independent of adjacent domain such that it shall not affect the adjacent multicast domain without permission. - Multicast system architecture is required to provide a mechanism to check integrity of multicast contents before service delivery such that it prevents unauthorized contents from becoming the content source. Deng, et al. Expires May 8, 2008 [Page 9] Internet-Draft PS-MC Mobile-TV November 2007 5. Conclusion This draft discusses multicast mobility for mobile network and mobile IPTV services. Firstly the mobile IPTV multicast framework is described followed by its the requirements on multicast mobile networks. The impacts on current mobile IPv6 multicast solutions are also discussed based on the requirements of mobile IPTV. Security issues are discussed lastly in this document. Deng, et al. Expires May 8, 2008 [Page 10] Internet-Draft PS-MC Mobile-TV November 2007 6. Normative References [BCMCS] 3GPP2, "Broadcast/Multicast Services - Stage 1, Revision A", 3GPP2 S.R0030-A V1.0, Feb. 2004. [Gundavelli07] Gundavelli, S., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-06.txt (work in progress), September 2007. [IPTV.FR] Xie, W. and Will. , "IPTV Architecture", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0084, May 2007. [IPTV.MC.FR] Seo, Y., "IPTV Multicast Frameworks", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0092, May 2007. [IPTV.QoE.REQ] Takahashi, A., "Quality of Experience Requirements for IPTV", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0086, May 2007. [IPTV.SEC] Xie, W., "IPTV Security Aspects", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0090, May 2007. [IPTV.SR.REQ] Becha, B., "IPTV service requirements", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0083, May 2007. [IPTV.SR.SC] Li, M., "IPTV service scenarios", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0085, May 2007. [MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS) Architecture and functional description", 3GPP TS 23.246 V8.0.0, September 2007. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. Deng, et al. Expires May 8, 2008 [Page 11] Internet-Draft PS-MC Mobile-TV November 2007 [Schmidt07] Schmidt, T., "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-01.txt (work in progress), July 2007. Deng, et al. Expires May 8, 2008 [Page 12] Internet-Draft PS-MC Mobile-TV November 2007 Authors' Addresses Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Peng Yang Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)328 Email: pyang@hitachi.cn Qian Wu Tsinghua Univ. Deng, et al. Expires May 8, 2008 [Page 13] Internet-Draft PS-MC Mobile-TV November 2007 Full Copyright Statement 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. 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, THE IETF TRUST 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 procedures with respect to rights in RFC 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Deng, et al. Expires May 8, 2008 [Page 14]