idnits 2.17.00 (12 Aug 2021) /tmp/idnits64176/draft-sarikaya-multimob-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-mboned-lightweight-igmpv3-mldv2 has been published as RFC 5790 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track S. Krishnan 5 Expires: August 21, 2008 Ericsson 6 February 18, 2008 8 Multicast Mobility Problem Statement 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document discusses problems that are caused due to the mobility 43 of multicast receivers. It also divides the problems based on the 44 protocols that they need to be fixed in. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Multicast Mobility Problem . . . . . . . . . . . . . . . . . . 3 51 4. Problems due to multicast for mobile nodes . . . . . . . . . . 5 52 4.1. Bandwidth wastage . . . . . . . . . . . . . . . . . . . . . 5 53 4.2. Lack of multicast support in mobility protocols . . . . . . 5 54 4.3. Scalability issues due to point-to-point links . . . . . . 5 55 4.4. Increased leave latency . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 More and more operators are beginning to provide the wireless 68 broadband network services such as Mobile IPTV. Mobile IPTV service 69 is a kind of audio/video (A/V) service which is combined with 70 interactive data for the related or supplementary information of A/V 71 program using bi-directional wireless broadband links. Users can 72 enjoy the downlink A/V stream and request more detailed or value- 73 added information via uplink simultaneously. Mobile IPTV service, 74 which can also be described as place-shifting IPTV service, is to 75 ensure continuous and original IPTV experiences for the users who 76 move to the other place from where he or she was originally 77 subscribed for [ITUIPTV]. 79 Apart from Mobile IPTV which is considered "the killer application", 80 content broadcasting and streaming over audio and video conferencing, 81 online multiplayer gaming are applications of IP multicast technology 82 for mobile users. In this document we will establish the 83 requirements on supporting multicast mobility by way of improvements 84 on various protocols on which the mobile users depend in order to 85 receive Mobile IPTV and other multicast services 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in BCP 14 [RFC2119]. 93 This document uses the terminology defined in [RFC3775], [RFC3376], 94 [RFC3810] and [I-D.ietf-mboned-lightweight-igmpv3-mldv2]. 96 3. Multicast Mobility Problem 98 Figure 1 illustrates the key architectural components of multicast 99 mobility. 101 Mobile | Access Network | Service Provider 102 Multicast User| | (Edge + Core Network) 104 +-----+ Wireless +-----+ +------+ +--------+ -------------- 105 | MN |--link --| BS |-----+Access+---+ Edge | / Multicast- \ 106 +-----+ +-----+ |Router| | Router +==>| Enabled | 107 +--+---+ +--------+ \ Internet / 108 ------------- 109 +-----+ +-----+ | /\ /\ 110 | MN |------------| BS |--------+ || || 111 +-----+ +-----+ || || 112 | Home Network || || 113 | || || 114 +------+ || || 115 |Home |==== || 116 |Agent | || 117 +------+ || 118 | Content Provider || 119 | Network || 120 +-------+ || 121 |Content|=======|| 122 |Source | 123 +-------+ 125 Figure 1: Transport Profile of Multicast Mobility 127 Mobile nodes (MN) attach to a base station (BS) through wireless 128 interfaces. The Access Router (AR) is the first IP hop router of 129 MNs. MN as the multicast receiver uses the access network to receive 130 the content coming from the content network where the multicast 131 source is located. The edge network aggregates between the access 132 and the core which is the backbone infrastructure. Multicast enabled 133 core, edge and access network is assumed in this document. 135 MN uses Internet Group Management Protocol (IGMP) [RFC3376] or 136 Multicast Listener Discovery (MLD) [RFC3810] to dynamically join/ 137 leave multicast groups. IGMP/MLD runs between MN and the AR. This 138 is called local subscription. If mobility protocol such as Mobile IP 139 [RFC3775] is used, IGMP/MLD runs between MN and the home agent (HA) 140 at the home network. This is called remote subscription. While the 141 current Mboned work on light-weight IGMP/MLD 142 [I-D.ietf-mboned-lightweight-igmpv3-mldv2] aims to simplify the 143 original IGMPv3/MLDv2 thereby simplifying switch and host-side 144 implementation, there is work needed to support mobility in IGMP/MLD. 146 Currently the unicast global mobility protocol MIPv6 [RFC3775] allows 147 remote subscription and HA tunnels multicast traffic to MN's current 148 access network. This creates a bidirectional tunnel which is 149 inefficient. 151 4. Problems due to multicast for mobile nodes 153 The currently available multicast protocols were designed based on 154 the receivers being fixed nodes with large processing capacities. 155 Because of this, they usually have large leave latencies and are not 156 bandwidth efficient. They also potentially involve extensive 157 computation capabilities on the nodes. 159 4.1. Bandwidth wastage 161 Currently defined multicast protocols like IGMP and MLD send frequent 162 messages over the link on which the mobile node is connected. This 163 implies a wasteful use of spectrum resources on a potentially 164 expensive wireless link. This problem can be mitigated by correctly 165 adjusting the timing parameters on these multicast protocols. 167 4.2. Lack of multicast support in mobility protocols 169 Currently defined mobility protocols like MIPv6 [RFC3775] do not 170 really support native multicast. When a mobile node joins a 171 multicast group, it uses its home address to do so. Hence, the 172 multicast packets are sent to the home agent in the mobile node's 173 home network. The home agent then encapsulates these packets inside 174 an unicast tunnel terminating at the mobile node. Thus, multiple 175 mobile nodes attached to the same foreign link cannot share the same 176 multicast stream, since they receive only an unicast packet. This 177 leads to useless duplication of multicast packets, while it could be 178 avoided. This can be mitigated by adding multicast extensions to the 179 binding caches of mobility protocols. 181 4.3. Scalability issues due to point-to-point links 183 Currently defined multicast protocols do not scale very well if the 184 last hop multicast router is connected to a large number of mobiles 185 using point-to-point links. This is because the router has to keep 186 track of each mobile on a separate interface. Thus the number of 187 queries the router has to send out increases greatly with a large 188 number of mobile nodes. This problem can be mitigated by minor 189 modifications to the multicast protocols to simplify their behavior 190 on point-to-point links. e.g. remove host suppression, remove random 191 delays before responses etc. 193 4.4. Increased leave latency 195 When a mobile host leaves a multicast group on an access link, the 196 multicast router has to perform a query to determine whether any more 197 hosts remain on the same multicast group on the same link. This 198 increases the leave latency to an unacceptable level. There are 199 several ways to mitigate the problem like tuning of the multicast 200 protocol timers and explicit host tracking. 202 5. Security Considerations 204 This draft is an informational document and adds no new security 205 issues. 207 6. IANA Considerations 209 This is an informational document and creates no new IANA 210 considerations. 212 7. Acknowledgements 214 This document is written based on the requirements drafts written by 215 various authors: 217 o Multicast Mobility in MIPv6: Problem Statement and Brief Survey, 218 T. C. Schmidt and Matthias Waehlisch, 219 o Problem Statement and Requirement: Mobile Multicast, H. Deng, et 220 al., 221 o Mobile Multicast Requirements on IGMP/MLD Protocols, H. Liu and H. 222 Asaeda, 223 o MIPv6 Extensions for Mobile Multicast: Problem Statement, J.F. 224 (Tony) Guan, et al. 226 8. References 228 8.1. Normative References 230 [I-D.ietf-mboned-lightweight-igmpv3-mldv2] 231 Liu, H., "Lightweight IGMPv3 and MLDv2 Protocols", 232 draft-ietf-mboned-lightweight-igmpv3-mldv2-02 (work in 233 progress), November 2007. 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 239 Thyagarajan, "Internet Group Management Protocol, Version 240 3", RFC 3376, October 2002. 242 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 243 in IPv6", RFC 3775, June 2004. 245 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 246 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 248 8.2. Informative References 250 [ITUIPTV] "IPTV Service Scenarios", May 2007. 252 Authors' Addresses 254 Behcet Sarikaya 255 Huawei USA 256 1700 Alma Dr. Suite 500 257 Plano, TX 75075 259 Email: sarikaya@ieee.org 261 Suresh Krishnan 262 Ericsson 263 8400 Decarie Blvd. 264 Town of Mount Royal, QC 265 Canada 267 Email: suresh.krishnan@ericsson.com 269 Full Copyright Statement 271 Copyright (C) The IETF Trust (2008). 273 This document is subject to the rights, licenses and restrictions 274 contained in BCP 78, and except as set forth therein, the authors 275 retain all their rights. 277 This document and the information contained herein are provided on an 278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 280 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 281 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 282 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 285 Intellectual Property 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at 307 ietf-ipr@ietf.org. 309 Acknowledgment 311 Funding for the RFC Editor function is provided by the IETF 312 Administrative Support Activity (IASA).