Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track S. Krishnan
Expires: August 21, 2008 Ericsson
February 18, 2008
Multicast Mobility Problem Statement
<draft-sarikaya-multimob-ps-00.txt>
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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document discusses problems that are caused due to the mobility
of multicast receivers. It also divides the problems based on the
protocols that they need to be fixed in.
Sarikaya & Krishnan Expires August 21, 2008 [Page 1]
Internet-Draft Multicast Mobility PS February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multicast Mobility Problem . . . . . . . . . . . . . . . . . . 3
4. Problems due to multicast for mobile nodes . . . . . . . . . . 5
4.1. Bandwidth wastage . . . . . . . . . . . . . . . . . . . . . 5
4.2. Lack of multicast support in mobility protocols . . . . . . 5
4.3. Scalability issues due to point-to-point links . . . . . . 5
4.4. Increased leave latency . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Sarikaya & Krishnan Expires August 21, 2008 [Page 2]
Internet-Draft Multicast Mobility PS February 2008
1. Introduction
More and more operators are beginning to provide the wireless
broadband network services such as Mobile IPTV. Mobile IPTV service
is a kind of audio/video (A/V) service which is combined with
interactive data for the related or supplementary information of A/V
program using bi-directional wireless broadband links. Users can
enjoy the downlink A/V stream and request more detailed or value-
added information via uplink simultaneously. Mobile IPTV service,
which can also be described as place-shifting IPTV service, is to
ensure continuous and original IPTV experiences for the users who
move to the other place from where he or she was originally
subscribed for [ITUIPTV].
Apart from Mobile IPTV which is considered "the killer application",
content broadcasting and streaming over audio and video conferencing,
online multiplayer gaming are applications of IP multicast technology
for mobile users. In this document we will establish the
requirements on supporting multicast mobility by way of improvements
on various protocols on which the mobile users depend in order to
receive Mobile IPTV and other multicast services
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
This document uses the terminology defined in [RFC3775], [RFC3376],
[RFC3810] and [I-D.ietf-mboned-lightweight-igmpv3-mldv2].
3. Multicast Mobility Problem
Figure 1 illustrates the key architectural components of multicast
mobility.
Sarikaya & Krishnan Expires August 21, 2008 [Page 3]
Internet-Draft Multicast Mobility PS February 2008
Mobile | Access Network | Service Provider
Multicast User| | (Edge + Core Network)
+-----+ Wireless +-----+ +------+ +--------+ --------------
| MN |--link --| BS |-----+Access+---+ Edge | / Multicast- \
+-----+ +-----+ |Router| | Router +==>| Enabled |
+--+---+ +--------+ \ Internet /
-------------
+-----+ +-----+ | /\ /\
| MN |------------| BS |--------+ || ||
+-----+ +-----+ || ||
| Home Network || ||
| || ||
+------+ || ||
|Home |==== ||
|Agent | ||
+------+ ||
| Content Provider ||
| Network ||
+-------+ ||
|Content|=======||
|Source |
+-------+
Figure 1: Transport Profile of Multicast Mobility
Mobile nodes (MN) attach to a base station (BS) through wireless
interfaces. The Access Router (AR) is the first IP hop router of
MNs. MN as the multicast receiver uses the access network to receive
the content coming from the content network where the multicast
source is located. The edge network aggregates between the access
and the core which is the backbone infrastructure. Multicast enabled
core, edge and access network is assumed in this document.
MN uses Internet Group Management Protocol (IGMP) [RFC3376] or
Multicast Listener Discovery (MLD) [RFC3810] to dynamically join/
leave multicast groups. IGMP/MLD runs between MN and the AR. This
is called local subscription. If mobility protocol such as Mobile IP
[RFC3775] is used, IGMP/MLD runs between MN and the home agent (HA)
at the home network. This is called remote subscription. While the
current Mboned work on light-weight IGMP/MLD
[I-D.ietf-mboned-lightweight-igmpv3-mldv2] aims to simplify the
original IGMPv3/MLDv2 thereby simplifying switch and host-side
implementation, there is work needed to support mobility in IGMP/MLD.
Currently the unicast global mobility protocol MIPv6 [RFC3775] allows
remote subscription and HA tunnels multicast traffic to MN's current
Sarikaya & Krishnan Expires August 21, 2008 [Page 4]
Internet-Draft Multicast Mobility PS February 2008
access network. This creates a bidirectional tunnel which is
inefficient.
4. Problems due to multicast for mobile nodes
The currently available multicast protocols were designed based on
the receivers being fixed nodes with large processing capacities.
Because of this, they usually have large leave latencies and are not
bandwidth efficient. They also potentially involve extensive
computation capabilities on the nodes.
4.1. Bandwidth wastage
Currently defined multicast protocols like IGMP and MLD send frequent
messages over the link on which the mobile node is connected. This
implies a wasteful use of spectrum resources on a potentially
expensive wireless link. This problem can be mitigated by correctly
adjusting the timing parameters on these multicast protocols.
4.2. Lack of multicast support in mobility protocols
Currently defined mobility protocols like MIPv6 [RFC3775] do not
really support native multicast. When a mobile node joins a
multicast group, it uses its home address to do so. Hence, the
multicast packets are sent to the home agent in the mobile node's
home network. The home agent then encapsulates these packets inside
an unicast tunnel terminating at the mobile node. Thus, multiple
mobile nodes attached to the same foreign link cannot share the same
multicast stream, since they receive only an unicast packet. This
leads to useless duplication of multicast packets, while it could be
avoided. This can be mitigated by adding multicast extensions to the
binding caches of mobility protocols.
4.3. Scalability issues due to point-to-point links
Currently defined multicast protocols do not scale very well if the
last hop multicast router is connected to a large number of mobiles
using point-to-point links. This is because the router has to keep
track of each mobile on a separate interface. Thus the number of
queries the router has to send out increases greatly with a large
number of mobile nodes. This problem can be mitigated by minor
modifications to the multicast protocols to simplify their behavior
on point-to-point links. e.g. remove host suppression, remove random
delays before responses etc.
Sarikaya & Krishnan Expires August 21, 2008 [Page 5]
Internet-Draft Multicast Mobility PS February 2008
4.4. Increased leave latency
When a mobile host leaves a multicast group on an access link, the
multicast router has to perform a query to determine whether any more
hosts remain on the same multicast group on the same link. This
increases the leave latency to an unacceptable level. There are
several ways to mitigate the problem like tuning of the multicast
protocol timers and explicit host tracking.
5. Security Considerations
This draft is an informational document and adds no new security
issues.
6. IANA Considerations
This is an informational document and creates no new IANA
considerations.
7. Acknowledgements
This document is written based on the requirements drafts written by
various authors:
o Multicast Mobility in MIPv6: Problem Statement and Brief Survey,
T. C. Schmidt and Matthias Waehlisch,
o Problem Statement and Requirement: Mobile Multicast, H. Deng, et
al.,
o Mobile Multicast Requirements on IGMP/MLD Protocols, H. Liu and H.
Asaeda,
o MIPv6 Extensions for Mobile Multicast: Problem Statement, J.F.
(Tony) Guan, et al.
8. References
8.1. Normative References
[I-D.ietf-mboned-lightweight-igmpv3-mldv2]
Liu, H., "Lightweight IGMPv3 and MLDv2 Protocols",
draft-ietf-mboned-lightweight-igmpv3-mldv2-02 (work in
progress), November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Sarikaya & Krishnan Expires August 21, 2008 [Page 6]
Internet-Draft Multicast Mobility PS February 2008
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
8.2. Informative References
[ITUIPTV] "IPTV Service Scenarios", May 2007.
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Email: sarikaya@ieee.org
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Sarikaya & Krishnan Expires August 21, 2008 [Page 7]
Internet-Draft Multicast Mobility PS February 2008
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).
Sarikaya & Krishnan Expires August 21, 2008 [Page 8]