Network Working Group Seil Jeon Internet-Draft Younghan Kim Intended status: Standards Track Soongsil University, Korea Expires: January 11, 2012 July 11, 2011 PMIPv6 Multicasting Support using Native Infrastructure draft-sijeon-multimob-direct-routing-pmip6-01.txt 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. 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." 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 January 11, 2012. Jeon, et al. Expires January 11, 2012 [Page 1] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 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. 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. Jeon, et al. Expires January 11, 2012 [Page 2] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 Abstract To support IP multicasting in PMIPv6 domain, [RFC6424] has been determined as a base solution. This solution requires all the LMA to forward multicast packets to MAG via PMIPv6 tunnel. This approach creates a tunnel convergence problem. To resolve the issue, the current MULTIMOB WG charter is trying to draw a solution about how to separate multicasting routing from a mobility anchor. To address the issue, we propose the local routing approach that makes the direct connection between MAG and multicast router. The advantages of the proposed local routing solution are compared with the base solution and dedicated LMA approach. In addition, we present the applicability of local routing solution depending on several constraints. Table of Contents 1. Introduction.....................................................4 2. Terminology and Functional Components............................5 3. Local Routing Solution...........................................6 3.1. Architecture.................................................6 3.2. Handover Procedure...........................................7 4. Comparison with Base Solution, Dedicated LMA, and Local Routing..8 4.1. Tunnel Convergence...........................................8 4.2. Complexity in LMA............................................8 4.3. Packet Overhead..............................................8 4.4. Another Advantage............................................9 5. Applicability....................................................9 6. Message Header...................................................9 6.1. MLD Query....................................................9 6.2. MLD Report..................................................10 6.3. Multicast Packet............................................10 7. IANA Considerations.............................................11 8. Security Considerations.........................................11 9. References......................................................11 9.1. Normative References........................................11 9.2. Informative References......................................12 Authors' Addresses.................................................13 Jeon, et al. Expires January 11, 2012 [Page 3] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 1. Introduction PMIPv6 is a network-based IP mobility protocol that requires no host stack involvements; it provides enhanced mobility performance compared to host-based approaches like MIPv6, FMIPv6. However, current PMIPv6 specification does not explicitly address the method of multicasting communications [RFC5213]. To support multicasting in PMIPv6 domain, the base solution proposes deployment option [RFC6424], which places multicast routing on LMA. MAG receives a multicast stream from LMA by using PMIPv6 tunnel. It is simply derived from PMIPv6 specification and requires no modification to PMIPv6 components and MNs. However, the base solution introduces a tunnel convergence issue in case a MAG receives the same multicast packets from more than one LMA. This causes severe network bandwidth. To avoid a tunnel convergence problem, the current MULTIMOB WG charter is trying to d a solution on how to separate multicasting routing from the mobility anchor. As potential techniques, two kinds of approaches have been presented: a dedicated mobility anchor and local routing. The concept of dedicated LMA is to assign dedicated multicasting LMA to each MAG. This approach resolves tunnel convergence issues but introduces tunnel avalanche problem because M-LMA needs to replicate data streams to all MAGs. It imposes a heavy burden on the M-LMA to process and forward tunnel packets. Additionally, it makes severe packet tunneling overhead. In this draft, we propose a local routing solution that a MAG receives multicast packets directly from MR without any tunnel. This solution can completely solve tunnel-related performance issues by placing MLD proxy on a MAG and allowing multicast connectivity between the MAG and MR. With the description of local routing operation, we present the comparisons of a few of candidate solutions in terms of performance. In addition, we also check the applicability of local routing depending on several constraints. Jeon, et al. Expires January 11, 2012 [Page 4] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 2. Terminology and Functional Components 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 RFC2119. o Mobile Node (MN) o Previous Mobile Access Gateway (P-MAG) - The MAG that manages mobility related signaling for a MN before handover. o New Mobile Access Gateway (N-MAG) - The MAG that manages mobility related signaling for the MN after handover o Multicast Router (MR) o MLD Proxy (M-Proxy) Jeon, et al. Expires January 11, 2012 [Page 5] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 3. Local Routing Solution 3.1. Architecture Multicast Tree : : || - PMIPv6 Tunnel +----------+ +----------+ | - Multicast Data Path | LMA | | MR | +----------+ +----------+ ||\\ /| || \\ / | || \\ / | || \\ / | || \\/ | || / \\ | || / \\ | || / \\ | +----------+ +----------+ | P-MAG | | N-MAG | |(M-Proxy) | |(M-Proxy) | +----------+ +----------+ : : +------+ +------+ | MN | -----> | MN | +------+ +------+ Figure 1. Direct routing solution for PMIPv6 Multicasting Figure 1 shows the proposed local routing architecture using native multicasting infrastructure [I-D.deng-multimob-pmip6-requirement]. To forward IGMP/MLD signaling and multicast packets, a MLD proxy function defined in [RFC4605], SHOULD be placed on a MAG. This solution is much simpler than the base solution and easy to deploy because multicasting functions are totally separated from mobility anchor by using a native multicasting infrastructure. Jeon, et al. Expires January 11, 2012 [Page 6] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 3.2. Handover Procedure Multicast MN P-MAG N-MAG LMA MR Tree | | | | | | | | | | | | |<----------|<-- Multicast Data--------------|<-------| | | . | | | | | | . | | | | | | . | | | | Link->| Handover | | | | Disconnected Detection | | | | | | | | | | | | | | | | | | MN Attachment | | | | | | | | | | | | | | | |------ Rtr. Sol. ----->| | | | | | | | | | |<----- MLD Query ------| | | | | | | | | | |------ MLD Report ---->| | | | | | | Aggregated | | | | |--- MLD Report ---->| | | | | | | | | | | | | | |<----------------------|<-- Multicast Data--|<-------| | | | | | | | | | | | | | | | Proxy | | | | | |--Binding->| | | | | | Update | | | | | | | | | | | | Proxy | | | | | |<-Binding--| | | | | | Ack. | | | | | | | | | Figure 2. Handover procedure in direct routing architecture Figure 2 shows the handover operation in local routing architecture. When an MN hands off to the N-MAG from the P-MAG, the N-MAG detects Jeon, et al. Expires January 11, 2012 [Page 7] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 the newly arrived MN and transmits an MLD query message to the MN. After receiving the MLD query message, the MN sends an MLD report message that includes the multicast group information. The N-MAG then sends an aggregated MLD report message to the MR. When the N-MAG receives the multicast packets from the MR, it then simply forwards them without tunnel encapsulation. The N-MAG updates the MN's location information to the LMA by exchanging PBU/PBA signaling messages. 4. Comparison with Base Solution, Dedicated LMA, and Local Routing In this section, we compare the direct routing with the base solution [RFC6424] and dedicated LMA [I-D.zuniga-multimob-smspmip] in terms of performance, ease of deployment, and other factors. 4.1. Tunnel Convergence In the base solution, the MR function is combined with LMA. Thus, all the packets are delivered to MNs through PMIPv6 tunnel between MAG and LMA, which raises the tunnel convergence problem. because a MAG may receive the same multicast packets from several LMAs. Dedicated LMA and the proposed direct routing have different approaches; however, they can avoid the tunnel convergence issue. 4.2. Complexity in LMA In the tunnel-based approaches, a LMA needs to deal with MLD signaling, join/leave procedure, and tunnel packet processing (i.e., encapsulating/decapsulating and tunnel packet lookup) as well as the role of mobility anchor. When using a dedicated entity, these complexities can be reduced but cannot be avoided completely. On the other hand, the direct routing is absolutely not affected by these complexities. 4.3. Packet Overhead Using native multicasting infrastructure, local routing does not make tunneling overhead for multicast data delivery while tunnel-based approaches require 40 bytes of IP tunnel header per packet. According as packet arrival rate increases, the overhead becomes much severe. Jeon, et al. Expires January 11, 2012 [Page 8] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 4.4. Another Advantage When we consider that MNs move to non-PMIPv6 domains from PMIPv6 domains as described in [I-D.von-hugo-multimob-future-work], the direct routing approach can provide a compatible method because it does not depend on PMIPv6 tunnel for multicasting operation. 5. Applicability in Visited Network If a multicast listener is in visited network, the local routing can be applied on the condition that there are a multicast peering entities, e.g., content delivery network (CDN), inter-domain multicast routing like BGMP [RFC3913] or MBGP [RFC4765] in visited network. At that time, the multicast channel used in home network MAY be different in visited network therefore, the listener MAY need to wait a time for joining the channel informed from visited network but this latency can be reduced through handover optimization technique with multicast context transfer. In particular, the source in which the multicast listener is interested and the receiver are in same visited network, the local routing is used efficiently than tunnel-based multicast transmission technique using home subscription because local routing provides much optimized routing path for delivering multicast data transmission regardless of the number of channels and receivers. 6. Message Formats This section describes source and destination address of MLD signaling messages. The interface A-B means that an interface on node A, which is connected to node B. 6.1. MLD Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface | Source Address | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MR-MAG | MR link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAG-MN | MAG link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeon, et al. Expires January 11, 2012 [Page 9] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 6.2. MLD Report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface | Source Address | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-MAG | MN link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAG-MR | MAG link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3. Multicast Packets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface | Source Address | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MR-MAG | Streaming Source Addr. | Multicast Group Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAG-MN | Streaming Source Addr. | Multicast Group Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeon, et al. Expires January 11, 2012 [Page 10] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 7. IANA Considerations TBD. 8. Security Considerations This document does not discuss any special security concerns in detail. The protocol of this document is built on the assumption that all participating nodes are trusted each other as well as there is no adversary who modifies/injects false messages to corrupt the procedures. 9. References 9.1. Normative References [RFC2710] S. Deering, W. Fenner, B. Harberman, "Multicast Listener Discovery (MLD) for IPV6", IETF RFC 2710, October 1999. [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery Version(MLDv2) for IPv6", IETF RFC 3810, June 2004. [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008. [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", IETF RFC 4605, August 2006. [RFC6424] T. Schmidt, M. Waehlisch, and S. Krishnan, "Base Deployment for Multicast Listener Support in PMIPv6 Domains", IETF RFC 6424, April 2011. Jeon, et al. Expires January 11, 2012 [Page 11] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 9.2. Informative References [RFC3913] D. Thaler, "Border Gateway Multicast Protocol (BGMP): Protocol Specification," IETF RFC 3913, September 2004. [RFC4765] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol Extensions for BGP-4," IETF RFC 4765, January 2007. [I-D.deng-multimob-pmip6-requirement] H. Deng, T. Schmidt, P. Seite, and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", draft-deng- multimob-pmip6-requirement-02.txt (work in progress), July 2009. [I-D.zuniga-multimob-smspmip] J. C. Zuniga, A. Rahman, L. M. Contreras, C. J. Bernardos, and I. Soto, "Support Multicast Services Using Proxy Mobil IPv6," draft-zuniga-multimob-smspmip-05.txt (work in progress), March 2011. [I-D.von-hugo-multimob-future-work] D. von Hugo, H. Asaeda, B. Sarikaya, and P. Seite, "Evaluation of further issues on Multicast Mobility: Potential future work for WG MultiMob", draft-von-hugo- multimob-future-work-02.txt (work in progress), Juney 2010. Jeon, et al. Expires January 11, 2012 [Page 12] Internet-Draft PMIPv6 Multicasting Support July 11, 2011 Authors' Addresses Seil Jeon Soongsil University 4F Hyungnam Engineering Bldg. 424, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea Phone: +82-2-820-0841 E-mail: sijeon@dcn.ssu.ac.kr Younghan Kim Soongsil University 11F Hyungnam Engineering Bldg. 1107, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea Phone: +82-2-820-0904 E-mail: yhkim@dcn.ssu.ac.kr Jeon, et al. Expires January 11, 2012 [Page 13]