MULTIMOB Group T C. Schmidt
Internet-Draft HAW Hamburg
Intended status: BCP M. Waehlisch
Expires: June 19, 2010 link-lab & FU Berlin
B. Sarikaya
Huawei USA
S. Krishnan
Ericsson
December 16, 2009
A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains
draft-schmidt-multimob-pmipv6-mcast-deployment-03
Abstract
This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to Home Agents in
Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
subscription anchor points, while Mobile Access Gateways provide MLD
proxy functions. In this scenario, Mobile Nodes remain agnostic of
multicast mobility operations.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
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/ietf/1id-abstracts.txt.
Schmidt, et al. Expires June 19, 2010 [Page 1]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 19, 2010.
Copyright Notice
Copyright (c) 2009 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 BSD License.
Schmidt, et al. Expires June 19, 2010 [Page 2]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 7
4.2. Operations of the Mobile Access Gateway . . . . . . . . . 7
4.3. Operations of the Local Mobility Anchor . . . . . . . . . 8
4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. A Note on Explicit Tracking . . . . . . . . . . . . . . . 9
5. Message Source and Destination Address . . . . . . . . . . . . 10
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 12
Appendix B. Comparative Evaluation of Different Approaches . . . 12
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Schmidt, et al. Expires June 19, 2010 [Page 3]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by
network-based management functions that enable IP mobility for a host
without requiring its participation in any mobility-related
signaling. Additional network entities, i.e., the Local Mobility
Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for
managing IP mobility on behalf of the mobile node (MN).
With these routing entities in place, the mobile node looses
transparent end-to-end connectivity to the static Internet, and in
the particular case of multicast communication, group membership
management as signaled by the Multicast Listener Discovery protocol
[RFC3810], [RFC2710] requires a dedicated treatment at the network
side, see [I-D.deng-multimob-pmip6-requirement].
Multicast routing functions need a careful placement within the
PMIPv6 domain to augment unicast transmission with group
communication services. [RFC5213] does not explicitly address
multicast communication, whereas bi-directional home tunneling, the
minimal multicast support arranged by MIPv6, cannot be applied in
network-based management scenarios: A mobility-unaware node will
experience no reason to initiate a tunnel with an entity of mobility
support.
This document describes options for deploying multicast listener
functions in Proxy Mobile IPv6 domains without modifying mobility and
multicast protocol standards. Similar to Home Agents in Mobile IPv6,
PMIPv6 Local Mobility Anchors serve as multicast subscription anchor
points, while Mobile Access Gateways provide MLD proxy functions.
Mobile Nodes in this scenario remain agnostic of multicast mobility
operations. Accrediting the problem space of multicast mobility
[I-D.irtf-mobopts-mmcastv6-ps], this document does not address
specific optimizations and efficiency improvements of multicast
routing in network-centered mobility beyond base potentials, as such
solutions would require changes to the base specification of
[RFC5213].
2. Terminology
This document uses the terminology as defined for the mobility
protocols [RFC3775] and [RFC5213], as well as the multicast edge
related protocols [RFC3810] and [RFC4605].
Schmidt, et al. Expires June 19, 2010 [Page 4]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
3. Overview
The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 1.
+-------------+
| 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 1: Reference Network for Multicast Deployment in PMIPv6
An MN in a PMIPv6 domain will decide on multicast group membership
management completely independent of its current mobility conditions.
It will submit MLD Report and Done messages following application
desires, thereby using its link-local source address and multicast
destination addresses according to [RFC3810], or [RFC2710]. These
link-local signaling messages will arrive at the currently active MAG
via one of its downstream local (wireless) links. A multicast
unaware MAG would simply discard these MLD messages.
To facilitate multicast in a PMIPv6 domain, an MLD proxy function
Schmidt, et al. Expires June 19, 2010 [Page 5]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
[RFC4605] needs to be deployed on the MAG that selects the tunnel
interface corresponding to the MN's LMA for its upstream interface
(cf., section 6 of [RFC5213]). Thereby, each LMA-to-MAG tunnel
interface defines an MLD proxy domain at the MAG, containing all
downstream links to MNs that share this LMA. According to standard
proxy operations, MLD Report messages will be forwarded under
aggregation up the tunnel interface to its corresponding LMA.
Serving as the designated multicast router or an additional MLD
proxy, the LMA will transpose any MLD message from a MAG into the
multicast routing infrastructure. Correspondingly, the LMA will
implement appropriate multicast forwarding states at its tunnel
interface. Traffic arriving for groups under subscription will
arrive at the LMA, which it will forward according to all its group/
source states. In addition, the LMA will naturally act as an MLD
querier, seeing its downstream tunnel interfaces as multicast enabled
links.
At the MAG, MLD queries and multicast data will arrive on the
(tunnel) interface that is assigned to a group of access links as
identified by its Binding Update List (cf., section 6 of [RFC5213]).
As specified for MLD proxies, the MAG will forward multicast traffic
and initiate related signaling down the appropriate access links to
the MNs. In proceeding this way, all multicast-related signaling and
the data traffic will transparently flow from the LMA to the MN on an
LMA-specific tree, which is shared among the multicast sources.
In case of a mobility handover, the MN (unaware of IP mobility) will
refrain from submitting unsolicited MLD reports. Instead, the MAG is
required to maintain group memberships in the following way. On
observing a new MN on a downstream link, the MAG sends a General MLD
Query. Based on its outcome and the multicast group states
previously maintained at the MAG, a corresponding Report will be sent
to the LMA aggregating group states according to the proxy function.
Additional Reports can be omitted, whenever multicast forwarding
states previously established at the new MAG already cover the
subscriptions of the MN.
After Re-Binding, the LMA is not required to issue a General MLD
Query on the tunnel link to refresh forwarding states. Multicast
state updates SHOULD be triggered by the MAG, which aggregates
subscriptions of all its MNs (see the call flow in Figure 2).
Schmidt, et al. Expires June 19, 2010 [Page 6]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| | < Movement to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
Figure 2: Call Flow of Multicast-enabled PMIP
These multicast deployment considerations likewise apply for mobile
nodes that operate with its IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide an IPv4 home address mobility support
[I-D.ietf-netlmm-pmip6-ipv4-support]. Such mobile node will use
IGMPv3 [RFC3376] signaling for multicast, which is handled by an IGMP
proxy function at the MAG in an analogous way.
Following these deployment steps, multicast management transparently
interoperates with PMIPv6. It is worth noting that multicast streams
Schmidt, et al. Expires June 19, 2010 [Page 7]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
can possibly be distributed on redundant paths that lead to duplicate
traffic arriving from different LMAs at one MAG, and can cause
multiple data transmissions from an MAG over one wireless domain to
different MNs (see Appendix B for further considerations).
4. Deployment Details
Multicast activation in a PMIPv6 domain requires to deploy general
multicast functions at PMIPv6 routers and to define its interaction
with the PMIPv6 protocol in the following way:
4.1. Operations of the Mobile Node
A Mobile Node willing to manage multicast traffic will join, maintain
and leave groups as if located in the fixed Internet. No specific
mobility actions nor implementations are required at the MN.
4.2. Operations of the Mobile Access Gateway
A Mobility Access Gateway is required to assist in MLD signaling and
data forwarding between the MNs which it serves, and the
corresponding LMAs associated to each MN. It therefore needs to
implement an instance of the MLD proxy function [RFC4605] for each
upstream tunnel interface that has been established with an LMA. The
MAG decides on the mapping of downstream links to a proxy instance
(and hence an upstream link to an LMA) based on the regular Binding
Update List as maintained by PMIPv6 standard operations (cf., section
6.1 of [RFC5213]).
On the reception of MLD reports from an MN, the MAG MUST identify the
corresponding proxy instance from the incoming interface and perform
regular MLD proxy operations: it will insert/update/remove a
multicast forwarding state on the incoming interface, and state
updates will be merged into the MLD proxy membership database. An
aggregated Report will be sent to the upstream tunnel of the MAG when
the membership database (cf., section 4.1 of [RFC4605]) changes.
Conversely, on the reception of MLD Queries, the MAG proxy instance
will answer the Queries on behalf of all active downstream receivers
maintained in its membership database. Queries sent by the LMA do
not force the MAG to trigger corresponding messages immediately
towards MNs. Multicast traffic arriving at the MAG on an upstream
interface will be forwarded according to the group/source-specific
forwarding states as acquired for each downstream interface within
the MLD proxy instance.
In case of a mobility handover, the MAG will continue to manage
upstream tunnels and downstream interfaces as foreseen in the PMIPv6
Schmidt, et al. Expires June 19, 2010 [Page 8]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
specification. However, it MUST assure consistency of its up- and
downstream interfaces that change under mobility with MLD proxy
instances and its multicast forwarding states. The MAG will detect
the arrival of a new MN by receiving a router solicitation message
and by an upcoming link. To learn about multicast groups subscribed
by a newly attaching MN, the MAG sends a General Query to the MN's
link. Querying an upcoming interface is a standard operation of MLD
queriers (see Appendix A). In case, the access link between MN and
MAG goes down, interface-specific multicast states change. Both
cases may alter the composition of the membership database, which
then will trigger corresponding Reports towards the LMA. Note that
the actual observable state depends on the access link model in use.
An MN may be unable to answer MAG multicast membership queries due to
handover procedures. Such occurrence is equivalent to a General
Query loss. To prevent erroneous query timeouts at the MAG, MLD
parameters SHOULD be carefully adjusted to the mobility regime. In
particular, MLD timers and the Robustness Variable (see section 9 of
[RFC3810]) MUST be chosen to be compliant with the time scale of
handover operations in the PMIPv6 domain.
In proceeding this way, the MAG is entitled to aggregate multicast
subscriptions for each of its MLD proxy instances. However, this
deployment approach does not prevent multiple identical streams
arriving from different LMA upstream interfaces. Furthermore, a per
group forwarding into the wireless domain is restricted to the link
model in use.
4.3. Operations of the Local Mobility Anchor
For any MN, the Local Mobility Anchor acts as the persistent Home
Agent and at the same time as the default multicast querier for the
corresponding MAG. It implements the function of the designated
multicast router or a further MLD proxy. According to MLD reports
received from a MAG (on behalf of the MNs), it establishes/maintains/
removes group/source-specific multicast forwarding states at its
corresponding downstream tunnel interfaces. At the same time, it
procures for aggregated multicast membership maintenance at its
upstream interface. Based on the multicast-transparent operations of
the MAGs, the LMA experiences its tunnel interfaces as multicast
enabled downstream links, serving zero to many listening nodes.
Multicast traffic arriving at the LMA is transparently forwarded
according to its multicast forwarding information base.
On the occurrence of a mobility handover, the LMA will receive
Binding Lifetime De-Registrations and Binding Lifetime Extensions
that will cause a re-mapping of home network prefixes to Proxy-CoAs
in its Binding Cache (see section 5.3 of [RFC5213]). The multicast
Schmidt, et al. Expires June 19, 2010 [Page 9]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
forwarding states require updating, as well, if the MN within an MLD
proxy domain is the only receiver of a multicast group. Two cases
need distinction:
1. The mobile node is the only receiver of a group behind the
interface at which a De-Registration was received: The membership
database of the MAG changes, which will trigger a Report/Done
sent via the MAG-to-LMA interface to remove this group. The LMA
thus terminates multicast forwarding.
2. The mobile node is the only receiver of a group behind the
interface at which a Lifetime Extension was received: The
membership database of the MAG changes, which will trigger a
Report sent via the MAG-to-LMA interface to add this group. The
LMA thus starts multicast distribution.
In proceeding this way, each LMA will provide transparent multicast
support for the group of MNs it serves. It will perform traffic
aggregation at the MN-group level and will assure that multicast data
streams are uniquely forwarded per individual LMA-to-MAG tunnel.
4.4. IPv4 Support
An MN in a PMIPv6 domain may use an IPv4 address transparently for
communication as specified in [I-D.ietf-netlmm-pmip6-ipv4-support].
For this purpose, LMAs can register IPv4-Proxy-CoAs in its Binding
Caches and MAGs can provide IPv4 support in access networks.
Correspondingly, multicast membership management will be performed by
the MN using 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 IPv6. [RFC4605] defines IGMP proxy behaviour in full
agreement with IPv6/MLD. Thus IPv4 support can be transparently
provided following the obvious deployment analogy.
For a dual-stack IPv4/IPv6 access network, it should be noted that
the infrastructure cannot identify two data streams as identical when
distributed via an IPv4 and IPv6 multicast group. Thus duplicate
data may be forwarded on a heterogeneous network layer.
4.5. A Note on Explicit Tracking
IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with
explicit tracking, which allows routers to monitor each multicast
receiver. This mechanism is not standardized yet, but widely
implemented by vendors as it supports faster leave latencies and
reduced signaling.
Enabling explicit tracking on downstream interfaces of the LMA and
Schmidt, et al. Expires June 19, 2010 [Page 10]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
MAG would track a single MAG and MN respectively per interface. It
may be used to preserve bandwidth on the MAG-MN link.
5. Message Source and Destination Address
This section describes source and destination addresses of MLD
messages. The interface identifier A-B denotes an interface on node
A, which is connected to node B. This includes tunnel interfaces.
5.1. Query
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
5.2. Report/Done
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [RFC2710], [RFC3810] | inner |
+-----------+----------------+----------------------+----------+
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
This draft does neither introduce additional messages nor novel
protocol operations. Consequently, no new threats arrive from
procedures described in this document in excess to [RFC3810],
[RFC4605] and [RFC5213] security concerns.
Schmidt, et al. Expires June 19, 2010 [Page 11]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
8. Acknowledgements
This memo is the outcome of extensive previous discussions and a
follow-up of several initial drafts on the subject. The authors
would like to thank Gorry Fairhurst, Jouni Korhonen, Sebastian
Meiling, Liu Hui, Imed Romdhani, and Stig Venaas for advice, help and
reviews of the document.
9. References
9.1. Normative References
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
(work in progress), September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[I-D.deng-multimob-pmip6-requirement]
Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
"Multicast Support Requirements for Proxy Mobile IPv6",
Schmidt, et al. Expires June 19, 2010 [Page 12]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
draft-deng-multimob-pmip6-requirement-02 (work in
progress), July 2009.
[I-D.irtf-mobopts-mmcastv6-ps]
Schmidt, T., Waehlisch, M. and G. Fairhurst, "Multicast
Mobility in MIPv6: Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-09 (work in progress),
October 2009.
[I-D.zuniga-multimob-smspmip]
Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
Services Using Proxy Mobile IPv6",
draft-zuniga-multimob-smspmip-00 (work in progress),
October 2009.
Appendix A. Initial MLD Queries on Upcoming Links
According to [RFC3810] and [RFC2710] when an IGMP/MLD-enabled router
starts operating on a subnet, by default it considers itself as being
the Querier and sends several General Queries. Such initial query
should be sent by the router immediately, but could be delayed by a
(tunable) Startup Query Interval (see Sections 7.6.2. and 9.6. of
[RFC3810]).
Experimental tests on Linux and Cisco systems have revealed immediate
IGMP Queries following a link trigger event (within a fraction of 1
ms), while MLD Queries immediately followed the autoconfiguration of
IPv6 link-local addresses at the corresponding interface.
Appendix B. Comparative Evaluation of Different Approaches
In this section, we briefly evaluate two basic PMIP concepts for
multicast traffic organization at LMAs: In scenario A, multicast is
provided by combined unicast/multicast LMAs as described in this
document. Scenario B directs traffic via a dedicated multicast LMA
as proposed in [I-D.zuniga-multimob-smspmip], for example.
Both approaches do not establish native multicast distribution
between the LMA and MAG, but use tunneling mechanisms. In scenario
A, a MAG is connected to different multicast-enabled LMAs, and can
receive the same multicast stream via multiple paths depending on the
group subscriptions of MNs and their associated LMAs. This problem,
a.k.a. tunnel convergence problem, may lead to redundant traffic at
the MAGs. Scenario B in contrast configures MAGs to establish a
tunnel to a single, dedicated multicast LMA for all attached MNs and
relocates overhead costs to the multicast anchor. This eliminates
Schmidt, et al. Expires June 19, 2010 [Page 13]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
redundant traffic, but may result in an avalanche problem at the LMA.
We quantify the costs of both approaches based on two metrics: The
amount of redundant traffic at MAGs and the number of simultaneous
streams at LMAs. Realistic values depend on the topology and the
group subscription model. To explore scalability in a large PMIP
domain of 1,000,000 MNs, we consider the following two extremal
multicast settings.
1. All MNs participate in distinct multicast groups.
2. All MNs join the same multicast groups.
A typical PMIP deployment approximately allows for 5,000 MNs attached
to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000
MNs require approx. 200 MAGs backed by 4 LMAs for unicast
transmission. In scenario A, these LMAs also forward multicast
streams, while in scenario B one additional dedicated LMA (LMA-M)
serves multicast. In the following, we calculate the metrics
described above.
Setting 1:
+===================+================+===================+
| PMIP multicast | # of redundant | # of sim. streams |
| scheme | streams at MAG | at LMA / LMA-M |
+===================+================+===================+
| Combined Unicast/ | 0 | 250,000 |
| Multicast LMA | | |
+-------------------+----------------+-------------------+
| Dedicated | 0 | 1,000,000 |
| Multicast LMA | | |
+-------------------+----------------+-------------------+
1,000,000 MNs are subscribed to distinct multicast groups
Schmidt, et al. Expires June 19, 2010 [Page 14]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
Setting 2:
+===================+================+===================+
| PMIP multicast | # of redundant | # of sim. streams |
| scheme | streams at MAG | at LMA / LMA-M |
+===================+================+===================+
| Combined Unicast/ | 4 | 50 |
| Multicast LMA | | |
+-------------------+----------------+-------------------+
| Dedicated | 0 | 200 |
| Multicast LMA | | |
+-------------------+----------------+-------------------+
1,000,000 MNs are subscribed to the same multicast group
These considerations of extremal settings show that tunnel
convergence, i.e., duplicate data arriving at a MAG, does cause much
smaller problems in scalability than the stream replication at LMAs.
For scenario A it should be also noted that the high stream
replication requirements at LMAs in setting 1 can be attenuated by
deploying additional LMAs in a PMIP domain, while scenario B does not
allow for distributing the LMA-M, as no handover management is
available at LMA-M.
Appendix C. Change Log
The following changes have been made from
draft-schmidt-multimob-pmipv6-mcast-deployment-02.
1. Many editorial improvements, in particular as response to draft
reviews.
2. Section on IPv4 support added.
3. Added clarifications on initial IGMP/MLD Queries and
supplementary information in appendix.
4. Appendix added on comparative performance evaluation regarding
mixed/dedicated deployment of multicast at LMAs.
Schmidt, et al. Expires June 19, 2010 [Page 15]
Internet-Draft Multicast Listeners in PMIPv6 December 2009
Authors' Addresses
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
Email: mw@link-lab.net
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
Email: sarikaya@ieee.org
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Schmidt, et al. Expires June 19, 2010 [Page 16]