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]