MULTIMOB Group T C. Schmidt, Ed.
Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao
Expires: July 12, 2012 H. Zhang
Beijing Jiaotong University
M. Waehlisch
link-lab & FU Berlin
January 9, 2012
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
draft-ietf-multimob-pmipv6-source-00
Abstract
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.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2012.
Copyright Notice
Schmidt, Ed., et al. Expires July 12, 2012 [Page 1]
Internet-Draft Multicast Senders in PMIPv6 January 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Base Solution for Source Mobility: Details . . . . . . . . 8
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Efficiency of the Distribution System . . . . . . . . 10
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11
4.2.1. PIM-SM Considerations . . . . . . . . . . . . . . . . 12
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 12
4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. BIDIR PIM . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Extended Source Mobility Schemes in PMIPv6 . . . . . . . . . . 13
5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 16
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Schmidt, Ed., et al. Expires July 12, 2012 [Page 2]
Internet-Draft Multicast Senders in PMIPv6 January 2012
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
[RFC6275] 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 [RFC5213], cannot participate
in multicast communication, as MAGs will discard group packets.
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 [RFC6224].
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.
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.
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.
This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains subsequently for the base deployment
scenario [RFC6224], 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 [RFC5757]. Mobile Nodes in this setting remain agnostic
of multicast mobility operations.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 3]
Internet-Draft Multicast Senders in PMIPv6 January 2012
2. Terminology
This document uses the terminology as defined for the mobility
protocols [RFC6275], [RFC5213] and [RFC5844], as well as the
multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605].
3. Base Solution for Source Mobility and PMIPv6 Routing
3.1. Overview
The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 1. 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.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 4]
Internet-Draft Multicast Senders in PMIPv6 January 2012
+-------------+
| 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)
Figure 1: Reference Network for Multicast Deployment in PMIPv6 with
Source Mobility
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).
An MN can successfully distribute multicast data in PMIPv6, if MLD
Schmidt, Ed., et al. Expires July 12, 2012 [Page 5]
Internet-Draft Multicast Senders in PMIPv6 January 2012
proxy functions are deployed at the MAG as described in [RFC6224].
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.
According to the specifications given in [RFC4605], 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.
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.
1. The MAG has determined that the MN is admissible to multicast
services.
2. The MAG has added the new downstream link to the MLD proxy
instance with up-link to the corresponding LMA.
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
Figure 2). In this way, multicast source mobility is transparently
enabled in PMIPv6 domains that deploy the base scenario for
multicast.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 6]
Internet-Draft Multicast Senders in PMIPv6 January 2012
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 | | | |
|<---------------+ | | |
| | | | |
Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP
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 [RFC5844].
IPv4 multicast is handled by an IGMP proxy function at the MAG in an
analogous way.
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 Appendix A for further
considerations).
Schmidt, Ed., et al. Expires July 12, 2012 [Page 7]
Internet-Draft Multicast Senders in PMIPv6 January 2012
3.2. Base Solution for Source Mobility: Details
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.
3.2.1. Operations of the Mobile Node
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.
3.2.2. Operations of the Mobile Access Gateway
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., [RFC6224]). 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 [RFC4605].
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.
3.2.3. Operations of the Local Mobility Anchor
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.
3.2.3.1. Local Mobility Anchors Operating PIM
Local Mobility Anchors that operate the PIM-SM routing protocol
[RFC4601] 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.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 8]
Internet-Draft Multicast Senders in PMIPv6 January 2012
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 [RFC4601] ).
Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
respect to source location and does not require a special
configuration.
3.2.4. IPv4 Support
An MN in a PMIPv6 domain may use an IPv4 address transparently for
communication as specified in [RFC5844]. 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. [RFC4605] defines IGMP proxy behaviour in full agreement with
IPv6/MLD. Thus IPv4 support can be transparently provided following
the obvious deployment analogy.
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.
A particular note is worth giving the scenario of [RFC5845] 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.
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-
Schmidt, Ed., et al. Expires July 12, 2012 [Page 9]
Internet-Draft Multicast Senders in PMIPv6 January 2012
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.
3.2.5. Efficiency of the Distribution System
In the following efficiency-related issues are enumerated.
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.
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.
4. Direct Multicast Routing
There are deployment scenarios, where multicast services are
available throughout the access network independent of the PMIPv6
routing system [I-D.zuniga-multimob-pmipv6-ropt]. 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 Section 5 for a further
discussion).
4.1. Overview
Direct multicast access can be supported by
o 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,
o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM
[RFC5015] deployed at the MAGs.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 10]
Internet-Draft Multicast Senders in PMIPv6 January 2012
*** *** *** ***
* ** ** ** *
* *
* 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
Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast
Access and (b) Dynamic Multicast Routing at MAGs
Figure 3 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.
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
[RFC5757] for further aspects). Deployment details are specific to
the multicast routing protocol in use, in the following described for
common protocols.
4.2. MLD Proxies at MAGs
In a PMIPv6 domain, single MLD proxy instances can be deployed at
each MAG to enable multicast service at the access (see Figure 3 (a)
). To avoid service disruptions on handovers, the uplinks of all
proxies SHOULD be adjacent to the same next-hop multicast router.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 11]
Internet-Draft Multicast Senders in PMIPv6 January 2012
This can either be achieved by arranging proxies within a flat access
network, or by upstream tunnels that terminate at a common multicast
router.
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.
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.
4.2.1. PIM-SM Considerations
A mobile source that transmits data via an MLD proxy will not be
directly connected to a PIM Designated Router as discussed in
Section 3.2.3.1. Countermeasures apply correspondingly.
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.
4.2.2. SSM Considerations
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.
4.3. PIM-SM
TODO
Schmidt, Ed., et al. Expires July 12, 2012 [Page 12]
Internet-Draft Multicast Senders in PMIPv6 January 2012
4.4. BIDIR PIM
TODO
5. Extended Source Mobility Schemes in PMIPv6
In this section, specific optimization approaches to multicast source
mobility are introduced.
5.1. Multiple Upstream Interface Proxy
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 [RFC6224]
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).
.... TODO details.
6. IANA Considerations
TODO.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
TODO
Schmidt, Ed., et al. Expires July 12, 2012 [Page 13]
Internet-Draft Multicast Senders in PMIPv6 January 2012
Consequently, no new threats are introduced by this document in
addition to those identified as security concerns of [RFC3810],
[RFC4605], [RFC5213], and [RFC5844].
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.
8. Acknowledgements
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 14]
Internet-Draft Multicast Senders in PMIPv6 January 2012
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
9.2. Informative References
[I-D.zuniga-multimob-pmipv6-ropt]
Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y.
Kim, "Multicast Mobility Routing Optimizations for Proxy
Mobile IPv6", draft-zuniga-multimob-pmipv6-ropt-01 (work
in progress), October 2011.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
and Brief Survey", RFC 5757, February 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
Schmidt, Ed., et al. Expires July 12, 2012 [Page 15]
Internet-Draft Multicast Senders in PMIPv6 January 2012
Appendix A. Evaluation of Traffic Flows
TODO
Appendix B. Change Log
The following changes have been made from version
draft-ietf-multimob-pmipv6-source-00:
Authors' Addresses
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Shuai Gao
Beijing Jiaotong University
Beijing,
China
Phone:
Fax:
Email: shgao@bjtu.edu.cn
URI:
Hong-Ke Zhang
Beijing Jiaotong University
Beijing,
China
Phone:
Fax:
Email: hkzhang@bjtu.edu.cn
URI:
Schmidt, Ed., et al. Expires July 12, 2012 [Page 16]
Internet-Draft Multicast Senders in PMIPv6 January 2012
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
Email: mw@link-lab.net
Schmidt, Ed., et al. Expires July 12, 2012 [Page 17]