draft-ietf-multimob-pmipv6-source-02.txt   draft-ietf-multimob-pmipv6-source-03.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: April 25, 2013 H. Zhang Expires: August 29, 2013 H. Zhang
Beijing Jiaotong University Beijing Jiaotong University
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
October 22, 2012 February 25, 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-02 draft-ietf-multimob-pmipv6-source-03
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 April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 13
4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 14
4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 14 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 14
4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . 15 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 15
4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . 17 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 17
4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 17 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 17
4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 18 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 18
4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 18 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 18
5. Extended MLD Proxy Functions for Optimized Source Mobility 5. Extended MLD Proxy Function for Optimized Source Mobility
in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 19 5.1. Peering Function for MLD Proxies . . . . . . . . . . . . . 19
5.1.1. Operations for Local Multicast Sources . . . . . . . . 19 5.1.1. Operations at the Multicast Sender . . . . . . . . . . 19
5.1.2. Operations for Local Multicast Subscribers . . . . . . 20 5.1.2. Operations at the Multicast Listener . . . . . . . . . 20
5.2. Peering Function for MLD Proxies . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Operations at the Multicast Sender . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.2.2. Operations at the Multicast Listener . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 A.1. Operations for Local Multicast Sources . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 A.2. Operations for Local Multicast Subscribers . . . . . . . . 24
Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 24 Appendix B. Evaluation of Traffic Flows . . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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, or by selective
route optimization schemes. Such approaches (partially) follow the route optimization schemes. Such approaches (partially) follow the
business model of providing multicast data services in parallel to business model of providing multicast data services in parallel to
PMIPv6 unicast routing. PMIPv6 unicast routing.
Multicast listener support satisfies the needs of receptive use cases Multicast listener support satisfies the needs of receptive use cases
such as IPTV or sever-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 enfold 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
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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 (unaware of IP mobility) can continue
to send multicast packets as soon as network connectivity is to send multicast packets as soon as network connectivity is
reconfigured. At this time, the MAG has determined the corresponding reconfigured. At this time, the MAG has determined the corresponding
LMA, and IPv6 unicast address configuration (including PMIPv6 LMA, and IPv6 unicast address configuration (including PMIPv6
bindings) has been performed . Still multicast packets arriving at bindings) has been performed. Still multicast packets arriving at
the MAG are discarded (if not buffered) until the MAG has completed the MAG are discarded (if not buffered) until the MAG has completed
the following steps. 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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
PMIPv6 can provide IPv4 home address mobility support [RFC5844]. PMIPv6 can provide IPv4 home address mobility support [RFC5844].
IPv4 multicast is handled by an IGMP proxy function at the MAG in an IPv4 multicast is handled by an IGMP proxy function at the MAG in an
analogous way. analogous way.
Following these deployment steps, multicast traffic distribution Following these deployment steps, multicast traffic distribution
transparently inter-operates with PMIPv6. It is worth noting that an transparently inter-operates with PMIPv6. It is worth noting that an
MN - while being attached to the same MAG as the mobile source, but MN - while being attached to the same MAG as the mobile source, but
associated with a different LMA - cannot receive multicast traffic on associated with a different LMA - cannot receive multicast traffic on
a shortest path. Instead, multicast streams flow up to the LMA of a shortest path. Instead, multicast streams flow up to the LMA of
the mobile source, are transferred to the LMA of the mobile listener the mobile source, are transferred to the LMA of the mobile listener
and tunneled downwards to the MAG again (see Appendix A for further and tunneled downwards to the MAG again (see Appendix B for further
considerations). considerations).
3.2. Base Solution for Source Mobility: Details 3.2. Base Solution for Source Mobility: Details
Incorporating multicast source mobility in PMIPv6 requires to deploy Incorporating multicast source mobility in PMIPv6 requires to deploy
general multicast functions at PMIPv6 routers and to define their general multicast functions at PMIPv6 routers and to define their
interaction with the PMIPv6 protocol in the following way. interaction with the PMIPv6 protocol in the following way.
3.2.1. Operations of the Mobile Node 3.2.1. Operations of the Mobile Node
skipping to change at page 16, line 24 skipping to change at page 16, line 24
from the RP via the (stable) LMA, the LMA-MAG tunnel to the mobile from the RP via the (stable) LMA, the LMA-MAG tunnel to the mobile
source. This tree can be of lesser routing efficiency than the PIM source. This tree can be of lesser routing efficiency than the PIM
source register tunnel established in phase one, but provides the source register tunnel established in phase one, but provides the
advantage of immediate data delivery to receivers that share a MAG advantage of immediate data delivery to receivers that share a 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. In consequence, and initiate a source registering of PIM phase one with the RP. In
the PIM transition from phase one to two will be iterated per response, the PIM RP will recognize the known source at a new
handover, leading to an enhanced signaling load and repeated delay (tunnel) interface. A PIM RP implementation compliant with this
variations. change can proceed as follows. The RP immediately responds with a
register stop, when it receives a register from the new MAG. As the
RP had joined the shortest path tree to receive from the source via
the LMA, the tree is persistently updated by joins transmitted
towards the new 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 initiated 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 proceed from receivers not sharing a MAG with S, this (S,G) tree will proceed 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 to the
mobile source. This tree is of higher routing efficiency than mobile source. This tree is of higher routing efficiency than
established in the previous phase two, but need not outperform the established in the previous phase two, but need not outperform the
PIM source register tunnel established in phase one. It provides the PIM source register tunnel established in phase one. It provides the
advantage of immediate data delivery to receivers that share a MAG advantage of immediate data delivery to receivers that share a 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. In consequence, and initiate a source registering of PIM phase one. A PIM
the PIM transition from phase one to two and three will be iterated implementation compliant with this change can recover phase three
per handover, leading to an enhanced signaling load and repeated states in the following way. First, the RP recovers to phase two as
delay variations. described in the previous section, but - being unaware of the LMA in
the role of a static mobility anchor - needs to forward data packets
that arrived via the source register tunnel down the RP-base tree
towards receivers. Such packets will trigger updates of phase three
shortest path trees at the DRs of the receivers. Meanwhile packets
arriving at the LMA without source register encapsulation are
forwarded natively along the shortest path tree towards receivers.
In consequence, the PIM transition from phase one to two and three
will be quickly recovered per handover, but still leads to an
enhanced signaling load and repeated delay variations.
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
skipping to change at page 18, line 37 skipping to change at page 19, line 5
On handover, the mobile source re-attaches to a new MAG (DF), which On handover, the mobile source re-attaches 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 Functions for Optimized Source Mobility in PMIPv6 5. Extended MLD Proxy 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, unmodified [RFC6224], [I-D.ietf-multimob-pmipv6-ropt]. However, deploying
standard solutions can go along with significant performance unmodified standard proxies can go along with significant performance
degradation for mobile senders as discussed along the lines of this degradation for mobile senders as discussed along the lines of this
document. To overcome these deficits, optimizing approaches to document. To overcome these deficits, an optimized approach to
multicast source mobility are introduced in this section. In multicast source mobility based on extended peering functions among
particular, uplink capabilities of MLD proxies are extended to allow proxies is introduced in this section. Prior to presenting the
for rapid, optimized multicast traffic flows from mobile sources. solution, we will sketch the relevant 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 different techniques, these requirements are met in the
following solutions. following solutions.
5.1. Multiple Upstream Interface Proxy 5.1. Peering Function for MLD Proxies
In this section, we define upstream extensions for an MLD proxy.
Multiple proxy instances deployed at a single MAG (see Section 3) can
be avoided by adding multiple upstream interfaces to a single MLD
Proxy. In a typical PMIPv6 deployment, each upstream of a single
proxy instance can interconnect to one of the LMAs. With such
ambiguous upstream options, appropriate forwarding rules MUST be
supplied to
o unambiguously guide traffic forwarding from directly attached
mobile sources, and
o lead listener reports to initiating unique traffic subscriptions.
This can be achieved by a complete set of source- and group-specific
filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces.
These filters MAY be derived in parts from PMIPv6 routing policies,
and can include a default behavior (e.g., (*,*)).
5.1.1. Operations for Local Multicast Sources
Packets from a locally attached multicast source will be forwarded to
all downstream interfaces with appropriate subscriptions, as well as
up the interface with the matching source-specific filter.
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
Multicast listener reports are group-wise aggregated by the MLD
proxy. The aggregated report is issued to the upstream interface
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.
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
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 remain as silent (locally deployed as in [RFC6224] or remotely) and remain as silent
virtual links 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 directly connects on exchanged only in cases, where one peering proxy directly connects on
the downstream to a source of multicast traffic, which the other the downstream to a source of multicast traffic, which the other
peering proxy actively subscribes to. Operations are defined for ASM peering proxy actively subscribes to. 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).
5.2.1. Operations at the Multicast Sender 5.1.1. 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 locally attached
source at the downstream. In detail, a proxy will extract from its source at the downstream. In detail, a proxy will extract from its
configuration the network prefixes attached to its downstream configuration the network prefixes attached to its downstream
interfaces and MUST implement a source filter base at its peering interfaces and MUST implement a source filter base at its peering
interfaces that restricts data transmission to IP source addresses interfaces that restricts data transmission to IP source addresses
from its local prefixes. This filter base Must be updated, if and from its local prefixes. This filter base Must be updated, if and
skipping to change at page 21, line 21 skipping to change at page 20, line 20
that arrive from the upstream interface of the proxy are thus only that arrive from the upstream interface of the proxy are thus only
forwarded to regular downstream interfaces with appropriate 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. interfaces with appropriate subscription states.
5.2.2. Operations at the Multicast Listener 5.1.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
offer 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 be mutually disjoint, but normally also available from the links will be mutually disjoint, but normally also available from the
upstream. To prevent duplicate traffic from arriving at the listener upstream. To prevent duplicate traffic from arriving at the listener
side, the proxy side, the proxy
o MAY delay aggregated reports to the upstream, and o MAY delay aggregated reports to the upstream, and
skipping to change at page 24, line 13 skipping to change at page 23, 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-01 (work in Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-03 (work in
progress), September 2012. progress), February 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.
[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.
Appendix A. Evaluation of Traffic Flows Appendix A. Multiple Upstream Interface Proxy
In this section, we document upstream extensions for an MLD proxy
that were originally developed during the work on this document.
Multiple proxy instances deployed at a single MAG (see Section 3) can
be avoided by adding multiple upstream interfaces to a single MLD
Proxy. In a typical PMIPv6 deployment, each upstream of a single
proxy instance can interconnect to one of the LMAs. With such
ambiguous upstream options, appropriate forwarding rules MUST be
supplied to
o unambiguously guide traffic forwarding from directly attached
mobile sources, and
o lead listener reports to initiating unique traffic subscriptions.
This can be achieved by a complete set of source- and group-specific
filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces.
These filters MAY be derived in parts from PMIPv6 routing policies,
and can include a default behavior (e.g., (*,*)).
A.1. Operations for Local Multicast Sources
Packets from a locally attached multicast source will be forwarded to
all downstream interfaces with appropriate subscriptions, as well as
up the interface with the matching source-specific filter.
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.
A.2. Operations for Local Multicast Subscribers
Multicast listener reports are group-wise aggregated by the MLD
proxy. The aggregated report is issued to the upstream interface
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.
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.
Appendix B. Evaluation of Traffic Flows
TODO TODO
Appendix B. Change Log Appendix C. Change Log
The following changes have been made from version
draft-ietf-multimob-pmipv6-source-02:
1. Added clarifications and details as requested by the working
group, resolved nits.
2. Moved Multiple Upstream MLD Proxy to Appendix in response to WG
desire.
3. Updated references.
The following changes have been made from version The following changes have been made from version
draft-ietf-multimob-pmipv6-source-01: draft-ietf-multimob-pmipv6-source-01:
1. Added clarifications and details as requested be the working 1. Added clarifications and details as requested by the working
group, resolved nits. group, resolved nits.
2. Detailed out operations of Multiple Upstream MLD Proxies. 2. Detailed out operations of Multiple Upstream MLD Proxies.
3. Clarified operations of MLD proxies with peering links. 3. Clarified operations of MLD proxies with peering links.
4. Many editorial improvements. 4. Many editorial improvements.
5. Updated references. 5. Updated references.
skipping to change at page 25, line 26 skipping to change at page 26, line 7
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
Thomas C. Schmidt Thomas C. Schmidt (editor)
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg 20099 Hamburg 20099
Germany Germany
Email: schmidt@informatik.haw-hamburg.de Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Shuai Gao Shuai Gao
Beijing Jiaotong University Beijing Jiaotong University
 End of changes. 23 change blocks. 
113 lines changed or deleted 141 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/