Network Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track B. Sarikaya
Expires: January 7, 2010 Huawei USA
TC. Schmidt
HAW Hamburg, Dept. Informatik
July 6, 2009
Proxy Mobile IPv6 Basic Multicast Support Solution
<draft-krishnan-multimob-pmip6basicmcast-solution-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Krishnan, et al. Expires January 7, 2010 [Page 1]
Internet-Draft Mobile Multicast July 2009
Abstract
This document describes how multicast routing can be supported in
Proxy Mobile IPv6 in a way similar to Mobile IPv6. The Mobile Access
Gateway tunnels MLD messages from the mobile nodes to local mobility
anchor. The Local Mobility Anchor joins the multicast group and
starts forwarding the received multicast packets to the mobile access
gateway. In case of a handover the tunnel end point changes but the
operation remains anchored at the local mobility anchor.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of PMIPv6 Multicast . . . . . . . . . . . . . . . . . 4
3.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 4
4. Local Mobility Anchor Operation . . . . . . . . . . . . . . . . 5
4.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 6
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . . 7
6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Krishnan, et al. Expires January 7, 2010 [Page 2]
Internet-Draft Mobile Multicast July 2009
1. Introduction
More and more operators are beginning to provide wireless broadband
network services such as Mobile IPTV. Mobile IPTV service is an
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]. IPTV
strongly relies on a group distribution system available in the
network.
Apart from Mobile IPTV, packet based point-to-multipoint group voice
application like push to talk, content broadcasting and streaming
over audio and video conferencing, online multiplayer gaming, mobile
chat and instant messaging, file transfer to recipients of a group
whose members could be on the move are applications of IP multicast
technology for mobile users. Most of these services pose rigid real-
time constraints onto the network infrastructure challenging both,
mobility and multicast routing protocol performance [MMCASTv6-PS].
Localized mobility management domain is an access network that
supports IP level mobility without requiring client software on the
mobile nodes [RFC4831]. Proxy Mobile IPv6 (PMIPv6) provides mobility
support to the mobile nodes (MN) in a localized mobility management
domain [RFC5213]. Mobile access gateway (MAG) proxies MN in mobility
signaling (proxy binding update/acknowledgement) with the localized
mobility anchor (LMA). PMIPv6 is currently an unicast mobility
protocol.
In this document we will describe how multicast routing can be
supported in Proxy Mobile IPv6 [RFC5213]. PMIPv6 has potential to be
widely used and because of this multicast mobility support in PMIPv6
is essential. PMIPv6 with multicast routing support can then be used
in Mobile IPTV and other IP multicast applications to provide
seamless mobility.
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] and in NetLMM
Krishnan, et al. Expires January 7, 2010 [Page 3]
Internet-Draft Mobile Multicast July 2009
Goals document [RFC4831].
3. Overview of PMIPv6 Multicast
This document describes Local Mobility Anchor-based basic multicast
forwarding in Proxy Mobile IPv6. Mobility Access Gateway is not
enabled to support multicast routing. The base protocol only
supports receiver mobility.
When mobile node wishes to join a multicast group it sends a Mobile
Listener Discovery Version 2 (MLDv2) protocol Report message to its
Mobility Access Gateway. The mobile node MUST use the link-local
address as the source address to send the MLD Report and any
subsequent MLD messages. Mobility Access Gateway encapsulates the
message and forwards it to Local Mobility Anchor on the bi-
directional tunnel between Mobility Access Gateway and Local Mobility
Anchor.
Local Mobility Anchor decapsulates the MLD report message from the
Mobility Access Gateway. Local Mobility Anchor joins the group on
behalf of the mobile node with the upstream multicast router (MR).
Local Mobility Anchor sets up multicast state as multicast router for
the listener which is the mobile node.
Multicast data packets received by Local Mobility Anchor MUST be
encapsulated and sent to Mobility Access Gateway on the bi-
directional tunnel. Mobility Access Gateway decapsulates the packet
and sends it to the mobile node.
Since Mobility Access Gateway does not keep multicast state, if the
decapsulated packet is a multicast packet Mobility Access Gateway can
not send it to the mobile node. This requires Local Mobility Anchor
to duplicate the multicast packet for each member in the multicast
group and encapsulate the multicast packet with a unicast header.
This encapsulation is done first. Next, based on the destination
address (MN-HoA) the packet is encapsulated again to be sent to the
Mobility Access Gateway for this mobile node [RFC3344].
In case of handover the new Mobility Access Gateway sends a Proxy
Binding Update to Local Mobility Anchor. This message will update
the binding cache entry so that it points for this MN-HoA to the new
Mobility Access Gateway's Proxy-CoA.
3.1. IPv4 Support
For mobile nodes that have IPv4 stack enabled Proxy Mobile IPv6 can
provide IPv4 home address mobility support
Krishnan, et al. Expires January 7, 2010 [Page 4]
Internet-Draft Mobile Multicast July 2009
[I-D.ietf-netlmm-pmip6-ipv4-support]. Mobile access gateway gets an
IPv4 home address for the mobile node as described in
[I-D.ietf-netlmm-pmip6-ipv4-support]. When such a mobile node wishes
to join a multicast group it sends an Internet Group Management
Protocol version 3 (IGMPv3) Membership Report message to its Mobility
Access Gateway. IGMPv3 requires a valid IP source address to be used
as the source address of the membership report message. Mobile node
MUST use its home address as the source address of the membership
report message.
Mobile access gateway tunnels the report message to the local
mobility anchor. Local mobility anchor decapsulates the IGMP report
message from the Mobility Access Gateway. Local Mobility Anchor
joins the group on behalf of the mobile node with the upstream
multicast router (MR). Local Mobility Anchor sets up multicast state
as multicast router for the listener which is the mobile node.
When packets are received for the multicast group that the mobile
node is subscribed, local mobility anchor encapsulates each packet
and sends it to each mobile node on the tunnel between local mobility
anchor and mobile access gateway.
4. Local Mobility Anchor Operation
Local Mobility Anchor is the multicast router for all mobile nodes in
Proxy Mobile IPv6 domain and performs the multicast router part of
MLDv2 [RFC3810]. After receiving MLD Report message from the mobile
node, Local Mobility Anchor joins the multicast tree for this
multicast group with an upstream router.
MLDv2 nodes maintain multicast listening state per multicast address
which keeps track of the sources of the multicast group. This allows
a simple forwarding downstream of the multicast packet received from
one of the sources. As for the group membership, local mobility
anchor receives information about the receivers by sending periodic
queries to the mobile nodes. Since Proxy Mobile IPv6 supports Per-MN
prefix model the query messages and report messages are sent
individually to each mobile node. This means that each group can
have only one member on the link between local mobility anchor and
mobile node. However a given multicast group may have more than one
member each located on a different point-to-point link.
Local Mobility Anchor MUST maintain multicast membership status state
for the the mobile nodes. This state consists of a set of records of
the form:
(IPv6 multicast address, receiver list)
Krishnan, et al. Expires January 7, 2010 [Page 5]
Internet-Draft Mobile Multicast July 2009
where the receiver list is a potentially long list of link-local
source addresses of all the mobile nodes that are currently members
of this multicast group.
When a multicast packet is received from the upstream multicast
router, local mobility anchor searches the multicast membership
status state for the source multicast address. When a match is
found, local mobility anchor tunnels the packet to each member in the
receiver list on the bi-directional tunnel between local mobility
anchor and mobile access gateway. For each receiver, local mobility
anchor searches the binding cache entry to find a match to the link
local source address. When a match is found, the corresponding
mobile access gateway address, i.e Proxy-CoA and mobile node home
address, i.e. MN-HoA are used in formating the tunneled packet. The
format of the tunneled packet is shown below (where CP stands for the
content provider for the multicast channel):
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */
IPv6 header (src=CP, dst= Multicast group) /* Multicast Packet */
Upper layer protocols /* Packet Content*/
Figure 1: Tunneled Multicast Packet from LMA to MAG
MLDv2 General Queries sent by the local mobility anchor are sent to
the link-local all-nodes multicast address (FF02::1). Local mobility
anchor MUST tunnel the general queries to each MN that has MLD
multicast membership state.
The format of the tunneled packet is shown below:
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */
IPv6 header (src=LMA Link-local, dst= FF02::1) /* Multicast Packet */
General Query /* Packet Content*/
Figure 2: Tunneled Multicast Packet from LMA to MAG
4.1. IPv4 Support
If IPv4 transport is used between mobile access gateway and local
mobility anchor, the format of the tunneled packet is shown below:
Krishnan, et al. Expires January 7, 2010 [Page 6]
Internet-Draft Mobile Multicast July 2009
IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */
IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */
IPv4 header (src=CP, dst= Multicast group) /* Multicast Packet */
Upper layer protocols /* Packet Content*/
Figure 3: Tunneled Multicast IPv4 Packet from LMA to MAG
IGMP general queries are sent to all systems on this subnet multicast
address (224.0.0.1). Local mobility anchor MUST tunnel the general
queries to each MN that has IGMP multicast membership state.
The format of the tunneled packet is shown below if IPv4 transport is
used:
IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */
IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */
IPv4 header (src=IPv4-LMAA1, dst= 224.0.0.1) /* Multicast Packet */
General Query /* Packet Content*/
Figure 4: Tunneled Multicast IPv4 Packet from LMA to MAG
5. Mobile Access Gateway Operation
Proxy Mobile IPv6 base specification [RFC5213] requires Mobile Access
Gateway to not to forward the packets that are sent with the link-
local source address to support Duplicate Address Detection protocol.
However in this document we modify this in order to allow MLDv2
packets to be exchanged between Local Mobility Anchor and mobile
node. Mobile Access Gateway MUST tunnel a packet from a mobile node
connected to its access link with an IP destination address of FF02:
0:0:0:0:0:0:16 (all MLDv2-capable routers) through the bi-
directional tunnel established between itself and the mobile node's
local mobility anchor. MLDv2 also requires the source address of
such packets to be link-local address of the mobile node.
When forwarding packets sent to the mobile node, after removing the
outer header, if the mobile access gateway determines that the inner
packet is encapsulated and the source address is the local mobility
anchor address, it MUST remove this second outer header. The mobile
access gateway MUST forward the resulting packet on the connected
interface associated with the destination address of the second outer
header.
Krishnan, et al. Expires January 7, 2010 [Page 7]
Internet-Draft Mobile Multicast July 2009
6. Mobile Node Operation
In order to receive multicast packets from the multicast groups of
interest, Mobile node must be MLDv2-capable. MLDv2 is run between
the mobile node and Local Mobility Anchor with the mobile node being
the multicast address listener and local mobility anchor the
multicast router.
When an application wants to join a multicast group such as receive
IPTV, the application makes a join socket call. This triggers MLDv2
layer to send Multicast Listener Report to Mobile Access Gateway
which tunnels it to local mobility anchor. The source address of the
MLDv2 Report message is mobile node's link-local address and the
destination address is FF02:0:0:0:0:0:0:16, i.e. MLDv2 capable
routers group address. Local mobility anchor as multicast router
joins the multicast group and gets attached to the multicast tree
associated with this multicast group. Multicast packets sent to the
multicast group address are received by the local mobility anchor
which tunnels them to the mobile access gateway.
By the time mobile node sends the first MLDv2 report message mobile
access gateway must have registered this mobile node to the local
mobility anchor. Proxy Mobile IPv6 base protocol assures that
mobile-node link local address is unique in the point-to-point link
between the mobile node and mobile access gateway and also the mobile
node is registered with its local mobility anchor (LMA) (using Proxy
Binding Update/ Acknowledgement exchange between mobile access
gateway and local mobility anchor) before the mobile node completes
the duplicate address detection (DAD) operation (Section 6.8 in
[RFC5213]). Mobile node MUST send MLDv2 report message after DAD
operation is completed.
7. Security Considerations
This draft introduces no additional messages. Compared to [RFC3810],
[RFC3376], [RFC5213], and [I-D.ietf-netlmm-pmip6-ipv4-support] there
are no additional threats to be introduced.
8. IANA Considerations
None.
9. Acknowledgements
The authors would like to thank Jouni Korhonen for his comments on
Krishnan, et al. Expires January 7, 2010 [Page 8]
Internet-Draft Mobile Multicast July 2009
the mailing list.
10. References
10.1. Normative References
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13
(work in progress), June 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[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.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
10.2. Informative References
[ITUIPTV] Li, M., "IPTV Service Scenarios", ITU-T IPTV Focus Group
on IPTV FG-IPTV-DOC-0085, May 2007.
[MMCASTv6-PS]
Schmidt, TC., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in MIPv6: Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-07 (work in progress),
April 2009.
Krishnan, et al. Expires January 7, 2010 [Page 9]
Internet-Draft Mobile Multicast July 2009
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Email: sarikaya@ieee.org
Thomas C. Schmidt
HAW Hamburg, Dept. Informatik
Berliner Tor 7
D-20099 Hamburg, Germany
Email: Schmidt@informatik.haw-hamburg.de
Krishnan, et al. Expires January 7, 2010 [Page 10]