One document matched: draft-schmidt-multimob-pmipv6-mcast-deployment-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="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="bcp"
docName="draft-schmidt-multimob-pmipv6-mcast-deployment-00"
ipr="trust200811">
<front>
<title abbrev="Multicast Listeners in PMIPv6">A Minimal Deployment Option
for Multicast Listeners in PMIPv6 Domains</title>
<author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>20099</code>
<country>Germany</country>
</postal>
<email>schmidt@informatik.haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/schmidt</uri>
</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>10318</code>
<country>Germany</country>
</postal>
<email>mw@link-lab.net</email>
</address>
</author>
<author fullname="Behcet Sarikaya" initials="B." surname="Sarikaya">
<organization>Huawei USA</organization>
<address>
<postal>
<street>1700 Alma Dr. Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<email>sarikaya@ieee.org</email>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<country>Canada</country>
</postal>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<date day="13" month="June" year="2009" />
<abstract>
<t>This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to Home Agents in
Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
subscription anchor points, while Mobile Access Gateways provide MLD
proxy functions. In this scenario, Mobile Nodes remain agnostic of
multicast mobility operations.</t>
</abstract>
<note title="Requirements Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Proxy Mobile IPv6 (PMIPv6) <xref target="RFC5213"></xref> extends
Mobile IPv6 <xref target="RFC3775"></xref> by network-based management
functions that enable IP mobility for a host without requiring its
participation in any mobility-related signaling. Additional network
entities, i.e., the Local Mobility Anchor (LMA), and Mobile Access
Gateways (MAGs), are responsible for managing IP mobility on behalf of
the mobile node (MN).</t>
<t>With these routing entities in place, the mobile node looses
transparent end-to-end connectivity to the static Internet, and in the
particular case of multicast communication, group membership management
as signaled by the Multicast Listener Discovery protocol <xref
target="RFC3810"></xref>, <xref target="RFC2710"></xref> requires a
dedicated treatment, see <xref
target="I-D.deng-multimob-pmip6-requirement"></xref>.</t>
<t>Multicast routing functions need a careful placement within the
PMIPv6 domain to augment unicast transmission with group communication
services. <xref target="RFC5213"></xref> does not explicitly address
multicast communication, whereas bi-directional home tunneling, the
minimal multicast support arranged by MIPv6, cannot be applied in
network-based management scenarios: A mobility-unaware node will
experience no reason to initiate a tunnel with an entity of mobility
support.</t>
<t>This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to Home Agents in
Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
subscription anchor points, while Mobile Access Gateways provide MLD
proxy functions. Mobile Nodes in this scenario remain agnostic of
multicast mobility operations. Accrediting the problem space of
multicast mobility <xref target="I-D.irtf-mobopts-mmcastv6-ps"></xref>,
this document does not address optimization potentials and efficiency
improvements of multicast routing in network-centered mobility, as such
solutions would require changes to the base specification of <xref
target="RFC5213"></xref>.</t>
</section>
<section title="Terminology">
<t>This document uses the terminology as defined for the mobility
protocols <xref target="RFC3775"></xref> and <xref target="RFC5213">
</xref>, as well as the multicast edge related protocols <xref
target="RFC3810"></xref> and <xref target="RFC4605"></xref>.</t>
<t>The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in <xref target="fig1"></xref>.</t>
<t></t>
<figure anchor="fig1"
title="Reference Network for Multicast Deployment in PMIPv6">
<artwork><![CDATA[ +-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| MLD Querier
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3]]></artwork>
</figure>
</section>
<section title="Overview">
<t>An MN in a PMIPv6 domain will decide on multicast group membership
management completely independent of its current mobility conditions. It
will submit MLD Report and Done messages following application desires,
thereby using its link-local source address and multicast destinations
according to <xref target="RFC3810"></xref>, or <xref target="RFC2710">
</xref>. These link-local signaling messages will arrive at the
currently active MAG via one of its downstream local (wireless) links. A
multicast unaware MAG would simply discard these MLD messages.</t>
<t>To facilitate multicast in a PMIPv6 domain, an MLD proxy function
<xref target="RFC4605"></xref> needs to be deployed on the MAG that
selects the tunnel interface corresponding to the MN's LMA for its
upstream interface (cf., section 6 of <xref target="RFC5213"></xref>).
Thereby each LMA upstream interface defines an MLD proxy domain at the
MAG, containing all downstream links to MNs that share this LMA. MLD
signaling of the MN will be consequently forwarded up the tunnel
interface to its corresponding LMA.</t>
<t>Serving as the designated multicast router or an additional MLD
proxy, the LMA will transpose any MLD messages of the MN into the
multicast routing infrastructure. Correspondingly, the LMA will
implement appropriate multicast forwarding states at its tunnel
interface. Traffic arriving for groups under subscription will arrive at
the LMA, which it will forward according to all its group/source states.
In addition, the LMA will naturally act as an MLD querier, seeing its
downstream tunnel interfaces as multicast enabled links.</t>
<t>At the MAG, MLD queries and multicast data will arrive on the
(tunnel) interface that is assigned to a group of access links as
identified by its Binding Update List (cf., section 6 of <xref
target="RFC5213"></xref>). As specified for MLD proxies, the MAG will
forward multicast traffic and related signaling down the appropriate
access links to the MNs. In proceeding this way, all multicast-related
signaling and the corresponding traffic will transparently flow from the
LMA to the MN on an LMA-specific shared tree.</t>
<t>In case of a mobility handover, the (IP mobility unaware) MN will
refrain from submitting unsolicited MLD reports. Instead, the LMA is
required to maintain group memberships in the following way. On the
reception of a Proxy Binding Update (PBU) from the new MAG and
successful Re-Binding, the LMA re-establishes a route to the MN's home
network prefix over the tunnel interface corresponding to the new MAG
(cf., section 5.3 of <xref target="RFC5213"></xref>).</t>
<t>After Re-Binding, the LMA SHOULD issue a general MLD query on the new
tunnel link to refresh forwarding requirements. Queries can be omitted,
if multicast forwarding states previously established at the tunnel
interface towards the new MAG form a superset of those present at the
old tunnel interface. The LMA SHOULD likewise perform a general MLD
query after receiving a Binding De-Registration at a tunnel interface
that is to be maintained. The LMA MAY reduce the need for queries when
it applies explicit tracking in combination with <xref
target="RFC3810"></xref>.</t>
<t>These multicast deployment considerations likewise apply for mobile
nodes that operate with its IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide an IPv4 home address mobility support <xref
target="I-D.ietf-netlmm-pmip6-ipv4-support"></xref>. Such mobile node
will use IGMPv3 <xref target="RFC3376"></xref> signaling for multicast,
which is handled by an IGMP proxy function at the MAG in an analogous
way.</t>
<t>Following these deployment steps, multicast management transparently
interoperates with PMIPv6. It is worth noting that multicast streams can
possibly be distributed on redundant path, leading to duplicate traffic
arriving from different LMAs at one MAG, and causing multiple data
transmissions from a MAG over one wireless domain to different MNs.</t>
</section>
<section title="Deployment Details">
<t>Multicast activation in a PMIPv6 domain requires to deploy general
multicast functions at PMIPv6 routers and to define its interaction with
the PMIPv6 protocol in the following way:</t>
<section title="Operations of the Mobile Node">
<t>A Mobile Node willing to manage multicast traffic will join,
maintain and leave groups as if located in the fixed Internet. No
specific mobility actions nor implementations are required at the
MN.</t>
</section>
<section title="Operations of the Mobile Access Gateway">
<t>A Mobility Access Gateway is required to assist in MLD signaling
and data forwarding between the MNs which it serves, and the
corresponding LMAs associated to each MN. It therefore needs to
implement an instance of the MLD proxy function <xref
target="RFC4605"></xref> for each upstream tunnel interface that has
been established with an LMA. The MAG decides on the mapping of
downstream links to a proxy instance (and hence an upstream link to an
LMA) based on the regular Binding Update List as maintained by PMIPv6
standard operations (cf., section 6.1 of <xref
target="RFC5213"></xref>).</t>
<t>On the reception of MLD reports from an MN, the MAG MUST identify
the corresponding proxy instance from the incoming interface and
perform regular MLD proxy operations: it will insert/update/remove a
multicast forwarding state on the incoming interface and forward the
report to its upstream tunnel. Conversely on the reception of MLD
queries, the MAG proxy instance will transfer the queries to its
appropriate downstream interfaces. Multicast traffic arriving on an
upstream interface at the MAG will be forwarded according to the
group/source-specific forwarding states as acquired for each
downstream interface within the MLD proxy instance.</t>
<t>In case of a mobility handover, the MAG will continue to manage
upstream tunnels and downstream interfaces as foreseen in the PMIPv6
specification. However, it MUST assure consistency of its up- and
downstream interfaces that change under mobility with MLD proxy
instances and its multicast forwarding states.</t>
<t>In proceeding this way, the MAG is entitled to aggregate multicast
subscriptions for each of its MLD proxy instances. However, this
deployment approach does not prevent multiple identical streams
arriving from different LMA upstream interfaces. Furthermore, a per
group forwarding into the wireless domain is restricted to the link
model in use.</t>
</section>
<section title="Operations of the Local Mobility Anchor">
<t>For any MN, the Local Mobility Anchor acts as the persistent Home
Agent and at the same time as the default multicast querier. It
implements the function of the designated multicast router or a
further MLD proxy. According to MLD reports received from MNs (via
MAGs), it establishes/maintains/removes group/source-specific
multicast forwarding states at its downstream tunnel interfaces
established with MAGs, and at the same time procures for aggregated
multicast membership maintenance at its upstream interface. Based on
the multicast-transparent operations of the MAGs, the LMA experiences
its tunnel interfaces as multicast enabled downstream links serving
zero to many listening nodes. Multicast traffic arriving at the LMA is
transparently forwarded according to its multicast forwarding states.
The LMA MAY choose to apply explicit node tracking in combination with
MLDv2 <xref target="RFC3810"></xref>.</t>
<t>On the occurrence of a mobility handover, the LMA will receive
Binding Lifetime De-Registrations and Binding Lifetime Extensions that
will cause a re-mapping of home network prefixes to Proxy-CoAs in its
Binding Cache. Correspondingly, the multicast forwarding states
require updating, as well. In the absence of explicit tracking, the
LMA MUST proceed as follows:</t>
<t><list style="symbols">
<t>Issue a general multicast query on a tunnel interface that is
to be maintained even though a De-Registration was received.
Update the multicast forwarding states according to the query
outcome.</t>
<t>Issue a general multicast query on a tunnel interface at which
a Lifetime Extension was received from a new Proxy-CoA, if the
multicast forwarding states at this interface do not form a
superset of the states established at the interface corresponding
to the previous Proxy-CoA.</t>
</list>For multicast membership queries, two cases need
distinction:</t>
<t><list style="numbers">
<t>LMA multicast membership maintenance is unaffected by the
handover-related absence of the MN: In this case, the LMA actively
maintains states and continues to transmit multicast packets to
the down-tunnel towards the MN. The PMIPv6 protocol will transfer
the tunnel endpoints and access link binding states between
previous and new MAG, such that the MN can simply continue to
receive its group traffic under subscription. Service
interruptions are bound to the handover discontinuities
experienced for PMIPv6 unicast transmission.</t>
<t>A MN may be unable to answer LMA multicast membership queries
due to handover procedures. Such instance is equivalent to a
general query loss. To prevent erroneous query timeouts at the
LMA, MLD parameters SHOULD be carefully adjusted to the mobility
regime. In particular, MLD timers and the Robustness Variable (see
section 9 of <xref target="RFC3810"></xref>) MUST be chosen to be
compliant with the temporal handover operations of the PMIPv6
domain.</t>
</list></t>
<t>In proceeding this way, each LMA will provide transparent multicast
support for the group of MNs it serves. It will perform traffic
aggregation at the MN-group level and will assure that multicast data
streams are uniquely forwarded per individual LMA-to-MAG tunnel.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft does neither introduce additional messages nor novel
protocol operations. Consequently, no new threats arrive from procedures
described in this document in excess to <xref target="RFC3810"></xref>
and <xref target="RFC5213"></xref> security concerns.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This memo is the outcome of extensive previous discussions and a
follow-up of several initial drafts on the subject. The authors would
like to thank Gorry Fairhurst for advice and reviews of the
document.</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.3810"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.2710"?>
<?rfc include="reference.I-D.ietf-netlmm-pmip6-ipv4-support"?>
<?rfc include="reference.RFC.3376"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.irtf-mobopts-mmcastv6-ps"?>
<?rfc include="reference.I-D.deng-multimob-pmip6-requirement"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:39:16 |