One document matched: draft-schmidt-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="std"
docName="draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07"
ipr="trust200902">
<?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." 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>Cisco Systems</organization>
<address>
<postal>
<street>30 International Place</street>
<street>Xuanwu District,</street>
<city>Tewksbury</city>
<code>MA 01876</code>
<country>USA</country>
</postal>
<email>rkoodli@cisco.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>
<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, are comprised of delay-sensitive real-time traffic
and will benefit from fast handover execution. 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Mobile IPv6 <xref target="RFC3775"></xref> defines a network layer
mobility protocol involving mobile nodes participation, 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 application scenarios. Mobile IPv6 Fast Handovers
(FMIPv6) <xref target="RFC5568"></xref>, and Fast Handovers for Proxy
Mobile IPv6 (PFMIPv6) <xref target="RFC5949"></xref> improve these
handover delays for unicast communication to the order of the maximum
delay 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 reception 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 at all in
<xref target="RFC5213"></xref>, but are subject to current specification
<xref target="RFC6224"></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 serve applications such as IPTV
with high-volume content streams to be distributed to potentially large
numbers of receivers, and therefore should 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 of FMIPv6 and PFMIPv6 for
including multicast traffic management in fast handover operations. The
solution common to both underlying protocols defines the per-group
transfer of multicast contexts between ARs or MAGs. The protocol defines
corresponding message extensions necessary for carrying group 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>This specification is applicable 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>
</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="RFC3775"></xref>, and
<xref target="RFC5213"></xref>. In addition, the following terms are
introduced:</t>
</section>
<section title="Protocol Overview">
<t></t>
<t>The reference scenario for multicast fast handover is illustrated in
<xref target="fig1"></xref>.</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 MN's forthcoming move to a new AR and
assist the MN to immediately resume communication on the new subnet
link using its previous IP address. In contrast to unicast, multicast
stream 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>. Multicast listeners at handover may take the
twofold advantage of including the multicast groups under subscription
in context transfer. First, the NAR can proactively join the desired
groups as soon as it gains knowledge of them. Second, multicast
streams MAY be included in traffic forwarding via the tunnel
established from PAR to 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 NAR. 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, PAR will initiate an
AR-binding and context transfer by transmitting a HI message to NAR
(NMAG). HI 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, NAR returns a multicast
acknowledgement in its HACK answer that indicates its ability to
support each requested group (see <xref
target="multicast-ack"></xref>). NAR (NMAG) expresses its willingness
to receive multicast traffic from forwarding by PAR using standard MLD
signaling. There are several reasons to waive forwarding, e.g., the
group could already be under native subscription or capacity
constraints can hinder decapsulation of additional streams at the NAR.
On the previous network side, forwarding of multicast traffic can be
in conflict with capacity or policy constraints of PAR.</t>
<t>For the groups requested, PAR MAY add the tunnel interface to its
multicast forwarding database, so that multicast streams can be
forwarded in parallel to unicast traffic. NAR, taking the role of an
MLD proxy <xref target="RFC4605"></xref> with upstream router PAR,
will submit an MLD report on this upstream tunnel interface to request
the desired groups, but will terminate multicast forwarding <xref
target="RFC3810"></xref> from PAR, as soon as group traffic natively
arrives. In addition, NAR immediately joins all groups that are not
already under subscription using its native multicast upstream
interface and loopback as downstream. It starts to downstream
multicast forwarding after the MN has arrived.</t>
<t>In a reactive fast handover, 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 are
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 though, 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 react on the departure of the MN in the context of
local group management. Depending on the multicast state management,
link type and MLD parameters deployed (cf., <xref
target="RFC5757"></xref>), it is requested to take appropriate actions
to adjust multicast service to requirements of the remaining
nodes.</t>
<t>In this way, the MN will be able to participate in multicast group
communication with a handover performance comparable to that for
unicast, while network resource consumption is minimized.</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 handovers.</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, FBU is issued on the previous link and received
by PAR as displayed in <xref target="fmip-pred"></xref>. 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
FBACK message. From receiving FBACK, the MN will learn about a per
group multicast support in the new access network. If some groups or a
multicast flavour are not supported, it MAY decide on taking actions
to compensate the missing service. 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 call flow for reactive mode is visualized 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 NAR forwards to PAR without processing. At this
time, the MN is able to re-join all desired multicast groups without
relying on AR assistance. Nevertheless, multicast context options are
exchanged in the HI/HACK dialog to facilitate intermediate forwarding
of requested streams. Note that group traffic possibly already arrives
from a MN's subscription at the time NAR receives the HI message. Such
streams may be transparently excluded from forwarding by setting an
appropriate multicast acknowledge option. In any case, NAR MUST ensure
that not more than one stream 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. 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 record of MN's
multicast membership. First, MAGs MAY perform an explicit tracking
(cf., <xref target="RFC4605"></xref>, <xref target="RFC6224"></xref>)
or extract membership status from forwarding states at node-specific
point-to-point links. Second, routers can perform general queries at
handovers. Both methods are equally applicable. However, a router that
does not operate explicit tracking MUST query its downstream links
subsequent to handovers. In either case, the PAR will become
knowledgeable about multicast group subscriptions of the MN.</t>
<t>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 learn about the multicast
groups under subscription. 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 about MN's attachment
to the N-AN and establish connectivity by means of 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 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>, PMAG acknowledges those
requested groups in its HACK answer that 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></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 within fast
handover operations will inform about its MLD listener state records
within handover signaling.</t>
<t>When sensing a handover in predictive mode, an MN will 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. It will receive the Multicast
Acknowledgement Option(s) as part of 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 bridge missing multicast
services in the new access network. 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 appends an 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 desired
multicast groups (channels) directly on its newly established access
link.</t>
</section>
<section title="Operations of the Previous Access Router">
<t>A PAR will advertise its multicast support by setting the M-bit
in PrRtAdv.</t>
<t>In predictive mode, a PAR will receive the multicast listener
state of a MN prior to handover from the Multicast Mobility Option
appended to the FBU. It will forward 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 AR 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 NAR. In response to receiving multicast
subscriptions, PAR will normally forward group data acting as a
normal multicast router or proxy. However, NAR MAY refuse to forward
some or all of the multicast streams.</t>
<t>In reactive mode, PAR will receive the FBU augmented by the
Multicast Mobility Option from the new network, but will continue
with an identical multicast record exchange in the HI/HACk dialog.
As in the predictive case, it will configure the PAR-to-NAR tunnel
for multicast downstream and forward data according to MLD reports
obtained from NAR, if capable of forwarding.</t>
<t>In both modes, PAR will interpret the first of the two events,
the departure of the MN or the reception of the Multicast
Acknowledgement Option(s) 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 Access Router">
<t>NAR will advertise its multicast support by setting the M-bit in
PrRtAdv.</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, 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, NAR joins the groups desired for forwarding on the
tunnel link.</t>
<t>In reactive mode, NAR will learn about the multicast listener
state of a new MN from the Multicast Mobility Option appended to HI
at a time, when the MN has already performed local subscriptions of
the multicast service. Thus 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, NAR MUST send a LEAVE message to the tunnel
immediately after forwarding of a group (channel) becomes unneeded,
e.g., after native multicast traffic arrives or group membership of
the MN terminates.</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 gaining knowledge
of the multicast subscriptions of the MN, 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. PMAG then
waits for receiving the Multicast Acknowledgement Option(s) with
HACK (see <xref target="multicast-ack"></xref>) and the creation of
the bidirectional tunnel with NMAG. Thereafter PMAG will add 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, 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 it
receives an MLD listener report message from NMAG. However, it MAY
deny forwarding service. After the departure of the MN and on the
reception of LEAVE messages for groups/channels, PMAG MUST terminate
forwarding of the specific groups and update 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 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 HACK listing those
groups/channels unsupported at 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 NMAG. At the reception of LEAVE
messages for groups (channels), PMAG MUST terminate forwarding of
the specific groups and update its multicast forwarding database.
According to its multicast forwarding states, it MAY 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, 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 Multicast Mobility Option for a
currently unattached node follows the predictive fast handover mode
as NMAG. It will decide on those multicast groups/channels it wants
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 unicast
HACK message being submitted prior to multicast state
acknowledgement - sent in an additional HACK message to the PMAG.
Immediately thereafter, NMAG SHOULD update its MLD listener state by
the new groups/channels obtained from the Multicast Mobility Option.
Until the MN re-attaches, NMAG uses its loopback interface for
downstream and does not forward traffic to the potential link of the
MN. NMAG SHOULD issue JOIN messages for those newly adopted groups
to its regular multicast upstream interface. As soon as the
bidirectional tunnel with PMAG is established, NMAG additionally
joins those groups/channels on the tunnel interface that it wants to
receive by forwarding from PMAG. NMAG MUST send a LEAVE message to
the tunnel immediately after forwarding of a group/channel becomes
unneeded, e.g., after native multicast traffic arrives or group
membership of the MN terminates.</t>
<t>A MAG experiencing a connection request for a MN without prior
reception of a corresponding Multicast Mobility Option is operating
in the reactive fast handover mode as NMAG. Following the
re-attachment, it immediately issues an MLD General Query to learn
about multicast subscriptions of the newly arrived MN. Using
standard multicast operations, 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
upcoming of the bidirectional tunnel, NMAG additionally joins those
groups/channels on the tunnel interface that it wants to receive by
forwarding from PMAG. When multicast streams arrive, the NMAG
forwards data to the appropriate downlink(s). NMAG MUST send a LEAVE
message to the tunnel immediately after forwarding of a
group/channel becomes unneeded, e.g., after native multicast traffic
arrives or group membership of the MN terminates.</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 multiprotocol 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 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>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, cf.,
<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>An FMIPv6 AR will indicate its multicast support by activating the
M-bit in its Proxy Router Advertisements (PrRtAdv). The message
extension has the following format.</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>
</section>
<section anchor="m-mobheader"
title="Extensions to Existing Mobility Header Messages">
<t>The fast handover protocols use a new IPv6 header type called
Mobility Header as defined in <xref target="RFC3775"></xref>. Mobility
headers can carry variable Mobility Options.</t>
<t>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 acknowledged by a corresponding 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>The Multicast Mobility Option 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>Type: TBD</t>
<t>Length: 8-bit unsigned integer. The size of this option in 8 octets
including the Type, Option-Code, and Length 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. Corresponding message
formats are defined for MLDv2 in <xref target="RFC3810"></xref>, and
for IGMPv3 in <xref target="RFC3376"></xref>.</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>Type: TBD</t>
<t>Length: 8-bit unsigned integer. The size of this option in 8
octets. The length is 1 when the MLD (IGMP) Unsupported Report Payload
field contains no Mcast Address Record.</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>Reserved: MUST be set to zero by the sender and MUST be
ignored by the receiver.</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. The maximal
payload length available in FBU/FBACK messages is the PATH-MTU - 40
octets (IPv6 Header) - 6 octets (Mobility Header) - 6 octets
(FBU/FBACK Header). For example, on an Ethernet link with an MTU of
1500 octets, not more than 72 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 Report Payloads 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 on an
Ethernet link, the number of source addresses is limited to 89.</t>
</section>
<section anchor="MLD-compat" title="MLD (IGMP) Compatibility Aspects">
<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. 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 (IGMPv2) 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 minimum obtained from its previous and newly learned value of MLD
(IGMP) Compatibility Mode 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 new flags and status codes in the HI and HAck
messages as well as two new mobility options. The Type values for these
mobility options are assigned from the same numbering space as allocated
for the other mobility options defined in <xref
target="RFC3775"></xref>. Those for the flags and status codes are
assigned from the corresponding numbering space defined in <xref
target="RFC5568"></xref>, or <xref target="RFC5949"></xref> and
requested to be created as new tables in the IANA registry (marked with
asterisks). New values for these registries can be allocated by
Standards Action or IESG approval <xref target="RFC5226"></xref>.</t>
</section>
<section title="Acknowledgments">
<t>Protocol extensions to support multicast in Fast Mobile IPv6 have
been loosely discussed since 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
already 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. Comments, discussions and reviewing remarks have been
contributed by (in alphabetical order) Carlos J. Bernardos, Luis M.
Contreras, Dirk von Hugo, Marco Liebsch, Behcet Sarikaya, Stig Venaas
and Juan Carlos Zuniga.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3775"?>
<?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.5844"?>
<?rfc include="reference.RFC.5845"?>
</references>
<section title="Change Log ">
<t>The following changes have been made from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04. <list
style="numbers">
<t>Following working group feedback, multicast traffic forwarding is
now a two-sided option between PAR (PMAG) and NAR (NMAG): Either
access router can decide on its contribution to the data plane.</t>
<t>Several editorial improvements.</t>
</list></t>
<t>The following changes have been made from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-03. <list
style="numbers">
<t>References updated.</t>
</list></t>
<t>The following changes have been made from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-02. <list
style="numbers">
<t>Detailed operations on PFMIPv6 entities completed.</t>
<t>Some editorial improvements & clarifications.</t>
<t>References updated.</t>
</list></t>
<t>The following changes have been made from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01. <list
style="numbers">
<t>First detailed operations on PFMIPv6 added.</t>
<t>IPv4 support considerations for PFMIPv6 added.</t>
<t>Section on length considerations for multicast context records
corrected.</t>
<t>Many editorial improvements & clarifications.</t>
<t>References updated.</t>
</list></t>
<t>The following changes have been made from
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-00. <list
style="numbers">
<t>Editorial improvements & clarifications.</t>
<t>Section on length considerations for multicast context records
added.</t>
<t>Section on MLD/IGMP compatibility aspects added.</t>
<t>Security section added.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:30:24 |