Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track S. Krishnan Expires: August 21, 2008 Ericsson February 18, 2008 Multicast Mobility Problem Statement Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document discusses problems that are caused due to the mobility of multicast receivers. It also divides the problems based on the protocols that they need to be fixed in. Sarikaya & Krishnan Expires August 21, 2008 [Page 1] Internet-Draft Multicast Mobility PS February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multicast Mobility Problem . . . . . . . . . . . . . . . . . . 3 4. Problems due to multicast for mobile nodes . . . . . . . . . . 5 4.1. Bandwidth wastage . . . . . . . . . . . . . . . . . . . . . 5 4.2. Lack of multicast support in mobility protocols . . . . . . 5 4.3. Scalability issues due to point-to-point links . . . . . . 5 4.4. Increased leave latency . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Sarikaya & Krishnan Expires August 21, 2008 [Page 2] Internet-Draft Multicast Mobility PS February 2008 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 which is considered "the killer application", content broadcasting and streaming over audio and video conferencing, online multiplayer gaming are applications of IP multicast technology for mobile users. In this document we will establish the requirements on supporting multicast mobility by way of improvements on various protocols on which the mobile users depend in order to receive Mobile IPTV and other multicast services 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], [RFC3376], [RFC3810] and [I-D.ietf-mboned-lightweight-igmpv3-mldv2]. 3. Multicast Mobility Problem Figure 1 illustrates the key architectural components of multicast mobility. Sarikaya & Krishnan Expires August 21, 2008 [Page 3] Internet-Draft Multicast Mobility PS February 2008 Mobile | Access Network | Service Provider Multicast User| | (Edge + Core Network) +-----+ Wireless +-----+ +------+ +--------+ -------------- | MN |--link --| BS |-----+Access+---+ Edge | / Multicast- \ +-----+ +-----+ |Router| | Router +==>| Enabled | +--+---+ +--------+ \ Internet / ------------- +-----+ +-----+ | /\ /\ | MN |------------| BS |--------+ || || +-----+ +-----+ || || | Home Network || || | || || +------+ || || |Home |==== || |Agent | || +------+ || | Content Provider || | Network || +-------+ || |Content|=======|| |Source | +-------+ Figure 1: Transport Profile of Multicast Mobility Mobile nodes (MN) attach to a base station (BS) through wireless interfaces. The Access Router (AR) is the first IP hop router of MNs. MN as the multicast receiver uses the access network to receive the content coming from the content network where the multicast source is located. The edge network aggregates between the access and the core which is the backbone infrastructure. Multicast enabled core, edge and access network is assumed in this document. MN uses Internet Group Management Protocol (IGMP) [RFC3376] or Multicast Listener Discovery (MLD) [RFC3810] to dynamically join/ leave multicast groups. IGMP/MLD runs between MN and the AR. This is called local subscription. If mobility protocol such as Mobile IP [RFC3775] is used, IGMP/MLD runs between MN and the home agent (HA) at the home network. This is called remote subscription. While the current Mboned work on light-weight IGMP/MLD [I-D.ietf-mboned-lightweight-igmpv3-mldv2] aims to simplify the original IGMPv3/MLDv2 thereby simplifying switch and host-side implementation, there is work needed to support mobility in IGMP/MLD. Currently the unicast global mobility protocol MIPv6 [RFC3775] allows remote subscription and HA tunnels multicast traffic to MN's current Sarikaya & Krishnan Expires August 21, 2008 [Page 4] Internet-Draft Multicast Mobility PS February 2008 access network. This creates a bidirectional tunnel which is inefficient. 4. Problems due to multicast for mobile nodes The currently available multicast protocols were designed based on the receivers being fixed nodes with large processing capacities. Because of this, they usually have large leave latencies and are not bandwidth efficient. They also potentially involve extensive computation capabilities on the nodes. 4.1. Bandwidth wastage Currently defined multicast protocols like IGMP and MLD send frequent messages over the link on which the mobile node is connected. This implies a wasteful use of spectrum resources on a potentially expensive wireless link. This problem can be mitigated by correctly adjusting the timing parameters on these multicast protocols. 4.2. Lack of multicast support in mobility protocols Currently defined mobility protocols like MIPv6 [RFC3775] do not really support native multicast. When a mobile node joins a multicast group, it uses its home address to do so. Hence, the multicast packets are sent to the home agent in the mobile node's home network. The home agent then encapsulates these packets inside an unicast tunnel terminating at the mobile node. Thus, multiple mobile nodes attached to the same foreign link cannot share the same multicast stream, since they receive only an unicast packet. This leads to useless duplication of multicast packets, while it could be avoided. This can be mitigated by adding multicast extensions to the binding caches of mobility protocols. 4.3. Scalability issues due to point-to-point links Currently defined multicast protocols do not scale very well if the last hop multicast router is connected to a large number of mobiles using point-to-point links. This is because the router has to keep track of each mobile on a separate interface. Thus the number of queries the router has to send out increases greatly with a large number of mobile nodes. This problem can be mitigated by minor modifications to the multicast protocols to simplify their behavior on point-to-point links. e.g. remove host suppression, remove random delays before responses etc. Sarikaya & Krishnan Expires August 21, 2008 [Page 5] Internet-Draft Multicast Mobility PS February 2008 4.4. Increased leave latency When a mobile host leaves a multicast group on an access link, the multicast router has to perform a query to determine whether any more hosts remain on the same multicast group on the same link. This increases the leave latency to an unacceptable level. There are several ways to mitigate the problem like tuning of the multicast protocol timers and explicit host tracking. 5. Security Considerations This draft is an informational document and adds no new security issues. 6. IANA Considerations This is an informational document and creates no new IANA considerations. 7. Acknowledgements This document is written based on the requirements drafts written by various authors: o Multicast Mobility in MIPv6: Problem Statement and Brief Survey, T. C. Schmidt and Matthias Waehlisch, o Problem Statement and Requirement: Mobile Multicast, H. Deng, et al., o Mobile Multicast Requirements on IGMP/MLD Protocols, H. Liu and H. Asaeda, o MIPv6 Extensions for Mobile Multicast: Problem Statement, J.F. (Tony) Guan, et al. 8. References 8.1. Normative References [I-D.ietf-mboned-lightweight-igmpv3-mldv2] Liu, H., "Lightweight IGMPv3 and MLDv2 Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-02 (work in progress), November 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sarikaya & Krishnan Expires August 21, 2008 [Page 6] Internet-Draft Multicast Mobility PS February 2008 [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. 8.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 Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: suresh.krishnan@ericsson.com Sarikaya & Krishnan Expires August 21, 2008 [Page 7] Internet-Draft Multicast Mobility PS February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sarikaya & Krishnan Expires August 21, 2008 [Page 8]