MULTIMOB Group T C. Schmidt, Ed.
Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao
Expires: May 17, 2012 H. Zhang
Beijing Jiaotong University
M. Waehlisch
link-lab & FU Berlin
November 14, 2011

Mobile Multicast Sender Support in PMIPv6 Domains
draft-schmidt-multimob-pmipv6-source-00

Abstract

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, or by additional route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario, as well as in settings of further optimization. Mobile sources remain agnostic of multicast mobility operations.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [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 May 17, 2012.

Copyright Notice

Copyright (c) 2011 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 (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

Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) [RFC6275] 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, which only operates according to the base specifications of [RFC5213], cannot participate in multicast communication, as MAGs will discard group 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 [RFC6224]. 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.

Alternate solutions leverage performance optimization by providing multicast routing at the access routers directly, or by other dedicated schemes.

This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains as it is provided by the base deployment scenario [RFC6224], as well as optimizations throughout the access network infrastructure to efficiently solve the source mobility problem as discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic of multicast mobility operations.

2. Terminology

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

3. Base Solution for Source Mobility: Overview

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

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

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 applications, 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 [RFC6224]. In this set-up, the MLD 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 arriving at the MAG are discarded until the MAG has completed the following steps.

Figure 2). In this way, multicast source mobility is transparently enabled in PMIPv6 domains that deploy the base scenario for multicast.

  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

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 Proxy Configuration >  |
|                |                |               |                |
|                |                |   MLD Query   |                |
|                |                |<--------------+                |
|                |                |  Mcast Data   |                |
|                |                +-------------->|                |
|                |                |               | Mcast Data     |   
|                |                |               +===============>|
|                |                |               |                |
|                |   Mcast Data   |               |                |
|                |<================================================+
|  Mcast Data    |                |               |                |
|<---------------+                |               |                |
|                |                |               |                |

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 Appendix A for further considerations).

4. Base Solution for 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., [RFC6224]. 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.3.1. Local Mobility Anchors Operating PIM

Local Mobility Anchors that operate the PIM routing protocol [RFC4601] will require sources to be directly connected for sending PIM registers to the RP. This does not hold in a PMIPv6 domain, as MAGs are routers intermediate to MN and the LMA. In this sense, MNs are multicast sources external to the PIM-SM domain.

To cure this defect common to all set-ups of subsidiary domains not running PIM, the LMA should act as a PIM Border Router and activate the Border-bit. In this case, the DirectlyConnected(S) is treated as being TRUE for mobile sources and the PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel interface from MAG to LMA is considered as not part of the PIM-SM component of the LMA (see A.1 of [RFC4601] ).

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

Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). 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 in multicast communication (including MLD queries and reports). Multicast traffic sent upstream and downstream of MAG-to-LMA tunnels proceeds as router-to-router forwarding according to the multicast forwarding information base (MFIB) of the MAG or LMA and independent of MN's unicast addresses, while the MAG proxy instance re-distributes multicast data down the point-to-point links (interfaces) according to its own MFIB, independent of MN's IP addresses.

4.5. Efficiency of the Distribution System

In the following efficiency-related issues are enumerated.

Multicast reception 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 MAG.

5. Multicast Routing Throughout the Access Network

There are deployment scenarios, where multicast services are available throughout the access network independent of the PMIPv6 infrastructure. Direct multicast access can be supported by[RFC5757] for further aspects). Deployment details are specific to the multicast routing protocol in use, in the following described for common protocols.

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. Multicast routing functions at MAGs will seemlessly embed PMIP mobility gateways within a multicast cloud. 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

5.1. PIM-SM

TODO

5.2. BIDIR PIM

TODO

6. Extended Source Mobility Schemes in PMIPv6

In this section, specific optimization approaches to multicast source mobility are introduced.

6.1. Multiple Upstream Interface Proxy

Although multicast communication can be enabled in PMIPv6 domains by deploying MLD Proxy functions at MAG, some disadvantages still exist. Firstly, for a proxy device performing IGMP/MLD-based forwarding has a single upstream interface and one or more downstream interfaces as described in RFC4605, there should be many MLD Proxy functions deployed at one MAG, which is complicated and then is difficult for implementation and management. And then when the multicast packets arrive at the MAG running multiple parallel MLD proxy functions, there may be confusions for the data if there is no extra processing or filtering scheme at the MAG. In addition, the route optimization issue is still up in the air, that is, for a mobile receiver and a source on the same MAG using 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 MAG. Therefore, the MLD Proxy function should be extended to accommodate the PMIPv6 protocol. As same as described in [RFC6224] and this document (s. abobe), the MLD proxy functions are deployed at the MAG, while only one MLD Proxy function is required to run at the MAG and multiple upstream interfaces can be set for the MLD Proxy instance, which is called Multi-Upstream Interfaces MLD Proxy (MUIMP).

.... TODO details.

7. IANA Considerations

TODO.

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

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

9. Acknowledgements

The authors would like to thank (in alphabetical order) Muhamma Omer Farooq, Jouni Korhonen, He-Wu Li, Stig Venaas Li-Li Wang, Qian Wu, Zhi-Wei Yan for advice, help and reviews of the document.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[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.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC6224] Schmidt, T., Waehlisch, M. and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

10.2. Informative References

[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.
[RFC2236] Fenner, W.C., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.

Appendix A. Evaluation of Traffic Flows

TODO

Appendix B. Change Log

The following changes have been made from version draft-schmidt-multimob-pmipv6-source-00:

Authors' Addresses

Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg, 20099 Germany EMail: schmidt@informatik.haw-hamburg.de URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Shuai Gao Beijing Jiaotong University Beijing, China EMail: shgao@bjtu.edu.cn
Hong-Ke Zhang Beijing Jiaotong University Beijing, China EMail: hkzhang@bjtu.edu.cn
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin, 10318 Germany EMail: mw@link-lab.net