MULTIMOB Working Group D. von Hugo Internet-Draft Deutsche Telekom Laboratories Intended status: Informational H. Asaeda Expires: August 26, 2010 Keio University B. Sarikaya Huawei USA P. Seite France Telecom - Orange February 22, 2010 Evaluation of further issues on Multicast Mobility: Potential future work for WG MultiMob Abstract The WG MultiMob aims at defining a basic mobile multicast solution leveraging on network localized mobility management, i.e. Proxy Mobile IPv6 protocol. The solution would be basically based on multicast group management, i.e. IGMP/MLD, proxying at the access gateway. If such a basic solution is essential from an operational point of view, challenges with efficient resource utilization and user perceived service quality still persist. These issues may prevent large scale deployments of mobile multicast applications. This document attempts to identify topics for future extension of work such as modifying base PMIPv6 and MLD/IGMP for optimal multicast support, extending to and modifying of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of Handover optimization, multiple flows with multihoming and any other different issues. 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 von Hugo, et al. Expires August 26, 2010 [Page 1] Internet-Draft Future Work for MultiMob WG February 2010 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 August 26, 2010. Copyright Notice Copyright (c) 2010 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 BSD License. von Hugo, et al. Expires August 26, 2010 [Page 2] Internet-Draft Future Work for MultiMob WG February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. IGMP/MLD Proxy Architecture . . . . . . . . . . . . . . . . . 7 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 8 4.1. Modification of base PMIPv6 for optimal multicast support . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Modification of MLD/IGMP for optimal multicast support . . 8 4.3. Extensions to and modifying of MIPv4/v6 and DSMIPv6 . . . 9 4.4. Consideration of sender (source) mobility . . . . . . . . 9 4.5. Consideration of Handover Optimization . . . . . . . . . . 9 4.6. Support of multiple flows . . . . . . . . . . . . . . . . 10 4.7. Support of multi-hop transmission . . . . . . . . . . . . 10 4.8. Mobility agnosticity . . . . . . . . . . . . . . . . . . . 10 4.9. Local routing . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements on Solutions . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 von Hugo, et al. Expires August 26, 2010 [Page 3] Internet-Draft Future Work for MultiMob WG February 2010 1. Introduction Recently chartered WG MultiMob focuses on documentation of proper configuration and usage of existing (specified standard) protocols within both mobility and multicast related areas to enable and support mobility for multicast services and vice versa. Although the final recommendation is not yet available it is expected that such a solution following the remote subscription aproach will not be resource efficient nor grant the service quality expected by the end user. Such a solution would resolve the problem to ensure multicast reception in PMIPv6-enabled [RFC5213] networks without appropriate multicast support. However it would neither automatically minimize multicast forwarding delay to provide seamless and fast handovers for real-time services nor minimize packet loss and reordering that result from multicast handover management as stated in [I-D.irtf-mobopts-mmcastv6-ps]. Also Route Optimization is out of scope of the basic solution - an issue for reducing amount of transport resource usage and transmission delay. Thus possible enhancements and issues for solutions beyond a basic solution need to be described to enable current PMIPv6 protocols to fully support efficient mobile multicast services. Such extensions may include protocol modifications for both mobility and multicast related protocols to achieve optimizations for resource efficient and performance increasing multimob approaches. The document includes the case of mobile multicast senders using Any Source Multicast (ASM) and Source Specific Multicast (SSM) [RFC4607]. Figure 1 illustrates the key components of the foreseen basic Multimob solution. The extended multicast mobility scenario, leading to above issues, is sketched in Figure 2. von Hugo, et al. Expires August 26, 2010 [Page 4] Internet-Draft Future Work for MultiMob WG February 2010 +------+ +------+ | MN | =====> | MN | +------+ +------+ | . | . +--------+ +--------+ | MAG 1 | | MAG 2 | |IGMP/MLD| |IGMP/MLD| |Proxy | |Proxy | +--------+ +--------+ | | *** *** *** *** * ** ** ** * * * * Internet Subnet * * * * ** ** ** * *** *** *** *** | | +-------+ +-------+ | LMA 1 | | LMA 2 | +-------+ +-------+ | | *** *** *** *** * ** ** ** * * * * Fixed Internet * * * * ** ** ** * *** *** *** *** | +------+ | CN | +------+ Figure 1: MultiMob Scenario for chartered PMIP6 issue von Hugo, et al. Expires August 26, 2010 [Page 5] Internet-Draft Future Work for MultiMob WG February 2010 +------+ +------+ +------+ | MN | =====> | MN | ====> | MN | +------+ +------+ +------+ | . . | . . | . . +-------+ +-------+ +-------+ +-------+ | MAG 1 | | MAG 2 | | AR 1 | | AR 2 | |IGMP/MLD| |IGMP/MLD| |IGMP/MLD| |IGMP/MLD| |Proxy | |Proxy | |Proxy | |Proxy | +-------+ +-------+ +-------+ +-------+ \ / | | *** *** *** *** *** *** *** *** * ** *** ** * * ** *** ** * * * * * * Internet Subnet 1 * * Internet Subnet 2 * * * * * * ** *** ** * * ** *** ** * *** *** *** *** *** *** *** *** | | | +-------+ +-------+ | | LMA 1 | | LMA 2 | / +-------+ +-------+ / \ | / *** *** *** *** / *** *** *** *** * ** ** ** * / * ** *** ** * * * * * * Fixed Internet * * Internet Subnet 3 * * *_____* * * ** ** ** * * ** *** ** * *** *** *** *** *** .*** *** *** | . +-------+ +-------+ | CN | ====> | CN | +-------+ +-------+ Figure 2: MultiMob scenario for extended MultiMob issues In summary additional to a 'Single hop, link, flow' Proxy MIP mobility for listening MNs (scenario shown in Figure 1), the future work will focus on optimization of performances and extend the scenario to 'Multi-hop, -homed, -flow' client mobility, thus also including optimizations for MIPv6 [RFC3775]. The following is the proposed work items to be covered in the MultiMob continuation: (see Figure 2). o Modification of base PMIPv6 and MLD/IGMP for optimal multicast support. von Hugo, et al. Expires August 26, 2010 [Page 6] Internet-Draft Future Work for MultiMob WG February 2010 o Extension to and modifying of MIPv4/v6 and DSMIP using IGMP/MLD Proxy and the Foreign Agent/ Access Router. o Consideration of sender (source) mobility. o Consideration of Handover optimization. o Support of multiple flows on multihomed mobile nodes. o Multi-hop transmission. o Fixed mobile convergence support. o Consideration of earlier versions of IGMP and MLD in the solutions. o Consideration of locally available multicast without remote subscription. o Improve host mobility agnoticity o Routing optimization 2. Terminology 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 BCP 14 [RFC2119]. This document uses the terminology defined in [RFC3775], [RFC3376], [RFC3810], [RFC5213], [I-D.irtf-mobopts-mmcastv6-ps]. 3. IGMP/MLD Proxy Architecture Multimob basic solution is based on IGMPv3/MLDv2 Proxy support at the mobile access gateway (MAG) of Proxy Mobile IPv6 as shown in Figure 1. IGMPv3/MLDv2 proxy keeps multicast state on the subscriptions of the mobile nodes and only an aggregate state is kept at the local mobility anchor (LMA). When LMA receives multicast data it can forward it to the MAG without duplication because MAG takes of the packet duplication. This leads to solving the avalanche problem. By keeping multicast state locally, IGMPv3/MLDv2 Proxy introduces mobility related problems such as possible packet loss when a mobile node does a handover to another MAG and its multicast state is not modified fast enough at the LMA. von Hugo, et al. Expires August 26, 2010 [Page 7] Internet-Draft Future Work for MultiMob WG February 2010 IGMPv3/MLDv2 introduces tunnel convergence problem which occurs when a given MAG serves MNs that belong to different LMAs and MNs subscribe to the same multicast group. In that case MNs receive duplicate multicast data forwarded from more than one LMA. It can be foreseen that mobile access gateways will serve both mobile and fixed terminals concurrently. The tuning of multicast-related protocol parameters based on the terminal characteristics is needed. Parameters only applicable to mobile users need to be distinguished from the parameters applicable to fixed users. It should be also possible to distinguish between slow and fast movement and handover frequency to form corresponding tunnels for mobile users. Based on the above observations we will state the problems next and then list the requirements on possible solutions. 4. Problem Description The general issues of multicast mobility are extensively discussed and described in [I-D.irtf-mobopts-mmcastv6-ps]. To reduce the complexity of the pleothera of requirements listed in [I-D.irtf-mobopts-mmcastv6-ps] and in [I-D.deng-multimob-pmip6-requirement] this document tries to propose lightweight solutions for multicast mobility which allow for easy deployment within realistic scenarios and architectures, and which build directly on basic MultiMob solution which is based on IGMP/MLD Proxy at the mobile access gateway. 4.1. Modification of base PMIPv6 for optimal multicast support There would be potential solutions proposed for multicast optimization for PMIPv6 such as [I-D.asaeda-multimob-pmip6-extension], agent-based reling on additional encapsulation, and a hybrid approach. Since other functional enhancements of PMIPv6 are currently under way in NETEXT WG, both the impact of new features on Mobile Multicast as well as a potential Multicast-initiated proposal for PMIPv6 modification have to be considered in a continuous exchange process between both WGs. 4.2. Modification of MLD/IGMP for optimal multicast support Potential approaches for enhancement of group management as specified e.g. by MLDv2 [RFC3810] include default timer value modification, specific query message introduction, and standard (query) reaction suppression, beside introducing multicast router attendance control in terms of e.g. specification of a Listener Hold message as proposed in [I-D.asaeda-multimob-igmp-mld-mobility-extensions]. von Hugo, et al. Expires August 26, 2010 [Page 8] Internet-Draft Future Work for MultiMob WG February 2010 4.3. Extensions to and modifying of MIPv4/v6 and DSMIPv6 Operational interest clearly focusses on network-based mobility approaches, but in the framework of multiple technologies serving a mobile user there will be demand to include also other non-PMIPv6 based specifications. This section addresses the compatibility of PMIPv6-based multicast solutions with MIPv6 [RFC3775], i.e. handover between network-based and client mobility support as well as interoperabiliy between IPv4 and IPv6 mechanisms (e.g. FA handling, IPv4/v4-tunneling) with mobile multicast. DSMIPv6 [RFC5555] has a basic support for multicast which is based on remote subscription and bi-directional tunneling, but does not specify how to achieve group management and data forwarding unless the mobility anchor (i.e. Home Agent) is a fully functional IPv6 multicast router. 4.4. Consideration of sender (source) mobility We see future demand for such a feature in terms of applications such as 'Push to talk over wireless technologies' (packet based point-to- multipoint (P2MP) group voice) like 3GPP or WiMAX, 'Multi-party mobile audio/video conferencing', 'mobile multi-player gaming' etc, where due to real-time constraints a solution based on a central server might add too much delay. According to [I-D.irtf-mobopts-mmcastv6-ps] generally (i.e. for ASM) a mobile multicast source must provide address transparency at Routing - for Reverse Path Forwarding (RPF) checks - as well as on Transport layer - to coincide with packet source address at receiver side. Further issues are temporal handover constraints, possible packet loss and multicast scoping, and enhanced complexity of inter- domain multicasting. Additional challenges arise for SSM (Source Specific Multicast) due to the principle of multicast decoupling between sender and receivers. 4.5. Consideration of Handover Optimization This work item would deal with reduction of delay, packet loss, and packet reordering effort. In case these degradations are induced due to terminal movement it will be discussed how to make use of MIPSHOP approaches such as HMIP, FMIP etc. (predominantly focusing on intra- technology handover). Reusing multicast specific protocol extensions exceeding IGMP/MLD modifications shall further decrease the impact of group management induced delay. von Hugo, et al. Expires August 26, 2010 [Page 9] Internet-Draft Future Work for MultiMob WG February 2010 4.6. Support of multiple flows Considering a per-flow handover for parallel multicast sessions allows to treat different services requirements and labels of flows independently. This would improve user perceived service performance as well as allow for more efficient usage of network resources because of the enabled flexibility. 4.7. Support of multi-hop transmission This scenario adds another level of complexity to Multicast Mobility and is of interest e.g. in nested NEMO (Network Mobility, [RFC3963]) scenarios, for MANETs (Mobile Adhoc NETworks) where also mechanisms for multicast forwarding are dicussed, e.g. in terms of Simplified Multicast Forwarding (SMF, [I-D.ietf-manet-smf]) or for infrastructure mesh networks. Here, more than the mobile and temporary character of connections, it is the existence of (more or less stable) multiple hops and multiple paths which is stressed. 4.8. Mobility agnosticity In the idea of network based mobility management, the mobile node should remain agnostic of the multicast mobility management when roaming. In particular, the node MUST not be required to re- subscribe to multicast group(s) after handoff. If the mobile node does no re-resubscribes, the new MAG must be able to retrieve the multicast states corresponding to the moving node. 4.9. Local routing Short term deployment focuses on architecture where multicast traffic is provided via the home network. However, depending on the network topology, namely the location of the content delivery network, the LMA may not be on the optimal multicast service delivery path. This enables mobile nodes to access locally available multicast services such as local channels. Figure 3 illustrates the use-case for local routing. von Hugo, et al. Expires August 26, 2010 [Page 10] Internet-Draft Future Work for MultiMob WG February 2010 +----+ |LMA | +----+ | | *** *** *** *** * ** ** ** * * * +-------------+ * Local Routing * _____ | Content | * * | Delivery | | Network | * ** ** ** * +-------------+ *** *** *** *** || || +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | | MN1 MN2 MN3 Figure 3: local Multicast routing In such a case, the MAG should act as a multicast router to construct the optimal multicast delivery path. If the MAG also supports MLD proxy function issue raises up on the dual mode behaviour. In such a case, a pragmatic approach could be to leverage only on multicast routing at the MAG in the PMIP domain. Whatever is the MAG operation mode, the multicast state is locally kept at the access gateway, so unknown from the mobility anchor. In other words, the multicast service is independent from the mobility service that the mobile node is receiving from the network in the form of PMIPv6 or DSMIPv6. However, handover support is still desirable but cannot be provided by the mobility anchor (i.e. HA or LMA). In such a case mobility support for locally available multicast should be provided by extending multicast protocols of IGMP or MLD. 5. Requirements on Solutions This section tries to identify requirements from the issues discussed in previous section. von Hugo, et al. Expires August 26, 2010 [Page 11] Internet-Draft Future Work for MultiMob WG February 2010 o Seamless handover (low latency and during the handover). o Similar packet loss to unicast service. o Multiple LMAs architecture. o Agnostic mobile host re-subscription. So, MAGs must be able to retrieve multicast contexts of the mobile nodes. o Solution address IPv6, IPv4 only and dual stack nodes. o Supports sender (source) mobility. o Optimal local routing. o To be completed... 6. Security Considerations This draft introduces no additional messages. Compared to [RFC3376], [RFC3810], and [RFC3775][RFC5213] there is no additional threats to be introduced. 7. IANA Considerations None. 8. Acknowledgements The authors would thank all active mebers of MultiMob WG, especially (in no specific order) Gorry Fairhurst, Jouni Korhonen, Thomas Schmidt, Suresh Krishnan and Matthias Waehlisch for providing continuous support and helpful comments. 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. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [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. von Hugo, et al. Expires August 26, 2010 [Page 12] Internet-Draft Future Work for MultiMob WG February 2010 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 9.2. Informative References [23246] "3GPP TS 23.246 V8.2.0, Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 8).", 2008. [23401] "3GPP TS 23.401 V8.2.0, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8).", 2008. [23402] "3GPP TS 23.402 V8.4.1, Architecture enhancements for non- 3GPP accesses (Release 8).", 2009. [I-D.asaeda-multimob-igmp-mld-mobility-extensions] Asaeda, H. and T. Schmidt, "IGMP and MLD Hold and Release Extensions for Mobility", draft-asaeda-multimob-igmp-mld-mobility-extensions-03 (work in progress), July 2009. [I-D.asaeda-multimob-igmp-mld-optimization] Asaeda, H., "IGMP and MLD Optimization for Mobile Hosts and Routers", draft-asaeda-multimob-igmp-mld-optimization-01 (work in progress), October 2009. [I-D.asaeda-multimob-pmip6-extension] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for Multicast", draft-asaeda-multimob-pmip6-extension-02 (work in progress), July 2009. [I-D.deng-multimob-pmip6-requirement] 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. von Hugo, et al. Expires August 26, 2010 [Page 13] Internet-Draft Future Work for MultiMob WG February 2010 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] Madanapalli, S., Park, S., Chakrabarti, S., and G. Montenegro, "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06 (work in progress), June 2009. [I-D.ietf-manet-smf] Macker, J. and S. Team, "Simplified Multicast Forwarding", draft-ietf-manet-smf-09 (work in progress), July 2009. [I-D.irtf-mobopts-mmcastv6-ps] Fairhurst, G., Schmidt, T., and M. Waehlisch, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-09 (work in progress), October 2009. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. Authors' Addresses Dirk von Hugo Deutsche Telekom Laboratories Deutsche-Telekom-Allee 7 64295 Darmstadt, Germany Email: dirk.von-hugo@telekom.de Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Email: asaeda@wide.ad.jp URI: http://www.sfc.wide.ad.jp/~asaeda/ von Hugo, et al. Expires August 26, 2010 [Page 14] Internet-Draft Future Work for MultiMob WG February 2010 Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Email: sarikaya@ieee.org Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel BP 91226 Cesson-Sevigne, BZH 35512 France Email: pierrick.seite@orange-ftgroup.com von Hugo, et al. Expires August 26, 2010 [Page 15]