One document matched: draft-ietf-multimob-fmipv6-pfmipv6-multicast-07.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-07"
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>schmidt@informatik.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 MIPv6 and 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>
</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 multicast 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 current specification <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 news items like stock-exchange prices are
commonly transmitted via multicast to support fair and fast updates.
Both may be mobile and both largely benefit from fast handover
operations. Operators may 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 predestined to 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>
</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, multicast
listeners may offer the 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 established from the PAR to the NAR.</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 MLD signaling. There are several
reasons to waive forwarding, 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 of capacity constraints that make it undesirable to
forward the multicast traffic. The PAR can add the tunnel interface 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 that
it requests the groups/channels 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 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 if 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.</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, 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 group-wise learn about the multicast support in
the new access network. If some groups or multicast service models are
not supported, it can decide on taking actions to overcome the 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 requested flows. The multicast traffic could arrive from
a MN subscription at the same time 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,
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
operate explicit tracking needs to query its downstream links
after a handover. The MLD membership information then allows the
PMAG (PAR) to learn the multicast group/channel subscriptions of
the MN.</t>
</list>In predictive mode, the PMAG (PAR) will learn about the
upcoming movement of the mobile node. Without explicit tracking, it
will immediately submit a general MLD query and receive MLD reports
for the subscribed group(s). As displayed in <xref
target="pfmip-pred"></xref>, it will initiate binding and context
transfer with the NMAG (NAR) by issuing a HI message that is augmented
by multicast contexts in the mobility options defined in <xref
target="multicast-option"></xref>. NAR 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 (NAR) 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 a MN attachment, the NMAG will send a general
MLD query and thereafter join the requested groups. 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>In this section the protocol operations are defined in a normative
way.</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 (IGMP)
multicast listener state and append it to the Fast Binding Update
(FBU) prior to signaling with PAR.</t>
<t>It will receive the Multicast Acknowledgement Option(s) as 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
like home tunneling to receive groups/channels not available from
NAR. No multicast-specific operation is required by the MN when
re-attaching in the new network besides standard FMIPv6
signaling.</t>
<t>In reactive mode, the MN MUST append the identical Multicast
Mobility Option to FBU sent after its reconnect. In response, it
will learn about the Multicast Acknowledgement Option(s) from FBACK
and expect corresponding multicast data. Concurrently it joins all
subscribed multicast groups (channels) 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 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 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 NAR within HI
messages and will expect Multicast Acknowledgement Option(s) in
HACK, which itself is returned to the MN as an appendix to FBACK. In
performing 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 await MLD
listener reports 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 and forwards data according to MLD reports
obtained from NAR, if capable of forwarding.</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 MLD/IGMP records from the
message and intersect the request subscription with its multicast
service offer. Further on it will adjoin the supported groups
(channels) to the MLD listener state using Loopback as downstream
interface. This will lead to suitable regular subscriptions on its
native multicast upstream interface without additional forwarding.
Concurrently, the NAR builds a Multicast Acknowledgement Option(s)
(see <xref target="multicast-ack"></xref>) listing those groups
(channels) unsupported on the new access link and returns them
within HACK. As soon as the bidirectional tunnel from PAR to NAR is
operational, the NAR joins the groups the MN has subscribed for
(which are then forwarded by PAR) via 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 a
HI message at a time, when the MN has already performed local
subscriptions of the multicast service. Thus the NAR solely
determines the intersection of requested and supported groups
(channels) and issues the join requests for group forwarding on the
PAR-NAR tunnel interface.</t>
<t>In both modes, the NAR MUST send a LEAVE message to the tunnel
after forwarding of a group (channel) becomes unneeded, e.g., after
native multicast traffic arrives or group membership of the MN
terminates. Sending this immediately eliminates the need for PAR and
NAR to process traffic that is not 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 for 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 the multicast
packet loss, but may 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).</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 predictive fast handover mode as a PMAG. It MUST issue an MLD
General Query immediately on its corresponding link unless it
performs an explicit 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 (IGMP)
multicast listener state. If not empty, this Mobility Option is
appended to the regular fast handover HI messages, or - in the case
of unicast HI message being submitted prior to multicast state
detection - 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 (channels) 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) in concordance with the network
policy. It SHOULD start forwarding traffic down the tunnel interface
for those groups for which an MLD listener report was received from
NMAG. However, it MAY deny forwarding for some or all groups
included in the listener report.</t>
<t>After the departure of the MN and on the reception of LEAVE
messages for groups/channels, it is RECOMMENDED that the PMAG
terminates forwarding of the specific groups and updates its
multicast forwarding database. Correspondingly it issues a
group/channel LEAVE to its upstream link, if no more listeners are
present on its downstream links.</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 those groups/channels it does not support to forward to the
NMAG. It will add the bidirectional tunnel with NMAG to its
downstream interfaces and will start forwarding multicast traffic
for those groups it receives an MLD listener report message from the
NMAG. At the reception of LEAVE messages for groups (channels), the
PMAG terminates forwarding of the specific groups and update its
multicast forwarding database. According to its multicast forwarding
state, it will need to issue a group/channel LEAVE to its upstream
link, if no more listeners are present on its downstream links.</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 predictive fast handover
mode as an NMAG. It will decide on those multicast groups/channels
it selects to be forwarded from the PMAG and builds a Multicast
Acknowledgement Option (see <xref target="multicast-ack"></xref>)
that enumerates only unwanted groups/channels. 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 report received 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/channels on
the tunnel interface that it wants to receive 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 the missing groups
(channels) on its regular multicast upstream interface.
Concurrently, it selects groups (channels) for forwarding from PMAG
and builds a Multicast Mobility Option as described in <xref
target="multicast-option"></xref> that contains the MLD (IGMP)
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 those groups/channels on the tunnel interface that it wants 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
after forwarding of a group (channel) becomes unneeded, e.g., after
native multicast traffic arrives or group membership of the MN
terminates. Sending this immediately eliminates the need for PMAG
and NMAG to process traffic that is not 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 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 (IGMP) Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>RFC Editor note: IANA is requested to allocate the value XXX and
remove this note prior to publication.</t>
<t>Type: XXX</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 (IGMP) Report Payload: this field is composed of the MLD (IGMP)
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 (IGMP) Unsupported Report Payload +
~ ~
~ ~
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>RFC Editor note: IANA is requested to allocate the value XXX and
remove this note prior to publication.</t>
<t>Type: XXX</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 (IGMP) Unsupported Report Payload: this field is syntactically
identical to the MLD (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 (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 exceed 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 (IGMP) Compatibility Requirements">
<t>Access routers (MAGs) MUST support MLDv2 (IGMPv3). To enable
multicast service for MLDv1 (IGMPv2) listeners, the routers MUST
follow the interoperability rules defined in <xref
target="RFC3810"></xref> (<xref target="RFC3376"></xref>) and
appropriately set the Multicast Address Compatibility Mode.</t>
<t>When the Multicast Address Compatibility Mode is MLDv1 (IGMPv2), a
router internally translates the following MLDv1 (IGMPv2) messages for
that multicast address to their MLDv2 (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 (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><list style="empty">
<t>XXX Multicast Mobility Option, described in <xref
target="multicast-option"></xref></t>
<t>XXX Multicast Acknowledgement Option, described in <xref
target="multicast-ack"></xref></t>
</list>RFC Editor note: The RFC Editor is requested to replace "XXX"
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, 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"?>
<?rfc include="reference.RFC.5226"?>
</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 any case, 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:15:49 |