NETLMM WG Hong-ke Zhang
Internet Draft Jian-feng Guan
Expires: March 2009 Hua-chun Zhou
Ying Zhu
Beijing Jiaotong University, NGIRC
September 4, 2008
Multicast Routing in Proxy Mobile IPv6
draft-zhang-netlmm-pmipv6-mcast-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may only be posted in an Internet-Draft.
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 February 4, 2009.
Abstract
With the development of various mobile technologies, mobile multicast
becomes a research hotspot. Several mobile multicast schemes were
proposed, but most of them are based on the Mobile IPv6 and its
alternatives. Recently, the Proxy Mobile IPv6 (PMIPv6) was proposed
to provide the mobility support for mobile node without mobility
function. However, the PMIPv6 mainly concerns on the unicast
transmission support, and little considers the multicast routing. So,
in this memo, we propose two mobile multicast mechanisms, the MAG-
Zhang, et al. Expires March 4, 2009 [Page 1]
Internet-Draft Multicast Routing in PMIPv6 September 2008
based method and LMA-based method to support the multicast routing in
PMIPv6.
Table of Contents
1. Introduction.................................................2
2. Conventions & Terminology....................................3
2.1. Conventions used in this document.......................3
2.2. Terminology.............................................3
3. Overview of Multicast Routing in PMIPv6......................4
4. Working flow.................................................5
4.1. MAG-based mobile multicast..............................5
4.1.1. Scenario 1: Intra-PMIPv6 domain roaming............5
4.1.2. Scenario 2: Inter-PMIPv6 domain Roaming............6
4.2. LMA-based mobile multicast..............................7
4.2.1. Scenario 1: Intra-PMIPv6 domain roaming............7
4.2.2. Scenario 2: Inter-PMIPv6 domains roaming...........9
5. Protocol Configuration Variables.............................9
6. Security Considerations......................................9
7. IANA Considerations..........................................9
8. Conclusions.................................................10
9. Acknowledgments.............................................10
10. References.................................................11
10.1. Normative References..................................11
10.2. Informative References................................11
Author's Addresses.............................................12
Intellectual Property Statement................................12
Disclaimer of Validity.........................................12
Copyright Statement............................................13
Acknowledgment.................................................13
1. Introduction
With the development of mobile and wireless communication
technologies, multicast technology has developed from fixed platform
to wireless and mobile platform, and the mobile multicast technology
was proposed. Mobile multicast has to handle the dynamic membership
and manage mobile subscribers. The Multicast Listener Discovery (MLD)
[3] [4] protocol was proposed to manage the dynamic membership for
IPv6 (IPv4 uses the Internet Group Management Protocol), but it
cannot maintain the continuous multicast session for the mobile
subscribers. To support the mobile subscribers, The current mobile
multicast schemes mainly depend on the MIPv6 [5] and its variants
which are the host-based mobility management protocols, and require
the mobile nodes to involve in the mobility signaling. As a result,
the mobile node needs to implement new mobility support
Zhang, et al. Expires March 4, 2009 [Page 2]
Internet-Draft Multicast Routing in PMIPv6 September 2008
specifications which increases the process overhead. Recently, the
IETF NETLMM workgroup proposes the Proxy Mobile IPv6 (PMIPv6) [6]
protocol which provides the mobility support for mobile nodes without
involvement of mobility signaling. But the current PMIPv6
specification does not consider multicast routing. In this memo, we
proposed two mobile multicast methods to address the issues and
requirement of mobile multicast in PMIPv6.
2. Conventions & Terminology
2.1. Conventions used in this document
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 [1].
2.2. Terminology
All the general mobility related terms used in this document are to
be interpreted as defined in the Mobile IPv6 base specification [5].
This document adopts the terms, Local Mobility Anchor (LMA) and
Mobile Access Gateway (MAG) from the NETLMM Goals document [8]. This
document mainly uses the following terms in this document.
Proxy Mobile IPv6 Domain (PMIPv6-Domain)
Proxy Mobile IPv6 domain refers to the network where the mobility
management of a mobile node is handled using the Proxy Mobile IPv6
protocol as defined in this specification. The Proxy Mobile IPv6
domain includes local mobility anchors and mobile access gateways
between which security associations can be setup and authorization
for sending Proxy Binding Updates on behalf of the mobile nodes can
be ensured.
Local Mobility Anchor (LMA)
Local Mobility Anchor is the home agent for the mobile node in the
Proxy Mobile IPv6 domain. It is the topological anchor point for the
mobile node's home network prefix and is the entity that manages the
mobile node's binding state. The local mobility anchor has the
functional capabilities of a home agent as defined in Mobile IPv6
base specification [5] with the additional capabilities required for
supporting Proxy Mobile IPv6 protocol as defined in this
specification.
Mobile Access Gateway (MAG)
Zhang, et al. Expires March 4, 2009 [Page 3]
Internet-Draft Multicast Routing in PMIPv6 September 2008
Mobile Access Gateway is a function that manages the mobility related
signaling for a mobile node that is attached to its access link. It
is responsible for tracking the mobile node's movements to and from
the access link and for signaling the mobile node's local mobility
anchor.
Mobile Node (MN)
Throughout this document, the term mobile node is used to refer to an
IP host or router whose mobility is managed by the network. The
mobile node may be operating in IPv6 mode, IPv4 mode or inIPv4/IPv6
dual mode. The mobile node is not required to participate in any IP
mobility related signaling for achieving mobility for an IP address
that is obtained in that Proxy Mobile IPv6 domain.
3. Overview of Multicast Routing in PMIPv6
This document describes two basic multicast forwarding mechanisms in
the PMIPv6 based on the configuration variable which is noted as the
EnableMAGLocalMulticastRouting to control two different methods in
multicast routing.
The choice of the two methods SHOULD be based on the policy
configured on the MAG, but enforced by the LMA. The specific details
on how this is achieved are beyond of the scope of this document.
In the PMIPv6, the MAG is a function that typically runs on an access
router in IP level and acts as a default router for mobile nodes
connected to it. So in case of mobile multicast in PMIPv6, the MAG
SHOULD support multicast routing which includes the group membership
management, the multicast state maintenance and the multicast packets
forwarding.
If EnableMAGLocalMulticastRouting is enabled to route the multicast
packets locally in the MAG, the MAG MAY optimize the path by locally
joining the group on behalf of the MN and routing the packets and by
not reverse tunneling them to the LMA. MAG MAY choose to route the
multicast packets directly from/to upstream multicast router locally.
The mobile node uses the link-local address as the source address and
sends the MLD messages. The MAG performs the join procedure after
receiving the MLD message. For the mobile node that wants to send the
multicast packets to a multicast group, it sends the multicast
packets directly on the attached link, and then MAG forwards the
multicast packets to the established multicast distribution tree. We
call this mechanism the MAG-based mobile multicast.
If the MAG is not allowed to route the multicast packets locally, the
MAG SHOULD tunnel the MLD report message from the mobile node to the
LMA. This mechanism requires that not only the MAG but also the LMA
support the multicast routing function through the bi-directional
Zhang, et al. Expires March 4, 2009 [Page 4]
Internet-Draft Multicast Routing in PMIPv6 September 2008
tunnel, so that LMA can de-capsulate the MLD report message from the
MAG and join the group on behalf of the mobile nodes. The mobile node
uses the global address as the source address to send the MLD message.
The MAG MAY performs the MLD proxy function to sets up the multicast
listener state for mobile nodes and forwards the aggregated MLD
messages through the bi-directional tunnel between the MAG and the
LMA. The LMA sets up the multicast state and joins the group.
Multicast packets SHOULD be tunneled to the MAG after being received
by the LMA. The MAG forwards these packets to the MN according to the
multicast listener state in the MAG after receiving the tunneled
multicast packets. When mobile node serves as a multicast source and
sends packets to a group, it sends the multicast packets to the MAG
at first, and then MAG encapsulates these packets and forwards them
to the LMA through the bi-directional tunnel. We call this
mechanism the LMA-based mobile multicast.
4. Working flow
4.1. MAG-based mobile multicast
4.1.1. Scenario 1: Intra-PMIPv6 domain Roaming
The MAG-based mobile multicast mechanism transmits the multicast
through the local multicast router and it requires the MAG supports
the multicast routing.
Figure 1 shows the procedure of MAG-based mobile multicast mechanism
in detail. Assume that mobile node attaches to P-MAG at first, and
then it attaches to the N-MAG. After attaching to the P-MAG, the
mobile node joins a multicast group. When the mobile node moves from
the P-MAG to the N-MAG, it sends the unsolicited MLD report message
including the joined multicast group information as soon as it
finished the link-local address configuration. N-MAG firstly
authenticates the mobile node for PMIPv6 services, and then acquires
the profile information of mobile node. After that, N-MAG performs
binding process with the LMA. If the N-MAG is allowed to forward the
multicast packets locally which means the
EnableMAGLocalMulticastRouting is enabled, the N-MAG will set up the
multicast listener state and joins the multicast delivery tree to
transmit the multicast packets to mobile node.
On receiving the multicast packets from the local multicast router,
the MAG checks the EnableMAGLocalMulticastRouting flag to ensure the
MAG is allowed to route the multicast packets directly to the mobile
node. If the MAG is not allowed to route the packets directly, it
must discard these packets. On receiving the multicast packets from
the mobile node as a source, MAG should firstly ensure that it is
Zhang, et al. Expires March 4, 2009 [Page 5]
Internet-Draft Multicast Routing in PMIPv6 September 2008
allowed to forward the multicast locally. MAG forwards these
multicast packets according to its multicast routing state.
N-MAG MN P-MAG LMA local-MR
| | | | |
| Attachment MN attached event | |
| | (accquire MN-Id and Profile) | |
| | |<-----register----->| |
| | |====bi-dir tunnel===| |
| |------RS----->| | |
| |<-----RA------| | |
| address configuration | | |
| |--MLD Report->| | |
| | |---MLD Report/Join message-->|
| | |<---multicast packets------- |
| |<--multicast--| | |
| | packets | | |
| | | | |
MN attached event | | | |
(acquire MN-Id handover MN detached event | |
and Profile) | |<----deregister---->| |
| | | |
|<--------------------Register------------------->| |
|================bi-directional tunnel============| |
|<-----RS-----| | | |
|------RA---->| | | |
|<-MLD Report-| | | |
|-----------------MLD Report/Join message----------------->|
|<---------------------multicast packets-------------------|
|--multicast->| | | |
| packets | | | |
| | | | |
Figure 1 the work flow of MAG-based mobile multicast
Generally speaking, the MAG-based mechanism joins the group through
the access link directly, so it is more scalable and has the optimal
multicast delivery path. However, it may have long join delay
especially when the multicast delivery tree is far away the current
MAG. Moreover in some systems, this mechanism may cause problem in
applying traffic policies or accounting for those multicast traffic.
4.1.2. Scenario 2: Inter-PMIPv6 domain Roaming
(TBD)
Zhang, et al. Expires March 4, 2009 [Page 6]
Internet-Draft Multicast Routing in PMIPv6 September 2008
4.2. LMA-based mobile multicast
4.2.1. Scenario 1: Intra-PMIPv6 Domain Roaming
The LMA-based method transmits the multicast packets through the LMA,
and it requires the LMA to support the multicast routing, and
requires the MAG to forward the MLD messages between LMA and mobile
nodes through bi-directional tunnel. Figure 2 shows the operation
flow in detail. Assume that a mobile node attaches to P-MAG at first,
and then it attaches to the N-MAG. After the mobile node attaches to
the P-MAG, it sends a join message such as the MLD report message to
join the multicast group. The P-MAG will forward this join message to
the LMA through the tunnel. The LMA, after receiving this message,
sets up the multicast state for the group and transmits the multicast
packets through the bi-directional tunnel between the P-MAG and the
LMA. When mobile node moves from P-MAG to N-MAG, it sends the
unsolicited MLD report message to N-MAG as soon as it finished the
global address configuration. The N-MAG sets up the multicast
listener states and forwards the multicast packets to mobile node
after receiving the encapsulated multicast packets from the LMA.
The LMA records the multicast listener state for every tunnel, and
maintains the group membership on behalf of every mobile node. On
receiving the multicast packets that the mobile nodes joined, the LMA
MUST forward the multicast packets to the corresponding tunnel. When
the MN sends the multicast packets, the LMA, after removing the
tunnel header, MUST forward these packets to multicast router that
attached to the LMA according to the multicast routing table.
Zhang, et al. Expires March 4, 2009 [Page 7]
Internet-Draft Multicast Routing in PMIPv6 September 2008
N-MAG MN P-MAG LMA MR
| | | | |
| Attachment MN attached event | |
| | (acquire MN-Id and Profile) | |
| | |<-----register----->| |
| | |====bi-dir tunnel===| |
| |------RS----->| | |
| |<-----RA------| | |
| address configuration | | |
| |--MLD Report->| | |
| | |=====MLD Report ====| |
| | | (Join message) | |
| | | |MLD Report
| | | |------->|
| | | (Join message)
| | | | |
| | | | multicast
| | | |<-------|
| | | | packets|
| | |==multicast packets=| |
| |<--multicast--| | |
| | packets | | |
MN attached event | | | |
(acquire MN-Id handover MN detached event | |
and Profile) | |<----deregister---->| |
| | | |
|<--------------------Register------------------->| |
|================bi-directional tunnel============| |
|<-----RS-----| | | |
|------RA---->| | | |
|<-MLD Report-| | | |
|=================MLD Report/Join message==================|
|======================multicast packets===================|
|--multicast->| | | |
| packets | | | |
| | | | |
Figure 2 the work flow of LMA-based mobile multicast
The LMA-based method has lower multicast handover delay compared with
the MAG-based method, and it can provide the traffic management and
accounting for mobile nodes. However, the LMA-based method requires
the LMA support multicast and all the multicast packets transmitting
through the tunnel increases the process overhead on the LMA. The bi-
directional tunnel between LMA and MAG can be shared by multiple
mobile nodes belonging to the same LMA. LMA only transmits one copy
through the tunnel to mobile node located in the same MAG when they
Zhang, et al. Expires March 4, 2009 [Page 8]
Internet-Draft Multicast Routing in PMIPv6 September 2008
want to join the same group. But for the mobile nodes with different
LMAs who want to join the same group, the MAG MAY receive multiple
copies of the group, and it may cause the tunnel convergence problem.
The problem is out of scope of this document and can be referred to
[9].
4.2.2. Scenario 2: Inter-PMIPv6 Domains Roaming
(TBD)
5. Protocol Configuration Variables
The local mobility anchor MUST allow the following variable to be
configured by the system management.
EnableMAGLocalMulticastRouting
This flag indicates whether or not the mobile access gateway is
allowed to enable local multicast routing when mobile access gateway
can obtain or send multicast traffic data from or to local multicast
router connected in the local area.
The default value for this flag is set to false, indicating that the
mobile access gateway MUST reverse tunnel all the MLD report to the
local mobility anchor of the mobile node.
When the value of this flag is set to true, the mobile access gateway
MUST route the multicast traffic locally.
This aspect of local multicast routing MAY be defined as policy and
when present will take precedence over this flag.
6. Security Considerations
This memo discusses the multicast routing in PMIPv6 and the security
issues arise from the PMIPv6 specifications and MLD protocols.
7. IANA Considerations
There are no IANA considerations introduced by this memo currently.
Zhang, et al. Expires March 4, 2009 [Page 9]
Internet-Draft Multicast Routing in PMIPv6 September 2008
8. Conclusions
In this memo, we discuss the multicast routing in the PMIPv6
specification, and introduce the EnableMAGLocalMulticastRouting flag
to determine the different multicast routing policy and method.
9. Acknowledgments
The authors would like to thank Si-Dong Zhang, Ya-juan Qin (BJTU
NGIRC) for their valuable comments and suggestions on this memo.
Zhang, et al. Expires March 4, 2009 [Page 10]
Internet-Draft Multicast Routing in PMIPv6 September 2008
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] S. Deering, W. Fenner, B. Haberman, "Multicast Listener
Discovery (MLD) for Ipv6", 1999.
[4] R. Vida and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", IETF RFC 3810, (2004).
[5] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6", RFC 3775, 2004.
10.2. Informative References
[6] S. Gundavelli, K. leung, V. Devarapalli, K. Chowdhury, B. Patil,
Proxy Mobile IPv6,draft-ietf-netlmm-proxymip6-18,work in
progress,(2008).
[7] S. Narayanan et al., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, (2008)
[8] J. Kempf et al., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[9] T.G. Harrison, C. L. Williamson, W. L. Mackrell, Richard B.
Bunt, "Mobile multicast (MoM) protocol: Multicast support for
mobile hosts", ACM MOBIGCOM 1997, Budapest, Hungary, pp:151-160,
(1997).
Zhang, et al. Expires March 4, 2009 [Page 11]
Internet-Draft Multicast Routing in PMIPv6 September 2008
Author's Addresses
Hong-ke Zhang, Jian-feng Guan, Hua-chun Zhou, Ying Zhu,
Next Generation Internet Research Center (NGIRC), Beijing JiaoTong
University
Beijing, China, 100044
Phone: +86 10 51685677
Email: hkzhang@bjtu.edu.cn
guanjian863@163.com
hchzhou@bjtu.edu.cn
03211152@bjtu.edu.cn
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright Statement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhang, et al. Expires March 4, 2009 [Page 12]
Internet-Draft Multicast Routing in PMIPv6 September 2008
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang, et al. Expires March 4, 2009 [Page 13]