One document matched: draft-schmidt-multimob-fmipv6-pfmipv6-multicast-00.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-00"
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</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 day="01" month="March" year="2010" />
<abstract>
<t>Fast handover protocols for MIPv6 and PMIPv6 define mobility
management procedures that support unicast communication at reduced
handover latencies. 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 could strongly 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.</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="I-D.ietf-mipshop-pfmipv6"></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 further
specifications. It is assumed throughout this document that mechanisms
and protocol operations are in place to transport multicast traffic to
ARs. Symbolically, 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 like IPTV with
voluminous 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. Native multicast forwarding requires
forwarding states, 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 can continuously
perform remote subscriptions in the visited networks.</t>
<t>This document specifies extension 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 in use. ARs
or MAGs are then enabled to treat multicast traffic in correspondence to
fast unicast handovers and with analogous 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 groups prior to undergoing a fast
handover. It does not pose any requirements on 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="I-D.ietf-mipshop-pfmipv6"></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 such that
traffic follows the MN. This process may be significantly slower than
fast handover management <xref target="RFC5757"></xref>. Multicast
listeners at handover may take 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 thereof. 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
MN's handover, while in the reactive mode, these steps are executed
after the MN's re-attachment to NAR has been detected. 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 (e.g., PAR 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.
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 per group indicates its ability to support the
requested group, as well as its willingness to receive multicast
traffic forwarded from PAR (see <xref target="multicast-ack"></xref>).
There are several reasons to waive forwarding, e.g., the group may
already be under native subscription or capacity constraints at the
NAR may hinder decapsulation of additional streams. For the groups
requested, PAR will add the tunnel interface to its multicast
forwarding database, so that multicast streams are forwarded in
parallel to unicast traffic. NAR, taking the role of an MLD proxy
<xref target="RFC4605"></xref> with the upstream tunnel interface to
PAR, will submit an MLD report to request for 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 loopback interface, and starts 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. Depending on
the specific network topology, multicast traffic for some groups may
natively arrive before it is forwarded from PAR. However, PAR-NAR
forwarding SHOULD be procured for groups in far reach.</t>
<t>In both modes of operation, it is the responsibility of the PAR
(PMAG) to properly consider the departure of the MN for the local
group management. Depending on the multicast state management, link
type and MLD parameters deployed (cf., <xref
target="RFC5757"></xref>), it SHOULD 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 handover experiences comparable to unicast
performance, while network resources are preserved whenever
possible.</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 forward |
| packets ===============>|
| | |
| | |
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, 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 may already arrive from
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)|
| | |
| forward |
| packets(including FBack)=====>|
| | |
|<=================================== 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 operations are pursued by the
access routers or MAGs. The handover initiation, or the re-association
respectively is managed by the access networks. Consequently, access
routers need to be aware of multicast membership states 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="I-D.ietf-multimob-pmipv6-base-solution"></xref>) or extract
membership status from forwarding states at node-specific
point-to-point links. Second, routers may perform general queries.
Both methods are equally applicable, which leaves a final choice to
the implementation. 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 Initiate | |
| |--(MN ID, New AP ID)-->| |
| | | | |
| | | Optional: |
| | | MLD Query |
| | | | |
| | | |------HI---->|
| | | |(Multicast MobOpt)
| | | | |
| | | |<---HAck-----|
| | | |(Multicast AckOpt)
| | | | |
| | | | Join to
| | | | Multicast
| | | | Groups
| | | | |
| | | |HI/HAck(optional)
| | | |<- - - - - ->|
| | | | |
| | | forward |
| | | packets =======>|
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 states
at the MN. Triggered by MN's attachment, the NMAG will inquire on
group memberships by submitting 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="I-D.ietf-mipshop-pfmipv6"></xref>). For
multicast context transfer, the NMAG attaches those group identifiers
in multicast mobility options which it requests for forwarding. Using
the identical syntax in its option headers as defined in <xref
target="multicast-ack"></xref>, PMAG acknowledges the group forwarding
request in its HACK answer. 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)
| | | |<- - - - - ->|
| | | | |
| | | forward |
| | | packets =======>|
| | | | |
|<======================================== deliver packets
| | | | |
]]></artwork>
</figure>
<t></t>
</section>
</section>
<section title="Protocol Details">
<t></t>
<section title="Generals">
<t>:::TODO:</t>
</section>
<section title="Protocol Operations Specific to FMIPv6">
<t>:::TODO:</t>
</section>
<section anchor="det-pfmipv6"
title="Protocol Operations Specific to PFMIPv6">
<t>:::TODO:</t>
<section anchor="det-IPv4" title="IPv4 Support Considerations">
<t>:::TODO:</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 an
M-bit in its Proxy Router Advertisements (PrRtAdv). The message
extension is of the following form.</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>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 as 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: XX</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>
</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 line. 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 correspondingly
(see Section 5.2. of <xref target="RFC3810"></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 |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section anchor="number-of-addresses" title="Number of Addresses">
<t></t>
</section>
</section>
<section anchor="multicast-ack"
title="New Multicast Acknowledgement Option">
<t>The Multicast Acknowledgement Option reports on the status of
context transfer and contains the list of state records that could not
successfully be 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: XX</t>
<t>Length: 8-bit unsigned integer. The size of this option in 8
octets. The length is 1 when 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 Nr of Mcast Address Records), but MUST not
contain any Mcast Address Record, if 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="MLD-compat" title="MLD (IGMP) Compatibility Aspects">
<t>:::TODO:</t>
</section>
</section>
<section title="Security Considerations">
<t>:::TODO:</t>
</section>
<section title="IANA Considerations">
<t>This document defines new Mobility Options that need Type assignment
from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters ....</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.I-D.ietf-mipshop-pfmipv6"?>
<?rfc include="reference.RFC.1112"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.3810"?>
<?rfc include="reference.RFC.3376"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5757"?>
<reference anchor="fmcast-mip6">
<front>
<title>Fast Multicast Protocol for Mobile IPv6 in the fast handovers
environments</title>
<author initials="K." surname="Suh">
<organization>Samsung Electronics</organization>
</author>
<author initials="D." surname="Kwon">
<organization>Postech</organization>
</author>
<author initials="Y." surname="Suh">
<organization>Postech</organization>
</author>
<author initials="Y." surname="Park">
<organization>Samsung Electronics</organization>
</author>
<date month="July" year="2004" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-suh-mipshop-fmcast-mip6-00" />
<format target="http://tools.ietf.org/html/draft-suh-mipshop-fmcast-mip6-00"
type="TXT" />
</reference>
<reference anchor="FMIPv6-Analysis">
<front>
<title>Predictive versus Reactive - Analysis of Handover Performance
and Its Implications on IPv6 and Multicast Mobility</title>
<author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization>
</author>
<author initials="M." surname="Waehlisch">
<organization>link-lab</organization>
</author>
<date month="November" year="2005" />
</front>
<seriesInfo name="Telecommunication Systems"
value="Vol 33, No. 1-3, pp. 131-154" />
<format target="http://dx.doi.org/10.1007/s11235-005-4321-4"
type="PDF" />
</reference>
<?rfc include="reference.I-D.ietf-multimob-pmipv6-base-solution"?>
<reference anchor="PMIPv6v4">
<front>
<title>IPv4 Support for Proxy Mobile IPv6</title>
<author initials="R." surname="Wakikawa">
<organization>Toyota ITC</organization>
</author>
<author initials="S." surname="Gundavelli">
<organization>Cisco</organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-netlmm-pmip6-ipv4-support-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-04.txt"
type="TXT" />
</reference>
<?rfc ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:01:37 |