MULTIMOB Working Group D. von Hugo Internet-Draft Deutsche Telekom Laboratories Intended status: Informational Hitoshi Asaeda Expires: September 7, 2011 Keio University March 7, 2011 Comparison of Multicast Mobility Route Optimization Abstract The Multimob WG has defined a basic mobile multicast solution leveraging on network localized mobility management, i.e. Proxy Mobile IPv6 protocol. The basic solution incorporates multicast aware routers co-located with the mobility anchor and a proxy functionality for group management, i.e. IGMP/MLD, at the access gateway. Although such a basic solution solves the issue from an operational point of view, challenges with respect to optimization, e.g. efficient resource utilization, still remain. This document attempts to evaluate proposed solutions for the chartered work item of "PMIPv6 routing optimizations to avoid tunnel convergence problem". A corresponding deployment specific extension would cover dynamic and/or automatic tunnel configuration and a direct or local routing approach. 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/1id-abstracts.html. von Hugo, et al. Expires September 7, 2011 [Page 1] Internet-Draft MultiMob Route Optimization Comparison March 2011 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 7, 2011. Copyright and License 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. von Hugo, et al. Expires September 7, 2011 [Page 2] Internet-Draft MultiMob Route Optimization Comparison March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Route Optimized MultiMob Architecture. . . . . . . . . . . . . 4 4. Proposed Solutions for Optimized or local Routing. . . . . . . 6 5. Adaptation of MBoneD approach. . . . . . . . . . . . . . . . . 8 6. Requirements on Solutions . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 von Hugo, et al. Expires September 7, 2011 [Page 3] Internet-Draft MultiMob Route Optimization Comparison March 2011 1. Introduction The Multimob WG has focuses on documentation of proper configuration and usage of existing (specified standard) protocols with both mobility and multicast related areas to enable and support mobility for multicast services and vice versa. The current 'RFC to be' WG document [I-D.ietf-multimob-pmipv6-base-solution] describes how to deploy multicast listener functionality in PMIPv6 [RFC5213] domains according to basic requirements i.e. without modifying mobility and multicast protocol standards. However beside aggregation of multiple (downstream) multicast subscriptions at the MAG no specific optimizations and efficiency improvements of multicast routing for network-based mobility are addressed. Such an operation which considers more efficient resource usage at network and nodes may require actual modification and extension of the base protocol. This draft attempts to compare proposed approaches to include Route Optimization and direct local routing support in the basic solution and the application of an existing approach from another WG - which can help to reduce the amount of transport resource usage and transmission delay. 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 RFC 2119 [RFC2119]. This document uses the terminology defined in [RFC3775], [RFC3376], [RFC3810], [RFC5213], [RFC5757]. 3. Route Optimized MultiMob Architecture Potential extensions to multimob basic solution would mainly rely on IGMPv3/MLDv2 Proxy [RFC4605] support at the mobile access gateway (MAG) as proposed in the basic Multimob solution [I-D.ietf-multimob-pmipv6-base-solution]. Thus at the MAG of Proxy Mobile IPv6 an IGMPv3/MLDv2 Proxy functionality keeps multicast state on the subscriptions of the mobile nodes (MNs). The local von Hugo, et al. Expires September 7, 2011 [Page 4] Internet-Draft MultiMob Route Optimization Comparison March 2011 mobility anchor (LMA) on the other hand keeps an aggregate state and thus when receiving multicast data from the outside world, which may be either native multicast enabled or not, LMA can forward it to the MAG without duplication because MAG takes care of the packet duplication before delivering to the different subscribers. This leads to solving the avalanche problem. However, 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. The architecture for route optimization and direct routing is shown in Figure 1. +----+ +----+ |LMA1| |LMA2|\ +----+ +----+ \ | | \ | | \ *** *** *** *** \ * ** ** ** * \ * * +-------------+ * Local Routing * | Content | * *....| Delivery | * * | Network | * ** ** *** +-------------+ *** *** *** || || +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | | MN1 MN2 MN3 Figure 1: Optimized and local Multicast routing The basic approach of multicast traffic forwarding via the MAG-LMA tunnel (i.e. in case that a multicast router (MR) is co-located in LMA as defined in the base solution von Hugo, et al. Expires September 4, 2011 [Page 5] Internet-Draft MultiMob Route Optimization Comparison March 2011 [I-D.ietf-multimob-pmipv6-base-solution]) may introduce in specific situations a tunnel convergence problem and lead to waste of network bandwidth usage. A Multicast Router as assumed here would support native multicast operation as e.g. defined in [RFC4607]. 4. Proposed Solutions for Optimized or Local Routing Currently discussed aspects of multicast optimization for PMIPv6 include introduction of a bi-directional Multicast Tunnel (M-Tunnel) between LMA and MAG as described in [I-D.asaeda-multimob-pmip6-extension]. Separation of mobility entity LMA and multicast router allows MAGs to receive multicast packets directly and also reduces LMA complexity. Both mobility entities MAG and LMA may be operated as MLD proxy or multicast router. For a PMIPv6 domain the establishment of a dedicated multicast tunnel is proposed which may either be dynamically set up and released or be pre-configured in a static manner. Contrary to the MAG-LMA tunnel as defined in PMIPv6 [RFC5213] the static M-Tunnel is not set up per MN but once for all Multicast traffic between a MAG operated as MLD proxy. Alternatively the MAG may be operating as multicast router (e.g. PIM-SM router) and thus be able to directly join an existing multicast tree (within the PMIPv6 domain) and thus provide direct or local routing without including the LMA. The LMA however is kept informed of mutlicast subscriptions to be ready to forward data e.g. via the statically pre-configured M-tunnel between MAG and LMA. Thus in case of handover additional delay or packet loss is prevented which otherwise might occur before the new MAG has established direct routing of multicast data . The protocol defines a Proxy Binding Update with multicast extension (PBU-M) (new C flag) for the Proxy MLD enabled MAG to request the LMA to forward multicast data. For handover the Context Transfer Protocol (CXTP) [RFC4067] or an MN profile may be used and a Multicast Context Transfer Data (M-CTD) message is defined to be exchanged between MAGs. Whereas MAG is envisaged to act either as a multicast router for direct local routing or as an MLD proxy forwarding the multicast management messages to the corresponding LMA, the LMA can either be operated also as an MLD proxy or as a multicast router according to the MAG's cofiguration. von Hugo, et al. Expires September 4, 2011 [Page 6] Internet-Draft Route Optimization for MultiMob WG March 2011 Altogether the approach [I-D.asaeda-multimob-pmip6-extension] supports 3 different scenarios: (1) MR@MAG and MR@LMA, (2) MLD-Proxy@MAG and MLD-Proxy@LMA, (3) MLD-Proxy@MAG and MR@LMA, in terms of functionalities at MAG and LMA, by proposing protocol extensions for PMIPv6 (C-flag in PBU) and CXTP (M-CTD message), respectively. Another approach to introduce multicast traffic replication mechanisms is proposed in [I-D.zuniga-multimob-smspmip]. Here by introducing a Dedicated Multicast LMA (DM-LMA) as topological anchor point for multicast traffic protocol complexity is reduced in terms of time consuming tunnel set-up by definition of pre- or post- configured tunnels between LMA and MAG. This scheme to PMIPv6 domains uses dedicated LMAs for Unicast (U-LMA) and for Multicast (M-LMA) as specific topological anchor point for unicast and multicast traffic, respectively, while the MAG remains as an IGMP/MLD proxy. The solution is applied to different scenarios which are characterised by varying ratio of U-LMA:M-LMA and also introduces a hybrid H-LMA simultaneously transporting multicast service to an entire group of MNs within a PMIPv6 domain and unicast service to a subset of them. Thanks to separation of unicast and multicast traffic at LMA in specific scenarios a gradual network upgrade of a PMIPv6 domain to support multicast functionality and minimized replication of multicast packets may take place. The amount of replicated packets will be more limited using this aproach for increasing number of MAGs per LMA and MNs per MAG as compared to the basic solution. Required enhancements to the Proxy Mobile IPv6 [RFC5213] protocol to support the M-LMA architecture are an update of the Binding Update List in MAG to enable handling of more than one LMA (i.e. U-LMA and M-LMA) serving the mobile node, extension of a mobile node's policy profile information to store the IPv6 addresses of both the U-LMA and M-LMA, and additional capability of MAG procedures to be able to handle simultaneous attachment of a mobile node to both the U-LMA and M-LMA. Recently expired draft [I-D.sijeon-multimob-mms-pmip6] describes a direct or local routing approach applicable to a network topology where multicast content delivery source is located in the same von Hugo, et al. Expires September 7, 2011 [Page 7] Internet-Draft Route Optimization for MultiMob WG March 2011 network such that the optimal multicast service delivery path is not via LMA. The support of optimal local (direct) routing uses a direct connection between MLD proxy at MAG and a multicast router separated from LMA. By making no use of base multimob solution [I-D.ietf-multimob-pmipv6-base-solution] this solution proposes to save complexity. 5. Adaptation of AMT [I-D.ietf-mboned-auto-multicast] describes an approach of the MBONED (Multicast Backbone Deployment) WG which allows automatic multicast communication without explicit tunnels (AMT). This mechanism can be applied to isolated multicast-enabled sites or hosts, attached to a network without native multicast support - without need for any manual configuration. Communication between these sites and the backbone is established by AMT gateway and AMT relay - similar to MAG and LMA communication. The analogy between AMT and PMIP-based Multimob is shown in Figure 2. However, compared to the basic multimob solution and the proposed extensions summarized in sect. 4, the AMT approach does not introduce any further advantage: Either the required tunnel is already available via MAG-LMA cooperation or and an additional tunnel has to be set up which adds more complexity instead of simplifying things. The analogy to the Multimob WG is described in the following: Each MAG with multicast subscribing MNs attached behaves as an AMT Gateway which has already established via a three way handshake a tunnel to an AMT Relay or does so on subcription of a MN - similar to an M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extension]. A dedicated multicast LMA or a local MR with native multicast support behaves like an AMT Relay in that join messages are forwarded within the native Multicast environment and on the other hand received multicast traffic is subsequently forwarded via the AMT interface to the MAG/AMT Gateway. Such a dedicated multicast DM-LMA is proposed by [I-D.zuniga-multimob-smspmip]. von Hugo, et al. Expires September 4, 2011 [Page 8] Internet-Draft Route Optimization for MultiMob WG March 2011 Since between MAG and LMA already a security association may be already established according to RFC5213, the handshake mechanism may be not required. An AMT relay can also provide direct local routing of traffic to the requesting MAG independent of any LMA as proposed in [I-D.sijeon-multimob-mms-pmip6]. On the other hand, the situation may be different in client MIPv6 for which the AMT approach would add advantage. A MIPv6 enabled MN having the AMT gateway function implemented might result in a large functionality set on a usually small, power- and size limited MN and thus a reduced lite-AMT version would be a feasible approach. However, a generally more complex NEMO [RFC3963] Mobile Router should have the capability to host also the AMT Gateway functionality and serve a set of nodes (LFN, MNN,...) with multicast traffic so that the AMT approach [I-D.ietf-mboned-auto-multicast] may be appropriate for such NEMO MultiMob support. von Hugo, et al. Expires September 4, 2011 [Page 9] Internet-Draft Route Optimization for MultiMob WG March 2011 +---------------+ Internet +---------------+ | AMT Site | | Native MCast | | | | | | +------+----+ AMT +----+----+ AMT | | |AMT Gateway| Anycast |AMT Relay| Subnet | | | +-----+-+ Prefix +-+-----+ | Prefix | | | |AMT IF | <------------|AMT IF | |--------> | | | +-----+-+ +-+-----+ | | | +------+----+ +----+----+ | | | | | +---------------+ +---------------+ +---------------+ PMIPv6 domain +---------------+ | MNs' site | | Native MCast | | | | or | | +------+----+ +----+----+ Internet | | | MLD proxy | |MLD proxy| | | | @ +-----+-+ +-------+/MR| | | | MAG |PMIP IF| <------------|PMIP IF| @ |--------> | | | +-----+-+ +-+-----+LMA| | | +------+----+ +----+----+ | | | | | +---------------+ +---------------+ +---------------+ MIPv6 domain +---------------+ | NEMO site | | Native MCast | | | | or | | or +------+----+ +----+----+ Internet | | |AMT Gateway| |AMT Relay| | | MN |@ +-----+-+ +-------+ | | | | |AMT IF | ------------>|AMT IF | |--------> | | |MN |MIP6 IF| <------------|MIP6 IF| |<-------- | | |or +-----+-+ +-+-----+ | | | |NEMO MR | +----+----+ | | +------+----+ | | | | | | +---------------+ +---------------+ Figure 2: Analogy of AMT, PMIPv6, and MIPv6 entities von Hugo, et al. Expires September 4, 2011 [Page 10] Internet-Draft Route Optimization for MultiMob WG March 2011 6. Conformance with Multimob Requirements This section compares specific requirements for extensions for optimized routing in multicast mobility solutions discussed in the Multimob WG according to issues discussed in the original requirements draft [I-D.deng-multimob-pmip6-requirement] with the different approaches described above. With respect to the performance requirements: - PMIPv6 transmission SHOULD realize native multicast forwarding, and where applicable conserve network resources and utilize link layer multipoint distribution to avoid data redundancy. - Multicast mobility SHOULD minimize transport costs on the forwarding link, as well as any additional overhead on the multicast delivery path. the solutions attempt to fulfil the demand and partly also include the direct routing approach aiming also towards more resource and effort efficient transport. 7. Security Considerations This draft does not introduce additional messages but describes work in progress. Compared to [RFC3376], [RFC3810], [RFC3775], and [RFC5213] there have no additional threats been introduced. But as pointed out in [I-D.deng-multimob-pmip6-requirement] security is a very crucial issue in mobile multicast service such that a multitude of participating users is introduced in the PMIPv6 domain. Therefore it is required to provide extra security capabilities to protect mobile multicast networks from any malicious attempts caused by multicast security holes such as denial of service attacks. - The multicast service in PMIPv6 MUST NOT degrade the security protection of the basic PMIPv6 AAA mechanism. - Multicast system architecture MUST provide an admission control mechanism to regulate any multicast events. von Hugo, et al. Expires September 4, 2011 [Page 11] Internet-Draft MultiMob Route Optimization Comparison March 2011 - Multicast system architecture MUST be independent of adjacent domains such that it shall not affect the adjacent multicast domain without permission. - Multicast system architecture MUST provide a mechanism to check integrity of multicast sources prior to service delivery such that it prevents unauthorized source to distribute multicast content. 8. IANA Considerations Whereas this document does not explicitly introduce requests to IANA, some of the proposals referenced above (such as [I-D.asaeda-multimob-pmip6-extension]) specify flags for mobility messages or options. For details please see those documents. 9. Acknowledgements Discussion with and comments from members of the Multimob WG are gratefully acknowledged. 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. [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. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4067] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. von Hugo, et al. Expires September 4, 2011 [Page 12] Internet-Draft MultiMob Route Optimization Comparison 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. [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. [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", RFC 5757, June 2010. 10.2. Informative References [I-D.asaeda-multimob-pmip6-extension] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for Multicast", draft-asaeda-multimob-pmip6-extension-05 (work in progress), February 2011. [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. [I-D.ietf-mboned-auto-multicast] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Pusateri, "Automatic IP Multicast Without Explicit Tunnels (AMT)", draft-ietf-mboned-auto-multicast-10 (work in progress), March 2010 [I-D.ietf-multimob-pmipv6-base-solution] 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. von Hugo, et al. Expires September 4, 2011 [Page 13] Internet-Draft MultiMob Route Optimization Comparison March 2010 [I-D.sijeon-multimob-mms-pmip6] Jeon, S. and Y. Kim, "Mobile Multicasting Support in Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02 (work in progress), March 2010 [I-D.zuniga-multimob-smspmip] Zuniga, J., Lu, G., and A. Rahman, "Support Multicast Services Using Proxy Mobile IPv6", draft-zuniga-multimob-smspmip-04 (work in progress), October 2010. 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 September 4, 2011 [Page 14]