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

Versions: 00 01 02 03 04 05 06

MULTIMOB Group                                                JC.Zuniga
Internet Draft                                                     G.Lu
Intended status: Standards Track                               A.Rahman
Expires: July 14, 2010                 InterDigital Communications, LLC
                                                       January 14, 2010


            Support Multicast Services Using Proxy Mobile IPv6
                   draft-zuniga-multimob-smspmip-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 July 14,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.







Zuniga, et al.          Expires July 14, 2010                  [Page 1]


Internet-Draft     Multicast Services using PMIPv6         January 2010


Abstract

   This document describes how multicast mobility services can be
   supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener
   Discovery (MLD) [RFC3810], and Internet Group Management Protocol
   (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for
   multicast listener mobility. It proposes the use of a dedicated Local
   Mobility Anchor as the topological anchor point for multicast
   traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy.
   There are no impacts to the Mobile Node to support multicast listener
   mobility.

Table of Contents


   1. Introduction...................................................2
   2. Conventions and Terminology....................................3
   3. Solution.......................................................3
      3.1. Architecture..............................................3
      3.2. Multicast Establishment...................................5
      3.3. Multicast Mobility........................................6
      3.4. Advantages................................................7
   4. Security Considerations.......................................11
   5. IANA Considerations...........................................11
   6. References....................................................11
      6.1. Normative References.....................................11
      6.2. Informative References...................................12
   7. Acknowledgments...............................................12

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


Zuniga, et al.          Expires July 14, 2010                  [Page 2]


Internet-Draft     Multicast Services using PMIPv6         January 2010


   mobility of multicast listeners (i.e. IGMP and MLD protocols were
   originally designed for fixed networks).

   Supporting mobility of multicast traffic has been under discussions
   within the MULTIMOB working group. This document focuses on
   addressing multicast listener mobility using the PMIPv6 and IGMP/MLD
   protocols. It proposes the use of a dedicated LMA as the topological
   mobility anchor point for multicast traffic, while the MAG serves as
   an IGMP/MLD proxy.

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

   This document uses the terminology defined in [RFC5213], [RFC3775],
   and [RFC3810].

3. Solution

   A PMIPv6 domain may receive data from both unicast and multicast
   sources.  A dedicated LMA can be used to serve as the mobility anchor
   for multicast traffic. Unicast traffic will go normally to the other
   LMAs in the PMIPv6 domain. This section describes how the multicast
   LMA works in scenarios of mobile node attachment and multicast
   mobility.

3.1. Architecture

   Figure 1 shows an example of a PMIPv6 domain supporting multicast
   mobility. LMA1 is dedicated to unicast traffic, and LMA2 is dedicated
   to multicast traffic. Note that there can multiple LMAs dedicated to
   unicast traffic (not shown in Figure 1) in a given PMIPv6 domain.
   However, we assume a single LMA dedicated to multicast traffic in a
   PMIPv6 domain (as shown in Figure 1).

   Also in this architecture, all MAGs that are connected to the
   multicast LMA must support the MLD proxy [RFC4605] function.
   Specifically in Figure 1, each of the MAG1-LMA2 and MAG2-LMA2 tunnel
   interface defines an MLD proxy domain.  The MNs are considered to be
   on the downstream interface of the MLD proxy (in the MAG), and LMA2
   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.


Zuniga, et al.          Expires July 14, 2010                  [Page 3]


Internet-Draft     Multicast Services using PMIPv6         January 2010


   As shown in Figure 1, MAG1 may connect to both unicast and multicast
   LMAs. 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.



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

        Figure 1 Architecture of Dedicated LMA as Multicast Anchor






Zuniga, et al.          Expires July 14, 2010                  [Page 4]


Internet-Draft     Multicast Services using PMIPv6         January 2010


3.2. Multicast Establishment

   Figure 2 shows the procedure when MN1 attaches to MAG1, and
   establishes associations with LMA1 (unicast) and LMA2 (multicast).


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

        Figure 2 MN Attachment and Multicast Service Establishment

   In Figure 2, MAG1 first establishes the PMIPv6 tunnel with LMA1 for
   unicast traffic as defined in [RFC5213] after being triggered by the
   Router Solicitation message from MN1. Also, MN1 sends the MLD report
   message (when required by its upper layer applications) as defined in
   [RFC3810].  MAG1 acting as a MLD Proxy as defined in [RFC4605] will
   then send an Aggregated MLD Report to the multicast anchor, LMA2.
   This will then trigger establishment of a multicast tunnel between
   MAG1 and LMA2.





Zuniga, et al.          Expires July 14, 2010                  [Page 5]


Internet-Draft     Multicast Services using PMIPv6         January 2010




3.3. Multicast Mobility

   Figure 3 illustrates the mobility scenario for multicast traffic.
   Specifically, MN2 with ongoing multicast subscription moves from MAG1
   to MAG2.  Note that in this scenario MAG2 is connected only to LMA2
   (multicast) and does not receive unicast traffic.  Of course, if it
   was desired to support unicast traffic, the architecture will easily
   allow MAG2 to also connect to LMA1 to support unicast traffic.

   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 LMA2 from MAG2.

   When MN2 detaches, MAG1 may keep the multicast tunnel with the
   multicast LMA2 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.



























Zuniga, et al.          Expires July 14, 2010                  [Page 6]


Internet-Draft     Multicast Services using PMIPv6         January 2010


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

                   Figure 3 Multicast Mobility Signaling

3.4. Advantages

   One of the main advantages of the proposed architecture of a
   dedicated multicast LMA, and MAGs acting as a Proxy MLD, 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]).

   Another major advantage is that a dedicated multicast LMA minimizes
   replication of multicast packets compared to a combined
   unicast/multicast LMA as proposed in [I-D.schmidt-multimob-pmipv6-


Zuniga, et al.          Expires July 14, 2010                  [Page 7]


Internet-Draft     Multicast Services using PMIPv6         January 2010


   mcast-deployment]. Figures 4 and 5 illustrate this point visually.
   For this simple scenario, it can be observed that the dedicated
   multicast LMA topology (Figure 4) generates 6 packets for one input
   multicast packet. In comparison, the combined unicast/multicast LMA
   topology (Figure 5) 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.  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
   dedicated multicast architecture significantly decreases the network
   capacity requirements.

   (Note that in Figure 4, it is assumed that MN1 and MN2 are associated
   with MAG1-LMA1, and MN3 is associated with MAG2-LMA2 for multicast
   traffic.  In Figure 5, 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 4 and 5, it is
   assumed that the packets are transmitted point to point on the last
   hop wireless link.)


























Zuniga, et al.          Expires July 14, 2010                  [Page 8]


Internet-Draft     Multicast Services using PMIPv6         January 2010


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

             Figure 4 Packet Flow in a Dedicated Multicast LMA


Zuniga, et al.          Expires July 14, 2010                  [Page 9]


Internet-Draft     Multicast Services using PMIPv6         January 2010


                       +--------------+
                       |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 5 Packet Flow in a Combined Unicast/Multicast LMA


Zuniga, et al.          Expires July 14, 2010                 [Page 10]


Internet-Draft     Multicast Services using PMIPv6         January 2010




4. 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].

5. IANA Considerations

   This document makes no request of IANA.

6. References

6.1. Normative References

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

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
             Syntax Specifications: ABNF", RFC 2234, Internet Mail
             Consortium and Demon Internet Ltd., November 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, "Internet
             Group Management Protocol (IGMP)/ Multicast Listener
             Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
             Proxying")", RFC 4605, August 2006.








Zuniga, et al.          Expires July 14, 2010                 [Page 11]


Internet-Draft     Multicast Services using PMIPv6         January 2010


6.2. Informative References

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

   [I-D.schmidt-multimob-pmipv6-mcast-deployment-03] Schmidt, TC.,
             Waehlisch, M., Sarikaya, B., and S.Krishnan, "A Minimal
             Deployment Option for Multicast Listeners in PMIPv6
             Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-03
             (Work in progress), December 16, 2009.

7. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

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


   Guang Lu
   InterDigital Communications, LLC
   Email: Guang.Lu@InterDigital.com


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
















Zuniga, et al.          Expires July 14, 2010                 [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/