One document matched: draft-ietf-multimob-pmipv6-source-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="std" docName="draft-ietf-multimob-pmipv6-source-00"
ipr="trust200902">
<front>
<title abbrev="Multicast Senders in PMIPv6">Mobile Multicast Sender
Support in Proxy Mobile IPv6 (PMIPv6) Domains</title>
<author fullname="Thomas C. Schmidt" initials="T C."
surname="Schmidt, Ed.">
<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="Shuai Gao" initials="S." surname="Gao">
<organization>Beijing Jiaotong University</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>shgao@bjtu.edu.cn</email>
<uri></uri>
</address>
</author>
<author fullname="Hong-Ke Zhang" initials="H." surname="Zhang">
<organization>Beijing Jiaotong University</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>hkzhang@bjtu.edu.cn</email>
<uri></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>
<date />
<workgroup>MULTIMOB Group</workgroup>
<abstract>
<t>Multicast communication can be enabled in Proxy Mobile IPv6 domains
via the Local Mobility Anchors by deploying MLD Proxy functions at
Mobile Access Gateways, via a direct traffic distribution within an
ISP's access network, or by selective route optimization schemes. This
document describes the support of mobile multicast senders in Proxy
Mobile IPv6 domains for all three scenarios. Mobile sources always
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="RFC6275"></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 follows the
common PMIPv6 traffic model and neither requires new protocol operations
nor additional infrastructure entities. Standard software functions need
to be activated on PMIPv6 entities, only, at the price of possibly
non-optimal multicast routing.</t>
<t>Alternate solutions leverage performance optimization by providing
multicast routing at the access gateways directly, or by selective route
optimization schemes. Such approaches (partially) follow the business
model of providing multicast data services in parallel to PMIPv6 unicast
routing.</t>
<t>Multicast listener support satisfies the needs of receptive use cases
such as IPTV or sever-centric gaming on mobiles. However, current trends
in the Internet enfold towards user-centric, highly interactive group
applications like user generated streaming, conferencing, collective
mobile sensing, etc. Many of these popular applications create group
content at end systems and can largely profit from a direct data
transmission to a multicast-enabled network.</t>
<t>This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains subsequently for the base deployment scenario
<xref target="RFC6224"></xref>, for direct traffic distribution within
an ISP's access network, as well as for selective route optimization
schemes. The contribution of this work reflects the source mobility
problem as discussed in <xref target="RFC5757"></xref>. Mobile Nodes in
this setting remain agnostic of multicast mobility operations.</t>
</section>
<section title="Terminology">
<t>This document uses the terminology as defined for the mobility
protocols <xref target="RFC6275"></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 anchor="Base"
title="Base Solution for Source Mobility and PMIPv6 Routing">
<section title="Overview">
<t>The reference scenario for multicast deployment in Proxy Mobile
IPv6 domains is illustrated in <xref target="fig1"></xref>. MAGs play
the role of first-hop access routers that serve multiple MNs on the
downstream while running an MLD/IGMP proxy instance for every LMA
upstream tunnel.</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 address
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 routing information base (MRIB).</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 that have
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 and MLD
Proxy instance. Serving as the designated multicast router or an
additional MLD proxy, the LMA forwards data to the fixed Internet,
whenever forwarding states are maintained by multicast routing. If the
LMA is acting as another MLD proxy, it will forward the multicast data
to its upstream interface, and to downstream interfaces with matching
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 (including PMIPv6
bindings) has been performed . Still multicast packets arriving at the
MAG are discarded (if not buffered) until the MAG has completed the
following steps.</t>
<t><list style="numbers">
<t>The MAG has determined that the MN is admissible to multicast
services.</t>
<t>The MAG has added 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 an
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="Base Solution for 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, one for each tunnel to an LMA, which serves as its unique
upstream link (cf., <xref target="RFC6224"></xref>). On the arrival
of an 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 an 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 anchor="PIM-Source"
title="Local Mobility Anchors Operating PIM">
<t>Local Mobility Anchors that operate the PIM-SM 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 mitigate this incompatibility common to all subsidiary MLD
proxy domains, 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>
<t>Notably, running BIDIR PIM <xref target="RFC5015"></xref> on
LMAs remains robust with respect to source location and does not
require a special configuration.</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, an LMA can register an IPv4-Proxy-CoA in its
Binding Cache and the MAG can provide IPv4 support in its access
network. 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). Multicast data
transmission from the MAG to the corresponding LMA is link-local
between the routers and routing/forwarding remains 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 routing
information base (MRIB) 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 MRIB, 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>
</section>
<section anchor="Direct-Routing" title="Direct Multicast Routing">
<t>There are deployment scenarios, where multicast services are
available throughout the access network independent of the PMIPv6
routing system <xref target="I-D.zuniga-multimob-pmipv6-ropt"></xref>.
In these cases, the visited networks grant a local content distribution
service (in contrast to LMA-based home subscription) with locally
optimized traffic flows. It is also possible to deploy a mixed service
model of local and LMA-based subscriptions, provided a unique way of
service selection is implemented. For example, access routers (MAGs)
could decide on service access based on the multicast address G or the
SSM channel (S,G) under request (see <xref target="Extensions"></xref>
for a further discussion).</t>
<section title="Overview">
<t>Direct multicast access can be supported by <list style="symbols">
<t>native multicast routing provided by one multicast router that
is neighboring MLD proxies deployed at MAGs within a flat access
network, or via tunnel uplinks,</t>
<t>a multicast routing protocol such as PIM-SM <xref
target="RFC4601"></xref> or BIDIR-PIM <xref
target="RFC5015"></xref> deployed at the MAGs.</t>
</list></t>
<figure anchor="fig2"
title="Reference Networks for (a) Proxy-assisted Direct Multicast Access and (b) Dynamic Multicast Routing at MAGs">
<artwork><![CDATA[
*** *** *** ***
* ** ** ** *
* *
* Multicast *
+----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+
| // \\ |
\\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *//
|| || || || * || Routing || *
+----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***|
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
]]></artwork>
</figure>
<t><xref target="fig2"></xref> displays the corresponding deployment
scenarios, which separate multicast from PMIPv6 unicast routing. It is
assumed throughout these scenarios that all MAGs (MLD proxies) are
linked to a single multicast routing domain.</t>
<t>Multicast traffic distribution can be simplified in these
scenarios. A single proxy instance at MAGs with up-link into the
multicast domain will serve as a first hop multicast gateway and avoid
traffic duplication or detour routing. Multicast routing functions at
MAGs will seamlessly embed access gateways within a multicast cloud.
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 aspects). Deployment
details are specific to the multicast routing protocol in use, in the
following described for common protocols.</t>
</section>
<section title="MLD Proxies at MAGs">
<t>In a PMIPv6 domain, single MLD proxy instances can be deployed at
each MAG to enable multicast service at the access (see <xref
target="fig2"></xref> (a) ). To avoid service disruptions on
handovers, the uplinks of all proxies SHOULD be adjacent to the same
next-hop multicast router. This can either be achieved by arranging
proxies within a flat access network, or by upstream tunnels that
terminate at a common multicast router.</t>
<t>Multicast data submitted by a mobile source will reach the MLD
proxy at the MAG that subsequently forwards flows to the upstream and
all downstream interfaces with appropriate subscriptions. Traversing
the upstream will lead traffic into the multicast infrastructure
(e.g., to a PIM Designated Router) which will route packets to all
local MAGs that have joined the group, as well as further upstream
according to protocol procedures and forwarding states.</t>
<t>On handover, a mobile source will reattach at a new MAG and can
continue to send multicast packets as soon as PMIPv6 unicast
configurations have completed. Like at the previous MAG, the new MLD
proxy will forward data upstream and downstream to subscribers.
Listeners local to the previous MAG will continue to receive group
traffic via the local multicast distribution infrastructure following
aggregated listener reports of the previous proxy. In general, the
mobile source remains unchanged when seen from the wider multicast
infrastructure.</t>
<section title="PIM-SM Considerations">
<t>A mobile source that transmits data via an MLD proxy will not be
directly connected to a PIM Designated Router as discussed in <xref
target="PIM-Source"></xref>. Countermeasures apply correspondingly.
</t>
<t>A PIM Designated Router that is connected to MLD proxies via
individual IP-tunnel interfaces will experience invalid PIM source
states on handover. This problem can be mitigated by aggregating
proxies on a lower layer.</t>
</section>
<section title="SSM Considerations">
<t>Source-specific subscriptions invalidate with routes, whenever
the source moves from or to the MAG/proxy of a subscriber. Multicast
forwarding states will rebuild with unicast route changes. However,
this may lead to noticeable service disruptions for locally
subscribed nodes.</t>
</section>
</section>
<section title="PIM-SM">
<t>TODO</t>
</section>
<section title="BIDIR PIM">
<t>TODO</t>
</section>
</section>
<section anchor="Extensions"
title="Extended Source Mobility Schemes in PMIPv6">
<t>In this section, specific optimization approaches to multicast source
mobility are introduced.</t>
<section title="Multiple Upstream Interface Proxy">
<t>Although multicast communication can be enabled in PMIPv6 domains
by deploying MLD Proxy functions at MAG, some disadvantages still
exist. Firstly, for a proxy device performing IGMP/MLD-based
forwarding has a single upstream interface and one or more downstream
interfaces as described in RFC4605, there should be many MLD Proxy
functions deployed at one MAG, which is complicated and then is
difficult for implementation and management. And then when the
multicast packets arrive at the MAG running multiple parallel MLD
proxy functions, there may be confusions for the data if there is no
extra processing or filtering scheme at the MAG. In addition, the
route optimization issue is still up in the air, that is, for a mobile
receiver and a source on the same MAG using 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. Therefore, the MLD Proxy function
should be extended to accommodate the PMIPv6 protocol. As same as
described in <xref target="RFC6224"></xref> and this document (s.
abobe), the MLD proxy functions are deployed at the MAG, while only
one MLD Proxy function is required to run at the MAG and multiple
upstream interfaces can be set for the MLD Proxy instance, which is
called Multi-Upstream Interfaces MLD Proxy (MUIMP).</t>
<t>.... TODO details.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TODO.</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>TODO</t>
<t>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) Muhamma Omer
Farooq, Aaron Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li,
Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for advice,
help and reviews of the document. Funding by the German Federal Ministry
of Education and Research within the G-LAB Initiative (project HAMcast)
is gratefully acknowledged.</t>
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6275"?>
<?rfc include="reference.RFC.5213"?>
<?rfc include="reference.RFC.3810"?>
<?rfc include="reference.RFC.4601"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.5015"?>
<?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.6224"?>
<?rfc include="reference.RFC.5845"?>
<?rfc include="reference.RFC.2236"?>
<?rfc include="reference.I-D.zuniga-multimob-pmipv6-ropt"?>
</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-ietf-multimob-pmipv6-source-00:</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:22:02 |