idnits 2.17.1 draft-von-hugo-multimob-future-work-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors 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 date (June 8, 2010) is 5064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.asaeda-igmp-mld-optimization' is mentioned on line 125, but not defined == Missing Reference: 'I-D.asaeda-igmp-mld-mobility-extension' is mentioned on line 127, but not defined == Missing Reference: 'RFC5568' is mentioned on line 348, but not defined == Unused Reference: 'RFC3314' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '23246' is defined on line 490, but no explicit reference was found in the text == Unused Reference: '23401' is defined on line 494, but no explicit reference was found in the text == Unused Reference: '23402' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'I-D.asaeda-multimob-igmp-mld-optimization' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-manet-smf' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC5121' is defined on line 586, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-asaeda-multimob-igmp-mld-mobility-extensions-03 == Outdated reference: A later version (-05) exists of draft-asaeda-multimob-igmp-mld-optimization-02 == Outdated reference: A later version (-11) exists of draft-asaeda-multimob-pmip6-extension-02 == Outdated reference: A later version (-07) exists of draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01 == Outdated reference: A later version (-06) exists of draft-zuniga-multimob-smspmip-02 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-10 == Outdated reference: A later version (-07) exists of draft-ietf-multimob-pmipv6-base-solution-02 Summary: 2 errors (**), 0 flaws (~~), 22 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group D. von Hugo 3 Internet-Draft Deutsche Telekom Laboratories 4 Intended status: Informational H. Asaeda 5 Expires: December 9, 2010 Keio University 6 B. Sarikaya 7 Huawei USA 8 P. Seite 9 France Telecom - Orange 10 June 8, 2010 12 Evaluation of further issues on Multicast Mobility: Potential future 13 work for WG MultiMob 14 16 Abstract 18 The WG MultiMob aims at defining a basic mobile multicast solution 19 leveraging on network localized mobility management, i.e. Proxy 20 Mobile IPv6 protocol. The solution would be basically based on 21 multicast group management, i.e. IGMP/MLD, proxying at the access 22 gateway. If such a basic solution is essential from an operational 23 point of view, challenges with efficient resource utilization and 24 user perceived service quality still persist. These issues may 25 prevent large scale deployments of mobile multicast applications. 27 This document attempts to identify topics for near future extension 28 of work such as modifying multimob base solution, PMIPv6 and MLD/ 29 IGMP for optimal multicast support, and adaptation of Handover 30 optimization. Far future items such as extending to and modifying 31 of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of 32 multiple flows and multihoming will be dealt with in a future 33 version. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 This Internet-Draft will expire on December 9, 2010. 58 Copyright Notice 60 Copyright (c) 2010 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3. IGMP/MLD Proxy Architecture . . . . . . . . . . . . . . . . . 7 78 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Modification of base PMIPv6 for optimal multicast 80 support . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.2. Modification of MLD/IGMP for optimal multicast support . . 8 82 4.3. Consideration of Handover Optimization . . . . . . . . . . 9 83 4.4. Specific PMIP deployment issues . . . . . . . . . . . . . 9 84 5. Requirements on Solutions . . . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 Chartered work of WG MultiMob focuses on documentation of proper 96 configuration and usage of existing (specified standard) protocols 97 within both mobility and multicast related areas to enable and 98 support mobility for multicast services and vice versa. The current 99 WG document [I-D.ietf-multimob-pmipv6-base-solution] does not address 100 specific optimizations and efficiency improvements of multicast 101 routing for network-based mobility and thus the operation may be not 102 resource efficient nor grant the service quality expected by the end 103 user. 105 The described solution resolves the problem to ensure multicast 106 reception in PMIPv6-enabled [RFC5213] networks without appropriate 107 multicast support. However it neither automatically minimizes 108 multicast forwarding delay to provide seamless and fast handovers for 109 real-time services nor minimizes packet loss and reordering that 110 result from multicast handover management as stated in [RFC5757]. 111 Also Route Optimization is out of scope of the basic solution - an 112 issue for reducing amount of transport resource usage and 113 transmission delay. Thus possible enhancements and issues for 114 solutions beyond a basic solution need to be described to enable 115 current PMIPv6 protocols to fully support efficient mobile multicast 116 services. Such extensions may include protocol modifications for 117 both mobility and multicast related protocols to achieve 118 optimizations for resource efficient and performance increasing 119 multimob approaches. The document includes the case of mobile 120 multicast senders using Any Source Multicast (ASM) and Source 121 Specific Multicast (SSM) [RFC4607]. 123 This document focuses on discussion work on multicast protocols 124 such as IGMP/MLD operational tuning (e.g. as proposed in 125 [I-D.asaeda-igmp-mld-optimization]) and enhancements of IGMP/MLD 126 protocol behaviors and messages for optimal multicast support 127 (proposed in [I-D.asaeda-igmp-mld-mobility-extension]). 129 An alternative approach proposes the addition of acknowledgement 130 messages on group management ([I-D.liu-multimob-reliable-igmp-mld]) 131 and changes the unreliable protocol concept. 133 Furthermore a modification of PMIPv6 by introducing a dedicated 134 multicast tunnel and support of local routing is discussed in 135 [I-D.asaeda-multimob-pmip6-extension]. Other performance 136 improvements have been outlined in 137 [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] where extensions to 138 Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568], and the corresponding 139 extension for Proxy MIPv6 operation [I-D.ietf-mipshop-pfmipv6]. 141 Another type of multimob work aims directly at enhancements of the 142 current multimob base solution 143 [I-D.ietf-multimob-pmipv6-base-solution] towards introduction of 144 multicast traffic replication mechanisms and a reduction of the 145 protocol complexity in terms of time consuming tunnel set-up by 146 definition of pre- or post-configured tunnels (as provided by e.g. 147 [I-D.zuniga-multimob-smspmip]). Further work within this topic deals 148 with direct routing (e.g. [I-D.sijeon-multimob-mms-pmip6]) and with 149 dynamic or automatic tunnel configuration (see e.g. 150 [I-D.ietf-mboned-auto-multicast]). 152 A large field of additional investigations which are partly described 153 in detail in [RFC5757] will be mentioned for completeness and may be 154 subject of a later WG re-chartering. 156 +------+ +------+ 157 | MN | =====> | MN | 158 +------+ +------+ 159 | . 160 | . 161 +--------+ +--------+ 162 | MAG 1 | | MAG 2 | 163 |IGMP/MLD| |IGMP/MLD| 164 |Proxy | |Proxy | 165 +--------+ +--------+ 166 | | 167 *** *** *** *** 168 * ** ** ** * 169 * * 170 * Internet Subnet * 171 * * 172 * ** ** ** * 173 *** *** *** *** 174 | | 175 +-------+ +-------+ 176 | LMA 1 | | LMA 2 | 177 +-------+ +-------+ 178 | | 179 *** *** *** *** 180 * ** ** ** * 181 * * 182 * Fixed Internet * 183 * * 184 * ** ** ** * 185 *** *** *** *** 186 | 187 +------+ 188 | CN | 189 +------+ 191 Figure 1: MultiMob Scenario for chartered PMIP6 issue 193 +------+ +------+ +------+ 194 | MN | =====> | MN | ====> | MN | 195 +------+ +------+ +------+ 196 | . . 197 | . . 198 | . . 199 +--------+ +--------+ +--------+ +--------+ 200 | MAG 1 | | MAG 2 | | AR 1 | | AR 2 | 201 |IGMP/MLD| |IGMP/MLD| |IGMP/MLD| |IGMP/MLD| 202 | Proxy | | Proxy | | Proxy | | Proxy | 203 +--------+ +--------+ +--------+ +--------+ 204 \ / | | 205 *** *** *** *** *** *** *** *** 206 * ** *** ** * * ** *** ** * 207 * * * * 208 * Internet Subnet 1 * * Internet Subnet 2 * 209 * * * * 210 * ** *** ** * * ** *** ** * 211 *** *** *** *** *** *** *** *** 212 | | | 213 +-------+ +-------+ | 214 | LMA 1 | | LMA 2 | / 215 +-------+ +-------+ / 216 \ | / 217 *** *** *** *** / *** *** *** *** 218 * ** ** ** * / * ** *** ** * 219 * * * * 220 * Fixed Internet * * Internet Subnet 3 * 221 * *_____* * 222 * ** ** ** * * ** *** ** * 223 *** *** *** *** *** .*** *** *** 224 | . 225 +-------+ +-------+ 226 | CN | ====> | CN | 227 +-------+ +-------+ 229 Figure 2: MultiMob scenario for extended MultiMob issues 231 Figure 1 illustrates the key components of the foreseen basic 232 Multimob solution. The extended multicast mobility scenario, leading 233 to above issues, is sketched in Figure 2. 235 In summary additional to a 'Single hop, link, flow' Proxy MIP 236 mobility for listening MNs (scenario shown in Figure 1), future work 237 towards a complete performance-optimized scenario of a 'Multi-hop, 238 -homed, -flow' client mobility (i.e. including MIPv6 [RFC3775] and 239 DSMIPv6 [RFC5555]) would cover a plurality of issues. For the near 240 future we see the following issues as most important: 242 o Extension of multimob base solution 244 o Modification of base PMIPv6 and MLD/IGMP for optimal multicast 245 support. 247 o Consideration of Handover optimization. 249 All further issues which would include extensions to and 250 modifications of MIPv4/v6 and DSMIP using IGMP/MLD Proxy and the 251 Foreign Agent/Access Router, consideration of sender (source) 252 mobility, support of multiple flows on multihomed mobile nodes, 253 multi-hop transmission, Routing optimization, and so forth will be 254 topics for a potential next stage of future work extension. 256 2. Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in BCP 14 [RFC2119]. 262 This document uses the terminology defined in [RFC3775], [RFC3376], 263 [RFC3810], [RFC5213], [RFC5757]. 265 3. IGMP/MLD Proxy Architecture 267 Multimob basic solution is based on IGMPv3/MLDv2 Proxy support at the 268 mobile access gateway (MAG) of Proxy Mobile IPv6 as shown in 269 Figure 1. IGMPv3/MLDv2 proxy keeps multicast state on the 270 subscriptions of the mobile nodes and only an aggregate state is kept 271 at the local mobility anchor (LMA). When LMA receives multicast data 272 it can forward it to the MAG without duplication because MAG takes of 273 the packet duplication. This leads to solving the avalanche problem. 275 By keeping multicast state locally, IGMPv3/MLDv2 Proxy introduces 276 mobility related problems such as possible packet loss when a mobile 277 node does a handover to another MAG and its multicast state is not 278 modified fast enough at the LMA. 280 IGMPv3/MLDv2 introduces tunnel convergence problem which occurs when 281 a given MAG serves MNs that belong to different LMAs and MNs 282 subscribe to the same multicast group. In that case MNs receive 283 duplicate multicast data forwarded from more than one LMA. 285 It can be foreseen that mobile access gateways will serve both mobile 286 and fixed terminals concurrently. The tuning of multicast-related 287 protocol parameters based on the terminal characteristics is needed. 288 Parameters only applicable to mobile users need to be distinguished 289 from the parameters applicable to fixed users. It should be also 290 possible to distinguish between slow and fast movement and handover 291 frequency to form corresponding tunnels for mobile users. 293 Based on the above observations we will state the problems next and 294 then list the requirements on possible solutions. 296 4. Problem Description 298 The general issues of multicast mobility are extensively discussed 299 and described in [RFC5757]. To reduce the complexity of the 300 plethora of requirements listed in [RFC5757] and also in 301 [I-D.deng-multimob-pmip6-requirement] this document summarises some 302 lightweight solutions for multicast mobility which allow for easy 303 deployment within realistic scenarios and architectures. Moreover 304 we focus on approaches building directly on basic MultiMob solution 305 [I-D.ietf-multimob-pmipv6-base-solution] which is based on IGMP/MLD 306 Proxy functionality at the mobile access gateway, and for which 307 already solution proposals have been described. 309 4.1. Modification of base PMIPv6 for optimal multicast support 311 Currently discussed aspects of multicast optimization for PMIPv6 312 include introduction of multicast tunnels and support of local 313 routing such as described in [I-D.asaeda-multimob-pmip6-extension]. 314 For a PMIPv6 domain the establishment of a dedicated multicast tunnel 315 is proposed which may either be dynamically set up and released or be 316 pre-configured in a static manner. Both mobility entities MAG and 317 LMA may be operate as MLD proxy or multicast router. 318 Since further functional enhancements of PMIPv6 are currently under 319 way in NETEXT WG, both the impact of new features on Mobile Multicast 320 as well as such a Multicast-initiated proposal for PMIPv6 321 modification have to be considered in a continuous exchange process 322 between MultiMob and NETEXT WGs. 324 4.2. Modification of MLD/IGMP for optimal multicast support 326 Potential approaches for enhancement of group management as specified 327 e.g. by MLDv2 [RFC3810] include operational improvements such as 328 proper tuning in terms of default timer value modification, specific 329 query message introduction, and standard (query) reaction 330 suppression, beside introducing multicast router attendance control 331 in terms of e.g. specification of a Listener Hold message as proposed 332 in [I-D.asaeda-multimob-igmp-mld-mobility-extensions]. 334 4.3. Consideration of Handover Optimization 336 Ideally the customer experience while using multicast services should 337 not be affected by transmission issues whether the terminal is 338 operated in a fixed or a mobile environment. This implies not only 339 that the terminal should be unaware of changes at network layer 340 connectivity (seamless communication) as is typically the case in a 341 PMIPv6 domain, but also that any impact of connectivity changes 342 (handover) should be minimized. In the framework of Multimob this 343 relates to reduction of delay, packet loss, and packet reordering 344 effort for mobile multicast by applying fast handover mechanisms, 345 which have originally been developed for unicast traffic to multicast 346 group management. [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] 347 works on specification of extension of the Mobile IPv6 Fast Handovers 348 (FMIPv6) [RFC5568] and the Fast Handovers for Proxy Mobile IPv6 349 (PFMIPv6) [I-D.ietf-mipshop-pfmipv6] protocols to include multicast 350 traffic management in fast handover operations. Issues for further 351 work are details of including multicast group messaging in context 352 transfer, for both predictive and reactive handover mode, as well as 353 details of corresponding message exchange protocols and message 354 design. 356 4.4. Specific PMIP deployment issues 358 Currently several proposals are under work which describe extensions 359 of the base protocol WG draft 360 [I-D.ietf-multimob-pmipv6-base-solution]. While MAG operation will 361 remain that of an MLD proxy additional LMA functionalities are 362 described in [I-D.zuniga-multimob-smspmip] which allow for 363 replication of multicast traffic and solution of the tunnel 364 convergence problem. The dedicated multicast LMA may either set up 365 dedicated multicast tunnels dynamically or a-priory via 366 pre-configuration or a delayed release. 368 Another solution on dynamic and/or automatic tunnel configuration is 369 proposed within multicast WG MBONED [I-D.ietf-mboned-auto-multicast]. 371 A direct or local routing approach is described in 372 [I-D.sijeon-multimob-mms-pmip6]. This scenario may hold for short 373 term deployment focusing on an architecture where multicast traffic 374 is provided via the home network. However, depending on the network 375 topology, namely the location of the content delivery network, the 376 LMA may not be on the optimal multicast service delivery path. This 377 enables mobile nodes to access locally available multicast services 378 such as local channels. 380 Figure 3 illustrates the use-case for local routing. 382 +----+ 383 |LMA | 384 +----+ 385 | 386 | 387 *** *** *** *** 388 * ** ** ** * 389 * * +-------------+ 390 * Local Routing * _____ | Content | 391 * * | Delivery | 392 | Network | 393 * ** ** ** * +-------------+ 394 *** *** *** *** 395 || || 396 +----+ +----+ 397 |MAG1| |MAG2| 398 +----+ +----+ 399 | | | 400 | | | 401 MN1 MN2 MN3 403 Figure 3: local Multicast routing 405 In such a case, the MAG should act as a multicast router to construct 406 the optimal multicast delivery path. If the MAG also supports MLD 407 proxy function issue raises up on the dual mode behaviour. In such a 408 case, a pragmatic approach could be to leverage only on multicast 409 routing at the MAG in the PMIP domain. 411 Whatever is the MAG operation mode, the multicast state is locally 412 kept at the access gateway, so unknown from the mobility anchor. In 413 other words, the multicast service is independent from the mobility 414 service that the mobile node is receiving from the network in the 415 form of PMIPv6 or DSMIPv6. However, handover support is still 416 desirable but cannot be provided by the mobility anchor (i.e. HA or 417 LMA). In such a case mobility support for locally available 418 multicast should be provided by extending multicast protocols of IGMP 419 or MLD. 421 5. Requirements on Solutions 423 This section tries to identify requirements from the issues discussed 424 in previous section. 426 o Seamless handover (low latency and during the handover). 427 o Similar packet loss to unicast service. 428 o Multiple LMAs architecture. 429 o Agnostic mobile host re-subscription. So, MAGs must be able to 430 retrieve multicast contexts of the mobile nodes. 431 o Solution address IPv6, IPv4 only and dual stack nodes. 432 o Supports sender (source) mobility. 433 o Optimal local routing. 434 o To be completed... 436 6. Security Considerations 438 This draft introduces no additional messages. Compared to [RFC3376], 439 [RFC3810], [RFC3775], and [RFC5213] there have no additional threats 440 been introduced. 442 7. IANA Considerations 444 Whereas this document does not explicitly introduce requests to IANA 445 some of the proposals referenced above (such as 446 [I-D.asaeda-multimob-pmip6-extension] and 447 [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast]) specify flags for 448 mobility messages or options. For details please see those 449 documents. 451 8. Acknowledgements 453 The authors would thank all active members of MultiMob WG, especially 454 (in no specific order) Gorry Fairhurst, Jouni Korhonen, Thomas 455 Schmidt, Suresh Krishnan and Matthias Waehlisch for providing 456 continuous support and helpful comments. 458 9. References 460 9.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 466 Generation Partnership Project (3GPP) Standards", 467 RFC 3314, September 2002. 469 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 470 Thyagarajan, "Internet Group Management Protocol, Version 471 3", RFC 3376, October 2002. 473 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 474 in IPv6", RFC 3775, June 2004. 476 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 477 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 479 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 480 IP", RFC 4607, August 2006. 482 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 483 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 485 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 486 Routers", RFC 5555, June 2009. 488 9.2. Informative References 490 [23246] "3GPP TS 23.246 V8.2.0, Multimedia Broadcast/Multicast 491 Service (MBMS); Architecture and functional description 492 (Release 8).", 2008. 494 [23401] "3GPP TS 23.401 V8.2.0, General Packet Radio Service 495 (GPRS) enhancements for Evolved Universal Terrestrial 496 Radio Access Network (E-UTRAN) access (Release 8).", 2008. 498 [23402] "3GPP TS 23.402 V8.4.1, Architecture enhancements for non- 499 3GPP accesses (Release 8).", 2009. 501 [I-D.asaeda-multimob-igmp-mld-mobility-extensions] 502 Asaeda, H. and T. Schmidt, "IGMP and MLD Hold and Release 503 Extensions for Mobility", 504 draft-asaeda-multimob-igmp-mld-mobility-extensions-03 505 (work in progress), July 2009. 507 [I-D.asaeda-multimob-igmp-mld-optimization] 508 Asaeda, H. and S. Venaas, "Tuning the Behavior of IGMP 509 and MLD for Mobile Hosts and Routers", 510 draft-asaeda-multimob-igmp-mld-optimization-02 (work in 511 progress), March 2010. 513 [I-D.asaeda-multimob-pmip6-extension] 514 Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for 515 Multicast", draft-asaeda-multimob-pmip6-extension-02 (work 516 in progress), July 2009. 518 [I-D.deng-multimob-pmip6-requirement] 519 Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, 520 "Multicast Support Requirements for Proxy Mobile IPv6", 521 draft-deng-multimob-pmip6-requirement-02 (work in 522 progress), July 2009. 524 [I-D.liu-multimob-reliable-igmp-mld] 525 Liu, H. and Q. Wu, "Reliable IGMP and MLD Protocols in 526 Wireless Environment", 527 draft-liu-multimob-reliable-igmp-mld-00 (work in 528 progress), March 2010. 530 [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] 531 Schmidt, T., Waehlisch, M., Koodli, R., and G. Fairhurst, 532 "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast 533 Handovers", 534 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01 (work 535 in progress), March 2010. 537 [I-D.sijeon-multimob-mms-pmip6] 538 Jeon, S. and Y. Kim, "Mobile Multicasting Support in 539 Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02 540 (work in progress), March 2010 542 [I-D.zuniga-multimob-smspmip] 543 Zuniga, J., Lu, G., and A. Rahman, "Support Multicast 544 Services Using Proxy Mobile IPv6", 545 draft-zuniga-multimob-smspmip-02 (work in progress), 546 June 2010. 548 [I-D.ietf-mboned-auto-multicast] 549 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and 550 T. Pusateri, "Automatic IP Multicast Without Explicit 551 Tunnels (AMT)", draft-ietf-mboned-auto-multicast-10 (work 552 in progress), March 2010 554 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] 555 Madanapalli, S., Park, S., Chakrabarti, S., and G. 556 Montenegro, "Transmission of IPv4 packets over IEEE 557 802.16's IP Convergence Sublayer", 558 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 (work in 559 progress), June 2010. 561 [I-D.ietf-manet-smf] 562 Macker, J. (editor), "Simplified Multicast Forwarding", 563 draft-ietf-manet-smf-10 (work in progress), March 2010. 565 [I-D.ietf-mipshop-pfmipv6] 566 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 567 Xia, "Fast Handovers for Proxy Mobile IPv6", 568 draft-ietf-mipshop-pfmipv6-14 (work in progress), May 569 2010 571 [I-D.ietf-multimob-pmipv6-base-solution] 572 Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 573 Deployment for Multicast Listener Support in PMIPv6 574 Domains", 575 draft-ietf-multimob-pmipv6-base-solution-02 (work in 576 progress), May 2010. 578 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 579 Mobility in MIPv6: Problem Statement and Brief Survey", 580 RFC 5757, June 2010. 582 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 583 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 584 RFC 3963, January 2005. 586 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 587 Madanapalli, "Transmission of IPv6 via the IPv6 588 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 589 February 2008. 591 Authors' Addresses 593 Dirk von Hugo 594 Deutsche Telekom Laboratories 595 Deutsche-Telekom-Allee 7 596 64295 Darmstadt, Germany 598 Email: dirk.von-hugo@telekom.de 600 Hitoshi Asaeda 601 Keio University 602 Graduate School of Media and Governance 603 5322 Endo 604 Fujisawa, Kanagawa 252-8520 605 Japan 607 Email: asaeda@wide.ad.jp 608 URI: http://www.sfc.wide.ad.jp/~asaeda/ 610 Behcet Sarikaya 611 Huawei USA 612 1700 Alma Dr. Suite 500 613 Plano, TX 75075 615 Email: sarikaya@ieee.org 616 Pierrick Seite 617 France Telecom - Orange 618 4, rue du Clos Courtel 619 BP 91226 620 Cesson-Sevigne, BZH 35512 621 France 623 Email: pierrick.seite@orange-ftgroup.com