Skip to main content

Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
draft-ietf-multimob-pmipv6-ropt-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7028.
Authors Juan-Carlos Zúñiga , Luis M. Contreras , Carlos J. Bernardos , Seil Jeon , Younghan Kim
Last updated 2013-05-03
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7028 (Experimental)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-multimob-pmipv6-ropt-04
MULTIMOB Working Group                                        JC. Zuniga
Internet-Draft                                              InterDigital
Intended status: Experimental                              LM. Contreras
Expires: November 4, 2013                                 Telefonica I+D
                                                           CJ. Bernardos
                                                                    UC3M
                                                                 S. Jeon
                                           Instituto de Telecomunicacoes
                                                                  Y. Kim
                                                     Soongsil University
                                                             May 3, 2013

     Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
                   draft-ietf-multimob-pmipv6-ropt-04

Abstract

   The MULTIMOB group has specified a base solution to support IP
   multicasting in a PMIPv6 domain [RFC6224].  In this document, some
   enhancements to the base solution are described.  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 deployment scenarios.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 4, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the

Zuniga, et al.          Expires November 4, 2013                [Page 1]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Multicast Tree Mobility Anchor (subscription via MTMA) . .  5
     3.2.  Direct Routing (subscription via direct routing) . . . . .  6
   4.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . .  8
     4.1.  Extensions to Binding Update List Data Structure . . . . .  8
     4.2.  MAG as MLD proxy . . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  MTMA mode (subscription via MTMA)  . . . . . . . . . .  8
       4.2.2.  Direct Routing mode (subscription via direct
               routing) . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 13
     5.1.  Dynamic IP Multicast Selector Option . . . . . . . . . . . 13
       5.1.1.  Option application rules . . . . . . . . . . . . . . . 13
       5.1.2.  Option format  . . . . . . . . . . . . . . . . . . . . 13
   6.  Multicast Tree Mobility Anchor Operation . . . . . . . . . . . 14
     6.1.  Conceptual Data Structures . . . . . . . . . . . . . . . . 15
   7.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 15
   8.  IPv4 support . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   11. Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     12.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  MTMA Deployment Use Cases . . . . . . . . . . . . . . 18
     A.1.  PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . . . 18
     A.2.  PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . . . 18
     A.3.  PMIPv6 domain with ratio 1:N . . . . . . . . . . . . . . . 20
     A.4.  PMIPv6 domain with H-LMA . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

Zuniga, et al.          Expires November 4, 2013                [Page 2]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

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 performs 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.  However, a PMIPv6 domain may handle data from
   both unicast and multicast sources.

   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 [RFC4065]
   specification allows an intermediate (i.e., edge) node to appear as a
   multicast router to downstream hosts, and as a host to upstream
   multicast routers.  IGMP and MLD related protocols however 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 multiple
   PMIPv6 tunnels with different LMAs, e.g., up to one per MN.  In the
   presence of multicast traffic, multiple instances of the same traffic
   can converge to the same MAG.  Hence, when IP multicasting is applied
   into PMIPv6, it leads to redundant traffic at a MAG.  This is the so-
   called tunnel convergence problem.

   In order to address this issue, a comprehensive solution is proposed
   in this document, consisting of two complementary enhancements:
   multicast anchor and direct routing.  The former enhancements makes
   use of a multicast tree mobility anchor (MTMA) as the topological
   anchor point for remotely delivering multicast traffic, while the
   latter enhancement uses direct routing taking advantage of local
   multicast source availability, allowing a MAG to connect directly to
   a multicast router for simple access to local content.  Neither of
   the two schemes has any impact on the MN to support multicast
   listener mobility.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Zuniga, et al.          Expires November 4, 2013                [Page 3]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

   This document uses the terminology defined in [RFC5213], [RFC6275],
   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.  This service supports
      mobility as the MN moves from one MAG to another one, both
      associated to the same LMA regarding the MN 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.

   From the definitions above, it can be stated 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.

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

   Direct routing:  This scheme uses the native multicast infrastructure
      for retrieving multicast data.  For an operator having its own
      local content, this technique also includes the case where the
      content source is directly connected to the MAG.

   Subscription via MTMA:  Multicast subscription mode in which the
      content is retrieved from the remote (or home) MTMA.

Zuniga, et al.          Expires November 4, 2013                [Page 4]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   Subscription via direct routing:  Multicast subscription mode in
      which the content is retrieved using direct routing from the local
      domain.

3.  Overview

   This document specifies a solution to the tunnel convergence problem
   composed of two operational modes that can be used as complementary
   enhancements: multicast tree mobility anchor (MTMA) and direct
   routing.  Next, each one of these two operational modes is
   introduced.

3.1.  Multicast Tree Mobility Anchor (subscription via MTMA)

   An MTMA is used used to serve as the mobility anchor for multicast
   traffic.  Typically, the MTMA will be used to get access to remote
   multicast content.

   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 as described in
   [RFC5213].  A MAG connecting to the MTMA acts as a MLD proxy.

   This section describes how the MTMA works in scenarios of MN
   attachment and multicast mobility.  It concentrates on the case of
   both LMA and MTMA defining a unique PMIPv6 domain.  Some other
   different deployment scenarios are presented in Appendix A.

   Figure 1 shows an example of a PMIPv6 domain supporting multicast
   mobility.  The LMA is dedicated to unicast traffic, and the MTMA is
   dedicated to multicast traffic.  The MTMA can be considered to be a
   form of upstream multicast router with tunnel interfaces allowing
   subscription via MTMA for the MNs.  Note that there can be multiple
   LMAs for unicast traffic in a given PMIPv6 domain (not shown in
   Figure 1 for simplicity).  Similarly, more than one MTMA could be
   deployed by the operator, for example to serve different multicast
   groups (not shown in Figure 1).  This would require support for MLD
   proxy with multiple interfaces [I-D.ietf-multimob-pmipv6-source],
   [I-D.contreras-multimob-multiple-upstreams],
   [I-D.asaeda-pim-mldproxy-multif].

   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.

Zuniga, et al.          Expires November 4, 2013                [Page 5]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

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

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

3.2.  Direct Routing (subscription via direct routing)

   Direct routing uses a native multicast infrastructure, allowing a MAG
   to directly connect to a multicast router (as next hop) in the PMIPv6
   domain.  A MAG acts as a MLD proxy.

   The main purpose of direct routing is to provide optimal connectivity
   for local content.  As a consequence, it alleviates the MTMA of the
   channel management and data delivery of locally available content.
   Unicast traffic will go as normally to the LMAs in the PMIPv6 domain.

   This section describes how the direct routing works in scenarios of

Zuniga, et al.          Expires November 4, 2013                [Page 6]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   MN attachment and multicast mobility.

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

    Figure 2: Architecture for direct routing based PMIPv6 multicasting

   Figure 2 shows the architecture for the local routing case using
   native multicasting infrastructure
   [I-D.deng-multimob-pmip6-requirement].

   The LMA is dedicated to unicast traffic, and the multicast traffic is
   obtained from an upstream multicast router present in the PMIPv6
   domain.  Note that there can be multiple LMAs for unicast traffic
   (not shown in Figure 1 for simplicity) in a given PMIPv6 domain.

   As shown in Figure 2, a MAG may connect to both unicast (LMA) and
   multicast (MR) routers.  Thus, a given MN may simultaneously receive
   both unicast and multicast traffic.

   As seen in Figure 2, each MAG has a direct connection (i.e., not
   using the tunnel interface) with a multicast router.  To facilitate
   IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy
   function defined in [RFC4605] SHOULD be implemented in the MAG.
   There SHOULD be direct connectivity between the MAG and the local

Zuniga, et al.          Expires November 4, 2013                [Page 7]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   multicast router (or additional MLD proxy).

4.  Mobile Access Gateway Operation

   This section describes the operation of the mobile access gateway,
   considering that the MAG incorporates MLD proxy functions as per
   [RFC4605].

4.1.  Extensions to Binding Update List Data Structure

   The binding update list (BUL) in the MAG must be updated to be able
   to handle the fact that more than one entity (i.e., LMA and MTMA) may
   be serving the mobile node for different kind of traffic.

4.2.  MAG as MLD proxy

4.2.1.  MTMA mode (subscription via MTMA)

   In case of subscription via MTMA, all MAGs that are connected to the
   MTMA must support the MLD proxy function [RFC4605].  Specifically in
   Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces
   define an MLD proxy domain.  The MNs are considered to be on the
   downstream interface of the MLD proxy (of the MAG), and the MTMA is
   considered to be on the upstream interface (of the MAG) as per
   [RFC4605].  Note that the 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.

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

Zuniga, et al.          Expires November 4, 2013                [Page 8]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

           MN1                   MAG        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 3: MN Attachment and Multicast Service Establishment for MTMA

   In Figure 3, the MAG 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 MAG and MTMA, or may be dynamically established
   when the first MN appears at the MAG.

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

Zuniga, et al.          Expires November 4, 2013                [Page 9]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   MTMA towards MN1.

   We next consider a mobility scenario in which MN1 with an ongoing
   multicast subscription moves from one MAG to another MAG.  According
   to the baseline solution signaling method described in [RFC6224],
   after MN1 mobility, the new MAG 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 MN1 requests membership for a new
   multicast group (from the new MAG's point of view), this will then
   result in an Aggregated MLD Report being sent to the MTMA from the
   new MAG.  This message will be sent through a multicast tunnel
   between the new MAG and MTMA (pre-established or dynamically
   established).

   When MN1 detaches, the old MAG 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,
   the old MAG may decide to keep the multicast tunnel temporariliy for
   potential future use.

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

4.2.2.  Direct Routing mode (subscription via direct routing)

   In this case, the MLD proxy instance is configured to obtain the
   multicast traffic locally.  Figure 4 shows an example of multicast
   service establishment.  The MAG first establishes the PMIPv6 tunnel
   with the LMA for unicast traffic as defined in [RFC5213] after being
   triggered by the Router Solicitation message from the MN.  Unicast
   traffic will then flow between the MN and LMA.

   For multicast traffic, it is assumed that the upstream interface of
   the MLD proxy instance has been configured pointing to a multicast
   router internal to the PMIPv6 domain (or towards an additional MLD
   proxy node in the domain), for all the multicast channels (which, in
   consequence, have to be local).  There should be direct connectivity
   between the MAG and the local multicast router (or additional MLD
   proxy).

Zuniga, et al.          Expires November 4, 2013               [Page 10]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

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

       Figure 4: Multicast service establishment for direct routing

   Upon detecting node attachment from an incoming interface, the MAG
   adds each downstream interface to the MLD Proxy instance with
   upstream link to an MR according to the standard MLD proxy operations
   [RFC3810] and sends an MLD Query message towards the MN.  The MN
   sends the MLD report message (when required by its upper layer
   applications) in response to an MLD Query from MAG.  Upon receiving
   the MLD Report message from each incoming interface, the MAG checks
   the MLD Proxy instance associated with the downstream interface and
   then the MLD Report messages will be aggregated and forwarded to the
   upstream link associated with the MR (assuming that this is a new
   multicast group which the MAG had not previously subscribed to).
   Multicast traffic will then flow from the local multicast router
   towards the MN.

Zuniga, et al.          Expires November 4, 2013               [Page 11]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

         MN           P-MAG       N-MAG        LMA        MR
          |             |           |           |          |
          |             |           |           |          |
          |<------------|<-- Multicast Data----------------|
          |             |       .   |           |          |
          |             |       .   |           |          |
          |             |       .   |           |          |
       Link         Handover        |           |          |
    Disconnected    Detection       |           |          |
          |             |           |           |          |
          |             |           |           |          |
          |             |    MN Attachment      |          |
          |             |           |           |          |
          |             |           |           |          |
          |----Rtr Sol------------->|           |          |
          |             |           |           |          |
          |             |           |--PBU----->|          |
          |             |           |           |          |
          |             |           |<-----PBA--|          |
          |             |           |           |          |
          |<-----------MLD Query----|           |          |
          |             |           |           |          |
          |----MLD Report---------->|           |          |
          |             |           |           |          |
          |             |           |----Aggregated------->|
          |             |           |    MLD Report        |
          |             |           |           |          |
          |<------------------------|<---Multicast Data----|
          |             |           |           |          |

         Figure 5: Multicast mobility signaling for direct routing

   Figure 5 shows the handover operation procedure for the direct
   routing operation mode.  When an MN hands off to the next MAG (N-MAG)
   from the previous MAG (P-MAG), the N-MAG detects the newly arrived
   attached MN and performs binding update procedure by exchanging PBU/
   PBA signaling messages with LMA.  At the same time, a MLD Proxy
   instance detecting the new MN 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 upstream
   link associated with the MR.  In the direct routing case, an upstream
   interface of MLD Proxy instance is decided towards certain multicast
   router based on the operator's configuration or multicast routing, as
   compared to the base solution defined in [RFC6224] where it is
   determined for each MN based on the Proxy Binding Update List.  When
   the N-MAG receives the multicast packets from the MR, it then simply
   forwards them without tunnel encapsulation.  The N-MAG updates the

Zuniga, et al.          Expires November 4, 2013               [Page 12]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   MN's location information to the LMA by exchanging PBU/PBA signaling
   messages.

5.  Local Mobility Anchor Operation

   This section includes a new mobility option to support dynamic
   policies on subscription via MTMA/direct routing based on the local
   mobility anchor conveying the required info to the mobile access
   gateway in the proxy binding acknowledge message.

5.1.  Dynamic IP Multicast Selector Option

5.1.1.  Option application rules

   A new TLV-encoded mobility option, "Dynamic IP Multicast Selector"
   option is defined for use with the PBA (Proxy Binding Acknowledge)
   message exchanged between an LMA and a MAG to convey dynamic policies
   on subscription via MTMA/direct routing.  This option is used for
   exchanging the IP addresses of both the group subscribed to by the
   MN, and the source(s) delivering it, as well as the applicable filter
   mode.  This information is carried by using directly the Multicast
   Address Record format defined in [RFC3810].  There can be multiple
   "Dynamic IP Multicast Selector" options present in the message, one
   for each active subscription maintained by the MN (i.e., one per
   Multicast Address Record).

5.1.2.  Option format

   The format of this new option is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Type     |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Multicast Address Record                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:

      To be defined by IANA.

Zuniga, et al.          Expires November 4, 2013               [Page 13]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   Length:

      8-bit unsigned integer indicating the length of the option in
      octets, excluding the type and length fields.

   Reserved:

      This field is unused for now.  The value MUST be initialized to 0
      by the sender and MUST be ignored by the receiver.

   Dynamic IP Multicast Selector Mode Flag:

      This field indicates the subscription via MTMA/direct routing
      mode.  If the (M) flag value is set to a value of (1), it is an
      indication that the IP multicast traffic associated to the
      multicast group identified by the Multicast Address Record in this
      mobility option SHOULD be routed locally (subscription via direct
      routing mode).  If the (M) flag value is set to a value of (0), it
      is an indication that IP multicast traffic associated to the
      multicast group identified by the Multicast Address Record in this
      mobility option SHOULD be routed to the home network, via the MTMA
      (subscription via MTMA mode).  All other IP traffic associated
      with the mobile node SHOULD be managed according to a default
      policy configured at the PMIPv6 multicast domain.

   Multicast Address Record:

      Multicast subscription information corresponding to a single
      subscribed multicast address as defined in [RFC3810].

6.  Multicast Tree Mobility Anchor Operation

   The MTMA provides connectivity to the multicast infrastructure out of
   the PMIPv6 domain.  The MTMA itself could either act as an additional
   MLD proxy (only in the case where all the connected MAGs act also as
   MLD proxies), reporting to a further node an aggregated view of the
   subscriptions in a PMIPv6 multicast domain; or it can act as a
   designated multicast router for all the MAGs in a PMIPv6 multicast
   domain.  The MTMA will then request the multicast content on behalf
   of the MAGs (and MNs behind them).  In addition, the MTMA will create
   and maintain the corresponding multicast forwarding states per each
   tunnel interface towards the MAGs.  Whatever the role played, when
   the MAGs act as MLD proxy, the MTMA becomes the MLD querier of the
   MLD proxy instance located in each MAG.

Zuniga, et al.          Expires November 4, 2013               [Page 14]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

6.1.  Conceptual Data Structures

   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 (e.g., similar to what is
   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.

7.  Mobile Node Operation

   The MN operation is not impacted by the existence of an MTMA as
   anchor for the multicast traffic being subscribed or the use of
   direct routing.  The MN will act according to the stated operations
   in [RFC5213] and [RFC6224].

   This draft considers that every MN requesting multicast-only services
   is previously registered in a PMIPv6 unicast domain to get a unicast
   IP address.  The registration can also be required for several
   purposes such as remote management, billing, multicast configuration,
   etc.

   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, the
   later for the subscription via MTMA case.

8.  IPv4 support

   This document does not introduce any IPv4-specific issue regarding
   [RFC5844].  In order for the solution to support IPv4, all the
   described network elements (i.e.  MAG, MTMA and MR) must support
   IGMP.  In this case, the functionalities of the MAG and MTMA would be
   as described in [RFC6224], with the MTMA replicating the requirements
   described for the LMA.  For the case of the MR, it must also be dual-
   stack (i.e.  IPv6/IPv4) enabled.

   Although references to "MLD proxy" have been used in the document, it
   should be understood to also include "IGMP/MLD proxy" functionality.

Zuniga, et al.          Expires November 4, 2013               [Page 15]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

9.  IANA Considerations

   This document defines a new mobility option, the Dynamic IP Multicast
   Selector, which has been assigned the type TBD by IANA.

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

11.  Authors

   Additional co-authors of this document are:

      Akbar Rahman

         InterDigital Communications, LLC

         E-mail: akbar.rahman@interdigital.com

      Ignacio Soto

         Universidad Carlos III de Madrid

         E-mail: isoto@it.uc3m.es

12.  References

12.1.  Normative References

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

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

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4065]  Kempf, J., "Instructions for Seamoby and Experimental
              Mobility Protocol IANA Allocations", RFC 4065, July 2005.

Zuniga, et al.          Expires November 4, 2013               [Page 16]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

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

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

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

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

12.2.  Informative References

   [I-D.asaeda-pim-mldproxy-multif]
              Asaeda, H. and S. Jeon, "Multiple Upstream Interface
              Support for IGMP/MLD Proxy",
              draft-asaeda-pim-mldproxy-multif-01 (work in progress),
              February 2013.

   [I-D.contreras-multimob-multiple-upstreams]
              Contreras, L., Bernardos, C., and J. Zuniga, "Extension of
              the MLD proxy functionality to support multiple upstream
              interfaces",
              draft-contreras-multimob-multiple-upstreams-01 (work in
              progress), February 2013.

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

   [I-D.ietf-multimob-pmipv6-source]
              Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile
              Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6)
              Domains", draft-ietf-multimob-pmipv6-source-03 (work in
              progress), February 2013.

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

Zuniga, et al.          Expires November 4, 2013               [Page 17]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

Appendix A.  MTMA Deployment Use Cases

   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:

   o  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).

   o  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).

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

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

A.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 6 shows the scenario here described.

Zuniga, et al.          Expires November 4, 2013               [Page 18]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

            +----------------+       +----------------+
            |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 6: PMIPv6 domain with ratio N:1

   The Figure 6 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 November 4, 2013               [Page 19]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   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.

A.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.  Different
   MTMAs might be associated to serving different multicast groups.
   These associations remain the same even if the MNs move within the
   PMIPv6 domain.

   Figure 7 shows the scenario here described.

Zuniga, et al.          Expires November 4, 2013               [Page 20]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

     +----------------+                    +----------------+
     |Content Source A|                    |Content Source B|
     +----------------+                    +----------------+
            |                                       |
            |          ********************         |
           ( )        *                    *       ( )
          (   )      *    Fixed Internet    *     (   )
         (     )     *   (Unicast Traffic)  *    (     )
          (   )       *                    *      (   )
           ( )         ********************        ( )
            |                   |                   |
            |                   |                   |
         +------+       +--------------+      +------+
         | MTMA1|       |     LMA2     |      | MTMA3|
         +------+       +--------------+      +------+
         oo      oo           // \\          ^^     ^^
          oo       oo        //   \\       ^^      ^^
           oo        oo     //     \\    ^^       ^^
            oo         oo  //       \\ ^^        ^^
             oo          oo/         ^^         ^^
              oo         //oo      ^^ \\       ^^
               oo       //   oo  ^^    \\     ^^
                oo     //      oo       \\   ^^
                 oo   //      ^^ oo      \\ ^^
                  oo //     ^^     oo     \^^
               +-------------+     +-------------+
               |   \      /  |     |  \     |    |
               |   ~o~~~~o~  |     |  ~o~~~~o~   |
               |  ( MLD w  ) |     | (  MLD w )  |
               |  ( multip ) |     | ( multip )  |
               |  (  i/f   ) |     | (  i/f   )  |
               |   ~~~~~~~~  |     |  ~~~~~~~~   |
               |             |     |             |
               |     MAG1    |     |     MAG2    |
              /+-------------+     +-------------+\
             |       |       |     |        |      |
             |       |       |     |        |      |
          {MN10}   {MN11} {MN12}  {MN20}  {MN21} {MN22}

                  Figure 7: PMIPv6 domain with ratio 1:N

   Figure 7 proposes an architecture where the LMA2 is the unique LMA
   for a certain group of MNs, while there are two other entities, MTMA1
   and MTMA3, acting as MTMAs for different subsets of multicast
   content.  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).  Looking at the figure, all MNs are

Zuniga, et al.          Expires November 4, 2013               [Page 21]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   served by LMA2 for unicast, while they might be simultaneously served
   by MTMA1 and MTMA3, depending on the multicast content.  For the
   scenario described above, the association between multicast content
   and MTMA is permanently maintained.  Note that this scenario requires
   the support for multiple MLD upstream interfaces at the MAGs.

A.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 8
   adapts the PMIPv6 domain with ratio N:1 scenario of Figure 7 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
   unicast traffic to the subset formed by MN30, MN40 and MN41.

Zuniga, et al.          Expires November 4, 2013               [Page 22]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

            +----------------+       +----------------+
            |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 8: PMIPv6 domain with H-LMA

   Figure 8 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.

Zuniga, et al.          Expires November 4, 2013               [Page 23]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   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 MN20, 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.

Authors' Addresses

   Juan Carlos Zuniga
   InterDigital Communications, LLC
   1000 Sherbrooke Street West, 10th floor
   Montreal, Quebec  H3A 3G4
   Canada

   Email: JuanCarlos.Zuniga@InterDigital.com
   URI:   http://www.InterDigital.com/

   Luis M. Contreras
   Telefonica I+D
   Don Ramon de la Cruz, 82-84
   Madrid  28006
   Spain

   Email: lmcm@tid.es

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/

Zuniga, et al.          Expires November 4, 2013               [Page 24]
Internet-Draft  Multicast Mobility Routing Optimizations        May 2013

   Seil Jeon
   Instituto de Telecomunicacoes
   Campus Universitario de Santiago
   Aveiro  3810-193
   Portugal

   Email: seiljeon@av.it.pt
   URI:   https://atnog.av.it.pt/~sjeon/

   Younghan Kim
   Soongsil University
   Sangdo-dong, Dongjak-gu
   Seoul  511
   Republic of Korea

   Email: yhkim@dcn.ssu.ac.kr
   URI:   http://dcnlab.ssu.ac.kr/

Zuniga, et al.          Expires November 4, 2013               [Page 25]