draft-ietf-multimob-pmipv6-source-09.txt   rfc7287.txt 
MULTIMOB Group T. Schmidt, Ed. Internet Engineering Task Force (IETF) T. Schmidt, Ed.
Internet-Draft HAW Hamburg Request for Comments: 7287 HAW Hamburg
Intended status: Experimental S. Gao Category: Experimental S. Gao
Expires: October 2, 2014 H. Zhang ISSN: 2070-1721 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
March 31, 2014 June 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-09
Abstract Abstract
Multicast communication can be enabled in Proxy Mobile IPv6 domains Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6)
via the Local Mobility Anchors by deploying MLD proxy functions at domains via the Local Mobility Anchors by deploying Multicast
Mobile Access Gateways, via a direct traffic distribution within an Listener Discovery (MLD) proxy functions at Mobile Access Gateways,
ISP's access network, or by selective route optimization schemes. by using direct traffic distribution within an ISP's access network,
This document describes a base solution and an experimental protocol or by selective route optimization schemes. This document describes
to support mobile multicast senders in Proxy Mobile IPv6 domains for a base solution and an experimental protocol to support mobile
all three scenarios. Protocol optimizations for synchronizing PMIPv6 multicast senders in PMIPv6 domains for all three scenarios.
with PIM, as well as a peering function for MLD Proxies are defined. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as
Mobile sources always remain agnostic of multicast mobility a peering function for MLD proxies are defined. Mobile sources
operations. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 2, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7287.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . 8 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8 3.2. Base Solution for Source Mobility: Details . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.5. Efficiency of the Distribution System . . . . . . . . 10 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 10
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 11 3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 13 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 14
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 14 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 15
4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 15 4.3.2. Operations of PIM in Phase One (RP Tree) . . . . . . 16
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 15 4.3.3. Operations of PIM in Phase Two (Register-Stop) . . . 16
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16 4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 17
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 18
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 19
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 19
5. MLD Proxy Peering Function for Optimized Source Mobility in 5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Operations in Support of Multicast Senders . . . . . . . 19 5.3. Operations in Support of Multicast Senders . . . . . . . 20
5.4. Operations in Support of Multicast Listeners . . . . . . 19 5.4. Operations in Support of Multicast Listeners . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 23 A.1. Operations for Local Multicast Sources . . . . . . . . . 26
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 24 A.2. Operations for Local Multicast Subscribers . . . . . . . 26
A.1. Operations for Local Multicast Sources . . . . . . . . . 24 Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 27
A.2. Operations for Local Multicast Subscribers . . . . . . . 24
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 Local
Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are Mobility Anchor (LMAs) 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
according to the base specifications of [RFC5213], cannot participate according to the base specifications of [RFC5213], cannot participate
in multicast communication, as MAGs will discard group packets. in multicast communication, as MAGs will discard group packets.
Multicast support for mobile listeners can be enabled within a PMIPv6 Multicast support for mobile listeners can be enabled within a PMIPv6
domain by deploying MLD proxy functions at Mobile Access Gateways, domain by deploying MLD proxy functions at Mobile Access Gateways,
and multicast routing functions at Local Mobility Anchors [RFC6224]. and multicast routing functions at Local Mobility Anchors [RFC6224].
This base deployment option is the simplest way to PMIPv6 multicast This base deployment option is the simplest way to PMIPv6 multicast
extensions in the sense that it follows the common PMIPv6 traffic extensions in the sense that it follows the common PMIPv6 traffic
model and neither requires new protocol operations nor additional model and neither requires new protocol operations nor additional
infrastructure entities. Standard software functions need to be infrastructure entities. Standard software functions need to be
activated on PMIPv6 entities, only, at the price of possibly non- activated on PMIPv6 entities, only, at the price of possibly non-
optimal multicast routing. optimal multicast routing.
Alternate solutions leverage performance optimization by providing Alternate solutions leverage performance optimization by providing
multicast routing at the access gateways directly multicast routing at the access gateways directly [MULTI-EXT] or by
[I-D.ietf-multimob-fmipv6-pfmipv6-multicast], or by selective route using selective route optimization schemes [RFC7028]. Such
optimization schemes [RFC7028]. Such approaches (partially) follow approaches (partially) follow the model of providing multicast data
the model of providing multicast data services in parallel to PMIPv6 services in parallel to PMIPv6 unicast routing [RFC7161].
unicast routing [I-D.ietf-multimob-handover-optimization].
Multicast listener support satisfies the needs of receptive use cases Multicast listener support satisfies the needs of receptive use cases
such as IPTV or server-centric gaming on mobiles. However, current such as IPTV or server-centric gaming on mobiles. However, current
trends in the Internet develop towards user-centric, highly trends in the Internet develop towards user-centric, highly
interactive group applications like user generated streaming, interactive group applications like user-generated streaming,
conferencing, collective mobile sensing, etc. Many of these popular conferencing, collective mobile sensing, etc. Many of these popular
applications create group content at end systems and can largely applications create group content at end systems and can largely
profit from a direct data transmission to a multicast-enabled profit from a direct data transmission to a multicast-enabled
network. network.
This document describes the support of mobile multicast senders in This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains subsequently for the base deployment Proxy Mobile IPv6 domains for the base deployment scenario [RFC6224],
scenario [RFC6224], for direct traffic distribution within an ISP's for direct traffic distribution within an ISP's access network, as
access network, as well as for selective route optimization schemes. well as for selective route optimization schemes. The source
The contribution of this work reflects the source mobility problem as mobility problem as discussed in [RFC5757] serves as a foundation of
discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic this document. Mobile nodes in this setting remain agnostic of
of multicast mobility operations. multicast mobility operations.
2. Terminology 2. Terminology
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 routing [RFC4601] and edge related protocols [RFC3376], multicast routing [RFC4601] and edge-related protocols [RFC3376],
[RFC3810] and [RFC4605]. [RFC3810], and [RFC4605].
Throught this document, we use the following acronyms Throughout this document, we use the following acronyms:
HNP Home Network Prefix as defined in [RFC5213]. HNP Home Network Prefix as defined in [RFC5213].
MAG Mobile Access Gateway as defined in [RFC5213] MAG Mobile Access Gateway as defined in [RFC5213].
MLD Multicast Listener Discovery as defined in [RFC2710] and MLD Multicast Listener Discovery as defined in [RFC2710] and
[RFC3810]. [RFC3810].
PIM Protocol Independent Multicast as defined in [RFC4601]. PIM Protocol Independent Multicast as defined in [RFC4601].
PMIPv6 Proxy Mobile IPv6 as defined in [RFC5213]. PMIPv6 Proxy Mobile IPv6 as defined in [RFC5213].
2.1. 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].
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. It displays the general setting domains is illustrated in Figure 1. It displays the general setting
for source mobility - Mobile Nodes (MNs) with Home Network Prefixes for source mobility -- mobile nodes (MNs) with Home Network Prefixes
(HNPs) that receive services via tunnels, which are spanned between a (HNPs) that receive services via tunnels, which are spanned between a
Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address
(Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role (Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role
of first-hop access routers that serve multiple MNs on the downstream of first-hop access routers that serve multiple MNs on the downstream
while running an MLD/IGMP proxy instance for every LMA upstream while running an MLD/IGMP proxy instance for every LMA upstream
tunnel. tunnel.
+-------------+ +-------------+
| Multicast | | Multicast |
| Listeners | | Listeners |
skipping to change at page 5, line 45 skipping to change at page 6, line 45
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
Multicast Sender + Listener(s) Multicast Sender + Listener(s)
Figure 1: Reference Network for Multicast Deployment in PMIPv6 Figure 1: Reference Network for Multicast Deployment in PMIPv6
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 an HNP and a multicast destination address chosen by application
chosen by application needs. Multicast packets will arrive at the needs. Multicast packets will arrive at the currently active MAG via
currently active MAG via one of its downstream local (wireless) one of its downstream local (wireless) links. A multicast-unaware
links. A multicast unaware MAG would simply discard these packets in MAG would simply discard these packets in the absence of instructions
the absence of instructions for packet processing, i.e., a multicast for packet processing, i.e., a Multicast Routing Information Base
routing information base (MRIB). (MRIB).
An MN can successfully distribute multicast data in PMIPv6, if MLD An MN can successfully distribute multicast data in PMIPv6, if MLD
proxy functions are deployed at the MAG as described in [RFC6224]. proxy functions are deployed at the MAG as described in [RFC6224].
In this set-up, the MLD proxy instance serving a mobile multicast In this setup, the MLD proxy instance serving a mobile multicast
source has configured its upstream interface at the tunnel towards source has configured its upstream interface at the tunnel towards
MN's corresponding LMA. For each LMA, there will be a separate the MN's corresponding LMA. For each LMA, there will be a separate
instance of an MLD proxy. instance of an MLD proxy.
According to the specifications given in [RFC4605], multicast data According to the specifications given in [RFC4605], multicast data
arriving from a downstream interface of an MLD proxy will be arriving from a downstream interface of an MLD proxy will be
forwarded to the upstream interface and to all but the incoming forwarded to the upstream interface and to all but the incoming
downstream interfaces that have appropriate forwarding states for downstream interfaces that have appropriate forwarding states for
this group. Thus multicast streams originating from an MN will this group. Thus, multicast streams originating from an MN will
arrive at the corresponding LMA and directly at all mobile receivers arrive at the corresponding LMA and directly at all mobile receivers
co-located at the same MAG and MLD proxy instance. Serving as the co-located at the same MAG and MLD proxy instance. Serving as the
designated multicast router or an additional MLD proxy, the LMA designated multicast router or an additional MLD proxy, the LMA
forwards data to the fixed Internet, whenever forwarding states are forwards data to the fixed Internet, whenever forwarding states are
maintained by multicast routing. If the LMA is acting as another MLD maintained by multicast routing. If the LMA is acting as another MLD
proxy, it will forward the multicast data to its upstream interface, proxy, it will forward the multicast data to its upstream interface
and to downstream interfaces with matching subscriptions, and to downstream interfaces with matching subscriptions,
accordingly. accordingly.
In case of a handover, the MN (being unaware of IP mobility) can In case of a handover, the MN (being unaware of IP mobility) can
continue to send multicast packets as soon as network connectivity is continue to send multicast packets as soon as network connectivity is
re-established. At this time, the MAG has determined the re-established. At this time, the MAG has determined the
corresponding LMA, and IPv6 unicast address configuration (including corresponding LMA, and IPv6 unicast address configuration (including
PMIPv6 bindings) has been completed. Still multicast packets PMIPv6 bindings) has been completed. Still, multicast packets
arriving at the MAG are discarded (if not buffered) until the MAG has arriving at the MAG are discarded (if not buffered) until the MAG has
completed the following steps. completed the following steps.
1. The MAG has determined that the MN is admissible to multicast 1. The MAG has determined that the MN is admissible to multicast
services. services.
2. The MAG has added the new downstream link to the MLD proxy 2. The MAG has added the new downstream link to the MLD proxy
instance with up-link to the corresponding LMA. instance with an uplink to the corresponding LMA.
As soon as the MN's uplink is associated with the corresponding MLD As soon as the MN's uplink is associated with the corresponding MLD
proxy instance, multicast packets are forwarded again to the LMA and proxy instance, multicast packets are forwarded again to the LMA and
eventually to receivers within the PMIP domain (see the call flow in eventually to receivers within the PMIP domain. (See the call flow
Figure 2). In this way, multicast source mobility is transparently in Figure 2.) In this way, multicast source mobility is
enabled in PMIPv6 domains that deploy the base scenario for transparently enabled in PMIPv6 domains that deploy the base scenario
multicast. for multicast.
MN1 MAG1 MN2 MAG2 LMA MN1 MAG1 MN2 MAG2 LMA
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<---------------+ | | | |<---------------+ | |
| | Mcast Data | | | | | Mcast Data | | |
| Join(G) +================================================>| | Join(G) +================================================>|
+--------------> | | | | +--------------> | | | |
| Mcast Data | | | | | Mcast Data | | | |
|<---------------+ | | | |<---------------+ | | |
skipping to change at page 7, line 35 skipping to change at page 8, line 35
| | +-------------->| | | | +-------------->| |
| | | | Mcast Data | | | | | Mcast Data |
| | | +===============>| | | | +===============>|
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<================================================+ | |<================================================+
| Mcast Data | | | | | Mcast Data | | | |
|<---------------+ | | | |<---------------+ | | |
| | | | | | | | | |
Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP Legend: Rtr Sol - ICMPv6 Router Solicitation
Rtr Adv - ICMPv6 Router Advertisement
Figure 2: Call Flow for Group Communication in Multicast-Enabled PMIP
These multicast deployment considerations likewise apply for mobile These multicast deployment considerations likewise apply for mobile
nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. nodes that operate with their IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide IPv4 home address mobility support [RFC5844]. PMIPv6 can provide IPv4 home address mobility support [RFC5844].
IPv4 multicast is handled by an IGMP proxy function at the MAG in an IPv4 multicast is handled by an IGMP proxy function at the MAG in an
analogous way. analogous way.
Following these deployment steps, multicast traffic distribution Following these deployment steps, multicast traffic distribution
transparently inter-operates with PMIPv6. It is worth noting that an transparently interoperates with PMIPv6. It is worth noting that an
MN - while being attached to the same MAG as the mobile source, but MN -- while being attached to the same MAG as the mobile source, but
associated with a different LMA - cannot receive multicast traffic on associated with a different LMA -- cannot receive multicast traffic
a shortest path. Instead, multicast streams flow up to the LMA of 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 the mobile source, are transferred to the LMA of the mobile listener,
and tunneled downwards to the MAG again (see Section 5 for further and are tunneled downwards to the MAG again. (See Section 5 for
optimizations). further optimizations.)
3.2. Base Solution for Source Mobility: Details 3.2. Base Solution for Source Mobility: Details
A support of multicast source mobility in PMIPv6 requires to deploy Support of multicast source mobility in PMIPv6 requires that general
general multicast functions at PMIPv6 routers and to define their multicast functions be deployed at PMIPv6 routers and that their
interaction with the PMIPv6 protocol in the following way. interactions with the PMIPv6 protocol be defined as follows.
3.2.1. Operations of the Mobile Node 3.2.1. Operations of the Mobile Node
A Mobile Node willing to send multicast data will proceed as if A mobile node willing to send multicast data will proceed as if
attached to the fixed Internet. No specific mobility or other attached to the fixed Internet. No specific mobility or other
multicast related functionalities are required at the MN. multicast-related functionalities are required at the MN.
3.2.2. Operations of the Mobile Access Gateway 3.2.2. Operations of the Mobile Access Gateway
A Mobile Access Gateway is required to have MLD proxy instances A Mobile Access Gateway is required to have MLD proxy instances
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
transmission from an MN. It is advisable to take special care that transmission from an MN. It is advisable to take special care that
MLD proxy implementations do not redistribute multicast data to MLD proxy implementations do not redistribute multicast data to
skipping to change at page 8, line 47 skipping to change at page 10, line 7
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
PMIPv6 domain and thereby ensure a continuous receptivity while the PMIPv6 domain and thereby ensure a continuous receptivity while the
source is in motion. source is in motion.
3.2.3.1. Local Mobility Anchors Operating PIM 3.2.3.1. Local Mobility Anchors Operating PIM
Local Mobility Anchors that operate the PIM-SM routing protocol Local Mobility Anchors that operate the Protocol Independent
[RFC4601] will require sources to be directly connected for sending Multicast - Sparse Mode (PIM-SM) routing protocol [RFC4601] will
PIM registers to the RP. This does not hold in a PMIPv6 domain, as require sources to be directly connected for sending PIM registers to
MAGs are routers intermediate to MN and the LMA. In this sense, MNs the Rendezvous Point (RP). This does not hold in a PMIPv6 domain, as
are multicast sources external to the PIM-SM domain. MAGs are routers intermediate to the MN and the LMA. In this sense,
MNs are multicast sources external to the PIM-SM domain.
To mitigate this incompatibility common to all subsidiary MLD proxy To mitigate this incompatibility common to all subsidiary MLD proxy
domains, the LMA MUST act as a PIM Border Router and activate the domains, the LMA MUST act as a PIM Border Router and activate the
Border-bit. In this case, the DirectlyConnected(S) is treated as Border-bit. In this case, the DirectlyConnected(S) is treated as
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 not considered part of the PIM-SM
component of the LMA (see A.1 of [RFC4601] ). component of the LMA (see Appendix A.1 of [RFC4601] ).
In addition, an LMA serving as PIM Designated Router (DR) is In addition, an LMA serving as the 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
Reverse Path Forwarding (RPF) 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 the 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 Bidirectional PIM (BIDIR-PIM) [RFC5015] on LMAs
respect to source location and does not require special remains robust with respect to source location and does not require
configurations or state management for sources. special 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
IGMP. For multicast support on the network side, an IGMP proxy 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 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. [RFC4605] defines IGMP proxy behavior in full agreement with
IPv6/MLD. Thus IPv4 support can be transparently provided following IPv6/MLD. Thus, IPv4 support can be transparently provided following
the obvious deployment analogy. the obvious deployment analogy.
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
SHOULD choose multicast signaling according to address configurations SHOULD choose multicast signaling according to address configurations
on the link, but MAY submit IGMP and MLD queries in parallel, if on the link, but they MAY submit IGMP and MLD queries in parallel, if
needed. It should further be noted that the infrastructure cannot needed. It should further be noted that the infrastructure cannot
identify two data streams as identical when distributed via an IPv4 identify two data streams as identical when distributed via an IPv4
and IPv6 multicast group. Thus duplicate data may be forwarded on a and IPv6 multicast group. Thus, duplicate data may be forwarded on a
heterogeneous network layer. heterogeneous network layer.
A particular note is worth giving the scenario of [RFC5845] in which The following points are worth noting about the scenario in [RFC5845]
overlapping private address spaces of different operators can be in which overlapping private address spaces of different operators
hosted in a PMIP domain by using GRE encapsulation with key can be hosted in a PMIP domain by using Generic Routing Encapsulation
identification. This scenario implies that unicast communication in (GRE) with key identification. This scenario implies that unicast
the MAG-LMA tunnel can be individually identified per MN by the GRE communication in the MAG-LMA tunnel can be individually identified
keys. This scenario still does not impose any special treatment of per MN by the GRE keys. This scenario still does not impose any
multicast communication for the following reasons. special treatment of multicast communication for the following
reasons.
Multicast streams from and to MNs arrive at a MAG on point-to-point Multicast streams from and to MNs arrive at a MAG on point-to-point
links (identical to unicast). Multicast data transmission from the links (identical to unicast). Multicast data transmission from the
MAG to the corresponding LMA is link-local between the routers and MAG to the corresponding LMA is link-local between the routers and
routing/forwarding remains independent of any individual MN. So the routing/forwarding remains independent of any individual MN. So, the
MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain
GRE encapsulation in multicast communication (including MLD queries GRE in multicast communication (including MLD queries and reports).
and reports). Multicast traffic is transmitted as router-to-router Multicast traffic is transmitted using router-to-router forwarding
forwarding via the MAG-to-LMA tunnels and according to the multicast via the MAG-to-LMA tunnels and according to the MRIB of the MAG or
routing information base (MRIB) of the MAG or the LMA. It remains the LMA. It remains independent of MN's unicast addresses, while the
independent of MN's unicast addresses, while the MAG proxy instance MAG proxy instance redistributes multicast data down the point-to-
redistributes multicast data down the point-to-point links point links (interfaces) according to its local subscription states,
(interfaces) according to its local subscription states, independent independent of IP addresses of the MN.
of IP addresses of the MN.
3.2.5. Efficiency of the Distribution System 3.2.5. Efficiency of the Distribution System
The distribution system of the base solution directly follows PMIPv6 The distribution system of the base solution directly follows PMIPv6
routing rules, and organizes multicast domains with respect to LMAs. routing rules and organizes multicast domains with respect to LMAs.
Thus, no coordination between address spaces or services is required Thus, no coordination between address spaces or services is required
between the different instances, provided their associated LMAs between the different instances, provided their associated LMAs
belong to disjoint multicast domains. Routing is optimal for belong to disjoint multicast domains. Routing is optimal for
communication between MNs of the same domain, or stationary communication between MNs of the same domain or stationary
subscribers. subscribers.
In the following, efficiency-related issues remain. In the following situations, efficiency-related issues remain.
Multicast reception at LMA In the current deployment scenario, the Multicast reception at LMA
LMA will receive all multicast traffic originating from its In the current deployment scenario, the LMA will receive all
associated MNs. There is no mechanism to suppress upstream multicast traffic originating from its associated MNs. There is
forwarding in the absence of receivers. 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 MNs on the same MAG using different LMAs
source that use different LMAs, the traffic has to go up to one For a mobile receiver and a source that use different LMAs, the
LMA, cross over to the other LMA, and then be tunneled back to the traffic has to go up to one LMA, cross over to the other LMA, and
same MAG, causing redundant flows in the access network and at the then be tunneled back to the same MAG, causing redundant flows in
MAG. the access network and at the MAG.
These remaining deficits in routing efficiency can be resolved by These remaining deficits in routing efficiency can be resolved by
adding peering functions to MLD proxies as described in Section 5. 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 that 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
service access based on the multicast address G or the SSM channel service access based on the multicast address G or the source-
(S,G) under request (see Appendix A for further discussions). specific multicast (SSM) channel (S,G) under request. (See
Appendix A for further discussions.)
4.1. Overview 4.1. Overview
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
skipping to change at page 11, line 51 skipping to change at page 13, line 27
|| || || || * || 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 that
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.
Multicast traffic distribution can be simplified in these scenarios. Multicast traffic distribution can be simplified in these scenarios.
A single proxy instance at MAGs with up-link into the multicast A single proxy instance at MAGs with uplinks into the multicast
domain will serve as a first hop multicast gateway and avoid traffic domain will serve as a first-hop multicast gateway and avoid traffic
duplication or detour routing. Multicast routing functions at MAGs duplication or detour routing. Multicast routing functions at MAGs
will seamlessly embed access gateways within a multicast cloud. will seamlessly embed access gateways within a multicast cloud.
However, mobility of the multicast source in this scenario will However, mobility of the multicast source in this scenario will
require some multicast routing protocols to rebuild distribution require some multicast routing protocols to rebuild distribution
trees. This can cause significant service disruptions or delays (see trees. This can cause significant service disruptions or delays (see
[RFC5757] for further aspects). Deployment details are specific to [RFC5757] for further aspects). Deployment details are specific to
the multicast routing protocol in use, in the following described for the multicast routing protocol in use; this is described below for
common protocols. common protocols.
4.2. MLD Proxies at MAGs 4.2. MLD Proxies at MAGs
In a PMIPv6 domain, single MLD proxy instances can be deployed at In a PMIPv6 domain, single MLD proxy instances can be deployed at
each MAG that enable multicast service at the access via an uplink to each MAG that enable multicast service at the access via an uplink to
a multicast service infrastructure (see Figure 3 (a) ). To avoid a multicast service infrastructure (see Figure 3(a)). To avoid
service disruptions on handovers, the uplinks of all proxies SHOULD service disruptions on handovers, the uplinks of all proxies SHOULD
be adjacent to the same next-hop multicast router. This can either be adjacent to the same next-hop multicast router. This can either
be achieved by arranging proxies within a flat access network, or by be achieved by arranging proxies within a flat access network or by
upstream tunnels that terminate at a common multicast router. using upstream tunnels that terminate at a common multicast router.
Multicast data submitted by a mobile source will reach the MLD proxy Multicast data submitted by a mobile source will reach the MLD proxy
at the MAG that subsequently forwards flows to the upstream, and all at the MAG that subsequently forwards flows to the upstream and to
downstream interfaces with appropriate subscriptions. Traversing the all downstream interfaces with appropriate subscriptions. Traversing
upstream will transfer traffic into the multicast infrastructure the upstream will transfer traffic into the multicast infrastructure
(e.g., to a PIM Designated Router) which will route packets to all (e.g., to a PIM Designated Router) that will route packets to all
local MAGs that have joined the group, as well as further upstream local MAGs that have joined the group, as well as further upstream
according to protocol procedures and forwarding states. according to protocol procedures and forwarding states.
On handover, a mobile source will reattach to a new MAG and can On handover, a mobile source will reattach to a new MAG and can
continue to send multicast packets as soon as PMIPv6 unicast continue to send multicast packets as soon as PMIPv6 unicast
configurations have been completed. Like at the previous MAG, the configurations have been completed. Like at the previous MAG, the
new MLD proxy will forward data upstream and downstream to new MLD proxy will forward data upstream and downstream to
subscribers. Listeners local to the previous MAG will continue to subscribers. Listeners local to the previous MAG will continue to
receive group traffic via the local multicast distribution receive group traffic via the local multicast distribution
infrastructure following aggregated listener reports of the previous infrastructure following aggregated listener reports of the previous
skipping to change at page 13, line 12 skipping to change at page 14, line 36
source address and thus remains unchanged when seen from the wider source address and thus remains unchanged when seen from the wider
multicast infrastructure. multicast infrastructure.
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 3.2.3.1). This problem lead to an interim packet loss (see Section 3.2.3.1). This 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
unicast routes (see Figure 3 b). Throughout this section, it is unicast routes (see Figure 3(b)). Throughout this section, it is
assumed that the PMIPv6 mobility domain is part of a single PIM-SM assumed that the PMIPv6 mobility domain is part of a single PIM-SM
multicast routing domain with PIM-SM routing functions present at all multicast routing domain with PIM-SM routing functions present at all
MAGs and all LMAs. The PIM routing instance at a MAG SHALL then MAGs and all LMAs. The PIM routing instance at a MAG SHALL then
serve as the Designated Router (DR) for all directly attached Mobile serve as the Designated Router (DR) for all directly attached Mobile
Nodes. For expediting handover operations, it is advisable to Nodes. For expediting handover operations, it is advisable to
position PIM Rendezvous Points (RPs) in the core of the PMIPv6 position PIM Rendezvous Points (RPs) in the core of the PMIPv6
network domain. However, regular IP routing tables need not be network domain. However, regular IP routing tables need not be
present in a PMIPv6 deployment, and additional effort is required to present in a PMIPv6 deployment, and additional effort is required to
establish reverse path forwarding rules as required by PIM-SM. establish reverse path forwarding rules as required by PIM-SM.
skipping to change at page 14, line 10 skipping to change at page 15, line 39
following information is needed. following information is needed.
o All routes to networks and nodes (including RPs) that are not o All routes to networks and nodes (including RPs) that are not
mobile members of the PMIPv6 domain MUST be defined consistently mobile members of the PMIPv6 domain MUST be defined consistently
among PIM routers and MUST remain unaffected by node mobility. among PIM routers and MUST remain unaffected by node mobility.
The setup of these general routes is expected to follow the The setup of these general routes is expected to follow the
topology of the operator network and is beyond the scope of this topology of the operator network and is beyond the scope of this
document. document.
The following route entries are required at a PIM-operating MAG when The following route entries are required at a PIM-operating MAG when
phases two or three of PIM, or PIM-SSM are in operation. phase two or three of PIM or PIM-SSM is in operation.
o Local routes to the Home Network Prefixes (HNPs) of all MNs o Local routes to the Home Network Prefixes (HNPs) of all MNs
associated with their corresponding point-to-point attachments associated with their corresponding point-to-point attachments
that MUST be included in the local MRIB. that MUST be included in the local MRIB.
o All routes to MNs that are attached to distant MAGs of the PMIPv6 o All routes to MNs that are attached to distant MAGs of the PMIPv6
domain point towards their corresponding LMAs. These routes MUST domain point towards their corresponding LMAs. These routes MUST
be made available in the MRIB of all PIM routers (except for the be made available in the MRIB of all PIM routers (except for the
local MAG of attachment), but MAY be eventually expressed by an local MAG of attachment), but they MAY be eventually expressed by
appropriate default entry. an appropriate default entry.
4.3.2. Operations of PIM in Phase One (RP Tree) 4.3.2. Operations of PIM in Phase One (RP Tree)
A new mobile source S will transmit multicast data of group G towards A new mobile source S will transmit multicast data of group G towards
its MAG of attachment. Acting as a PIM DR, the access gateway will its MAG of attachment. Acting as a PIM DR, the access gateway will
unicast-encapsulate the multicast packets and forward the data to the unicast-encapsulate the multicast packets and forward the data to the
Virtual Interface (VI) with encapsulation target RP(G), a process Virtual Interface (VI) with encapsulation target RP(G), a process
known as PIM source registering. The RP will decapsulate and known as "PIM source registering". The RP will decapsulate and
natively forward the packets down the RP-based distribution tree natively forward the packets down the RP-based distribution tree
towards (mobile and stationary) subscribers. towards (mobile and stationary) subscribers.
On handover, the point-to-point link connecting the mobile source to On handover, the point-to-point link connecting the mobile source to
the old MAG will go down and all (S,*) flows terminate. In response, the old MAG will go down and all (S,*) flows terminate. In response,
the previous DR (MAG) deactivates the data encapsulation channels for the previous DR (MAG) deactivates the data encapsulation channels for
the transient source (i.e., all DownstreamJPState(S,*,VI) are set to the transient source (i.e., all DownstreamJPState(S,*,VI) are set to
NoInfo state). After reattaching and completing unicast handover NoInfo state). After reattaching and completing unicast handover
negotiations, the mobile source can continue to transmit multicast negotiations, the mobile source can continue to transmit multicast
packets, while being treated as a new source at its new DR (MAG). packets, while being treated as a new source at its new DR (MAG).
Source register encapsulation will be immediately initiated, and Source register encapsulation will be immediately initiated, and
(S,G) data continue to flow natively down the (*,G) RP-based tree. (S,G) data continue to flow natively down the (*,G) RP-based tree.
Source handover management in PIM phase one admits low complexity and Source handover management in PIM phase one admits low complexity and
remains transparent to receivers. In addition, the source register remains transparent to receivers. In addition, the source register
tunnel management of PIM is a fast protocol operation that introduces tunnel management of PIM is a fast protocol operation that introduces
little overhead. In a PMIPv6 deployment, PIM RPs MAY be configured little overhead. In a PMIPv6 deployment, PIM RPs MAY be configured
to not initiated (S,G) shortest path trees for mobile sources, and to uninitiated (S,G) shortest path trees for mobile sources, and thus
thus remain in phase one of the protocol. The price to pay for such remain in phase one of the protocol. The price to pay for such
simplified deployment lies in possible routing detours by an overall simplified deployment lies in possible routing detours by an overall
RP-based packet distribution. RP-based packet distribution.
4.3.3. Operations of PIM in Phase Two (Register-Stop) 4.3.3. Operations of PIM in Phase Two (Register-Stop)
After receiving source register packets, a PIM RP eventually will After receiving source register packets, a PIM RP eventually will
initiate a source-specific Join for creating a shortest path tree to initiate a source-specific Join for creating a shortest path tree to
the (mobile) source S, and issue a source register stop at the native the (mobile) source S and issue a source register stop at the native
arrival of data from S. For initiating an (S,G) tree, the RP, as well arrival of data from S. For initiating an (S,G) tree, the RP, as
as all intermediate routers, require route entries for the HNP of the well as all intermediate routers, require route entries for the HNP
MN that - unless the RP coincides with the MAG of S - point towards of the MN that -- unless the RP coincides with the MAG of S -- point
the corresponding LMA of S. Consequently, the (S,G) tree will proceed towards the corresponding LMA of S. Consequently, the (S,G) tree
from the RP via the (stable) LMA, down the LMA-MAG tunnel to the will proceed from the RP via the (stable) LMA, down the LMA-MAG
mobile source. This tree can be of lower routing efficiency than the tunnel to the mobile source. This tree can be of lower routing
PIM source register tunnel established in phase one. efficiency than the PIM source register tunnel established in phase
one.
On handover, the mobile source reattaches to a new MAG (DR), and On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one with the RP. In and initiate a source registering of PIM phase one with the RP. In
response, the PIM RP will recognize the known source at a new response, the PIM RP will recognize the known source at a new
(tunnel) interface and immediately responds with a register stop. As (tunnel) interface and will immediately respond with a register stop.
the RP had previously joined the shortest path tree towards the As the RP had previously joined the shortest path tree towards the
source via the LMA, it will see an RPF change when data arrives at a source via the LMA, it will see an RPF change when data arrives at a
new interface. Implementation-dependent, this can trigger an update new interface. This is implementation dependent and can trigger an
of the PIM MRIB and trigger a new PIM Join message that will install update of the PIM MRIB as well as a new PIM Join message that will
the multicast forwarding state missing at the new MAG. Otherwise, install the multicast forwarding state missing at the new MAG.
the tree is periodically updated by Joins transmitted towards the new Otherwise, the tree is periodically updated by Joins transmitted
MAG on a path via the LMA. In proceeding this way, a quick recovery towards the new MAG on a path via the LMA. In proceeding this way, a
of PIM transition from phase one to two will be performed per quick recovery of PIM transition from phase one to two will be
handover. performed per handover.
4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree) 4.3.4. Operations of PIM in Phase Three (Shortest-Path Tree)
In response to an exceeded threshold of packet transmission, DRs of In response to an exceeded threshold of packet transmission, DRs of
receivers eventually will initiate a source-specific Join for receivers eventually will initiate a source-specific Join for
creating a shortest path tree to the (mobile) source S, thereby creating a shortest path tree to the (mobile) source S, thereby
transitioning PIM into the final short-cut phase three. For all transitioning PIM into the final shortcut phase three. For all
receivers not sharing a MAG with S, this (S,G) tree will range from receivers not sharing a MAG with S, this (S,G) tree will range from
the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the
serving MAG to the mobile source. This tree is of higher routing serving MAG to the mobile source. This tree is of higher routing
efficiency than that established in the previous phase two, but need efficiency than that established in the previous phase two, but it
not outperform the PIM source register tunnel established in phase need not outperform the PIM source register tunnel established in
one. It provides the advantage of immediate data delivery to phase one. It provides the advantage of immediate data delivery to
receivers that share a MAG with S. receivers that share a MAG with S.
On handover, the mobile source reattaches to a new MAG (DR), and On handover, the mobile source reattaches to a new MAG (DR), and
PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new
point of attachment. However, in the absence of a corresponding point of attachment. However, in the absence of a corresponding
multicast forwarding state, the new DR will treat S as a new source multicast forwarding state, the new DR will treat S as a new source
and initiate a source registering of PIM phase one. A PIM and initiate a source registering of PIM phase one. A PIM
implementation compliant with this change can recover phase three implementation compliant with this change can recover phase three
states in the following way. First, the RP recovers to phase two as states in the following way. First, the RP recovers to phase two as
described in the previous section, and will not forward data arriving described in the previous section and will not forward data arriving
via the source register tunnel. Tree maintenance eventually via the source register tunnel. Tree maintenance eventually
triggered by the RPF change (see Section 4.3.3) will generate proper triggered by the RPF change (see Section 4.3.3) will generate proper
states for a native forwarding from the new MAG via the LMA. states for a native forwarding from the new MAG via the LMA.
Thereafter, packets arriving at the LMA without source register Thereafter, packets arriving at the LMA without source register
encapsulation are forwarded natively along the shortest path tree encapsulation are forwarded natively along the shortest path tree
towards receivers. towards receivers.
In consequence, the PIM transitions from phase one to two and to In consequence, the PIM transitions from phase one to two to three
three will be quickly recovered per handover, but still lead to an will be quickly recovered per handover but still lead to an enhanced
enhanced signaling load and intermediate packet loss. signaling load and intermediate packet loss.
4.3.5. PIM-SSM Considerations 4.3.5. PIM-SSM Considerations
Source-specific Joins of receivers will guide PIM to operate in SSM Source-specific Joins of receivers will guide PIM to operate in SSM
mode and lead to an immediate establishment of source-specific mode and lead to an immediate establishment of source-specific
shortest path trees. Such (S,G) trees will equal the distribution shortest path trees. Such (S,G) trees will equal the distribution
system of PIM's final phase three (see Section 4.3.4). However, on system of PIM's final phase three (see Section 4.3.4). However, on
handover and in the absence of RP-based data distribution, SSM data handover and in the absence of RP-based data distribution, SSM data
delivery cannot be resumed via source registering as in PIM phase delivery cannot be resumed via source registering as in PIM phase
one. Consequently, data packets transmitted after a handover will be one. Consequently, data packets transmitted after a handover will be
discarded at the MAG until regular tree maintenance has reestablished discarded at the MAG until regular tree maintenance has reestablished
the (S,G) forwarding state at the new MAG. the (S,G) forwarding state at the new MAG.
4.3.6. Handover Optimizations for PIM 4.3.6. Handover Optimizations for PIM
Source-specific shortest path trees are constructed in PIM-SM (phase Source-specific shortest path trees are constructed in PIM-SM (phase
two and three), and in PIM-SSM that follow LMA-MAG tunnels towards a two and three) and in PIM-SSM. These RPF-trees traverse LMA-MAG
source. As PIM remains unaware of source mobility management, these tunnels towards a source. As PIM remains unaware of source mobility
trees invalidate under handovers with each tunnel re-establishment at management, these trees invalidate under handovers with each tunnel
a new MAG. Regular tree maintenance of PIM will recover the states, re-establishment at a new MAG. Regular tree maintenance of PIM will
but remains unsynchronized and too slow to seamlessly preserve PIM recover the states, but it remains unsynchronized and too slow to
data distribution services. seamlessly preserve PIM data distribution services.
A method to quickly recover PIM (S,G) trees under handover SHOULD A method to quickly recover PIM (S,G) trees under handover SHOULD
synchronize multicast state maintenance with unicast handover synchronize multicast state maintenance with unicast handover
operations and can proceed as follows. On handover, an LMA reads all operations and can proceed as follows. On handover, an LMA reads all
(S,G) Join states from its corresponding tunnel interface and (S,G) Join states from its corresponding tunnel interface and
identifies those source addresses S_i that match moving HNPs. After identifies those source addresses S_i that match moving HNPs. After
re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join
states with the new tunnel endpoint and immediately trigger a state states with the new tunnel endpoint and immediately trigger a state
maintenance (PIM Join) message. In proceeding this way, the source- maintenance (PIM Join) message. In proceeding this way, the source-
specific PIM states are transferred to the new tunnel end point and specific PIM states are transferred to the new tunnel endpoint and
propagated to the new MAG in synchrony with unicast handover propagated to the new MAG in synchrony with unicast handover
procedures. procedures.
4.4. BIDIR-PIM 4.4. BIDIR-PIM
BIDIR-PIM MAY be deployed in the access network for providing BIDIR-PIM MAY be deployed in the access network for providing
multicast services in parallel to unicast routes. Throughout this multicast services in parallel to unicast routes. Throughout this
section, it is assumed that the PMIPv6 mobility domain is part of a section, it is assumed that the PMIPv6 mobility domain is part of a
single BIDIR-PIM multicast routing domain with BIDIR-PIM routing single BIDIR-PIM multicast routing domain with BIDIR-PIM routing
functions present at all MAGs and all LMAs. The PIM routing instance functions present at all MAGs and all LMAs. The PIM routing instance
skipping to change at page 17, line 45 skipping to change at page 19, line 30
BIDIR-PIM will establish spanning trees across its network domain in BIDIR-PIM will establish spanning trees across its network domain in
conformance to its pre-configured RPAs and the routing information conformance to its pre-configured RPAs and the routing information
provided. Multicast data transmitted by a mobile source will provided. Multicast data transmitted by a mobile source will
immediately be forwarded by its DF (MAG) onto the spanning tree for immediately be forwarded by its DF (MAG) onto the spanning tree for
the multicast group without further protocol operations. the multicast group without further protocol operations.
On handover, the mobile source reattaches to a new MAG (DF), which On handover, the mobile source reattaches to a new MAG (DF), which
completes unicast network configurations. Thereafter, the source can completes unicast network configurations. Thereafter, the source can
immediately proceed with multicast packet transmission onto the pre- immediately proceed with multicast packet transmission onto the pre-
established distribution tree. BIDIR-PIM does neither require established distribution tree. BIDIR-PIM does not require protocol
protocol signaling nor additional reconfiguration delays to adapt to signaling or additional reconfiguration delays to adapt to source
source mobility and can be considered the protocol of choice for mobility, and it can be considered the protocol of choice for mobile
mobile multicast operations in the access. As multicast streams multicast operations in the access network. As multicast streams
always flow up to the Rendezvous Point Link, some care should be always flow up to the Rendezvous Point Link, some care should be
taken to configure RPAs compliant with network capacities. taken to configure RPAs compliant with network capacities.
5. MLD Proxy Peering Function for Optimized Source Mobility in PMIPv6 5. MLD Proxy Peering Function for Optimized Source Mobility in PMIPv6
A deployment of MLD Proxies (see [RFC4605]) at MAGs has proven a A deployment of MLD proxies (see [RFC4605]) at MAGs has proven a
useful and appropriate approach to multicast in PMIPv6, see useful and appropriate approach to multicast in PMIPv6; see [RFC6224]
[RFC6224], [RFC7028]. However, deploying unmodified standard proxies and [RFC7028]. However, deploying unmodified standard proxies can go
can go along with significant performance degradation for mobile along with significant performance degradation for mobile senders as
senders as discussed along the lines of this document. To overcome discussed in this document. To overcome these deficits, an optimized
these deficits, an optimized approach to multicast source mobility approach to multicast source mobility based on extended peering
based on extended peering functions among proxies is defined in this functions among proxies is defined in this section. Based on such
section. Based on such direct data exchange between proxy instances direct data exchange between proxy instances at MAGs, triangular
at MAGs, triangular routing is avoided and multicast streams can be routing is avoided and multicast streams can be disseminated directly
disseminated directly within a PMIPv6 access network, and in within a PMIPv6 access network, and in particular within MAG routing
particular within MAG routing machines. Prior to presenting the machines. Prior to presenting the solution, we will summarize the
solution, we will summarize the relevant requirements. relevant requirements.
5.1. Requirements 5.1. Requirements
Solutions that extend MLD Proxies by additional uplinking functions Solutions that extend MLD proxies by additional uplinking functions
need to comply to the following requirements. need to comply to the following requirements.
Prevention of Routing Loops In the absence of a full-featured Prevention of routing loops
routing logic at an MLD Proxy, simple and locally decidable rules In the absence of a full-featured routing logic at an MLD proxy,
need to prevent source traffic from traversing the network in simple and locally decidable rules need to prevent source traffic
loops as potentially enabled by multiple uplinks. from traversing the network in loops that would be potentially
enabled by multiple uplinks.
Unique coverage of receivers Listener functions at Proxies require Unique coverage of receivers
simple, locally decidable rules to initiate a unique delivery of Listener functions at proxies require simple, locally decidable
multicast packets to all receivers. rules to initiate a unique delivery of multicast packets to all
receivers.
Following local filter techniques, these requirements are met in the Following local filtering techniques, these requirements are met in
following solution. the 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 --
any two proxy instances (locally deployed as in [RFC6224] or between any two proxy instances (locally deployed as in [RFC6224] or
remotely). Peerings remain as silent virtual links in regular proxy remotely deployed). Peerings remain as silent virtual links in
operations. Data is exchanged on such links only in cases, where one regular proxy operations. Data is exchanged on such links only in
peering proxy on its downstream directly connects to a source of cases where one peering proxy on its downstream directly connects to
multicast traffic, which the other peering proxy actively subscribes a source of multicast traffic to which the other peering proxy
to. In such cases, the proxy connected to the source will receive a actively subscribes. In such cases, the proxy connected to the
listener report on its peering interface and forwards traffic from source will receive a listener report on its peering interface and
its local source accordingly. It is worth noting that multicast will forward traffic from its local source accordingly. It is worth
traffic distribution on peering links does not follow reverse unicast noting that multicast traffic distribution on peering links does not
paths to sources. In the following, operations are defined for ASM follow reverse unicast paths to sources. In the following,
and SSM, but provide superior performance in the presence of source- operations are defined for Any-Source Multicast (ASM) and SSM, but
specific signaling (IGMPv3/MLDv2) [RFC4604]. they provide superior performance in the presence of source-specific
signaling (IGMPv3/MLDv2) [RFC4604].
5.3. Operations in Support of Multicast Senders 5.3. Operations in Support of Multicast Senders
An MLD proxy in the perspective of a sender will see peering An MLD proxy with 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 (e.g., due to mobility). Multicast packets configuration changes (e.g., due to mobility). Multicast packets
that arrive from the upstream interface of the proxy are thus that arrive from the upstream interface of the proxy are thus
prevented from traversing any peering link, but are only forwarded to prevented from traversing any peering link, but they are only
regular downstream interfaces with appropriate subscription states. forwarded to regular downstream interfaces with appropriate
In this way, a multihop forwarding on peering links is prevented. subscription states. In this way, 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 downstream
appropriate subscription states (i.e., regular proxy operations). In interfaces with appropriate subscription states (i.e., regular proxy
addition, multicast packets of local origin are transferred to those operations). In addition, multicast packets of local origin are
peering interfaces with appropriate subscription states. transferred to those peering interfaces with appropriate subscription
states.
5.4. Operations in Support of Multicast Listeners 5.4. Operations in Support of Multicast Listeners
At the listener side, peering interfaces appear as preferred upstream On the listener side, peering interfaces appear as preferred upstream
links. The multicast proxy will attempt to receive multicast links. The multicast proxy will attempt to receive multicast
services on peering links for as many groups (channels) as possible. services on peering links for as many groups (channels) as possible.
The general upstream interface configured according to [RFC4605] will The general upstream interface configured according to [RFC4605] will
be used only for retrieving 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 all of its peering links. These links span reports (in parallel) to all of its peering links. These links span
at most one (virtual) hop. Whenever certain group traffic (SSM at most one (virtual) hop. Whenever certain group traffic (SSM
channels) does not arrive from the peerings after a waiting time channels) does not arrive from the peerings after a waiting time
(default: 10 ms (node-local) and 25 ms (remote)), additional (default: 10 ms (node-local) and 25 ms (remote)), additional reports
(complementary, in the case of SSM) reports are sent to the standard (complementary reports, in the case of SSM) are sent to the standard
upstream interface. upstream interface.
Whenever traffic from a peering link arrives, 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 upstream interfaces (as described in
RFC 4605) in the following way.
ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using ASM with IGMPv2/MLDv1: In the presence of ASM using IGMPv2/MLDv1,
IGMPv2/MLDv1, only, the proxy cannot signal source filtering to only, the proxy cannot signal source filtering to its upstream.
its upstream. Correspondingly, it applies (S,*) ingress filters Correspondingly, it applies (S,*) ingress filters at its upstream
at its upstream interface for all sources S seen in traffic on the interface for all sources S seen in traffic on the peering links.
peering links. It is noteworthy that unwanted traffic is still It is noteworthy that unwanted traffic is still replicated to the
replicated to the proxy via the (wired) provider backbone, but it proxy via the (wired) provider backbone, but it is not forwarded
is not forwarded into the wireless access network. 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 MLD proxies will install data-driven timers (source-timeout) for each
source but common to all peering interfaces to detect interruptions source but common to all peering interfaces to detect interruptions
of data services from individual sources at proxy peers. Termination of data services from individual sources at proxy peers. Termination
of source-specific flows may be application-specific, but also due to of source-specific flows may be application specific, but also may be
a source handover, or transmission failures. After a handover, a due to a source handover or a transmission failure. After a
mobile source may reattach at another MLD proxy with peering relation handover, a mobile source may reattach at another MLD proxy with a
to the listener, or at a proxy that does not peer. While in the peering relation to the listener, or at a proxy that does not peer.
first case, traffic reappears on another peering link, in the second While in the first case, traffic reappears on another peering link;
case data can only be retrieved via the regular upstream. To account in the second case, data can only be retrieved via the regular
for the latter, the MLD proxy revokes the source-specific filter(s) upstream. To account for the latter, the MLD proxy revokes the
at its upstream interface, after the source-timeout fires (default: source-specific filter(s) at its upstream interface, after the
50 ms). Corresponding traffic will then be pulled from the regular source-timeout expires (default: 50 ms). Corresponding traffic will
upstream. Source-specific filters MUST be reinstalled, whenever then be pulled from the regular upstream interface. Source-specific
traffic of this source arrives at any peering interface. filters MUST be reinstalled whenever traffic of this source arrives
at any peering interface.
There is a noteworthy trade-off between traffic minimization and There is a noteworthy trade-off between traffic minimization and
available traffic at the upstream that is locally filtered at the available traffic at the upstream that is locally filtered at the
proxy. Implementors can use this relation to optimize for service- proxy. Implementors can use this relation to optimize for service-
specific requirements. 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. Security Considerations
This document makes no request to IANA..
Note to RFC Editor: this section may be removed on publication as an
RFC.
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 [RFC2236], [RFC2710], , [RFC3810], [RFC4605], as security concerns in [RFC2236], [RFC2710], [RFC3810], [RFC4605],
[RFC5213], and [RFC5844] are inherited by this document. [RFC5213], 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 arise 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
possibly high frequency. In addition to proper authorization checks possibly high frequency. In addition to proper authorization checks
of MNs, rate controls at routing agents and replicators may be needed of MNs, rate controls at routing agents and replicators may be needed
to protect the agents and the downstream networks. In particular, to protect the agents and the downstream networks. In particular,
MLD proxy implementations at MAGs SHOULD automatically extinct MLD proxy implementations at MAGs SHOULD automatically erase
multicast state on the departure of MNs, as mobile multicast multicast state on the departure of MNs, as mobile multicast
listeners in the PMIPv6 domain will in general not actively terminate listeners in the PMIPv6 domain will in general not actively terminate
group membership prior to departure. group membership prior to departure.
The deployment of IGMP/MLD proxies for multicast routing requires The deployment of IGMP/MLD proxies for multicast routing requires
particular care, as routing loops on the upstream are not particular care, as routing loops on the upstream are not
automatically detected. Peering functions between proxies extend automatically detected. Peering functions between proxies extend
this threat in the following way. Routing loops among peering and this threat in the following way. Routing loops among peering and
upstream interfaces are prevented by filters on local sources. Such upstream interfaces are prevented by filters on local sources. Such
filtering can fail, whenever prefix configurations for downstream filtering can fail whenever prefix configurations for downstream
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 keeping IP configurations consistent at the downstream in a care on keeping IP configurations consistent at the downstream in a
reliable and timely manner (see [RFC6224] for requirements on reliable and timely manner. (See [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies). PMIPv6-compliant implementations of MLD proxies.)
8. Acknowledgements 7. Acknowledgements
The authors would like to thank (in alphabetical order) David Black, The authors would like to thank (in alphabetical order) David Black,
Luis M. Contreras, Spencer Dawkins, Muhamma Omer Farooq, Bohao Feng, Luis M. Contreras, Spencer Dawkins, Muhamma Omer Farooq, Bohao Feng,
Sri Gundavelli, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li, Sri Gundavelli, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Li,
Cong Liu, Radia Perlman, Akbar Rahman, Behcet Sarikaya, Stig Venaas, Cong Liu, Radia Perlman, Akbar Rahman, Behcet Sarikaya, Stig Venaas,
Li-Li Wang, Sebastian Woelke, Qian Wu, Zhi-Wei Yan for advice, help Li-Li Wang, Sebastian Woelke, Qian Wu, and Zhi-Wei Yan for advice,
and reviews of the document. Funding by the German Federal Ministry help, and reviews of the document. Funding by the German Federal
of Education and Research within the G-LAB Initiative (projects Ministry of Education and Research within the G-LAB Initiative
HAMcast, Mindstone and SAFEST) is gratefully acknowledged. (projects HAMcast, Mindstone, and SAFEST) is gratefully acknowledged.
9. References 8. References
9.1. Normative References 8.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
1999. 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
skipping to change at page 22, line 40 skipping to change at page 24, line 29
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP Listener Discovery (MLD)-Based Multicast Forwarding
/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010. Mobile IPv6", RFC 5844, May 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
9.2. Informative References 8.2. Informative References
[I-D.ietf-multimob-fmipv6-pfmipv6-multicast]
Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and
D. Liu, "Multicast Listener Extensions for MIPv6 and
PMIPv6 Fast Handovers", draft-ietf-multimob-
fmipv6-pfmipv6-multicast-05 (work in progress), March
2014.
[I-D.ietf-multimob-handover-optimization] [MULTI-EXT]
Contreras, L., Bernardos, C., and I. Soto, "PMIPv6 Schmidt, T., Ed., Waehlisch, M., Koodli, R., Fairhurst,
multicast handover optimization by the Subscription G., and D. Liu, "Multicast Listener Extensions for MIPv6
Information Acquisition through the LMA (SIAL)", draft- and PMIPv6 Fast Handovers", Work in Progress, May 2014.
ietf-multimob-handover-optimization-07 (work in progress),
December 2013.
[Peering-Analysis] [PEERING-ANALYSIS]
Schmidt, TC., Woelke, S., and M. Waehlisch, "Peer my Proxy Schmidt, TC., Woelke, S., and M. Waehlisch, "Peer my Proxy
- A Performance Study of Peering Extensions for Multicast - A Performance Study of Peering Extensions for Multicast
in Proxy Mobile IP Domains", Proc. of 7th IFIP Wireless in Proxy Mobile IP Domains", Proc. of 7th IFIP Wireless
and Mobile Networking Conference (WMNC 2014) IEEEPress, and Mobile Networking Conference (WMNC 2014), IEEE Press,
May 2014. May 2014.
[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.
skipping to change at page 24, line 9 skipping to change at page 25, line 36
Mobile IPv6", RFC 5845, June 2010. Mobile IPv6", RFC 5845, June 2010.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011. IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013. Proxy Mobile IPv6", RFC 7028, September 2013.
[RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile
IPv6 (PMIPv6) Multicast Handover Optimization by the
Subscription Information Acquisition through the LMA
(SIAL)", RFC 7161, March 2014.
Appendix A. Multiple Upstream Interface Proxy Appendix A. Multiple Upstream Interface Proxy
In this section, we document upstream extensions for an MLD proxy In this section, we document upstream extensions for an MLD proxy
that were originally developed during the work on this document. that were originally developed during the work on this document.
Multiple proxy instances deployed at a single MAG (see Section 3) can Multiple proxy instances deployed at a single MAG (see Section 3) can
be avoided by adding multiple upstream interfaces to a single MLD be avoided by adding multiple upstream interfaces to a single MLD
Proxy. In a typical PMIPv6 deployment, each upstream of a single proxy. In a typical PMIPv6 deployment, each upstream interface of a
proxy instance can interconnect to one of the LMAs. With such single proxy instance can interconnect to one of the LMAs. With such
ambiguous upstream options, appropriate forwarding rules MUST be ambiguous upstream options, appropriate forwarding rules MUST be
supplied to supplied to
o unambiguously guide traffic forwarding from directly attached o unambiguously guide traffic forwarding from directly attached
mobile sources, and mobile sources, and
o lead listener reports to initiating unique traffic subscriptions. o lead listener reports to initiating unique traffic subscriptions.
This can be achieved by a complete set of source- and group-specific This can be achieved by a complete set of source- and group-specific
filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces.
These filters MAY be derived in parts from PMIPv6 routing policies, These filters MAY be derived in part from PMIPv6 routing policies and
and can include a default behavior (e.g., (*,*)). can include a default behavior (e.g., (*,*)).
A.1. Operations for Local Multicast Sources A.1. Operations for Local Multicast Sources
Packets from a locally attached multicast source will be forwarded to Packets from a locally attached multicast source will be forwarded to
all downstream interfaces with appropriate subscriptions, as well as all downstream interfaces with appropriate subscriptions, as well as
up the interface with the matching source-specific filter. up the interface with the matching source-specific filter.
Typically, the upstream interface for a mobile multicast source is Typically, the upstream interface for a mobile multicast source is
chosen based on the policy routing (e.g., the MAG-LMA tunnel chosen based on the policy routing (e.g., the MAG-LMA tunnel
interface for LMA-based routing or the interface towards the interface for LMA-based routing or the interface towards the
multicast router for direct routing), but alternate configurations multicast router for direct routing), but alternate configurations
MAY be applied. Packets from a locally attached multicast source MAY be applied. Packets from a locally attached multicast source
will be forwarded to the corresponding upstream interface with the will be forwarded to the corresponding upstream interface with the
matching source-specific filter, as well as all the downstream matching source-specific filter, as well as all the downstream
interfaces with appropriate subscriptions. interfaces with appropriate subscriptions.
A.2. Operations for Local Multicast Subscribers A.2. Operations for Local Multicast Subscribers
Multicast listener reports are group-wise aggregated by the MLD Multicast listener reports are group-wise aggregated by the MLD
proxy. The aggregated report is issued to the upstream interface proxy. The aggregated report is issued to the upstream interface
with matching group/channel-specific filter. The choice of the with a matching group/channel-specific filter. The choice of the
corresponding upstream interface for aggregated group membership corresponding upstream interface for aggregated group membership
reports MAY be additionally based on some administrative scoping reports MAY be additionally based on some administrative scoping
rules for scoped multicast group addresses. rules for scoped multicast group addresses.
In detail, a Multiple Upstream Interface proxy will provide and In detail, a Multiple Upstream Interface proxy will provide and
maintain a Multicast Subscription Filter Table that maps source- and maintain a Multicast Subscription Filter Table that maps source- and
group-specific filters to upstream interfaces. The forwarding group-specific filters to upstream interfaces. The forwarding
decision for an aggregated MLD listener report is based on the first decision for an aggregated MLD listener report is based on the first
matching entry from this table, with the understanding that for matching entry from this table, with the understanding that for
IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed
(i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the
presence of (*,G) after (S,G) interface entries), and that presence of (*,G) after (S,G) interface entries), and that
(S,*)-filters are always false in the absence of source-specific (S,*)-filters are always false in the absence of source-specific
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, are either
while a (*,*) default subscription entry (in the last table line) is
bound to a local routing interface, or selected groups are configured o associated with selected uplinks to remote LMAs, while a (*,*)
as local services first, while a (*,*) default entry (in the last default subscription entry (in the last table line) is bound to a
table line) points to a remote uplink that provides the general local routing interface, or
multicast support.
o configured as local services first, while a (*,*) default entry
(in the last table line) points to a remote uplink that provides
the general multicast support.
Appendix B. Implementation Appendix B. Implementation
An implementation of the extended IGMP/MLD proxy has been provided An implementation of the extended IGMP/MLD proxy has been provided
within the MCPROXY project http://mcproxy.realmv6.org/. This open within the MCPROXY project (http://mcproxy.realmv6.org/). This open-
source software is written in C++ and uses forwarding capabilities of source software is written in C++ and uses forwarding capabilities of
the Linux kernel. It supports all regular operations according to the Linux kernel. It supports all regular operations according to
[RFC4605], allows for multiple proxy instances on one node, [RFC4605] and allows for multiple proxy instances on one node,
dynamically changing downstream links, as well as proxy-to-proxy dynamically changing downstream links, proxy-to-proxy peerings, and
peerings and multiple upstream links with individual configurations. multiple upstream links with individual configurations. The software
The software can be downloaded from Github at https://github.com/ can be downloaded from GitHub at
mcproxy/mcproxy. Based on this software, an experimental performance <https://github.com/mcproxy/mcproxy>. Based on this software, an
evaluation of the proxy peering function has been reported in experimental performance evaluation of the proxy peering function has
[Peering-Analysis]. been reported in [PEERING-ANALYSIS].
Authors' Addresses Authors' Addresses
Thomas C. Schmidt (editor) Thomas C. Schmidt (editor)
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg 20099 Hamburg 20099
Germany Germany
Email: schmidt@informatik.haw-hamburg.de EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Shuai Gao Shuai Gao
Beijing Jiaotong University Beijing Jiaotong University
Beijing Beijing
China China
Email: shgao@bjtu.edu.cn EMail: shgao@bjtu.edu.cn
Hong-Ke Zhang Hong-Ke Zhang
Beijing Jiaotong University Beijing Jiaotong University
Beijing Beijing
China China
Email: hkzhang@bjtu.edu.cn EMail: hkzhang@bjtu.edu.cn
Matthias Waehlisch Matthias Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
Hoenower Str. 35 Hoenower Str. 35
Berlin 10318 Berlin 10318
Germany Germany
Email: mw@link-lab.net EMail: mw@link-lab.net
 End of changes. 124 change blocks. 
369 lines changed or deleted 373 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/