draft-ietf-multimob-pmipv6-source-06.txt   draft-ietf-multimob-pmipv6-source-07.txt 
MULTIMOB Group T. Schmidt, Ed. MULTIMOB Group T. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Experimental S. Gao Intended status: Experimental S. Gao
Expires: April 22, 2014 H. Zhang Expires: July 9, 2014 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
October 19, 2013 January 5, 2014
Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
draft-ietf-multimob-pmipv6-source-06 draft-ietf-multimob-pmipv6-source-07
Abstract Abstract
Multicast communication can be enabled in Proxy Mobile IPv6 domains Multicast communication can be enabled in Proxy Mobile IPv6 domains
via the Local Mobility Anchors by deploying MLD proxy functions at via the Local Mobility Anchors by deploying MLD proxy functions at
Mobile Access Gateways, via a direct traffic distribution within an Mobile Access Gateways, via a direct traffic distribution within an
ISP's access network, or by selective route optimization schemes. ISP's access network, or by selective route optimization schemes.
This document describes the support of mobile multicast senders in This document describes a base solution and an experimental protocol
Proxy Mobile IPv6 domains for all three scenarios. Protocol to support of mobile multicast senders in Proxy Mobile IPv6 domains
optimizations for synchronizing PMIPv6 with PIM, as well as a peering for all three scenarios. Protocol optimizations for synchronizing
function for MLD Proxies are defined. Mobile sources always remain PMIPv6 with PIM, as well as a peering function for MLD Proxies are
agnostic of multicast mobility operations. defined. Mobile sources always remain agnostic of multicast mobility
operations.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2014. This Internet-Draft will expire on July 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Base Solution for Source Mobility: Details . . . . . . . 7 3.2. Base Solution for Source Mobility: Details . . . . . . . 8
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 7 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 7 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Efficiency of the Distribution System . . . . . . . . 10 3.2.5. Efficiency of the Distribution System . . . . . . . . 10
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 10 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 12 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 12 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 13
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13
4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 14 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 14
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 14 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 15
4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 15 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 15
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17
5. MLD Proxy Peering Function for Optimized Source Mobility in 5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Operations at the Multicast Sender . . . . . . . . . . . 18 5.3. Operations in Support of Multicast Senders . . . . . . . 19
5.4. Operations at the Multicast Listener . . . . . . . . . . 19 5.4. Operations in Support of Multicast Listeners . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 23 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 23
A.1. Operations for Local Multicast Sources . . . . . . . . . 23 A.1. Operations for Local Multicast Sources . . . . . . . . . 24
A.2. Operations for Local Multicast Subscribers . . . . . . . 23 A.2. Operations for Local Multicast Subscribers . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
[RFC6275] by network-based management functions that enable IP [RFC6275] by network-based management functions that enable IP
mobility for a host without requiring its participation in any mobility for a host without requiring its participation in any
mobility-related signaling. Additional network entities called the mobility-related signaling. Additional network entities called the
Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are
responsible for managing IP mobility on behalf of the mobile node responsible for managing IP mobility on behalf of the mobile node
(MN). An MN connected to a PMIPv6 domain, which only operates (MN). An MN connected to a PMIPv6 domain, which only operates
skipping to change at page 4, line 33 skipping to change at page 4, line 26
This document uses the terminology as defined for the mobility This document uses the terminology as defined for the mobility
protocols [RFC6275], [RFC5213] and [RFC5844], as well as the protocols [RFC6275], [RFC5213] and [RFC5844], as well as the
multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605].
3. Base Solution for Source Mobility and PMIPv6 Routing 3. Base Solution for Source Mobility and PMIPv6 Routing
3.1. Overview 3.1. Overview
The reference scenario for multicast deployment in Proxy Mobile IPv6 The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 1. MAGs play the role of first-hop domains is illustrated in Figure 1. It displays the general setting
access routers that serve multiple MNs on the downstream while for source mobility - Mobile Nodes (MNs) with Home Network Prefixes
running an MLD/IGMP proxy instance for every LMA upstream tunnel. (HNPs) that receive services via tunnels, which are spanned between a
Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address
(Proxy-CoA) at a Mobility Access Gateway (MAG). 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.
+-------------+ +-------------+
| Multicast | | Multicast |
| Listeners | | Listeners |
+-------------+ +-------------+
| |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
/ \ / \
+----+ +----+ +----+ +----+
|LMA1| |LMA2| Multicast Anchor |LMA1| |LMA2| Multicast Anchor
+----+ +----+ +----+ +----+
LMAA1 | | LMAA2 LMAA1 | | LMAA2
| | | |
\\ //\\ \\ //\\
\\ // \\ \\ // \\
\\ // \\ Unicast Tunnel \\ // \\ Unicast Tunnel
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
Proxy-CoA1 || || Proxy-CoA2 Proxy-CoA1 || || Proxy-CoA2
+----+ +----+ +----+ +----+
|MAG1| |MAG2| MLD Proxy |MAG1| |MAG2| MLD Proxy
+----+ +----+ +----+ +----+
| | | | | |
MN-HNP1 | | MN-HNP2 | MN-HNP3 MN-HNP1 | | MN-HNP2 | MN-HNP3
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
Multicast Sender + Listener(s) Multicast Sender + Listener(s)
Figure 1: Reference Network for Multicast Deployment in PMIPv6 with Figure 1: Reference Network for Multicast Deployment in PMIPv6
Source Mobility - Mobile Nodes (MNs) with Home Network Prefixes
(HNPs) receive services via tunnels that are spanned between a Local
Mobiity Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA)
at a Mobility Access Gateway (MAG)
An MN in a PMIPv6 domain will decide on multicast data transmission An MN in a PMIPv6 domain will decide on multicast data transmission
completely independent of its current mobility conditions. It will completely independent of its current mobility conditions. It will
send packets as initiated by applications, using its source address send packets as initiated by applications, using its source address
with Home Network Prefix (HNP) and a multicast destination address with Home Network Prefix (HNP) and a multicast destination address
chosen by application needs. Multicast packets will arrive at the chosen by application needs. Multicast packets will arrive at the
currently active MAG via one of its downstream local (wireless) currently active MAG via one of its downstream local (wireless)
links. A multicast unaware MAG would simply discard these packets in links. A multicast unaware MAG would simply discard these packets in
the absence of instructions for packet processing, i.e., a multicast the absence of instructions for packet processing, i.e., a multicast
routing information base (MRIB). routing information base (MRIB).
skipping to change at page 8, line 9 skipping to change at page 8, line 30
deployed, one for each tunnel to an LMA, which serves as its unique 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 upstream link (cf., [RFC6224]). On the arrival of an MN, the MAG
decides on the mapping of downstream links to a proxy instance and 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 the upstream link to the LMA based on the regular Binding Update List
as maintained by PMIPv6 standard operations. When multicast data is as maintained by PMIPv6 standard operations. When multicast data is
received from the MN, the MAG MUST identify the corresponding proxy received from the MN, the MAG MUST identify the corresponding proxy
instance from the incoming interface and forwards multicast data instance from the incoming interface and forwards multicast data
upstream according to [RFC4605]. upstream according to [RFC4605].
The MAG MAY apply special admission control to enable multicast data The MAG MAY apply special admission control to enable multicast data
transition from an MN. It is advisable to take special care that MLD transmission from an MN. It is advisable to take special care that
proxy implementations do not redistribute multicast data to MLD proxy implementations do not redistribute multicast data to
downstream interfaces without appropriate subscriptions in place. downstream interfaces without appropriate subscriptions in place.
3.2.3. Operations of the Local Mobility Anchor 3.2.3. Operations of the Local Mobility Anchor
For any MN, the Local Mobility Anchor acts as the persistent Home 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 Agent and at the same time as the default multicast upstream for the
corresponding MAG. It will manage and maintain a multicast corresponding MAG. It will manage and maintain a multicast
forwarding information base for all group traffic arriving from its forwarding information base for all group traffic arriving from its
mobile sources. It SHOULD participate in multicast routing functions mobile sources. It SHOULD participate in multicast routing functions
that enable traffic redistribution to all adjacent LMAs within the that enable traffic redistribution to all adjacent LMAs within the
skipping to change at page 8, line 45 skipping to change at page 9, line 18
being TRUE for mobile sources and the PIM-SM forwarding rule "iif == being TRUE for mobile sources and the PIM-SM forwarding rule "iif ==
RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 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 interface from MAG to LMA is considered as not part of the PIM-SM
component of the LMA (see A.1 of [RFC4601] ). component of the LMA (see A.1 of [RFC4601] ).
In addition, an LMA serving as PIM Designated Router (DR) is In addition, an LMA serving as PIM Designated Router (DR) is
connected to MLD proxies via individual IP-tunnel interfaces and will connected to MLD proxies via individual IP-tunnel interfaces and will
experience changing PIM source states on handover. As the incoming experience changing PIM source states on handover. As the incoming
interface connects to a point-to-point link, PIM Assert contention is interface connects to a point-to-point link, PIM Assert contention is
not active, and incoming interface validation is only performed by not active, and incoming interface validation is only performed by
RPF (Reverse Path Forwarding) checks. Consequently, a PIM DR SHOULD Reverse Path Forwarding (RPF) checks. Consequently, a PIM DR SHOULD
update incoming source states, as soon as RPF inspection succeeds, update incoming source states, as soon as RPF inspection succeeds,
i.e., after PMIPv6 forwarding state update. Consequently, PIM i.e., after PMIPv6 forwarding state update. Consequently, PIM
routers SHOULD be able to manage these state changes, but some routers SHOULD be able to manage these state changes, but some
implementations are expected to incorrectly refuse packets until the implementations are expected to incorrectly refuse packets until the
previous state has timed out. previous state has timed out.
Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with Notably, running BIDIR-PIM [RFC5015] on LMAs remains robust with
respect to source location and does not require special respect to source location and does not require special
configurations or state management for sources. configurations or state management for sources.
3.2.4. IPv4 Support 3.2.4. IPv4 Support
An MN in a PMIPv6 domain may use an IPv4 address transparently for An MN in a PMIPv6 domain may use an IPv4 address transparently for
communication as specified in [RFC5844]. For this purpose, an LMA communication as specified in [RFC5844]. For this purpose, an LMA
can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can
provide IPv4 support in its access network. Correspondingly, provide IPv4 support in its access network. Correspondingly,
multicast membership management will be performed by the MN using multicast membership management will be performed by the MN using
skipping to change at page 10, line 28 skipping to change at page 10, line 46
LMA will receive all multicast traffic originating from its LMA will receive all multicast traffic originating from its
associated MNs. There is no mechanism to suppress upstream associated MNs. There is no mechanism to suppress upstream
forwarding in the absence of receivers. forwarding in the absence of receivers.
MNs on the same MAG using different LMAs For a mobile receiver and a 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 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 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 same MAG, causing redundant flows in the access network and at the
MAG. MAG.
These remaining deficits in routing efficiency can be resolved by
adding peering functions to MLD proxies as described in Section 5.
4. Direct Multicast Routing 4. Direct Multicast Routing
There are deployment scenarios, where multicast services are There are deployment scenarios, where multicast services are
available throughout the access network independent of the PMIPv6 available throughout the access network independent of the PMIPv6
routing system [RFC7028]. In these cases, the visited networks grant routing system [RFC7028]. In these cases, the visited networks grant
a local content distribution service (in contrast to LMA-based home a local content distribution service (in contrast to LMA-based home
subscription) with locally optimized traffic flows. It is also subscription) with locally optimized traffic flows. It is also
possible to deploy a mixed service model of local and LMA-based possible to deploy a mixed service model of local and LMA-based
subscriptions, provided a unique way of service selection is subscriptions, provided a unique way of service selection is
implemented. For example, access routers (MAGs) could decide on implemented. For example, access routers (MAGs) could decide on
skipping to change at page 11, line 5 skipping to change at page 11, line 29
Direct multicast access can be supported by Direct multicast access can be supported by
o native multicast routing provided by one multicast router that is o native multicast routing provided by one multicast router that is
neighboring MLD proxies deployed at MAGs within a flat access neighboring MLD proxies deployed at MAGs within a flat access
network, or via tunnel uplinks, network, or via tunnel uplinks,
o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM
[RFC5015] deployed at the MAGs. [RFC5015] deployed at the MAGs.
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Multicast * * Multicast *
+----+ * Infrastructure * +----+ +----+ * Infrastructure * +----+
|LMA | * ** ** ** * |LMA | |LMA | * ** ** ** * |LMA |
+----+ *** *** *** *** +----+ +----+ *** *** *** *** +----+
| // \\ | | // \\ |
\\ // \\ PMIP (unicast) | \\ // \\ PMIP (unicast) |
PMIP \\ // \\ // \\ ** *** *** ** // PMIP \\ // \\ // \\ ** *** *** ** //
(unicast) \\ // \\ // \\ * ** ** ** // (unicast) \\ // \\ // \\ * ** ** ** //
\\ // \\ // \\* Multicast *// \\ // \\ // \\* Multicast *//
|| || || || * || Routing || * || || || || * || Routing || *
+----+ +----+ * +----+ +----+ * +----+ +----+ * +----+ +----+ *
MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| *
+----+ +----+ *+----+ ** ** +----+* +----+ +----+ *+----+ ** ** +----+*
| | | | |*** *** ***| | | | | |*** *** ***|
| | | | | | | | | | | |
MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast
Access and (b) Dynamic Multicast Routing at MAGs Access and (b) Dynamic Multicast Routing at MAGs
Figure 3 displays the corresponding deployment scenarios, which Figure 3 displays the corresponding deployment scenarios, which
separate multicast from PMIPv6 unicast routing. It is assumed separate multicast from PMIPv6 unicast routing. It is assumed
throughout these scenarios that all MAGs (MLD proxies) are linked to throughout these scenarios that all MAGs (MLD proxies) are linked to
a single multicast routing domain. Notably, this scenario requires a single multicast routing domain. Notably, this scenario requires
coordination of multicast address utilization and service bindings. coordination of multicast address utilization and service bindings.
skipping to change at page 12, line 44 skipping to change at page 13, line 14
4.2.1. Considerations for PIM-SM on the Upstream 4.2.1. Considerations for PIM-SM on the Upstream
A mobile source that transmits data via an MLD proxy will not be A mobile source that transmits data via an MLD proxy will not be
directly connected to a PIM Designated Router as discussed in directly connected to a PIM Designated Router as discussed in
Section 3.2.3.1. Countermeasures apply correspondingly. Section 3.2.3.1. Countermeasures apply correspondingly.
A PIM Designated Router that is connected to MLD proxies via A PIM Designated Router that is connected to MLD proxies via
individual IP-tunnel interfaces will experience invalid PIM source individual IP-tunnel interfaces will experience invalid PIM source
states on handover. In some implementations of PIM-SM this could states on handover. In some implementations of PIM-SM this could
lead to an interim packet loss (see Section Section 3.2.3.1). This lead to an interim packet loss (see Section 3.2.3.1). This problem
problem can be mitigated by aggregating proxies on a lower layer. can be mitigated by aggregating proxies on a lower layer.
4.2.2. SSM Considerations 4.2.2. SSM Considerations
Source-specific subscriptions invalidate with routes, whenever the Source-specific subscriptions invalidate with routes, whenever the
source moves from or to the MAG/proxy of a subscriber. Multicast source moves from or to the MAG/proxy of a subscriber. Multicast
forwarding states will rebuild with unicast route changes. However, forwarding states will rebuild with unicast route changes. However,
this may lead to noticeable service disruptions for locally this may lead to noticeable service disruptions for locally
subscribed nodes. subscribed nodes.
4.3. PIM-SM at MAGs 4.3. PIM-SM at MAGs
The full-featured multicast routing protocol PIM-SM MAY be deployed The full-featured multicast routing protocol PIM-SM MAY be deployed
in the access network for providing multicast services in parallel to in the access network for providing multicast services in parallel to
skipping to change at page 18, line 30 skipping to change at page 18, line 45
following solution. following solution.
5.2. Overview 5.2. Overview
A peering interface for MLD proxies allows for a direct data exchange A peering interface for MLD proxies allows for a direct data exchange
of locally attached multicast sources. Such peering interfaces can of locally attached multicast sources. Such peering interfaces can
be configured - as a direct link or a bidirectional tunnel - between be configured - as a direct link or a bidirectional tunnel - between
any two proxy instances (locally deployed as in [RFC6224] or any two proxy instances (locally deployed as in [RFC6224] or
remotely). Peerings remain as silent virtual links in regular proxy remotely). Peerings remain as silent virtual links in regular proxy
operations. Data is exchanged on such links only in cases, where one operations. Data is exchanged on such links only in cases, where one
peering proxy directly connects on the downstream to a source of peering proxy on its downstream directly connects to a source of
multicast traffic, which the other peering proxy actively subscribes multicast traffic, which the other peering proxy actively subscribes
to. In such cases, the source-connected proxy will receive a to. In such cases, the proxy connected to the source will receive a
listener report on its peering interface and forwards traffic from listener report on its peering interface and forwards traffic from
its local source accordingly. It is worth noting that multicast its local source accordingly. It is worth noting that multicast
traffic distribution on peering links does not follow reverse unicast traffic distribution on peering links does not follow reverse unicast
paths to sources. In the following, operations are defined for ASM paths to sources. In the following, operations are defined for ASM
and SSM, but provide superior performance in the presence of source- and SSM, but provide superior performance in the presence of source-
specific signaling (IGMPv3/MLDv2) [RFC4604]. specific signaling (IGMPv3/MLDv2) [RFC4604].
5.3. Operations at the Multicast Sender 5.3. Operations in Support of Multicast Senders
An MLD proxy in the perspective of a sender will see peering An MLD proxy in the perspective of a sender will see peering
interfaces as restricted downstream interfaces. It will install and interfaces as restricted downstream interfaces. It will install and
maintain source filters at its peering links that will restrict data maintain source filters at its peering links that will restrict data
transmission to those packets that originate from a source that is transmission to those packets that originate from a source that is
locally attached at one of its downstream interfaces. locally attached at one of its downstream interfaces.
In detail, a proxy will extract from its configuration the network In detail, a proxy will extract from its configuration the network
prefixes attached to its downstream interfaces and MUST implement a prefixes attached to its downstream interfaces and MUST implement a
source filter base at its peering interfaces that restricts data source filter base at its peering interfaces that restricts data
transmission to IP source addresses from its local prefixes. This transmission to IP source addresses from its local prefixes. This
filter base MUST be updated, if and only if the downstream filter base MUST be updated, if and only if the downstream
configuration changes. Multicast packets that arrive from the configuration changes (e.g., due to mobility). Multicast packets
upstream interface of the proxy are thus prevented from traversing that arrive from the upstream interface of the proxy are thus
any peering link, but are only forwarded to regular downstream prevented from traversing any peering link, but are only forwarded to
interfaces with appropriate subscription states. In this way, a regular downstream interfaces with appropriate subscription states.
multihop forwarding on peering links is prevented. In this way, a multihop forwarding on peering links is prevented.
Multicast traffic arriving from a locally attached source will be Multicast traffic arriving from a locally attached source will be
forwarded to the regular upstream interface and all downstreams with forwarded to the regular upstream interface and all downstreams with
appropriate subscription states (i.e., regular proxy operations). In appropriate subscription states (i.e., regular proxy operations). In
addition, multicast packets of local origin are transferred to those addition, multicast packets of local origin are transferred to those
peering interfaces with appropriate subscription states. peering interfaces with appropriate subscription states.
5.4. Operations at the Multicast Listener 5.4. Operations in Support of Multicast Listeners
From the listener side, peering interfaces appear as preferred At the listener side, peering interfaces appear as preferred upstream
upstream links. The multicast proxy will attempt to subscribe to links. The multicast proxy will attempt to receive multicast
multicast services on peering links for as many groups (channels) as services on peering links for as many groups (channels) as possible.
possible. The general upstream interface configured according to The general upstream interface configured according to [RFC4605] will
[RFC4605] will be used only for those groups (channels) that remain be used only for retrieving those groups (channels) that remain
unavailable from peerings. From this extension of [RFC4605], an MLD unavailable from peerings. From this extension of [RFC4605], an MLD
proxy with peering interconnects will exhibit several interfaces for proxy with peering interconnects will exhibit several interfaces for
pulling remote traffic: the regular upstream and the peerings. pulling remote traffic: the regular upstream and the peerings.
Traffic available from any of the peering links will be mutually Traffic available from any of the peering links will be mutually
disjoint, but normally also available from the upstream. To prevent disjoint, but normally also available from the upstream. To prevent
duplicate traffic from arriving at the listener side, the proxy duplicate traffic from arriving at the listener side, the proxy
o MAY delay aggregated reports to the upstream, and o MAY delay aggregated reports to the upstream, and
o MUST apply appropriate filters to exclude duplicate streams. o MUST apply appropriate filters to exclude duplicate streams.
In detail, an MLD proxy instance at a MAG first issues listener In detail, an MLD proxy instance at a MAG first issues listener
reports (in parallel) to its peering links. These links only span reports (in parallel) to all of its peering links. These links span
one (virtual) hop. Whenever certain group traffic (SSM channels) at most one (virtual) hop. Whenever certain group traffic (SSM
does not arrive from the peerings after a waiting time (default: 10 channels) does not arrive from the peerings after a waiting time
ms), additional (complementary, in the case of SSM) reports are sent (default: 10 ms (node-local) and 25 ms (remote)), additional
to the standard upstream interface. (complementary, in the case of SSM) reports are sent to the standard
upstream interface.
After the arrival of traffic from peering links, an MLD proxy MUST Whenever traffic from a peering link arrives, an MLD proxy MUST
install source filters at its RFC 4605 upstream in the following way. install source filters at its RFC 4605 upstream in the following way.
ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using
IGMPv2/MLDv1, only, the proxy cannot signal source filtering to IGMPv2/MLDv1, only, the proxy cannot signal source filtering to
its upstream. Correspondingly, it applies (S,*) ingress filters its upstream. Correspondingly, it applies (S,*) ingress filters
at its upstream interface for all sources S seen in traffic on the at its upstream interface for all sources S seen in traffic on the
peering links. It is noteworthy that unwanted traffic is still peering links. It is noteworthy that unwanted traffic is still
replicated to the proxy via the (wired) provider backbone, but not replicated to the proxy via the (wired) provider backbone, but it
forwarded into the wireless access network. is not forwarded into the wireless access network.
ASM with IGMPv3/MLDv2 In the presence of source-specific signaling ASM with IGMPv3/MLDv2 In the presence of source-specific signaling
(IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude
mode for all sources S seen in traffic of the peering links. The mode for all sources S seen in traffic of the peering links. The
corresponding source-specific signaling will prevent forwarding of corresponding source-specific signaling will prevent forwarding of
duplicate traffic throughout the access network. duplicate traffic throughout the access network.
SSM In the presence of Source Specific Multicast, the proxy will SSM In the presence of Source Specific Multicast, the proxy will
subscribe on its uplink interface to those (S,G) channels, only, subscribe on its uplink interface to those (S,G) channels, only,
that do not arrive via the peering links. that do not arrive via the peering links.
MLD proxies will install data-driven timers (source-timeout) for each
source but common to all peering interfaces to detect interruptions
of data services from individual sources at proxy peers. Termination
of source-specific flows may be application-specific, but also due to
a source handover, or transmission failures. After a handover, a
mobile source may reattach at another MLD proxy with peering relation
to the listener, or at a proxy that does not peer. While in the
first case, traffic reappears on another peering link, in the second
case data can only be retrieved via the regular upstream. To account
for the latter, the MLD proxy revokes the source-specific filter(s)
at its upstream interface, after the source-timeout fires (default:
50 ms). Corresponding traffic will then be pulled from the regular
upstream. Source-specific filters MUST be reinstalled, whenever
traffic of this source arrives at any peering interface.
There is a noteworthy trade-off between traffic minimization and
available traffic at the upstream that is locally filtered at the
proxy. Implementors can use this relation to optimize for service-
specific requirements.
In proceeding this way, multicast group data will arrive from peering In proceeding this way, multicast group data will arrive from peering
interfaces first, while only peer-wise unavailable traffic is interfaces first, while only peer-wise unavailable traffic is
retrieved from the regular upstream interface. retrieved from the regular upstream interface.
6. IANA Considerations 6. IANA Considerations
This document makes no request to IANA.. This document makes no request to IANA..
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
This document defines multicast sender mobility based on PMIPv6 and This document defines multicast sender mobility based on PMIPv6 and
common multicast routing protocols. Consequently, threats identified common multicast routing protocols. Consequently, threats identified
as security concerns of [RFC3810], [RFC4605], [RFC5213], and as security concerns of [RFC2710] [RFC3810], [RFC4605], [RFC5213],
[RFC5844] are inherited by this document. and [RFC5844] are inherited by this document.
In addition, particular attention should be paid to implications of In addition, particular attention should be paid to implications of
combining multicast and mobility management at network entities. As combining multicast and mobility management at network entities. As
this specification allows mobile nodes to initiate the creation of this specification allows mobile nodes to initiate the creation of
multicast forwarding states at MAGs and LMAs while changing multicast forwarding states at MAGs and LMAs while changing
attachments, threats of resource exhaustion at PMIP routers and attachments, threats of resource exhaustion at PMIP routers and
access networks arrive from rapid state changes, as well as from high access networks arrive from rapid state changes, as well as from high
volume data streams routed into access networks of limited volume data streams routed into access networks of limited
capacities. In cases of PIM-SM deployment, handover operations of capacities. In cases of PIM-SM deployment, handover operations of
the MNs include re-registering sources at the Rendezvous Points at the MNs include re-registering sources at the Rendezvous Points at
skipping to change at page 21, line 17 skipping to change at page 22, line 9
interfaces at a proxy are incorrect or inconsistent. Consequently, interfaces at a proxy are incorrect or inconsistent. Consequently,
implementations of peering-enabled proxies SHOULD take particular implementations of peering-enabled proxies SHOULD take particular
care on maintaining (varying) IP configurations at the downstream in care on maintaining (varying) IP configurations at the downstream in
a reliable and timely manner (see [RFC6224] for requirements on a reliable and timely manner (see [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies). PMIPv6-compliant implementations of MLD proxies).
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Luis M. The authors would like to thank (in alphabetical order) Luis M.
Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong,
Jouni Korhonen, He-Wu Li, Cong Liu, Akbar Rahman, Stig Venaas, Li-Li Jouni Korhonen, He-Wu Li, Cong Liu, Akbar Rahman, Behcet Sarikaya,
Wang, Qian Wu, Zhi-Wei Yan for advice, help and reviews of the Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, Zhi-Wei Yan for
document. Funding by the German Federal Ministry of Education and advice, help and reviews of the document. Funding by the German
Research within the G-LAB Initiative (projects HAMcast, Mindstone and Federal Ministry of Education and Research within the G-LAB
SAFEST) is gratefully acknowledged. Initiative (projects HAMcast, Mindstone and SAFEST) is gratefully
acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
skipping to change at page 22, line 31 skipping to change at page 23, line 21
Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and
D. Liu, "Multicast Listener Extensions for MIPv6 and D. Liu, "Multicast Listener Extensions for MIPv6 and
PMIPv6 Fast Handovers", draft-ietf-multimob- PMIPv6 Fast Handovers", draft-ietf-multimob-
fmipv6-pfmipv6-multicast-01 (work in progress), February fmipv6-pfmipv6-multicast-01 (work in progress), February
2013. 2013.
[I-D.ietf-multimob-handover-optimization] [I-D.ietf-multimob-handover-optimization]
Contreras, L., Bernardos, C., and I. Soto, "PMIPv6 Contreras, L., Bernardos, C., and I. Soto, "PMIPv6
multicast handover optimization by the Subscription multicast handover optimization by the Subscription
Information Acquisition through the LMA (SIAL)", draft- Information Acquisition through the LMA (SIAL)", draft-
ietf-multimob-handover-optimization-05 (work in progress), ietf-multimob-handover-optimization-06 (work in progress),
October 2013. November 2013.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
skipping to change at page 24, line 24 skipping to change at page 25, line 15
signaling, i.e. in IGMPv2/MLDv1 only domains. signaling, i.e. in IGMPv2/MLDv1 only domains.
In typical deployment scenarios, specific group services (channels) In typical deployment scenarios, specific group services (channels)
could be either associated with selected uplinks to remote LMAs, could be either associated with selected uplinks to remote LMAs,
while a (*,*) default subscription entry (in the last table line) is while a (*,*) default subscription entry (in the last table line) is
bound to a local routing interface, or selected groups are configured bound to a local routing interface, or selected groups are configured
as local services first, while a (*,*) default entry (in the last as local services first, while a (*,*) default entry (in the last
table line) points to a remote uplink that provides the general table line) points to a remote uplink that provides the general
multicast support. multicast support.
Appendix B. Change Log Appendix B. Implementation
An implementation of the extended IGMP/MLD proxy has been provided
within the MCPROXY project http://mcproxy.realmv6.org/. This open
source software is written in C++ and uses forwarding capabilities of
the Linux kernel. It supports all regular operations according to
[RFC4605], allows for multiple proxy instances on one node,
dynamically changing downstream links, as well as proxy-to-proxy
peerings and multiple upstream links with individual configurations.
The software can be downloaded from Github at https://github.com/
mcproxy/mcproxy.
Appendix C. Change Log
The following changes have been made from version draft-ietf-
multimob-pmipv6-source-06:
1. Editorial improvements in response to WG Last Call.
2. Clarified mobile source handover treatment for peering proxies in
response to WG Last Call.
3. Updated and extended references.
4. Added pointer to available implementation in Appendix.
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-05: multimob-pmipv6-source-05:
1. Editorial improvements in response to WG feedback. 1. Editorial improvements in response to WG feedback.
2. Updated and extended references. 2. Updated and extended references.
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-04: multimob-pmipv6-source-04:
 End of changes. 42 change blocks. 
101 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/