Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track T. Schmidt
Expires: November 14, 2009 HAW Hamburg, Dept. Informatik
S. Krishnan
Ericsson
May 13, 2009
Proxy Mobile IPv6 Basic Multicast Support Solution
<draft-gundavelli-multimob-pmip6basicmcast-solution-01.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 November 14, 2009.
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.
Sarikaya, et al. Expires November 14, 2009 [Page 1]
Internet-Draft Mobile Multicast May 2009
Abstract
This document describes how multicast routing can be supported in
Proxy Mobile IPv6 in a way similar to Mobile IPv6. Mobile Access
Gateway tunnels MLD messages from the mobile nodes to local mobility
anchor. Local mobility anchor joins the multicast group and starts
forwarding the received multicast packets to the mobile access
gateway. In case of 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 . . . . . . . . . . . . . . . . 6
6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Sarikaya, et al. Expires November 14, 2009 [Page 2]
Internet-Draft Mobile Multicast May 2009
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, 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.
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]. Mobility 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
Goals document [RFC4831].
Sarikaya, et al. Expires November 14, 2009 [Page 3]
Internet-Draft Mobile Multicast May 2009
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
[I-D.ietf-netlmm-pmip6-ipv4-support]. Mobility 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
Sarikaya, et al. Expires November 14, 2009 [Page 4]
Internet-Draft Mobile Multicast May 2009
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.
Mobility 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)
where the receiver list is a potentially long list of link-local
source addresses of all the mobile nodes that are currently members
Sarikaya, et al. Expires November 14, 2009 [Page 5]
Internet-Draft Mobile Multicast May 2009
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
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:
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 2: 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:
Sarikaya, et al. Expires November 14, 2009 [Page 6]
Internet-Draft Mobile Multicast May 2009
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.
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 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.
Because mobile access gateway is not MLDv2 capable, the mobile node
receives all multicast data packets from local mobility anchor as
unicast packets with the multicast datagram encapsulated. The mobile
node MUST be capable of decapsulating packets sent to its home
address in order to receive multicast datagrams.
Sarikaya, et al. Expires November 14, 2009 [Page 7]
Internet-Draft Mobile Multicast May 2009
7. Security Considerations
This draft introduces no additional messages. Compared to [RFC3810]
and [RFC5213] there is no additional threats to be introduced.
8. IANA Considerations
None.
9. Acknowledgements
TBD.
10. References
10.1. Normative References
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Sarikaya, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12
(work in progress), April 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] Sarikaya, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Sarikaya, et al. Expires November 14, 2009 [Page 8]
Internet-Draft Mobile Multicast May 2009
10.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
Thomas C. Schmidt
HAW Hamburg, Dept. Informatik
Berliner Tor 7
D-20099 Hamburg, Germany
Email: Schmidt@informatik.haw-hamburg.de
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Sarikaya, et al. Expires November 14, 2009 [Page 9]