One document matched: draft-schmidt-multimob-pmipv6-mcast-deployment-01.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-01"
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="29" 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| Multicast Anchor
+----+ +----+
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 under aggregation 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 message from a MAG 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 initiate related signaling down the
appropriate access links to the MNs. In proceeding this way, all
multicast-related signaling and the data traffic will transparently flow
from the LMA to the MN on an LMA-specific tree, which is shared among
the multicast sources.</t>
<t>In case of a mobility handover, the (IP mobility unaware) MN will
refrain from submitting unsolicited MLD reports. Instead, the MAG is
required to maintain group memberships in the following way. On
activation of a link connecting a new MN, the MAG sends a General MLD
Query. Based on its outcome and the multicast group states previously
maintained at the MAG, a corresponding Report will be sent to the LMA
according to the proxy function. Additional Reports can be omitted,
whenever multicast forwarding states previously established at the new
MAG already cover the demands of the MN.</t>
<t>After Re-Binding, the LMA is not required to issue a General MLD
Query on the tunnel link to refresh forwarding states. Multicast state
updates SHOULD be triggered by the MAG, which aggregates subscriptions
of all its MNs (see the call flow in <xref
target="fig:callflow"></xref>).</t>
<figure anchor="fig:callflow" height=""
title="Call Flow of Multicast-enabled PMIP">
<artwork><![CDATA[MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| | < Movement to MAG2 & PMIP Binding Update > |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
]]></artwork>
</figure>
<t></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 state
updates will be merged in the MLD proxy membership database. An
aggregated Report will be sent to the upstream tunnel of the MAG when
the membership database <xref target="RFC4605">(cf., section 4.1 of
</xref>) changes. Conversely on the reception of MLD Queries, the MAG
proxy instance will answer the Queries on behalf of all active
downstream receivers maintained in its membership database. Queries
sent by the LMA do not force the MAG to trigger corresponding messages
immediately towards MNs. Multicast traffic arriving at the MAG on an
upstream interface 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. To learn about
multicast groups subscribed by a newly attaching MN, the MAG sends a
General Query to the MN access link as it goes up. In case the access
link between MN and MAG goes down, interface-specific multicast states
change. Both cases may alter the composition of the membership
database, which then will trigger corresponding Reports towards the
LMA.</t>
<t>A MN may be unable to answer MAG multicast membership queries due
to handover procedures. Such instance is equivalent to a General Query
loss. To prevent erroneous query timeouts at the MAG, 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>
<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 for the
corresponding MAG. It implements the function of the designated
multicast router or a further MLD proxy. According to MLD reports
received from a MAG (on behalf of the MNs), it
establishes/maintains/removes group/source-specific multicast
forwarding states at its corresponding downstream tunnel interfaces.
At the same time it 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.</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. The multicast forwarding states require updating, as
well, if the MN within a MLD proxy domain is the only receiver of a
multicast group. Two cases need distinction:</t>
<t><list style="numbers">
<t>The mobile node was the only receiver of a group behind the
interface a De-Registration was received: The membership database
of the MAG changes, which will trigger a Report/Done sent via the
MAG-to-LMA interface to remove this group. The LMA thus terminates
multicast forwarding.</t>
<t>The mobile node is the only receiver of a group behind the
interface a Lifetime Extension was received: The membership
database of the MAG changes, which will trigger a Report sent via
the MAG-to-LMA interface to add this group. The LMA thus starts
multicast distribution.</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 title="A Note on Explicit Tracking">
<t>IGMPv3/MLDv2 <xref target="RFC3376"></xref><xref target="RFC3810">,
</xref> may operate in combination with explict tracking, which allows
routers to monitor each multicast receiver. This mechanism is not
standardized yet, but widely implemented by vendors as it supports
faster leave latencies and reduced signaling.</t>
<t>Enabling explicit tracking on downstream interfaces of the LMA and
MAG would track a single MAG and MN respectively per interface. It may
be used to preserve bandwidth on the MAG-MN link.</t>
</section>
</section>
<section title="Message Source and Destination Address">
<t>This section describes source and destination address of MLD
messages. The interface identifier A-B denotes an interface on node A,
which is connected to node B. This includes tunnel interfaces.</t>
<section title="Query">
<figure>
<artwork><![CDATA[ +===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
]]></artwork>
</figure>
</section>
<section title="Report/Done">
<figure>
<artwork><![CDATA[ +===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
]]></artwork>
</figure>
</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, Stig Venaas, Jouni Korhonen and Liu Hui
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:03 |