[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01

MULTIMOB Group                                              J. C. Zuniga
INTERNET-DRAFT                        (InterDigital Communications, LLC)
Intended Status: Standards Track                         L. M. Contreras
Expires: May 2, 2012                                    (Telefonica I+D)
                                                         C. J. Bernardos
                                      (Universidad Carlos III de Madrid)
                                                                 S. Jeon
                                                                  Y. Kim
                                                   (Soongsil University)
                                                        October 30, 2011



     Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
               <draft-zuniga-multimob-pmipv6-ropt-01.txt>


Abstract

   The MULTIMOB group has specified a base solution to support IP
   multicasting in a PMIPv6 domain [RFC6224]. In this document, some
   enhancements are proposed to the base solution. These enhancements
   include the use of a multicast tree mobility anchor as the
   topological anchor point for multicast traffic, as well as a direct
   routing option where the MAG can provide access to multicast content
   in the local network. These enhancements provide benefits such as
   reducing multicast traffic replication and supporting different
   PMIPv6 deployments scenarios.


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/1id-abstracts.html




Zuniga, et al.            Expires May 2, 2012                   [Page 1]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

































Zuniga, et al.            Expires May 2, 2012                   [Page 2]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2  Conventions and Terminology  . . . . . . . . . . . . . . . . . . 4
   3  Multicast Tree Mobility Anchor (MTMA)  . . . . . . . . . . . . . 5
      3.1  Architecture  . . . . . . . . . . . . . . . . . . . . . . . 6
      3.2  Deployment Scenarios  . . . . . . . . . . . . . . . . . . . 7
         3.2.1  PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . 8
         3.2.2  PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . 8
         3.2.3  PMIPv6 domain with ratio 1:N . . . . . . . . . . . .  10
         3.2.4  PMIPv6 domain with H-LMA . . . . . . . . . . . . . .  11
      3.3  Multicast Establishment . . . . . . . . . . . . . . . . .  14
      3.4  Multicast Mobility  . . . . . . . . . . . . . . . . . . .  15
      3.5  PMIPv6 enhancements . . . . . . . . . . . . . . . . . . .  16
         3.5.1  New Binding Update List in MAG . . . . . . . . . . .  16
         3.5.2  Policy Profile Information with Multicast Parameters  17
         3.5.3  MAG to MTMA attach requirements  . . . . . . . . . .  17
         3.5.4. Data structure stored by MTMA  . . . . . . . . . . .  17
      3.6  Advantages  . . . . . . . . . . . . . . . . . . . . . . .  17
   4  Direct routing . . . . . . . . . . . . . . . . . . . . . . . .  21
      4.1 MAG as MLD proxy . . . . . . . . . . . . . . . . . . . . .  22
         4.1.1 Local subscription when the MAG implements MLD proxy
               functionality   . . . . . . . . . . . . . . . . . . .  22
            4.1.1.1 Local subscription architecture  . . . . . . . .  22
            4.1.1.2 Handover procedure for local routing . . . . . .  23
         4.1.2 Remote subscription when the MAG implements MLD
               proxy functionality . . . . . . . . . . . . . . . . .  24
      4.2 MAG as multicast router  . . . . . . . . . . . . . . . . .  25
         4.2.1 Local subscription when the MAG implements a
               multicast routing protocol  . . . . . . . . . . . . .  25
         4.2.2 Remote subscription when the MAG implements a
               multicast routing protocol  . . . . . . . . . . . . .  25
   5 Dynamic selection of local versus remote multicast subscription  25
      5.1 Any source multicast scenario  . . . . . . . . . . . . . .  26
      5.2 Source specific multicast scenario . . . . . . . . . . . .  26
   6  Security Considerations  . . . . . . . . . . . . . . . . . . .  27
   7  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  27
   8  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  27
   9  References . . . . . . . . . . . . . . . . . . . . . . . . . .  27
      9.1  Normative References  . . . . . . . . . . . . . . . . . .  27
      9.2  Informative References  . . . . . . . . . . . . . . . . .  28
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29









Zuniga, et al.            Expires May 2, 2012                   [Page 3]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


1  Introduction

   Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving
   the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the
   Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the
   network and does the mobility management on behalf of the Mobile Node
   (MN). The Local Mobility Anchor (LMA) is the home agent for the MN
   and the topological anchor point. PMIPv6 was originally designed for
   unicast traffic.

   The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by
   IPv4 hosts to report their IP multicast group memberships to
   neighboring multicast routers. Multicast Listener Discovery (MLDv2)
   [RFC3810] is used in a similar way by IPv6 routers to discover the
   presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605]
   allows an intermediate (edge) node to appear as a multicast router to
   downstream hosts, and as a host to upstream multicast routers. IGMP
   and MLD related protocols were not originally designed to address IP
   mobility of multicast listeners (i.e. IGMP and MLD protocols were
   originally designed for fixed networks).

   The MULTIMOB group has specified a base solution to support IP
   multicast listener mobility in a PMIPv6 domain [RFC6224], which
   describes deployment options without modifying mobility and multicast
   protocol standards. The PMIPv6 allows a MAG to establish a multiple
   of PMIPv6 tunnels with LMAs. Hence, when IP multicasting is applied
   into PMIPv6, it leads to redundant traffic at a MAG called "Tunnel
   Convergence problem". To address this issue, two enhancements are
   proposed in this document; multicast anchor and direct routing. The
   former uses a multicast tree mobility anchor (MTMA) as the
   topological anchor point for delivering multicast traffic, while the
   latter uses direct routing, allowing a MAG to connect directly to a
   multicast router for simple access to local content. Both schemes
   have no impact on the MN to support multicast listener mobility.

   The MTMA architecture and solution are described in section 3.
   Section 4 describes the direct routing solution and the enhancements
   details. Section 5 describes the details about the selection at the
   MAG between direct routing (e.g. for local access) and MTMA (e.g. for
   remote access).


2  Conventions and 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 RFC 2119 [RFC2119].




Zuniga, et al.            Expires May 2, 2012                   [Page 4]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   This document uses the terminology defined in [RFC5213], [RFC3775],
   and [RFC3810]. Specifically, the definition of PMIPv6 domain is
   reused from [RFC5213] and reproduced here for completeness.

      - Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6
      domain refers to the network where the mobility management of a
      mobile node is handled using the Proxy Mobile IPv6 protocol as
      defined in [RFC5213]. The Proxy Mobile IPv6 domain includes local
      mobility anchors and mobile access gateways between which security
      associations can be set up and authorization for sending Proxy
      Binding Updates on behalf of the mobile nodes can be ensured.

   In this draft we refine such definition from the point of view of the
   kind of traffic served to the MN in the following way:

      - PMIPv6 unicast domain: PMIPv6 unicast domain refers to the
      network covered by one LMA for unicast service in such a way that
      an MN using that service is not aware of mobility as it moves from
      one MAG to another associated to that LMA regarding its unicast
      traffic.

      - PMIPv6 multicast domain: PMIPv6 multicast domain refers to the
      network covered by one network element named MTMA (defined below)
      for multicast service in such a way that an MN using that service
      is not aware of mobility as it moves from one MAG to another.

      - Direct routing: it uses native multicast infrastructure for
      retrieving multicast data. For the operator having its own local
      content, this technique also includes the case that content source
      is directly connected to a MAG.

   This means that a PMIPv6 domain can have several PMIPv6 unicast
   domains and PMIPv6 multicast domains.

   Additionally, some other definitions are introduced, as follows.

      - MTMA or multicast tree mobility anchor: an entity working as
      topological anchor point for multicast traffic exclusively.

      - H-LMA or Hybrid-LMA: an entity dedicated to both unicast and
      multicast services, that is, it is able to work as both LMA and
      MTMA simultaneously.


3  Multicast Tree Mobility Anchor (MTMA)

   A PMIPv6 domain may handle data from both unicast and multicast
   sources. This document addresses optimizations to the base solution



Zuniga, et al.            Expires May 2, 2012                   [Page 5]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   specified for multicast support in PMIPv6 domains [RFC6224] by
   firstly introducing a complementary network entity, named multicast
   tree mobility anchor (MTMA), and defining the architecture and
   protocol flows derived from it; and secondly by defining a direct
   routing option where a MAG can directly receive packets from a
   multicast router.

   An MTMA can be used to serve as the mobility anchor for multicast
   traffic. The MTMA connects to the MAG as described in [RFC6224] and
   it can reuse native PMIPv6 features such as tunnel establishment and
   security [RFC5213], heartbeat [RFC5847], etc. Unicast traffic will go
   normally to the LMAs in the PMIPv6 domain.

   This section describes how the MTMA works in scenarios of MN
   attachment and multicast mobility. We first concentrate on the case
   of both LMA and MTMA defining a unique PMIPv6 domain, and then
   different deployment scenarios are presented.


3.1  Architecture

   Figure 1 shows an example of a PMIPv6 domain supporting multicast
   mobility. LMA1 is dedicated to unicast traffic, and MTMA1 is
   dedicated to multicast traffic. The tree mobility anchor MTMA1 can be
   considered to be a form of upstream multicast router with tunnel
   interfaces allowing remote subscription for the MNs. Note that there
   can be multiple LMAs for unicast traffic (not shown in Figure 1) in a
   given PMIPv6 domain. Similarly, more than one MTMA can be deployed by
   the operator (not shown in Figure 1).

   Also in this architecture, all MAGs that are connected to the MTMA
   must support the MLD proxy [RFC4605] function. Specifically in Figure
   1, each of the MAG1-MTMA1 and MAG2-MTMA1 tunnel interfaces defines an
   MLD proxy domain.  The MNs are considered to be on the downstream
   interface of the MLD proxy (in the MAG), and MTMA1 is considered to
   be on the upstream interface (of the MAG) as per [RFC4605].  Note
   that MAG could also be an IGMP proxy.  For brevity this document will
   refer primarily to MLD proxy, but all references to "MLD proxy"
   should be understood to also include "IGMP/MLD proxy" functionality.

   As shown in Figure 1, MAG1 may connect to both unicast (LMAs) and
   multicast (MTMAs) entities. Thus, a given MN may simultaneously
   receive both unicast and multicast traffic. In Figure 1, MN1 and MN2
   receive unicast traffic, multicast traffic, or both, whereas MN3
   receives multicast traffic only, despite of that, this draft
   considers that every MN demanding multicast-only services is
   previously registered in a PMIPv6 unicast domain to get a unicast IP
   address. This registration can be required also for several purposes



Zuniga, et al.            Expires May 2, 2012                   [Page 6]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   such as remote management, billing, etc.

                                   +--------------+
                                   |Content Source|
                                   +--------------+
                                          |
                                          |
         ***  ***  ***  ***      ***  ***  ***  ***
        *   **   **   **   *    *   **   **   **    *
       *                    *  *                     *
       *  Unicast Traffic   *  *  Multicast Traffic  *
       *                    *  *                     *
        *   **   **   **   *    *   **   **   **   *
         ***  ***  ***  ***      ***  ***  ***  ***
                 |                       |
                 |                       |
                 |                       |
              +-----+                 +------+
     Unicast  | LMA1|                 | MTMA1|     Multicast
      Anchor  +-----+                 +------+      Anchor
                  \\                    // ||
                   \\                  //  ||
                    \\                //   ||
                     \\              //    ||
                      \\            //     ||
                       \\          //      ||
                        \\        //       ||
                         \\      //        ||
                          \\    //         ||
                          +-----+       +-----+
                          | MAG1|       | MAG2|      MLD Proxy
                          +-----+       +-----+
                          |     |          |
                          |     |          |
                        {MN1} {MN2}      {MN3}

    Figure 1. Architecture of Multicast Tree Mobility Anchor (MTMA)


3.2  Deployment Scenarios

   From the network architecture point of view, there are several
   options when considering the multicast tree mobility anchor (MTMA)
   approach. These options can be distinguished in terms of the number
   of LMAs and MTMAs present in a PMIPv6 domain and the service
   relationship that a set of MNs gets from them, in the form of a "LMA
   : MTMA" ratio. According to that, it is possible to differentiate the
   following approaches:



Zuniga, et al.            Expires May 2, 2012                   [Page 7]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


      - A set of MNs is served in a PMIPv6 domain by two entities, one
      MTMA for multicast service, and one LMA for unicast, in such a way
      that the ratio is 1:1 (one common PMIPv6 unicast and multicast
      domain).

      - A set of MNs is served in a PMIPv6 domain by several entities,
      one MTMA for multicast service, while the others (LMAs) for
      unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast
      domains coexist with a unique multicast domain).

      - A set of MNs is served in a PMIPv6 domain by several entities,
      one LMA for unicast, while the others (MTMAs) are devoted to
      multicast service, in such a way that the ratio is 1:N (one single
      PMIPv6 unicast domain coexists with multiple multicast domains).

   Scenarios with an N:M ratio are considered to be a combination of the
   previous ones.


3.2.1  PMIPv6 domain with ratio 1:1

   This approach basically refers to the architecture presented in
   figure 1. Within this approach, a common set of MNs is served by a
   couple of entities, one LMA for unicast and one MTMA for multicast.
   All the MNs of the set are served by these two elements as they move
   in the PMIPv6 domain.


3.2.2  PMIPv6 domain with ratio N:1

   This approach basically refers to the situation where a common set of
   MNs is served by a unique MTMA for multicast service, but
   simultaneously there are subsets from that group of MNs which are
   served by distinct LMAs for unicast service as they move in the
   PMIPv6 domain. Each particular MN association with the LMAs (unicast)
   and MTMA (multicast) remains always the same as it moves in the
   PMIPv6 domain.

   Figure 2 shows the scenario here described.












Zuniga, et al.            Expires May 2, 2012                   [Page 8]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


               +----------------+       +----------------+
               |Content Source A|       |Content Source B|
               +----------------+       +----------------+
                      |                      |
                      |                      |
            ***  ***  ***  ***  ***  ***  ***  *** *** *** ***
           *   **   **   **   **  **   **   **   **   **  **  *
          *                                                    *
          *                 Fixed Internet                     *
          *        (Unicast & Multicast Traffic)               *
           *   **   **   **   **  **   **   **   **   **  **  *
            ***  ***  ***  *** *** ***  ***  ***  ***  ***  ***
              |                     |                      |
              |                     |                      |
              |                     |                      |
           +-------+       +-----------------+          +-------+
           |  LMA1 |       |      MTMA2      |          |  LMA3 |
           +-------+       +-----------------+          +-------+
             || \\        oo    oo      oo   oo          //  ||
             ||  \\      oo     oo      oo    oo        //   ||
             ||   \\    oo      oo      oo     oo      //    ||
             ||    \\  oo       oo      oo      oo    //     ||
             ||     \\oo        oo      oo       oo  //      ||
             ||      \\         oo      oo        oo//       ||
             ||     oo\\        oo      oo         //        ||
             ||    oo  \\       oo      oo        //oo       ||
             ||   oo    \\      oo      oo       //  oo      ||
             ||  oo      \\     oo      oo      //    oo     ||
           +------+      +--------+     +--------+     +--------+
           | MAG1 |      |  MAG2  |     |  MAG3  |     |  MAG4  |
           +------+      +--------+     +--------+     +--------+
           |      |       |      |       |      |       |      |
           |      |       |      |       |      |       |      |
        {MN10}  {MN11}  {MN20} {MN21}  {MN30} {MN31} {MN40} {MN41}

                 Figure 2. PMIPv6 domain with ratio N:1

   The figure 2 proposes an architecture where there are two entities
   acting as LMAs, LMA1 and LMA3, while there is another one, named
   MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3
   constitute two distinct unicast domains, whereas MTMA2 forms a single
   multicast domain. The tunnels among MAGs and LMAs represented by
   lines ("||") indicate a tunnel transporting unicast traffic, while
   the tunnels among MAGs and MTMA2 depicted with circles ("o") show a
   tunnel transporting multicast traffic.

   In the figure it can be observed that all the MNs are served by MTMA2
   for the incoming multicast traffic from sources A or B. However,



Zuniga, et al.            Expires May 2, 2012                   [Page 9]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   there are different subsets regarding unicast traffic which maintain
   distinct associations within the PMIPv6 domain. For instance, the
   subset formed by MN10, MN11, MN20 and MN21 is served by LMA1 for
   unicast, and the rest of MNs are being served by LMA3. For the
   scenario described above, the association between each MN and the
   corresponding LMA and MTMA is permanently maintained.


3.2.3  PMIPv6 domain with ratio 1:N

   This approach is related to a scenario where a common group of MNs is
   served by a unique LMA for unicast service, but simultaneously there
   are subsets from that group of MNs which are served by distinct MTMAs
   for multicast service as they move in the PMIPv6 domain. Each
   particular MN association with the LMA and MTMAs (unicast and
   multicast respectively) remains always the same as it moves in the
   PMIPv6 domain.

   Figure 3 shows the scenario here described.

   The figure 3 proposes an architecture where the LMA2 is the unique
   LMA for a certain group of MNs, while there are two others entities,
   MTMA1 and MTMA3, acting as MTMAs for different subsets of MNs of the
   same group. MTMA1 and MTMA3 constitute two distinct multicast
   domains, whereas LMA2 forms a single unicast domain. Each MTMA could
   be devoted to carry on a different content (for instance, MTMA1 for
   source A and MTMA3 for source B) or not. Looking at the picture, the
   subset formed by MN10, MN11, MN20 and MN21 is served by MTMA1 for
   multicast. The rest of MNs are being served by MTMA3 also for
   multicast. Finally, all of them are served by LMA2 for unicast. For
   the scenario described above, the association between each MN and the
   corresponding LMA and MTMA is permanently maintained.



















Zuniga, et al.            Expires May 2, 2012                  [Page 10]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


               +----------------+       +----------------+
               |Content Source A|       |Content Source B|
               +----------------+       +----------------+
                      |                      |
                      |                      |
            ***  ***  ***  ***  ***  ***  ***  *** *** *** ***
           *   **   **   **   **  **   **   **   **   **  **  *
          *                                                    *
          *                 Fixed Internet                     *
          *        (Unicast & Multicast Traffic)               *
           *   **   **   **   **  **   **   **   **   **  **  *
            ***  ***  ***  *** *** ***  ***  ***  ***  ***  ***
              |                     |                      |
              |                     |                      |
              |                     |                      |
           +-------+       +-----------------+          +-------+
           | MTMA1 |       |       LMA2      |          | MTMA3 |
           +-------+       +-----------------+          +-------+
             oo oo        //    ||      ||   \\          oo  oo
             oo  oo      //     ||      ||    \\        oo   oo
             oo   oo    //      ||      ||     \\      oo    oo
             oo    oo  //       ||      ||      \\    oo     oo
             oo     oo//        ||      ||       \\  oo      oo
             oo      oo         ||      ||        \\oo       oo
             oo     //oo        ||      ||         \\        oo
             oo    //  oo       ||      ||        oo\\       oo
             oo   //    oo      ||      ||       oo  \\      oo
             oo  //      oo     ||      ||      oo    \\     oo
           +------+      +--------+     +--------+     +--------+
           | MAG1 |      |  MAG2  |     |  MAG3  |     |  MAG4  |
           +------+      +--------+     +--------+     +--------+
           |      |       |      |       |      |       |      |
           |      |       |      |       |      |       |      |
        {MN10}  {MN11}  {MN20} {MN21}  {MN30} {MN31} {MN40} {MN41}


                 Figure 3. PMIPv6 domain with ratio 1:N

3.2.4  PMIPv6 domain with H-LMA

   The H-LMA is defined as an entity which simultaneously transports
   unicast and multicast service, that is, it simultaneously works as
   LMA and MTMA. In the context of the MTMA solution, an H-LMA can play
   the role of MTMA for an entire group of MNs in a PMIPv6 domain, while
   acting simultaneously as LMA for a subset of them. The figure 4
   adapts the PMIPv6 domain with ratio N:1 scenario of figure 2 to the
   case where MTMA2 is an H-LMA, which serves multicast traffic to all
   the MNs in the picture, and simultaneously, it is able to serve



Zuniga, et al.            Expires May 2, 2012                  [Page 11]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   unicast traffic to the subset formed by MN30, MN40 and MN41.

   Figure 4 presents a PMIPv6 network where there are two pure unicast
   LMAs, LMA1 and LMA3, and a hybrid LMA, labeled as H-LMA in the
   figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4.
   The tunnels among MAGs and LMAs represented by lines ("||") indicate
   a tunnel transporting exclusively unicast traffic, the tunnels
   depicted with circles ("o") show a tunnel transporting exclusively
   multicast traffic, and the tunnels with mixed lines and circles
   ("db") describe a tunnel transporting both types of traffic
   simultaneously.

   All of the MNs in the figure receive the multicast traffic from H-LMA
   (one single multicast domain), but it is possible to distinguish
   three subsets from the unicast service perspective (that is, three
   unicast domains). The first subset is the one formed by MN10, MN11
   and MN 20, which receives unicast traffic from LMA1. A second subset
   is the one formed by MN21 and MN30, which receives unicast traffic
   from H-LMA. And finally, a third subset is built on MN31, MN40 and
   MN41, which receives unicast traffic from LMA3. For the scenario
   described above, the association between each MN and the
   corresponding LMA and H-LMA is permanently maintained.





























Zuniga, et al.            Expires May 2, 2012                  [Page 12]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


               +----------------+       +----------------+
               |Content Source A|       |Content Source B|
               +----------------+       +----------------+
                      |                      |
                      |                      |
            ***  ***  ***  ***  ***  ***  ***  *** *** *** ***
           *   **   **   **   **  **   **   **   **   **  **  *
          *                                                    *
          *                 Fixed Internet                     *
          *        (Unicast & Multicast Traffic)               *
           *   **   **   **   **  **   **   **   **   **  **  *
            ***  ***  ***  *** *** ***  ***  ***  ***  ***  ***
              |                     |                      |
              |                     |                      |
              |                     |                      |
           +-------+       +-----------------+          +-------+
           |  LMA1 |       |      H-LMA      |          |  LMA3 |
           +-------+       +-----------------+          +-------+
             || \\        oo    db      db   oo          //  ||
             ||  \\      oo     db      db    oo        //   ||
             ||   \\    oo      db      db     oo      //    ||
             ||    \\  oo       db      db      oo    //     ||
             ||     \\oo        db      db       oo  //      ||
             ||      \\         db      db        oo//       ||
             ||     oo\\        db      db         //        ||
             ||    oo  \\       db      db        //oo       ||
             ||   oo    \\      db      db       //  oo      ||
             ||  oo      \\     db      db      //    oo     ||
           +------+      +--------+     +--------+     +--------+
           | MAG1 |      |  MAG2  |     |  MAG3  |     |  MAG4  |
           +------+      +--------+     +--------+     +--------+
           |      |       |      |       |      |       |      |
           |      |       |      |       |      |       |      |
        {MN10}  {MN11}  {MN20} {MN21}  {MN30} {MN31} {MN40} {MN41}

                   Figure 4. PMIPv6 domain with H-LMA















Zuniga, et al.            Expires May 2, 2012                  [Page 13]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


3.3  Multicast Establishment

   Figure 5 shows the procedure when MN1 attaches to MAG1, and
   establishes associations with LMA (unicast) and MTMA (multicast).

           MN1                   MAG1       LMA       MTMA
            |                (MLD Proxy) (Unicast) (Multicast)
        MN attaches to MAG1       |          |          |
            |                     |          |          |
            |------Rtr Sol----- ->|          |          |
            |                     |--PBU -- >|          |
            |                     |          |          |
            |                     |<-- PBA --|          |
            |                     |          |          |
            |                     |=Unicast= |          |
            |                     |  Tunnel  |          |
            |<-----Rtr Adv ------ |          |          |
            |                     |          |          |
            |< ------ Unicast Traffic------ >|          |
            |                     |          |          |
            |                     |==Multicast Tunnel ==|
            |                     |          |          |
            |<--MLD Query --------|          |          |
            |                     |          |          |
        MN requires               |          |          |
        multicast services        |          |          |
            |                     |          |          |
            |---MLD Report (G) -->|          |          |
            |                     |          |          |
            |                     |---- Aggregated ---> |
            |                     |    MLD Report (G)   |
            |                     |          |          |
            |                     |          |          |
            |< --------- Multicast Traffic ----------- >|
            |                     |          |          |


      Figure 5. MN Attachment and Multicast Service Establishment

   In Figure 5, MAG1 first establishes the PMIPv6 tunnel with LMA for
   unicast traffic as defined in [RFC5213] after being triggered by the
   Router Solicitation message from MN1. Unicast traffic will then flow
   between MN1 and LMA.

   For multicast traffic, a multicast tunnel may have been pre-
   configured between MAG1 and MTMA. Or the multicast tunnel may be
   dynamically established when the first MN appears at the MAG.




Zuniga, et al.            Expires May 2, 2012                  [Page 14]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   MN1 sends the MLD report message (when required by its upper layer
   applications) as defined in [RFC3810] in response to an MLD Query
   from MAG1.  MAG1 acting as a MLD Proxy as defined in [RFC4605] will
   then send an Aggregated MLD Report to the multicast anchor, MTMA
   (assuming that this is a new multicast group which MAG1 had not
   previously subscribed to).  Multicast traffic will then flow from
   MTMA towards MN1.


3.4  Multicast Mobility

   Figure 6 illustrates the mobility scenario for multicast traffic.
   Specifically, MN2 with ongoing multicast subscription moves from MAG1
   to MAG2.  Note that, for simplicity, in this scenario we only
   consider the tunnel of MAG2 with MTMA (for multicast traffic) and we
   assume that MN2 does not receive unicast traffic.  Of course, if it
   was desired to support unicast traffic, this is served by a tunnel
   between  MAG2 and LMA to transfer unicast traffic.

   According to baseline solution signaling method described in
   [RFC6224], after MN2 mobility, MAG2 acting in its role of MLD proxy
   will send an MLD Query to the newly observed MN on its downlink.
   Assuming that the subsequent MLD Report from MN2 requests membership
   of a new multicast group (from MAG2's point of view), this will then
   result in an Aggregated MLD Report being sent to MTMA from MAG2. This
   message will be sent through a pre-established (or dynamically
   established) multicast tunnel between MAG2 and MTMA.

   When MN2 detaches, MAG1 may keep the multicast tunnel with the
   multicast MTMA if there are still other MNs using the multicast
   tunnel. Even if there are no MNs currently on the multicast tunnel,
   MAG1 may decide to keep the multicast tunnel for potential future
   use.

   As discussed above, existing MLD (and Proxy MLD) signaling will
   handle a large part of the multicast mobility management for the MN.















Zuniga, et al.            Expires May 2, 2012                  [Page 15]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


           MN2          MAG1       MAG2         LMA      MTMA
            |        (MLD Proxy) (MLD Proxy) (Unicast)(Multicast)
            |            |           |            |          |
          MN Attached    |           |            |          |
           To MAG1       |           |            |          |
            |            |           |            |          |
            |            |========= Multicast Tunnel ======= |
            |            |           |            |          |
          MN Detaches    |           |            |          |
           From MAG1     |           |            |          |
            |            |           |            |          |
            |            |           |            |          |
          MN Attaches    |           |            |          |
           To MAG2       |           |            |          |
            |            |           |            |          |
            |            |           |==Multicast Tunnel === |
            |            |           |            |          |
            |---------Rtr Sol------ >|            |          |
            |            |           |--- PBU --->|          |
            |            |           |            |          |
            |            |           |<-- PBA ----|          |
            |<-----Rtr Adv --------- |            |          |
            |            |           |            |          |
            |            |           |            |          |
            |<---------MLD Query---- |            |          |
            |            |           |            |          |
            |---MLD Report (G) ----> |            |          |
            |            |           |            |          |
            |            |           |---- Aggregated -----> |
            |            |           |    MLD Report (G)     |
            |            |           |            |          |
            |< --------- Multicast Traffic ---------------- >|
            |            |           |            |          |
            |            |           |            |          |


                 Figure 6. Multicast Mobility Signaling


3.5  PMIPv6 enhancements

   This section describes the enhancements to the Proxy Mobile IPv6
   [RFC5213] protocol required to support the MTMA architecture.


3.5.1  New Binding Update List in MAG

   The Binding Update List in the MAG must be updated to be able to



Zuniga, et al.            Expires May 2, 2012                  [Page 16]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   handle the fact that more than one entity (i.e. LMA and MTMA) may be
   serving the mobile node.


3.5.2  Policy Profile Information with Multicast Parameters

   A given mobile node's policy profile information must be updated to
   be able to store the IPv6 addresses of both the LMA and MTMA.


3.5.3  MAG to MTMA attach requirements

   The MAG procedures must be updated to be able to handle simultaneous
   attach for a given mobile node to both the LMA and MTMA. For example,
   packets coming from a given mobile node must be screened to determine
   if it should be sent to the LMA or to the MTMA.


3.5.4. Data structure stored by MTMA

   The MTMA does not directly interact with the MNs attached to any of
   the MAGs. The MTMA only manages the multicast groups subscribed per
   MAG on behalf of the MNs attached to it. Having this in mind, the
   relevant information to be stored in the MTMA should be the tunnel
   interface identifier (tunnel-if-id) of the bi-directional tunnel for
   multicast between the MTMA and every MAG (as stated in [RFC5213] for
   the unicast case), the IP addresses of the multicast group delivered
   per tunnel to each of the MAGs, and the IP addresses of the sources
   injecting the multicast traffic per tunnel to the multicast domain
   defined by the MTMA.


3.6  Advantages

   An advantage of the proposed MTMA architecture is that it allows a
   PMIPv6 domain to closely follow a simple multicast tree topology for
   Proxy MLD forwarding (cf., sections 1.1 and 1.2 of [RFC4605]).  In
   contrast, the combined unicast/multicast LMA as proposed in [RFC6224]
   will be a more complex set of trees.

   Another advantage of the proposed dedicated multicast solution is
   that it allows a gradual network upgrade of a PMIPv6 domain to
   support multicast functionality.  This is because the operator does
   not have to upgrade all the LMAs in the network to support multicast
   functionality.  Only certain nodes (MTMAs), dedicated to multicast
   support, will have to be upgraded to support the new multicast
   functionality. Also, multiple deployment scenarios are supported as
   required by the operator for expected traffic distributions.



Zuniga, et al.            Expires May 2, 2012                  [Page 17]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   A final advantage is that a specific multicast elements minimize the
   replication of multicast packets (the Tunnel Convergence problem), in
   certain scenarios, compared to [RFC6224]. Figures 7 and 8 illustrate
   this point visually.  For this simple scenario, it can be observed
   that the multicast MTMA topology (Figure 7) generates 6 packets for
   one input multicast packet. In comparison, the combined
   unicast/multicast LMA topology (Figure 8) generates 8 packets for one
   input multicast packet.

   In general, it can be seen that the extra multiplication of packets
   in the combined unicast/multicast LMA topology will be proportional
   to the number of LMAs, and the number of MNs (in a given MAG)
   associated to different LMAs, for a given multicast group.  The
   packet multiplication problem aggravates as more MNs associated to
   different LMAs receive the same multicast traffic when attached to
   the same MAG.  Hence, the MTMA architecture significantly decreases
   the network capacity requirements in this scenario.

   (Note that in Figure 7, it is assumed that MN1 and MN2 are associated
   with MAG1-LMA1, and MN3 is associated with MAG2-MTMA2 for multicast
   traffic.  In Figure 8, it is assumed that MN1 is associated with
   MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated
   with MAG2-LMA2 for multicast traffic.  In both Figures 7 and 8, it is
   assumed that the packets are transmitted point to point on the last
   hop wireless link.)

   Additional results can be found in [ERCIM], where both solutions are
   compared by simulation under realistic traffic conditions. It can be
   shown that, for multicast traffic, the number of channels that a node
   (LMA in the base solution, MTMA in the proposed multicast
   architecture) has to serve does not decrease linearly with the
   reduction of the number of MNs associated to that node. The key
   factor is the set of channels subscribed by the MNs. In fact, as the
   number of MNs increases in the PMIPv6 domain, we have less advantage
   for having several nodes serving multicast, as each of them will
   probably manage all the multicast channels (or at least the popular
   ones) anyway.














Zuniga, et al.            Expires May 2, 2012                  [Page 18]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


                                   +--------------+
                                   |Content Source|
                                   +--------------+
                                          |
                                          |
                                        +---+     Packet destined
                                        | 1 |   for Multicast group "G"
                                        +---+
                                          |
         ***  ***  ***  ***      ***  ***  ***  ***
        *   **   **   **   *    *   **   **   **    *
       *                    *  *                     *
       *  Unicast Traffic   *  *  Multicast Traffic  *
       *                    *  *                     *
        *   **   **   **   *    *   **   **   **   *
         ***  ***  ***  ***      ***  ***  ***  ***
                 |                       |
                 |                     +---+
                 |                     | 2 |
                 |                     +---+
                 |                       |
              +-----+                 +------+
     Unicast  | LMA1|                 | MTMA2|     Multicast
      Anchor  +-----+                 +------+      Anchor
                 \\                     //||
                  \\                   // ||
                   \\                 //  ||
                    \\               //   ||
                     \\          +---+  +---+
                      \\         | 3 |  | 4 |
                       \\        +---+  +---+
                        \\       //       ||
                         \\     //        ||
                          \\   //         ||
                           \\ //          ||
                          +-----+       +-----+
                          | MAG1|       | MAG2|      MLD Proxy
                          +-----+       +-----+
                          |     |          |
                        +---+ +---+      +---+
                        | 5 | | 6 |      | 7 |
                        +---+ +---+      +---+
                          |     |          |         All MNs in same
                          |     |          |       multicast group "G"
                        {MN1} {MN2}      {MN3}


             Figure 7. Packet Flow in the MTMA architecture



Zuniga, et al.            Expires May 2, 2012                  [Page 19]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


                       +--------------+
                       |Content Source|
                       +--------------+
                              |
                              |
                            +---+      Packet destined
                            | 1 |    for Multicast group "G"
                            +---+
                              |
         ***  ***  ***  ***  ***  ***  ***  *** ***
        *   **   **   **   **  **   **   **   **   *
       *                                            *
       *                 Fixed Internet             *
       *        (Unicast & Multicast Traffic)       *
        *   **   **   **   **  **   **   **   **   *
         ***  ***  ***  ***      *** ***  ***  ***
                 |                       |
               +---+                   +---+
               | 2 |                   | 3 |
               +---+                   +---+
                 |                       |
              +-----+                 +------+
              | LMA1|                 | LMA2 |     Combined
              +-----+                 +------+     Unicast/Multicast
                 \\                   //  ||       Anchor
                  \\                 //   ||
                   \\               //    ||
                    \\             //     ||
                    +---+        +---+  +---+
                    | 4 |        | 5 |  | 6 |
                    +---+        +---+  +---+
                        \\       //       ||
                         \\     //        ||
                          \\   //         ||
                           \\ //          ||
                          +-----+       +-----+
                          | MAG1|       | MAG2|      MLD Proxy
                          +-----+       +-----+
                          |     |          |
                        +---+ +---+      +---+
                        | 7 | | 8 |      | 9 |
                        +---+ +---+      +---+
                          |     |          |         All MNs in same
                          |     |          |       multicast group "G"
                        {MN1} {MN2}      {MN3}


       Figure 8. Packet Flow in a Combined Unicast/Multicast LMA



Zuniga, et al.            Expires May 2, 2012                  [Page 20]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


4  Direct routing

   Direct routing uses native multicast infrastructure, allowing a MAG
   to connect a multicast router directly. A MAG can act as a MLD proxy
   or multicast router for redirecting multicast packets. The key idea
   of direct routing is to provide optimal routing for local content. As
   a consequence, it does not give the LMA processing burden for channel
   management and data delivery of locally available content. Direct
   routing is simple and easy to deploy.

   When thinking on the MAG reception of the multicast flow being
   forwarded to the attached MNs, two models for the MAG subscription to
   the multicast flow (on behalf of the MNs) can be considered:

      - Local subscription, which refers to the situation where the
      multicast channel is forwarded to the MAG by a multicast router
      within the PMIPv6 domain

      - Remote subscription, which refers to the situation where the
      multicast channel is forwarded to the MAG through the tunnel
      interface from the home network

   In the architecture described in [RFC6224], if MLD proxy is installed
   on a MAG, all MAGs that participate in the multicast traffic
   distribution in a PMIPv6 domain are considered to act as MLD proxies.
   An important consequence derived from such characterization is that
   every MLD proxy instance defined in the MAG has a unique upstream
   interface, and thus, an MLD proxy instance cannot dynamically choose
   among local or remote multicast subscription. For instance, one
   possible scenario pushing for local source deployment, and
   consequently local subscription, could be the one where there is an
   extremely high number of multicast channels, all of them with active
   subscriptions in all the MAGs along the PMIPv6 domain, resulting in
   the MTMA replicating the totally of the multicast flows to all the
   MAGs (leading to the known as "avalanche problem").

   Once a decision is taken (at configuration time) about what kind of
   subscription, either local or remote, is applicable for a certain
   instance regarding all the multicast channels for all the attached
   MNs, this cannot be changed without resetting and reconfiguring the
   whole MLD instance.

   In order to have such kind of flexibility, the MAG needs to act as a
   multicast router, that is, it must implement some multicast routing
   protocol able to choose between local or remote subscription, for one
   or all the subscribed multicast channels, by using some routing
   criteria leveraged by the network routing information or by the
   network management systems. The most commonly deployed multicast



Zuniga, et al.            Expires May 2, 2012                  [Page 21]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


   routing protocol nowadays is PIM [RFC4601].

   So it is possible to distinguish among two situations depending on
   the MAG functionality. The following sub-sections describe the
   applying constraints.


4.1 MAG as MLD proxy

   In case of the MAG only incorporates MLD proxy functionality, for
   every one of the MLD proxy instances invoked in the MAG it is
   necessary to define at configuration time the upstream interface from
   where the multicast traffic will be received. This decision actually
   requires to define whether the multicast subscription by an MLD proxy
   instance for all the multicast channels will be local (if the
   upstream interface points to a multicast router internal to the
   PMIPv6 domain) or remote (in case of the upstream interface is the
   bi-directional tunnel towards the LMA, for the architecture in
   [RFC6224], or the MTMA, for the multicast listener optimization
   described in this document).

4.1.1 Local subscription when the MAG implements MLD proxy functionality

   If the MAG has MLD proxy functionality only, once this MLD proxy
   instance is configured to obtain the multicast traffic locally, the
   system behavior when operating with local subscription remains
   static.

4.1.1.1 Local subscription architecture

   Figure 9 shows the proposed local routing architecture using native
   multicasting infrastructure [I-D.deng-multimob-pmip6-requirement]. To
   forward IGMP/MLD signaling and multicast packets, a MLD proxy
   function defined in [RFC4605], SHOULD be placed on a MAG. This
   solution is much simpler than the base solution and easy to deploy
   because multicasting functions are totally separated from mobility
   anchor by using a native multicasting infrastructure.














Zuniga, et al.            Expires May 2, 2012                  [Page 22]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


                               Multicast Tree
                                      :
                                      :         || - PMIPv6 Tunnel
           +----------+         +----------+    |  - Multicast Data Path
           |   LMA    |         |    MR    |
           +----------+         +----------+
                ||\\                /|
                ||  \\            /  |
                ||    \\        /    |
                ||      \\    /      |
                ||        \\/        |
                ||        / \\       |
                ||      /     \\     |
                ||    /         \\   |
           +----------+        +----------+
           |  P-MAG   |        |  N-MAG   |
           |(M-Proxy) |        |(M-Proxy) |
           +----------+        +----------+
                :                   :
            +------+             +------+
            |  MN  |   ----->    |  MN  |
            +------+             +------+

      Figure 9. Direct routing solution for PMIPv6 Multicasting


4.1.1.2 Handover procedure for local routing

   Figure 10 shows the handover operation in local routing architecture.
   When an MN hands off to the next MAG (N-MAG) from the previous MAG
   (P-MAG), the N-MAG detects the newly arrived MN and transmits an MLD
   query message to the MN. After receiving the MLD query message, the
   MN sends an MLD report message that includes the multicast group
   information. The N-MAG then sends an aggregated MLD report message to
   the MR. When the N-MAG receives the multicast packets from the MR, it
   then simply forwards them without tunnel encapsulation. The N-MAG
   updates the MN's location information to the LMA by exchanging
   PBU/PBA signaling messages.













Zuniga, et al.            Expires May 2, 2012                  [Page 23]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


          MN         P-MAG       N-MAG        LMA      MR      Tree
           |           |           |           |        |        |
           |           |           |           |        |        |
           |<----------|<-- Multicast Data--------------|<-------|
           |           |       .   |           |        |        |
           |           |       .   |           |        |        |
           |           |       .   |           |        |        |
     Link->|       Handover        |           |        |        |
   Disconnected    Detection       |           |        |        |
           |           |           |           |        |        |
           |           |           |           |        |        |
           |           |    MN Attachment      |        |        |
           |           |           |           |        |        |
           |           |           |           |        |        |
           |------ Rtr. Sol. ----->|           |        |        |
           |           |           |           |        |        |
           |<----- MLD Query ------|           |        |        |
           |           |           |           |        |        |
           |------ MLD Report ---->|           |        |        |
           |           |           |    Aggregated      |        |
           |           |           |--- MLD Report ---->|        |
           |           |           |           |        |        |
           |           |           |           |        |        |
           |<----------------------|<-- Multicast Data--|<-------|
           |           |           |           |        |        |
           |           |           |           |        |        |
           |           |           |   Proxy   |        |        |
           |           |           |--Binding->|        |        |
           |           |           |   Update  |        |        |
           |           |           |           |        |        |
           |           |           |   Proxy   |        |        |
           |           |           |<-Binding--|        |        |
           |           |           |   Ack.    |        |        |
           |           |           |           |        |        |


        Figure 10. Handover procedure in direct routing architecture


4.1.2 Remote subscription when the MAG implements MLD proxy
   functionality

   If the MAG has only MLD proxy functionality, the system behavior when
   operating with remote subscription is as described in chapter 3. Once
   the MLD proxy instance is configured to obtain the multicast traffic
   remotely, this remains static.





Zuniga, et al.            Expires May 2, 2012                  [Page 24]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


4.2 MAG as multicast router

   If the MAG behaves as a multicast router, the MAG then implements a
   multicast routing protocol. This allows the MAG to make decisions
   about from where to receive the traffic of any multicast channel,
   based in routing information and/or network management criteria. The
   selected incoming interface for receiving multicast traffic will be
   then the one matching such criteria, and it could drive to either a
   local or remote subscription. Some situations are introduced in the
   next section.


4.2.1 Local subscription when the MAG implements a multicast routing
   protocol

   If the MAG is a multicast router, the system behavior when operating
   with local subscription is as before, but extending the role of the
   MAG to be a multicast router, and running a multicast routing
   protocol among the MAG and local multicast router serving the
   multicast traffic. Once the MAG decides to obtain the multicast
   traffic locally based in routing information and/or network
   management criteria, this can be dynamically changed if such criteria
   change.


4.2.2 Remote subscription when the MAG implements a multicast routing
   protocol

   If the MAG is a multicast router, the system behavior when operating
   with remote subscription is as described in chapter 3, considering
   that a multicast routing protocol is running among the MAG and the
   MTMA on the tunnel interface. Once the MAG decides to obtain the
   multicast traffic remotely based in routing information and/or
   network management criteria, this can be dynamically changed if such
   criteria change.


5 Dynamic selection of local versus remote multicast subscription

   As mentioned above, the MAG as multicast router provides some
   flexibility for choosing local versus remote multicast subscription.
   Considering PIM as the multicast routing protocol running on the MAG,
   it is possible to find out two situations where such dynamic
   selection can occur, according to the PIM flavor on place. For all
   the scenarios below we consider a certain multicast flow being
   injected by two different sources, one local to the PMIPv6 domain and
   one remote through the home network, by using an MTMA.




Zuniga, et al.            Expires May 2, 2012                  [Page 25]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


5.1 Any source multicast scenario

   This situation applies for both PIM-SM and BIDIR PIM variants. In
   this case, once the MAG receives the MLD report from the MN
   requesting the multicast channel in the form (*,G), the MAG could
   decide what multicast flow subscribes to (the local or the remote
   one).

   The subscription can be statically pre-configured or dynamically
   configured based on some rule. For instance, static configuration can
   be made per MN (user), such as "multicast traffic from user X should
   always go through the home (i.e., via the tunnel with the MTMA/LMA-
   as-per-RFC6224), while traffic from user Y should go via local
   subscription". Also, configuration profiles can also be more complex
   and include considerations on types of traffic or IP flows, such as
   "traffic of type A from user X should always go through the home,
   traffic of type B from user X should be subscribed locally" using
   routing information and/or network management criteria.  Similarly,
   routing information can be received dynamically, for example, at
   user's registration time PBU/PBA signaling can be used to carry the
   profile information similar to what is described in [I-D.gundavelli-
   netext-pmipv6-sipto-option]. Also, routing information can be
   exchanged dynamically when the multicast group subscription is made.

   When focusing on PIM-SM, another scenario is possible. PIM-SM allows
   for switching from a multicast shared-tree to a source-specific tree
   to optimize the path for traffic delivery. The location of the
   rendezvous point and the multicast source can be either in the PMIPv6
   domain or the home network, so the optimization could be from local
   subscription to remote subscription or vice versa. The possibility of
   switching to a source-based tree, and the time for doing is
   implementation-dependent, and it could be triggered immediately
   (after reception of the first multicast packet) or last to some time,
   or even not switching never.


5.2 Source specific multicast scenario

   This situation applies for PIM-SSM. Then, in a source-specific
   multicast scenario [RFC4607], the MAG would send the PIM request to
   the corresponding interface based on the multicast source address
   indicated on the (S,G) subscription requested by the MN in the MLD
   Report, using the routing information.








Zuniga, et al.            Expires May 2, 2012                  [Page 26]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


6  Security Considerations

   This draft discusses the operations of existing protocols without
   modifications. It does not introduce new security threats beyond the
   current security considerations of PMIPv6 [RFC5213], MLD [RFC3810],
   IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605].


7  IANA Considerations

   This document makes no request of IANA.


8  Contributors

   The following people have considerably contributed to this draft:

   Akbar Rahman
   InterDigital Communications, LLC
   Email: Akbar.Rahman@InterDigital.com

   Ignacio Soto
   Universidad Politecnica de Madrid
   Email: isoto@dit.upm.es


9  References

9.1  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5213]   Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
               K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August
               2008.

   [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.

   [RFC3376]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
               Thyagarajan, "Internet Group Management Protocol, Version
               3", RFC 3376, October 2002.

   [RFC4605]   Fenner, B., He, H., Haberman, B., and H. Sandick,



Zuniga, et al.            Expires May 2, 2012                  [Page 27]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


               "Internet Group Management Protocol (IGMP)/ Multicast
               Listener Discovery (MLD)-Based Multicast Forwarding
               ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC5847]   Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan,
               S., Laganier, J., "Heartbeat Mechanism for Proxy Mobile
               IPv6", RFC 5847, June 2010.

   [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4607]   Holbrook, H., and B. Cain, "Source-Specific Multicast for
               IP", RFC 4607, August 2006.


9.2  Informative References

   [RFC6224]   Schmidt, T.C., Waehlisch, M., and S.Krishnan, "Base
               Deployment for Multicast Listener Support in PMIPv6
               Domains", RFC 6224, April 2011.

   [ERCIM]     L.M. Contreras, C.J. Bernardos, I. Soto, "On the
               efficiency of a dedicated LMA for multicast traffic
               distribution in PMIPv6 domains", 5th ERCIM Workshop in
               eMobility, Vilanova i la Geltru, Spain, June 2011.

   [I-D.deng-multimob-pmip6-requirement] H. Deng, T. Schmidt, P. Seite,
               and P. Yang, "Multicast Support Requirements for Proxy
               Mobile IPv6", draft-deng-multimob-pmip6-requirement-
               02.txt (work in progress), July 2009.

   [I-D.gundavelli-netext-pmipv6-sipto-option] S. Gundavelli, X. Zhou,
               J. Korhonen, G. Feige, R. Koodli, "IP Traffic Offload
               Selector Option for Proxy Mobile IPv6", draft-gundavelli-
               netext-pmipv6-sipto-option-01.txt (work in progress),
               July 2011.














Zuniga, et al.            Expires May 2, 2012                  [Page 28]

INTERNET DRAFT  Multicast Mobility Routing Optimizations   October, 2011


Author's Addresses


   Juan Carlos Zuniga
   InterDigital Communications, LLC
   EMail: JuanCarlos.Zuniga@InterDigital.com

   Luis M. Contreras
   Telefonica I+D
   EMail: lmcm@tid.es

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   EMail: cjbc@it.uc3m.es

   Seil Jeon
   Soongsil University
   Email: sijeon@dcn.ssu.ac.kr

   Younghan Kim
   Soongsil University
   Email: yhkim@dcn.ssu.ac.kr





























Zuniga, et al.            Expires May 2, 2012                  [Page 29]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/