draft-ietf-multimob-pmipv6-source-04.txt   draft-ietf-multimob-pmipv6-source-05.txt 
MULTIMOB Group T. Schmidt, Ed. MULTIMOB Group T. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao Intended status: Experimental S. Gao
Expires: January 14, 2014 H. Zhang Expires: April 03, 2014 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
July 13, 2013 September 30, 2013
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-04 draft-ietf-multimob-pmipv6-source-05
Abstract Abstract
Multicast communication can be enabled in Proxy Mobile IPv6 domains Multicast communication can be enabled in Proxy Mobile IPv6 domains
via the Local Mobility Anchors by deploying MLD Proxy functions at via the Local Mobility Anchors by deploying MLD proxy functions at
Mobile Access Gateways, via a direct traffic distribution within an Mobile Access Gateways, via a direct traffic distribution within an
ISP's access network, or by selective route optimization schemes. ISP's access network, or by selective route optimization schemes.
This document describes the support of mobile multicast senders in This document describes the support of mobile multicast senders in
Proxy Mobile IPv6 domains for all three scenarios. Protocol Proxy Mobile IPv6 domains for all three scenarios. Protocol
optimizations for synchronizing PMIPv6 with PIM, as well as a peering optimizations for synchronizing PMIPv6 with PIM, as well as a peering
function for MLD Proxies defined. Mobile sources always remain function for MLD Proxies are defined. Mobile sources always remain
agnostic of multicast mobility operations. agnostic of multicast mobility operations.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2014. This Internet-Draft will expire on April 03, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Base Solution for Source Mobility: Details . . . . . . . 7 3.2. Base Solution for Source Mobility: Details . . . . . . . 7
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 7 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 7
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 7 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 7
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 7 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 8 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Efficiency of the Distribution System . . . . . . . . 9 3.2.5. Efficiency of the Distribution System . . . . . . . . 10
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 10 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 12 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 12
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 12 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 12
4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 12 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 12 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13
4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 13 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 14
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 14 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 14
4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 14 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 15
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 15 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 15 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 16 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 16 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17
5. Extended MLD Proxy Function for Optimized Source Mobility in 5. MLD Proxy Peering Function for Optimized Source Mobility in
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Peering Function for MLD Proxies . . . . . . . . . . . . 17 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18
5.1.1. Operations at the Multicast Sender . . . . . . . . . 18 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Operations at the Multicast Listener . . . . . . . . 18 5.3. Operations at the Multicast Sender . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5.4. Operations at the Multicast Listener . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
A.1. Operations for Local Multicast Sources . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
A.2. Operations for Local Multicast Subscribers . . . . . . . 22 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 23
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 A.1. Operations for Local Multicast Sources . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Operations for Local Multicast Subscribers . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6)
[RFC6275] by network-based management functions that enable IP [RFC6275] by network-based management functions that enable IP
mobility for a host without requiring its participation in any mobility for a host without requiring its participation in any
mobility-related signaling. Additional network entities called the mobility-related signaling. Additional network entities called the
Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are
responsible for managing IP mobility on behalf of the mobile node responsible for managing IP mobility on behalf of the mobile node
(MN). An MN connected to a PMIPv6 domain, which only operates (MN). An MN connected to a PMIPv6 domain, which only operates
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, or by selective multicast routing at the access gateways directly
route optimization schemes. Such approaches (partially) follow the [I-D.ietf-multimob-fmipv6-pfmipv6-multicast], or by selective route
business model of providing multicast data services in parallel to optimization schemes [RFC7028]. Such approaches (partially) follow
PMIPv6 unicast routing. the business model of providing multicast data services in parallel
to PMIPv6 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 enfold 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 subsequently for the base deployment
scenario [RFC6224], for direct traffic distribution within an ISP's scenario [RFC6224], for direct traffic distribution within an ISP's
access network, as well as for selective route optimization schemes. access network, as well as for selective route optimization schemes.
skipping to change at page 5, line 15 skipping to change at page 5, line 25
|MAG1| |MAG2| MLD Proxy |MAG1| |MAG2| MLD Proxy
+----+ +----+ +----+ +----+
| | | | | |
MN-HNP1 | | MN-HNP2 | MN-HNP3 MN-HNP1 | | MN-HNP2 | MN-HNP3
| | | | | |
MN1 MN2 MN3 MN1 MN2 MN3
Multicast Sender + Listener(s) Multicast Sender + Listener(s)
Figure 1: Reference Network for Multicast Deployment in PMIPv6 with Figure 1: Reference Network for Multicast Deployment in PMIPv6 with
Source Mobility Source Mobility - Mobile Nodes (MNs) with Home Network Prefixes
(HNPs) receive services via tunnels that are spanned between a Local
Mobiity Anchor Address (LMAA) and a Proxy Care-of-Address (Proxy-CoA)
at a Mobility Access Gateway (MAG)
An MN in a PMIPv6 domain will decide on multicast data transmission An MN in a PMIPv6 domain will decide on multicast data transmission
completely independent of its current mobility conditions. It will completely independent of its current mobility conditions. It will
send packets as initiated by applications, using its source address send packets as initiated by applications, using its source address
with Home Network Prefix (HNP) and a multicast destination address with Home Network Prefix (HNP) and a multicast destination address
chosen by application needs. Multicast packets will arrive at the chosen by application needs. Multicast packets will arrive at the
currently active MAG via one of its downstream local (wireless) currently active MAG via one of its downstream local (wireless)
links. A multicast unaware MAG would simply discard these packets in links. A multicast unaware MAG would simply discard these packets in
the absence of a multicast routing information base (MRIB). the absence of instructions for packet processing, i.e., a multicast
routing information base (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 set-up, 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 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 (unaware of IP mobility) can continue In case of a handover, the MN (being unaware of IP mobility) can
to send multicast packets as soon as network connectivity is continue to send multicast packets as soon as network connectivity is
reconfigured. At this time, the MAG has determined the corresponding re-established. At this time, the MAG has determined the
LMA, and IPv6 unicast address configuration (including PMIPv6 corresponding LMA, and IPv6 unicast address configuration (including
bindings) has been completed. Still multicast packets arriving at PMIPv6 bindings) has been completed. Still multicast packets
the MAG are discarded (if not buffered) until the MAG has completed arriving at the MAG are discarded (if not buffered) until the MAG has
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 up-link 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 in
skipping to change at page 8, line 27 skipping to change at page 8, line 40
are multicast sources external to the PIM-SM domain. 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 considered as not part of the PIM-SM
component of the LMA (see A.1 of [RFC4601] ). component of the LMA (see A.1 of [RFC4601] ).
In addition, an LMA serving as PIM Designated Router is connected to In addition, an LMA serving as PIM Designated Router (DR) is
MLD proxies via individual IP-tunnel interfaces and will experience connected to MLD proxies via individual IP-tunnel interfaces and will
changing PIM source states on handover. As the incoming interface experience changing PIM source states on handover. As the incoming
connects to a point-to-point link, PIM Assert contention is not interface connects to a point-to-point link, PIM Assert contention is
active, and incoming interface validation is only performed by RPF not active, and incoming interface validation is only performed by
checks. Consequently, a PIM DR SHOULD update incoming source states, RPF (Reverse Path Forwarding) checks. Consequently, a PIM DR SHOULD
as soon as RPF inspection succeeds, i.e., after PMIPv6 forwarding update incoming source states, as soon as RPF inspection succeeds,
state update. Consequently, PIM routers SHOULD be able to manage i.e., after PMIPv6 forwarding state update. Consequently, PIM
these state changes, but some implementations are expected to routers SHOULD be able to manage these state changes, but some
incorrectly refuse packets until the previous state has timed out. implementations are expected to incorrectly refuse packets until the
previous state has timed out.
Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
respect to source location and does not require special respect to source location and does not require special
configurations or state management for sources. configurations or state management for sources.
3.2.4. IPv4 Support 3.2.4. IPv4 Support
An MN in a PMIPv6 domain may use an IPv4 address transparently for An MN in a PMIPv6 domain may use an IPv4 address transparently for
communication as specified in [RFC5844]. For this purpose, an LMA communication as specified in [RFC5844]. For this purpose, an LMA
can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can
skipping to change at page 9, line 33 skipping to change at page 9, line 48
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 encapsulation in multicast communication (including MLD queries
and reports). Multicast traffic is transmitted as router-to-router and reports). Multicast traffic is transmitted as router-to-router
forwarding via the MAG-to-LMA tunnels and according to the multicast forwarding via the MAG-to-LMA tunnels and according to the multicast
routing information base (MRIB) of the MAG or the LMA. It remains routing information base (MRIB) of the MAG or the LMA. It remains
independent of MN's unicast addresses, while the MAG proxy instance independent of MN's unicast addresses, while the MAG proxy instance
re-distributes multicast data down the point-to-point links redistributes multicast data down the point-to-point links
(interfaces) according to its local subscription states, independent (interfaces) according to its local subscription states, 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
skipping to change at page 10, line 20 skipping to change at page 10, line 32
MNs on the same MAG using different LMAs For a mobile receiver and a MNs on the same MAG using different LMAs For a mobile receiver and a
source that use different LMAs, the traffic has to go up to one source that use different LMAs, the traffic has to go up to one
LMA, cross over to the other LMA, and then be tunneled back to the LMA, cross over to the other LMA, and then be tunneled back to the
same MAG, causing redundant flows in the access network and at the same MAG, causing redundant flows in the access network and at the
MAG. MAG.
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 [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the routing system [RFC7028]. In these cases, the visited networks grant
visited networks grant a local content distribution service (in a local content distribution service (in contrast to LMA-based home
contrast to LMA-based home subscription) with locally optimized subscription) with locally optimized traffic flows. It is also
traffic flows. It is also possible to deploy a mixed service model possible to deploy a mixed service model of local and LMA-based
of local and LMA-based subscriptions, provided a unique way of subscriptions, provided a unique way of service selection is
service selection is implemented. For example, access routers (MAGs) implemented. For example, access routers (MAGs) could decide on
could decide on service access based on the multicast address G or service access based on the multicast address G or the SSM channel
the SSM channel (S,G) under request (see Appendix A for further (S,G) under request (see Appendix A for further discussions).
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 48 skipping to change at page 12, line 18
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. 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 all
downstream interfaces with appropriate subscriptions. Traversing the downstream interfaces with appropriate subscriptions. Traversing the
upstream will lead traffic into the multicast infrastructure (e.g., upstream will transfer traffic into the multicast infrastructure
to a PIM Designated Router) which will route packets to all local (e.g., to a PIM Designated Router) which will route packets to all
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 completed. Like at the previous MAG, the new MLD configurations have been completed. Like at the previous MAG, the
proxy will forward data upstream and downstream to subscribers. new MLD proxy will forward data upstream and downstream to
Listeners local to the previous MAG will continue to receive group subscribers. Listeners local to the previous MAG will continue to
traffic via the local multicast distribution infrastructure following receive group traffic via the local multicast distribution
aggregated listener reports of the previous proxy. In general, infrastructure following aggregated listener reports of the previous
traffic from the mobile source continues to be transmitted via the proxy. In general, traffic from the mobile source continues to be
same next-hop router using the same source address and thus remains transmitted via the same next-hop multicast router using the same
unchanged when seen from the wider multicast infrastructure. source address and thus remains unchanged when seen from the wider
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
skipping to change at page 12, line 40 skipping to change at page 13, line 14
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. Throughout this section, it is assumed that the unicast routes (see Figure 3 b). Throughout this section, it is
PMIPv6 mobility domain is part of a single PIM-SM multicast routing assumed that the PMIPv6 mobility domain is part of a single PIM-SM
domain with PIM-SM routing functions present at all MAGs and all multicast routing domain with PIM-SM routing functions present at all
LMAs. The PIM routing instance at a MAG SHALL then serve as the MAGs and all LMAs. The PIM routing instance at a MAG SHALL then
Designated Router (DR) for all directly attached Mobile Nodes. For serve as the Designated Router (DR) for all directly attached Mobile
expediting handover operations, it is advisable to position PIM Nodes. For expediting handover operations, it is advisable to
Rendezvous Points (RPs) in the core of the PMIPv6 network domain. position PIM Rendezvous Points (RPs) in the core of the PMIPv6
However, regular IP routing tables need not be present in a PMIPv6 network domain. However, regular IP routing tables need not be
deployment, and additional effort is required to establish reverse present in a PMIPv6 deployment, and additional effort is required to
path forwarding rules as required by PIM-SM. establish reverse path forwarding rules as required by PIM-SM.
4.3.1. Routing Information Base for PIM-SM 4.3.1. Routing Information Base for PIM-SM
In this scenario, PIM-SM will rely on a Multicast Routing Information In this scenario, PIM-SM will rely on a Multicast Routing Information
Base (MRIB) that is generated independently of the policy-based Base (MRIB) that is generated independently of the policy-based
routing rules of PMIPv6. The granularity of mobility-related routing routing rules of PMIPv6. The granularity of mobility-related routing
locators required in PIM depends on the complexity (phases) of its locators required in PIM depends on the complexity (phases) of its
deployment. deployment.
The following information is needed for all phases of PIM. The following information is needed for all three phases of PIM as
defined in [RFC4601].
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 uneffected 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. phases two or three of PIM, or PIM-SSM are 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.
skipping to change at page 14, line 9 skipping to change at page 14, line 32
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 and little tunnel management of PIM is a fast protocol operation and little
overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be
configured to not initiated (S,G) shortest path tress for mobile configured to not initiated (S,G) shortest path trees for mobile
sources, and thus remain in phase one of the protocol. The price to sources, and thus remain in phase one of the protocol. The price to
pay for such simplified deployment lies in possible routing detours pay for such simplified deployment lies in possible routing detours
by an overall RP-based packet distribution. by an overall RP-based packet distribution.
4.3.3. Operations of PIM in Phase Two 4.3.3. Operations of PIM in Phase Two
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 well
as all intermediate routers, require route entries for the HNP of the as all intermediate routers, require route entries for the HNP of the
MN that - unless the RP coincides with the MAG of S - point towards MN that - unless the RP coincides with the MAG of S - point towards
the corresponding LMA of S. Consequently, the (S,G) tree will proceed the corresponding LMA of S. Consequently, the (S,G) tree will proceed
from the RP via the (stable) LMA, down the LMA-MAG tunnel to the from the RP via the (stable) LMA, down the LMA-MAG tunnel to the
mobile source. This tree can be of lesser routing efficiency than mobile source. This tree can be of lower routing efficiency than the
the PIM source register tunnel established in phase one, but provides PIM source register tunnel established in phase one, but provides the
the advantage of immediate data delivery to receivers that share a advantage of immediate data delivery to receivers that share a MAG
MAG with S. 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 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 immediately responds with a register stop. As the (tunnel) interface and immediately responds with a register stop. As
RP had joined the shortest path tree to receive from the source via the RP had previously joined the shortest path tree towards the
the LMA, it will see an RPF change when data arrives at a new source via the LMA, it will see an RPF change when data arrives at a
interface. Implementation-dependent, this can trigger an update of new interface. Implementation-dependent, this can trigger an update
the PIM MRIB and trigger a new PIM Join message. Otherwise, the tree of the PIM MRIB and trigger a new PIM Join message that will install
is periodically updated by Joins transmitted towards the new MAG on a the multicast forwarding state missing at the new MAG. Otherwise,
path via the LMA. In proceeding this way, a quick recovery of PIM the tree is periodically updated by Joins transmitted towards the new
transition from phase one to two will be performed per handover. MAG on a path via the LMA. In proceeding this way, a quick recovery
of PIM transition from phase one to two will be performed per
handover.
4.3.4. Operations of PIM in Phase Three 4.3.4. Operations of PIM in Phase Three
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 initiated 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 short-cut 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 to the the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the
mobile source. This tree is of higher routing efficiency than serving MAG to the mobile source. This tree is of higher routing
established in the previous phase two, but need not outperform the efficiency than that established in the previous phase two, but need
PIM source register tunnel established in phase one. It provides the not outperform the PIM source register tunnel established in phase
advantage of immediate data delivery to receivers that share a MAG one. It provides the advantage of immediate data delivery to
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 mainenance eventually triggered via the source register tunnel. Tree maintenance eventually
by the RPF change (see Section 4.3.3) will generate proper states for triggered by the RPF change (see Section 4.3.3) will generate proper
a native forwarding from the new MAG via the LMA. Thereafter, states for a native forwarding from the new MAG via the LMA.
packets arriving at the LMA without source register encapsulation are Thereafter, packets arriving at the LMA without source register
forwarded natively along the shortest path tree towards receivers. encapsulation are forwarded natively along the shortest path tree
towards receivers.
In consequence, the PIM transition from phase one to two and three In consequence, the PIM transitions from phase one to two and to
will be quickly recovered per handover, but still leads to an three will be quickly recovered per handover, but still lead to an
enhanced signaling load and intermediate packet loss. enhanced 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 re- discarded at the MAG until regular tree maintenance has reestablished
established 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 that follow LMA-MAG tunnels towards a
source. As PIM remains unaware of source mobility management, these source. As PIM remains unaware of source mobility management, these
trees invalidate under handovers with each tunnel re-establishment at trees invalidate under handovers with each tunnel re-establishment at
a new MAG. Regular tree maintenance of PIM will recover the states, a new MAG. Regular tree maintenance of PIM will recover the states,
but remains unsynchronized and too slow to seamlessly preserve PIM but remains unsynchronized and too slow to seamlessly preserve PIM
data dissemination. 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 MAY 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 end point 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
skipping to change at page 16, line 37 skipping to change at page 17, line 18
4.4.1. Routing Information Base for BIDIR-PIM 4.4.1. Routing Information Base for BIDIR-PIM
In this scenario, BIDIR-PIM will rely on a Multicast Routing In this scenario, BIDIR-PIM will rely on a Multicast Routing
Information Base (MRIB) that is generated independently of the Information Base (MRIB) that is generated independently of the
policy-based routing rules of PMIPv6. The following information is policy-based routing rules of PMIPv6. The following information is
needed. needed.
o All routes to networks and nodes (including RPAs) that are not o All routes to networks and nodes (including RPAs) that are not
mobile members of the PMIPv6 domain MUST be defined consistently mobile members of the PMIPv6 domain MUST be defined consistently
among BIDIR-PIM routers and remain uneffected by node mobility. among BIDIR-PIM routers and 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.
4.4.2. Operations of BIDIR-PIM 4.4.2. Operations of BIDIR-PIM
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 preconfigured 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 group tree immediately be forwarded by its DF (MAG) onto the spanning tree for
without further protocol operations. the multicast group without further protocol operations.
On handover, the mobile source re-attaches 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 neither require
protocol signaling nor additional reconfiguration delays to adapt to protocol signaling nor additional reconfiguration delays to adapt to
source mobility and can be considered the protocol of choice for source mobility and can be considered the protocol of choice for
mobile multicast operations in the access. As multicast streams mobile multicast operations in the access. 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. Extended MLD Proxy 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], [I-D.ietf-multimob-pmipv6-ropt]. However, deploying [RFC6224], [RFC7028]. However, deploying unmodified standard proxies
unmodified standard proxies can go along with significant performance can go along with significant performance degradation for mobile
degradation for mobile senders as discussed along the lines of this senders as discussed along the lines of this document. To overcome
document. To overcome these deficits, an optimized approach to these deficits, an optimized approach to multicast source mobility
multicast source mobility based on extended peering functions among based on extended peering functions among proxies is defined in this
proxies is introduced in this section. Prior to presenting the section. Based on such direct data exchange between proxy instances
solution, we will sketch the relevant requirements. at MAGs, triangular routing is avoided and multicast streams can be
disseminated directly within a PMIPv6 access network, and in
particular within MAG routing machines. Prior to presenting the
solution, we will summarize the relevant 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 In the absence of a full-featured
routing logic at an MLD Proxy, simple and locally decidable rules routing logic at an MLD Proxy, simple and locally decidable rules
need to prevent source traffic from traversing the network in need to prevent source traffic from traversing the network in
loops as potentially enabled by multiple uplinks. loops as potentially enabled by multiple uplinks.
Unique coverage of receivers Listener functions at Proxies require Unique coverage of receivers Listener functions at Proxies require
simple, locally decidable rules to initiate a unique delivery of simple, locally decidable rules to initiate a unique delivery of
multicast packets to all receivers. multicast packets to all receivers.
Following different techniques, these requirements are met in the Following local filter techniques, these requirements are met in the
following solutions. following solution.
5.1. Peering Function for MLD Proxies 5.2. Overview
In this section, we define a peering interface for MLD proxies that A peering interface for MLD proxies allows for a direct data exchange
allows for a direct data exchange of locally attached multicast of locally attached multicast sources. Such peering interfaces can
sources. Such peering interfaces can be configured - as a direct be configured - as a direct link or a bidirectional tunnel - between
link or a bidirectional tunnel - between any two proxy instances any two proxy instances (locally deployed as in [RFC6224] or
(locally deployed as in [RFC6224] or remotely) and remain as silent remotely). Peerings remain as silent virtual links in regular proxy
virtual links in regular proxy operations. Data on such link is operations. Data is exchanged on such links only in cases, where one
exchanged only in cases, where one peering proxy directly connects on peering proxy directly connects on the downstream to a source of
the downstream to a source of multicast traffic, which the other multicast traffic, which the other peering proxy actively subscribes
peering proxy actively subscribes to. Operations are defined for ASM to. In such cases, the source-connected proxy will receive a
listener report on its peering interface and forwards traffic from
its local source accordingly. It is worth noting that multicast
traffic distribution on peering links does not follow reverse unicast
paths to sources. In the following, operations are defined for ASM
and SSM, but provide superior performance in the presence of source- and SSM, but provide superior performance in the presence of source-
specific signaling (IGMPv3/MLDv2). specific signaling (IGMPv3/MLDv2) [RFC4604].
5.1.1. Operations at the Multicast Sender 5.3. Operations at the Multicast Sender
An MLD Proxy in the perspective of a sender will see peering An MLD proxy in the perspective of a sender will see peering
interfaces as restricted downstream interfaces. It will install and interfaces as restricted downstream interfaces. It will install and
maintain source filters at its peering links that will restrict data maintain source filters at its peering links that will restrict data
transmission to those packets that originate from a locally attached transmission to those packets that originate from a source that is
source at the downstream. In detail, a proxy will extract from its locally attached at one of its downstream interfaces.
configuration the network prefixes attached to its downstream
interfaces and MUST implement a source filter base at its peering In detail, a proxy will extract from its configuration the network
interfaces that restricts data transmission to IP source addresses prefixes attached to its downstream interfaces and MUST implement a
from its local prefixes. This filter base Must be updated, if and source filter base at its peering interfaces that restricts data
only if the downstream configuration changes. In this way, a transmission to IP source addresses from its local prefixes. This
multihop forwarding on peering links is prevented. Multicast packets filter base MUST be updated, if and only if the downstream
that arrive from the upstream interface of the proxy are thus only configuration changes. Multicast packets that arrive from the
forwarded to regular downstream interfaces with appropriate upstream interface of the proxy are thus prevented from traversing
subscription states. any peering link, but are only forwarded to regular downstream
interfaces with appropriate subscription states. In this way, a
multihop forwarding on peering links is prevented.
Multicast traffic arriving from a locally attached source will be Multicast traffic arriving from a locally attached source will be
forwarded to the regular upstream interface and all downstreams with forwarded to the regular upstream interface and all downstreams with
appropriate subscription states (i.e., regular Proxy operations). In appropriate subscription states (i.e., regular proxy operations). In
addition, local multicast packets are transferred to those peering addition, multicast packets of local origin are transferred to those
interfaces with appropriate subscription states. peering interfaces with appropriate subscription states.
5.1.2. Operations at the Multicast Listener 5.4. Operations at the Multicast Listener
From the listener side, peering interfaces appear as preferred From the listener side, peering interfaces appear as preferred
upstream links. Thus an MLD proxy with peering interconnects will upstream links. The multicast proxy will attempt to subscribe to
offer several interfaces for pulling remote traffic: the regular multicast services on peering links for as many groups (channels) as
upstream and the peerings. Traffic arriving from any of the peering possible. The general upstream interface configured according to
links will be mutually disjoint, but normally also available from the [RFC4605] will be used only for those groups (channels) that remain
upstream. To prevent duplicate traffic from arriving at the listener unavailable from peerings. From this extension of [RFC4605], an MLD
side, the proxy proxy with peering interconnects will exhibit several interfaces for
pulling remote traffic: the regular upstream and the peerings.
Traffic available from any of the peering links will be mutually
disjoint, but normally also available from the upstream. To prevent
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, it first issues listener reports (in parallel) to its In detail, an MLD proxy instance at a MAG first issues listener
peering links, which only span one (virtual) hop. Whenever the reports (in parallel) to its peering links. These links only span
expected traffic (e.g., SSM channels) does not completely arrive from one (virtual) hop. Whenever certain group traffic (SSM channels)
the peerings after a waiting time (default: 10 ms), additional does not arrive from the peerings after a waiting time (default: 10
(complementary, in the case of SSM) reports are sent to the standard ms), additional (complementary, in the case of SSM) reports are sent
upstream interface. to the standard upstream interface.
After the arrival of traffic from peering links, an MLD proxy MUST After the arrival of traffic from peering links, an MLD proxy MUST
install source filters at the upstream in the following way. install source filters at its RFC 4605 upstream in the following way.
ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using
IGMPv2/MLDv1, only, the proxy cannot signal source filtering to IGMPv2/MLDv1, only, the proxy cannot signal source filtering to
its upstream. Correspondingly, it applies (S,*) ingress filters its upstream. Correspondingly, it applies (S,*) ingress filters
at its upstream interface for all sources S seen in traffic of the at its upstream interface for all sources S seen in traffic on the
peering links. It is noteworthy that unwanted traffic is still peering links. It is noteworthy that unwanted traffic is still
replicated to the proxy via the access network. replicated to the proxy via the (wired) provider backbone, but not
forwarded into the wireless access network.
ASM with IGMPv3/MLDv2 In the presence of source-specific signaling ASM with IGMPv3/MLDv2 In the presence of source-specific signaling
(IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude
mode for all sources S seen in traffic of the peering links. The mode for all sources S seen in traffic of the peering links. The
corresponding source-specific signaling will prevent duplicate corresponding source-specific signaling will prevent forwarding of
traffic forwarding 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.
In proceeding this way, multicast group data arrive from peering In proceeding this way, multicast group data will arrive from peering
interfaces first, while only peer-wise unavailable traffic is interfaces first, while only peer-wise unavailable traffic is
retrieved from the regular upstream interface. retrieved from the regular upstream interface.
6. IANA Considerations 6. IANA Considerations
TODO. This document makes no request to IANA..
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
TODO This document defines multicast sender mobility based on PMIPv6 and
common multicast routing protocols. Consequently, threats identified
Consequently, no new threats are introduced by this document in as security concerns of [RFC3810], [RFC4605], [RFC5213], and
addition to those identified as security concerns of [RFC3810], [RFC5844] are inherited by this document.
[RFC4605], [RFC5213], and [RFC5844].
However, particular attention should be paid to implications of In addition, particular attention should be paid to implications of
combining multicast and mobility management at network entities. As combining multicast and mobility management at network entities. As
this specification allows mobile nodes to initiate the creation of this specification allows mobile nodes to initiate the creation of
multicast forwarding states at MAGs and LMAs while changing multicast forwarding states at MAGs and LMAs while changing
attachments, threats of resource exhaustion at PMIP routers and attachments, threats of resource exhaustion at PMIP routers and
access networks arrive from rapid state changes, as well as from high access networks arrive from rapid state changes, as well as from high
volume data streams routed into access networks of limited volume data streams routed into access networks of limited
capacities. In addition to proper authorization checks of MNs, rate capacities. In cases of PIM-SM deployment, handover operations of
controls at replicators MAY be required to protect the agents and the the MNs include re-registering sources at the Rendezvous Points at
downstream networks. In particular, MLD proxy implementations at possibly high frequency. In addition to proper authorization checks
MAGs SHOULD carefully procure for automatic multicast state of MNs, rate controls at routing agents and replicators MAY be
extinction on the departure of MNs, as mobile multicast listeners in required to protect the agents and the downstream networks. In
the PMIPv6 domain will not actively terminate group membership prior particular, MLD proxy implementations at MAGs SHOULD carefully
to departure. procure for automatic multicast state extinction on the departure of
MNs, as mobile multicast listeners in the PMIPv6 domain will in
general not actively terminate group membership prior to departure.
The deployment of IGMP/MLD proxies for multicast routing requires
particular care, as routing loops on the upstream are not
automatically detected. Peering functions between proxies extend
this threat in the following way. Routing loops among peering and
upstream interfaces are prevented by filters on local sources. Such
filtering can fail, whenever prefix configurations for downstream
interfaces at a proxy are incorrect or inconsistent. Consequently,
implementations of peering-enabled proxies SHOULD take particular
care on maintaining (varying) IP configurations at the downstream in
a reliable and timely manner (see [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies).
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Luis M. The authors would like to thank (in alphabetical order) Luis M.
Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong,
Jouni Korhonen, He-Wu Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Jouni Korhonen, He-Wu Li, Cong Liu, Akbar Rahman, Stig Venaas, Li-Li
Wu, Zhi-Wei Yan for advice, help and reviews of the document. Wang, Qian Wu, Zhi-Wei Yan for advice, help and reviews of the
Funding by the German Federal Ministry of Education and Research document. Funding by the German Federal Ministry of Education and
within the G-LAB Initiative (projects HAMcast, Mindstone and SAFEST) Research within the G-LAB Initiative (projects HAMcast, Mindstone and
is gratefully acknowledged. SAFEST) is gratefully acknowledged.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
skipping to change at page 21, line 13 skipping to change at page 22, line 40
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 9.2. Informative References
[I-D.ietf-multimob-pmipv6-ropt] [I-D.ietf-multimob-fmipv6-pfmipv6-multicast]
Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and
Kim, "Multicast Mobility Routing Optimizations for Proxy D. Liu, "Multicast Listener Extensions for MIPv6 and
Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-07 (work in PMIPv6 Fast Handovers", draft-ietf-multimob-
progress), July 2013. fmipv6-pfmipv6-multicast-01 (work in progress), February
2013.
[I-D.ietf-multimob-handover-optimization]
Contreras, L., Bernardos, C., and I. Soto, "PMIPv6
multicast handover optimization by the Subscription
Information Acquisition through the LMA (SIAL)", draft-
ietf-multimob-handover-optimization-04 (work in progress),
September 2013.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in Mobile IP Version 6 (MIPv6): Problem Statement Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
and Brief Survey", RFC 5757, February 2010. and Brief Survey", RFC 5757, February 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy "Generic Routing Encapsulation (GRE) Key Option for Proxy
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
Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013.
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 of a single
proxy instance can interconnect to one of the LMAs. With such 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
skipping to change at page 22, line 11 skipping to change at page 24, line 4
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 parts from PMIPv6 routing policies,
and can include a default behavior (e.g., (*,*)). and 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 configuriations 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 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, could be either associated with selected uplinks to remote LMAs,
while a (*,*) default subscription entry (in the last table line) is while a (*,*) default subscription entry (in the last table line) is
bound to a local routing interface, or selected groups are configured bound to a local routing interface, or selected groups are configured
as local services first, while a (*,*) default entry (in the last as local services first, while a (*,*) default entry (in the last
table line) points to a remote uplink that provides the general table line) points to a remote uplink that provides the general
multicast support. multicast support.
Appendix B. Change Log Appendix B. Change Log
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-04:
1. Cleaned structure in Section Section 5.
2. Clarified operations of the proxy peering function.
3. Completed Section on Security Considerations.
4. Editorial improvements in response to WG feedback.
5. Updated and extended references.
The following changes have been made from version draft-ietf-
multimob-pmipv6-source-03: multimob-pmipv6-source-03:
1. Fixed issues in Section Section 4.3 (PIM phase two and three 1. Fixed issues in Section Section 4.3 (PIM phase two and three
transistion) according to WG feedback. transition) according to WG feedback.
2. Editorial improvements, resolved nits. 2. Editorial improvements, resolved nits.
3. Updated references. 3. Updated references.
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-02: multimob-pmipv6-source-02:
1. Added clarifications and details as requested by the working 1. Added clarifications and details as requested by the working
group, resolved nits. group, resolved nits.
2. Moved Multiple Upstream MLD Proxy to Appendix in response to WG 2. Moved Multiple Upstream MLD proxy to Appendix in response to WG
desire. desire.
3. Updated references. 3. Updated references.
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-01: multimob-pmipv6-source-01:
1. Added clarifications and details as requested by the working 1. Added clarifications and details as requested by the working
group, resolved nits. group, resolved nits.
skipping to change at page 23, line 51 skipping to change at page 26, line 9
The following changes have been made from version draft-ietf- The following changes have been made from version draft-ietf-
multimob-pmipv6-source-00: multimob-pmipv6-source-00:
1. Direct routing with PIM-SM and PIM-SSM has been added. 1. Direct routing with PIM-SM and PIM-SSM has been added.
2. PMIP synchronization with PIM added for improved handover. 2. PMIP synchronization with PIM added for improved handover.
3. Direct routing with BIDIR-PIM has been added. 3. Direct routing with BIDIR-PIM has been added.
4. MLD Proxy extensions requirements added. 4. MLD proxy extensions requirements added.
5. Peering of MLD Proxies added. 5. Peering of MLD Proxies added.
6. First sketch of multiple upstream proxy added. 6. First sketch of multiple upstream proxy added.
7. Editorial improvements. 7. Editorial improvements.
8. Updated references. 8. Updated references.
Authors' Addresses Authors' Addresses
 End of changes. 76 change blocks. 
216 lines changed or deleted 287 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/