One document matched: draft-ietf-multimob-pmipv6-base-solution-04.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-ietf-multimob-pmipv6-base-solution-04"
ipr="trust200902">
<front>
<title abbrev="Multicast Listeners in PMIPv6">Base Deployment for
Multicast Listener Support in PMIPv6 Domains</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="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="12" month="July" year="2010" />
<workgroup>MULTIMOB Group</workgroup>
<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, Local Mobility Anchors of Proxy Mobile IPv6 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. A support for mobile
multicast senders is outside the scope of this document.</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).</t>
<t>With these entities in place, the mobile node experiences an
exceptional access topology towards the static Internet in the sense
that the MAG introduces a routing hop also in situations, were the LMA
architecturally acts as the next hop (or designated) router for the MN.
In the particular case of multicast communication, group membership
management as signaled by the Multicast Listener Discovery protocol
(MLD) <xref target="RFC3810"></xref>, <xref target="RFC2710"></xref>
requires dedicated treatment at the network side .</t>
<t>Multicast routing functions need to be placed carefully within the
PMIPv6 domain to augment unicast transmission with group communication
services. <xref target="RFC5213"></xref> does not explicitly address
multicast communication. Bi-directional home tunneling, the minimal
multicast support arranged by MIPv6, cannot be directly transferred to
network-based management scenarios, since a mobility-unaware node will
not initiate such a tunnel after movement. Consequently, even a minimal
multicast listener support in PMIPv6 domains requires an explicit
deployment of additional functions.</t>
<t>This document describes options for deploying 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.
This document does not address specific optimizations and efficiency
improvements of multicast routing for network-based mobility discussed
in <xref target="RFC5757"></xref>, as such solutions would require
changes to the base PMIPv6 protocol <xref target="RFC5213"></xref>. A
support for mobile multicast senders is outside the scope of this
document, as well.</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">
<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>
<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, based on application triggers,
using its link-local source address and multicast destination addresses
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 MAG-to-LMA tunnel interface defines an MLD proxy domain at
the MAG, and it contains all downstream links to MNs that share this
specific LMA. According to standard proxy operations, MLD Report
messages will be 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 create
appropriate multicast forwarding states at its tunnel interface. Traffic
arriving for subscribed groups will arrive at the LMA, and the LMA will
forward this traffic according to its group/source states. In addition,
the LMA will 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. Hence 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 handover, the MN (unaware of IP mobility) will not send
unsolicited MLD reports. Instead, the MAG is required to maintain group
memberships in the following way. On observing a new MN on a downstream
access link, 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 aggregating group
membership states according to the proxy function. Additional Reports
can be omitted when the previously established multicast forwarding
states at the new MAG already cover the subscriptions of the MN.</t>
<t>In summary, the following steps are executed on handover:</t>
<t><list style="numbers">
<t>The MAG-MN link comes up and the MAG discovers the new MN.</t>
<t>Unicast address configuration and PMIPv6 binding are performed
after the MAG determines the corresponding LMA.</t>
<t>Following IPv6 address configuration, the MAG SHOULD send an
(early) MLD General Query to the new downstream link as part of its
standard multicast-enabled router operations.</t>
<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>
<t>The corresponding Proxy instance triggers an MLD General Query on
the new downstream link.</t>
<t>The MN Membership Reports arrive at the MAG, either in response
to the early Query or to that of the Proxy instance.</t>
<t>The Proxy processes the MLD Report, updates states and reports
upstream if necessary.</t>
</list></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 with "MLD Membership Report" abbreviated by "Join"">
<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 > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | 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 their IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide IPv4 home address mobility support <xref
target="RFC5844"></xref>. Such mobile nodes will use IGMP <xref
target="RFC2236"></xref>,<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
inter-operates with PMIPv6. It is worth noting that MNs - while being
attached to the same MAG, but associated with different LMAs - can
subscribe to the same multicast group. Thereby data could be distributed
redundantly in the network and duplicate traffic could arrive at a MAG.
Additionally in a point-to-point wireless link model, a MAG might be
forced to transmit the same data over one wireless domain to different
MNs. However, multicast traffic to one MN will always remain unique,
i.e., the mobile multicast distribution system will never cause
duplicate packets arriving at an MN (see <xref target="A-Eval"></xref>
for further considerations).</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 their 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 Mobile 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>). As links connecting MNs and
MAGs change under mobility, MLD proxies at MAGs MUST be able to
dynamically add and remove downstream interfaces in its
configuration.</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
multicast forwarding state on the incoming interface, and will merge
state updates into the MLD proxy membership database. It will then
send an aggregated Report to the upstream tunnel to the LMA 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. At this stage, it
is important to note that IGMP/MLD proxy implementations capable of
multiple instances are expected to closely follow the specifications
of section 4.2 in <xref target="RFC4605"></xref>, i.e., treat proxy
instances in isolation of each other while forwarding. In providing
isolated proxy instances, the MAG will uniquely serve its downstream
links with exactly the data that belong to whatever group is
subscribed on the particular interface.</t>
<t>After a handover, the MAG will continue to manage upstream tunnels
and downstream interfaces as specified in the PMIPv6 specification. It
MUST dynamically associate new access links to proxy instances that
include the upstream connection to the corresponding LMA. The MAG
detects the arrival of a new MN by receiving a router solicitation
message and by an upcoming link. To learn about multicast groups
subscribed by a newly attaching MN, the MAG SHOULD send a General
Query to the MN's link. Querying an upcoming interface is a standard
operation of MLD queriers (see <xref target="A-InitMLD"></xref>) and
is performed immediately after address configuration. In addition, an
MLD query SHOULD be initiated by the proxy instance, as soon as a new
interface has been configured for downstream. 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 and this will trigger corresponding Reports towards the LMA.
Note that the actual observable state depends on the access link model
in use.</t>
<t>An MN may be unable to answer MAG multicast membership queries due
to handover procedures, or its report may arrive before the MAG has
configured its link as proxy downstream interface. Such occurrences
are 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 time scale of handover operations and
proxy configurations in the PMIPv6 domain.</t>
<t>In proceeding this way, the MAG is able 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
multipoint channel forwarding into the wireless domain is prevented by
the point-to-point 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 treats 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
information base.</t>
<t>After a handover, the LMA will receive Binding De-Registrations and
Binding Lifetime Extensions that will cause a re-mapping of home
network prefix(es) to a new Proxy-CoA in its Binding Cache (see
section 5.3 of <xref target="RFC5213"></xref>). The multicast
forwarding states require updating, as well, if the MN within an MLD
proxy domain is the only receiver of a multicast group. Two different
cases need to be considered:</t>
<t><list style="numbers">
<t>The mobile node is the only receiver of a group behind the
interface at which 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 at which 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="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>MLD/IGMP signaling between MNs and the MAG is on point-to-point
links (identical to unicast). Aggregated MLD/IGMP signaling between
the MAG proxy instance and the LMA remains link-local 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 to
exchange MLD queries and reports. Similarly, multicast traffic sent
from an LMA to MAGs proceeds as router-to-router forwarding according
to the MFIB of the LMA and independent of MN's unicast addresses,
while the MAG proxy instance distributes multicast data down the
point-to-point links (interfaces) according to its MFIB, independent
of MN's IP addresses.</t>
<t>It remains an open issue how communication proceeds in a
multi-operator scenario, i.e., from which network the LMA pulls
multicast traffic from. This could be any mobility Operator itself, or
a third party. However, this backbone routing in general is out of
scope of the document, and most likely a matter of contracts.</t>
</section>
<section title="Multihoming Support">
<t>An MN can connect to a PMIPv6 domain through multiple interfaces
and experience transparent unicast handovers at all interfaces (cf.,
section 5.4 of <xref target="RFC5213"></xref>). In such simultaneous
access scenario, it can autonomously assign multicast channel
subscriptions to individual interfaces (see <xref
target="RFC5757"></xref> for additional details). While doing so,
multicast mobility operations described in this document will
transparently preserve the association of channels to interfaces in
the following way.</t>
<t>Multicast listener states are kept per interface in the MLD state
table. An MN will answer to an MLD General Query received on a
specific (re-attaching) interface according to the specific
interface's state table. Thereafter, multicast forwarding is resumed
for channels identical to those under subscription prior to handover.
Consequently, an MN in a PMIPv6 domain MAY use multiple interfaces to
facilitate load balancing or redundancy, but cannot follow a
'make-before-break' approach to service continuation on handovers.</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, or by deploying AMT
<xref target="I-D.ietf-mboned-auto-multicast"></xref>.</t>
<t>Multicast deployment can be simplified in these scenarios. A single
proxy instance at MAGs with up-link into the multicast cloud, for
instance, could serve group communication purposes. MAGs could operate
as general multicast routers or AMT gateways, as well.</t>
<t>Common to these solutions is that mobility management is covered by
the dynamics of multicast routing, as initially foreseen in the Remote
Subscription approach sketched in <xref target="RFC3775"></xref>. Care
must be taken to avoid avalanche problems or service disruptions due
to tardy multicast routing operations, and to adapt to different
link-layer technologies <xref target="RFC5757"></xref>. The different
possible approaches should be carefully investigated beyond the
initial sketch in <xref target="A-Eval"></xref>. Such work is beyond
the scope of this document.</t>
</section>
<section title="A Note on Explicit Tracking">
<t>An IGMPv3/MLDv2 Querier may operate in combination with explicit
tracking as described in Appendix 2 of <xref target="RFC3376"></xref>,
or Appendix 2 of<xref target="RFC3810"> </xref>. This mechanism allows
routers to monitor each multicast receiver individually. Even though
this procedure is not standardized yet, it is 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 addresses of MLD
messages and encapsulating outer headers when deployed in the PMIPv6
domain. This overview is for clarification purposes, only, and does not
define a behavior different from referenced standards in any way.</t>
<t>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 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>This memo follows initial requirements work presented in
draft-deng-multimob-pmip6-requirement, and is the outcome of extensive
previous discussions and a follow-up of several initial drafts on the
subject. The authors would like to thank (in alphabetical order) Jari
Arkko, Luis Contreras, Greg Daley, Gorry Fairhurst, Dirk von Hugo, Seil
Jeon, Jouni Korhonen, Guang Lu, Sebastian Meiling, Liu Hui, Akbar
Rahman, Imed Romdhani, Behcet Sarikaya, Pierrick Seite, Stig Venaas, and
Juan Carlos Zuniga 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.4605"?>
<?rfc include="reference.RFC.2710"?>
<?rfc include="reference.RFC.5844"?>
<?rfc include="reference.RFC.3376"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5757"?>
<?rfc include="reference.RFC.5845"?>
<?rfc include="reference.I-D.ietf-mboned-auto-multicast"?>
<?rfc include="reference.I-D.zuniga-multimob-smspmip"?>
<?rfc include="reference.RFC.2236"?>
</references>
<section anchor="A-InitMLD" title="Initial MLD Queries on Upcoming Links">
<t>According to <xref target="RFC3810"></xref> and <xref
target="RFC2710"></xref> when an IGMP/MLD-enabled multicast router
starts operating on a subnet, by default it considers itself as Querier
and sends several General Queries. Such initial query should be sent by
the router immediately, but could be delayed by a (tunable) Startup
Query Interval (see Sections 7.6.2. and 9.6. of <xref
target="RFC3810"></xref>).</t>
<t>Experimental tests on Linux and Cisco systems have revealed immediate
IGMP Queries following a link trigger event (within a fraction of 1 ms),
while MLD Queries immediately followed the autoconfiguration of IPv6
link-local addresses at the corresponding interface.</t>
</section>
<section title="State of IGMP/MLD Proxy Implementations">
<t>The deployment scenario defined in this document requires certain
proxy functionalities at the MAGs that implementations of <xref
target="RFC4605"></xref> need to contribute. In particular, a
simultaneous support of IGMP and MLD is needed, as well as a
configurable list of downstream interfaces that may be altered during
runtime, and the deployment of multiple proxy instances at a single
router that can operate independently on separated interfaces.</t>
<t>A brief experimental trial undertaken in February 2010 revealed the
following divergent status of selected IGMP/MLD proxy
implementations.</t>
<t><list style="hanging">
<t hangText="Cisco Edge Router">Software-based commodity edge
routers (test device from the 26xx-Series) implement IGMPv2/v3 proxy
functions only in combination with PIM-SM. There is no support of
MLD Proxy. Interfaces are dynamically configurable at runtime via
the CLI, but multiple proxy instances are not supported.</t>
<t hangText="Linux igmpproxy">IGMPv2 Proxy implementation that
permits a static configuration of downstream interfaces (simple bug
fix required). Multiple instances are prevented by a lock
(corresponding code re-used from a previous DVMRP implementation).
IPv6/MLD is unsupported. Project page:
http://sourceforge.net/projects/igmpproxy/.</t>
<t hangText="Linux gproxy">IGMPv3 Proxy implementation that permits
configuration of the upstream interface, only. Downstream interfaces
are collected at startup without dynamic extension of this list. No
support of multiple instances or MLD. Project page:
http://potiron.loria.fr/projects/madynes/internals/perso/lahmadi/igmpv3proxy/.</t>
<t hangText="Linux ecmh">MLDv1/2 Proxy implementation without IGMP
support that inspects IPv4 tunnels and detects encapsulated MLD
messages. Allows for dynamic addition of interfaces at runtime and
multiple instances. However, downstream interfaces cannot be
configured. Project page: http://sourceforge.net/projects/ecmh/</t>
</list></t>
</section>
<section anchor="A-Eval"
title="Comparative Evaluation of Different Approaches">
<t>In this section, we briefly evaluate two basic PMIP concepts for
multicast traffic organization at LMAs: In scenario A, multicast is
provided by combined unicast/multicast LMAs as described in this
document. Scenario B directs traffic via a dedicated multicast LMA as
proposed in <xref target="I-D.zuniga-multimob-smspmip"></xref>, for
example.</t>
<t>Both approaches do not establish native multicast distribution
between the LMA and MAG, but use tunneling mechanisms. In scenario A, a
MAG is connected to different multicast-enabled LMAs, and can receive
the same multicast stream via multiple paths depending on the group
subscriptions of MNs and their associated LMAs. This problem, a.k.a.
tunnel convergence problem, may lead to redundant traffic at the MAGs.
Scenario B in contrast configures MAGs to establish a tunnel to a
single, dedicated multicast LMA for all attached MNs and relocates
overhead costs to the multicast anchor. This eliminates redundant
traffic, but may result in an avalanche problem at the LMA.</t>
<t>We quantify the costs of both approaches based on two metrics: The
amount of redundant traffic at MAGs and the number of simultaneous
streams at LMAs. Realistic values depend on the topology and the group
subscription model. To explore scalability in a large PMIP domain of
1,000,000 MNs, we consider the following two extremal multicast
settings.</t>
<t><list style="numbers">
<t>All MNs participate in distinct multicast groups.</t>
<t>All MNs join the same multicast groups.</t>
</list>A typical PMIP deployment approximately allows for 5,000 MNs
attached to one MAG, while 50 MAGs can be served by one LMA. Hence
1,000,000 MNs require approx. 200 MAGs backed by 4 LMAs for unicast
transmission. In scenario A, these LMAs also forward multicast streams,
while in scenario B one additional dedicated LMA (LMA-M) serves
multicast. In the following, we calculate the metrics described above.
In addition, we display the number of packet streams that cross the
interconnecting (wired) network within a PMIPv6 domain.</t>
<figure title="1,000,000 MNs are subscribed to distinct multicast groups">
<preamble>Setting 1:</preamble>
<artwork><![CDATA[ +===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<figure title="1,000,000 MNs are subscribed to the same multicast group">
<preamble>Setting 2:</preamble>
<artwork><![CDATA[ +===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+]]></artwork>
<postamble></postamble>
</figure>
<t>These considerations of extremal settings show that tunnel
convergence, i.e., duplicate data arriving at a MAG, does cause much
smaller problems in scalability than the stream replication at LMAs
(avalanche problem). For scenario A it should be also noted that the
high stream replication requirements at LMAs in setting 1 can be
attenuated by deploying additional LMAs in a PMIP domain, while scenario
B does not allow for distributing the LMA-M, as no handover management
is available at LMA-M.</t>
</section>
<section title="Change Log ">
<t>The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-03.<list style="numbers">
<t>Clarifications and editorial improvements in response to WG
feedback.</t>
<t>Added pointers and explanations to Explicit Tracking and GRE
tunneling in the IPv4 scenario (RFC 5845).</t>
</list></t>
<t>The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-02.<list style="numbers">
<t>Clarifications and editorial improvements in response to WG
feedback.</t>
</list></t>
<t>The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-01.<list style="numbers">
<t>Editorial improvements in response to WG feedback.</t>
</list></t>
<t>The following changes have been made from version
draft-ietf-multimob-pmipv6-base-solution-00.</t>
<t><list style="numbers">
<t>Added section on multihoming.</t>
<t>Updated security section.</t>
<t>Several editorial improvements and minor extensions.</t>
</list></t>
<t>The following changes have been made from the previous individual
version draft-schmidt-multimob-pmipv6-mcast-deployment-04.</t>
<t><list style="numbers">
<t>Updated references.</t>
<t>Corrected typos.</t>
<t>Adjusted title & document name.</t>
</list>The following changes have been made from
draft-schmidt-multimob-pmipv6-mcast-deployment-03. <list style="numbers">
<t>Detailed outline of multicast reconfiguration steps on handovers
added in protocol overview (section 3).</t>
<t>Clarified the details of proxy operations at the MAG along with
the expected features of IGMP/MLD Proxy implementations (section
4.2).</t>
<t>Clarified querying in dual-stack scenarios (section 4.4).</t>
<t>Subsection added on the special case, where multicast is
available throughout the access network (section 4.5).</t>
<t>Appendix on IGMP/MLD behaviour added with test reports on current
Proxy implementations.</t>
</list></t>
<t>The following changes have been made from
draft-schmidt-multimob-pmipv6-mcast-deployment-02. <list style="numbers">
<t>Many editorial improvements, in particular as response to draft
reviews.</t>
<t>Section on IPv4 support added.</t>
<t>Added clarifications on initial IGMP/MLD Queries and
supplementary information in appendix.</t>
<t>Appendix added an comparative performance evaluation regarding
mixed/dedicated deployment of multicast at LMAs.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:26:03 |