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]