One document matched: draft-zhang-multimob-msm-01.txt
Differences from draft-zhang-multimob-msm-00.txt
MULTIMOB Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: May 2011 Shuai Gao
Li-Li Wang
Beijing Jiaotong University
Qian Wu
He-Wu Li
Tsinghua University
November 8, 2010
Multicast Source Mobility Support in PMIPv6 Network
draft-zhang-multimob-msm-01.txt
Abstract
Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility
protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility
Anchor (LMA) to allow hosts to move around within a domain while
keeping their address or address prefix stable [1]. Although the
issues of mobile multicast in the PMIPv6 network are being discussed
in the Multimob WG, how to provide the service connectivity for the
mobile multicast source is still a problem for the PMIPv6. This
document discusses the extensions of the PMIPv6 to support the
multicast source mobility.
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 [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
Zhang et al. Expires May,2011 [Page 1]
Internet-Draft MSM Support in PMIPv6 Network November 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May, 2011.
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.
Table of Contents
1. Introduction................................................2
2. Overview....................................................3
3. Extensions of PMIPv6........................................4
3.1. MN.....................................................4
3.2. MAG....................................................5
3.3. LMA....................................................5
4. Multicast source mobility procedure.........................5
5. Format of signaling messages................................7
5.1. PBU....................................................7
5.2. PBA....................................................7
5.3. Multicast address option...............................8
6. Security Considerations.....................................9
7. References..................................................9
Authors' Addresses............................................10
Acknowledgment................................................10
1. Introduction
Different from MIPv6 [2], 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 MN which is
involved in the unicast communication. In order to deploy the
multicast service in the PMIPv6 network, many schemes have been
Zhang et al. Expires May,2011 [Page 2]
Internet-Draft MSM Support in PMIPv6 Network November 2010
proposed [3-6]. However, all of these schemes aim to support the
multicast service for the mobile receiver and how to support the
multicast source mobility in the PMIPv6 network is not yet discussed.
Without doubt, the multicast source mobility is also a very important
issue for the deployment of the multicast service. For example, there
is an advanced concept based on the Intelligent Transport Systems
(ITS) service. In this concept, all the vehicles on the same route
are identified by using a GPS or a car-navigation system. The
vehicles multicast real-time video information about the
transportation through the communication infrastructure like 3G, WiFi
to the other vehicles interested in it. We call this advance
information 'Future vision' and the similar concept has been proposed
in [7]. The multicast source mobility just provides a network
distribution functionality (protocol) to realize the above concept.
In this document, a multicast source mobility supporting scheme is
proposed. In this scheme, the basic PMIPv6 signalings are extended
and the LMA which acts as the RP (Rendezvous Point), responses to the
join message sent to the source (e.g., MN). The multicast packets are
sent from MN to the LMA as the basic PMIPv6 specified. Then these
packets are transmitted through the multicast tree established
between the LMA and the receivers using the traditional multicast
routing protocols.
2. Overview
The problem of multicast source mobility was also concerned in the
MIPv6 network in which the RPT-based (Rendezvous Point Tree-based)
scheme and the SPT-based (Shortest Path Tree-based) scheme are
proposed as two solutions [8]. In the RPT-based scheme, the Home
Agent (HA) acts as the RP in order to provide the transparency of
source mobility. The multicast tree is stable, while the multicast
path may not be optimized in this scheme. In the SPT-based scheme,
the MN need reconstruct the multicast tree once the L3 (network layer)
handover happens. The multicast path can be optimized in this case,
however, the frequent handover of the source may lead to the
unstability of the multicast tree.
The above two schemes can also be used in the PMIPv6 network. For the
SPT-based scheme, the SPT can be reconstructed once the MN moves to
the new MAG. And for the RPT-based scheme, the LMA can act as the RP
for the MN. However, the SPT-based scheme is not suitable in the
PMIPv6 network due to the following reasons:
---The PMIPv6 is used to enhance the handover performance for the MN,
which moves in the restricted domain. So the LMA and the MAG may not
be so far. In other words, the differences between the two paths
Zhang et al. Expires May,2011 [Page 3]
Internet-Draft MSM Support in PMIPv6 Network November 2010
corresponding to the RPT-based scheme and the SPT-based scheme may
not be so evident;
---The stability of the multicast tree is a very important factor for
the multicast service, which affects the disruption latency and then
the performance of the multicast service during the multicast source
mobility. However, in the SPT-based scheme, the multicast tree needs
to be reconstructed even the MN moves between two nearby MAGs, which
leads to the frequent disruption and low efficiency of the multicast
service;
---A mobile multicast source must provide address transparency at two
layers: To comply with Reverse Path Forward (RPF) checks, it has to
use an address within the source field of the IPv6 basic header,
which is in topological agreement with the employed multicast
distribution tree. For application transparency, the logical node
identifier must be presented as the packet source address to the
transport layer at the receiver side. It is a tough problem for the
SPT-based scheme because the identifier and the locator of the MN are
separated. The MN can only configure the HoA (Home Address) as its
identifier and its locator is the address of the MAG. However, the
RPT-based scheme can easily solve this problem because the HoA is
just anchored at the LMA.
Thus, we suggest using the RPT-based scheme to provide the multicast
source mobility in the PMIPv6 network. 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. The multicast
packets sent by the MN are firstly sent to the LMA as traditional
PMIPv6 specified and then the packets are transmitted from the LMA to
the receivers according to the multicast routing protocols.
3. Extensions 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. Then the signaling messages and
the related processing of basic PMIPv6 should be extended.
3.1. MN
In order to provide the multicast service during the MN's movement,
the MAG must recognize that the attached MN is a multicast source.
This information can be learned by the MAG during the authentication
phase for example and the corresponding multicast address must be
Zhang et al. Expires May,2011 [Page 4]
Internet-Draft MSM Support in PMIPv6 Network November 2010
contained in this information at least. The particular procedure is
out of this document.
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". The multicast address is contained in the Multicast address
option of the PBU message when the "S" is set to "1". Then the MAG
encapsulates the multicast packets into the bi-directional tunnel and
sends them to the LMA firstly.
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 session specified by the
Multicast address option.
The LMA also intercepts the join message and proceeds it for the MN.
Then the SPT between LMA and the new receiver can be established. In
this way, the multicast service can always be provided through the
RPT and the stability of the multicast tree is guaranteed.
4. Multicast source mobility procedure
Figure 1 shows the protocol procedure.
+-----+ +-----+ +-----+ +-----+
| MN | | MAG1| | LMA | | MAG2|
+-----+ +-----+ +-----+ +-----+
| | | |
1) |--- Rtr Sol------>| | |
| |------- PBU ----->| |
2) | (Multicast address option) |
| | | |
| | Accept PBU |
| | (Allocate HNP1, act as RP for MN) |
| |<------ PBA ------| |
|<---- Rtr Adv ----| (HNP1) | |
| | | |
3) |==multicast data=>|=multicast data==>| |
| | | |
| | (process the join message and |
Zhang et al. Expires May,2011 [Page 5]
Internet-Draft MSM Support in PMIPv6 Network November 2010
| |establish the multicast routing tree)|
| | | |
4) |---------------------- Rtr Sol------------------------->|
| | |<----- PBU -------|
| | (Multicast address option)|
| | | |
5) | | Accept PBU |
| | (Allocate HNP1, refresh tunnel) |
| | | |
| | |------- PBA ----->|
| | | (HNP1) |
|<-------------------- Rtr Adv ------------------------- |
6) |==================|===multicast data=|=================>|
| | |<=multicast data==|
| | (continue the packet transmission) |
| | | |
Figure 1: Multicast Source Mobility Procedure
The detailed descriptions are as follows:
1) The MN connects to the MAG1 initially and sends Router
Solicitation (RS) message to the MAG1;
2) When the attachment of MN is detected by the MAG1, an extended
PBU message is sent to the LMA. Because the LMA finds the S flag
and the Multicast address option 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. And then the LMA sends back a PBA message to the MAG1.
Afterwards, the bi-directional tunnel is established between the
MAG1 and the LMA;
3) The multicast packets are sent from the MN to the LMA as the
basic PMIPv6 specified. Since the multicast routing tree will be
established between the LMA and the receiver, the packets are
transmitted between the LMA and the receiver according to the
multicast routing protocol;
4) When the MN moves to the MAG2, the multicast related information
is also learned by the MAG2;
5) Then the LMA-MAG bi-directional tunnel is refreshed, however, the
multicast routing tree between the LMA and the receiver is kept
unchanged;
Zhang et al. Expires May,2011 [Page 6]
Internet-Draft MSM Support in PMIPv6 Network November 2010
6) The multicast packets transmission continues after the handover
and the mobility of the source is transparent to the receiver.
5. Format of signaling messages
5.1. PBU
The format of the PBU message is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast address option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PBU Message Format
S flag and Multicast address option
1-bit "Multicast source identification" flag is used to identify
whether this MN is a multicast source. When this flag is set to
"1", the related multicast address is attached in the Multicast
address option.
5.2. PBA
The format of the PBA message is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Res. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
Zhang et al. Expires May,2011 [Page 7]
Internet-Draft MSM Support in PMIPv6 Network November 2010
. Multicast address option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PBA Message Format
S flag and Multicast address option
The S flag is set to "1" if the LMA can act as the RP for the
multicast service identified by the Multicast address option. The
LMA will not act as the RP for the multicast service if the S
flag is set to "0" or there is no S flag in the PBA message. How
to provide the multicast source mobility service in the scenario
with the LMA not acting as the RP will be discussed in the future.
5.3. Multicast address option
The format of Multicast address option is illustrated in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of Multicast Address Option
Option Type
TBD
Option Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the option type and option length fields. This
field can be set to 16 and 4 for the IPv6 and IPv4 multicast
addresses, respectively.
Multicast address
Zhang et al. Expires May,2011 [Page 8]
Internet-Draft MSM Support in PMIPv6 Network November 2010
The multicast address related to the multicast session provided
by the MN.
6. Security Considerations
This document does not introduce any security considerations.
7. 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, 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.
[7] K. Sato, M. Katsumoto, T. Miki. "Future vision distribution
system and network", This paper appears in: IEEE International
Symposium on Communications and Information Technology, 2004.
ISCIT 2004, vol.1, pp: 274 - 279, October 2004.
[8] T. Schmidt, M. Waehlisch and G. Fairhurst. "Multicast Mobility
in Mobile IP Version 6 (MIPv6): Problem Statement and Brief
Survey", RFC 5757, February 2010.
Zhang et al. Expires May,2011 [Page 9]
Internet-Draft MSM Support in PMIPv6 Network November 2010
Authors' Addresses
Hong-Ke Zhang, Zhi-Wei Yan, Shuai-Gao, Li-Li Wang
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, China
Phone: +861051685677
Email:gaoxlh@gmail.com
06120232@bjtu.edu.cn
09111044@bjtu.edu.cn
shgao@bjtu.edu.cn
Qian Wu, He-Wu Li
Network Research Center
Tsinghua University, China
Phone: +861062772375
Email:wuqian@cernet.edu.cn
lihewu@cernet.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires May,2011 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 16:00:06 |