text/plain draft-schmidt-multimob-pmipv6-base-source-00.txt — 25.2 KB

File contents

MULTIMOB Group                                              T C. Schmidt
Internet-Draft                                               HAW Hamburg
Intended status: Informational                              M. Waehlisch
Expires: September 26, 2011                         link-lab & FU Berlin
                                                               M. Farooq
                                                             HAW Hamburg
                                                          March 25, 2011

 Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast


   Multicast communication can be enabled in Proxy Mobile IPv6 domains
   by deploying MLD Proxy functions at Mobile Access Gateways, and
   multicast routing functions at Local Mobility Anchors.  This document
   describes the support of mobile multicast senders in Proxy Mobile
   IPv6 domains that is provided by this base deployment scenario.
   Mobile sources 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 September 26, 2011.

Copyright Notice

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

Schmidt, et al.        Expires September 26, 2011               [Page 1]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

   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 . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Source Mobility Details  . . . . . . . . . . . . . . . . . . .  7
     4.1.  Operations of the Mobile Node  . . . . . . . . . . . . . .  7
     4.2.  Operations of the Mobile Access Gateway  . . . . . . . . .  7
     4.3.  Operations of the Local Mobility Anchor  . . . . . . . . .  7
     4.4.  IPv4 Support . . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Efficiency of the Distribution System  . . . . . . . . . .  8
     4.6.  Multicast Availability throughout the Access Network . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Evaluation of Traffic Flows . . . . . . . . . . . . . 11
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Schmidt, et al.        Expires September 26, 2011               [Page 2]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
   [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).  An MN connected to a PMIPv6 domain, only operates according to
   the base specifications of [RFC5213], cannot participate in multicast
   communication, as MAGs will discard such packets.

   Multicast support for mobile listeners can be enabled within a PMIPv6
   domain by deploying MLD Proxy functions at Mobile Access Gateways,
   and multicast routing functions at Local Mobility Anchors
   [I-D.ietf-multimob-pmipv6-base-solution].  This base deployment
   option is the simplest way to PMIPv6 multicast extensions in the
   sense that it neither requires new protocol operations nor additional
   infrastructure entities.  Standard software functions need to be
   activated on PMIPv6 entities, only, on the price of possibly non-
   optimal multicast routing.

   This document describes the support of mobile multicast senders in
   Proxy Mobile IPv6 domains as it is provided in the base deployment
   scenario [I-D.ietf-multimob-pmipv6-base-solution].  Mobile Nodes in
   this setting remain agnostic of multicast mobility operations.  This
   document discusses implications on multicast routing, but does not
   address specific optimizations and efficiency improvements of
   multicast routing for network-based mobility as discussed in

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

3.  Overview

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

Schmidt, et al.        Expires September 26, 2011               [Page 3]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

                       | Multicast   |
                       | Listeners   |
                     ***  ***  ***  ***
                    *   **   **   **   *
                   *                    *
                    *  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
                 Multicast Sender + Listener(s)

   Figure 1: Reference Network for  Multicast Deployment in PMIPv6 with
                              Source Mobility

   An MN in a PMIPv6 domain will decide on multicast data transmission
   completely independent of its current mobility conditions.  It will
   send packets as initiated by application, using its source address
   with Home Network Prefix (HNP) and a multicast destination addresses
   chosen by application needs.  Multicast packets will arrive at the
   currently active MAG via one of its downstream local (wireless)
   links.  A multicast unaware MAG would simply discard these packets in
   the absence of a multicast forwarding information base (MFIB).

   An MN can successfully distribute multicast data in PMIPv6, if MLD
   proxy functions are deployed at the MAG as described in
   [I-D.ietf-multimob-pmipv6-base-solution].  In this set-up, the MLD

Schmidt, et al.        Expires September 26, 2011               [Page 4]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

   proxy instance serving a mobile multicast source has configured its
   upstream interface at the tunnel towards MN's corresponding LMA.  For
   each LMA, there will be a separate instance of an MLD proxy.

   According to the specifications given in [RFC4605], multicast data
   arriving from a downstream interface of an MLD proxy will be
   forwarded to the upstream interface and to all but the incoming
   downstream interfaces with appropriate forwarding states for this
   group.  Thus multicast streams originating from an MN will arrive at
   the corresponding LMA and directly at all mobile receivers co-located
   at the same MAG.  Serving as the designated multicast router or an
   additional MLD proxy, the LMA forwards data to the fixed Internet, if
   forwarding states are maintained through multicast routing.  If the
   LMA is acting as another MLD proxy, it will forward the multicast
   data to its upstream interface, and based upon the downstream
   interfaces' subscriptions accordingly.

   In case of a handover, the MN (unaware of IP mobility) can continue
   to send multicast packets as soon as network connectivity is
   reconfigured.  At this time, the MAG has determined the corresponding
   LMA and IPv6 unicast address configuration with PMIPv6 bindings have
   been performed.  Multicast packets are discarded until the MAG has
   completed the following steps.

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

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

   As soon as the MN's uplink is associated with the corresponding MLD
   proxy instance, multicast packets are forwarded again to the LMA and
   eventually to receivers within the PMIP domain (see the call flow in
   Figure 2).  In this way, multicast source mobility is transparently
   enabled in PMIPv6 domains that deploy the base scenario for

Schmidt, et al.        Expires September 26, 2011               [Page 5]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

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

   Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP

   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].
   IPv4 multicast is handled by an IGMP proxy function at the MAG in an
   analogous way.

   Following these deployment steps, multicast traffic distribution
   transparently inter-operates with PMIPv6.  It is worth noting that a
   MN - while being attached to the same MAG as the mobile source, but
   associated with a different LMA cannot receive multicast traffic on a
   shortest path.  Instead, multicast streams flow up to the LMA of the
   mobile source, are transferred to the LMA of the mobile listener and
   tunneled downwards to the MAG again (see Appendix A for further

Schmidt, et al.        Expires September 26, 2011               [Page 6]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

4.  Source Mobility Details

   Incorporating multicast source mobility in PMIPv6 requires to deploy
   general multicast functions at PMIPv6 routers and to define their
   interaction with the PMIPv6 protocol in the following way.

4.1.  Operations of the Mobile Node

   A Mobile Node willing to send multicast data will proceed as if
   attached to the fixed Internet.  No specific mobility or other
   multicast related functionalities are required at the MN.

4.2.  Operations of the Mobile Access Gateway

   A Mobile Access Gateway is required to have MLD proxy instances
   deployed corresponding to each LMA, taking the corresponding tunnel
   as its unique upstream link, cf.,
   [I-D.ietf-multimob-pmipv6-base-solution].  On the arrival of a MN,
   the MAG decides on the mapping of downstream links to a proxy
   instance and the upstream link to the LMA based on the regular
   Binding Update List as maintained by PMIPv6 standard operations.
   When multicast data is received from the MN, the MAG MUST identify
   the corresponding proxy instance from the incoming interface and
   forwards multicast data upstream according to [RFC4605].

   The MAG MAY apply special admission control to enable multicast data
   transition from a MN.  It is advisable to take special care that MLD
   proxy implementations do not redistribute multicast data to
   downstream interfaces without appropriate subscriptions in place.

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 upstream for the
   corresponding MAG.  It will manage and maintain a multicast
   forwarding information base for all group traffic arriving from its
   mobile sources.  It SHOULD participate in multicast routing functions
   that enable traffic redistribution to all adjacent LMAs within the
   PMIPv6 domain and thereby ensure a continuous receptivity while the
   source is in motion.

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 September 26, 2011               [Page 7]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

   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.

   A particular note is worth giving the scenario of [RFC5845] in which
   overlapping private address spaces of different operators can be
   hosted in a PMIP domain by using GRE encapsulation with key
   identification.  This scenario implies that unicast communication in
   the MAG-LMA tunnel can be individually identified per MN by the GRE
   keys.  This scenario still does not impose any special treatment of
   multicast communication for the following reasons.

   MLD/IGMP signaling between MNs and the MAG is on point-to-point links
   (identical to unicast).  Aggregated MLD/IGMP signaling between the
   MAG proxy instance and the LMA remains link-local between the routers
   and independent of any individual MN.  So the MAG-proxy and the LMA
   SHOULD not use GRE key identifiers, but plain GRE encapsulation to
   exchange MLD queries and reports.  Similarly, multicast traffic sent
   from an LMA to MAGs proceeds as router-to-router forwarding according
   to the multicast forwarding information base (MFIB) of the LMA and
   independent of MN's unicast addresses, while the MAG proxy instance
   distributes multicast data down the point-to-point links (interfaces)
   according to its own MFIB, independent of MN's IP addresses.

   It remains an open issue how communication proceeds in a multi-
   operator scenario, i.e., from which network the LMA pulls multicast
   traffic.  This could be any mobility Operator itself, or a third
   party.  However, this backbone routing in general is out of scope of
   the document, and most likely a matter of contracts.

4.5.  Efficiency of the Distribution System

   In the following efficiency-related issues are enumerated.

Schmidt, et al.        Expires September 26, 2011               [Page 8]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

   Multicast receiption at LMA  In the current deployment scenario, the
      LMA will receive all multicast traffic originating from its
      associated MNs.  There is no mechanism to suppress upstream
      forwarding in the absence of receivers.

   MNs on the same MAG using different LMAs  For a mobile receiver and a
      source that use different LMAs, the traffic has to go up to one
      LMA, cross over to the other LMA, and then be tunneled back to the
      same MAG, causing redundant flows in the access network and at the

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.

   Multicast traffic distribution can be simplified in these scenarios.
   A single proxy instance at MAGs with up-link into the multicast cloud
   will serve as a first hop gateway into the multicast routing domain
   and avoid traffic duplication or detour routing.  However, mobility
   of the multicast source in this scenario will require some multicast
   routing protocols to rebuild distribution trees.  This can cause
   significant service disruptions or delays (see [RFC5757] for further

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

Schmidt, et al.        Expires September 26, 2011               [Page 9]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

   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.

7.  Acknowledgements

   The authors would like to thank (in alphabetical order) Jouni
   Korhonen and Stig Venaas 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.

8.  References

8.1.  Normative References

              Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in PMIPv6
              Domains", draft-ietf-multimob-pmipv6-base-solution-07
              (work in progress), December 2010.

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

Schmidt, et al.        Expires September 26, 2011              [Page 10]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

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

8.2.  Informative References

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

   [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "Generic Routing Encapsulation (GRE) Key Option for Proxy
              Mobile IPv6", RFC 5845, June 2010.

Appendix A.  Evaluation of Traffic Flows


Appendix B.  Change Log

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 September 26, 2011              [Page 11]

Internet-Draft         Multicast Senders in PMIPv6            March 2011

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

   Email: mw@link-lab.net

   Muhamma Omer Farooq
   HAW Hamburg
   Berliner Tor 7
   Hamburg  20099

   Email: omer.farooq@ymail.com

Schmidt, et al.        Expires September 26, 2011              [Page 12]