Internet DRAFT - draft-contreras-multimob-multiple-upstreams
draft-contreras-multimob-multiple-upstreams
MULTIMOB Working Group Luis M. Contreras
INTERNET-DRAFT Telefonica I+D
Intended Status: Proposed Standard Carlos J. Bernardos
Expires: April 18, 2013 Universidad Carlos III de Madrid
Juan Carlos Zuniga
InterDigital
February 25, 2013
Extension of the MLD proxy functionality to support multiple
upstream interfaces
draft-contreras-multimob-multiple-upstreams-01
Abstract
This document presents different scenarios of applicability for an
MLD proxy running more than one upstream interface. Since those
scenarios impose different requirements on the MLD proxy with
multiple upstream interfaces, it is important to ensure that the
proxy functionality addresses all of them for compatibility.
The purpose of this document is to define the requirements in an MLD
proxy with multiple interfaces covering a variety of applicability
scenarios, and to specify the proxy functionality to satisfy all of
them.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Contreras et al. Expires August 29, 2013 [Page 1]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Scenarios of applicability . . . . . . . . . . . . . . . . . . 7
4.1 Fixed network scenarios . . . . . . . . . . . . . . . . . . 7
4.1.1 Multicast wholesale offer for residential services . . 7
4.1.1.1 Requirements . . . . . . . . . . . . . . . . . . . 7
4.1.2 Multicast resiliency . . . . . . . . . . . . . . . . . 8
4.1.2.1 Requirements . . . . . . . . . . . . . . . . . . . 8
4.1.3 Load balancing for multicast traffic in the metro
segment . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3.1 Requirements . . . . . . . . . . . . . . . . . . . 8
4.1.4 Summary of the requirements needed for mobile network
scenarios . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Mobile network scenarios . . . . . . . . . . . . . . . . . 9
4.2.1 Applicability to multicast listener mobility . . . . . 10
4.2.1.1 Single MLD proxy instance on MAG . . . . . . . . . 10
4.2.1.1.1 Requirements . . . . . . . . . . . . . . . . . 10
4.2.1.2 Remote and local multicast subscription . . . . . . 10
4.2.1.2.1 Requirements . . . . . . . . . . . . . . . . . 11
4.2.1.3 Dual subscription to multicast groups during
handover . . . . . . . . . . . . . . . . . . . . . 11
4.2.1.3.1 Requirements . . . . . . . . . . . . . . . . . 12
4.2.2 Applicability to multicast source mobility . . . . . . 12
4.2.2.1 Support of remote and direct subscription in
basic source mobility . . . . . . . . . . . . . . . 12
4.2.2.1.1 Requirements . . . . . . . . . . . . . . . . . 13
4.2.2.2 Direct communication between source and listener
associated with distinct LMAs but on the same MAG . 13
Contreras et al. Expires August 29, 2013 [Page 2]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
4.2.2.3.1 Requirements . . . . . . . . . . . . . . . . . 14
4.2.2.3 Route optimization support in source mobility for
remote subscribers . . . . . . . . . . . . . . . . 14
4.2.2.3.1 Requirements . . . . . . . . . . . . . . . . . 14
4.2.3 Summary of the requirements needed for mobile network
scenarios . . . . . . . . . . . . . . . . . . . . . . . 15
5 Functional specification of an MLD proxy with multiple
interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 17
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Normative References . . . . . . . . . . . . . . . . . . . 17
10.2 Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Basic support for multicast listener with PMIPv6 . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Contreras et al. Expires August 29, 2013 [Page 3]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
1 Introduction
The aim of this document is to define the functionality that an MLD
proxy with multiple upstream interfaces should have in order to
support different scenarios of applicability in both fixed and mobile
networks. This compatibility is needed in order to simplify node
functionality and to ensure an easier deployment of multicast
capabilities in all the use cases described in this document.
2. Terminology
This document uses the terminology defined in [3]. Specifically, the
definition of Upstream and Downstream interfaces, which are
reproduced here for completeness.
Upstream interface:
A proxy device's interface in the direction of the root of the
tree. Also called the "Host interface".
Downstream interface:
Each of a proxy device's interfaces that is not in the direction
of the root of the tree. Also called the "Router interfaces".
3. Problem statement
The concept of MLD proxy with several upstream interfaces has emerged
as a way of optimizing (and in some cases enabling) service delivery
scenarios where separate multicast service providers are reachable
through the same access network infrastructure. Figure 1 presents the
conceptual model under consideration.
Contreras et al. Expires August 29, 2013 [Page 4]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
downstream upstream
interface interface A
| |
| | _______________
| +-------+ v / \
| | O-------( Multicast Set 1 )
+----------+ v | MLD | \_______________/
| Listener |------| | _______________
+----------+ | Proxy | / \
| O-------( Multicast Set 2 )
+-------+ ^ \_______________/
|
|
upstream
interface B
Figure 1. Concept of MLD proxy with multiple upstream interfaces
For illustrative purposes, two applications for fixed and mobile
networks are here introduced. They will be elaborated later on the
document.
In the case of fixed networks, multicast wholesale services in a
competitive residential market require an efficient distribution of
multicast traffic from different operators, i.e. the incumbent
operator and a number of alternative ones, on the network
infrastructure of the former. Existing proposals are based on the use
of PIM routing from the metro network, and multicast traffic
aggregation on the same tree. A different approach could be achieved
with the use of an MLD proxy with multiple upstream interfaces, each
of them pointing to a distinct multicast router in the metro border
which is part of separated multicast trees deep in the network.
Figure 2 graphically describes this scenario.
In the case of mobile networks, IP mobility services guarantee the
continuity of the IP session while a Mobile Node (MN) changes its
point of attachment. Proxy Mobile IPv6 (PMIPv6) [1] standardized a
protocol that allows the network to manage the MN mobility without
requiring specific support from the mobile terminal. The traffic to
the MN is tunneled from the Home Network making use of two entities,
one acting as mobility anchor, and the other as Mobility Access
Gateway (MAG). Multicast support in PMIPv6 [2] implies the delivery
of all the multicast traffic from the Home Network, via the mobility
anchor. However, multicast routing optimization [4] could take
advantage of an MLD proxy with multiple upstream interfaces by
supporting the decision of subscribing a multicast content from the
Home Network or from the local PMIPv6 domain if it is locally
available. Figure 3 presents this scenario.
Contreras et al. Expires August 29, 2013 [Page 5]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
Informational text is provided in Appendix A summarizing how the
basic solution for deploying multicast listener mobility with Proxy
Mobile IPv6 works.
downstream upstream
interface interface A
| |
| | _______________
| +--------+ v / \
| | O-------( Multicast Set 1 )
| | Aggr. | \_______________/
+----+ v | Switch | (e.g. from the Incumbent
| AN |-------| | Operator)
+----+ | (MLD | _______________
(e.g. | Proxy) | / \
DSLAM) | O-------( Multicast Set 2 )
+--------+ ^ \_______________/
| (e.g. from an Alternative
| Operator)
|
upstream
interface B
Figure 2. Example of usage of an MLD proxy with multiple
upstream interfaces in a fixed network scenario
downstream upstream
interface interface A
| |
| | _______________
| +--------+ v / \
| | O-------( Multicast Set 1 )
| | | \_______________/
+----+ v | MAG | e.g. from the Home Network
| MN |-------| | via the mobility anchor)
+----+ | (MLD | _______________
| Proxy) | / \
| O-------( Multicast Set 2 )
+--------+ ^ \_______________/
| (e.g. from the local PMIPv6
| domain via direct routing)
|
upstream
interface B
Figure 3. Example of usage of an MLD proxy with multiple
upstream interfaces in a mobile network scenario
Contreras et al. Expires August 29, 2013 [Page 6]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
Since those scenarios can motivate distinct needs in terms of MLD
proxy functionality, it is necessary to consider a comprehensive
approach, looking at the possible scenarios, and establishing a
minimum set of requirements which can allow the operation of a
versatile MLD proxy with multiple upstream interfaces as a common
entity to all of them (i.e., no different kinds of proxies depending
on the scenario, but a common proxy applicable to all the potential
scenarios).
4. Scenarios of applicability
This section describes in detail a number of scenarios of
applicability of an MLD proxy with multiple upstream interfaces in
place. A number of requirements for the MLD proxy functionality are
identified from those scenarios.
4.1 Fixed network scenarios
Residential broadband users get access to multiple IP services
through fixed network infrastructures. End user's equipment is
connected to an access node, and the traffic of a number of access
nodes is collected in aggregation switches.
For the multicast service, the use of an MLD proxy with multiple
upstream interfaces in those switches can provide service flexibility
in a lightweight and simpler manner if compared with PIM-routing
based alternatives.
4.1.1 Multicast wholesale offer for residential services
This scenario has been already introduced in the previous section,
and can be seen in Figure 2. There are two different operators, the
one operating the fixed network where the end user is connected
(e.g., typically an incumbent operator), and the one providing the
Internet service to the end user (e.g., an alternative Internet
service provider). Both can offer multicast streams that can be
subscribed by the end user, independently of which provider
contributes with the content.
Note that it is assumed that both providers offer distinct multicast
groups. However, more than one subscription to multicast channels of
different providers could take place simultaneously.
4.1.1.1 Requirements
- The MLD proxy should be able to deliver multicast control messages
sent by the end user to the corresponding provider's multicast
router.
Contreras et al. Expires August 29, 2013 [Page 7]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
- The MLD proxy should be able to deliver multicast control messages
sent by each of the providers to the corresponding end user.
4.1.2 Multicast resiliency
In current PIM-based solutions, the resiliency of the multicast
distribution relays on the routing capabilities provided by protocols
like PIM and VRRP. A simpler scheme could be achieved by implementing
different upstream interfaces on MLD proxies, providing path
diversity through the connection to distinct leaves of a given
multicast tree.
It is assumed that only one of the upstream interfaces is active in
receiving the multicast content, while the other is up and in standby
for fast switching.
4.1.2.1 Requirements
- The MLD proxy should be able to deliver multicast control messages
sent by the end user to the corresponding active upstream interface.
- The MLD proxy should be able to deliver multicast control messages
received in the active upstream to the end users, while ignoring the
control messages of the standby upstream interface.
- The MLD proxy should be able of rapidly switching from the active
to the standby upstream interface in case of network failure,
transparently to the end user.
4.1.3 Load balancing for multicast traffic in the metro segment
A single upstream interface in existing MLD proxy functionality
typically forces the distribution of all the channels on the same
path in the last segment of the network. Multiple upstream interfaces
could naturally split the demand, alleviating the bandwidth
requirements in the metro segment.
4.1.3.1 Requirements
- The MLD proxy should be able to deliver multicast control messages
sent by the end user to the corresponding multicast router which
provides the channel of interest.
- The MLD proxy should be able to deliver multicast control messages
sent by each of the multicast routers to the corresponding end user.
- The MLD proxy should be able to decide which upstream interface is
selected for any new channel request according to defined criteria
Contreras et al. Expires August 29, 2013 [Page 8]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
(e.g., load balancing).
4.1.4 Summary of the requirements needed for mobile network scenarios
Following the analysis above, a number of different requirements can
be identified by the MLD proxy to support multiple upstream
interfaces in fixed network scenarios. The following table summarizes
these requirements.
+-----------------------------------+
| Fixed Network Scenarios |
+---------+-----------+-----------+-----------+
|Functio- | Multicast | Multicast | Load |
|nality | Wholesale | Resiliency| Balancing |
+---------+-----------+-----------+-----------+
|Upstream | | | |
|Control | X | X | X |
|Delivery | | | |
+---------+-----------+-----------+-----------+
|Downstr. | | | |
|Control | X | X | X |
|Delivery | | | |
+---------+-----------+-----------+-----------+
|Active / | | | |
|Standby | | X | |
|Upstream | | | |
+---------+-----------+-----------+-----------+
|Upstr i/f| | | |
|selection| | | X |
|per group| | | |
+---------+-----------+-----------+-----------+
|Upstr i/f| | | |
|selection| | X | |
|all group| | | |
+---------+-----------+-----------+-----------+
Table I. Functionality needed on MLD proxy with multiple
upstream interfaces per application scenario in fixed networks
4.2 Mobile network scenarios
The mobile networks considered in this document are supposed to run
PMIPv6 protocol for IP mobility management. A brief description of
multicast provision in PMIPv6-based networks can be found in Appendix
A.
Contreras et al. Expires August 29, 2013 [Page 9]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
The use of an MLD proxy supporting multiple upstream interfaces can
improve the performance and the scalability of multicast-capable
PMIPv6 domains.
4.2.1 Applicability to multicast listener mobility
Three sub-cases can be identified for the multicast listener
mobility.
4.2.1.1 Single MLD proxy instance on MAG
The base solution for multicast service in PMIPv6 [2] assumes that
any MN subscribed to multicast services receive the multicast traffic
through the associated LMA, as in the unicast case. As standard MLD
proxy functionality only supports one upstream interface, the MAG
should implement several separated MLD proxy instances, one per LMA,
in order to serve the multicast traffic to the MNs, according to any
particular LMA-MN association.
A way of avoiding the multiplicity of MLD proxy instance in a MAG is
to deploy a unique MLD proxy instance with multiple upstream
interfaces, one per LMA, without any change in the multicast traffic
distribution.
4.2.1.1.1 Requirements
- The MLD proxy should be able of delivering the multicast control
messages sent by the MNs to the associated LMA.
- The MLD proxy should be able of delivering the multicast control
messages sent by each of the connected LMAs to the corresponding MN.
- The MLD proxy should be able of routing the multicast data coming
from different LMAs to the corresponding MNs according to the MN to
LMA association.
- The MLD proxy should be able of maintaining a 1:1 association
between an MN and LMA (or downstream to upstream).
4.2.1.2 Remote and local multicast subscription
This scenario has been already introduced in the previous section,
and can be seen in Figure 3. Standard MLD proxy definition, with a
unique upstream interface per proxy, does not allow the reception of
multicast traffic from distinct upstream multicast routers. In other
words, all the multicast traffic being sent to the MLD proxy in
Contreras et al. Expires August 29, 2013 [Page 10]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
downstream traverses a concrete, unique router before reaching the
MAG. There are, however, situations where different multicast content
could reach the MLD proxy through distinct next-hop routers.
For instance, the solution adopted to avoid the tunnel convergence
problem in basic multicast PMIPv6 deployments [4] considers the
possibility of subscription to a multicast source local to the PMIPv6
domain. In that situation, some multicast content will be accesses
remotely, through the home network via the multicast tree mobility
anchor, while some other multicast content will reach the proxy
directly, via a local router in the domain.
4.2.1.2.1 Requirements
- The MLD proxy should be able of delivering the multicast control
messages sent by the MNs to the associated upstream interface based
on the location of the source, remote or local, for a certain
multicast group.
- The MLD proxy should be able of delivering the multicast control
messages sent either local or remotely to the corresponding MNs.
- The MLD proxy should be able of routing the multicast data coming
from different upstream interfaces to a certain MN according to the
MN subscription, either local or remote. Note that it is assumed that
a multicast group can be subscribed either locally or remotely, but
not simultaneously. However more than one subscription could happen,
being local or remote independently.
- The MLD proxy should be able of maintaining a 1:N association
between an MN and the remote and local multicast router (or
downstream to upstream).
- The MLD proxy should be able of switching between local or remote
subscription for per multicast group according to specific
configuration parameters (out of the scope of this document).
4.2.1.3 Dual subscription to multicast groups during handover
In the event of an MN handover, once an MN moves from a previous MAG
(pMAG) to a new MAG (nMAG), the nMAG needs to set up the multicast
status for the incoming MN, and subscribe the multicast channels it
was receiving before the handover event. The MN will then experience
a certain delay until it receives again the subscribed content.
A generic solution is being defined in [5] to speed up the knowledge
of the ongoing subscription by the nMAG. However, for the particular
case that the underlying radio access technology supports layer-2
Contreras et al. Expires August 29, 2013 [Page 11]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
triggers (thus requiring extra capabilities on the mobile node),
there could be inter-MAG cooperation for handover support if pMAG and
nMAG are known in advance.
This could be the case, for instance for those contents not already
arriving to the nMAG, where the nMAG temporally subscribes the
multicast groups of the ongoing MN's subscription via the pMAG, while
the multicast delivery tree among the nMAG and the mobility anchor is
being established.
A similar approach is followed in [6] despite the solution proposed
there differs from this approach (i.e., there is no consideration of
an MLD proxy with multiple interfaces).
4.2.1.3.1 Requirements
- The MLD proxy should be able of delivering the multicast control
messages sent by the MNs to the associated upstream interface based
on the handover specific moment, for a certain multicast group.
- The MLD proxy should be able of delivering the multicast control
messages sent either from pMAG or the multicast anchor to the
corresponding MNs, based on the handover specific moment.
- The MLD proxy should be able of handle the incoming packet flows
from the two simultaneous upstream interfaces, in order to not
duplicate traffic delivered on the point-to-point link to the MN.
- The MLD proxy should be able of maintaining a 1:N association
between an MN and both the remote multicast router and the pMAG (or
downstream to upstream).
- The MLD proxy should be able of switching between local or remote
subscription for all the multicast groups (from pMAG to multicast
anchor) according to specific configuration parameters (out of the
scope of this document).
4.2.2 Applicability to multicast source mobility
A couple of sub-cases can be identified for the multicast source
mobility.
4.2.2.1 Support of remote and direct subscription in basic source
mobility
In the basic case of source mobility, the multicast source is
connected to one of the downstream interfaces of an MLD proxy.
According to the standard specification [3] every packet sent by the
Contreras et al. Expires August 29, 2013 [Page 12]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
multicast source will be forwarded towards the root of the multicast
tree.
However, linked to the mobility listener problem, there could be the
case of simultaneous remote subscribers, subscribing to the multicast
content through the home network, and local subscribers, requesting
the contents directly via a multicast router residing on the same
PMIPv6 domain where the source is attached to.
Then, in order to provide the co-existence of both types of
subscribers, an MLD proxy with two upstream interfaces could
simultaneously serve all kind of multicast subscribers.
Basic source mobility is being defined in [7] but the solution
proposed there does not allow simultaneous co-existence of remote and
local subscribers (i.e., the content sent by the source is either
distributed locally to a multicast router in the PMIPv6 domain, or
remotely by using the bi-directional tunnel towards the mobility
anchor, but not both simultaneously).
4.2.2.1.1 Requirements
- The MLD proxy should be able of forwarding (replicating) the
multicast content to both upstream interfaces, in case of
simultaneous remote and local distribution.
- The MLD proxy should be able of handling control information
incoming through any of the two upstream interfaces, providing the
expected behavior for each of the multicast trees.
- The MLD proxy should be able of routing the multicast data towards
different upstream interfaces for both remote and local subscriptions
that could happen simultaneously.
- The MLD proxy should be able of maintaining a 1:N association
between an MN and both the remote and local multicast router (or
downstream to upstream).
4.2.2.2 Direct communication between source and listener associated
with distinct LMAs but on the same MAG
In a certain PMIPv6 domain can be MNs associated to distinct LMAs
using the same MAG to get access to their corresponding home
networks. For multicast communication, according to the base solution
[2], each MN <-> LMA association implies a distinct MLD proxy
instance to be invoked in the MAG.
Contreras et al. Expires August 29, 2013 [Page 13]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
In these conditions, when a mobile source is serving multicast
content to a mobile listener, both attached to the same MAG but each
of them associated to different LMAs, the multicast flow must
traverse the PMIPv6 domain from the MAG to the LMA where the source
maintains an association, then from that LMA to the LMA where the
listener is associated to, and finally come back to the same MAG from
where the flow departed. This routing is extremely inefficient.
An MLD proxy with multiple upstream interfaces avoids this behavior
since it allows to invoke a unique MLD proxy instance in the MAG. In
this case, the multicast source can directly communicate with the
multicast listener, without need for delivering the multicast traffic
to the LMAs.
4.2.2.3.1 Requirements
- The MLD proxy should be able of forwarding (replicating) the
multicast content to different upstream or downstream interfaces
where subscribers are present.
- The MLD proxy should be able of handling control information
incoming through any of the upstream or downstream interfaces
requesting a multicast flow being injected in another downstream
interface.
- The MLD proxy should be able of maintaining a 1:N association
between an MN and any of the upstream or downstream interfaces
demanding the multicast content.
4.2.2.3 Route optimization support in source mobility for remote
subscribers
Even in a scenario of remote subscription, there could be the case
where both the source and the listener are attached to the same
PMIPv6-Domain (for instance, no possibility of direct routing within
the PMIPv6, or source and listener pertaining to distinct home
networks). In this situation there is a possibility of route
optimization if inter-MAG communication is enabled, in such a way
that the listeners in the PMIPv6 domain are served through the
tunnels between MAGs, while the rest of remote listeners are served
through the mobility anchor.
A multi-upstream MLD proxy would allow the simultaneous delivery of
traffic to such kind of remote listeners.
A similar route optimization approach is proposed in [8].
4.2.2.3.1 Requirements
Contreras et al. Expires August 29, 2013 [Page 14]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
- The MLD proxy should be able of forwarding (replicating) the
multicast content to both kinds of upstream interfaces, inter-MAG
tunnel interfaces and MAG to mobility anchor tunnel interface.
- The MLD proxy should be able of handling control information
incoming through any of the two types of upstream interfaces,
providing the expected behavior for each of the multicast trees
(e.g., no forwarding traffic on one inter-MAG link once there are not
more listeners requesting the content).
- The MLD proxy should be able of routing the multicast data towards
different upstream interfaces for both remote and route optimized
subscriptions that could happen simultaneously.
- The MLD proxy should be able of maintaining a 1:N association
between an MN and both the remote and local MAGs (or downstream to
upstream).
4.2.3 Summary of the requirements needed for mobile network scenarios
After the previous analysis, a number of different requirements can
be identified by the MLD proxy to support multiple upstream
interfaces in mobile network scenarios. The following table
summarizes these requirements.
Contreras et al. Expires August 29, 2013 [Page 15]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
+----------------------------------------------------+
| Mobile Network Scenarios |
+--------------------------+-------------------------+
| Mulicast Listener | Mulicast Source |
+---------+--------+--------+--------+--------+--------+-------+
| | Single| Remote | Dual | Direct |Listener| Route |
|Functio- | MLD |& local | subscr.|& remote|& source|optimi.|
|nality | Proxy | subscr.| in HO | subscr.| on MAG | |
+---------+--------+--------+--------+--------+--------+-------+
|Upstream | | | | | | |
|Control | X | X | X | X | X | X |
|Delivery | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Downstr. | | | | | | |
|Control | X | X | X | | X | |
|Delivery | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Upstream | | | | | | |
|Data | | | | X | | X |
|Delivery | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Downstr. | | | | | | |
|Data | X | X | X | | X | |
|Delivery | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|1:1 MN to| | | | | | |
|upstream | X | | | | | |
|assoc. | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|1:N MN to| | | | | | |
|upstream | | X | X | X | X | X |
|assoc. | | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Upstr i/f| | | | | | |
|selection| | X | | | | |
|per group| | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Upstr i/f| | | | | | |
|selection| | | X | | | |
|all group| | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
|Upstream | | | | | | |
|traffic | | | | X | | X |
|replicat.| | | | | | |
+---------+--------+--------+--------+--------+--------+-------+
Table II. Functionality needed on MLD proxy with multiple
upstream interfaces per application scenario in mobile networks
Contreras et al. Expires August 29, 2013 [Page 16]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
5 Functional specification of an MLD proxy with multiple interfaces
<To be completed>.
6 Security Considerations
<To be completed>.
7 IANA Considerations
<IANA considerations text>.
8 Conclusions
<To be completed>.
9 Acknowledgements
The authors thank Stig Venaas for his valuable comments and
suggestions.
The research of Carlos J. Bernardos leading to these results has
received funding from the European Community's Seventh Framework
Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL
project), being also partially supported by the Ministry of Science
and Innovation (MICINN) of Spain under the QUARTET project (TIN2009-
13992-C02-01).
10 References
10.1 Normative References
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B.
Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[2] T.C. Schmidt, M. Waehlisch, and S. Krishnan, "A Minimal
Deployment Option for Multicast Listeners in PMIPv6 Domains",
RFC6224, April 2011.
[3] B. Fenner, H. He, B. Haberman, and H. Sandick,"Internet Group
Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-
Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605,
August 2006.
10.2 Informative References
Contreras et al. Expires August 29, 2013 [Page 17]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
[4] J.C. Zuniga, L.M. Contreras, C.J. Bernardos, S. Jeon, Y. Kim,
"Multicast Mobility Routing Optimizations for Proxy Mobile
IPv6", work in progress, draft-ietf-multimob-pmipv6-ropt-01,
September 2012.
[5] L.M. Contreras, C.J. Bernardos, I. Soto, "PMIPv6 multicast
handover optimization by the Subscription Information
Acquisition through the LMA (SIAL)", work in progress, draft-
ietf-multimob-fast-handover-01, July 2012.
[6] T.C. Schmidt, M. Waehlisch, R. Koodli, G. Fairhurst, "Multicast
Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", work
in progress, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-06,
May 2012
[7] T.C. Schmidt, S. Gao, H. Zhang, M. Waehlisch, "Mobile Multicast
Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", work in
progress, draft-ietf-multimob-pmipv6-source-01, July 2012.
[8] J. Liu, W. Luo, "Routes Optimization for Multicast Sender in
Proxy Mobile IPv6 Domain", work in progress, draft-liu-multimob-
pmipv6-multicast-ro-02, July 2012.
Appendix A. Basic support for multicast listener with PMIPv6
This section briefly summarizes the operation of Proxy Mobile IPv6
[1] and how multicast listener support works with PMIPv6 as specified
in [2].
Proxy Mobile IPv6 (PMIPv6) [1] is a network-based mobility management
protocol which enables the network to provide mobility support to
standard IP terminals residing in the network. These terminals enjoy
this mobility service without being required to implement any
mobility-specific IP operations. Namely, PMIPv6 is one of the
mechanisms adopted by the 3GPP to support the mobility management of
non-3GPP terminals in future Evolved Packet System (EPS) networks.
PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct
bi-directional tunnel with different Local Mobility Anchors (LMAs),
being each tunnel shared by the attached Mobile Nodes (MNs). Each
mobile node is associated with a corresponding LMA, which keeps track
of its current location, that is, the MAG where the mobile node is
attached. IP-in-IP encapsulation is used within the tunnel to forward
traffic between the LMA and the MAG. Figure 4 (taken from [1]) shows
the architecture of a PMIPv6 domain.
Contreras et al. Expires August 29, 2013 [Page 18]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
| | |
MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4
{MN1} {MN3}
Figure 4. Proxy Mobile IPv6 Domain
The basic solution for the distribution of multicast traffic within a
PMIPv6 domain [2] makes use of the bi-directional LMA-MAG tunnels.
The base solution follows the so-called remote subscription model, in
which the subscribed multicast content is delivered from the Home
Network. By doing so, an individual copy of every multicast flow is
delivered through the tunnel connecting the mobility anchor to any of
the access gateways in the domain. In many cases, these individual
copies traverse the same routers in the path towards the access
gateways, incurring in an inefficient distribution, equivalent to the
unicast distribution of the multicast content in the domain.
The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 5 (taken from [2]).
This fact leads to distribution inefficiencies and higher per-bit
delivery costs, incurred by the PMIPv6 domain operator offering
transport capabilities to the Home Network operator for serving their
MNs when attached to the PMIPv6 domain. As long as the remotely
subscribed multicast service is not affected, it seems worthy to
explore more optimal ways of distributing such content within the
PIMPv6 domain.
Contreras et al. Expires August 29, 2013 [Page 19]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3
Figure 5. Reference Network for Multicast Deployment in PMIPv6
Authors' Addresses
Luis M. Contreras
Telefonica I+D
EMail: lmcm@tid.es
Carlos J. Bernardos
Universidad Carlos III de Madrid
EMail: cjbc@it.uc3m.es
Contreras et al. Expires August 29, 2013 [Page 20]
INTERNET DRAFT MLD proxy with multiple upstream February 25, 2012
Juan Carlos Zuniga
InterDigital Communications, LLC
EMail: JuanCarlos.Zuniga@InterDigital.com
Contreras et al. Expires August 29, 2013 [Page 21]
