wdiff draft-von-hugo-multimob-future-work-01.txt draft-von-hugo-multimob-future-work-02.txt

MULTIMOB Working Group D. von Hugo
Internet-Draft Deutsche Telekom Laboratories
Intended status: Informational H. Asaeda
Expires: August 26, December 9, 2010 Keio University
B. Sarikaya
Huawei USA
P. Seite
France Telecom - Orange
February 22,
June 8, 2010

Evaluation of further issues on Multicast Mobility: Potential future
work for WG MultiMob
<draft-von-hugo-multimob-future-work-01.txt>
<draft-von-hugo-multimob-future-work-02.txt>

Abstract

The WG MultiMob aims at defining a basic mobile multicast solution
leveraging on network localized mobility management, i.e. Proxy
Mobile IPv6 protocol. The solution would be basically based on
multicast group management, i.e. IGMP/MLD, proxying at the access
gateway. If such a basic solution is essential from an operational
point of view, challenges with efficient resource utilization and
user perceived service quality still persist. These issues may
prevent large scale deployments of mobile multicast applications.

This document attempts to identify topics for near future extension
of work such as modifying multimob base solution, PMIPv6 and MLD/IGMP MLD/
IGMP for optimal multicast support, and adaptation of Handover
optimization. Far future items such as extending to and modifying
of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of Handover optimization,
multiple flows with multihoming and any other different issues. multihoming will be dealt with in a future
version.

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 August 26, December 9, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. IGMP/MLD Proxy Architecture . . . . . . . . . . . . . . . . . 7
4. Problem Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. Modification of base PMIPv6 for optimal multicast
support . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Modification of MLD/IGMP for optimal multicast support . . 8
4.3. Extensions to and modifying of MIPv4/v6 and DSMIPv6 . . . 9
4.4. Consideration of sender (source) mobility . . . . . . . . 9
4.5. Consideration of Handover Optimization . . . . . . . . . . 9
4.6. Support of multiple flows . . . . . . . . . . . . . . . . 10
4.7. Support of multi-hop transmission . . . . . . . . . . . . 10
4.8. Mobility agnosticity . . . . . . . . . . . . . . . . . . . 10
4.9. Local routing . . . . . . . . .
4.4. Specific PMIP deployment issues . . . . . . . . . . . . . 10 9
5. Requirements on Solutions . . . . . . . . . . . . . . . . . . 11 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

1. Introduction

Recently chartered

Chartered work of WG MultiMob focuses on documentation of proper
configuration and usage of existing (specified standard) protocols
within both mobility and multicast related areas to enable and
support mobility for multicast services and vice versa. Although the
final recommendation is The current
WG document [I-D.ietf-multimob-pmipv6-base-solution] does not yet available it is expected that such a
solution following address
specific optimizations and efficiency improvements of multicast
routing for network-based mobility and thus the remote subscription aproach will not operation may be not
resource efficient nor grant the service quality expected by the end
user.

Such a

The described solution would resolve resolves the problem to ensure multicast
reception in PMIPv6-enabled [RFC5213] networks without appropriate
multicast support. However it would neither automatically minimize minimizes
multicast forwarding delay to provide seamless and fast handovers for
real-time services nor minimize minimizes packet loss and reordering that
result from multicast handover management as stated in
[I-D.irtf-mobopts-mmcastv6-ps]. [RFC5757].
Also Route Optimization is out of scope of the basic solution - an
issue for reducing amount of transport resource usage and
transmission delay. Thus possible enhancements and issues for
solutions beyond a basic solution need to be described to enable
current PMIPv6 protocols to fully support efficient mobile multicast
services. Such extensions may include protocol modifications for
both mobility and multicast related protocols to achieve
optimizations for resource efficient and performance increasing
multimob approaches. The document includes the case of mobile
multicast senders using Any Source Multicast (ASM) and Source
Specific Multicast (SSM) [RFC4607].

Figure 1 illustrates

This document focuses on discussion work on multicast protocols
such as IGMP/MLD operational tuning (e.g. as proposed in
[I-D.asaeda-igmp-mld-optimization]) and enhancements of IGMP/MLD
protocol behaviors and messages for optimal multicast support
(proposed in [I-D.asaeda-igmp-mld-mobility-extension]).

An alternative approach proposes the key components addition of acknowledgement
messages on group management ([I-D.liu-multimob-reliable-igmp-mld])
and changes the foreseen basic
Multimob solution. The extended unreliable protocol concept.

Furthermore a modification of PMIPv6 by introducing a dedicated
multicast mobility scenario, leading
to above issues, tunnel and support of local routing is sketched discussed in Figure 2.
[I-D.asaeda-multimob-pmip6-extension]. Other performance
improvements have been outlined in
[I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] where extensions to
Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568], and the corresponding
extension for Proxy MIPv6 operation [I-D.ietf-mipshop-pfmipv6].

Another type of multimob work aims directly at enhancements of the
current multimob base solution
[I-D.ietf-multimob-pmipv6-base-solution] towards introduction of
multicast traffic replication mechanisms and a reduction of the
protocol complexity in terms of time consuming tunnel set-up by
definition of pre- or post-configured tunnels (as provided by e.g.
[I-D.zuniga-multimob-smspmip]). Further work within this topic deals
with direct routing (e.g. [I-D.sijeon-multimob-mms-pmip6]) and with
dynamic or automatic tunnel configuration (see e.g.
[I-D.ietf-mboned-auto-multicast]).

A large field of additional investigations which are partly described
in detail in [RFC5757] will be mentioned for completeness and may be
subject of a later WG re-chartering.

+------+ +------+
| MN | =====> | MN |
+------+ +------+
| .
| .
+--------+ +--------+
| MAG 1 | | MAG 2 |
|IGMP/MLD| |IGMP/MLD|
|Proxy | |Proxy |
+--------+ +--------+
| |
*** *** *** ***
* ** ** ** *
* *
* Internet Subnet *
* *
* ** ** ** *
*** *** *** ***
| |
+-------+ +-------+
| LMA 1 | | LMA 2 |
+-------+ +-------+
| |
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
|
+------+
| CN |
+------+

Figure 1: MultiMob Scenario for chartered PMIP6 issue

+------+ +------+ +------+
| MN | =====> | MN | ====> | MN |
+------+ +------+ +------+
| . .
| . .
| . .
+-------+ +-------+ +-------+ +-------+
+--------+ +--------+ +--------+ +--------+
| MAG 1 | | MAG 2 | | AR 1 | | AR 2 |
|IGMP/MLD| |IGMP/MLD| |IGMP/MLD| |IGMP/MLD|
|Proxy
| |Proxy Proxy | |Proxy | |Proxy Proxy |
+-------+ +-------+ +-------+ +-------+ | Proxy | | Proxy |
+--------+ +--------+ +--------+ +--------+
\ / | |
*** *** *** *** *** *** *** ***
* ** *** ** * * ** *** ** *
* * * *
* Internet Subnet 1 * * Internet Subnet 2 *
* * * *
* ** *** ** * * ** *** ** *
*** *** *** *** *** *** *** ***
| | |
+-------+ +-------+ |
| LMA 1 | | LMA 2 | /
+-------+ +-------+ /
\ | /
*** *** *** *** / *** *** *** ***
* ** ** ** * / * ** *** ** *
* * * *
* Fixed Internet * * Internet Subnet 3 *
* *_____* *
* ** ** ** * * ** *** ** *
*** *** *** *** *** .*** *** ***
| .
+-------+ +-------+
| CN | ====> | CN |
+-------+ +-------+

Figure 2: MultiMob scenario for extended MultiMob issues

Figure 1 illustrates the key components of the foreseen basic
Multimob solution. The extended multicast mobility scenario, leading
to above issues, is sketched in Figure 2.

In summary additional to a 'Single hop, link, flow' Proxy MIP
mobility for listening MNs (scenario shown in Figure 1), the future work will focus on optimization of performances and extend the
towards a complete performance-optimized scenario to of a 'Multi-hop,
-homed, -flow' client mobility, thus also mobility (i.e. including optimizations for MIPv6 [RFC3775]. The following is [RFC3775] and
DSMIPv6 [RFC5555]) would cover a plurality of issues. For the
proposed work items to be covered in near
future we see the MultiMob continuation: (see
Figure 2). following issues as most important:

o Extension of multimob base solution

o Modification of base PMIPv6 and MLD/IGMP for optimal multicast
support.

o Extension Consideration of Handover optimization.

All further issues which would include extensions to and modifying
modifications of MIPv4/v6 and DSMIP using IGMP/MLD Proxy and the
Foreign Agent/ Access Router.

o Consideration Agent/Access Router, consideration of sender (source) mobility.

o Consideration of Handover optimization.

o Support
mobility, support of multiple flows on multihomed mobile nodes.

o Multi-hop transmission.

o Fixed mobile convergence support.

o Consideration of earlier versions of IGMP nodes,
multi-hop transmission, Routing optimization, and MLD in the
solutions.

o Consideration so forth will be
topics for a potential next stage of locally available multicast without remote
subscription.

o Improve host mobility agnoticity

o Routing optimization future work extension.

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], [RFC5213], [I-D.irtf-mobopts-mmcastv6-ps]. [RFC5757].

3. IGMP/MLD Proxy Architecture

Multimob basic solution is based on IGMPv3/MLDv2 Proxy support at the
mobile access gateway (MAG) of Proxy Mobile IPv6 as shown in
Figure 1. IGMPv3/MLDv2 proxy keeps multicast state on the
subscriptions of the mobile nodes and only an aggregate state is kept
at the local mobility anchor (LMA). When LMA receives multicast data
it can forward it to the MAG without duplication because MAG takes of
the packet duplication. This leads to solving the avalanche problem.

By keeping multicast state locally, IGMPv3/MLDv2 Proxy introduces
mobility related problems such as possible packet loss when a mobile
node does a handover to another MAG and its multicast state is not
modified fast enough at the LMA.

IGMPv3/MLDv2 introduces tunnel convergence problem which occurs when
a given MAG serves MNs that belong to different LMAs and MNs
subscribe to the same multicast group. In that case MNs receive
duplicate multicast data forwarded from more than one LMA.

It can be foreseen that mobile access gateways will serve both mobile
and fixed terminals concurrently. The tuning of multicast-related
protocol parameters based on the terminal characteristics is needed.
Parameters only applicable to mobile users need to be distinguished
from the parameters applicable to fixed users. It should be also
possible to distinguish between slow and fast movement and handover
frequency to form corresponding tunnels for mobile users.

Based on the above observations we will state the problems next and
then list the requirements on possible solutions.

4. Problem Description

The general issues of multicast mobility are extensively discussed
and described in [I-D.irtf-mobopts-mmcastv6-ps]. [RFC5757]. To reduce the complexity of the pleothera
plethora of requirements listed in
[I-D.irtf-mobopts-mmcastv6-ps] [RFC5757] and also in
[I-D.deng-multimob-pmip6-requirement] this document tries to propose summarises some
lightweight solutions for multicast mobility which allow for easy
deployment within realistic scenarios and architectures, and which
build architectures. Moreover
we focus on approaches building directly on basic MultiMob solution
[I-D.ietf-multimob-pmipv6-base-solution] which is based on IGMP/MLD
Proxy functionality at the mobile access gateway. gateway, and for which
already solution proposals have been described.

4.1. Modification of base PMIPv6 for optimal multicast support

There would be potential solutions proposed for

Currently discussed aspects of multicast optimization for PMIPv6
include introduction of multicast tunnels and support of local
routing such as
[I-D.asaeda-multimob-pmip6-extension], agent-based reling on
additional encapsulation, described in [I-D.asaeda-multimob-pmip6-extension].
For a PMIPv6 domain the establishment of a dedicated multicast tunnel
is proposed which may either be dynamically set up and released or be
pre-configured in a hybrid approach. static manner. Both mobility entities MAG and
LMA may be operate as MLD proxy or multicast router.
Since other further functional enhancements of PMIPv6 are currently under
way in NETEXT WG, both the impact of new features on Mobile Multicast
as well as such a
potential Multicast-initiated proposal for PMIPv6
modification have to be considered in a continuous exchange process
between both MultiMob and NETEXT WGs.

4.2. Modification of MLD/IGMP for optimal multicast support

Potential approaches for enhancement of group management as specified
e.g. by MLDv2 [RFC3810] include operational improvements such as
proper tuning in terms of default timer value modification, specific
query message introduction, and standard (query) reaction
suppression, beside introducing multicast router attendance control
in terms of e.g. specification of a Listener Hold message as proposed
in [I-D.asaeda-multimob-igmp-mld-mobility-extensions].

4.3. Extensions to and modifying of MIPv4/v6 and DSMIPv6

Operational interest clearly focusses on network-based mobility
approaches, but in the framework Consideration of multiple technologies serving a
mobile user there will be demand to include also other non-PMIPv6
based specifications.

This section addresses Handover Optimization

Ideally the compatibility of PMIPv6-based multicast
solutions with MIPv6 [RFC3775], i.e. handover between network-based
and client mobility support as well as interoperabiliy between IPv4
and IPv6 mechanisms (e.g. FA handling, IPv4/v4-tunneling) with
mobile multicast. DSMIPv6 [RFC5555] has a basic support for customer experience while using multicast which is based on remote subscription and bi-directional
tunneling, but does services should
not specify how to achieve group management and
data forwarding unless be affected by transmission issues whether the mobility anchor (i.e. Home Agent) terminal is a
fully functional IPv6 multicast router.

4.4. Consideration of sender (source) mobility

We see future demand for such a feature
operated in terms of applications such
as 'Push to talk over wireless technologies' (packet based point-to-
multipoint (P2MP) group voice) like 3GPP or WiMAX, 'Multi-party
mobile audio/video conferencing', 'mobile multi-player gaming' etc,
where due to real-time constraints a solution based on a central
server might add too much delay.

According to [I-D.irtf-mobopts-mmcastv6-ps] generally (i.e. for ASM) fixed or a mobile multicast source must provide address transparency environment. This implies not only
that the terminal should be unaware of changes at
Routing - for Reverse Path Forwarding (RPF) checks - as well as on
Transport network layer - to coincide with packet source address at receiver
side. Further issues are temporal handover constraints, possible
packet loss and multicast scoping, and enhanced complexity of inter-
domain multicasting. Additional challenges arise for SSM (Source
Specific Multicast) due to
connectivity (seamless communication) as is typically the principle case in a
PMIPv6 domain, but also that any impact of multicast decoupling
between sender and receivers.

4.5. Consideration connectivity changes
(handover) should be minimized. In the framework of Handover Optimization

This work item would deal with Multimob this
relates to reduction of delay, packet loss, and packet reordering effort. In case these degradations are induced due
to terminal movement it will be discussed how to make use of MIPSHOP
approaches such as HMIP, FMIP etc. (predominantly focusing on intra-
technology handover). Reusing
effort for mobile multicast specific protocol extensions
exceeding IGMP/MLD modifications shall further decrease the impact of
group management induced delay.

4.6. Support of multiple flows

Considering a per-flow by applying fast handover mechanisms,
which have originally been developed for parallel multicast sessions
allows unicast traffic to treat different services requirements and labels of flows
independently. This would improve user perceived service performance
as well as allow for more efficient usage multicast
group management. [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast]
works on specification of network resources
because extension of the enabled flexibility.

4.7. Support of multi-hop transmission

This scenario adds another level of complexity to Multicast Mobility Mobile IPv6 Fast Handovers
(FMIPv6) [RFC5568] and is of interest e.g. in nested NEMO (Network Mobility, [RFC3963])
scenarios, for MANETs (Mobile Adhoc NETworks) where also mechanisms the Fast Handovers for Proxy Mobile IPv6
(PFMIPv6) [I-D.ietf-mipshop-pfmipv6] protocols to include multicast forwarding are dicussed, e.g.
traffic management in terms fast handover operations. Issues for further
work are details of Simplified
Multicast Forwarding (SMF, [I-D.ietf-manet-smf]) or including multicast group messaging in context
transfer, for
infrastructure mesh networks. Here, more than the mobile both predictive and
temporary character of connections, it is the existence reactive handover mode, as well as
details of (more or
less stable) multiple hops corresponding message exchange protocols and multiple paths message
design.

4.4. Specific PMIP deployment issues

Currently several proposals are under work which is stressed.

4.8. Mobility agnosticity

In the idea describe extensions
of network based mobility management, the mobile node
should base protocol WG draft
[I-D.ietf-multimob-pmipv6-base-solution]. While MAG operation will
remain agnostic that of an MLD proxy additional LMA functionalities are
described in [I-D.zuniga-multimob-smspmip] which allow for
replication of the multicast mobility management when
roaming. In particular, traffic and solution of the node MUST not be required to re-
subscribe to tunnel
convergence problem. The dedicated multicast group(s) after handoff. If the mobile node
does no re-resubscribes, the new MAG must be able to retrieve the LMA may either set up
dedicated multicast states corresponding to the moving node.

4.9. Local tunnels dynamically or a-priory via
pre-configuration or a delayed release.

Another solution on dynamic and/or automatic tunnel configuration is
proposed within multicast WG MBONED [I-D.ietf-mboned-auto-multicast].

A direct or local routing

Short approach is described in
[I-D.sijeon-multimob-mms-pmip6]. This scenario may hold for short
term deployment focuses focusing on an architecture where multicast traffic
is provided via the home network. However, depending on the network
topology, namely the location of the content delivery network, the
LMA may not be on the optimal multicast service delivery path. This
enables mobile nodes to access locally available multicast services
such as local channels.

Figure 3 illustrates the use-case for local routing.

+----+
|LMA |
+----+
|
|
*** *** *** ***
* ** ** ** *
* * +-------------+
* Local Routing * _____ | Content |
* * | Delivery |
| Network |
* ** ** ** * +-------------+
*** *** *** ***
|| ||
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| | |
| | |
MN1 MN2 MN3

Figure 3: local Multicast routing

In such a case, the MAG should act as a multicast router to construct
the optimal multicast delivery path. If the MAG also supports MLD
proxy function issue raises up on the dual mode behaviour. In such a
case, a pragmatic approach could be to leverage only on multicast
routing at the MAG in the PMIP domain.

Whatever is the MAG operation mode, the multicast state is locally
kept at the access gateway, so unknown from the mobility anchor. In
other words, the multicast service is independent from the mobility
service that the mobile node is receiving from the network in the
form of PMIPv6 or DSMIPv6. However, handover support is still
desirable but cannot be provided by the mobility anchor (i.e. HA or
LMA). In such a case mobility support for locally available
multicast should be provided by extending multicast protocols of IGMP
or MLD.

5. Requirements on Solutions

This section tries to identify requirements from the issues discussed
in previous section.

o Seamless handover (low latency and during the handover).
o Similar packet loss to unicast service.
o Multiple LMAs architecture.
o Agnostic mobile host re-subscription. So, MAGs must be able to
retrieve multicast contexts of the mobile nodes.
o Solution address IPv6, IPv4 only and dual stack nodes.
o Supports sender (source) mobility.
o Optimal local routing.
o To be completed...

6. Security Considerations

This draft introduces no additional messages. Compared to [RFC3376],
[RFC3810], [RFC3775], and [RFC3775][RFC5213] [RFC5213] there is have no additional threats to
be
been introduced.

7. IANA Considerations

None.

Whereas this document does not explicitly introduce requests to IANA
some of the proposals referenced above (such as
[I-D.asaeda-multimob-pmip6-extension] and
[I-D.schmidt-multimob-fmipv6-pfmipv6-multicast]) specify flags for
mobility messages or options. For details please see those
documents.

8. Acknowledgements

The authors would thank all active mebers members of MultiMob WG, especially
(in no specific order) Gorry Fairhurst, Jouni Korhonen, Thomas
Schmidt, Suresh Krishnan and Matthias Waehlisch for providing
continuous support and helpful comments.

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.

[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 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.

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.

[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.

9.2. Informative References

[23246] "3GPP TS 23.246 V8.2.0, Multimedia Broadcast/Multicast
Service (MBMS); Architecture and functional description
(Release 8).", 2008.

[23401] "3GPP TS 23.401 V8.2.0, General Packet Radio Service
(GPRS) enhancements for Evolved Universal Terrestrial
Radio Access Network (E-UTRAN) access (Release 8).", 2008.

[23402] "3GPP TS 23.402 V8.4.1, Architecture enhancements for non-
3GPP accesses (Release 8).", 2009.

[I-D.asaeda-multimob-igmp-mld-mobility-extensions]
Asaeda, H. and T. Schmidt, "IGMP and MLD Hold and Release
Extensions for Mobility",
draft-asaeda-multimob-igmp-mld-mobility-extensions-03
(work in progress), July 2009.

[I-D.asaeda-multimob-igmp-mld-optimization]
Asaeda, H., "IGMP H. and S. Venaas, "Tuning the Behavior of IGMP
and MLD Optimization for Mobile Hosts and Routers",
draft-asaeda-multimob-igmp-mld-optimization-01
draft-asaeda-multimob-igmp-mld-optimization-02 (work in
progress), October 2009. March 2010.

[I-D.asaeda-multimob-pmip6-extension]
Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-02 (work
in progress), July 2009.

[I-D.deng-multimob-pmip6-requirement]
Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
"Multicast Support Requirements for Proxy Mobile IPv6",
draft-deng-multimob-pmip6-requirement-02 (work in
progress), July 2009.

[I-D.liu-multimob-reliable-igmp-mld]
Liu, H. and Q. Wu, "Reliable IGMP and MLD Protocols in
Wireless Environment",
draft-liu-multimob-reliable-igmp-mld-00 (work in
progress), March 2010.

[I-D.schmidt-multimob-fmipv6-pfmipv6-multicast]
Schmidt, T., Waehlisch, M., Koodli, R., and G. Fairhurst,
"Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
Handovers",
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01 (work
in progress), March 2010.

[I-D.sijeon-multimob-mms-pmip6]
Jeon, S. and Y. Kim, "Mobile Multicasting Support in
Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02
(work in progress), March 2010

[I-D.zuniga-multimob-smspmip]
Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
Services Using Proxy Mobile IPv6",
draft-zuniga-multimob-smspmip-02 (work in progress),
June 2010.

[I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and
T. Pusateri, "Automatic IP Multicast Without Explicit
Tunnels (AMT)", draft-ietf-mboned-auto-multicast-10 (work
in progress), March 2010

[I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]
Madanapalli, S., Park, S., Chakrabarti, S., and G.
Montenegro, "Transmission of IPv4 packets over IEEE
802.16's IP Convergence Sublayer",
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 (work in
progress), June 2009. 2010.

[I-D.ietf-manet-smf]
Macker, J. and S. Team, (editor), "Simplified Multicast Forwarding",
draft-ietf-manet-smf-09
draft-ietf-manet-smf-10 (work in progress), July 2009.

[I-D.irtf-mobopts-mmcastv6-ps]
Fairhurst, G., March 2010.

[I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-14 (work in progress), May
2010

[I-D.ietf-multimob-pmipv6-base-solution]
Schmidt, T., Waehlisch, M., and M. S. Krishnan, "Base
Deployment for Multicast Listener Support in PMIPv6
Domains",
draft-ietf-multimob-pmipv6-base-solution-02 (work in
progress), May 2010.

[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in MIPv6: Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-09 (work in progress),
October 2009.
RFC 5757, June 2010.

[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.

[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.

Authors' Addresses

Dirk von Hugo
Deutsche Telekom Laboratories
Deutsche-Telekom-Allee 7
64295 Darmstadt, Germany

Email: dirk.von-hugo@telekom.de

Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan

Email: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/

Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075

Email: sarikaya@ieee.org
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel
BP 91226
Cesson-Sevigne, BZH 35512
France

Email: pierrick.seite@orange-ftgroup.com