MULTIMOB Group JC.Zuniga Internet Draft G.Lu Intended status: Standards Track A.Rahman Expires: August 23, 2010 InterDigital Communications, LLC February 23, 2010 Support Multicast Services Using Proxy Mobile IPv6 draft-zuniga-multimob-smspmip-02.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 August 23,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. Zuniga, et al. Expires August 23, 2010 [Page 1] Internet-Draft Multicast Services using PMIPv6 February 2010 Abstract This document describes how multicast mobility services can be supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener Discovery (MLD) [RFC3810], and Internet Group Management Protocol (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for multicast listener mobility. It proposes the use of a dedicated Local Mobility Anchor as the topological anchor point for multicast traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. There are no impacts to the Mobile Node to support multicast listener mobility. Table of Contents 1. Introduction...................................................2 2. Conventions and Terminology....................................3 3. Solution.......................................................3 3.1. Architecture..............................................3 3.2. Multicast Establishment...................................5 3.3. Multicast Mobility........................................7 3.4. Advantages................................................8 4. Security Considerations.......................................12 5. IANA Considerations...........................................12 6. References....................................................12 6.1. Normative References.....................................12 6.2. Informative References...................................13 7. Acknowledgments...............................................13 1. Introduction Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the network and does the mobility management on behalf of the Mobile Node (MN). The Local Mobility Anchor (LMA) is the home agent for the MN and the topological anchor point. PMIPv6 was originally designed for unicast traffic. The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by IPv4 hosts to report their IP multicast group memberships to neighboring multicast routers. Multicast Listener Discovery (MLDv2) [RFC3810] is used in a similar way by IPv6 routers to discover the Zuniga, et al. Expires August 23, 2010 [Page 2] Internet-Draft Multicast Services using PMIPv6 February 2010 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605] allows an intermediate (edge) node to appear as a multicast router to downstream hosts, and as a host to upstream multicast routers. IGMP and MLD related protocols were not originally designed to address IP mobility of multicast listeners (i.e. IGMP and MLD protocols were originally designed for fixed networks). Supporting mobility of multicast traffic has been under discussions within the MULTIMOB working group. This document focuses on addressing multicast listener mobility using the PMIPv6 and IGMP/MLD protocols. It proposes the use of a dedicated LMA as the topological mobility anchor point for multicast traffic, while the MAG serves as an IGMP/MLD proxy. 2. Conventions and 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]. This document uses the terminology defined in [RFC5213], [RFC3775], and [RFC3810]. 3. Solution A PMIPv6 domain may receive data from both unicast and multicast sources. A dedicated LMA can be used to serve as the mobility anchor for multicast traffic. Unicast traffic will go normally to the other LMAs in the PMIPv6 domain. This section describes how the multicast LMA works in scenarios of mobile node attachment and multicast mobility. 3.1. Architecture Figure 1 shows an example of a PMIPv6 domain supporting multicast mobility. LMA1 is dedicated to unicast traffic, and LMA2 is dedicated to multicast traffic. Note that there can multiple LMAs dedicated to unicast traffic (not shown in Figure 1) in a given PMIPv6 domain. However, we assume a single LMA dedicated to multicast traffic in a PMIPv6 domain (as shown in Figure 1). This LMA (LMA2) can be considered to be a form of upstream multicast router with tunnel interfaces allowing remote subscription for the MNs. Also in this architecture, all MAGs that are connected to the multicast LMA must support the MLD proxy [RFC4605] function. Specifically in Figure 1, each of the MAG1-LMA2 and MAG2-LMA2 tunnel interfaces defines an MLD proxy domain. The MNs are considered to be Zuniga, et al. Expires August 23, 2010 [Page 3] Internet-Draft Multicast Services using PMIPv6 February 2010 on the downstream interface of the MLD proxy (in the MAG), and LMA2 is considered to be on the upstream interface (of the MAG) as per [RFC4605]. Note that MAG could also be an IGMP proxy. For brevity this document will refer primarily to MLD proxy, but all references to "MLD proxy" should be understood to also include "IGMP/MLD proxy" functionality. As shown in Figure 1, MAG1 may connect to both unicast and multicast LMAs. Thus, a given MN may simultaneously receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 receive unicast traffic, multicast traffic, or both, whereas MN3 receives multicast traffic only. Zuniga, et al. Expires August 23, 2010 [Page 4] Internet-Draft Multicast Services using PMIPv6 February 2010 +--------------+ |Content Source| +--------------+ | | *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Unicast Traffic * * Multicast Traffic * * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** | | | | | | +-----+ +------+ Unicast | LMA1| | LMA2 | Multicast Anchor +-----+ +------+ Anchor \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || +-----+ +-----+ | MAG1| | MAG2| MLD Proxy +-----+ +-----+ | | | | | | {MN1} {MN2} {MN3} Figure 1 Architecture of Dedicated LMA as Multicast Anchor 3.2. Multicast Establishment Figure 2 shows the procedure when MN1 attaches to MAG1, and establishes associations with LMA1 (unicast) and LMA2 (multicast). Zuniga, et al. Expires August 23, 2010 [Page 5] Internet-Draft Multicast Services using PMIPv6 February 2010 MN1 MAG1 LMA1 LMA2 | (MLD Proxy) (Unicast) (Multicast) MN attaches to MAG1 | | | | | | | |------Rtr Sol----- ->| | | | |--PBU -- >| | | | | | | |<-- PBA --| | | | | | | |=Unicast= | | | | Tunnel | | |<-----Rtr Adv ------ | | | | | | | |< ------ Unicast Traffic------ >| | | | | | | |==Multicast Tunnel ==| | | | | |<--MLD Query --------| | | | | | | MN requires multicast services | | | | | | |---MLD Report (G) -->| | | | | | | | |---- Aggregated ---> | | | MLD Report (G) | | | | | | | | | |< --------- Multicast Traffic ----------- >| | | | | Figure 2 MN Attachment and Multicast Service Establishment In Figure 2, MAG1 first establishes the PMIPv6 tunnel with LMA1 for unicast traffic as defined in [RFC5213] after being triggered by the Router Solicitation message from MN1. Unicast traffic will then flow between MN1 and LMA1. For multicast traffic, a multicast tunnel may have been pre- configured between MAG1 and the multicast LMA (LMA2). Or the multicast tunnel may be dynamically established when the first MN appears at the MAG. MN1 sends the MLD report message (when required by its upper layer applications) as defined in [RFC3810] in response to an MLD Query from MAG1. MAG1 acting as a MLD Proxy as defined in [RFC4605] will Zuniga, et al. Expires August 23, 2010 [Page 6] Internet-Draft Multicast Services using PMIPv6 February 2010 then send an Aggregated MLD Report to the multicast anchor, LMA2 (assuming that this is a new multicast group which MAG1 had not previously subscribed to). Multicast traffic will then flow from LMA2 towards MN1. 3.3. Multicast Mobility Figure 3 illustrates the mobility scenario for multicast traffic. Specifically, MN2 with ongoing multicast subscription moves from MAG1 to MAG2. Note that, for simplicity, in this scenario MAG2 is connected only to LMA2 (multicast) and does not receive unicast traffic. Of course, if it was desired to support unicast traffic, the architecture will easily allow MAG2 to also connect to LMA1 to support unicast traffic. After MN2 mobility, MAG2 acting in its role of MLD proxy will send an MLD Query to the newly observed MN on its downlink. Assuming that the subsequent MLD Report from MN2 requests membership of a new multicast group (from MAG2's point of view), this will then result in an Aggregated MLD Report being sent to LMA2 from MAG2. This message will be sent through a pre-established (or dynamically established) multicast tunnel between MAG2 and LMA2. When MN2 detaches, MAG1 may keep the multicast tunnel with the multicast LMA2 if there are still other MNs using the multicast tunnel. Even if there are no MNs currently on the multicast tunnel, MAG1 may decide to keep the multicast tunnel for potential future use. As discussed above, existing MLD (and Proxy MLD) signaling will handle a large part of the multicast mobility management for the MN. Zuniga, et al. Expires August 23, 2010 [Page 7] Internet-Draft Multicast Services using PMIPv6 February 2010 MN2 MAG1 MAG2 LMA1 LMA2 | (MLD Proxy) (MLD Proxy) (Unicast)(Multicast) | | | | | MN Attached | | | | To MAG1 | | | | | | | | | | |========= Multicast Tunnel ======= | | | | | | MN Detaches | | | | From MAG1 | | | | | | | | | | | | | | MN Attaches | | | | To MAG2 | | | | | | | | | | | |==Multicast Tunnel === | | | | | | |---------Rtr Sol------ >| | | | | | | | |<-----Rtr Adv --------- | | | | | | | | | | | | | |<---------MLD Query---- | | | | | | | | |---MLD Report (G) ----> | | | | | | | | | | |---- Aggregated -----> | | | | MLD Report (G) | | | | | | | | | | | |< --------- Multicast Traffic ---------------- >| | | | | | | | | | | Figure 3 Multicast Mobility Signaling 3.4. Advantages An advantage of the proposed dedicated multicast LMA architecture is that it allows a PMIPv6 domain to closely follow a simple multicast tree topology for Proxy MLD forwarding (cf., sections 1.1 and 1.2 of [RFC4605]). Other approaches, like the combined unicast/multicast LMA as proposed in [I-D.schmidt-multimob-pmipv6-mcast-deployment] also comply to a multicast tree topology but will have a more complex set of trees of which the sum, of course, will still be a tree. Zuniga, et al. Expires August 23, 2010 [Page 8] Internet-Draft Multicast Services using PMIPv6 February 2010 Finally another advantage is that a dedicated multicast LMA minimizes replication of multicast packets, in certain scenarios, compared to [I-D.schmidt-multimob-pmipv6-mcast-deployment]. Figures 4 and 5 illustrate this point visually. For this simple scenario, it can be observed that the dedicated multicast LMA topology (Figure 4) generates 6 packets for one input multicast packet. In comparison, the combined unicast/multicast LMA topology (Figure 5) generates 8 packets for one input multicast packet. In general, it can be seen that the extra multiplication of packets in the combined unicast/multicast LMA topology will be proportional to the number of LMAs, and the number of MNs (in a given MAG) associated to different LMAs, for a given multicast group. The packet multiplication problem aggravates as more MNs associated to different LMAs receive the same multicast traffic when attached to the same MAG. Hence, the dedicated multicast architecture significantly decreases the network capacity requirements in this scenario. (Note that in Figure 4, it is assumed that MN1 and MN2 are associated with MAG1-LMA1, and MN3 is associated with MAG2-LMA2 for multicast traffic. In Figure 5, it is assumed that MN1 is associated with MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated with MAG2-LMA2 for multicast traffic. In both Figures 4 and 5, it is assumed that the packets are transmitted point to point on the last hop wireless link.) Zuniga, et al. Expires August 23, 2010 [Page 9] Internet-Draft Multicast Services using PMIPv6 February 2010 +--------------+ |Content Source| +--------------+ | | +---+ Packet destined | 1 | for Multicast group "G" +---+ | *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Unicast Traffic * * Multicast Traffic * * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** | | | +---+ | | 2 | | +---+ | | +-----+ +------+ Unicast | LMA1| | LMA2 | Multicast Anchor +-----+ +------+ Anchor \\ //|| \\ // || \\ // || \\ // || \\ +---+ +---+ \\ | 3 | | 4 | \\ +---+ +---+ \\ // || \\ // || \\ // || \\ // || +-----+ +-----+ | MAG1| | MAG2| MLD Proxy +-----+ +-----+ | | | +---+ +---+ +---+ | 5 | | 6 | | 7 | +---+ +---+ +---+ | | | All MNs in same | | | multicast group "G" {MN1} {MN2} {MN3} Figure 4 Packet Flow in a Dedicated Multicast LMA Zuniga, et al. Expires August 23, 2010 [Page 10] Internet-Draft Multicast Services using PMIPv6 February 2010 +--------------+ |Content Source| +--------------+ | | +---+ Packet destined | 1 | for Multicast group "G" +---+ | *** *** *** *** *** *** *** *** *** * ** ** ** ** ** ** ** ** * * * * Fixed Internet * * (Unicast & Multicast Traffic) * * ** ** ** ** ** ** ** ** * *** *** *** *** *** *** *** *** *** | | +---+ +---+ | 2 | | 3 | +---+ +---+ | | +-----+ +------+ | LMA1| | LMA2 | Combined +-----+ +------+ Unicast/Multicast \\ // || Anchor \\ // || \\ // || \\ // || +---+ +---+ +---+ | 4 | | 5 | | 6 | +---+ +---+ +---+ \\ // || \\ // || \\ // || \\ // || +-----+ +-----+ | MAG1| | MAG2| MLD Proxy +-----+ +-----+ | | | +---+ +---+ +---+ | 7 | | 8 | | 9 | +---+ +---+ +---+ | | | All MNs in same | | | multicast group "G" {MN1} {MN2} {MN3} Figure 5 Packet Flow in a Combined Unicast/Multicast LMA Zuniga, et al. Expires August 23, 2010 [Page 11] Internet-Draft Multicast Services using PMIPv6 February 2010 4. Security Considerations This draft discusses the operations of existing protocols without modifications. It does not introduce new security threats beyond the current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 5. IANA Considerations This document makes no request of IANA. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [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. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [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. Zuniga, et al. Expires August 23, 2010 [Page 12] Internet-Draft Multicast Services using PMIPv6 February 2010 6.2. Informative References [I-D.deng-multimob-pmip6-requirement] Deng, H., Schmidt, T., Seite, P., and P.Yang, "Multicast Support Requirements for Proxy Mobile IPv6", draft-deng- multimob-pmip6-requirements-02 (Work in progress), July 13, 2009. [I-D.schmidt-multimob-pmipv6-mcast-deployment-04] Schmidt, TC., Waehlisch, M., and S.Krishnan, "A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains", draft-schmidt- multimob-pmipv6-mcast-deployment-04 (Work in progress), February 8, 2010. 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Guang Lu InterDigital Communications, LLC Email: Guang.Lu@InterDigital.com Akbar Rahman InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Zuniga, et al. Expires August 23, 2010 [Page 13]