draft-ietf-multimob-pmipv6-source-01.txt   draft-ietf-multimob-pmipv6-source-02.txt 
MULTIMOB Group T C. Schmidt, Ed. MULTIMOB Group T C. Schmidt, Ed.
Internet-Draft HAW Hamburg Internet-Draft HAW Hamburg
Intended status: Standards Track S. Gao Intended status: Standards Track S. Gao
Expires: January 17, 2013 H. Zhang Expires: April 25, 2013 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
July 16, 2012 October 22, 2012
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-01 draft-ietf-multimob-pmipv6-source-02
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 extended optimizations for synchronizing PMIPv6 with PIM, as well as extended
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 17, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 18 skipping to change at page 3, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 5 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Base Solution for Source Mobility: Details . . . . . . . . 9 3.2. Base Solution for Source Mobility: Details . . . . . . . . 9
3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9
3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9
3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9
3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Efficiency of the Distribution System . . . . . . . . 11 3.2.5. Efficiency of the Distribution System . . . . . . . . 11
4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 11 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 13 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 14 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 14
4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 14 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 15
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 15 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 16
4.3.4. Operations of PIM in Phase Three . . . . . . . . . . . 16 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . . 16
4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 16 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 17
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 16 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 17
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 17 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 18
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 18
5. Extended MLD Proxy Functions for Optimized Source Mobility 5. Extended MLD Proxy Functions for Optimized Source Mobility
in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 18 5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 19
5.1.1. Operations for Local Multicast Sources . . . . . . . . 19 5.1.1. Operations for Local Multicast Sources . . . . . . . . 19
5.1.2. Operations for Local Multicast Subscribers . . . . . . 19 5.1.2. Operations for Local Multicast Subscribers . . . . . . 20
5.2. Peering Function for MLD Proxies . . . . . . . . . . . . . 19 5.2. Peering Function for MLD Proxies . . . . . . . . . . . . . 20
5.2.1. Operations at the Multicast Sender . . . . . . . . . . 19 5.2.1. Operations at the Multicast Sender . . . . . . . . . . 20
5.2.2. Operations at the Multicast Listener . . . . . . . . . 20 5.2.2. Operations at the Multicast Listener . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 23 Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 the
Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are
responsible for managing IP mobility on behalf of the mobile node responsible for managing IP mobility on behalf of the mobile node
(MN). An MN connected to a PMIPv6 domain, which only operates (MN). An MN connected to a PMIPv6 domain, which only operates
skipping to change at page 8, line 22 skipping to change at page 8, line 22
| Mcast Data | | | | | Mcast Data | | | |
|<---------------+ | | | |<---------------+ | | |
| | | | | | | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > | | < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | | | | | | |
| | |--- Rtr Sol -->| | | | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| | | | |<-- Rtr Adv ---| |
| | | | | | | | | |
| | | < MLD Proxy Configuration > | | | | < MLD Proxy Configuration > |
| | | | | | | | | |
| | | MLD Query | | | | | (MLD Query) | |
| | |<--------------+ | | | |<--------------+ |
| | | Mcast Data | | | | | Mcast Data | |
| | +-------------->| | | | +-------------->| |
| | | | Mcast Data | | | | | Mcast Data |
| | | +===============>| | | | +===============>|
| | | | | | | | | |
| | Mcast Data | | | | | Mcast Data | | |
| |<================================================+ | |<================================================+
| Mcast Data | | | | | Mcast Data | | | |
|<---------------+ | | | |<---------------+ | | |
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 should act as a PIM Border Router and activate the domains, the LMA should 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
MLD proxies via individual IP-tunnel interfaces and will experience
changing PIM source states on handover. As the incoming interface
connects to a point-to-point link, PIM Assert contention is not
active, and incoming interface validation is only performed by RPF
checks. Consequently, a PIM DR should update incoming source states,
as soon as RPF inspection succeeds, i.e., after PMIPv6 forwarding
state update. Consequently, PIM routers SHOULD be able to manage
these state changes, but some 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 a special respect to source location and does not require special
configuration. 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
skipping to change at page 11, line 13 skipping to change at page 11, line 24
and reports). Multicast traffic sent upstream and downstream of MAG- and reports). Multicast traffic sent upstream and downstream of MAG-
to-LMA tunnels proceeds as router-to-router forwarding according to to-LMA tunnels proceeds as router-to-router forwarding according to
the multicast routing information base (MRIB) of the MAG or LMA and the multicast routing information base (MRIB) of the MAG or LMA and
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 re-distributes multicast data down the point-to-point links
(interfaces) according to its own MRIB, independent of MN's IP (interfaces) according to its own MRIB, independent of MN's IP
addresses. addresses.
3.2.5. Efficiency of the Distribution System 3.2.5. Efficiency of the Distribution System
In the following efficiency-related issues are enumerated. The distribution system of the base solution directly follows PMIPv6
routing rules, and organizes multicast domains with respect to LMAs.
Thus, no coordination between address spaces or services is required
between the different instances, provided their associated LMAs
belong to disjoint multicast domains. Routing is optimal for
communication between MNs of the same domain, or stationary
subscribers.
In the following efficiency-related issues remain.
Multicast reception at LMA In the current deployment scenario, the Multicast reception at LMA In the current deployment scenario, the
LMA will receive all multicast traffic originating from its LMA will receive all multicast traffic originating from its
associated MNs. There is no mechanism to suppress upstream associated MNs. There is no mechanism to suppress upstream
forwarding in the absence of receivers. forwarding in the absence of receivers.
MNs on the same MAG using different LMAs For a mobile receiver and a MNs on the same MAG using different LMAs For a mobile receiver and a
source that use different LMAs, the traffic has to go up to one source that use different LMAs, the traffic has to go up to one
LMA, cross over to the other LMA, and then be tunneled back to the LMA, cross over to the other LMA, and then be tunneled back to the
same MAG, causing redundant flows in the access network and at the same MAG, causing redundant flows in the access network and at the
skipping to change at page 12, line 33 skipping to change at page 13, line 4
MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3 MN1 MN2 MN3
(a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG
Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast
Access and (b) Dynamic Multicast Routing at MAGs Access and (b) Dynamic Multicast Routing at MAGs
Figure 3 displays the corresponding deployment scenarios, which Figure 3 displays the corresponding deployment scenarios, which
separate multicast from PMIPv6 unicast routing. It is assumed separate multicast from PMIPv6 unicast routing. It is assumed
throughout these scenarios that all MAGs (MLD proxies) are linked to throughout these scenarios that all MAGs (MLD proxies) are linked to
a single multicast routing domain. a single multicast routing domain. Noteworthy, this scenario
requires 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 up-link 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
skipping to change at page 13, line 35 skipping to change at page 14, line 13
unchanged when seen from the wider multicast infrastructure. 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. This problem can be mitigated by aggregating states on handover. In some implementations of PIM-SM this could
proxies on a lower layer. lead to interim packet loss (see Section Section 3.2.3.1). This
problem 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 4.3. PIM-SM
skipping to change at page 15, line 18 skipping to change at page 15, line 44
the transient source (e.g., all DownstreamJPState(S,*,VI) are set to the transient source (e.g., 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 and little tunnel management of PIM is a fast protocol operation and little
overhead can be expected thereof. In a PMIPv6 deployment, PIM RPs overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be
MAY be configured to not initiated (S,G) shortest path tress for configured to not initiated (S,G) shortest path tress for mobile
mobile sources, and thus remain in phase one of the protocol. The sources, and thus remain in phase one of the protocol. The price to
price to pay for such simplified deployment lies in possible routing pay for such simplified deployment lies in possible routing detours
detours by an overall RP-based packet distribution even in those by an overall RP-based packet distribution.
cases, where mobile senders and receivers are attached to the same
access router.
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
initiated a source-specific Join for creating a shortest path tree to initiated 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 MN's HNP that as all intermediate routers, require route entries for MN's HNP that
- unless the RP coincides with the MAG of S - point towards the - unless the RP coincides with the MAG of S - point towards the
corresponding LMA of S. Consequently, the (S,G) tree will proceed corresponding LMA of S. Consequently, the (S,G) tree will proceed
skipping to change at page 18, line 17 skipping to change at page 18, line 42
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 Functions for Optimized Source Mobility in PMIPv6 5. Extended MLD Proxy Functions 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, unmodified [RFC6224], [I-D.ietf-multimob-pmipv6-ropt]. However, unmodified
standard solutions go along with significant performance degradation standard solutions can go along with significant performance
for mobile senders as discussed along the lines of this document. To degradation for mobile senders as discussed along the lines of this
overcome these deficits, optimizing approaches to multicast source document. To overcome these deficits, optimizing approaches to
mobility are introduced in this section. In particular, uplink multicast source mobility are introduced in this section. In
capabilities of MLD proxies are extended to allow for rapid, particular, uplink capabilities of MLD proxies are extended to allow
optimized multicast traffic flows from mobile sources. for rapid, optimized multicast traffic flows from mobile sources.
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 for all receivers. multicast packets to all receivers.
Following different techniques, these requirements are met in the Following different techniques, these requirements are met in the
following solutions. following solutions.
5.1. Multiple Upstream Interface Proxy 5.1. Multiple Upstream Interface Proxy
In this section, we define upstream extensions for an MLD proxy. In this section, we define upstream extensions for an MLD proxy.
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 one of the LMAs. With such ambiguous proxy instance can interconnect to one of the LMAs. With such
upstream options, appropriate forwarding rules MUST be supplied to ambiguous upstream options, appropriate forwarding rules MUST be
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 parts from PMIPv6 routing policies,
and can include a default behavior (e.g., (*,*)). and can include a default behavior (e.g., (*,*)).
TODO details
5.1.1. Operations for Local Multicast Sources 5.1.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.
TODO details Typically, the upstream interface for a mobile multicast source is
chosen based on the policy routing (e.g., the MAG-LMA tunnel
interface for LMA-based routing or the interface towards the
multicast router for direct routing), but alternate configuriations
MAY be applied. Packets from a locally attached multicast source
will be forwarded to the corresponding upstream interface with the
matching source-specific filter, as well as all the downstream
interfaces with appropriate subscriptions.
5.1.2. Operations for Local Multicast Subscribers 5.1.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-specific filter. with matching group/channel-specific filter. The choice of the
corresponding upstream interface for aggregated group membership
reports MAY be additionally based on some administrative scoping
rules for scoped multicast group addresses.
TODO details In detail, a Multiple Upstream Interface Proxy will provide and
maintain a Multicast Subscription Filter Table that maps source- and
group-specific filters to upstream interfaces. The forwarding
decision for an aggregated MLD listener report is based on the first
matching entry from this table, with the understanding that for
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
presence of (*,G) after (S,G) interface entries), and that
(S,*)-filters are always false in the absence of source-specific
signaling, i.e. in IGMPv2/MLDv1 only domains.
In typical deployment scenarios, specific group services (channels)
could be either associated with selected uplinks to remote LMAs,
while a (*,*) default subscription entry (in the last table line) is
bound to a local routing interface, or selected groups are 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.
5.2. Peering Function for MLD Proxies 5.2. Peering Function for MLD Proxies
In this section, we define a peering interface for MLD proxies that In this section, we define a peering interface for MLD proxies that
allows for a direct data exchange of locally attached multicast allows for a direct data exchange of locally attached multicast
sources. Such peering interfaces can be configured - as a direct sources. Such peering interfaces can be configured - as a direct
link or a bidirectional tunnel - between any two proxy instances link or a bidirectional tunnel - between any two proxy instances
(locally deployed as in [RFC6224] or remotely) and remains a silent (locally deployed as in [RFC6224] or remotely) and remain as silent
virtual link in regular proxy operations. Data on such link is virtual links in regular proxy operations. Data on such link is
exchanged only in cases, where one peering proxy connects to a source exchanged only in cases, where one peering proxy directly connects on
of multicast traffic, which the other peering proxy actively the downstream to a source of multicast traffic, which the other
subscribes to. Operations are defined for ASM and SSM, but provide peering proxy actively subscribes to. Operations are defined for ASM
superior performance in SSM mode. and SSM, but provide superior performance in the presence of source-
specific signaling (IGMPv3/MLDv2).
5.2.1. Operations at the Multicast Sender 5.2.1. Operations at the Multicast Sender
An MLD Proxy with peering interfaces will install and maintain source An MLD Proxy in the perspective of a sender will see peering
filters at its peering links that will restrict data transmission to interfaces as restricted downstream interfaces. It will install and
those packets that originate from a locally attached source. In this maintain source filters at its peering links that will restrict data
way, a multihop forwarding on peering links is prevented. Multicast transmission to those packets that originate from a locally attached
packets that arrive from the upstream interface of the Proxy are thus source at the downstream. In detail, a proxy will extract from its
be forwarded only to regular downstream interfaces with appropriate configuration the network prefixes attached to its downstream
interfaces and MUST implement a source filter base at its peering
interfaces that restricts data transmission to IP source addresses
from its local prefixes. This filter base Must be updated, if and
only if the downstream configuration changes. In this way, a
multihop forwarding on peering links is prevented. Multicast packets
that arrive from the upstream interface of the proxy are thus only
forwarded to regular downstream interfaces with appropriate
subscription states. subscription states.
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, local multicast packets are transferred to those peering
interfaces with appropriate subscription states. As seen from the interfaces with appropriate subscription states.
sender side, peering interfaces act as restricted downstream
interfaces.
5.2.2. Operations at the Multicast Listener 5.2.2. 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. Thus an MLD proxy with peering interconnects will
provide several interfaces for pulling remote traffic: the regular offer several interfaces for pulling remote traffic: the regular
upstream and the peerings. Traffic arriving from any of the peering upstream and the peerings. Traffic arriving from any of the peering
links will normally also be available from the upstream. To prevent links will be mutually disjoint, but normally also available from the
duplicate traffic from arriving at the listener side, the Proxy 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, it first issues listener reports (in parallel) to its
peering links, which are only one (virtual) hop apart. Whenever the peering links, which only span one (virtual) hop. Whenever the
expected traffic (e.g., SSM channels) does not completely arrive from expected traffic (e.g., SSM channels) does not completely arrive from
the peerings after a waiting time (default: 10 ms), additional the peerings after a waiting time (default: 10 ms), additional
(complementary, in the case of SSM) reports are sent to the standard (complementary, in the case of SSM) reports are sent to the standard
upstream interface. 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 the upstream in the following way.
ASM In the presence of Any Source Multicast (IGMPv2/MLDv1), only, ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using
the Proxy cannot signal source filtering to its upstream. IGMPv2/MLDv1, only, the proxy cannot signal source filtering to
Correspondingly, it applies (S,*) ingress filters at its upstream its upstream. Correspondingly, it applies (S,*) ingress filters
interface. It is noteworthy that unwanted traffic is still at its upstream interface for all sources S seen in traffic of the
peering links. It is noteworthy that unwanted traffic is still
replicated to the proxy via the access network. replicated to the proxy via the access network.
SSM In the presence of source-specific signaling (IGMPv3/MLDv2), the ASM with IGMPv3/MLDv2 In the presence of source-specific signaling
upstream interface is set to (S,*) exclude mode for all sources S (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude
seen in traffic of the peering links. The corresponding source- mode for all sources S seen in traffic of the peering links. The
specific signaling will prevent duplicate traffic forwarding corresponding source-specific signaling will prevent duplicate
throughout the access network. traffic forwarding throughout the access network.
SSM In the presence of Source Specific Multicast, the proxy will
subscribe on its uplink interface to those (S,G) channels, only,
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 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. TODO.
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
skipping to change at page 21, line 37 skipping to change at page 23, line 7
capacities. In addition to proper authorization checks of MNs, rate capacities. In addition to proper authorization checks of MNs, rate
controls at replicators MAY be required to protect the agents and the controls at replicators MAY be required to protect the agents and the
downstream networks. In particular, MLD proxy implementations at downstream networks. In particular, MLD proxy implementations at
MAGs SHOULD carefully procure for automatic multicast state MAGs SHOULD carefully procure for automatic multicast state
extinction on the departure of MNs, as mobile multicast listeners in extinction on the departure of MNs, as mobile multicast listeners in
the PMIPv6 domain will not actively terminate group membership prior the PMIPv6 domain will not actively terminate group membership prior
to departure. to departure.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Muhamma Omer The authors would like to thank (in alphabetical order) Luis M.
Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong,
Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for Jouni Korhonen, He-Wu Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian
advice, help and reviews of the document. Funding by the German Wu, Zhi-Wei Yan for advice, help and reviews of the document.
Federal Ministry of Education and Research within the G-LAB Funding by the German Federal Ministry of Education and Research
Initiative (project HAMcast) is gratefully acknowledged. within the G-LAB Initiative (project HAMcast) 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, Listener Discovery (MLD) for IPv6", RFC 2710,
skipping to change at page 22, line 43 skipping to change at page 24, line 13
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-pmipv6-ropt]
Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y.
Kim, "Multicast Mobility Routing Optimizations for Proxy Kim, "Multicast Mobility Routing Optimizations for Proxy
Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-00 (work in Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-01 (work in
progress), March 2012. progress), September 2012.
[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.
[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
skipping to change at page 23, line 20 skipping to change at page 24, line 38
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.
Appendix A. Evaluation of Traffic Flows Appendix A. Evaluation of Traffic Flows
TODO TODO
Appendix B. Change Log Appendix B. Change Log
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-source-01:
1. Added clarifications and details as requested be the working
group, resolved nits.
2. Detailed out operations of Multiple Upstream MLD Proxies.
3. Clarified operations of MLD proxies with peering links.
4. Many editorial improvements.
5. Updated references.
The following changes have been made from version
draft-ietf-multimob-pmipv6-source-00: draft-ietf-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.
 End of changes. 35 change blocks. 
94 lines changed or deleted 167 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/