One document matched: draft-zhang-multimob-msm-02.txt
Differences from draft-zhang-multimob-msm-01.txt
MULTIMOB Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: September 2011 Shuai Gao
Li-Li Wang
Beijing Jiaotong University
Qian Wu
He-Wu Li
Tsinghua University
March 14, 2011
Multicast Source Mobility Support in PMIPv6 Network
draft-zhang-multimob-msm-02.txt
Abstract
Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [1], is a network-
based mobility management 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.
Although the issues of mobile multicast in the PMIPv6 network are
being discussed in the Multimob WG, how to provide the service
connectivity when the multicast source is moving is still a problem
for the PMIPv6. This document proposes and analyzes the potential
solutions of the multicast source mobility in PMIPv6.
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 September,2011 [Page 1]
Internet-Draft MSM Support in PMIPv6 Network March 2011
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September, 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.................................................3
2. Multicast Source mobility in PMIPv6..........................3
2.1. Any Source Multicast....................................4
2.1.1. LMA-based scheme...................................4
2.1.2. MAG-based scheme...................................5
2.2. Source-Specific Multicast...............................5
2.2.1. LMA-based scheme...................................5
2.2.2. MAG-based scheme...................................6
2.3. LMA-based vs. MAG-based.................................7
3. Extensions of PMIPv6.........................................8
3.1. MAG.....................................................8
3.2. LMA.....................................................9
4. Format of signaling messages.................................9
4.1. PBU.....................................................9
4.2. PBA....................................................10
4.3. Multicast address option...............................10
5. Security Considerations.....................................11
6. References..................................................11
Authors' Addresses.............................................13
Acknowledgment.................................................13
Zhang et al. Expires September,2011 [Page 2]
Internet-Draft MSM Support in PMIPv6 Network March 2011
1. Introduction
Different from Mobile IPv6 (MIPv6) [2], PMIPv6 was proposed to
support the network-based mobility management. The entities in the
PMIPv6 have the responsibilities to track the Mobile Node (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 proposed [3-6]. However, all of these schemes aim
to support the multicast service for the mobile receiver. How to
support the multicast source mobility in the PMIPv6 network is a
newly planned work in the Multimob WG. 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.
This advance information is called as 'future vision' [7]. The
multicast source mobility is one of the core supporting schemes to
realize the above functions.
In this document, the potential solutions of the multicast source
mobility in PMIPv6 are proposed and analyzed.
2. Multicast Source mobility in PMIPv6
In PMIPv6 base solution, the LMA and the MAG are two most important
functional entities. According to different packet transmission paths
supporting multicast source mobility, two basic schemes are proposed
in this document. In the first case, all the multicast packets sent
out from the MN are directed to the LMA firstly and then transmitted
to the receivers according to the basic multicast routing protocols,
such as Protocol Independent Multicast-Sparse Mode (PIM-SM). While in
the second case, the packets sent out from the MN can be directly
transmitted from the MAG to the receivers. For convenience, these two
schemes are denoted as the LMA-based scheme and the MAG-based scheme,
respectively. Figure 1 shows the architecture of the multicast source
mobility in PMIPv6 using this two schemes.
As shown in Figure 1, the paths among the MAGs and the LMA
represented by lines ("||") indicate the tunnels in base PMIPv6,
while the path depicted with stars ("*") denotes the multicast tree
of the LMA-based scheme and the path pictured with circles ("o")
shows the multicast tree of the MAG-based scheme.
Zhang et al. Expires September,2011 [Page 3]
Internet-Draft MSM Support in PMIPv6 Network March 2011
+----+
|LMA | * * * * * * * * *{Receiver}
+----+ o
| o
/*/ \\ o
/*/ \\ o
+-------/*/-------\\-----------o-------+
( /*/ IPv6 \\ o )
( /*/ Network \\ o )
+----/*/-------------\\-----o----------+
/*/ \\ o
/*/ \\ o
| |o
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
{MS}----------------->{MS}
Figure 1: Architecture of the multicast source mobility in PMIPv6
In Section 2, the above two basic schemes of multicast source
mobility will be discussed in the scenarios of Any Source Multicast
(ASM) and Source-Specific Multicast (SSM), respectively. Also some
suggestions about the choice of multicast source mobility solutions
are given.
2.1. Any Source Multicast
These two schemes can be differently deployed in this scenario.
2.1.1. LMA-based scheme
In the PMIPv6 network, the LMA is just the topological anchor point
of the source's Home Address (HoA). In this way, the join message
(HoA,G) is delivered to the LMA firstly and the LMA-based multicast
tree can be established.
In this case, the LMA allows a mobile source to continuously send
data to the group through the LMA-MAG tunnel firstly. And then the
packets are transmitted from the LMA to the receivers according to
the multicast routing protocols. When the MN hands over from one MAG
to another, only the PMIPv6 tunnel is updated and the movement of
source is transparent to the receivers.
Zhang et al. Expires September,2011 [Page 4]
Internet-Draft MSM Support in PMIPv6 Network March 2011
When the handover from the Rendezvous Point Tree (RPT) to the
Shortest Path Tree (SPT) happens, the join message destined for the
HoA is delivered to the LMA firstly. After the encapsulation, the
join message is redirected to the MAG through the LMA-MAG tunnel.
Then the MAG parses the join message and establishes the related
multicast state. However, the path between the LMA and the MN is
still used for the multicast packets transmission. Although the SPT
handover finishes, the practical path is not the topological shortest
path tree due to the existence of PMIPv6 tunnel.
2.1.2. MAG-based scheme
In the case, the MAG sends the packets originated by the MN to the RP
directly but not through the PMIPv6 tunnel. For this, the PMIPv6
packet transmission procedure needs to be adjusted in the multicast
case. In particular, when the MAG receives the packets destined for a
multicast group, it should not encapsulate them in the MAG-LMA tunnel
but directly tunnel them to the RP from the outgoing interface.
For this, the MAG should ignore and discard all the join messages
sent to the HoA. In this way, all the multicast packets originated by
the MN can always be sent through the tunnel between the MAG and the
RP.
For the receivers, the original join message is sent to the RP for
the (*,G) multicast service. Then the RP can redirect the multicast
packets received from the MAG to the receivers according to the
multicast routing protocol.
When the handover of the RPT to the SPT happens, the procedure is
similar to the statement in section 2.2.2.
2.2. Source-Specific Multicast
The SSM is denoted by the multicast source address and the multicast
group address (S,G). Receivers can receive the multicast data by
subscribing to the channel (S,G). These two schemes can also be
differently deployed in this scenario as the same as in the ASM
scenario.
2.2.1. LMA-based scheme
In SSM, the multicast receivers actively send the (S,G) subscribe
message to establish the SPT from the specific source to the
receivers. Accordingly, the SSM scenario with the LMA-based scheme is
similar to the SPT handover in the ASM scenario with the LMA-based
scheme.
Zhang et al. Expires September,2011 [Page 5]
Internet-Draft MSM Support in PMIPv6 Network March 2011
In this case, the subscribe message destined for the HoA is delivered
to the LMA firstly. After the encapsulation, the subscribe message is
redirected to the MAG through the LMA-MAG tunnel. Then the MAG parses
the subscribe message and establishes the related multicast state.
However, the current SPT path is not the topological shortest path
tree due to the existence of PMIPv6 tunnel.
2.2.2. MAG-based scheme
When the MAG-based scheme is adopted in the SSM, there are more
complex issues. All the multicast listeners are forced to know the
address of the MAG corresponding to the multicast service related HoA.
For this, the following three important issues should be solved.
1) How can the MAG/LMA know all the receivers' addresses?
2) How can the MAG/LMA notify all the receivers about the current MAG
the MN attached when the handover happens?
3) How can the MAG/LMA maintain the freshest list of all the
receivers or DRs (Designated Routers)?
Then, two possible approaches are listed as follows:
Passive approach: When a receiver wants to subscribe a multicast
group identified by (HoA,G), the related report message is sent to
its attached DR. The DR then constructs a subscribe message destined
for the HoA and sends this message to its upstream router. As the
anchor point of this HoA, the LMA receives the subscribe message. The
first subscribe message is transmitted to the MN through the LMA-MAG
tunnel. However, the MAG when receiving the subscribe message must
notify the receiver that the (HoA,G) identified multicast channel is
the same channel identified by (MAG,HoA,G). Then the DR resubscribes
the multicast group as the new subscribe message is sent to the MAG.
Afterwards, the new SPT is established between the receiver and the
MAG. When the MN hands over to a new MAG, all the receivers have to
be notified with the new (MAG,HoA,G) and the SPT should be refreshed.
Optionally, the notification procedure of the address of current MAG
can also be executed by the LMA.
Active approach: When a receiver wants to subscribe a multicast group
identified by (HoA,G), it should query for the topological location
of the (HoA,G) related multicast source firstly. When the querying
message is received by the LMA, the LMA notifies the receiver about
the MAG's address. Then the DR resubscribes the multicast group as
the new subscribe message (MAG,HoA,G) is sent to the MAG. Afterwards,
Zhang et al. Expires September,2011 [Page 6]
Internet-Draft MSM Support in PMIPv6 Network March 2011
the new SPT is established between the receiver and the MAG. When the
MN hands over to a new MAG, all the receivers have to be notified
with the new (MAG,HoA,G) and the SPT should be refreshed.
2.3. LMA-based vs. MAG-based
In general, the LMA-based scheme is easy to implement and has very
low handover overhead and delay due to movement of the multicast
source, however, the packets transmission in this scheme incurs
packets transmission overhead and latency due to the sub-optimized
routing and tunneling overhead. Although the packet transmission
efficiency can be improved in the MAG-based scheme, it needs a high
handover overhead and delay and it is difficult to implement for the
essential extensions of the PMIPv6 protocol and the multicast routing
protocol. Even if the multicast tree has been established
successfully, it needs to be reconstructed even the MN moves between
two nearby MAGs, which may lead to frequent disruption and low
efficiency of the multicast service. The detailed comparison of the
two schemes in the different scenarios is described in Table 1.
Table 1: Comparison of the two schemes in different scenarios
+------------------------------------------------------------------------------------------------+
| | PMIPv6 | PIM-SM | handover | handover | Path |
| | Extension | Extension | delay | overhead | |
|------------------------------------------------------------------------------------------------|
| | | RPT | / | / | low | low | worst |
| | LMA-based |------------------------------------------------------------------------------|
| | | SPT | / | / | low | low | medium |
| ASM |------------------------------------------------------------------------------------------|
| | | RPT | MAG | / | low | low | better than |
| | MAG-based | | | | | | LMA-based RPT|
| | |------------------------------------------------------------------------------|
| | | SPT | MAG/LMA | multicast router| high | high | best |
| | | | | & receiver DR | | | |
|------------------------------------------------------------------------------------------------|
| | | | | | | |
| | LMA-based | / | / | low | low | medium |
| | | | | | | |
| SSM |------------------------------------------------------------------------------------------|
| | | | multicast router| | | |
| | MAG-based | MAG/LMA | & | high | high | best |
| | | | receiver DR | | | |
+------------------------------------------------------------------------------------------------+
Zhang et al. Expires September,2011 [Page 7]
Internet-Draft MSM Support in PMIPv6 Network March 2011
As shown in Table 1, the paths of the MAG-based SPT both in ASM and
SSM scenarios are the most optimal, but the establishment of the MAG-
based SPT is difficult and also incurs high handover delay and
handover overhead. And the MAG-based SPT scheme in ASM and SSM needs
to extend multicast routing protocols, which may be outside of the
Multimob WG's scope and then difficult to implement. Thus, it is
suggested that the MAG-based SPT scheme should not be considered.
While the LMA-based schemes, not only in the ASM case but also in the
SSM case, are simpler for implementation than other schemes, because
extra extensions of the PMIPv6 protocol and the multicast routing
protocol are unnecessary. Besides, it can be seen from the Table 1
that the path of the MAG-based RPT is better than the LMA-based RPT
in ASM and is also a good choice for mobile multicast service. This
is because that the packets can be transmitted from the MAG to the RP
directly rather than the MAG-LMA tunnel. However, it is required the
MAG should be extended accordingly. In real applications, the LMA-
based scheme and the MAG-based scheme in the ASM RPT scenario can be
selected according to network conditions and mobility characteristics
of the MN. Here we suggest introducing a negotiation capability
between the MAG and the LMA by some simple extensions of the PMIPv6
protocol specified in Section 3. The basic principle of the
negotiation is that the LMA with more global network information than
the MAG has the right to decide which schemes should be adopted. But
the specific negotiation approach is out of this document.
3. Extensions of PMIPv6
The signaling messages and the related processing of basic PMIPv6
should be extended in order to notify the multicast source-related
information from the MAG to the LMA. Besides, the extensions are used
for the negotiation between the MAG-based scheme and the LMA-based
scheme for a particular multicast source.
3.1. MAG
In order to provide the multicast service during the MN's movement,
the MAG must recognize that the attached MN is a multicast source and
the corresponding multicast address must also be learned. These
information can be learned by the MAG during the authentication phase
for example. The particular procedure is out of this document.
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 when the "S" is set to "1". Besides, a one bit "J" flag is
added to indicate whether the MAG has the ability to adopt the MAG-
Zhang et al. Expires September,2011 [Page 8]
Internet-Draft MSM Support in PMIPv6 Network March 2011
based scheme. When the MAG finds that the "J" flag is set to "1" in
the extended Proxy Binding Acknowledgement (PBA) message from the LMA,
the MAG-based scheme can be used for the MN. Otherwise, the LMA-based
scheme is adopted for multicast service.
3.2. LMA
When receiving the extended PBU message, the LMA establishes a tunnel
to the MAG as specified in PMIPv6. And if the "J" flag is set with
"1" in the extended PBU message, the LMA will judge whether the MAG
should adopt the MAG-based scheme and indicate the MAG with the "J"
flag in the extended PBA message. If the "J" flag is set with "0" in
the extended PBU message, the LMA will also set the "J" flag with "0"
in the extended PBA message.
4. Format of signaling messages
4.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|J| 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 mobile multicast source. When this flag is set
to "1", the related multicast address is attached in the Multicast
address option.
J flag
Zhang et al. Expires September,2011 [Page 9]
Internet-Draft MSM Support in PMIPv6 Network March 2011
1-bit "MAG join" flag is used to identify whether the MAG has the
ability to support the MAG-based scheme.
4.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|J|Res. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast address option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PBA Message Format
S flag and Multicast address option
1-bit "Multicast source identification" flag is used to identify
whether this MN is a mobile multicast source. The flag is set to "1"
only if the corresponding PBU had the S flag set to "1". And when
this flag is set to "1", the related multicast address is attached in
the Multicast address option.
J flag
1-bit "MAG join" flag is used to identify whether the MAG should
establish the MAG-based multicast tree. When the J in the PBA is set
to "1" as the same value in the PBU message, the MAG will establish
the MAG-based multicast tree. However, when the J in the PBA is set
to "0" but its value in PBU is "1", the MAG-based scheme is not
allowed by the LMA. The reason of the allowance of the MAG-based
multicast tree establishment at the LMA is that the LMA has more
information than the MAG to make this decision.
4.3. Multicast address option
The format of Multicast address option is illustrated in Figure 4.
Zhang et al. Expires September,2011 [Page 10]
Internet-Draft MSM Support in PMIPv6 Network March 2011
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: 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
The multicast address related to the multicast session provided by
the MN.
5. Security Considerations
This document does not introduce any security considerations.
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-07, December 29, 2010.
[4] H. Asaeda, P. Seite and J. Xia. "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-04, September
9, 2010.
Zhang et al. Expires September,2011 [Page 11]
Internet-Draft MSM Support in PMIPv6 Network March 2011
[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-03,
November 08, 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.
Zhang et al. Expires September,2011 [Page 12]
Internet-Draft MSM Support in PMIPv6 Network March 2011
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: +861051684274
Email:hkzhang@bjtu.edu.cn
06120232@bjtu.edu.cn
shgao@bjtu.edu.cn
09111044@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 September,2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 16:00:39 |