[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-schmidt-multimob-pmipv6-mcast-deployment) 00 01 02 03 04 05 06 07 RFC 6224

MULTIMOB Group                                              T C. Schmidt
Internet-Draft                                               HAW Hamburg
Intended status: BCP                                        M. Waehlisch
Expires: December 2, 2010                           link-lab & FU Berlin
                                                             S. Krishnan
                                                            May 31, 2010

    Base Deployment for Multicast Listener Support in PMIPv6 Domains


   This document describes deployment options for activating multicast
   listener functions in Proxy Mobile IPv6 domains without modifying
   mobility and multicast protocol standards.  Similar to Home Agents in
   Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as
   multicast subscription anchor points, while Mobile Access Gateways
   provide MLD proxy functions.  In this scenario, Mobile Nodes remain
   agnostic of multicast mobility operations.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 December 2, 2010.

Copyright Notice

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

Schmidt, et al.         Expires December 2, 2010                [Page 1]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   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 . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Deployment Details . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Operations of the Mobile Node  . . . . . . . . . . . . . .  8
     4.2.  Operations of the Mobile Access Gateway  . . . . . . . . .  8
     4.3.  Operations of the Local Mobility Anchor  . . . . . . . . . 10
     4.4.  IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10
     4.5.  Multihoming Support  . . . . . . . . . . . . . . . . . . . 11
     4.6.  Multicast Availability throughout the Access Network . . . 11
     4.7.  A Note on Explicit Tracking  . . . . . . . . . . . . . . . 12
   5.  Message Source and Destination Address . . . . . . . . . . . . 12
     5.1.  Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Report/Done  . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Initial MLD Queries on Upcoming Links . . . . . . . . 15
   Appendix B.  State of IGMP/MLD Proxy Implementations . . . . . . . 15
   Appendix C.  Comparative Evaluation of Different Approaches  . . . 16
   Appendix D.  Change Log  . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Schmidt, et al.         Expires December 2, 2010                [Page 2]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by
   network-based management functions that enable IP mobility for a host
   without requiring its participation in any mobility-related
   signaling.  Additional network entities called the Local Mobility
   Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for
   managing IP mobility on behalf of the mobile node (MN).

   With these entities in place, the mobile node looses transparent end-
   to-end connectivity to the static Internet, and in the particular
   case of multicast communication, group membership management as
   signaled by the Multicast Listener Discovery protocol [RFC3810],
   [RFC2710] requires dedicated treatment at the network side, see

   Multicast routing functions need to be placed carefully within the
   PMIPv6 domain to augment unicast transmission with group
   communication services.  [RFC5213] does not explicitly address
   multicast communication and thus relies on the minimal multicast
   support provided by MIPv6.  But unfortunately, bi-directional home
   tunneling, the minimal multicast support arranged by MIPv6, cannot be
   applied in network-based management scenarios, since a mobility-
   unaware node will not initiate such a tunnel after movement.
   Consequently, even a minimal multicast listener support in PMIPv6
   domains requires an explicit deployment of additional functions, as
   is the subject of this document.

   This document describes options for deploying multicast listener
   functions in Proxy Mobile IPv6 domains without modifying mobility and
   multicast protocol standards.  Similar to Home Agents in Mobile IPv6,
   PMIPv6 Local Mobility Anchors serve as multicast subscription anchor
   points, while Mobile Access Gateways provide MLD proxy functions.
   Mobile Nodes in this scenario remain agnostic of multicast mobility
   operations.  This document does not address specific optimizations
   and efficiency improvements of multicast routing for network-based
   mobility discussed in [RFC5757], as such solutions would require
   changes to the base PMIPv6 protocol [RFC5213].

2.  Terminology

   This document uses the terminology as defined for the mobility
   protocols [RFC3775], [RFC5213] and [RFC5844], as well as the
   multicast edge related protocols[RFC3376], [RFC3810] and [RFC4605].

Schmidt, et al.         Expires December 2, 2010                [Page 3]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

3.  Overview

   The reference scenario for multicast deployment in Proxy Mobile IPv6
   domains is illustrated in Figure 1.
                       | Content     |
                       | Source      |
                     ***  ***  ***  ***
                    *   **   **   **   *
                   *                    *
                    *  Fixed Internet  *
                   *                    *
                    *   **   **   **   *
                     ***  ***  ***  ***
                      /            \
                  +----+         +----+
                  |LMA1|         |LMA2|                 Multicast Anchor
                  +----+         +----+
             LMAA1  |              |  LMAA2
                    |              |
                    \\           //\\
                     \\         //  \\
                      \\       //    \\                 Unicast Tunnel
                       \\     //      \\
                        \\   //        \\
                         \\ //          \\
               Proxy-CoA1 ||            ||  Proxy-CoA2
                       +----+          +----+
                       |MAG1|          |MAG2|           MLD Proxy
                       +----+          +----+
                        |  |             |
                MN-HNP1 |  | MN-HNP2     | MN-HNP3
                       MN1 MN2          MN3

      Figure 1: Reference Network for Multicast Deployment in PMIPv6

   An MN in a PMIPv6 domain will decide on multicast group membership
   management completely independent of its current mobility conditions.
   It will submit MLD Report and Done messages, based on application
   triggers, using its link-local source address and multicast
   destination addresses according to [RFC3810], or [RFC2710].  These
   link-local signaling messages will arrive at the currently active MAG
   via one of its downstream local (wireless) links.  A multicast
   unaware MAG would simply discard these MLD messages.

   To facilitate multicast in a PMIPv6 domain, an MLD proxy function

Schmidt, et al.         Expires December 2, 2010                [Page 4]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   [RFC4605] needs to be deployed on the MAG that selects the tunnel
   interface corresponding to the MN's LMA for its upstream interface
   (cf., section 6 of [RFC5213]).  Thereby, each MAG-to-LMA tunnel
   interface defines an MLD proxy domain at the MAG, and it contains all
   downstream links to MNs that share this specific LMA.  According to
   standard proxy operations, MLD Report messages will be forwarded
   under aggregation up the tunnel interface to its corresponding LMA.

   Serving as the designated multicast router or an additional MLD
   proxy, the LMA will transpose any MLD message from a MAG into the
   multicast routing infrastructure.  Correspondingly, the LMA will
   create appropriate multicast forwarding states at its tunnel
   interface.  Traffic arriving for subscribed groups will arrive at the
   LMA, and the LMA will forward this traffic according to its group/
   source states.  In addition, the LMA will act as an MLD querier,
   seeing its downstream tunnel interfaces as multicast enabled links.

   At the MAG, MLD queries and multicast data will arrive on the
   (tunnel) interface that is assigned to a group of access links as
   identified by its Binding Update List (cf., section 6 of [RFC5213]).
   As specified for MLD proxies, the MAG will forward multicast traffic
   and initiate related signaling down the appropriate access links to
   the MNs.  Hence all multicast-related signaling and the data traffic
   will transparently flow from the LMA to the MN on an LMA-specific
   tree, which is shared among the multicast sources.

   In case of a handover, the MN (unaware of IP mobility) will not send
   unsolicited MLD reports.  Instead, the MAG is required to maintain
   group memberships in the following way.  On observing a new MN on a
   downstream access link, the MAG sends a General MLD Query.  Based on
   its outcome and the multicast group states previously maintained at
   the MAG, a corresponding Report will be sent to the LMA aggregating
   group membership states according to the proxy function.  Additional
   Reports can be omitted when the previously established multicast
   forwarding states at the new MAG already cover the subscriptions of
   the MN.

   In summary, the following steps are executed on handover:

   1.  The MAG-MN link comes up and the MAG discovers the new MN.

   2.  Unicast address configuration and PMIPv6 binding are performed
       after the MAG determines the corresponding LMA.

   3.  Following IPv6 address configuration, the MAG SHOULD send an
       (early) MLD General Query to the new downstream link as part of
       its standard multicast-enabled router operations.

Schmidt, et al.         Expires December 2, 2010                [Page 5]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   4.  The MAG SHOULD determine whether the MN is admissible to
       multicast services, and stop here otherwise.

   5.  The MAG adds the new downstream link to the MLD proxy instance
       with up-link to the corresponding LMA.

   6.  The corresponding Proxy instance triggers an MLD General Query on
       the new downstream link.

   7.  The MN Membership Reports arrive at the MAG, either in response
       to the early Query or to that of the Proxy instance.

   8.  The Proxy processes the MLD Report, updates states and reports
       upstream if necessary.

   After Re-Binding, the LMA is not required to issue a General MLD
   Query on the tunnel link to refresh forwarding states.  Multicast
   state updates SHOULD be triggered by the MAG, which aggregates
   subscriptions of all its MNs (see the call flow in Figure 2).

Schmidt, et al.         Expires December 2, 2010                [Page 6]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   MN1             MAG1             MN2             MAG2             LMA
   |                |                |               |                |
   |    Join(G)     |                |               |                |
   +--------------->|                |               |                |
   |                |     Join(G)    |               |                |
   |                |<---------------+               |                |
   |                |                |               |                |
   |                |     Aggregated Join(G)         |                |
   |                +================================================>|
   |                |                |               |                |
   |                |   Mcast Data   |               |                |
   |                |<================================================+
   |                |                |               |                |
   |  Mcast Data    | Mcast Data     |               |                |
   |<---------------+--------------->|               |                |
   |                |                |               |                |
   |                |      < Movement to MAG2 & PMIP Binding Update > |
   |                |                |               |                |
   |                |                |--- Rtr Sol -->|                |
   |                |                |               |                |
   |                |                |   MLD Query   |                |
   |                |                |<--------------+                |
   |                |                |               |                |
   |                |                |   Join(G)     |                |
   |                |                +-------------->|                |
   |                |                |               Aggregated Join(G)
   |                |                |               +===============>|
   |                |                |               |                |
   |                |   Mcast Data   |               |                |
   |                |<================================================+
   |                |                |               |   Mcast Data   |
   |                |                |               |<===============+
   |  Mcast Data    |                |               |                |
   |<---------------+                |  Mcast Data   |                |
   |                |                |<--------------+                |
   |                |                |               |                |

    Figure 2: Call Flow of Multicast-enabled PMIP with "MLD Membership
                       Report" abbreviated by "Join"

   These multicast deployment considerations likewise apply for mobile
   nodes that operate with their IPv4 stack enabled in a PMIPv6 domain.
   PMIPv6 can provide IPv4 home address mobility support [RFC5844].
   Such mobile nodes will use IGMP [RFC2236],[RFC3376] signaling for
   multicast, which is handled by an IGMP proxy function at the MAG in
   an analogous way.

   Following these deployment steps, multicast management transparently

Schmidt, et al.         Expires December 2, 2010                [Page 7]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   inter-operates with PMIPv6.  It is worth noting that MNs - while
   being attached to the same MAG, but associated with different LMAs -
   can subscribe to the same multicast group.  Thereby data could be
   distributed redundantly in the network and duplicate traffic could
   arrive at a MAG.  Additionally in a point-to-point wireless link
   model, an MAG might be forced to transmit the same data over one
   wireless domain to different MNs.  However, multicast traffic to one
   MN will always remain unique, i.e., the mobile multicast distribution
   system will never cause duplicate packets arriving at an MN (see
   Appendix C for further considerations).

4.  Deployment Details

   Multicast activation in a PMIPv6 domain requires to deploy general
   multicast functions at PMIPv6 routers and to define its interaction
   with the PMIPv6 protocol in the following way:

4.1.  Operations of the Mobile Node

   A Mobile Node willing to manage multicast traffic will join, maintain
   and leave groups as if located in the fixed Internet.  No specific
   mobility actions nor implementations are required at the MN.

4.2.  Operations of the Mobile Access Gateway

   A Mobile Access Gateway is required to assist in MLD signaling and
   data forwarding between the MNs which it serves, and the
   corresponding LMAs associated to each MN.  It therefore needs to
   implement an instance of the MLD proxy function [RFC4605] for each
   upstream tunnel interface that has been established with an LMA.  The
   MAG decides on the mapping of downstream links to a proxy instance
   (and hence an upstream link to an LMA) based on the regular Binding
   Update List as maintained by PMIPv6 standard operations (cf., section
   6.1 of [RFC5213]).  As links connecting MNs and MAGs change under
   mobility, MLD proxies at MAGs MUST be able to dynamically add and
   remove downstream interfaces in its configuration.

   On the reception of MLD reports from an MN, the MAG MUST identify the
   corresponding proxy instance from the incoming interface and perform
   regular MLD proxy operations: it will insert/update/remove multicast
   forwarding state on the incoming interface, and will merge state
   updates into the MLD proxy membership database.  It will then send an
   aggregated Report to the upstream tunnel to the LMA when the
   membership database (cf., section 4.1 of [RFC4605]) changes.
   Conversely, on the reception of MLD Queries, the MAG proxy instance
   will answer the Queries on behalf of all active downstream receivers
   maintained in its membership database.  Queries sent by the LMA do

Schmidt, et al.         Expires December 2, 2010                [Page 8]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   not force the MAG to trigger corresponding messages immediately
   towards MNs.  Multicast traffic arriving at the MAG on an upstream
   interface will be forwarded according to the group/source-specific
   forwarding states as acquired for each downstream interface within
   the MLD proxy instance.  At this stage, it is important to note that
   IGMP/MLD proxy implementations capable of multiple instances are
   expected to closely follow the specifications of section 4.2 in
   [RFC4605], i.e., treat proxy instances in isolation of each other
   while forwarding.

   After a handover, the MAG will continue to manage upstream tunnels
   and downstream interfaces as specified in the PMIPv6 specification.
   It MUST dynamically associate new access links to proxy instances
   that include the upstream connection to the corresponding LMA.  The
   MAG detects the arrival of a new MN by receiving a router
   solicitation message and by an upcoming link.  To learn about
   multicast groups subscribed by a newly attaching MN, the MAG SHOULD
   send a General Query to the MN's link.  Querying an upcoming
   interface is a standard operation of MLD queriers (see Appendix A)
   and is performed immediately after address configuration.  In
   addition, an MLD query SHOULD be initiated by the proxy instance, as
   soon as a new interface has been configured for downstream.  In case,
   the access link between MN and MAG goes down, interface-specific
   multicast states change.  Both cases may alter the composition of the
   membership database and this will trigger corresponding Reports
   towards the LMA.  Note that the actual observable state depends on
   the access link model in use.

   An MN may be unable to answer MAG multicast membership queries due to
   handover procedures, or its report may arrive before the MAG has
   configured its link as proxy downstream interface.  Such occurrences
   are equivalent to a General Query loss.  To prevent erroneous query
   timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to
   the mobility regime.  In particular, MLD timers and the Robustness
   Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant
   with the time scale of handover operations and proxy configurations
   in the PMIPv6 domain.

   In proceeding this way, the MAG is able to aggregate multicast
   subscriptions for each of its MLD proxy instances.  However, this
   deployment approach does not prevent multiple identical streams
   arriving from different LMA upstream interfaces.Furthermore, a
   multipoint channel forwarding into the wireless domain is prevented
   by the point-to-point link model in use.

Schmidt, et al.         Expires December 2, 2010                [Page 9]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

4.3.  Operations of the Local Mobility Anchor

   For any MN, the Local Mobility Anchor acts as the persistent Home
   Agent and at the same time as the default multicast querier for the
   corresponding MAG.  It implements the function of the designated
   multicast router or a further MLD proxy.  According to MLD reports
   received from a MAG (on behalf of the MNs), it establishes/maintains/
   removes group/source-specific multicast forwarding states at its
   corresponding downstream tunnel interfaces.  At the same time, it
   procures for aggregated multicast membership maintenance at its
   upstream interface.  Based on the multicast-transparent operations of
   the MAGs, the LMA treats its tunnel interfaces as multicast enabled
   downstream links, serving zero to many listening nodes.  Multicast
   traffic arriving at the LMA is transparently forwarded according to
   its multicast forwarding information base.

   After a handover, the LMA will receive Binding De-Registrations and
   Binding Lifetime Extensions that will cause a re-mapping of home
   network prefix(es) to a new Proxy-CoA in its Binding Cache (see
   section 5.3 of [RFC5213]).  The multicast forwarding states require
   updating, as well, if the MN within an MLD proxy domain is the only
   receiver of a multicast group.  Two different cases need to be

   1.  The mobile node is the only receiver of a group behind the
       interface at which a De-Registration was received: The membership
       database of the MAG changes, which will trigger a Report/Done
       sent via the MAG-to-LMA interface to remove this group.  The LMA
       thus terminates multicast forwarding.

   2.  The mobile node is the only receiver of a group behind the
       interface at which a Lifetime Extension was received: The
       membership database of the MAG changes, which will trigger a
       Report sent via the MAG-to-LMA interface to add this group.  The
       LMA thus starts multicast distribution.

   In proceeding this way, each LMA will provide transparent multicast
   support for the group of MNs it serves.  It will perform traffic
   aggregation at the MN-group level and will assure that multicast data
   streams are uniquely forwarded per individual LMA-to-MAG tunnel.

4.4.  IPv4 Support

   An MN in a PMIPv6 domain may use an IPv4 address transparently for
   communication as specified in [RFC5844].  For this purpose, LMAs can
   register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide
   IPv4 support in access networks.  Correspondingly, multicast
   membership management will be performed by the MN using IGMP.  For

Schmidt, et al.         Expires December 2, 2010               [Page 10]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   multicast support on the network side, an IGMP proxy function needs
   to be deployed at MAGs in exactly the same way as for IPv6.
   [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/
   MLD.  Thus IPv4 support can be transparently provided following the
   obvious deployment analogy.

   For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
   SHOULD choose multicast signaling according to address configurations
   on the link, but MAY submit IGMP and MLD queries in parallel, if
   needed.  It should further be noted that the infrastructure cannot
   identify two data streams as identical when distributed via an IPv4
   and IPv6 multicast group.  Thus duplicate data may be forwarded on a
   heterogeneous network layer.

4.5.  Multihoming Support

   An MN can connect to a PMIPv6 domain through multiple interfaces and
   experience transparent unicast handovers at all interfaces (cf.,
   section 5.4 of [RFC5213]).  In such simultaneous access scenario, it
   can autonomously assign multicast channel subscriptions to individual
   interfaces.  While doing so, multicast mobility operations described
   in this document will transparently preserve the association of
   channels to interfaces in the following way.

   Multicast listener states are kept per interface in the MLD state
   table.  An MN will answer to an MLD General Query received on a
   specific (re-attaching) interface according to the specific
   interface's state table.  Thereafter, multicast forwarding is resumed
   for channels identical to those under subscription prior to handover.
   Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to
   facilitate load balancing or redundancy, but cannot follow a 'make-
   before-break' approach to service continuation on handovers.

4.6.  Multicast Availability throughout the Access Network

   There may be deployment scenarios, where multicast services are
   available throughout the access network independent of the PMIPv6
   infrastructure.  Direct multicast access at MAGs may be supported
   through native multicast routing within a flat access network that
   includes a multicast router, via dedicated (tunnel or VPN) links
   between MAGs and designated multicast routers, or by deploying AMT

   Multicast deployment can be simplified in these scenarios.  A single
   proxy instance at MAGs with up-link into the multicast cloud, for
   instance, could serve group communication purposes.  MAGs could
   operate as general multicast routers or AMT gateways, as well.

Schmidt, et al.         Expires December 2, 2010               [Page 11]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   Common to these solutions is that mobility management is covered by
   the dynamics of multicast routing, as initially foreseen in the
   Remote Subscription approach sketched in [RFC3775].  Care must be
   taken to avoid avalanche problems or service disruptions due to tardy
   multicast routing operations, and to adapt to different link-layer
   technologies [RFC5757].  The different possible approaches should be
   carefully investigated beyond the initial sketch in Appendix C.  Such
   work is beyond the scope of this document.

4.7.  A Note on Explicit Tracking

   IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with
   explicit tracking, which allows routers to monitor each multicast
   receiver.  This mechanism is not standardized yet, but widely
   implemented by vendors as it supports faster leave latencies and
   reduced signaling.

   Enabling explicit tracking on downstream interfaces of the LMA and
   MAG would track a single MAG and MN respectively per interface.  It
   may be used to preserve bandwidth on the MAG-MN link.

5.  Message Source and Destination Address

   This section describes source and destination addresses of MLD
   messages.  The interface identifier A-B denotes an interface on node
   A, which is connected to node B. This includes tunnel interfaces.

5.1.  Query
        | Interface | Source Address | Destination Address  | Header   |
        |           | LMAA           | Proxy-CoA            | outer    |
        + LMA-MAG   +----------------+----------------------+----------+
        |           | LMA-link-local | [RFC2710], [RFC3810] | inner    |
        | MAG-MN    | MAG-link-local | [RFC2710], [RFC3810] |   --     |

Schmidt, et al.         Expires December 2, 2010               [Page 12]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

5.2.  Report/Done
        | Interface | Source Address | Destination Address  | Header   |
        | MN-MAG    | MN-link-local  | [RFC2710], [RFC3810] |   --     |
        |           | Proxy-CoA      | LMAA                 | outer    |
        + MAG-LMA   +----------------+----------------------+----------+
        |           | MAG-link-local | [RFC2710], [RFC3810] | inner    |

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

7.  Security Considerations

   This draft does not introduce additional messages or novel protocol
   operations.  Consequently, no new threats are introduced by this
   document in addition to those identified as security concerns of
   [RFC3810], [RFC4605], [RFC5213], and [RFC5844].

   However, particular attention should be paid to implications of
   combining multicast and mobility management at network entities.  As
   this specification allows mobile nodes to initiate the creation of
   multicast forwarding states at MAGs and LMAs while changing
   attachments, threats of resource exhaustion at PMIP routers and
   access networks arrive from rapid state changes, as well as from high
   volume data streams routed into access networks of limited
   capacities.  In addition to proper authorization checks of MNs, rate
   controls at replicators MAY be required to protect the agents and the
   downstream networks.  In particular, MLD proxy implementations at
   MAGs SHOULD carefully procure for automatic multicast state
   extinction on the departure of MNs, as mobile multicast listeners in
   the PMIPv6 domain will not actively terminate group membership prior
   to departure.

8.  Acknowledgements

   This memo is the outcome of extensive previous discussions and a
   follow-up of several initial drafts on the subject.  The authors
   would like to thank (in alphabetical order) Luis Contreras, Greg

Schmidt, et al.         Expires December 2, 2010               [Page 13]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   Daley, Gorry Fairhurst, Dirk von Hugo, Seil Jeon, Jouni Korhonen,
   Guang Lu, Sebastian Meiling, Liu Hui, Imed Romdhani, Behcet Sarikaya,
   Stig Venaas, and Juan Carlos Zuniga for advice, help and reviews of
   the document.  Funding by the German Federal Ministry of Education
   and Research within the G-LAB Initiative is gratefully acknowledged.

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.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

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

9.2.  Informative References

              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.


Schmidt, et al.         Expires December 2, 2010               [Page 14]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
              Pusateri, "Automatic IP Multicast Without Explicit Tunnels
              (AMT)", draft-ietf-mboned-auto-multicast-10 (work in
              progress), March 2010.

              Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
              Services Using Proxy Mobile IPv6",
              draft-zuniga-multimob-smspmip-02 (work in progress),
              February 2010.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC5757]  Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
              Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
              and Brief Survey", RFC 5757, February 2010.

Appendix A.  Initial MLD Queries on Upcoming Links

   According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled
   multicast router starts operating on a subnet, by default it
   considers itself as Querier and sends several General Queries.  Such
   initial query should be sent by the router immediately, but could be
   delayed by a (tunable) Startup Query Interval (see Sections 7.6.2.
   and 9.6. of [RFC3810]).

   Experimental tests on Linux and Cisco systems have revealed immediate
   IGMP Queries following a link trigger event (within a fraction of 1
   ms), while MLD Queries immediately followed the autoconfiguration of
   IPv6 link-local addresses at the corresponding interface.

Appendix B.  State of IGMP/MLD Proxy Implementations

   The deployment scenario defined in this document requires certain
   proxy functionalities at the MAGs that implementations of [RFC4605]
   need to contribute.  In particular, a simultaneous support of IGMP
   and MLD is needed, as well as a configurable list of downstream
   interfaces that may be altered during runtime, and the deployment of
   multiple proxy instances at a single router that can operate
   independently on separated interfaces.

   A brief experimental trial undertaken in February 2010 revealed the
   following divergent status of selected IGMP/MLD proxy

Schmidt, et al.         Expires December 2, 2010               [Page 15]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   Cisco Edge Router  Software-based commodity edge routers (test device
      from the 26xx-Series) implement IGMPv2/v3 proxy functions only in
      combination with PIM-SM.  There is no support of MLD Proxy.
      Interfaces are dynamically configurable at runtime via the CLI,
      but multiple proxy instances are not supported.

   Linux igmpproxy  IGMPv2 Proxy implementation that permits a static
      configuration of downstream interfaces (simple bug fix required).
      Multiple instances are prevented by a lock (corresponding code re-
      used from a previous DVMRP implementation).  IPv6/MLD is
      unsupported.  Project page:

   Linux gproxy  IGMPv3 Proxy implementation that permits configuration
      of the upstream interface, only.  Downstream interfaces are
      collected at startup without dynamic extension of this list.  No
      support of multiple instances or MLD.  Project page: http://

   Linux ecmh  MLDv1/2 Proxy implementation without IGMP support that
      inspects IPv4 tunnels and detects encapsulated MLD messages.
      Allows for dynamic addition of interfaces at runtime and multiple
      instances.  However, downstream interfaces cannot be configured.
      Project page: http://sourceforge.net/projects/ecmh/

Appendix C.  Comparative Evaluation of Different Approaches

   In this section, we briefly evaluate two basic PMIP concepts for
   multicast traffic organization at LMAs: In scenario A, multicast is
   provided by combined unicast/multicast LMAs as described in this
   document.  Scenario B directs traffic via a dedicated multicast LMA
   as proposed in [I-D.zuniga-multimob-smspmip], for example.

   Both approaches do not establish native multicast distribution
   between the LMA and MAG, but use tunneling mechanisms.  In scenario
   A, a MAG is connected to different multicast-enabled LMAs, and can
   receive the same multicast stream via multiple paths depending on the
   group subscriptions of MNs and their associated LMAs.  This problem,
   a.k.a. tunnel convergence problem, may lead to redundant traffic at
   the MAGs.  Scenario B in contrast configures MAGs to establish a
   tunnel to a single, dedicated multicast LMA for all attached MNs and
   relocates overhead costs to the multicast anchor.  This eliminates
   redundant traffic, but may result in an avalanche problem at the LMA.

   We quantify the costs of both approaches based on two metrics: The
   amount of redundant traffic at MAGs and the number of simultaneous

Schmidt, et al.         Expires December 2, 2010               [Page 16]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   streams at LMAs.  Realistic values depend on the topology and the
   group subscription model.  To explore scalability in a large PMIP
   domain of 1,000,000 MNs, we consider the following two extremal
   multicast settings.

   1.  All MNs participate in distinct multicast groups.

   2.  All MNs join the same multicast groups.

   A typical PMIP deployment approximately allows for 5,000 MNs attached
   to one MAG, while 50 MAGs can be served by one LMA.  Hence 1,000,000
   MNs require approx. 200 MAGs backed by 4 LMAs for unicast
   transmission.  In scenario A, these LMAs also forward multicast
   streams, while in scenario B one additional dedicated LMA (LMA-M)
   serves multicast.  In the following, we calculate the metrics
   described above.  In addition, we display the number of packet
   streams that cross the interconnecting (wired) network within a
   PMIPv6 domain.

   Setting 1:
   | PMIP multicast    | # of redund. | # of simul.    | # of total    |
   | scheme            |   streams    |   streams      |  streams in   |
   |                   |   at MAG     | at LMA/LMA-M   |  the network  |
   | Combined Unicast/ |        0     |     250,000    |  1,000,000    |
   | Multicast LMA     |              |                |               |
   | Dedicated         |        0     |   1,000,000    |  1,000,000    |
   | Multicast LMA     |              |                |               |

         1,000,000 MNs are subscribed to distinct multicast groups

Schmidt, et al.         Expires December 2, 2010               [Page 17]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   Setting 2:
   | PMIP multicast    | # of redund. | # of simul.    | # of total    |
   | scheme            |   streams    |   streams      |  streams in   |
   |                   |   at MAG     | at LMA/LMA-M   |  the network  |
   | Combined Unicast/ |        3     |       200      |     800       |
   | Multicast LMA     |              |                |               |
   | Dedicated         |        0     |       200      |     200       |
   | Multicast LMA     |              |                |               |

         1,000,000 MNs are subscribed to the same multicast group

   These considerations of extremal settings show that tunnel
   convergence, i.e., duplicate data arriving at a MAG, does cause much
   smaller problems in scalability than the stream replication at LMAs
   (avalanche problem).  For scenario A it should be also noted that the
   high stream replication requirements at LMAs in setting 1 can be
   attenuated by deploying additional LMAs in a PMIP domain, while
   scenario B does not allow for distributing the LMA-M, as no handover
   management is available at LMA-M.

Appendix D.  Change Log

   The following changes have been made from version

   1.  Editorial improvements in response to WG feedback.

   The following changes have been made from version

   1.  Added section on multihoming.

   2.  Updated security section.

   3.  Several editorial improvements and minor extensions.

   The following changes have been made from the previous individual
   version draft-schmidt-multimob-pmipv6-mcast-deployment-04.

   1.  Updated references.

   2.  Corrected typos.

Schmidt, et al.         Expires December 2, 2010               [Page 18]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   3.  Adjusted title & document name.

   The following changes have been made from

   1.  Detailed outline of multicast reconfiguration steps on handovers
       added in protocol overview (section 3).

   2.  Clarified the details of proxy operations at the MAG along with
       the expected features of IGMP/MLD Proxy implementations (section

   3.  Clarified querying in dual-stack scenarios (section 4.4).

   4.  Subsection added on the special case, where multicast is
       available throughout the access network (section 4.5).

   5.  Appendix on IGMP/MLD behaviour added with test reports on current
       Proxy implementations.

   The following changes have been made from

   1.  Many editorial improvements, in particular as response to draft

   2.  Section on IPv4 support added.

   3.  Added clarifications on initial IGMP/MLD Queries and
       supplementary information in appendix.

   4.  Appendix added an comparative performance evaluation regarding
       mixed/dedicated deployment of multicast at LMAs.

Authors' Addresses

   Thomas C. Schmidt
   HAW Hamburg
   Berliner Tor 7
   Hamburg  20099

   Email: schmidt@informatik.haw-hamburg.de
   URI:   http://inet.cpt.haw-hamburg.de/members/schmidt

Schmidt, et al.         Expires December 2, 2010               [Page 19]

Internet-Draft        Multicast Listeners in PMIPv6             May 2010

   Matthias Waehlisch
   link-lab & FU Berlin
   Hoenower Str. 35
   Berlin  10318

   Email: mw@link-lab.net

   Suresh Krishnan
   8400 Decarie Blvd.
   Town of Mount Royal, QC

   Email: suresh.krishnan@ericsson.com

Schmidt, et al.         Expires December 2, 2010               [Page 20]

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