Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track T. Schmidt Expires: November 14, 2009 HAW Hamburg, Dept. Informatik S. Krishnan Ericsson May 13, 2009 Proxy Mobile IPv6 Basic Multicast Support Solution 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 November 14, 2009. 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. Sarikaya, et al. Expires November 14, 2009 [Page 1] Internet-Draft Mobile Multicast May 2009 Abstract This document describes how multicast routing can be supported in Proxy Mobile IPv6 in a way similar to Mobile IPv6. Mobile Access Gateway tunnels MLD messages from the mobile nodes to local mobility anchor. Local mobility anchor joins the multicast group and starts forwarding the received multicast packets to the mobile access gateway. In case of handover the tunnel end point changes but the operation remains anchored at the local mobility anchor. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of PMIPv6 Multicast . . . . . . . . . . . . . . . . . 4 3.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 4 4. Local Mobility Anchor Operation . . . . . . . . . . . . . . . . 5 4.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 6 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . . 6 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Sarikaya, et al. Expires November 14, 2009 [Page 2] Internet-Draft Mobile Multicast May 2009 1. Introduction More and more operators are beginning to provide the wireless broadband network services such as Mobile IPTV. Mobile IPTV service is a kind of audio/video (A/V) service which is combined with interactive data for the related or supplementary information of A/V program using bi-directional wireless broadband links. Users can enjoy the downlink A/V stream and request more detailed or value- added information via uplink simultaneously. Mobile IPTV service, which can also be described as place-shifting IPTV service, is to ensure continuous and original IPTV experiences for the users who move to the other place from where he or she was originally subscribed for [ITUIPTV]. Apart from Mobile IPTV, packet based point-to-multipoint group voice application like push to talk, content broadcasting and streaming over audio and video conferencing, online multiplayer gaming, mobile chat and instant messaging, file transfer to recipients of a group whose members could be on the move are applications of IP multicast technology for mobile users. Localized mobility management domain is an access network that supports IP level mobility without requiring client software on the mobile nodes [RFC4831]. Proxy Mobile IPv6 (PMIPv6) provides mobility support to the mobile nodes (MN) in a localized mobility management domain [RFC5213]. Mobility access gateway (MAG) proxies MN in mobility signaling (proxy binding update/acknowledgement) with the localized mobility anchor (LMA). PMIPv6 is currently an unicast mobility protocol. In this document we will describe how multicast routing can be supported in Proxy Mobile IPv6 [RFC5213]. PMIPv6 has potential to be widely used and because of this multicast mobility support in PMIPv6 is essential. PMIPv6 with multicast routing support can then be used in Mobile IPTV and other IP multicast applications to provide seamless mobility. 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 BCP 14 [RFC2119]. This document uses the terminology defined in [RFC3775] and in NetLMM Goals document [RFC4831]. Sarikaya, et al. Expires November 14, 2009 [Page 3] Internet-Draft Mobile Multicast May 2009 3. Overview of PMIPv6 Multicast This document describes Local Mobility Anchor-based basic multicast forwarding in Proxy Mobile IPv6. Mobility Access Gateway is not enabled to support multicast routing. The base protocol only supports receiver mobility. When mobile node wishes to join a multicast group it sends a Mobile Listener Discovery Version 2 (MLDv2) protocol Report message to its Mobility Access Gateway. The mobile node MUST use the link-local address as the source address to send the MLD Report and any subsequent MLD messages. Mobility Access Gateway encapsulates the message and forwards it to Local Mobility Anchor on the bi- directional tunnel between Mobility Access Gateway and Local Mobility Anchor. Local Mobility Anchor decapsulates the MLD report message from the Mobility Access Gateway. Local Mobility Anchor joins the group on behalf of the mobile node with the upstream multicast router (MR). Local Mobility Anchor sets up multicast state as multicast router for the listener which is the mobile node. Multicast data packets received by Local Mobility Anchor MUST be encapsulated and sent to Mobility Access Gateway on the bi- directional tunnel. Mobility Access Gateway decapsulates the packet and sends it to the mobile node. Since Mobility Access Gateway does not keep multicast state, if the decapsulated packet is a multicast packet Mobility Access Gateway can not send it to the mobile node. This requires Local Mobility Anchor to duplicate the multicast packet for each member in the multicast group and encapsulate the multicast packet with a unicast header. This encapsulation is done first. Next, based on the destination address (MN-HoA) the packet is encapsulated again to be sent to the Mobility Access Gateway for this mobile node [RFC3344]. In case of handover the new Mobility Access Gateway sends a Proxy Binding Update to Local Mobility Anchor. This message will update the binding cache entry so that it points for this MN-HoA to the new Mobility Access Gateway's Proxy-CoA. 3.1. IPv4 Support For mobile nodes that have IPv4 stack enabled Proxy Mobile IPv6 can provide IPv4 home address mobility support [I-D.ietf-netlmm-pmip6-ipv4-support]. Mobility access gateway gets an IPv4 home address for the mobile node as described in [I-D.ietf-netlmm-pmip6-ipv4-support]. When such a mobile node wishes Sarikaya, et al. Expires November 14, 2009 [Page 4] Internet-Draft Mobile Multicast May 2009 to join a multicast group it sends an Internet Group Management Protocol version 3 (IGMPv3) Membership Report message to its Mobility Access Gateway. IGMPv3 requires a valid IP source address to be used as the source address of the membership report message. Mobile node MUST use its home address as the source address of the membership report message. Mobility access gateway tunnels the report message to the local mobility anchor. Local mobility anchor decapsulates the IGMP report message from the Mobility Access Gateway. Local Mobility Anchor joins the group on behalf of the mobile node with the upstream multicast router (MR). Local Mobility Anchor sets up multicast state as multicast router for the listener which is the mobile node. When packets are received for the multicast group that the mobile node is subscribed, local mobility anchor encapsulates each packet and sends it to each mobile node on the tunnel between local mobility anchor and mobile access gateway. 4. Local Mobility Anchor Operation Local Mobility Anchor is the multicast router for all mobile nodes in Proxy Mobile IPv6 domain and performs the multicast router part of MLDv2 [RFC3810]. After receiving MLD Report message from the mobile node, Local Mobility Anchor joins the multicast tree for this multicast group with an upstream router. MLDv2 nodes maintain multicast listening state per multicast address which keeps track of the sources of the multicast group. This allows a simple forwarding downstream of the multicast packet received from one of the sources. As for the group membership, local mobility anchor receives information about the receivers by sending periodic queries to the mobile nodes. Since Proxy Mobile IPv6 supports Per-MN prefix model the query messages and report messages are sent individually to each mobile node. This means that each group can have only one member on the link between local mobility anchor and mobile node. However a given multicast group may have more than one member each located on a different point-to-point link. Local Mobility Anchor MUST maintain multicast membership status state for the the mobile nodes. This state consists of a set of records of the form: (IPv6 multicast address, receiver list) where the receiver list is a potentially long list of link-local source addresses of all the mobile nodes that are currently members Sarikaya, et al. Expires November 14, 2009 [Page 5] Internet-Draft Mobile Multicast May 2009 of this multicast group. When a multicast packet is received from the upstream multicast router, local mobility anchor searches the multicast membership status state for the source multicast address. When a match is found, local mobility anchor tunnels the packet to each member in the receiver list on the bi-directional tunnel between local mobility anchor and mobile access gateway. For each receiver, local mobility anchor searches the binding cache entry to find a match to the link local source address. When a match is found, the corresponding mobile access gateway address, i.e Proxy-CoA and mobile node home address, i.e. MN-HoA are used in formating the tunneled packet. The format of the tunneled packet is shown below (where CP stands for the content provider for the multicast channel): IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= LMAA, dst= MN-HOA ) /* Packet Header */ IPv6 header (src=CP, dst= Multicast group) /* Multicast Packet */ Upper layer protocols /* Packet Content*/ Figure 1: Tunneled Multicast Packet from LMA to MAG 4.1. IPv4 Support If IPv4 transport is used between mobile access gateway and local mobility anchor, the format of the tunneled packet is shown below: IPv4 header (src= IPv4-LMAA1, dst= IPv4-Proxy-CoA1) /* Tunnel Header */ IPv4 header (src= IPv4-LMAA1, dst= IPv4-MN-HoA1 ) /* Packet Header */ IPv4 header (src=CP, dst= Multicast group) /* Multicast Packet */ Upper layer protocols /* Packet Content*/ Figure 2: Tunneled Multicast IPv4 Packet from LMA to MAG 5. Mobile Access Gateway Operation Proxy Mobile IPv6 base specification [RFC5213] requires Mobile Access Gateway to not to forward the packets that are sent with the link- local source address to support Duplicate Address Detection protocol. However in this document we modify this in order to allow MLDv2 packets to be exchanged between Local Mobility Anchor and mobile node. Mobile Access Gateway MUST tunnel a packet from a mobile node connected to its access link with an IP destination address of FF02: Sarikaya, et al. Expires November 14, 2009 [Page 6] Internet-Draft Mobile Multicast May 2009 0:0:0:0:0:0:16 (all MLDv2-capable routers) through the bi- directional tunnel established between itself and the mobile node's local mobility anchor. MLDv2 also requires the source address of such packets to be link-local address of the mobile node. 6. Mobile Node Operation In order to receive multicast packets from the multicast groups of interest, Mobile node must be MLDv2-capable. MLDv2 is run between the mobile node and Local Mobility Anchor with the mobile node being the multicast address listener and local mobility anchor the multicast router. When an application wants to join a multicast group such as receive IPTV the application makes a join socket call. This triggers MLDv2 layer to send Multicast Listener Report to Mobile Access Gateway which tunnels it to local mobility anchor. The source address of the MLDv2 Report message is mobile node's link-local address and the destination address is FF02:0:0:0:0:0:0:16, i.e. MLDv2 capable routers group address. Local mobility anchor as multicast router joins the multicast group and gets attached to the multicast tree associated with this multicast group. Multicast packets sent to the multicast group address are received by the local mobility anchor which tunnels them to mobile access gateway. By the time mobile node sends the first MLDv2 report message mobile access gateway must have registered this mobile node to the local mobility anchor. Proxy Mobile IPv6 base protocol assures that mobile-node link local address is unique in the point-to-point link between the mobile node and mobile access gateway and also the mobile node is registered with its local mobility anchor (LMA) (using Proxy Binding Update/ Acknowledgement exchange between mobile access gateway and local mobility anchor) before the mobile node completes the duplicate address detection (DAD) operation (Section 6.8 in [RFC5213]). Mobile node MUST send MLDv2 report message after DAD operation is completed. Because mobile access gateway is not MLDv2 capable, the mobile node receives all multicast data packets from local mobility anchor as unicast packets with the multicast datagram encapsulated. The mobile node MUST be capable of decapsulating packets sent to its home address in order to receive multicast datagrams. Sarikaya, et al. Expires November 14, 2009 [Page 7] Internet-Draft Mobile Multicast May 2009 7. Security Considerations This draft introduces no additional messages. Compared to [RFC3810] and [RFC5213] there is no additional threats to be introduced. 8. IANA Considerations None. 9. Acknowledgements TBD. 10. References 10.1. Normative References [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Sarikaya, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 (work in progress), April 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [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. [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [RFC5213] Sarikaya, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Sarikaya, et al. Expires November 14, 2009 [Page 8] Internet-Draft Mobile Multicast May 2009 10.2. Informative References [ITUIPTV] "IPTV Service Scenarios", May 2007. Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Email: sarikaya@ieee.org Thomas C. Schmidt HAW Hamburg, Dept. Informatik Berliner Tor 7 D-20099 Hamburg, Germany Email: Schmidt@informatik.haw-hamburg.de Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: suresh.krishnan@ericsson.com Sarikaya, et al. Expires November 14, 2009 [Page 9]