A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains
draft-schmidt-multimob-pmipv6-mcast-deployment-00

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

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 http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

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.

Abstract

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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

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

1.  Introduction

Proxy Mobile IPv6 (PMIPv6) [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) extends Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.), [RFC2710] (Deering, S., Fenner, W., and B. Haberman, “Multicast Listener Discovery (MLD) for IPv6,” October 1999.) requires a dedicated treatment, see [I‑D.deng‑multimob‑pmip6‑requirement] (Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, “Multicast Support Requirements for Proxy Mobile IPv6,” July 2009.).

Multicast routing functions need a careful placement within the PMIPv6 domain to augment unicast transmission with group communication services. [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) 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 support.

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] (Fairhurst, G., Schmidt, T., and M. Waehlisch, “Multicast Mobility in MIPv6: Problem Statement and Brief Survey,” October 2009.), 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.).

2.  Terminology

This document uses the terminology as defined for the mobility protocols [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), as well as the multicast edge related protocols [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) and [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"),” August 2006.).

The reference scenario for multicast deployment in Proxy Mobile IPv6 domains is illustrated in Figure 1 (Reference Network for Multicast Deployment in PMIPv6).

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

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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.), or [RFC2710] (Deering, S., Fenner, W., and B. Haberman, “Multicast Listener Discovery (MLD) for IPv6,” October 1999.). 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] (Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” August 2006.) 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.)). 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 LMA.

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 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.)). 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.)).

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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.).

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] (Wakikawa, R. and S. Gundavelli, “IPv4 Support for Proxy Mobile IPv6,” February 2010.). Such mobile node will use IGMPv3 [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) 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 MNs.

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] (Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” August 2006.) 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.)).

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 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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.).

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:

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

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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.)) 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 RFC.

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] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) and [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) 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 document.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses