[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-multimob-pmipv6-base-solution

Network Working Group                                        TC. Schmidt
Internet-Draft                                               HAW Hamburg
Intended status: BCP                                        M. Waehlisch
Expires: December 15, 2009                          link-lab & FU Berlin
                                                             B. Sarikaya
                                                              Huawei USA
                                                             S. Krishnan
                                                           June 13, 2009

 A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 15, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Schmidt, et al.         Expires December 15, 2009               [Page 1]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009


   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, PMIPv6 Local Mobility Anchors 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].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Deployment Details . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Operations of the Mobile Node  . . . . . . . . . . . . . .  6
     4.2.  Operations of the Mobile Access Gateway  . . . . . . . . .  6
     4.3.  Operations of the Local Mobility Anchor  . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

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

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

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, i.e., 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 routing 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 a dedicated treatment, see

   Multicast routing functions need a careful placement within the
   PMIPv6 domain to augment unicast transmission with group
   communication services.  [RFC5213] does not explicitly address
   multicast communication, whereas bi-directional home tunneling, the
   minimal multicast support arranged by MIPv6, cannot be applied in
   network-based management scenarios: A mobility-unaware node will
   experience no reason to initiate a tunnel with an entity of mobility

   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, 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.  Accrediting the problem space of
   multicast mobility [I-D.irtf-mobopts-mmcastv6-ps], this document does
   not address optimization potentials and efficiency improvements of
   multicast routing in network-centered mobility, as such solutions
   would require changes to the base specification of [RFC5213].

2.  Terminology

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

   The reference scenario for multicast deployment in Proxy Mobile IPv6
   domains is illustrated in Figure 1.

Schmidt, et al.         Expires December 15, 2009               [Page 3]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

                       | Content     |
                       | Source      |
                     ***  ***  ***  ***
                    *   **   **   **   *
                   *                    *
                    *  Fixed Internet  *
                   *                    *
                    *   **   **   **   *
                     ***  ***  ***  ***
                      /            \
                  +----+         +----+
                  |LMA1|         |LMA2|                   MLD Querier
                  +----+         +----+
             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

3.  Overview

   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 following application
   desires, thereby using its link-local source address and multicast
   destinations 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
   [RFC4605] needs to be deployed on the MAG that selects the tunnel

Schmidt, et al.         Expires December 15, 2009               [Page 4]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

   interface corresponding to the MN's LMA for its upstream interface
   (cf., section 6 of [RFC5213]).  Thereby each LMA upstream interface
   defines an MLD proxy domain at the MAG, containing all downstream
   links to MNs that share this LMA.  MLD signaling of the MN will be
   consequently forwarded up the tunnel interface to its corresponding

   Serving as the designated multicast router or an additional MLD
   proxy, the LMA will transpose any MLD messages of the MN into the
   multicast routing infrastructure.  Correspondingly, the LMA will
   implement appropriate multicast forwarding states at its tunnel
   interface.  Traffic arriving for groups under subscription will
   arrive at the LMA, which it will forward according to all its group/
   source states.  In addition, the LMA will naturally act as an MLD
   querier, seeing its downstream tunnel interfaces as multicast enabled

   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 related signaling down the appropriate access links to the MNs.
   In proceeding this way, all multicast-related signaling and the
   corresponding traffic will transparently flow from the LMA to the MN
   on an LMA-specific shared tree.

   In case of a mobility handover, the (IP mobility unaware) MN will
   refrain from submitting unsolicited MLD reports.  Instead, the LMA is
   required to maintain group memberships in the following way.  On the
   reception of a Proxy Binding Update (PBU) from the new MAG and
   successful Re-Binding, the LMA re-establishes a route to the MN's
   home network prefix over the tunnel interface corresponding to the
   new MAG (cf., section 5.3 of [RFC5213]).

   After Re-Binding, the LMA SHOULD issue a general MLD query on the new
   tunnel link to refresh forwarding requirements.  Queries can be
   omitted, if multicast forwarding states previously established at the
   tunnel interface towards the new MAG form a superset of those present
   at the old tunnel interface.  The LMA SHOULD likewise perform a
   general MLD query after receiving a Binding De-Registration at a
   tunnel interface that is to be maintained.  The LMA MAY reduce the
   need for queries when it applies explicit tracking in combination
   with [RFC3810].

   These multicast deployment considerations likewise apply for mobile
   nodes that operate with its IPv4 stack enabled in a PMIPv6 domain.
   PMIPv6 can provide an IPv4 home address mobility support
   [I-D.ietf-netlmm-pmip6-ipv4-support].  Such mobile node will use

Schmidt, et al.         Expires December 15, 2009               [Page 5]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

   IGMPv3 [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
   interoperates with PMIPv6.  It is worth noting that multicast streams
   can possibly be distributed on redundant path, leading to duplicate
   traffic arriving from different LMAs at one MAG, and causing multiple
   data transmissions from a MAG over one wireless domain to different

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

   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 a
   multicast forwarding state on the incoming interface and forward the
   report to its upstream tunnel.  Conversely on the reception of MLD
   queries, the MAG proxy instance will transfer the queries to its
   appropriate downstream interfaces.  Multicast traffic arriving on an
   upstream interface at the MAG will be forwarded according to the
   group/source-specific forwarding states as acquired for each
   downstream interface within the MLD proxy instance.

   In case of a mobility handover, the MAG will continue to manage
   upstream tunnels and downstream interfaces as foreseen in the PMIPv6

Schmidt, et al.         Expires December 15, 2009               [Page 6]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

   specification.  However, it MUST assure consistency of its up- and
   downstream interfaces that change under mobility with MLD proxy
   instances and its multicast forwarding states.

   In proceeding this way, the MAG is entitled 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 per
   group forwarding into the wireless domain is restricted to the link
   model in use.

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.  It
   implements the function of the designated multicast router or a
   further MLD proxy.  According to MLD reports received from MNs (via
   MAGs), it establishes/maintains/removes group/source-specific
   multicast forwarding states at its downstream tunnel interfaces
   established with MAGs, and at the same time procures for aggregated
   multicast membership maintenance at its upstream interface.  Based on
   the multicast-transparent operations of the MAGs, the LMA experiences
   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
   states.  The LMA MAY choose to apply explicit node tracking in
   combination with MLDv2 [RFC3810].

   On the occurrence of a mobility handover, the LMA will receive
   Binding Lifetime De-Registrations and Binding Lifetime Extensions
   that will cause a re-mapping of home network prefixes to Proxy-CoAs
   in its Binding Cache.  Correspondingly, the multicast forwarding
   states require updating, as well.  In the absence of explicit
   tracking, the LMA MUST proceed as follows:

   o  Issue a general multicast query on a tunnel interface that is to
      be maintained even though a De-Registration was received.  Update
      the multicast forwarding states according to the query outcome.

   o  Issue a general multicast query on a tunnel interface at which a
      Lifetime Extension was received from a new Proxy-CoA, if the
      multicast forwarding states at this interface do not form a
      superset of the states established at the interface corresponding
      to the previous Proxy-CoA.

   For multicast membership queries, two cases need distinction:

Schmidt, et al.         Expires December 15, 2009               [Page 7]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

   1.  LMA multicast membership maintenance is unaffected by the
       handover-related absence of the MN: In this case, the LMA
       actively maintains states and continues to transmit multicast
       packets to the down-tunnel towards the MN.  The PMIPv6 protocol
       will transfer the tunnel endpoints and access link binding states
       between previous and new MAG, such that the MN can simply
       continue to receive its group traffic under subscription.
       Service interruptions are bound to the handover discontinuities
       experienced for PMIPv6 unicast transmission.

   2.  A MN may be unable to answer LMA multicast membership queries due
       to handover procedures.  Such instance is equivalent to a general
       query loss.  To prevent erroneous query timeouts at the LMA, 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
       temporal handover operations of the PMIPv6 domain.

   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.

5.  IANA Considerations

   This document makes no request of IANA.

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

6.  Security Considerations

   This draft does neither introduce additional messages nor novel
   protocol operations.  Consequently, no new threats arrive from
   procedures described in this document in excess to [RFC3810] and
   [RFC5213] security concerns.

7.  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 Gorry Fairhurst for advice and reviews of the

Schmidt, et al.         Expires December 15, 2009               [Page 8]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

8.  References

8.1.  Normative References

              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12
              (work in progress), April 2009.

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

8.2.  Informative References

              Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast
              Support Requirements for Proxy Mobile IPv6",
              draft-deng-multimob-pmip6-requirement-01 (work in
              progress), October 2008.

              Fairhurst, G., Schmidt, T., and M. Waehlisch, "Multicast
              Mobility in MIPv6: Problem Statement and Brief Survey",
              draft-irtf-mobopts-mmcastv6-ps-07 (work in progress),
              April 2009.

Schmidt, et al.         Expires December 15, 2009               [Page 9]

Internet-Draft        Multicast Listeners in PMIPv6            June 2009

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

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

   Email: mw@link-lab.net

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Email: sarikaya@ieee.org

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

   Email: suresh.krishnan@ericsson.com

Schmidt, et al.         Expires December 15, 2009              [Page 10]

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