One document matched: draft-zhang-multimob-msm-00.txt
MULTIMOB Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: December 2010 Hua-Chun Zhou
Jian-Feng Guan
Si-Dong Zhang
Beijing Jiaotong University
June 10, 2010
Multicast Source Mobility Support in PMIPv6 Network
draft-zhang-multimob-msm-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 December, 2010.
Zhang et al. Expires December,2010 [Page 1]
Internet-Draft MSM Support in PMIPv6 Network June 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 Simplified BSD License.
Abstract
The NetLMM WG has specified Proxy Mobile IPv6 (PMIPv6) for network-
based localized mobility management, taking basic support for
registration, de-registration and handover of Mobile Node (MN) into
account in the RFC 5213 [1]. Although the mobile multicast provision
in the PMIPv6 network is being discussed in the multimob WG, how to
provide the service connectivity during the movement of MN which is a
multicast source, is a problem still up in the air for the PMIPv6.
This document discusses the extension of the PMIPv6 to support the
multicast source mobility.
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 5213 [1].
Table of Contents
Copyright Notice..................................................2
Abstract..........................................................2
1. Introduction...................................................3
2. Problem statement..............................................3
3. Extension of PMIPv6............................................4
3.1. MN........................................................4
3.2. MAG.......................................................4
3.3. LMA.......................................................5
4. Multicast source mobility procedure............................5
4.1. SPT between LMA and receiver..............................5
4.2. SPT between MN and receiver...............................6
5. Security Considerations........................................8
Zhang et al. Expires December,2010 [Page 2]
Internet-Draft MSM Support in PMIPv6 Network June 2010
6. References.....................................................8
Author's Addresses................................................9
Acknowledgment....................................................9
1. Introduction
Be different with the MIPv6[2], the PMIPv6 [1] was proposed to
support the network-based mobility management. The entities in the
PMIPv6 have the responsibility to track the MN, update the location
of the MN and redirect the packets to and from the MN. However, the
basic PMIPv6 protocol only solves the mobility management for the
single MN, which is only focus on the unicast transmission. In order
to deploy the multicast service in the PMIPv6 network, many schemes
are proposed [3-6]. However, all of these schemes focus on how to
support the multicast service for the mobile receivers. While how to
support the multicast source mobility in the PMIPv6 network is not
discussed yet. So in this document, a multicast source mobility
supporting scheme is proposed. In this scheme, the basic PMIPv6
signaling is extended and the Local Mobility Anchor (LMA) which acts
as the RP (Rendezvous Point), responses to the join message sent to
the source (MN). Then the multicast packets are sent from MN to the
LMA as the basic PMIPv6 specified, however, the packets are
transmitted through the multicast tree established between LMA and
the receivers using the traditional multicast routing protocols.
2. Problem statement
When the MN is the multicast source, all the multicast packets will
be transmitted through the Shortest Path Tree (SPT) from the source
to the receiver. In this way, the stability of the multicast tree
decreases with the increased handover rates of the MN. That is because
the multicast tree must be refreshed when the root of the multicast
tree changes its location. However, according to the basic PMIPv6
specification, all the packets to and from the MN must be transmitted
to the LMA through the LMA-MAG tunnel firstly. That means the LMA is
a fixed point on the way to and from the MN. So we can set the LMA to
be the RP and the proxy source of the multicast. And the following
packet transmission method is proposed in this document.
The multicast packets sent by the MN is firstly sent to the LMA as
traditional PMIPv6 specified and then the packets are transmitted
according to the multicast routing protocols from the LMA to the
receivers.
However, the packets transmission proposed above incurs serious
packets transmission overhead and latency due to the sub-optimized
Zhang et al. Expires December,2010 [Page 3]
Internet-Draft MSM Support in PMIPv6 Network June 2010
routing and tunneling overhead. So the MN should decide how to
establish the multicast tree: when the MN hands over between MAGs in
a low rate, the multicast join should be processed by the MN itself
and the SPT should be established between the MN and the receivers,
while when the MN hands over between MAGs in a high rate, the method
proposed above should be used.
3. Extension of PMIPv6
In order to support the mobility of the multicast source, the LMA is
selected to be the RP of the mobile multicast service. Besides, the
join message is processed by the LMA or the MN, which is decided by
the MN and indicated to the LMA. Then the signaling message and the
related processing should be extended.
3.1. MN
In order to provide the multicast service even during its movement,
the MN should indicate this information to the attached MAG through
the interface between MAG and MN. For example, the MAG may get this
information during the authentication phase. In this document, we do
not specify how to get this information, but the MAG must get the
multicast address corresponding to the multicast service provided by
the MN and the indication of whether the MN wants to process the join
message itself.
3.2. MAG
When the MAG finds that the attached MN is a multicast source, it
should send the extended Proxy Binding Update (PBU) message to the
LMA. In the extended PBU message, a one bit "S" flag is added and set
to "1", which means the MN is a multicast source. The multicast
address is contained in the PBU message as a Multicast Address
option when the "S" is set to "1". Besides, a one bit "J" flag is
added to indicate whether the LMA should receive and process the join
message sent to the MN. When the MAG finds that the "J" flag is set
to "1", it should not encapsulate the multicast packets into the bi-
directional tunnel but transmit them according to the traditional
multicast routing protocol. In this case, the MAG has to set up the
multicast routing table according to the traditional multicast
routing protocol.
Zhang et al. Expires December,2010 [Page 4]
Internet-Draft MSM Support in PMIPv6 Network June 2010
3.3. LMA
When receiving the extended PBU message, the normal PMIPv6 tunnel is
established between LMA and MAG. Besides, the LMA recognizes that it
should act as the RP for the multicast specified by the Multicast
Address option. Besides, when the "J" flag is set to "1", the LMA
who receives the join message sent to the MN will response to it and
establish the SPT between LMA and the receiver. In order to find the
RP for the receiver, the corresponding information of "Multicast
address<->address of RP" has to be learned by the receiver. And this
is out of the scope of the document.
4. Multicast source mobility procedure
According to the indication from the MN, different multicast tree
establishment methods are adopted.
4.1. SPT between LMA and receiver
Fig.1 shows the protocol procedure for the MN which hands over
between MAGs in a high rate.
+-----+ +-----+ +-----+ +-----+
| MN | | MAG1| | LMA | | MAG2|
+-----+ +-----+ +-----+ +-----+
| | | |
1) |--- Rtr Sol------>| | |
("S" and "J=1") |------- PBU ----->| |
2) | | Accept PBU |
| | (Allocates HNP1, acts as RP for MN)
| |<------ PBA ------| |
|<---- Rtr Adv ----| (HNP1) | |
| | | |
3) |==multicast data=>|=multicast data==>| |
| | | |
| | (process the join and establish SPT)|
| | | |
4) |------------- Rtr Sol ("S"and "J=1")------------------->|
| | |<----- PBU -------|
| | | |
5) | | Accept PBU |
| | (Allocates HNP1, refreshes tunnel |
| | | |
| | |------- PBA ----->|
| | | (HNP1) |
Zhang et al. Expires December,2010 [Page 5]
Internet-Draft MSM Support in PMIPv6 Network June 2010
|<-------------------- Rtr Adv ------------------------- |
6) |==multicast data=>|=multicast data==>| |
| | | |
| | (continue the packet transmission) |
| | | |
Figure 1 msm in the first case
1) As illustrated in the figure, the "S" bit ,the multicast address
and the "J" flag can be contained in the Router Solicitation(RS)
message sent from the MN to the MAG;
2) When the attachment of MN is detected by the MAG1, an extended
PBU message is sent to the LMA. And then the bi-directional
tunnel is established between MAG1 and LMA. Because the LMA finds
the extended information contained in the PBU message, the LMA
acts as the RP of the multicast service corresponding to the
multicast address and responses to the join message sent to the
MN;
3) The multicast packets are sent from the MN to the LMA as the
basic PMIPv6 specified. Since the SPT will be established between
LMA and the receiver, the packets are transmitted according to
the multicast routing protocol between LMA and the receiver;
4) When the MN moves to the MAG2, the multicast related information
is transmitted to the new MAG;
5) Then the LMA-MAG bi-directional is refreshed, however, the SPT
between LMA and the receiver is not affected;
6) So the multicast packets transmission is continued after the
handover and the mobility of the source is transparent to the
receiver.
4.2. SPT between MN and receiver
Fig.2 shows the protocol procedure for the MN which hands over
between MAG in a low rate.
+-----+ +-----+ +-----+ +-----+
| MN | | MAG1| | LMA | | MAG2|
+-----+ +-----+ +-----+ +-----+
| | | |
1) |--- Rtr Sol------>| | |
("S" and "J=0") |------- PBU ----->| |
2) | | Accept PBU |
Zhang et al. Expires December,2010 [Page 6]
Internet-Draft MSM Support in PMIPv6 Network June 2010
| | (Allocates HNP1, acts as RP for MN)
| |<------ PBA ------| |
|<---- Rtr Adv ----| (HNP1) | |
| | | |
3) |==multicast data=>|=multicast data==>| |
(process the join and establish SPT) | |
| | | |
4) |------------- Rtr Sol ("S" and "J=0")------------------>|
| | |<----- PBU -------|
| | | |
5) | | Accept PBU |
| | (Allocates HNP1, refreshes tunnel |
| | | |
| | |------- PBA ----->|
| | | (HNP1) |
6) |<-------------------- Rtr Adv ------------------------- |
(refreshes the SPT) | | |
| | | |
Figure 2 msm in the second case
1) As illustrated in the figure, the "S" bit ,the multicast address
and the "J" flag can be contained in the RS message sent from MN
to the MAG;
2) When the attachment of MN is detected by the MAG1, an extended
PBU message is sent to the LMA. And then the bi-directional
tunnel is established between MAG1 and LMA. Because the LMA finds
the extended information contained in the PBU message, the LMA
acts as the RP of the multicast service corresponding to the
multicast address but it will not response to the join message
sent to the MN;
3) The multicast packets are sent from the MN to the LMA as the
basic PMIPv6 specified firstly. But when the LMA redirects the
join message to the MN, the SPT is established between MN and the
receiver and the following packets are transmitted through the
optimized path;
4) When the MN moves to the MAG2, the multicast related information
is transmitted to the new MAG;
5) Then the LMA-MAG bi-directional is refreshed;
6) However, the SPT must be refreshed because the root of the
multicast tree moves to a different location.
Zhang et al. Expires December,2010 [Page 7]
Internet-Draft MSM Support in PMIPv6 Network June 2010
5. Security Considerations
The MAG should be responsible for the multicast service management
for the mobile source because the packets may be not transmitted to
the LMA.
6. References
[1] Gundavelli, et al., Proxy Mobile IPv6, RFC5213, August 2008.
[2] David B. Johnson, Charles E. Perkins and Jari Arkko, Mobility
Support in IPv6, RFC 3775, June 2004.
[3] T C. Schmidt, M. Waehlisch and S. Krishnan, Base Deployment
for Multicast Listener Support in PMIPv6 Domains, draft-ietf-
multimob-pmipv6-base-solution-00, February 24, 2010.
[4] H. Asaeda, P. Seite and J. Xia, PMIPv6 Extensions for
Multicast, draft-asaeda-multimob-pmip6-extension-03, March 8,
2010.
[5] Seil Jeon and Younghan Kim, Mobile Multicasting Support in
Proxy Mobile IPv6, draft-sijeon-multimob-mms-pmip6-02.txt,
March 4, 2010.
[6] T C. Schmidt, M. Waehlisch, R. Koodli and G. Fairhurst,
Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
Handovers, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01,
March 06, 2010.
Zhang et al. Expires December,2010 [Page 8]
Internet-Draft MSM Support in PMIPv6 Network June 2010
Author's Addresses
Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Si-Dong Zhang
NGI Research Center
Beijing Jiaotong University of China
Phone: +861051685677
Email:hkzhang@bjtu.edu.cn
06120232@bjtu.edu.cn
hchzhou@bjtu.edu.cn
sdzhang@center.njtu.edu.cn
Jian-feng Guan
Institute of Networking Technology, Beijing University of Post and
Telecommunication
Beijing, China, 100876
Phone: +86 10 62281007
Email: jfguan@bupt.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Internet-Draft MSM Support in PMIPv6 Network June 2010
| PAFTECH AB 2003-2026 | 2026-04-24 16:00:53 |