One document matched: draft-schmidt-multimob-pmipv6-base-source-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="info" docName="draft-schmidt-multimob-pmipv6-base-source-01"
ipr="trust200902">
<front>
<title abbrev="Multicast Senders in PMIPv6">Mobile Multicast Sender
Support in PMIPv6 Domains with Base Multicast Deployment</title>
<author fullname="Thomas C. Schmidt" initials="T C." 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="Muhamma Omer Farooq" initials="M." surname="Farooq">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>20099</code>
<country>Germany</country>
</postal>
<email>omer.farooq@ymail.com</email>
</address>
</author>
<date />
<workgroup>MULTIMOB Group</workgroup>
<abstract>
<t>Multicast communication can be enabled in Proxy Mobile IPv6 domains
by deploying MLD Proxy functions at Mobile Access Gateways, and
multicast routing functions at Local Mobility Anchors. This document
describes the support of mobile multicast senders in Proxy Mobile IPv6
domains that is provided by this base deployment scenario. Mobile
sources 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 (MIPv6) <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 called the Local Mobility Anchor (LMA), and
Mobile Access Gateways (MAGs), are responsible for managing IP mobility
on behalf of the mobile node (MN). An MN connected to a PMIPv6 domain,
which only operates according to the base specifications of <xref
target="RFC5213"></xref>, cannot participate in multicast communication,
as MAGs will discard group packets.</t>
<t>Multicast support for mobile listeners can be enabled within a PMIPv6
domain by deploying MLD Proxy functions at Mobile Access Gateways, and
multicast routing functions at Local Mobility Anchors <xref
target="RFC6224"></xref>. This base deployment option is the simplest
way to PMIPv6 multicast extensions in the sense that it neither requires
new protocol operations nor additional infrastructure entities. Standard
software functions need to be activated on PMIPv6 entities, only, on the
price of possibly non-optimal multicast routing.</t>
<t>This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains as it is provided by the base deployment
scenario <xref target="RFC6224"></xref>. Mobile Nodes in this setting
remain agnostic of multicast mobility operations. This document
discusses implications on multicast routing, but does not address
specific optimizations and efficiency improvements of multicast routing
for network-based mobility as discussed in <xref
target="RFC5757"></xref>.</t>
</section>
<section title="Terminology">
<t>This document uses the terminology as defined for the mobility
protocols <xref target="RFC3775"></xref>, <xref target="RFC5213">
</xref> and <xref target="RFC5844"></xref>, as well as the multicast
edge related protocols <xref target="RFC3376"></xref>, <xref
target="RFC3810"></xref> and <xref target="RFC4605"></xref>.</t>
</section>
<section title="Overview">
<t>The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in <xref target="fig1"></xref>.</t>
<figure anchor="fig1"
title="Reference Network for Multicast Deployment in PMIPv6 with Source Mobility">
<artwork><![CDATA[ +-------------+
| Multicast |
| Listeners |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* 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
Multicast Sender + Listener(s)
]]></artwork>
</figure>
<t>An MN in a PMIPv6 domain will decide on multicast data transmission
completely independent of its current mobility conditions. It will send
packets as initiated by applications, using its source address with Home
Network Prefix (HNP) and a multicast destination addresses chosen by
application needs. Multicast packets will arrive at the currently active
MAG via one of its downstream local (wireless) links. A multicast
unaware MAG would simply discard these packets in the absence of a
multicast forwarding information base (MFIB).</t>
<t>An MN can successfully distribute multicast data in PMIPv6, if MLD
proxy functions are deployed at the MAG as described in <xref
target="RFC6224"></xref>. In this set-up, the MLD proxy instance serving
a mobile multicast source has configured its upstream interface at the
tunnel towards MN's corresponding LMA. For each LMA, there will be a
separate instance of an MLD proxy.</t>
<t>According to the specifications given in <xref
target="RFC4605"></xref>, multicast data arriving from a downstream
interface of an MLD proxy will be forwarded to the upstream interface
and to all but the incoming downstream interfaces with appropriate
forwarding states for this group. Thus multicast streams originating
from an MN will arrive at the corresponding LMA and directly at all
mobile receivers co-located at the same MAG. Serving as the designated
multicast router or an additional MLD proxy, the LMA forwards data to
the fixed Internet, if forwarding states are maintained through
multicast routing. If the LMA is acting as another MLD proxy, it will
forward the multicast data to its upstream interface, and based upon the
downstream interfaces' subscriptions accordingly.</t>
<t>In case of a handover, the MN (unaware of IP mobility) can continue
to send multicast packets as soon as network connectivity is
reconfigured. At this time, the MAG has determined the corresponding
LMA, and IPv6 unicast address configuration with PMIPv6 bindings have
been performed. Multicast packets arriving at the MAG are discarded
until the MAG has completed the following steps.</t>
<t><list style="numbers">
<t>The MAG SHOULD determine whether the MN is admissible to
multicast services, and stop here otherwise.</t>
<t>The MAG adds the new downstream link to the MLD proxy instance
with up-link to the corresponding LMA.</t>
</list>As soon as the MN's uplink is associated with the corresponding
MLD proxy instance, multicast packets are forwarded again to the LMA and
eventually to receivers within the PMIP domain (see the call flow in
<xref target="fig-callflow"></xref>). In this way, multicast source
mobility is transparently enabled in PMIPv6 domains that deploy the base
scenario for multicast.</t>
<figure anchor="fig-callflow"
title="Call Flow for Group Communication in Multicast-enabled PMIP">
<artwork><![CDATA[MN1 MAG1 MN2 MAG2 LMA
| | | | |
| | Mcast Data | | |
| |<---------------+ | |
| | Mcast Data | | |
| Join(G) +================================================>|
+--------------> | | | |
| Mcast Data | | | |
|<---------------+ | | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | < MLD Proxy Configuration > |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | 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 their IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide IPv4 home address mobility support <xref
target="RFC5844"></xref>. IPv4 multicast is handled by an IGMP proxy
function at the MAG in an analogous way.</t>
<t>Following these deployment steps, multicast traffic distribution
transparently inter-operates with PMIPv6. It is worth noting that a MN -
while being attached to the same MAG as the mobile source, but
associated with a different LMA, cannot receive multicast traffic on a
shortest path. Instead, multicast streams flow up to the LMA of the
mobile source, are transferred to the LMA of the mobile listener and
tunneled downwards to the MAG again (see <xref target="A-Eval"></xref>
for further considerations).</t>
</section>
<section title="Source Mobility Details">
<t>Incorporating multicast source mobility in PMIPv6 requires to deploy
general multicast functions at PMIPv6 routers and to define their
interaction with the PMIPv6 protocol in the following way.</t>
<section title="Operations of the Mobile Node">
<t>A Mobile Node willing to send multicast data will proceed as if
attached to the fixed Internet. No specific mobility or other
multicast related functionalities are required at the MN.</t>
</section>
<section title="Operations of the Mobile Access Gateway">
<t>A Mobile Access Gateway is required to have MLD proxy instances
deployed corresponding to each LMA, taking the corresponding tunnel as
its unique upstream link, cf., <xref target="RFC6224"></xref>. On the
arrival of a MN, the MAG decides on the mapping of downstream links to
a proxy instance and the upstream link to the LMA based on the regular
Binding Update List as maintained by PMIPv6 standard operations. When
multicast data is received from the MN, the MAG MUST identify the
corresponding proxy instance from the incoming interface and forwards
multicast data upstream according to <xref
target="RFC4605"></xref>.</t>
<t>The MAG MAY apply special admission control to enable multicast
data transition from a MN. It is advisable to take special care that
MLD proxy implementations do not redistribute multicast data to
downstream interfaces without appropriate subscriptions in place.</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 upstream for the
corresponding MAG. It will manage and maintain a multicast forwarding
information base for all group traffic arriving from its mobile
sources. It SHOULD participate in multicast routing functions that
enable traffic redistribution to all adjacent LMAs within the PMIPv6
domain and thereby ensure a continuous receptivity while the source is
in motion.</t>
<section title="Local Mobility Anchors Operating PIM">
<t>Local Mobility Anchors that operate the PIM routing protocol
<xref target="RFC4601"></xref> will require sources to be directly
connected for sending PIM registers to the RP. This does not hold in
a PMIPv6 domain, as MAGs are routers intermediate to MN and the LMA.
In this sense, MNs are multicast sources external to the PIM-SM
domain.</t>
<t>To cure this defect common to all set-ups of subsidiary domains
not running PIM, the LMA should act as a PIM Border Router and
activate the Border-bit. In this case, the DirectlyConnected(S) is
treated as being TRUE for mobile sources and the PIM-SM forwarding
rule "iif == RPF_interface(S)" is relaxed to be TRUE, as the
incoming tunnel interface from MAG to LMA is considered as not part
of the PIM-SM component of the LMA (see A.1 of <xref
target="RFC4601"></xref> ). </t>
</section>
</section>
<section title="IPv4 Support">
<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 multicast support on the network side, an IGMP proxy
function needs to be deployed at MAGs in exactly the same way as for
IPv6. <xref target="RFC4605"></xref> defines IGMP proxy behaviour in
full agreement with IPv6/MLD. Thus IPv4 support can be transparently
provided following the obvious deployment analogy.</t>
<t>For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
SHOULD choose multicast signaling according to address configurations
on the link, but MAY submit IGMP and MLD queries in parallel, if
needed. It should further be noted that the infrastructure cannot
identify two data streams as identical when distributed via an IPv4
and IPv6 multicast group. Thus duplicate data may be forwarded on a
heterogeneous network layer.</t>
<t>A particular note is worth giving the scenario of <xref
target="RFC5845"></xref> in which overlapping private address spaces
of different operators can be hosted in a PMIP domain by using GRE
encapsulation with key identification. This scenario implies that
unicast communication in the MAG-LMA tunnel can be individually
identified per MN by the GRE keys. This scenario still does not impose
any special treatment of multicast communication for the following
reasons.</t>
<t>Multicast streams from and to MNs arrive at a MAG on point-to-point
links (identical to unicast). between the routers and independent of
any individual MN. So the MAG-proxy and the LMA SHOULD NOT use GRE key
identifiers, but plain GRE encapsulation in multicast communication
(including MLD queries and reports). Multicast traffic sent upstream
and downstream of MAG-to-LMA tunnels proceeds as router-to-router
forwarding according to the multicast forwarding information base
(MFIB) of the MAG or LMA and independent of MN's unicast addresses,
while the MAG proxy instance re-distributes multicast data down the
point-to-point links (interfaces) according to its own MFIB,
independent of MN's IP addresses.</t>
</section>
<section title="Efficiency of the Distribution System">
<t>In the following efficiency-related issues are enumerated.</t>
<t><list style="hanging">
<t hangText="Multicast reception at LMA">In the current deployment
scenario, the LMA will receive all multicast traffic originating
from its associated MNs. There is no mechanism to suppress
upstream forwarding in the absence of receivers.</t>
<t hangText="MNs on the same MAG using different LMAs">For a
mobile receiver and a source that use different LMAs, the traffic
has to go up to one LMA, cross over to the other LMA, and then be
tunneled back to the same MAG, causing redundant flows in the
access network and at the MAG.</t>
</list></t>
</section>
<section title="Multicast Availability throughout the Access Network">
<t>There may be deployment scenarios, where multicast services are
available throughout the access network independent of the PMIPv6
infrastructure. Direct multicast access at MAGs may be supported
through native multicast routing within a flat access network that
includes a multicast router, via dedicated (tunnel or VPN) links
between MAGs and designated multicast routers.</t>
<t>Multicast traffic distribution can be simplified in these
scenarios. A single proxy instance at MAGs with up-link into the
multicast cloud will serve as a first hop gateway into the multicast
routing domain and avoid traffic duplication or detour routing.
However, mobility of the multicast source in this scenario will
require some multicast routing protocols to rebuild distribution
trees. This can cause significant service disruptions or delays (see
<xref target="RFC5757"></xref> for further details).</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 not introduce additional messages or novel protocol
operations. Consequently, no new threats are introduced by this document
in addition to those identified as security concerns of <xref
target="RFC3810"></xref>, <xref target="RFC4605"></xref>, <xref
target="RFC5213"></xref>, and <xref target="RFC5844"></xref>.</t>
<t>However, particular attention should be paid to implications of
combining multicast and mobility management at network entities. As this
specification allows mobile nodes to initiate the creation of multicast
forwarding states at MAGs and LMAs while changing attachments, threats
of resource exhaustion at PMIP routers and access networks arrive from
rapid state changes, as well as from high volume data streams routed
into access networks of limited capacities. In addition to proper
authorization checks of MNs, rate controls at replicators MAY be
required to protect the agents and the downstream networks. In
particular, MLD proxy implementations at MAGs SHOULD carefully procure
for automatic multicast state extinction on the departure of MNs, as
mobile multicast listeners in the PMIPv6 domain will not actively
terminate group membership prior to departure.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank (in alphabetical order) Jouni
Korhonen and Stig Venaas for advice, help and reviews of the document.
Funding by the German Federal Ministry of Education and Research within
the G-LAB Initiative is gratefully acknowledged.</t>
<t></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.4601"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.2710"?>
<?rfc include="reference.RFC.5844"?>
<?rfc include="reference.RFC.3376"?>
<?rfc include="reference.RFC.6224"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5757"?>
<?rfc include="reference.RFC.5845"?>
<?rfc include="reference.RFC.2236"?>
</references>
<section anchor="A-Eval" title="Evaluation of Traffic Flows">
<t>TODO</t>
</section>
<section title="Change Log ">
<t>The following changes have been made from version
draft-schmidt-multimob-pmipv6-base-source-00: <list style="numbers">
<t>Added specifics of PIM directly connected neighbor requirements for sources </t>
<t>Updated references</t>
<t>Editorial improvements</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:14 |