MULTIMOB Group JC.Zuniga Internet Draft G.Lu Intended status: Standards Track A.Rahman Expires: April 15, 2010 InterDigital Communications, LLC October 15, 2009 Support Multicast Services Using Proxy Mobile IPv6 draft-zuniga-multimob-smspmip-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 April 16 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zuniga, et al. Expires April 15, 2010 [Page 1] Internet-Draft Multicast Services using PMIPv6 October 2009 Abstract This document describes how multicast services can be supported with Proxy Mobile IPv6 protocol [RFC5213], Multicast Listener Discovery (MLDv2) protocol [RFC3810], and Internet Group Management Protocol (IGMPv3)[RFC3376]. This document analyzes scenarios for multicast service establishment and mobility. It also proposes the use of a dedicated LMA for multicast services. Table of Contents 1. Introduction...................................................2 2. Conventions and Terminology....................................3 3. Single LMA Supporting both Unicast and Multicast Services......3 3.1. Architecture..............................................3 3.2. Multicast Establishment...................................4 3.3. Multicast Mobility........................................5 4. Dedicated LMA Supporting Multicast Services....................6 4.1. Architecture..............................................6 4.2. Multicast Establishment...................................7 4.3. Multicast Mobility........................................9 5. Enhanced Multicast Mobility Support...........................10 5.1. Architecture.............................................11 5.2. Multicast Mobility.......................................11 6. MLD/IGMP Enhancements.........................................14 6.1. "Join" before Handover...................................14 6.2. Fast "Join" after HO.....................................14 7. Security Considerations.......................................14 8. IANA Considerations...........................................15 9. References....................................................15 9.1. Normative References.....................................15 9.2. Informative References...................................15 10. Acknowledgments..............................................16 1. Introduction Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving IP mobility challenge. In a Proxy Mobile IPv6 domain, Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the network and does the mobility management on behalf of the mobile node attached to the network. Local Mobility Anchor (LMA) is the home agent for the mobile node and the topological anchor point. Proxy Mobile IPv6 is designed mainly for unicast services. The Internet Group Management Protocol (IGMP) [RFC3376] is the protocol used by IPv4 systems to report their IP multicast group Zuniga, et al. Expires April 15, 2010 [Page 2] Internet-Draft Multicast Services using PMIPv6 October 2009 memberships to neighboring multicast routers. The Multicast Listener Discovery Protocol (MLD)[RFC3810] is used in a similar way as IGMP by IPv6 routers to discover the presence of multicast listeners. However, IGMP/MLD are not designed to address mobility issues. Supporting multicast services has been under discussions within the working group. This document focuses on addressing multicast mobility scenarios using the Proxy Mobile IPv6 and IGMP/MLD protocols, and proposing a new deployment architecture with a dedicated LMA for multicast services. This document also provides two mechanisms to reduce latency for IGMP/MLD. 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], [RFC3810]. 3. Single LMA Supporting both Unicast and Multicast Services This section describes how multicast services and mobility can be supported based on how Proxy Mobile IPv6 and MLD protocols work now. To improve service continuity, some enhancements can be made, without modifying the protocols. The enhancements are discussed in section 4, 5, and 6. 3.1. Architecture Figure 1 illustrates the architecture using Proxy Mobile IPv6. In this architecture, MAG provides multicast proxy functions as defined in [RFC4605]. LMA serves as the multicast router and forwards multicast services. LMA is also the anchor point for unicast services. Zuniga, et al. Expires April 15, 2010 [Page 3] Internet-Draft Multicast Services using PMIPv6 October 2009 *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Unicast Services * * Multicast Services* * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** | | | | | | | | | | +-----+ | LMA | +-----+ // \\ // \\ // \\ // \\ +-----+ +-----+ |p-MAG| |n-MAG| +-----+ +-----+ | | | | {MN} -- Handover -> {MN} Figure 1 Multicast Mobility Architecture 3.2. Multicast Establishment Figure 2 shows the procedures of MN attachment and initiation of unicast and multicast services. The unicast service is shown for the purpose of completion and comparison. The procedures from "MN Attachment" to the establishment of unicast service are the same as defined in Proxy Mobile IPv6 [RFC5213]. MAG provides multicast proxy functions as defined in [RFC4605]. LMA serves as the multicast router and forwards multicast services. The MLD Query message may occur before the MLD Report is sent, and they are not shown in the figure for simplicity. Zuniga, et al. Expires April 15, 2010 [Page 4] Internet-Draft Multicast Services using PMIPv6 October 2009 MN MAG LMA | | | MN Attached | | | | | | | | |---- Rtr Sol --->| | | | | | |--------PBU------ >| | | | | |<-------PBA------- | | | | | | | | |===Bi-Dir Tunnel== | | | | |<----Rtr Adv---- | | | | | IP address | | Configuration | | | | | |< -------Unicast Traffic----------- >| | | | | | | |---MLD Report-- >| | | |-----MLD Report-- >| | | | |<--------Multicast Traffic--------- >| | | | Figure 2 MN Attachment and Multicast Service Establishment 3.3. Multicast Mobility Figure 3 shows the procedures of re-establishing the multicast services when the MN moves within the same LMA. The MN shown in the figure has both unicast and multicast sessions. This figure shows a basic scenario that the MN needs to re-join the multicast services after handover. There are ways to improve the multicast mobility support and they are discussed in section 4, 5 and 6. Zuniga, et al. Expires April 15, 2010 [Page 5] Internet-Draft Multicast Services using PMIPv6 October 2009 MN p-MAG n-MAG LMA | | | | | | | | |< --------------- Unicast Traffic -------------- >| | | | | |< ------------- Multicast Traffic -------------- >| | | | | Detached from p-MAG | | | | | | | | |----------- DeReg PBU--------- >| | | | | | |< -------------PBA ------------ | Attached to n-MAG | | | | | | | |------------Rtr Sol ------------- >| | | | |-----PBU---- >| | | | | | | |< ---PBA----- | | | | | | | |===Bi Dir === | | | | tunnel | |< ----------Rtr Adv--------------- | | | | | | |< --------------Unicast Traffic ---------------- >| | | | | | | | | |---------------MLD Report-------- >| | | | |-MLD Report- >| | | | | |<---------------Multicast Traffic--------------- >| | | | | Figure 3 Multicast Mobility 4. Dedicated LMA Supporting Multicast Services A PMIPv6 domain may receive data from sources of both the unicast services and multicast services. A dedicated LMA can be used to serve as the anchor for multicast services. This section describes how the multicast LMA works in scenarios of mobile node attachment and multicast mobility. 4.1. Architecture Figure 4 shows a PMIPv6 domain. One LMA is dedicated to unicast services, and one is dedicated to multicast services. A MAG may Zuniga, et al. Expires April 15, 2010 [Page 6] Internet-Draft Multicast Services using PMIPv6 October 2009 connect to both LMAs, or only one LMA. A MN may receive unicast and/or multicast services. In Figure 4, MN1 and MN2 have either unicast or multicast services, or both. MN3 has multicast services only. *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Unicast Services * * Multicast Services* * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** | | | | | | +-----+ +-----+ | LMA | | LMA | +-----+ +-----+ \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || \\ // || +-----+ +-----+ | MAG | | MAG | +-----+ +-----+ | | | | | | {MN1} {MN2} {MN3} Figure 4 Architecture of Dedicated LMA as Multicast Anchor 4.2. Multicast Establishment Figure 5 shows the procedure when two mobile nodes attach to the MAG, and establish Proxy Mobile IPv6 tunnels, with the unicast LMA and multicast LMA respectively. Zuniga, et al. Expires April 15, 2010 [Page 7] Internet-Draft Multicast Services using PMIPv6 October 2009 MN1 MN2 MAG LMA LMA | | | (Unicast) (Multicast) | | | | | MN1 Attachment | | | | | | | | | |------Rtr Sol----- ->| | | | | |--PBU -- >| | | | | | | | | |<-- PBA --| | | | | | | | | |=Unicast= | | | | | Tunnel | | |<-----Rtr Adv ------ | | | | | | | | |< ------ Unicast Traffic------ >| | | | | | | | MN2 Attachment | | | | | | | | | |-Rtr Sol >| | | | | | | | | |-- MLD -->| | | | | Report | | | | | |----- MLD Report---> | | | | | | | | |------------PBU---- >| | | | | | | | |< ----------PBA----- | | | | | | | | |==Multicast Tunnel ==| | | | | | | || | | | | | Figure 5 MN Attachment and Multicast Service Establishment In the illustrated scenario, both MN1 and MN2 are attached to the same MAG. MN1 is a "traditional" user for unicast services. The MAG establishes the Proxy Mobile IPv6 tunnel with LMA for unicast services as defined in [RFC5213]. MN2 requires multicast services. It may indicate its multicast request in the Router Solicitation request. MAG sends the Proxy Binding Update to the multicast LMA, and establishes the tunnel for multicast services. MAG may use a multicast CoA so the multicast Zuniga, et al. Expires April 15, 2010 [Page 8] Internet-Draft Multicast Services using PMIPv6 October 2009 tunnel can be shared by multiple MNs that subscribed to the same multicast services. The MN sends the MLD report message as defined in [RFC3810]. A MN may have multiple interfaces, and requires both unicast and multicast services simultaneously. The multicast tunnel may be downlink-only or bi-directional. 4.3. Multicast Mobility Figure 6 illustrates the mobility scenario for multicast services, using the dedicated multicast LMA. The figure shows a MN with both unicast services and multicast services. In the scenario discussed below, it is assumed that the p-MAG and n-MAG are connected to both the unicast LMA and multicast LMA. When the MN detaches from the p-MAG, the p-MAG deregisters from the unicast LMA, as defined in [RFC5213]. However, the p-MAG should keep the multicast tunnel with the multicast LMA if there are still other MNs using the multicast tunnel. Even if there is no MN on the multicast tunnel, the p-MAG may decide to keep the multicast tunnel. When the MN attaches to the n-MAG, the MN sends MLD reports, and the n-MAG establishes the multicast tunnel with the multicast LMA, same as described in section 4.2. It is possible that the multicast tunnel is already available at n- MAG when the MN attaches to n-MAG. Therefore the n-MAG can distribute the multicast traffic to the MN, using either the unicast or multicast L2 connection between n-MAG and MN. Zuniga, et al. Expires April 15, 2010 [Page 9] Internet-Draft Multicast Services using PMIPv6 October 2009 MN p-MAG n-MAG LMA LMA | | | (Unicast)(Multicast) | | | | | | | | | | | |=====Unicast Tunnel==== | | | | | | | | |========= Multicast Tunnel ======= | | | | | | MN Detached | | | | | | | | | | remove unicast | | | | tunnel | | | | |-------DeReg PBU ----- >| | | | | | | | |< ---------PBA--------- | | | | | | | MN Attached | | | | To n-MAG | | | | | | | | | |---------Rtr Sol------ >| | | | | | | | |----------MLD Report-- >| | | | | |---- MLD Report ----- >| | | | | | | | |------- PBU --------- >| | | | | | | | |<------PBA ----------- | | | | | | |< --------Rtr Adv------ |==Multicast Tunnel==== | | | | | | | . . . | | Establishment of new unicast tunnel is | | the same as defined in [RFC5213] | | . . . | | | | | | Figure 6 Multicast Mobility 5. Enhanced Multicast Mobility Support This section discusses how multicast mobility can be enhanced when indications of handover triggers are available. Traditionally, the new PMIP tunnel is established after the MN is attached to the n-MAG, which can cause long delay for multicast services. In this section, handover triggers are used to establish the tunnels before the MN is attached to the n-MAG. Zuniga, et al. Expires April 15, 2010 [Page 10] Internet-Draft Multicast Services using PMIPv6 October 2009 5.1. Architecture The handover scenarios can apply to the single LMA architecture illustrated in section 3.1, or the dedicated multicast LMA illustrated in section 4.1. They can apply to both unicast and multicast services. For simplicity, only the single LMA architecture and multicast services are depicted in the figures. 5.2. Multicast Mobility Handover triggers may occur in the MN or the network. The MN can get predictive indications of imminent handover, for example, using some L2 measurements. A MN can initiate a handover due to the request of an application. A MN can also get handover command from the network. In such cases, the MN can send an indication of imminent handover to the p-MAG. The p-MAG forwards the indication to n-MAG, including the multicast information of the MN. This helps the n-MAG to establish the multicast with LMA faster. The n-MAG can use a multicast CoA for the multicast tunnel. Therefore when the MN attaches to the n-MAG, the multicast service can be available. The figure shows the binding update occurs before the handover. Binding update may happen after the handover. The p-MAG can decide to keep or tear down the old tunnel. The procedure is illustrated in Figure 7. The protocol to transport the HO trigger message is beyond the scope of this document. For example, the context transfer method proposed in [RFC4067] can be used. Zuniga, et al. Expires April 15, 2010 [Page 11] Internet-Draft Multicast Services using PMIPv6 October 2009 MN p-MAG n-MAG LMA | | | | HO trigger | | | at MN | | | | | | | |---HO Trigger -->| | | | | | | | | | | | |---HO Trigger-- >| | | | (MN multicast) | | | | info | | | | | | | | | | | | |-----PBU---- >| | | | | | | |< ---PBA----- | | | | | | | |===Multicast= | | | | tunnel | | | | | MN Detaches from p-MAG | | | MN Attaches to n-MAG | | | | | | | | | | | |<----------------- Multicast Traffic ----------- >| | | | | Figure 7 Indication of Handover Triggers between MAGs Zuniga, et al. Expires April 15, 2010 [Page 12] Internet-Draft Multicast Services using PMIPv6 October 2009 Figure 8 illustrates an alternative way that the HO trigger is passed from the MN to p-MAG, and p-MAG forwards it to LMA. This scenario applies when there is no direct interface between p-MAG and n-MAG. To reuse the mechanisms defined in [RFC5213] without modification, the HO trigger is forwarded from LMA to n-MAG, while n-MAG initiates the tunnel establishment procedure with LMA as defined in [RFC5213]. MN p-MAG n-MAG LMA | | | | HO Trigger | | | at MN | | | | | | | |--HO trigger --->| | | | | | | | |----------- HO Trigger -------- >| | | (MN multicast info) | | | | | | | |<-HO Trigger --| | | |(MN multicast) | | | | info | | | | | | | |------PBU---- >| | | | | | | |< --- PBA----- | | | | | | | |===Multicast== | | | | tunnel | | | | | MN Detaches from p-MAG | | | MN Attaches to n-MAG | | | | | | | | | | | |<-----------------Multicast Traffic-------------- >| | | | | Figure 8 Indication of Handover Triggers to LMA The handover trigger may come from the network side, for example, due to operator policies, load balancing, etc. If either LMA or MAG is aware of the imminent handover from the network side, LMA or MAG can initiate the establishment of the multicast tunnels. The steps between MAG and LMA are the same as illustrated in Figure 7 and Figure 8. Zuniga, et al. Expires April 15, 2010 [Page 13] Internet-Draft Multicast Services using PMIPv6 October 2009 There are cases that the HO trigger is not generated at p-MAG or LMA. For example, the HO trigger may be originated from a policy control entity in the network, and passed to a corresponding mobility entity in the MN. The MN can send the HO trigger to the p-MAG, same as the procedures shown in Figure 7 and Figure 8. 6. MLD/IGMP Enhancements The multicast services can be interrupted after MN handover, due to service re-initiation. Therefore the key to enhance the MLD/IGMP performance is to reduce the delay caused by service re-initiation. Two methods to reduce handover delay for multicast services are proposed below. 6.1. "Join" before Handover In the scenarios discussed in section 5, a HO trigger is sent to n- MAG before the MN attaches to n-MAG. n-MAG can use the multicast information in the HO trigger message to enable the multicast services before the handover occurs. This is like the MN "joins" before the handover. In an alternative architecture, if imminent handover is known by a mobility management entity in the network, the mobility management entity can "join" the multicast group on behalf of the MN with the appropriate multicast router in the target network. 6.2. Fast "Join" after HO Right after the handover is completed, the mobility management entity in the MN can trigger the sending of a MLD/IGMP Report immediately, without waiting for the Query from the multicast router. The above proposed mechanisms can be used independently or jointly. For example, if a "join" before handover is not working, a fast "join" after HO can still work and reduce the service delay. 7. 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]. Zuniga, et al. Expires April 15, 2010 [Page 14] Internet-Draft Multicast Services using PMIPv6 October 2009 8. IANA Considerations This document makes no request of IANA. 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. [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. 9.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-01] Schmidt, T., Waehlisch, M., Sarikaya, B., and S.Krishnan, "A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-01 (Work in progress), June 29, 2009. Zuniga, et al. Expires April 15, 2010 [Page 15] Internet-Draft Multicast Services using PMIPv6 October 2009 [RFC4067] Loughney, Ed.,J., Nakhjiri, M., Perkins, C., and R. Roodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 10. 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 April 15, 2010 [Page 16]