MULTIMOB Group JC.Zuniga
Internet Draft G.Lu
Intended status: Standards Track A.Rahman
Expires: November 30, 2010 InterDigital Communications, LLC
May 31, 2010
Support Multicast Services Using Proxy Mobile IPv6
draft-zuniga-multimob-smspmip-03.txt
Abstract
The MULTIMOB group has specified a base solution to support IP
multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base-
solution]. In this document, an enhancement is proposed to the base
solution to use a dedicated multicast LMA as the topological anchor
point for multicast traffic, while the MAG remains as an IGMP/MLD
proxy. This enhancement provides benefits such as reducing multicast
traffic replication and reducing complexity of PMIPv6 deployments.
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 30, 2010.
Zuniga, et al. Expires November 30, 2010 [Page 1]
Internet-Draft Multicast Services using PMIPv6 May 2010
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1. Introduction...................................................2
2. Conventions and Terminology....................................3
3. Solution.......................................................3
3.1. Architecture..............................................3
3.2. Multicast Establishment...................................5
3.3. Multicast Mobility........................................7
3.4. Advantages................................................8
4. Security Considerations.......................................12
5. IANA Considerations...........................................12
6. References....................................................12
6.1. Normative References.....................................12
6.2. Informative References...................................12
7. Acknowledgments...............................................13
1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving
the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the
Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the
network and does the mobility management on behalf of the Mobile Node
(MN). The Local Mobility Anchor (LMA) is the home agent for the MN
and the topological anchor point. PMIPv6 was originally designed for
unicast traffic.
Zuniga, et al. Expires November 30, 2010 [Page 2]
Internet-Draft Multicast Services using PMIPv6 May 2010
The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by
IPv4 hosts to report their IP multicast group memberships to
neighboring multicast routers. Multicast Listener Discovery (MLDv2)
[RFC3810] is used in a similar way by IPv6 routers to discover the
presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605]
allows an intermediate (edge) node to appear as a multicast router to
downstream hosts, and as a host to upstream multicast routers. IGMP
and MLD related protocols were not originally designed to address IP
mobility of multicast listeners (i.e. IGMP and MLD protocols were
originally designed for fixed networks).
The MULTIMOB group has specified a base solution to support IP
multicast listener mobility in a PMIPv6 domain [I-D.draft-ietf-
multimob-pmipv6-base-solution]. In this document, an enhancement is
proposed to the base solution to use a dedicated multicast LMA as the
topological anchor point for multicast traffic, while the MAG remains
as an IGMP/MLD proxy. This enhancement reduces complexity of PMIPv6
deployments. It also eliminates the so called "Tunnel Convergence
problem" where the MAG may receive the same multicast packet from
several LMAs. There are no impacts to the MN to support multicast
listener mobility from this document.
2. Conventions and Terminology
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 [RFC2119].
This document uses the terminology defined in [RFC5213], [RFC3775],
and [RFC3810].
3. Solution
A PMIPv6 domain may receive data from both unicast and multicast
sources. A dedicated multicast LMA can be used to serve as the
mobility anchor for multicast traffic. Unicast traffic will go
normally to the other LMAs in the PMIPv6 domain. This section
describes how the multicast LMA works in scenarios of MN attachment
and multicast mobility.
3.1. Architecture
Figure 1 shows an example of a PMIPv6 domain supporting multicast
mobility. LMA1 is dedicated to unicast traffic, and LMA2 is dedicated
to multicast traffic. The multicast traffic LMA (LMA2) can be
considered to be a form of upstream multicast router with tunnel
interfaces allowing remote subscription for the MNs. Note that there
Zuniga, et al. Expires November 30, 2010 [Page 3]
Internet-Draft Multicast Services using PMIPv6 May 2010
can multiple LMAs for unicast traffic (not shown in Figure 1) in a
given PMIPv6 domain. Similarly, more than one multicast dedicated LMA
can be deployed by the operator (not shown in Figure 1).
Also in this architecture, all MAGs that are connected to the
multicast LMA must support the MLD proxy [RFC4605] function.
Specifically in Figure 1, each of the MAG1-LMA2 and MAG2-LMA2 tunnel
interfaces defines an MLD proxy domain. The MNs are considered to be
on the downstream interface of the MLD proxy (in the MAG), and LMA2
is considered to be on the upstream interface (of the MAG) as per
[RFC4605]. Note that MAG could also be an IGMP proxy. For brevity
this document will refer primarily to MLD proxy, but all references
to "MLD proxy" should be understood to also include "IGMP/MLD proxy"
functionality.
As shown in Figure 1, MAG1 may connect to both unicast and multicast
LMAs. Thus, a given MN may simultaneously receive both unicast and
multicast traffic. In Figure 1, MN1 and MN2 receive unicast traffic,
multicast traffic, or both, whereas MN3 receives multicast traffic
only.
Zuniga, et al. Expires November 30, 2010 [Page 4]
Internet-Draft Multicast Services using PMIPv6 May 2010
+--------------+
|Content Source|
+--------------+
|
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
| |
| |
| |
+-----+ +------+
Unicast | LMA1| | LMA2 | Multicast
Anchor +-----+ +------+ Anchor
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+-----+ +-----+
| MAG1| | MAG2| MLD Proxy
+-----+ +-----+
| | |
| | |
{MN1} {MN2} {MN3}
Figure 1 Architecture of Dedicated LMA as Multicast Anchor
3.2. Multicast Establishment
Figure 2 shows the procedure when MN1 attaches to MAG1, and
establishes associations with LMA1 (unicast) and LMA2 (multicast).
Zuniga, et al. Expires November 30, 2010 [Page 5]
Internet-Draft Multicast Services using PMIPv6 May 2010
MN1 MAG1 LMA1 LMA2
| (MLD Proxy) (Unicast) (Multicast)
MN attaches to MAG1 | | |
| | | |
|------Rtr Sol----- ->| | |
| |--PBU -- >| |
| | | |
| |<-- PBA --| |
| | | |
| |=Unicast= | |
| | Tunnel | |
|<-----Rtr Adv ------ | | |
| | | |
|< ------ Unicast Traffic------ >| |
| | | |
| |==Multicast Tunnel ==|
| | | |
|<--MLD Query --------| | |
| | | |
MN requires multicast services | |
| | | |
|---MLD Report (G) -->| | |
| | | |
| |---- Aggregated ---> |
| | MLD Report (G) |
| | | |
| | | |
|< --------- Multicast Traffic ----------- >|
| | | |
Figure 2 MN Attachment and Multicast Service Establishment
In Figure 2, MAG1 first establishes the PMIPv6 tunnel with LMA1 for
unicast traffic as defined in [RFC5213] after being triggered by the
Router Solicitation message from MN1. Unicast traffic will then flow
between MN1 and LMA1.
For multicast traffic, a multicast tunnel may have been pre-
configured between MAG1 and the multicast LMA (LMA2). Or the
multicast tunnel may be dynamically established when the first MN
appears at the MAG.
MN1 sends the MLD report message (when required by its upper layer
applications) as defined in [RFC3810] in response to an MLD Query
from MAG1. MAG1 acting as a MLD Proxy as defined in [RFC4605] will
Zuniga, et al. Expires November 30, 2010 [Page 6]
Internet-Draft Multicast Services using PMIPv6 May 2010
then send an Aggregated MLD Report to the multicast anchor, LMA2
(assuming that this is a new multicast group which MAG1 had not
previously subscribed to). Multicast traffic will then flow from
LMA2 towards MN1.
3.3. Multicast Mobility
Figure 3 illustrates the mobility scenario for multicast traffic.
Specifically, MN2 with ongoing multicast subscription moves from MAG1
to MAG2. Note that, for simplicity, in this scenario MAG2 is
connected only to LMA2 (multicast) and does not receive unicast
traffic. Of course, if it was desired to support unicast traffic,
the architecture will easily allow MAG2 to also connect to LMA1 to
support unicast traffic.
After MN2 mobility, MAG2 acting in its role of MLD proxy will send an
MLD Query to the newly observed MN on its downlink. Assuming that
the subsequent MLD Report from MN2 requests membership of a new
multicast group (from MAG2's point of view), this will then result in
an Aggregated MLD Report being sent to LMA2 from MAG2. This message
will be sent through a pre-established (or dynamically established)
multicast tunnel between MAG2 and LMA2.
When MN2 detaches, MAG1 may keep the multicast tunnel with the
multicast LMA2 if there are still other MNs using the multicast
tunnel. Even if there are no MNs currently on the multicast tunnel,
MAG1 may decide to keep the multicast tunnel for potential future
use.
As discussed above, existing MLD (and Proxy MLD) signaling will
handle a large part of the multicast mobility management for the MN.
Zuniga, et al. Expires November 30, 2010 [Page 7]
Internet-Draft Multicast Services using PMIPv6 May 2010
MN2 MAG1 MAG2 LMA1 LMA2
| (MLD Proxy) (MLD Proxy) (Unicast)(Multicast)
| | | | |
MN Attached | | | |
To MAG1 | | | |
| | | | |
| |========= Multicast Tunnel ======= |
| | | | |
MN Detaches | | | |
From MAG1 | | | |
| | | | |
| | | | |
MN Attaches | | | |
To MAG2 | | | |
| | | | |
| | |==Multicast Tunnel === |
| | | | |
|---------Rtr Sol------ >| | |
| | | | |
|<-----Rtr Adv --------- | | |
| | | | |
| | | | |
|<---------MLD Query---- | | |
| | | | |
|---MLD Report (G) ----> | | |
| | | | |
| | |---- Aggregated -----> |
| | | MLD Report (G) |
| | | | |
| | | | |
|< --------- Multicast Traffic ---------------- >|
| | | | |
| | | | |
Figure 3 Multicast Mobility Signaling
3.4. Advantages
An advantage of the proposed dedicated multicast LMA architecture is
that it allows a PMIPv6 domain to closely follow a simple multicast
tree topology for Proxy MLD forwarding (cf., sections 1.1 and 1.2 of
[RFC4605]). In contrast, the combined unicast/multicast LMA as
proposed in [I-D.draft-ietf-multimob-pmipv6-base-solution] will be a
more complex set of trees.
Zuniga, et al. Expires November 30, 2010 [Page 8]
Internet-Draft Multicast Services using PMIPv6 May 2010
Another advantage of the proposed dedicated multicast solution is
that it allows a gradual network upgrade of a PMIPv6 domain to
support multicast functionality. This is because the operator does
not have to upgrade all the LMAs in the network to support multicast
functionality. Only certain LMAs, dedicated to multicast support,
will have to be upgraded to support the new multicast functionality.
A final advantage is that a dedicated multicast LMA minimizes
replication of multicast packets (the Tunnel Convergence problem), in
certain scenarios, compared to [I-D.draft-ietf-multimob-pmipv6-base-
solution]. Figures 4 and 5 illustrate this point visually. For this
simple scenario, it can be observed that the dedicated multicast LMA
topology (Figure 4) generates 6 packets for one input multicast
packet. In comparison, the combined unicast/multicast LMA topology
(Figure 5) generates 8 packets for one input multicast packet.
In general, it can be seen that the extra multiplication of packets
in the combined unicast/multicast LMA topology will be proportional
to the number of LMAs, and the number of MNs (in a given MAG)
associated to different LMAs, for a given multicast group. The
packet multiplication problem aggravates as more MNs associated to
different LMAs receive the same multicast traffic when attached to
the same MAG. Hence, the dedicated multicast architecture
significantly decreases the network capacity requirements in this
scenario.
(Note that in Figure 4, it is assumed that MN1 and MN2 are associated
with MAG1-LMA1, and MN3 is associated with MAG2-LMA2 for multicast
traffic. In Figure 5, it is assumed that MN1 is associated with
MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated
with MAG2-LMA2 for multicast traffic. In both Figures 4 and 5, it is
assumed that the packets are transmitted point to point on the last
hop wireless link.)
Zuniga, et al. Expires November 30, 2010 [Page 9]
Internet-Draft Multicast Services using PMIPv6 May 2010
+--------------+
|Content Source|
+--------------+
|
|
+---+ Packet destined
| 1 | for Multicast group "G"
+---+
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
| |
| +---+
| | 2 |
| +---+
| |
+-----+ +------+
Unicast | LMA1| | LMA2 | Multicast
Anchor +-----+ +------+ Anchor
\\ //||
\\ // ||
\\ // ||
\\ // ||
\\ +---+ +---+
\\ | 3 | | 4 |
\\ +---+ +---+
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+-----+ +-----+
| MAG1| | MAG2| MLD Proxy
+-----+ +-----+
| | |
+---+ +---+ +---+
| 5 | | 6 | | 7 |
+---+ +---+ +---+
| | | All MNs in same
| | | multicast group "G"
{MN1} {MN2} {MN3}
Figure 4 Packet Flow in a Dedicated Multicast LMA
Zuniga, et al. Expires November 30, 2010 [Page 10]
Internet-Draft Multicast Services using PMIPv6 May 2010
+--------------+
|Content Source|
+--------------+
|
|
+---+ Packet destined
| 1 | for Multicast group "G"
+---+
|
*** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** ***
| |
+---+ +---+
| 2 | | 3 |
+---+ +---+
| |
+-----+ +------+
| LMA1| | LMA2 | Combined
+-----+ +------+ Unicast/Multicast
\\ // || Anchor
\\ // ||
\\ // ||
\\ // ||
+---+ +---+ +---+
| 4 | | 5 | | 6 |
+---+ +---+ +---+
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+-----+ +-----+
| MAG1| | MAG2| MLD Proxy
+-----+ +-----+
| | |
+---+ +---+ +---+
| 7 | | 8 | | 9 |
+---+ +---+ +---+
| | | All MNs in same
| | | multicast group "G"
{MN1} {MN2} {MN3}
Figure 5 Packet Flow in a Combined Unicast/Multicast LMA
Zuniga, et al. Expires November 30, 2010 [Page 11]
Internet-Draft Multicast Services using PMIPv6 May 2010
4. Security Considerations
This draft discusses the operations of existing protocols without
modifications. It does not introduce new security threats beyond the
current security considerations of PMIPv6 [RFC5213], MLD [RFC3810],
IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605].
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[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.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[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.
6.2. Informative References
[I-D.draft-ietf-multimob-pmipv6-base-solution] Schmidt, T.C.,
Waehlisch, M., and S.Krishnan, "Base Deployment for
Multicast Listener Support in PMIPv6 Domains", draft-ietf-
multimob-pmipv6-base-solution-01 (Work in progress), May
25, 2010.
Zuniga, et al. Expires November 30, 2010 [Page 12]
Internet-Draft Multicast Services using PMIPv6 May 2010
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: JuanCarlos.Zuniga@InterDigital.com
Guang Lu
InterDigital Communications, LLC
Email: Guang.Lu@InterDigital.com
Akbar Rahman
InterDigital Communications, LLC
Email: Akbar.Rahman@InterDigital.com
Zuniga, et al. Expires November 30, 2010 [Page 13]