One document matched: draft-yang-multimob-mip6-mc-tunnel-opt-02.txt
Differences from draft-yang-multimob-mip6-mc-tunnel-opt-01.txt
Network Working Group P. Yang
Internet-Draft Hitachi (China) R&D Corporation
Intended status: Standards Track H. Deng
Expires: January 15, 2009 China Mobile
Q. Wu
Tsinghua Univ.
July 14, 2008
Multicast tunneling optimization for Mobile IPv6
draft-yang-multimob-mip6-mc-tunnel-opt-02
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.
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 January 15, 2009.
Yang, et al. Expires January 15, 2009 [Page 1]
Internet-Draft Multicast Opt for MIPv6 July 2008
Abstract
This document provides the solution to optimize the multicast
tunneling in mobile IPv6. This solution will not break the basic bi-
directional tunneling multicast solution of MIPv6. A new Mobile
Multicast Agent works as a proxy node for multiple mobile nodes
within one limit scope. Single tunnel is set up between one Home
Agent and one Mobile Multicast Agent for single multicast stream. A
new notification message is created for the communication between
home agent and mobile multicast agent. There is no modification on
mobile nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution for MIPv6 multicast tunneling optimization . . . . . 4
3. Operation of Mobile Multicast Agent (MMA) . . . . . . . . . . 7
3.1. Tunnel manipulation . . . . . . . . . . . . . . . . . . . 7
3.2. operation of Multicast Serving Table . . . . . . . . . . . 7
3.3. operation of Multicast notification message . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Yang, et al. Expires January 15, 2009 [Page 2]
Internet-Draft Multicast Opt for MIPv6 July 2008
1. Introduction
Mobile IPv6 (MIPv6)[RFC3775] allows the mobile nodes(MN) to maintain
the reachability while moving in the IPv6 network. After
registration to home agent(HA), the packets destined to MN could be
routed correctly by using the end-to-end tunnel, while MN is away
from the home network. MIPv6 has some other extensions (HMIP6
[RFC4140] and FMIP6 [RFC4068] for different application schemes.
Multicast is an optimal way for mass multimedia delivery of gourp
communication in mobile network. Mobile IPTV is one of such group
communication cases, where multicast is suitable. [Deng07]. MIPv6
has two methods for multicast. [Schmidt07] has analysis on these two
ways:
- Remote multicast subsciption: this solution rely on multicast
router, which is seldom available in the mobile network. It also
suffers from the slow handover.
- Bi-directional tunneling: The advantage of the bi-directional
tunneling solution is its simplicity and the transparency of handover
to the multicast operation. But multiple tunnels are set up between
MNs and HA even for one single multicast stream. This tunnel
overhead weakens the benefit of using multicast greatly. So, this
document proposes the solution to optimize the bi-direction tunneling
multicast solution of MIPv6. With simple extension, this solution
could also be applied to other extended MIPv6 solution as well.
When MN is in the foreign network, the packet routing between HA and
MN is at least via an access router(AR). AR is the first hop for MN
to get access to internet. The characteristics of the link between
MN and AR are different depending on the types of access network and
radio links. So, the multicast optimization between MN and AR should
be specific for access network. In this document, the solution is
only focused on the multicast tunnels between AR and HA.
Yang, et al. Expires January 15, 2009 [Page 3]
Internet-Draft Multicast Opt for MIPv6 July 2008
2. Solution for MIPv6 multicast tunneling optimization
Currently bi-directional tunneling multicast routing in foreign
network is depicted in the picture below:
Access network
(Wired or Wireless) IP multicast
| packets
| |
+------+ V +------+ +------+ |
| |===============|======|=============| | |
| MN | | AR | | HA | V
| | |======|=============| |-----
+------+ //+------+ +------+
//
+------+ //< -------bi-dictional
| |// tunnel.
| MN |
| |
+------+
In this document, a new mobile multicast agent(MMA) is proposed to
optimize the multicast tunneling solution of MIPv6. In the real
deployment, MMA and AR could be collocated together. The new
solution of bi-directional tunneling multicast routing in foreign
network is depicted in the picture below:
Access network
(Wired or Wireless) IP multicast
| +......................+ packets
| : may be collocated : |
+------+ V : +------+ +------+ : +------+ |
| |============|======|====| | : | | |
| MN | : | AR | | MMA |========| HA | V
| | : |======|====| | : | |-----
+------+ //+------+ +------+ : +------+
//......................+
+------+ //
| |// < -------bi-dictional
| MN | tunnel.
| |
+------+
MMA is the termination point of the tunnel from HA. MMAs should be
very close to ARs or even collocated with ARs. Compared with the
current multicast solution of MIPv6, the number of unicasting tunnels
Yang, et al. Expires January 15, 2009 [Page 4]
Internet-Draft Multicast Opt for MIPv6 July 2008
for one streams multicast between one pair of AR/MMA and HA will
decreased to only one. This is especially meaningful when one HA
serves many MNs with multicast services.
The call flow of the optimized MIPv6 multicast is shown below (AR and
MMA are collocated together):
MN p(AR/MMA) n(AR/MMA) HA MR
| | | | |
| MLD membership query | | |
(0) |< ========================================|< ----------|
| | | | |
| MLD membership report | | |
(1) |======================================== >|---------- >|
| | MC Notify | | |
(2) | |< -------------------------| Multicast |
| | single | | packets |
(3) | multiple | tunnel | |< ----------|
(4) | tunnels |< #########################| |
(5) |< ============| | | |
| | | | |
Handover to n(AR/MMA) | | |
-------------------------------------------------------------
| BU | | | |
(6) |---------------------------------------- >| |
| BA | | | |
(7) |< ----------------------------------------| |
| | | MC Notify | |
(8) | | |< ---------| |
| | MC Notify | | |
(9) | |< -------------------------| Multicast |
| | single | | packets |
(10)| multiple | tunnel | |< ----------|
(11)| tunnels |< #########################| |
(12)|< ============| | | |
(0) HA forwards the MLD membership query message down to MNs via the
bi-directional tunnels periodically.
(1) MNs should report their multicast group membership by the MLD
membership report message. This message should be tunneled to HA
firstly and forwarded to the other multicast routers afterwards.
(2) When HA finds that MN(s) want to have join the new multicast
groups, it will notify AR/MMA with the information of related MN
addresses and multicast addresses. It may also put some other
Yang, et al. Expires January 15, 2009 [Page 5]
Internet-Draft Multicast Opt for MIPv6 July 2008
streams related messages inside the notification message. AR/MMA
will store this information inside the Multicast Serving Table (MST).
HA will also store the triple-units of (MN, AR/MMA, Multicast
Address) in the local cache.
(3) HA receives one multicast stream from the multicast router. HA
will check the cached (MN, AR/MMA, multicast address) based on the
multicast address of incoming multicast stream.
(4) HA will tunnel the stream to the related AR/MMA with single
tunnel. The Outer IP header is from HA to AR/MMA. The inner IP
packet is the original multicast packet.
(5) At AR/MMA, it will check the MST and get the addresses of MNs who
have subsribes this multicast stream. AR/MMA will make duplication
of the received tunnel packet based on the number of related MNs.
then, it will replace the dstination addresses of the outer tunnel
headers with the Care of Addresses(CoAs) of related MNs repectively.
Lastly, it will send all these tunnel packets to the MNs. MNs do not
need modification to receive these packets.
(6,7) When MN handover to the subnet of new AR/MMA, it will finish
BU/BA procedure firstly with HA.
(8) On parallel, HA sends notification to the new AR/MMA with the
information of multicast addresses =and MN addresses. The new AR/MMA
stores this information inside the (MST) of it's own.
(9) HA notifies the old AR/MMA to remove the MST entries related to
the MN addresses.
(10) HA receives one multicast stream from the multicast router. HA
will check the cached (MN, AR/MMA, multicast address) based on the
multicast address of incoming multicast stream.
(11) The multicast packet will be tunneled to the new AR/MMA
accordingly. The Outer IP header is from HA to new AR/MMA. The
inner IP packet is the original multicast packet.
(12) The new AR/MMA will do the same tunnel duplication and address
replacement as step (5)
MMA may be a seperated device from AR. The tunnel optimization
solution is almost the same as the combined one. But it may be
necessary for HA to discover the new MMA. How to choose the new MMA
is out of scope of this document. And, if MMA does not change while
MN does handover to new AR, HA does not need to do the step (9) in
the picture above.
Yang, et al. Expires January 15, 2009 [Page 6]
Internet-Draft Multicast Opt for MIPv6 July 2008
3. Operation of Mobile Multicast Agent (MMA)
The main function of MMA is to convert the single multicast tunnel
from HA to multile tunnels for related MNs respectively. This
operation should be done based on the information of MST. It is
recommended to put MMA and AR together.
3.1. Tunnel manipulation
The logical packet of the tunnel from HA is showed below:
+----------+------------+---------+--------------+---------+
| HA's Addr| MMA's Addr |CN's Addr|Multicast Addr| Payload |
+----------+------------+---------+--------------+---------+
|< ---- Outer IP ---- >|< ---- Inner IP ---- >|
| tunnel header | tunnel header |
In the tunneled packet from HA, the destination and original address
of the outer IP tunnel header is MMA's address and HA's address
respectively. The inner IP packet is the original IP multicast
packet from the corresponding node(CN).
In MMA, it will check the MST and get the addresses of MNs who have
subsribes this multicast stream. Duplication of the received tunnel
packet will be made based on the number of related MNs. The
dstination addresses of the outer tunnel headers will be replaced by
the Care of Addresses(CoAs) of related MNs repectively. Lastly, it
will send all these tunnel packets to the MNs. The generated tunnel
packet is depicted in the picture below:
+----------+------------+---------+--------------+---------+
| HA's Addr| MN's CoA |CN's Addr|Multicast Addr| Payload |
+----------+------------+---------+--------------+---------+
|< ---- Outer IP ---- >|< ---- Inner IP ---- >|
| tunnel header | tunnel header |
The structure of this tunnel packet is the same as the one of the
tunneled multicast packets between HA and MN in [RFC3775]. So, the
MN do not need to be modified in this solution.
3.2. operation of Multicast Serving Table
MST should at least contains the information of HA address, MNs'
addresses and related multicast address. It may have some other
information, such as the characterastics of streams, timing
information and mobile TV channel information. These supplementary
Yang, et al. Expires January 15, 2009 [Page 7]
Internet-Draft Multicast Opt for MIPv6 July 2008
information is sometimes useful for the stream manipulation.
The initiation, update and termination of MST entries should only be
done based on the notification messages from HA.
3.3. operation of Multicast notification message
The definition of multicast notification message is out of scope of
this document. It could be a specific message or extension to a
generic message. This part should be defined by seperated documents.
Yang, et al. Expires January 15, 2009 [Page 8]
Internet-Draft Multicast Opt for MIPv6 July 2008
4. Security Considerations
This solution basically does not break the security framework of
MIPv6.
Because MLD membership messages should be tunneled, the data traffic
between HA and MN should be protected by tunnel ESP. It is
recommended to set up the security associations (SAs) between HA and
MMAs. Notification messages could be protected by transport ESP.
Yang, et al. Expires January 15, 2009 [Page 9]
Internet-Draft Multicast Opt for MIPv6 July 2008
5. Conclusion
A new multicast delivery solution in MIPv6 is proposed in this
solution. It does not break the basic routing and security framework
of the original MIPv6 solution. The multiple unicasting multicast
tunnels could be avoided between HA and AR.
Yang, et al. Expires January 15, 2009 [Page 10]
Internet-Draft Multicast Opt for MIPv6 July 2008
6. Normative References
[BCMCS] 3GPP2, "Broadcast/Multicast Services - Stage 1, Revision
A", 3GPP2 S.R0030-A V1.0, Feb. 2004.
[Deng07] Deng, H., "Problem Statement and Analysis: Multicast
Mobility for Mobile IPTV",
draft-deng-multimob-ps-mobiletv-00.txt (work in progress),
November 2007.
[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS)
Architecture and functional description", 3GPP TS
23.246 V8.0.0, September 2007.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[Schmidt07]
Schmidt, T., "Multicast Mobility in MIPv6: Problem
Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-01.txt (work in progress),
July 2007.
Yang, et al. Expires January 15, 2009 [Page 11]
Internet-Draft Multicast Opt for MIPv6 July 2008
Authors' Addresses
Peng Yang
Hitachi (China) R&D Corporation
301, North Wing, Tower C Raycom Infotech Park
2 kexueyuan Nanlu
Haidian District
Beijing, 100080
P.R. China
Phone: +861082862918(ext.)328
Email: pyang@hitachi.cn
Hui Deng
China Mobile
Qian Wu
Tsinghua Univ.
Yang, et al. Expires January 15, 2009 [Page 12]
Internet-Draft Multicast Opt for MIPv6 July 2008
Full 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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Yang, et al. Expires January 15, 2009 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:31:34 |