One document matched: draft-zuniga-multimob-smspmip-00.txt
MULTIMOB Group JC.Zuniga
Internet Draft G.Lu
Intended status: Standards Track A.Rahman
Expires: April 15, 2010 InterDigital Communications, LLC
October 15, 2009
Support Multicast Services Using Proxy Mobile IPv6
draft-zuniga-multimob-smspmip-00.txt
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 April 16 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zuniga, et al. Expires April 15, 2010 [Page 1]
Internet-Draft Multicast Services using PMIPv6 October 2009
Abstract
This document describes how multicast services can be supported with
Proxy Mobile IPv6 protocol [RFC5213], Multicast Listener Discovery
(MLDv2) protocol [RFC3810], and Internet Group Management Protocol
(IGMPv3)[RFC3376]. This document analyzes scenarios for multicast
service establishment and mobility. It also proposes the use of a
dedicated LMA for multicast services.
Table of Contents
1. Introduction...................................................2
2. Conventions and Terminology....................................3
3. Single LMA Supporting both Unicast and Multicast Services......3
3.1. Architecture..............................................3
3.2. Multicast Establishment...................................4
3.3. Multicast Mobility........................................5
4. Dedicated LMA Supporting Multicast Services....................6
4.1. Architecture..............................................6
4.2. Multicast Establishment...................................7
4.3. Multicast Mobility........................................9
5. Enhanced Multicast Mobility Support...........................10
5.1. Architecture.............................................11
5.2. Multicast Mobility.......................................11
6. MLD/IGMP Enhancements.........................................14
6.1. "Join" before Handover...................................14
6.2. Fast "Join" after HO.....................................14
7. Security Considerations.......................................14
8. IANA Considerations...........................................15
9. References....................................................15
9.1. Normative References.....................................15
9.2. Informative References...................................15
10. Acknowledgments..............................................16
1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving IP
mobility challenge. In a Proxy Mobile IPv6 domain, Mobile Access
Gateway (MAG) behaves as a proxy mobility agent in the network and
does the mobility management on behalf of the mobile node attached to
the network. Local Mobility Anchor (LMA) is the home agent for the
mobile node and the topological anchor point. Proxy Mobile IPv6 is
designed mainly for unicast services.
The Internet Group Management Protocol (IGMP) [RFC3376] is the
protocol used by IPv4 systems to report their IP multicast group
Zuniga, et al. Expires April 15, 2010 [Page 2]
Internet-Draft Multicast Services using PMIPv6 October 2009
memberships to neighboring multicast routers. The Multicast Listener
Discovery Protocol (MLD)[RFC3810] is used in a similar way as IGMP by
IPv6 routers to discover the presence of multicast listeners.
However, IGMP/MLD are not designed to address mobility issues.
Supporting multicast services has been under discussions within the
working group. This document focuses on addressing multicast mobility
scenarios using the Proxy Mobile IPv6 and IGMP/MLD protocols, and
proposing a new deployment architecture with a dedicated LMA for
multicast services. This document also provides two mechanisms to
reduce latency for IGMP/MLD.
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 [RFC-2119].
This document uses the terminology defined in [RFC5213], [RFC3775],
[RFC3810].
3. Single LMA Supporting both Unicast and Multicast Services
This section describes how multicast services and mobility can be
supported based on how Proxy Mobile IPv6 and MLD protocols work now.
To improve service continuity, some enhancements can be made, without
modifying the protocols. The enhancements are discussed in section 4,
5, and 6.
3.1. Architecture
Figure 1 illustrates the architecture using Proxy Mobile IPv6. In
this architecture, MAG provides multicast proxy functions as defined
in [RFC4605]. LMA serves as the multicast router and forwards
multicast services. LMA is also the anchor point for unicast
services.
Zuniga, et al. Expires April 15, 2010 [Page 3]
Internet-Draft Multicast Services using PMIPv6 October 2009
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Services * * Multicast Services*
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
| |
| |
| |
| |
| |
+-----+
| LMA |
+-----+
// \\
// \\
// \\
// \\
+-----+ +-----+
|p-MAG| |n-MAG|
+-----+ +-----+
| |
| |
{MN} -- Handover -> {MN}
Figure 1 Multicast Mobility Architecture
3.2. Multicast Establishment
Figure 2 shows the procedures of MN attachment and initiation of
unicast and multicast services. The unicast service is shown for the
purpose of completion and comparison.
The procedures from "MN Attachment" to the establishment of unicast
service are the same as defined in Proxy Mobile IPv6 [RFC5213]. MAG
provides multicast proxy functions as defined in [RFC4605]. LMA
serves as the multicast router and forwards multicast services. The
MLD Query message may occur before the MLD Report is sent, and they
are not shown in the figure for simplicity.
Zuniga, et al. Expires April 15, 2010 [Page 4]
Internet-Draft Multicast Services using PMIPv6 October 2009
MN MAG LMA
| | |
MN Attached | |
| | |
| | |
|---- Rtr Sol --->| |
| | |
| |--------PBU------ >|
| | |
| |<-------PBA------- |
| | |
| | |
| |===Bi-Dir Tunnel== |
| | |
|<----Rtr Adv---- | |
| | |
IP address | |
Configuration | |
| | |
|< -------Unicast Traffic----------- >|
| | |
| | |
|---MLD Report-- >| |
| |-----MLD Report-- >|
| | |
|<--------Multicast Traffic--------- >|
| | |
Figure 2 MN Attachment and Multicast Service Establishment
3.3. Multicast Mobility
Figure 3 shows the procedures of re-establishing the multicast
services when the MN moves within the same LMA. The MN shown in the
figure has both unicast and multicast sessions. This figure shows a
basic scenario that the MN needs to re-join the multicast services
after handover. There are ways to improve the multicast mobility
support and they are discussed in section 4, 5 and 6.
Zuniga, et al. Expires April 15, 2010 [Page 5]
Internet-Draft Multicast Services using PMIPv6 October 2009
MN p-MAG n-MAG LMA
| | | |
| | | |
|< --------------- Unicast Traffic -------------- >|
| | | |
|< ------------- Multicast Traffic -------------- >|
| | | |
Detached from p-MAG | | |
| | | |
| |----------- DeReg PBU--------- >|
| | | |
| |< -------------PBA ------------ |
Attached to n-MAG | | |
| | | |
|------------Rtr Sol ------------- >| |
| | |-----PBU---- >|
| | | |
| | |< ---PBA----- |
| | | |
| | |===Bi Dir === |
| | | tunnel |
|< ----------Rtr Adv--------------- | |
| | | |
|< --------------Unicast Traffic ---------------- >|
| | | |
| | | |
|---------------MLD Report-------- >| |
| | |-MLD Report- >|
| | | |
|<---------------Multicast Traffic--------------- >|
| | | |
Figure 3 Multicast Mobility
4. Dedicated LMA Supporting Multicast Services
A PMIPv6 domain may receive data from sources of both the unicast
services and multicast services. A dedicated LMA can be used to
serve as the anchor for multicast services. This section describes
how the multicast LMA works in scenarios of mobile node attachment
and multicast mobility.
4.1. Architecture
Figure 4 shows a PMIPv6 domain. One LMA is dedicated to unicast
services, and one is dedicated to multicast services. A MAG may
Zuniga, et al. Expires April 15, 2010 [Page 6]
Internet-Draft Multicast Services using PMIPv6 October 2009
connect to both LMAs, or only one LMA. A MN may receive unicast
and/or multicast services. In Figure 4, MN1 and MN2 have either
unicast or multicast services, or both. MN3 has multicast services
only.
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Services * * Multicast Services*
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
| |
| |
| |
+-----+ +-----+
| LMA | | LMA |
+-----+ +-----+
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+-----+ +-----+
| MAG | | MAG |
+-----+ +-----+
| | |
| | |
{MN1} {MN2} {MN3}
Figure 4 Architecture of Dedicated LMA as Multicast Anchor
4.2. Multicast Establishment
Figure 5 shows the procedure when two mobile nodes attach to the MAG,
and establish Proxy Mobile IPv6 tunnels, with the unicast LMA and
multicast LMA respectively.
Zuniga, et al. Expires April 15, 2010 [Page 7]
Internet-Draft Multicast Services using PMIPv6 October 2009
MN1 MN2 MAG LMA LMA
| | | (Unicast) (Multicast)
| | | | |
MN1 Attachment | | | |
| | | | |
|------Rtr Sol----- ->| | |
| | |--PBU -- >| |
| | | | |
| | |<-- PBA --| |
| | | | |
| | |=Unicast= | |
| | | Tunnel | |
|<-----Rtr Adv ------ | | |
| | | | |
|< ------ Unicast Traffic------ >| |
| | | | |
| MN2 Attachment | | |
| | | | |
| |-Rtr Sol >| | |
| | | | |
| |-- MLD -->| | |
| | Report | | |
| | |----- MLD Report---> |
| | | | |
| | |------------PBU---- >|
| | | | |
| | |< ----------PBA----- |
| | | | |
| | |==Multicast Tunnel ==|
| | | | |
| |<Rtr Adv- | | |
| | | | |
| |< ----- Multicast Traffic ---- >|
| | | | |
Figure 5 MN Attachment and Multicast Service Establishment
In the illustrated scenario, both MN1 and MN2 are attached to the
same MAG. MN1 is a "traditional" user for unicast services. The MAG
establishes the Proxy Mobile IPv6 tunnel with LMA for unicast
services as defined in [RFC5213].
MN2 requires multicast services. It may indicate its multicast
request in the Router Solicitation request. MAG sends the Proxy
Binding Update to the multicast LMA, and establishes the tunnel for
multicast services. MAG may use a multicast CoA so the multicast
Zuniga, et al. Expires April 15, 2010 [Page 8]
Internet-Draft Multicast Services using PMIPv6 October 2009
tunnel can be shared by multiple MNs that subscribed to the same
multicast services. The MN sends the MLD report message as defined in
[RFC3810].
A MN may have multiple interfaces, and requires both unicast and
multicast services simultaneously.
The multicast tunnel may be downlink-only or bi-directional.
4.3. Multicast Mobility
Figure 6 illustrates the mobility scenario for multicast services,
using the dedicated multicast LMA. The figure shows a MN with both
unicast services and multicast services. In the scenario discussed
below, it is assumed that the p-MAG and n-MAG are connected to both
the unicast LMA and multicast LMA.
When the MN detaches from the p-MAG, the p-MAG deregisters from the
unicast LMA, as defined in [RFC5213]. However, the p-MAG should keep
the multicast tunnel with the multicast LMA if there are still other
MNs using the multicast tunnel. Even if there is no MN on the
multicast tunnel, the p-MAG may decide to keep the multicast tunnel.
When the MN attaches to the n-MAG, the MN sends MLD reports, and the
n-MAG establishes the multicast tunnel with the multicast LMA, same
as described in section 4.2.
It is possible that the multicast tunnel is already available at n-
MAG when the MN attaches to n-MAG. Therefore the n-MAG can
distribute the multicast traffic to the MN, using either the unicast
or multicast L2 connection between n-MAG and MN.
Zuniga, et al. Expires April 15, 2010 [Page 9]
Internet-Draft Multicast Services using PMIPv6 October 2009
MN p-MAG n-MAG LMA LMA
| | | (Unicast)(Multicast)
| | | | |
| | | | |
| |=====Unicast Tunnel==== | |
| | | | |
| |========= Multicast Tunnel ======= |
| | | | |
MN Detached | | | |
| | | | |
| remove unicast | | |
| tunnel | | |
| |-------DeReg PBU ----- >| |
| | | | |
| |< ---------PBA--------- | |
| | | | |
MN Attached | | | |
To n-MAG | | | |
| | | | |
|---------Rtr Sol------ >| | |
| | | | |
|----------MLD Report-- >| | |
| | |---- MLD Report ----- >|
| | | | |
| | |------- PBU --------- >|
| | | | |
| | |<------PBA ----------- |
| | | | |
|< --------Rtr Adv------ |==Multicast Tunnel==== |
| | | | |
| . . . |
| Establishment of new unicast tunnel is |
| the same as defined in [RFC5213] |
| . . . |
| | | | |
Figure 6 Multicast Mobility
5. Enhanced Multicast Mobility Support
This section discusses how multicast mobility can be enhanced when
indications of handover triggers are available. Traditionally, the
new PMIP tunnel is established after the MN is attached to the n-MAG,
which can cause long delay for multicast services. In this section,
handover triggers are used to establish the tunnels before the MN is
attached to the n-MAG.
Zuniga, et al. Expires April 15, 2010 [Page 10]
Internet-Draft Multicast Services using PMIPv6 October 2009
5.1. Architecture
The handover scenarios can apply to the single LMA architecture
illustrated in section 3.1, or the dedicated multicast LMA
illustrated in section 4.1. They can apply to both unicast and
multicast services. For simplicity, only the single LMA architecture
and multicast services are depicted in the figures.
5.2. Multicast Mobility
Handover triggers may occur in the MN or the network. The MN can get
predictive indications of imminent handover, for example, using some
L2 measurements. A MN can initiate a handover due to the request of
an application. A MN can also get handover command from the network.
In such cases, the MN can send an indication of imminent handover to
the p-MAG. The p-MAG forwards the indication to n-MAG, including the
multicast information of the MN. This helps the n-MAG to establish
the multicast with LMA faster. The n-MAG can use a multicast CoA for
the multicast tunnel. Therefore when the MN attaches to the n-MAG,
the multicast service can be available. The figure shows the binding
update occurs before the handover. Binding update may happen after
the handover. The p-MAG can decide to keep or tear down the old
tunnel. The procedure is illustrated in Figure 7.
The protocol to transport the HO trigger message is beyond the scope
of this document. For example, the context transfer method proposed
in [RFC4067] can be used.
Zuniga, et al. Expires April 15, 2010 [Page 11]
Internet-Draft Multicast Services using PMIPv6 October 2009
MN p-MAG n-MAG LMA
| | | |
HO trigger | | |
at MN | | |
| | | |
|---HO Trigger -->| | |
| | | |
| | | |
| |---HO Trigger-- >| |
| | (MN multicast) | |
| | info | |
| | | |
| | | |
| | |-----PBU---- >|
| | | |
| | |< ---PBA----- |
| | | |
| | |===Multicast= |
| | | tunnel |
| | | |
MN Detaches from p-MAG | | |
MN Attaches to n-MAG | | |
| | | |
| | | |
|<----------------- Multicast Traffic ----------- >|
| | | |
Figure 7 Indication of Handover Triggers between MAGs
Zuniga, et al. Expires April 15, 2010 [Page 12]
Internet-Draft Multicast Services using PMIPv6 October 2009
Figure 8 illustrates an alternative way that the HO trigger is passed
from the MN to p-MAG, and p-MAG forwards it to LMA. This scenario
applies when there is no direct interface between p-MAG and n-MAG.
To reuse the mechanisms defined in [RFC5213] without modification,
the HO trigger is forwarded from LMA to n-MAG, while n-MAG initiates
the tunnel establishment procedure with LMA as defined in [RFC5213].
MN p-MAG n-MAG LMA
| | | |
HO Trigger | | |
at MN | | |
| | | |
|--HO trigger --->| | |
| | | |
| |----------- HO Trigger -------- >|
| | (MN multicast info) |
| | | |
| | |<-HO Trigger --|
| | |(MN multicast) |
| | | info |
| | | |
| | |------PBU---- >|
| | | |
| | |< --- PBA----- |
| | | |
| | |===Multicast== |
| | | tunnel |
| | | |
MN Detaches from p-MAG | | |
MN Attaches to n-MAG | | |
| | | |
| | | |
|<-----------------Multicast Traffic-------------- >|
| | | |
Figure 8 Indication of Handover Triggers to LMA
The handover trigger may come from the network side, for example, due
to operator policies, load balancing, etc.
If either LMA or MAG is aware of the imminent handover from the
network side, LMA or MAG can initiate the establishment of the
multicast tunnels. The steps between MAG and LMA are the same as
illustrated in Figure 7 and Figure 8.
Zuniga, et al. Expires April 15, 2010 [Page 13]
Internet-Draft Multicast Services using PMIPv6 October 2009
There are cases that the HO trigger is not generated at p-MAG or LMA.
For example, the HO trigger may be originated from a policy control
entity in the network, and passed to a corresponding mobility entity
in the MN. The MN can send the HO trigger to the p-MAG, same as the
procedures shown in Figure 7 and Figure 8.
6. MLD/IGMP Enhancements
The multicast services can be interrupted after MN handover, due to
service re-initiation. Therefore the key to enhance the MLD/IGMP
performance is to reduce the delay caused by service re-initiation.
Two methods to reduce handover delay for multicast services are
proposed below.
6.1. "Join" before Handover
In the scenarios discussed in section 5, a HO trigger is sent to n-
MAG before the MN attaches to n-MAG. n-MAG can use the multicast
information in the HO trigger message to enable the multicast
services before the handover occurs. This is like the MN "joins"
before the handover.
In an alternative architecture, if imminent handover is known by a
mobility management entity in the network, the mobility management
entity can "join" the multicast group on behalf of the MN with the
appropriate multicast router in the target network.
6.2. Fast "Join" after HO
Right after the handover is completed, the mobility management entity
in the MN can trigger the sending of a MLD/IGMP Report immediately,
without waiting for the Query from the multicast router.
The above proposed mechanisms can be used independently or jointly.
For example, if a "join" before handover is not working, a fast
"join" after HO can still work and reduce the service delay.
7. 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].
Zuniga, et al. Expires April 15, 2010 [Page 14]
Internet-Draft Multicast Services using PMIPv6 October 2009
8. IANA Considerations
This document makes no request of IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 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.
9.2. Informative References
[I-D.deng-multimob-pmip6-requirement]
Deng, H., Schmidt, T., Seite, P., and P.Yang, "Multicast
Support Requirements for Proxy Mobile IPv6", draft-deng-
multimob-pmip6-requirements-02 (Work in progress), July 13,
2009.
[I-D.schmidt-multimob-pmipv6-mcast-deployment-01] Schmidt, T.,
Waehlisch, M., Sarikaya, B., and S.Krishnan, "A Minimal
Deployment Option for Multicast Listeners in PMIPv6
Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-01
(Work in progress), June 29, 2009.
Zuniga, et al. Expires April 15, 2010 [Page 15]
Internet-Draft Multicast Services using PMIPv6 October 2009
[RFC4067] Loughney, Ed.,J., Nakhjiri, M., Perkins, C., and R. Roodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
10. 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 April 15, 2010 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 05:44:07 |