Network Working Group H. Deng Internet-Draft China Mobile Intended status: Standards Track P. Yang Expires:August 23, 2008January 14, 2009 Hitachi(China) R&D CorporationQ. Wu Tsinghua Univ.February 20,July 13, 2008 Problem Statement and Requirement: Mobile Multicastdraft-deng-multimob-ps-mobilemulticast-01draft-deng-multimob-ps-mobilemulticast-02 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 onAugust 23, 2008. Copyright Notice Copyright (C) The IETF Trust (2008).January 14, 2009. 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 multicastIP mobility managementformulticast support in mobileIPTV . . . . . . . . . . . . . . . . . . . . . . . . . . .network . .54 2.1.(Mobile)Mobile IPTV multicast framework . . . . . . . . . . . .5 2.2. Service Requirements Mobile IPTV multicast delivery ... 5 2.3. Correspondence4 2.2. MobileIPv6 toIPv4 support Multicastfor mobile IPTV? .. . . . . . . . . . . . . .. . . . . . . . 7 3. One Problem about4 2.3. Mobile IPv6 support Multicast . . . . . . . . . . . . . .9 4.5 3. Security Considerations . . . . . . . . . . . . . . . . . . .10 5.7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .11 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.8 5. Normative References . . . . . . . . . . . . . . . . . . .13 7.2. Informative References . . . . .. .. . . . . . . . . . . 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1510 Intellectual Property and Copyright Statements . . . . . . . . . .1611 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 promising. Recently IPTV might become one of thekillerdesirable 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 theIPv6mobile network, MobileIPv6 (MIPv6)[RFC3775] isIPv4 (MIPv4)[RFC3344], Mobile IPv6[RFC3775], DSMIP6 [DSMIPv6] and PMIP6[Gundavelli08]is the basic way to supportmobility.IP mobility management. It allows the mobile nodes(MN) to maintain the reachability while moving in theIPv6IP network. After registration to home agent(HA), the packets destined to MN could be routed correctly by using theend-to-end tunnel,tunneling mechanism, while MN is away from the home network.MIPv6 has some other extensions (HMIP6 [RFC4140], FMIP6 [RFC4068], PMIP6 [Gundavelli08])for different application schemes. MIPv6 has two methods for multicast. [Schmidt07] has already analysis onBut theProns and Conscurrent IP mobility management mechanism lack ofthese two ways. Besides the MIP camp, there are some specific multicast solutions in 3GPP(MBMS)[MBMS] and 3GPP2 network(BCMCS)[BCMCS]. There is the possiblity that access gateway may experience the overload tofull supportthis kindofservices. Anyhow, Inmulticast service.This document will illustrate thereal deployment, BCMCS/MBMS maymain issue of them. Since DSMIP6 is principally similar to MIP6, so it will notalways available anywhere in operators' cellular network,they could also support the mobile IPTV servicesbe illustrated independently incellular networks.this document. 2.Requirements on multicastIP mobility managementformulticast support in mobileIPTVnetwork 2.1.(Mobile)Mobile IPTV multicast framework[IPTV.MC.FR] and [IPTV.FR]ITU 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 isservice/ networkservice/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] specifiedIn theservice requirementscase of(Mobile) IPTV. [IPTV.QoE.REQ] gives the requirements related to QoS and QoE. MobileIPTVservice includes multiple type of services,support in mobile network, suchas video, audio, data(captures, EPG, etc.). Video service need much bandwidth and also shouldarchitecture will bea service with high service quality. Network should implement traffic control for high priority multicast trafficconsidered and mapped toensuretheQOSnetwork entity ofmulticast. Specifically, following functions should be supported in the mobile network: (1)TotalIP mobility management. 2.2. Mobile IPv4 support MulticastBandwidth: access node should be able to control on total bandwidthSection 4.3 and 4.4 ofa user port that can be used for multicast service; (2)Current Available Bandwidth:[RFC3344] discuss theaccess node should be able to awaresupport ofcurrent available bandwidth that can be used formulticastservice, specifically, can be totaland broadcast. In order to receive multicastbandwidth consumedpacket through it's home network, a mobile node MUST join the multicastbandwidth; (3)Connection Admission Control (CAC): It is required that Connection Admission Control supportedgroup inAccess networkone of two ways. One is based onavailable resources. When end user subscribes to a multicast stream, access network will perform CAC: check if current available resources are enough forco-located care-of address, thenew 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, andother is based on themulticast replication function should forward multicast media contenthome address (foreign agent care-of address). In both cases, a mobile node tunnels IGMP messages tousers which haveits home agent, theprivilege of IPTVhome agent forwards multicastservices. (5) Packet loss: depending on the bit rate and video/audio profiles,datagrams down thevideo and audio streams have different levels of sensitiveness on packet loss. [IPTV.QoE.REQ] givestunnel to thedetail of packet loss requirements for all kinds of real-time mobile IPTV media streams. The multicastmobile node. Access networkshould gurantee not only(Wired or Wireless) IP multicast | packets +----+ | | | MN1| V +------+ +------+ | +----+---------------|======|=============| | | +----+ | FA | | HA | V | MN2|---------------|======|=============| |----- +----+ +------+ +------+ Figure 1: Nested tunneling in MIP4 for Multicast In thedurationcase ofsingle error, but alsoco-located care-of address, thetotal packet loss rate. Besides the packet loss at radio interface,home agent SHOULD tunnel themulticast handoff will also incur some packet loss. (6) Packet priority: considering the video/audio compression characteristics, different packets may have different importance. It is recommendeddatagram toprovide better guarantee for important packets. (7) Synchronization: Mobile IPTV services is also an integrated service with synchronized multiple streams. Althoughthis care-of address directly; In theservice provider andcase of foreign agent care-of address, theterminal may have some solutionhome agent MUST first encapsulate the datagram in a unicast datagram addressed tomaintain synchronized streams,the mobilenetwork may also incur delaynode's home address andjitter. So,then MUST tunnel themobile multicast should provide some machenismresulting datagram (nested tunneling) toensurethesynchronization ofmobileIPTV streams. (8) Notification:node's care-of address.If there aresome mobile IPTV service events, whichmore than 500 MNs under the same FA, there willtrigger notification messages. The multicast mobile network should understand such kind of notificationsbe 500 tunnels between HA andmake the actions accordingly. In this sense, a notifiction solution among the nodes ofFA to transmit multicastmobile network mya be useful.packets. 2.3.CorrespondenceMobile IPv6tosupport Multicastfor 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. Access network (Wired or Wireless) IP multicast +------+ | packets | | | | | MN | V +------+ +------+ | | |===============|======|=============| | | +------+ | | | | V bi-dictional tunnel | AR | | HA |----- +------+ | | | | | |===============|======|=============| | | MN | +------+ +------+ | | +------+Bandwidth efficiency: The advantage of the bi-directionalFigure 2: Nested tunnelingsolution (as the above figure) 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 (as the below figure). In the deployment of mobile IPv6inwireless 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. Access network (Wired or Wireless) IP multicast +------+ | packets | | | | | MN | V +------+ +------+ | | |===============|======| | | | +------+ | | | | V bi-dictional tunnel | AR |=============| HA |----- +------+ | | | | | |===============|======| | | | MN | +------+ +------+ | | +------+ 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 MAGMIP6 forseveral considerations.Multicast 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.3. One Problem about Mobile Multicast The current MBMS whichBy the way, it isdefined in 3GPP [MBMS] may experience overload for each network entity such as access gatewayrecommended that DSMIP6 has similar situation, andbroadcast/multicast server, in the case ofProxy mobilenode frequently join and quit from the multicast group, multicast service announcement may also need toIPv6 will bereconsidered. 4.described in a seperate document. 3. 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 securityholes. 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 againstholes such as denial of serviceattacks 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 anyattacks. After the integration IP mobility management like MIP4, MIP6 with the multicastevents. - Multicast system architecture is required to be independent of adjacent domain such thatservice, itshallshould notaffectdepreciate theadjacent multicast domain without permission. - Multicast system architecture is required to provide a mechanism to check integritysecurity protection ofmulticast contents before service delivery such that it prevents unauthorized contents from becomingthecontent source. 5.basic IP mobility management mechanism. 4. IANA Considerations This document makes no requests to IANA.6. 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. 7. References 7.1.5. Normative References [DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06.txt (work in progress), November 2007. [Gundavelli08] Gundavelli, S., "Proxy Mobile IPv6",draft-ietf-netlmm-proxymip6-10.txtdraft-ietf-netlmm-proxymip6-18.txt (work in progress),FebruaryMay 2008. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.7.2. Informative References [BCMCS] 3GPP2, "Broadcast/Multicast Services - Stage 1, Revision A", 3GPP2 S.R0030-A V1.0, Feb. 2004. [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. [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. [Schmidt07] Schmidt, T., "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-02.txt (work in progress), November 2007.Authors' Addresses Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Peng Yang Hitachi(China) R&D Corporation301, 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. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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).