Network Working Group Seil Jeon Internet-Draft Soongsil University, Korea Intended status: Standards Track Younghan Kim Expires: September 7, 2011 Soongsil University, Korea March 7, 2011 PMIPv6 Multicasting Support using Native Infrastructure draft-sijeon-multimob-direct-routing-pmip6-00.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. 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 September 7, 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 Jeon, et al. Expires September 7, 2011 [Page 1] Internet-Draft PMIPv6 Multicasting Support March 2011 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 September 7, 2011 [Page 2] Internet-Draft PMIPv6 Multicasting Support March 2011 Abstract To support IP multicasting in PMIPv6 domain, [I-D.ietf-multimob- pmipv6-base-solution] 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. As an effective solution, we propose the direct routing approach that makes the direct connection between MAG and multicast router. The advantages of the proposed direct routing solution are compared with the base solution and dedicated LMA approach. This draft is derived and revised from [I-D.sijeon-multimob-mms-pmip6] as re-chartered MULTIMOB WG description. Table of Contents 1. Introduction.....................................................4 2. Terminology and Functional Components............................5 3. Direct Routing Solution..........................................6 3.1. Architecture.................................................6 3.2. Handover Procedure...........................................7 4. Comparison with Base Solution, Dedicated LMA, and Direct Routing.7 4.1. Tunnel Convergence...........................................8 4.2. Complexity in LMA............................................8 4.3. Packet Overhead..............................................8 4.4. Another Advantage............................................8 5. Message Header...................................................9 5.1. MLD Query....................................................9 5.2. MLD Report...................................................9 5.3. Multicast Packet.............................................9 6. IANA Considerations.............................................10 7. Security Considerations.........................................10 8. References......................................................10 8.1. Normative References........................................10 Author's Address...................................................12 Jeon, et al. Expires September 7, 2011 [Page 3] Internet-Draft PMIPv6 Multicasting Support March 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 [I-D.ietf-multimob-pmipv6-base-solution], 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 direct routing. The concept of dedicated LMA is to assign dedicated multicasting LMA to each MAG. This approach resolves tunnel convergence issues; however, PMIPv6 tunnel is also used. It imposes a heavy burden on a multicasting LMA to process and forward tunnel packets to several MAGs. Additionally, it incurs severe packet tunneling overhead. In this draft, we propose a direct routing solution that a MAG receives multicast packets directly from MR with no tunnel. This solution can completely solve tunnel-related performance issues introduced from the base solution and dedicated LMA solution. Jeon, et al. Expires September 7, 2011 [Page 4] Internet-Draft PMIPv6 Multicasting Support March 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 September 7, 2011 [Page 5] Internet-Draft PMIPv6 Multicasting Support March 2011 3. Direct 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 direct 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 September 7, 2011 [Page 6] Internet-Draft PMIPv6 Multicasting Support March 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 direct routing architecture. When an MN hands off to the N-MAG from the P-MAG, the N-MAG detects Jeon, et al. Expires September 7, 2011 [Page 7] Internet-Draft PMIPv6 Multicasting Support March 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 Direct Routing In this section, we compare the direct routing with the base solution [I-D.ietf-multimob-pmipv6-base-solution] 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 With native multicasting infrastructure, direct routing does not make any packet overhead while tunnel-based approaches bring about tunneling overhead per packet. Tunneling overhead could become severe as the packet arrival rate increases. Jeon, et al. Expires September 7, 2011 [Page 8] Internet-Draft PMIPv6 Multicasting Support March 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. 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. 5.1. MLD Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface | Source Address | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MR-MAG | MR link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAG-MN | MAG link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. MLD Report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface | Source Address | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-MAG | MN link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAG-MR | MAG link local | [RFC2710], [RFC3810] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.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 September 7, 2011 [Page 9] Internet-Draft PMIPv6 Multicasting Support March 2011 6. IANA Considerations TBD. 7. 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. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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, Augurst 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. [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.ietf-multimob-pmipv6-base-solution] T. C. Schmidt, M. Waehlisch, S. Krishnan, "Base Deployment Jeon, et al. Expires September 7, 2011 [Page 10] Internet-Draft PMIPv6 Multicasting Support March 2011 for Multicast Listener Support in PMIPv6 Domains", draft- ietf-multimob-pmipv6-base-solution-00.txt (work in progress), February 2010. [I-D.sijeon-multimob-mms-pmip6] S. Jeon and Y. Kim, "Mobile Multicasting Support in Proxy Mobile IPv6," draft-sijeon-multimob-mms-pmip6-02.txt (expired), March 2010. [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-04.txt (work in progress), October 2010. [I-D.von-hugo-multimob-future-work] D. von Hugo, H. Asaeda, B. Sarikaya, P. Seite, "Evaluation of further issues on Multicast Mobility: Potential future work for WG MultiMob", draft-von-hugo-multimob-future- work-01.txt (work in progress), February 2010. Jeon, et al. Expires September 7, 2011 [Page 11] Internet-Draft PMIPv6 Multicasting Support March 2011 Author's 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 September 7, 2011 [Page 12]