One document matched: draft-ietf-multimob-fmipv6-pfmipv6-multicast-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-ietf-multimob-fmipv6-pfmipv6-multicast-09"
ipr="trust200902" updates="5568">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="Multicast for FMIPv6/PFMIPv6">Multicast Listener Extensions
for MIPv6 and PMIPv6 Fast Handovers</title>
<author fullname="Thomas C. Schmidt" initials="T C." role="editor"
surname="Schmidt">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Dept. Informatik</street>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<region></region>
<code>D-20099</code>
<country>Germany</country>
</postal>
<email>t.schmidt@haw-hamburg.de</email>
</address>
</author>
<author fullname="Matthias Waehlisch" initials="M." surname="Waehlisch">
<organization>link-lab & FU Berlin</organization>
<address>
<postal>
<street>Hoenower Str. 35</street>
<city>Berlin</city>
<code>D-10318</code>
<country>Germany</country>
</postal>
<email>mw@link-lab.net</email>
</address>
</author>
<author fullname="Rajeev Koodli" initials="R." surname="Koodli">
<organization>Intel</organization>
<address>
<postal>
<street>3600 Juliette Lane</street>
<city>Santa Clara,</city>
<code>CA 95054</code>
<country>USA</country>
</postal>
<email>rajeev.koodli@intel.com</email>
</address>
</author>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>UK</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
</address>
</author>
<author fullname="Dapeng Liu" initials="Dapeng" surname="Liu">
<organization>China Mobile</organization>
<address>
<phone>+86-123-456-7890</phone>
<email>liudapeng@chinamobile.com</email>
</address>
</author>
<date />
<workgroup>MULTIMOB Group</workgroup>
<abstract>
<t>Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6
(PMIPv6) define mobility management procedures that support unicast
communication at reduced handover latency. Fast handover base operations
do not affect multicast communication, and hence do not accelerate
handover management for native multicast listeners. Many multicast
applications like IPTV or conferencing, though, comprise delay-sensitive
real-time traffic and will benefit from fast handover completion. This
document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6)
and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to
include multicast traffic management in fast handover operations. This
multicast support is provided first at the control plane by a management
of rapid context transfer between access routers, second at the data
plane by an optional fast traffic forwarding that may include buffering.
An FMIPv6 access router indicates support for multicast using an updated
Proxy Router Advertisements message format.</t>
<t>This document updates RFC5568 "Mobile IPv6 Fast Handovers".</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Mobile IPv6 <xref target="RFC6275"></xref> defines a network layer
mobility protocol involving participation by mobile nodes, while Proxy
Mobile IPv6 <xref target="RFC5213"></xref> provides a mechanism without
requiring mobility protocol operations at a Mobile Node (MN). Both
protocols introduce traffic disruptions on handovers that may be
intolerable in many real-time application scenarios such as gaming or
conferencing. Mobile IPv6 Fast Handovers (FMIPv6) <xref
target="RFC5568"></xref>, and Fast Handovers for Proxy Mobile IPv6
(PFMIPv6) <xref target="RFC5949"></xref> improve the performance of
these handover delays for unicast communication to the order of the
maximum of the delays needed for link switching and signaling between
Access Routers (ARs) or Mobile Access Gateways (MAGs) <xref
target="FMIPv6-Analysis"></xref>.</t>
<t>No dedicated treatment of seamless IP multicast <xref
target="RFC1112"></xref> data service has been proposed by any of the
above protocols. MIPv6 only roughly defines multicast for Mobile Nodes
using a remote subscription approach or a home subscription through
bi-directional tunneling via the Home Agent (HA). Multicast forwarding
services have not been specified in <xref target="RFC5213"></xref>, but
are subject to separate specifications <xref target="RFC6224"></xref>,
<xref target="RFC7287"></xref>. It is assumed throughout this document
that mechanisms and protocol operations are in place to transport
multicast traffic to ARs. These operations are referred to as
'JOIN/LEAVE' of an AR, while the explicit techniques to manage multicast
transmission are beyond the scope of this document.</t>
<t>Mobile multicast protocols need to support applications such as IPTV
with high-volume content streams and allow distribution to potentially
large numbers of receivers. They should thus preserve the multicast
nature of packet distribution and approximate optimal routing <xref
target="RFC5757"></xref>. It is undesirable to rely on home tunneling
for optimizing multicast. Unencapsulated, native multicast transmission
requires establishing forwarding state, which will not be transferred
between access routers by the unicast fast handover protocols. Thus
multicast traffic will not experience expedited handover performance,
but an MN - or its corresponding MAG in PMIPv6 - can perform remote
subscriptions in each visited network.</t>
<t>This document specifies extensions to FMIPv6 and PFMIPv6 that include
multicast traffic management for fast handover operations in the
presence of any-source or source-specific multicast. The protocol
extensions were designed under the requirements that</t>
<t><list style="symbols">
<t>multicast context transfer shall be transparently included in
unicast fast handover operations</t>
<t>neither unicast mobility protocols nor multicast routing shall be
modified or otherwise affected</t>
<t>no active participation of MNs in PMIPv6 domains is defined.</t>
</list></t>
<t>The solution common to both underlying unicast protocols defines the
per-group or per channel transfer of multicast contexts between ARs or
MAGs. The protocol defines corresponding message extensions necessary
for carrying (*,G) or (S,G) context information independent of the
particular handover protocol. ARs or MAGs are then enabled to treat
multicast traffic according to fast unicast handovers and with similar
performance. No protocol changes are introduced that prevent a multicast
unaware node from performing fast handovers with multicast aware ARs or
MAGs.</t>
<t>The specified mechanisms apply when a mobile node has joined and
maintains one or several multicast group subscriptions prior to
undergoing a fast handover. It does not introduce any requirements on
the multicast routing protocols in use, nor are the ARs or MAGs assumed
to be multicast routers. It assumes network conditions, though, that
allow native multicast reception in both, the previous and new access
network. Methods to bridge regions without native multicast connectivity
are beyond the scope of this document.</t>
<t><xref target="m-prtrtadv"></xref> of this memo updates the Proxy
Router Advertisements (PrRtAdv) message format defined in Section 6.1.2.
of <xref target="RFC5568"></xref> to allow an FMIPv6 AR to indicate
support for multicast.</t>
<section title="Use Cases and Deployment Scenarios">
<t>Multicast Extensions for Fast Handovers enable multicast services
in those domains that operate any of the unicast fast handover
protocols <xref target="RFC5568"></xref> or <xref
target="RFC5949"></xref>. Typically, fast handover protocols are
activated within an operator network or within a dedicated service
installation.</t>
<t>Multicast group communication has a variety of dominant use cases.
One traditional application area is infotainment with voluminous
multimedia streams delivered to a large number of receivers (e.g.,
IPTV). Other time-critical services are commonly transmitted via
multicast, such as include news items or stock-exchange prices, to
support fair and fast updates. Both may be mobile and both largely
benefit from fast handover operations. Mobile operators may therefore
enhance their operational quality or offer premium services by
enabling fast handovers.</t>
<t>Another traditional application area for multicast is
conversational group communication in scenarios like conferencing or
gaming, but also in dedicated collaborative environments or teams.
Machine-to-machine communication in the emerging Internet of Things is
expected to generate various additional mobile use cases (e.g., among
cars). High demands on transmission quality and rapidly moving parties
may require fast handovers.</t>
<t>Most of the deployment scenarios above are bound to a fixed
infrastructure with consumer equipment at the edge. Today, they are
thus likely to follow an operator-centric approach like PFMIPv6.
However, Internet technologies evolve for adoption in
infrastructureless scenarios, at disaster recovery, rescue, crisis
prevention and civil safety for example. Mobile end-to-end
communication in groups is needed in Public Protection and Disaster
Relief (PPDR) scenarios, where mobile multicast communication needs to
be supported between members of rescue teams, police officers, fire
brigade teams, paramedic teams, command control offices in order to
support the protection and health of citizens. These use cases require
fast and reliable mobile services which cannot rely on operator
infrastructure. They are thus expected to be benefit from running
multicast with FMIPv6.</t>
</section>
</section>
<section title="Terminology">
<t>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 RFC 2119 <xref
target="RFC2119"></xref>. The use of the term, "silently ignore" is not
defined in RFC 2119. However, the term is used in this document and can
be similarly construed.</t>
<t>This document uses the terminology of <xref target="RFC5568"></xref>,
<xref target="RFC5949"></xref>, <xref target="RFC6275"></xref>, and
<xref target="RFC5213"></xref> for mobility entities.</t>
<t>A multicast group is any group (S,G) or (*,G) or (S,G) multicast
channel listed in a Multicast Listener Report Message.</t>
</section>
<section title="Protocol Overview">
<t>This section provides an informative overview of the protocol
mechanisms without normative specifications.</t>
<t>The reference scenario for multicast fast handover is illustrated in
<xref target="fig1"></xref>. A Mobile Node is initially attached to the
previous access network (P-AN) via the Previous Access Router (PAR) or
Previous Mobile Access Gateway (PMAG) and moves to the new access
network (N-AN) connected via a New AR (NAR) or New MAG (NMAG).</t>
<figure anchor="fig1" title="Reference Network for Fast Handover">
<artwork><![CDATA[
*** *** *** ***
* ** ** ** *
* *
* Multicast Cloud *
* *
* ** ** ** *
*** *** *** ***
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
]]></artwork>
</figure>
<section anchor="AR-context-transfer"
title="Multicast Context Transfer between Access Routers">
<t>In a fast handover scenario (cf. <xref target="fig1"></xref>),
ARs/MAGs establish a mutual binding and provide the capability to
exchange context information concerning the MN. This context transfer
will be triggered by detecting the forthcoming movement of an MN to a
new AR and assists the MN to immediately resume communication on the
new subnet using its previous IP address. In contrast to unicast,
multicast flow reception does not primarily depend on address and
binding cache management, but requires distribution trees to adapt so
that traffic follows the movement of the MN. This process may be
significantly slower than fast handover management <xref
target="RFC5757"></xref>. To accelerate the handover, a multicast
listener may offer a twofold advantage of including the multicast
groups under subscription in the context transfer: First, the NAR can
proactively join the subscribed groups as soon as it gains knowledge
of them. Second, multicast flows can be included in traffic forwarding
via the tunnel that is established from the PAR to the NAR by the
unicast fast handover protocol.</t>
<t>There are two modes of operation in FMIPv6 and in PFMIPv6. The
predictive mode allows for AR-binding and context transfer prior to an
MN handover, while in the reactive mode, these steps are executed
after detection that the MN has re-attached to a NAR (NMAG). Details
of the signaling schemes differ between FMIPv6 and PFMIPv6 and are
outlined in <xref target="FMIPv6-overview"></xref> and <xref
target="PFMIPv6-overview"></xref>.</t>
<t>In a predictive fast handover, the access router (i.e., PAR (PMAG)
in <xref target="fig1"></xref>) learns about the impending movement of
the MN and simultaneously about the multicast group context as
specified in <xref target="FMIPv6-overview"></xref> and <xref
target="PFMIPv6-overview"></xref>. Thereafter, the PAR will initiate
an AR-binding and context transfer by transmitting a HI message to NAR
(NMAG). The Handover Initiation (HI) message is extended by multicast
group states carried in mobility header options as defined in <xref
target="multicast-option"></xref>. On reception of the HI message, the
NAR returns a multicast acknowledgement in its Handover
Acknowledgement (HACK) answer that indicates its ability to support
each requested group (see <xref target="multicast-ack"></xref>). The
NAR (NMAG) expresses its willingness to receive multicast traffic
forwarded by the PAR using standard Multicast Listener Discovery (MLD)
signaling for IPv6, or the Internet Group Management Protocol (IGMP)
an IPv4 compatibility case.</t>
<t>Nodes normally create forwarding state for each group requested.
There are several reasons why a node may decide not to forward a
specific group, e.g., the NAR could already have a native subscription
for the group(s), or capacity constraints can hinder decapsulation of
additional streams. At the previous network, there may be policy or
capacity constraints that make it undesirable to forward the multicast
traffic. The PAR can add the tunnel interface obtained from the
underlying unicast protocol to its multicast forwarding database for
those groups the MN wishes to receive, so that multicast flows can be
forwarded in parallel to the unicast traffic.</t>
<t>The NAR implements an MLD proxy <xref target="RFC4605"></xref>
providing host-side behaviour towards the upstream PAR. The proxy will
submit an MLD report to the upstream tunnel interface to signal the
set of groups to be forwarded. It will terminate multicast forwarding
from the tunnel when the group is natively received. In parallel, the
NAR joins all groups that are not already under subscription using its
native multicast upstream interface. While the MN has not arrived at a
downstream interface of the NAR, multicast subscriptions on behalf of
the MN are associated with a downstream Loopback interface. Reception
of the Join at the NAR enables downstream native multicast forwarding
of the subscribed group(s).</t>
<t>In a reactive fast handover, the PAR will learn about the movement
of the MN, after the latter has re-associated with the new access
network. Also from the new link, it will be informed about the
multicast context of the MN. As group membership information is
present at the new access network prior to context transfer, MLD join
signaling can proceed in parallel to HI/HACK exchange. Following the
context transfer, multicast data can be forwarded to the new access
network using the PAR-NAR tunnel of the fast handover protocol.
Depending on the specific network topology multicast traffic for some
groups may natively arrive before it is forwarded from the PAR.</t>
<t>In both modes of operation, it is the responsibility of the PAR
(PMAG) to properly apply multicast state management when an MN leaves
(i.e., to determine whether it can prune the traffic for any
unsubscribed group). Depending on the link type and MLD parameter
settings, methods for observing the departure of an MN need to be
applied (cf., <xref target="RFC5757"></xref>). While considering
subscriptions of the remaining nodes and from the tunnel interfaces,
the PAR uses normal multicast forwarding rules to determine whether
multicast traffic can be pruned.</t>
<t>This method allows an MN to participate in multicast group
communication with a handover performance that is comparable to
unicast handover. It is worth noting that tunnel management between
access routers in all modes is inherited from the corresponding
unicast fast handover protocols. Tunnels thus remain active until
unicast handover operations have been completed for the MN.</t>
</section>
<section anchor="FMIPv6-overview"
title="Protocol Operations Specific to FMIPv6">
<t>ARs that provide multicast support in FMIPv6 will advertise this
general service by setting an indicator bit (M-bit) in its PrRtAdv
message as defined in <xref target="m-prtrtadv"></xref>. Additional
details about the multicast service support, e.g., flavors and groups,
will be exchanged within HI/HACK dialogs later at handover.</t>
<t>An MN operating FMIPv6 will actively initiate the handover
management by submitting a Fast Binding Update (FBU). The MN, which is
aware of the multicast groups it wishes to maintain, will attach
mobility options containing its group states (see <xref
target="multicast-option"></xref>) to the FBU, and thereby inform ARs
about its multicast context. ARs will use these multicast context
options for inter-AR context transfer.</t>
<t>In predictive mode, the FBU is issued on the previous link and
received by the PAR as displayed in <xref target="fmip-pred"></xref>.
The PAR will extract the multicast context options and append them to
its HI message. From the HACK message, the PAR will redistribute the
multicast acknowledgement by adding the corresponding mobility options
to its Fast Binding ACK (FBACK) message. From receiving the FBACK
message, the MN will learn about the multicast support for each group
in the new access network. If some groups or multicast service models
are not supported, it can decide to take actions to overcome a missing
service (e.g., by tunneling). Note that the proactive multicast
context transfer may proceed successfully, even if the MN misses the
FBACK message on the previous link.</t>
<figure anchor="fmip-pred"
title="Predictive Multicast Handover for FMIPv6">
<artwork><![CDATA[
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
| | |
|---------FBU-------->|----------HI--------->|
| (Multicast MobOpt) | (Multicast MobOpt) |
| | |
| |<--------HACK---------|
| | (Multicast AckOpt) |
| | Join to
| | Multicast
| | Groups
| | |
| <-----FBACK---|--FBACK------> |
| (Multicast AckOpt) | (Multicast AckOpt) |
| | |
disconnect optional |
| packet ================>|
| forwarding |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
]]></artwork>
</figure>
<t>The flow diagram for reactive mode is depicted in <xref
target="fmip-react"></xref>. After attaching to the new access link
and performing an Unsolicited Neighbor Advertisement (UNA), the MN
issues an FBU which the NAR forwards to the PAR without processing. At
this time, the MN is able to re-join all subscribed multicast groups
without relying on AR assistance. Nevertheless, multicast context
options are exchanged in the HI/HACK dialog to facilitate intermediate
forwarding of the requested multicast flows. The multicast traffic
could arrive from an MN subscription at the same time that the NAR
receives the HI message. Such multicast flows may be transparently
excluded from forwarding by setting an appropriate multicast
acknowledge option. In either case, to avoid duplication the NAR MUST
ensure that not more than one flow of the same group is forwarded to
the MN.</t>
<figure anchor="fmip-react"
title="Reactive Multicast Handover for FMIPv6">
<artwork><![CDATA[
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| (Multicast MobOpt) |<-------FBU----------)|
| | |
Join to | |
Multicast | |
Groups | |
| |----------HI--------->|
| | (Multicast MobOpt) |
| |<-------HACK----------|
| | (Multicast AckOpt) |
| | |
| |(HI/HACK if necessary)|
| | |
| FBACK, optional |
| packet forwarding ==========>|
| | |
|<=================================== deliver packets
| |
]]></artwork>
</figure>
</section>
<section anchor="PFMIPv6-overview"
title="Protocol Operations Specific to PFMIPv6">
<t>In a proxy mobile IPv6 environment, the MN remains agnostic of
network layer changes, and fast handover procedures are operated by
the access routers or MAGs to which MNs are connected via
node-specific point-to-point links. The handover initiation, or the
re-association respectively are managed by the access networks.
Consequently, access routers need to be aware of multicast membership
state at the mobile node. There are two ways to obtain the multicast
membership of an MN.</t>
<t><list style="symbols">
<t>MAGs may perform explicit tracking (see <xref
target="RFC4605"></xref>, <xref target="RFC6224"></xref>) or
extract membership status from forwarding states at node-specific
links.</t>
<t>routers can issue a general MLD query at handovers. Both
methods are equally applicable. However, a router that does not
provide explicit membership tracking needs to query its downstream
links after a handover. The MLD membership information then allows
the PMAG to learn the multicast group subscriptions of the MN.</t>
</list>In predictive mode, the PMAG will learn about the upcoming
movement of the mobile node including its new Access Point Identifier
(New AP ID). Without explicit tracking, it will immediately submit a
general MLD query and receive MLD reports indicating the multicast
address listening state of the subscribed group(s). As displayed in
<xref target="pfmip-pred"></xref>, it will initiate binding and
context transfer with the NMAG by issuing a HI message that is
augmented by multicast contexts in the mobility options defined in
<xref target="multicast-option"></xref>. NMAG will extract multicast
context information and act as described in <xref
target="AR-context-transfer"></xref>.</t>
<figure anchor="pfmip-pred"
title="Predictive Multicast Handover for PFMIPv6">
<artwork><![CDATA[
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
| Report | | | |
|---(MN ID,-->| | | |
| New AP ID) | | | |
| | HO Indication | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HACK-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HACK(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
disconnect | | | |
| | | | |
connect | | | |
| MN-AN connection | AN-MAG connection |
|<----establishment----->|<----establishment------->|
| | | (substitute for UNA) |
| | | | |
|<========================================== deliver packets
| | | | |
]]></artwork>
</figure>
<t>In reactive mode, the NMAG will learn the attachment of the MN to
the N-AN and establish connectivity using the PMIPv6 protocol
operations. However, it will have no knowledge about multicast state
at the MN. Triggered by an MN attachment, the NMAG will send a general
MLD query and thereafter join the groups for which it receives
multicast listener report messages. In the case of a reactive
handover, the binding is initiated by the NMAG, and the HI/HACK
message semantic is inverted (see <xref target="RFC5949"></xref>). For
multicast context transfer, the NMAG attaches to its HI message those
group identifiers it requests to be forwarded from PMAG. Using the
identical syntax in its multicast mobility option headers as defined
in <xref target="multicast-ack"></xref>, the PMAG acknowledges the set
of requested groups in a HACK answer, indicating the group(s) it is
willing to forward. The corresponding call flow is displayed in <xref
target="pfmip-react"></xref>.</t>
<figure anchor="pfmip-react"
title="Reactive Multicast Handover for PFMIPv6">
<artwork><![CDATA[
PMAG NMAG
MN P-AN N-AN (PAR) (NAR)
| | | | |
disconnect | | | |
| | | | |
connect | | | |
| | | | |
| MN-AN connection | AN-MAG connection |
|<---establishment---->|<----establishment------->|
| | |(substitute for UNA & FBU)|
| | | | |
| | | | MLD Query
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | |
| | | |<------HI----|
| | | |(Multicast MobOpt)
| | | | |
| | | |---HACK----->|
| | | |(Multicast AckOpt)
| | | | |
| | | | |
| | | |HI/HACK(optional)
| | | |<- - - - - ->|
| | | | |
| | | optional packet |
| | | forwarding =======>|
| | | | |
|<======================================== deliver packets
| | | | |
]]></artwork>
</figure>
<t></t>
</section>
</section>
<section title="Protocol Details">
<t>This section provides a normative definition of the protocol
operations.</t>
<section title="Protocol Operations Specific to FMIPv6">
<t></t>
<section title="Operations of the Mobile Node">
<t>A Mobile Node willing to manage multicast traffic by fast
handover operations MUST transfer its MLD listener state records
within fast handover negotiations.</t>
<t>When sensing a handover in predictive mode, an MN MUST build a
Multicast Mobility Option as described in <xref
target="multicast-option"></xref> that contains the MLD or IGMP
multicast listener state and append it to the Fast Binding Update
(FBU) prior to signaling with PAR.</t>
<t>The MN will receive the Multicast Acknowledgement Option(s) as a
part of the Fast Binding Acknowledge (FBACK) (see <xref
target="multicast-ack"></xref>) and learn about unsupported or
prohibited groups at the NAR. The MN MAY take appropriate actions
such as home tunneling to enable reception of groups that are not
available via the NAR. No multicast-specific operation is required
by the MN when re-attaching in the new network beyond standard
FMIPv6 signaling.</t>
<t>In reactive mode, the MN MUST append the identical Multicast
Mobility Option to the FBU sent after its reconnect. In response, it
will learn about the Multicast Acknowledgement Option(s) from the
FBACK and expect corresponding multicast data. Concurrently it joins
all subscribed multicast groups directly on its newly-established
access link.</t>
</section>
<section title="Operations of the Previous Access Router">
<t>A PAR MUST advertise its support for multicast by setting the
M-bit in the Proxy Router Advertisement (PrRtAdv) message, as
specified in <xref target="m-prtrtadv"></xref> of this document.
This indicator exclusively informs the MNs about the capability of
the PAR to process and exchange Multicast Mobility Options during
Fast Handover operations.</t>
<t>In predictive mode, a PAR will receive the multicast listener
state of an MN prior to handover from the Multicast Mobility Option
appended to the FBU. It forwards these records to the NAR within HI
messages and will expect Multicast Acknowledgement Option(s) in a
HACK, which is itself returned to the MN as an appendix to the
FBACK. In performing the multicast context exchange, the PAR is
instructed to include the PAR-to-NAR tunnel obtained from unicast
handover management in its multicast downstream interfaces and
awaits reception of multicast listener report messages from the NAR.
In response to receiving multicast subscriptions, the PAR SHOULD
forward group data acting as a regular multicast router or proxy.
However, the PAR MAY refuse to forward some or all of the multicast
flows (e.g., due to administrative configurations or load
conditions).</t>
<t>In reactive mode, the PAR will receive the FBU augmented by the
Multicast Mobility Option from the new network, but continues with
an identical multicast record exchange in the HI/HACK dialog. As in
the predictive case, it configures the PAR-to-NAR tunnel for the
multicast downstream. It then (if capable) forwards data according
to the group membership indicated in the multicast listener report
messages received from NAR.</t>
<t>In both modes, the PAR MUST interpret the first of the two events
- the departure of the MN or the reception of the Multicast
Acknowledgement Option(s) - as if the MN had sent a multicast LEAVE
message and react according to the signaling scheme deployed in the
access network (i.e., MLD querying, explicit tracking).</t>
</section>
<section title="Operations of the New Access Router">
<t>A NAR MUST advertise its multicast support by setting the M-bit
in PrRtAdv as specified in <xref target="m-prtrtadv"></xref> of this
document. This indicator exclusively serves the purpose of informing
MNs about the capability of the NAR to process and exchange
Multicast Mobility Options during Fast Handover operations.</t>
<t>In predictive mode, a NAR will receive the multicast listener
state of an expected MN from the Multicast Mobility Option appended
to the HI message. It will extract the multicast group membership
records from the message and match the request subscription with its
multicast service offer. Further on it will join the requested
groups using a downstream Loopback interface. This will lead to
suitable regular subscriptions to a native multicast upstream
interface without additional forwarding. Concurrently, the NAR
builds a Multicast Acknowledgement Option(s) (see <xref
target="multicast-ack"></xref>) listing the set of groups that are
unsupported on the new access link and returns this list within a
HACK. As soon as there is an operational bidirectional tunnel from
the PAR to NAR, the NAR joins the groups requested by the MN, which
are then forwarded by the PAR using the tunnel link.</t>
<t>In reactive mode, the NAR will learn about the multicast listener
state of a new MN from the Multicast Mobility Option appended to
each HI message, after the MN has already performed local
subscriptions of the multicast service. Thus the NAR solely
determines the intersection of requested and supported groups and
issues a join request for each group forwarding this on the PAR-NAR
tunnel interface.</t>
<t>In both modes, the NAR MUST send a LEAVE message to the tunnel
when it is no longer needed to forward a group, e.g., after native
multicast traffic arrives or termination of a group membership from
the MN. Although the message can be delayed, immediately sending the
LEAVE message eliminates the need for PAR and NAR to process traffic
that is not to be forwarded.</t>
</section>
<section title="Buffering Considerations">
<t>Multicast packets may be lost during handover. For example, in
predictive mode as illustrated by figure 2, packets may be lost
while the MN is - already or still - detached from the networks,
even though they are forwarded to the NAR. In reactive mode as
illustrated by figure 3, the situation may be worse, since there
will be a delay before joining the multicast group after the MN
re-attaches to the NAR. Multicast packets cannot be delivered during
this time. Buffering the multicast packets at the PAR can reduce
multicast packet loss, but may then increase resource consumption
and delay in packet transmission. Implementors should balance the
different requirements in the context of predominant application
demands (e.g., real-time requirements, or loss sensitivity).</t>
</section>
</section>
<section anchor="det-pfmipv6"
title="Protocol Operations Specific to PFMIPv6">
<t></t>
<section title="Operations of the Mobile Node">
<t>A Mobile Node willing to participate in multicast traffic will
join, maintain and leave groups as if located in the fixed Internet.
It will cooperate in handover indication as specified in <xref
target="RFC5949"></xref> and required by its access link-layer
technology. No multicast-specific mobility actions nor
implementations are required at the MN in a PMIPv6 domain.</t>
</section>
<section title="Operations of the Previous MAG">
<t>A MAG receiving a handover indication for one of its MNs follows
the same predictive fast handover mode as a PMAG. It MUST issue an
MLD General Query immediately on its corresponding link unless it
performs explicit membership tracking on that link. After knowledge
of the multicast subscriptions of the MN is acquired, the PMAG
builds a Multicast Mobility Option, as described in <xref
target="multicast-option"></xref> that contains the MLD and IGMP
multicast listener state. If not empty, this Mobility Option is
appended to the regular fast handover HI messages. In the case when
a unicast HI message is submitted prior to multicast state
detection, the multicast listener state is sent in an additional HI
message to the NMAG.</t>
<t>The PMAG then waits until it receives the Multicast
Acknowledgement Option(s) with a HACK message (see <xref
target="multicast-ack"></xref>) and the creation of the
bidirectional tunnel with NMAG. After the HACK message is received,
the PMAG adds the tunnel to its downstream interfaces in the
multicast forwarding database. For those groups reported in the
Multicast Acknowledgement Option(s), i.e., not supported in the new
access network, the PMAG normally takes appropriate actions (e.g.,
forwarding, termination) according to the network policy. It SHOULD
start forwarding multicast traffic down the tunnel interface for
those groups for the groups indicated in the multicast listener
reports received from NMAG. However, it MAY deny forwarding some or
all groups included in the multicast listener reports (e.g., due to
administrative configurations or load conditions).</t>
<t>After the departure of the MN and on the reception of a LEAVE
message, it is RECOMMENDED that the PMAG terminates forwarding of
the specified groups and updates its multicast forwarding database.
It correspondingly sends a LEAVE message to its upstream link for
any group where there are no longer any active listeners on any
downstream link.</t>
<t>A MAG receiving a HI message with the Multicast Mobility Option
for a currently attached node follows the reactive fast handover
mode as a PMAG. It will return Multicast Acknowledgement Option(s)
(see <xref target="multicast-ack"></xref>) within a HACK message
listing the groups for which it does not provide forwarding support
to the NMAG. It will add the bidirectional tunnel with NMAG to its
downstream interfaces and will start forwarding multicast traffic
for the groups listed in the multicast listener report messages from
the NMAG. On reception of a LEAVE message for a group, the PMAG
terminates forwarding for the specific group and update its
multicast forwarding database. According to its multicast forwarding
state, It sends a LEAVE message to its upstream link for any group
where there are no longer any active listeners on any downstream
link.</t>
<t>In both modes, the PMAG will interpret the departure of the MN as
a multicast LEAVE message of the MN and react according to the
signaling scheme deployed in the access network (i.e., MLD querying,
explicit tracking).</t>
</section>
<section title="Operations of the New MAG">
<t>A MAG receiving a HI message with a Multicast Mobility Option for
a currently unattached node follows the same predictive fast
handover mode as an NMAG. It will decide the multicast groups to be
forwarded from the PMAG and build a Multicast Acknowledgement Option
(see <xref target="multicast-ack"></xref>) that enumerates only
unwanted groups. This Mobility Option is appended to the regular
fast handover HACK messages, or - in the case of a unicast HACK
message being submitted prior to multicast state acknowledgement -
sent in an additional HACK message to the PMAG. Immediately
thereafter, the NMAG SHOULD update its MLD membership state based on
the membership reported in the Multicast Mobility Option. Until the
MN re-attaches, the NMAG uses its Loopback interface for downstream
and MUST NOT forward traffic to the potential link of the MN. The
NMAG SHOULD issue JOIN messages for those newly selected groups to
its regular multicast upstream interface. As soon as the
bidirectional tunnel with PMAG is established, the NMAG additionally
joins those groups on the tunnel interface requested to be forwarded
from the PMAG.</t>
<t>A MAG experiencing a connection request for an MN without prior
reception of a corresponding Multicast Mobility Option is operating
in the reactive fast handover mode as an NMAG. Following the
re-attachment, it SHOULD immediately issue an MLD General Query to
learn about multicast subscriptions of the newly arrived MN. Using
standard multicast operations, the NMAG joins groups not currently
forwarded using its regular multicast upstream interface.
Concurrently, it selects groups for forwarding from PMAG and builds
a Multicast Mobility Option as described in <xref
target="multicast-option"></xref> that contains the multicast
listener state. If not empty, this Mobility Option is appended to
the regular fast handover HI messages with the F flag set, or - in
the case of unicast HI message being submitted prior to multicast
state detection - sent in an additional HI message to the PMAG. Upon
reception of the Multicast Acknowledgement Option and establishment
of the bidirectional tunnel, the NMAG additionally joins the set of
groups on the tunnel interface that it wishes to receive by
forwarding from the PMAG. When multicast flows arrive, the NMAG
forwards data to the appropriate downlink(s).</t>
<t>In both modes, the NMAG MUST send a LEAVE message to the tunnel
when forwarding of a group is no longer needed, e.g., after native
multicast traffic arrives or group membership of the MN terminates.
Although the message can be delayed, immediately sending the LEAVE
message eliminates the need for PAR and NAR to process traffic that
is not to be forwarded.</t>
</section>
<section anchor="det-IPv4" title="IPv4 Support Considerations">
<t>An MN in a PMIPv6 domain MAY use an IPv4 address transparently
for communication as specified in <xref target="RFC5844"></xref>.
For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding
Caches and MAGs can provide IPv4 support in access networks.
Correspondingly, multicast membership management will be performed
by the MN using IGMP. For multi-protocol multicast support on the
network side, IGMPv3 router functions are required at both MAGs (see
<xref target="MLD-compat"></xref> for compatibility considerations
with previous IGMP versions). Context transfer between MAGs can
transparently proceed in the HI/HACK message exchanges by
encapsulating IGMP multicast state records within Multicast Mobility
Options (see <xref target="multicast-option"></xref> and <xref
target="multicast-ack"></xref> for details on message formats).</t>
<t>The deployment of IPv4 multicast support SHOULD be homogeneous
across a PMIP domain. This avoids multicast service breaks during
handovers.</t>
<t>It is worth mentioning the scenarios of a dual-stack IPv4/IPv6
access network, and the use of GRE tunneling as specified in<xref
target="RFC5845"> </xref>. Corresponding implications and operations
are discussed in the PMIP Multicast Base Deployment document,
see<xref target="RFC6224"> </xref>.</t>
</section>
</section>
</section>
<section title="Message Formats">
<t></t>
<section anchor="m-prtrtadv"
title="Multicast Indicator for Proxy Router Advertisement (PrRtAdv)">
<t>This document updates the Proxy Router Advertisements (PrRtAdv)
message format defined in Section 6.1.2. of <xref
target="RFC5568"></xref>. The update assigns the first bit of the
Reserved field, to carry the 'M' bit, as defined in <xref
target="fig-m-PrRtAdv"></xref>. An FMIPv6 AR indicates support for
multicast by assigning the setting 'M' bit to a value of 1.</t>
<figure anchor="fig-m-PrRtAdv"
title="Multicast Indicator Bit for Proxy Router Advertisement (PrRtAdv) Message">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |M| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure>
<t></t>
<t>This document updates the reserved field to include the 'M' bit
specified as follows.</t>
<t><list style="empty">
<t>M = 1 indicates that the specifications of this document
apply</t>
<t>M = 0 indicates that the behaviour during Fast Handover
proceeds according to <xref target="RFC5568"></xref>.</t>
</list>The default value (0) of this bit indicates a non-multicast
capable service.</t>
</section>
<section anchor="m-mobheader"
title="Extensions to Existing Mobility Header Messages">
<t>The fast handover protocols use an IPv6 header type called Mobility
Header as defined in <xref target="RFC6275"></xref>. Mobility headers
can carry variable Mobility Options.</t>
<t>The multicast listener context of an MN is transferred in fast
handover operations from PAR/PMAG to NAR/NMAG within a new Multicast
Mobility Option, and MUST be acknowledged by a corresponding Multicast
Acknowledgement Option. Depending on the specific handover scenario
and protocol in use, the corresponding option is included within the
mobility option list of HI/HACK only (PFMIPv6), or of
FBU/FBACK/HI/HACK (FMIPv6).</t>
</section>
<section anchor="multicast-option" title="New Multicast Mobility Option">
<t>This section defines the Multicast Mobility Option. It contains the
current listener state record of the MN obtained from the MLD
Multicast Listener Report message, and has the format displayed in
<xref target="mcast-mobopt"></xref>.</t>
<figure anchor="mcast-mobopt" title="Mobility Header Multicast Option">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>XXX RFC Editor note: IANA is requested to allocate the value TBD1
and remove this note prior to publication.</t>
<t>Type: TBD1</t>
<t>Length: 8-bit unsigned integer. The length of this option in 32 bit
words, not including the Option Type, Option Length, Option-Code and
Reserved fields.</t>
<t><list style="hanging">
<t hangText="Option-Code:"><list style="hanging">
<t hangText="1:">IGMPv3 Payload Type</t>
<t hangText="2:">MLDv2 Payload Type</t>
<t hangText="3:">IGMPv3 Payload Type from IGMPv2 Compatibility
Mode</t>
<t hangText="4:">MLDv2 Payload Type from MLDv1 Compatibility
Mode</t>
</list></t>
</list>Reserved: MUST be set to zero by the sender and MUST be
ignored by the receiver.</t>
<t>MLD or IGMP Report Payload: this field is composed of the
Membership Report message after stripping its ICMP header. This Report
Payload always contains an integer number of multicast records.
Corresponding message formats are defined for MLDv2 in <xref
target="RFC3810"></xref>, and for IGMPv3 in <xref
target="RFC3376"></xref>. This field MUST always contain the first
header line (reserved field and No of Mcast Address Records).</t>
<t><xref target="mld-payload"></xref> shows the Report Payload for
MLDv2, while the payload format for IGMPv3 is defined corresponding to
the IGMPv3 payload format (see Section 5.2. of <xref
target="RFC3810"></xref>, or Section 4.2 of <xref
target="RFC3376"></xref> for the definition of Multicast Address
Records).</t>
<figure anchor="mld-payload" title="MLDv2 Report Payload">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |No of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast Address Record (1) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (2) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record (M) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section anchor="multicast-ack"
title="New Multicast Acknowledgement Option">
<t>The Multicast Acknowledgement Option reports the status of the
context transfer and contains the list of state records that could not
be successfully transferred to the next access network. It has the
format displayed in <xref target="mcast-AckOpt"></xref>.</t>
<figure anchor="mcast-AckOpt"
title="Mobility Header Multicast Acknowledgement Option">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MLD or IGMP Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>XXX RFC Editor note: IANA is requested to allocate the value TBD2
and remove this note prior to publication.</t>
<t>Type: TBD2</t>
<t>Length: 8-bit unsigned integer. The length of this option in 32 bit
words, not including the Option Type, Option Length, Option-Code and
Status fields.</t>
<t>Option-Code: 0</t>
<t><list style="hanging">
<t hangText="Status:"><list style="hanging">
<t hangText="1:">Report Payload type unsupported</t>
<t hangText="2:">Requested group service unsupported</t>
<t hangText="3:">Requested group service administratively
prohibited</t>
</list></t>
</list></t>
<t>MLD or IGMP Unsupported Report Payload: this field is syntactically
identical to the MLD and IGMP Report Payload field described in <xref
target="multicast-option"></xref>, but is only composed of those
multicast address records that are not supported or prohibited in the
new access network. This field MUST always contain the first header
line (reserved field and No of Mcast Address Records), but MUST NOT
contain any Mcast Address Records, if the status code equals 1.</t>
<t>Note that group subscriptions to specific sources may be rejected
at the destination network, and thus the composition of multicast
address records may differ from initial requests within an MLD or IGMP
Report Payload option.</t>
</section>
<section anchor="number-of-addresses"
title="Length Considerations: Number of Records and Addresses">
<t>Mobility Header Messages exchanged in HI/HACK and FBU/FBACK dialogs
impose length restrictions on multicast context records due to the 8
bit Length field. The maximal payload length available in FBU/FBACK
messages is 4 octets (Mobility Option header line) + 1024 octets (MLD
Report Payload). For example, not more than 51 Multicast Address
Records of minimal length (without source states) may be exchanged in
one message pair. In typical handover scenarios, this number reduces
further according to unicast context and Binding Authorization data. A
larger number of MLD Reports that exceeds the available payload size
MAY be sent within multiple HI/HACK or FBU/FBACK message pairs. In
PFMIPv6, context information can be fragmented over several HI/HACK
messages. However, a single MLDv2 Report Payload MUST NOT be
fragmented. Hence, for a single Multicast Address Record, the number
of source addresses (S,.) is limited to 62.</t>
</section>
<section anchor="MLD-compat"
title="MLD and IGMP Compatibility Requirements">
<t>Access routers (MAGs) MUST support MLDv2 and IGMPv3. To enable
multicast service for MLDv1 and IGMPv2 listeners, the routers MUST
follow the interoperability rules defined in <xref
target="RFC3810"></xref> and <xref target="RFC3376"></xref>, and
appropriately set the Multicast Address Compatibility Mode.</t>
<t>When the Multicast Address Compatibility Mode is MLDv1 or IGMPv2, a
router internally translates the following MLDv1 and IGMPv2 messages
for that multicast address to their MLDv2 and IGMPv3 equivalents and
uses these messages in the context transfer. The current state of
Compatibility Mode is translated into the code of the Multicast
Mobility Option as defined in <xref target="multicast-option"></xref>.
A NAR (NMAG) receiving a Multicast Mobility Option during handover
will switch to the lowest level of MLD and IGMP Compatibility Mode
that it learned from its previous and new option values. This minimal
compatibility agreement is used to allow for continued operation.</t>
</section>
</section>
<section title="Security Considerations">
<t>Security vulnerabilities that exceed issues discussed in the base
protocols of this document (<xref target="RFC5568"></xref>, <xref
target="RFC5949"></xref>, <xref target="RFC3810"></xref>, <xref
target="RFC3376"></xref>) are identified as follows.</t>
<t>Multicast context transfer at predictive handovers implements group
states at remote access routers and may lead to group subscriptions
without further validation of the multicast service requests. Thereby a
NAR (NMAG) is requested to cooperate in potentially complex multicast
re-routing and may receive large volumes of traffic. Malicious or
inadvertent multicast context transfers may result in a significant
burden of route establishment and traffic management onto the backbone
infrastructure and the access router itself. Rapid re-routing or traffic
overload can be mitigated by a rate control at the AR that restricts the
frequency of traffic redirects and the total number of subscriptions. In
addition, the wireless access network remains protected from multicast
data injection until the requesting MN attaches to the new location.</t>
</section>
<section title="IANA Considerations">
<t>This document defines two new mobility options which need allocation
from the Mobility Header Type registry at
http://www.iana.org/assignments/mobility-parameters.</t>
<t>XXX RFC Editor note: IANA is requested to allocate the values TBD1
and TBD2 and remove this note prior to publication.</t>
<t><list style="empty">
<t>TBD1 Multicast Mobility Option, described in <xref
target="multicast-option"></xref></t>
<t>TBD2 Multicast Acknowledgement Option, described in <xref
target="multicast-ack"></xref></t>
</list>RFC Editor note: The RFC Editor is requested to replace "TBD*"
by the IANA-assigned value prior to publication and may then remove this
note.</t>
</section>
<section title="Acknowledgments">
<t>Protocol extensions to support multicast in Fast Mobile IPv6 have
been loosely discussed for several years. Repeated attempts have been
taken to define corresponding protocol extensions. The first draft <xref
target="fmcast-mip6"></xref> was presented by Suh, Kwon, Suh, and Park
in 2004.</t>
<t>This work was stimulated by many fruitful discussions in the MobOpts
research group. We would like to thank all active members for
constructive thoughts and contributions on the subject of multicast
mobility. The MULTIMOB working group has provided continuous feedback
during the evolution of this work. Comments, discussions, and reviewing
remarks have been contributed by (in alphabetical order) Carlos J.
Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao, Brian Haberman, Dirk
von Hugo, Min Hui, Georgios Karagian, Marco Liebsch, Behcet Sarikaya,
Stig Venaas and Juan Carlos Zuniga.</t>
<t>Funding has been provided by the German Federal Ministry of Education
and Research within the projects Mindstone, SKIMS and SAFEST, which is
gratefully acknowledged.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6275"?>
<?rfc include="reference.RFC.5213"?>
<?rfc include="reference.RFC.5568"?>
<?rfc include="reference.RFC.5949"?>
<?rfc include="reference.RFC.1112"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.3810"?>
<?rfc include="reference.RFC.3376"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5757"?>
<reference anchor="fmcast-mip6">
<front>
<title>Fast Multicast Protocol for Mobile IPv6 in the fast handovers
environments</title>
<author initials="K." surname="Suh">
<organization>Samsung Electronics</organization>
</author>
<author initials="D." surname="Kwon">
<organization>Postech</organization>
</author>
<author initials="Y." surname="Suh">
<organization>Postech</organization>
</author>
<author initials="Y." surname="Park">
<organization>Samsung Electronics</organization>
</author>
<date month="July" year="2004" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-suh-mipshop-fmcast-mip6-00" />
<format target="http://tools.ietf.org/html/draft-suh-mipshop-fmcast-mip6-00"
type="TXT" />
</reference>
<reference anchor="FMIPv6-Analysis">
<front>
<title>Predictive versus Reactive - Analysis of Handover Performance
and Its Implications on IPv6 and Multicast Mobility</title>
<author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization>
</author>
<author initials="M." surname="Waehlisch">
<organization>link-lab</organization>
</author>
<date month="November" year="2005" />
</front>
<seriesInfo name="Telecommunication Systems"
value="Vol 33, No. 1-3, pp. 131-154" />
<format target="http://dx.doi.org/10.1007/s11235-005-4321-4"
type="PDF" />
</reference>
<?rfc include="reference.RFC.6224"?>
<?rfc include="reference.RFC.7287"?>
<?rfc include="reference.RFC.5844"?>
<?rfc include="reference.RFC.5845"?>
</references>
<section title="Considerations for Mobile Multicast Sources">
<t>This document specifies protocol operations for a fast handover of
mobile listeners, only. In this appendix, we briefly discuss aspects of
supporting mobile multicast sources.</t>
<t>In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender
support is likely to be enabled by any one of the mechanisms described
in <xref target="RFC7287"></xref>. In this case, multicast data packets
from an MN are transparently forwarded either to its associated LMA or
to a multicast-enabled access network. In all cases, a mobile source can
continue to transmit multicast packets after a handover from PMAG to
NMAG without additional management operations. Packets (with a
persistent source address) will continue to flow via the LMA or the
access network into the previously established distribution system.</t>
<t>In contrast, an MN will change its Care-of Address while performing
FMIPv6 handovers. Even though MNs are enabled to send packets via the
reverse NAR-PAR tunnel using their previous Care-of Address for a
limited time, Multicast sender support in such a Mobile IPv6 regime will
most likely follow one of the basic mechanisms (1) bidirectional
tunneling, (2) remote subscription, or (3) agent-based as described in
Section 5.1 of <xref target="RFC5757"></xref>. A solution for multicast
senders that is homogeneously deployed throughout the mobile access
network can support seamless services during Fast Handovers, the details
of which are beyond the scope of this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 16:17:08 |