One document matched: draft-deng-multimob-mip4-00.txt
Network Working Group H. Deng
Internet-Draft China Mobile
Intended status: Standards Track June 20, 2008
Expires: December 22, 2008
Multicast tunneling optimization for Mobile IPv4
draft-deng-multimob-mip4-00
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 December 22, 2008.
Deng Expires December 22, 2008 [Page 1]
Internet-Draft Multimob MIP4 June 2008
Abstract
This document provides the solution to optimize the multicast
tunneling in mobile IPv4. This solution will not break the basic bi-
directional tunneling multicast solution of MIPv4. A new multicast
foreign 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 foreign agent for single multicast stream. A new
notification message is created for the communication between home
agent and multicast foreign agent. There is no modification on
mobile nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MIPv4 FA CoA multicast tunneling optimization . . . . . . . . 4
3. Call flow of Multicast MIP4 FA CoA . . . . . . . . . . . . . . 5
4. Operation of Multicast Foreign Agent (MFA) . . . . . . . . . . 7
4.1. Tunnel manipulation . . . . . . . . . . . . . . . . . . . 7
4.2. Operation of Multicast Serving Table . . . . . . . . . . . 7
4.3. Operation of Multicast notification message . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Deng Expires December 22, 2008 [Page 2]
Internet-Draft Multimob MIP4 June 2008
1. Introduction
While more and more operators begin to provide the wireless broadband
network systems, the needs for multicast and broadcast service in
mobile network become promising.
Section 4.3 and 4.4 of [RFC3344] discuss the support of multicast and
broadcast. In order to receive multicast packet through it's home
network, a mobile node MUST join the multicast group in one of two
ways. One is based on co-located care-of address, the other is based
on the home address (foreign agent care-of address). In both cases,
a mobile node tunnels IGMP messages to its home agent, the home agent
forwards multicast datagrams down the tunnel to the mobile node.
Access network
(Wired or Wireless) IP multicast
| packets
+----+ | |
| MN1| V +------+ +------+ |
+----+---------------|======|=============| | |
+----+ | FA | | HA | V
| MN2|---------------|======|=============| |-----
+----+ +------+ +------+
Figure 1: Nested tunneling in MIP4 for Multicast
In the case of co-located care-of address, the home agent SHOULD
tunnel the datagram to this care-of address directly; In the case of
foreign agent care-of address, the home agent MUST first encapsulate
the datagram in a unicast datagram addressed to the mobile node's
home address and then MUST tunnel the resulting datagram (nested
tunneling) to the mobile node's care-of address.If there are more
than 500 MNs under the same FA, there will be 500 tunnels between HA
and FA to transmit multicast packets.
Deng Expires December 22, 2008 [Page 3]
Internet-Draft Multimob MIP4 June 2008
2. MIPv4 FA CoA multicast tunneling optimization
The characteristics of the link between MN and FA are different
depending on the types of access network and radio links. So,the
multicast optimization between MN and FA should be specific for
access network.
In this document, a new multicast foreign agent(MFA) is proposed to
optimize the multicast tunneling solution of MIPv4. 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
+----+ | |
| MN1| V +------+ +------+ |
+----+---------------|======| | | |
+----+ | MFA |=============| HA | V
| MN2|---------------|======| | |-----
+----+ +------+ +------+
Figure 2: Optimized MIP4 FA-CoA for Multicast
MFA is the termination point of the tunnel from HA. MFA should be
very close to ARs or even collocated with ARs. Compared with the
current multicast solution of MIPv4, the number of unicasting tunnels
for one streams multicast between one pair of MFA and HA will be
decreased to only one. This is especially meaningful when one HA
serves many MNs with multicast services.
Deng Expires December 22, 2008 [Page 4]
Internet-Draft Multimob MIP4 June 2008
3. Call flow of Multicast MIP4 FA CoA
The call flow of the optimized MIPv4 multicast is shown below:
MN p(MFA) n(MFA) HA MR
| | | | |
| IGMP host membership query | |
(0) |< ========================================|< ----------|
| | | | |
| IGMP host membership report | |
(1) |======================================== >|---------- >|
| | MC Notify | | |
(2) | |< -------------------------| Multicast |
| | single | | packets |
(3) | multiple | tunnel | |< ----------|
(4) | tunnels |< #########################| |
(5) |< ============| | | |
| | | | |
Handover to n(MFA) | | |
-------------------------------------------------------------
| RRQ | | | |
(6) |---------------------------------------- >| |
| RRQ | | | |
(7) |< ----------------------------------------| |
| | | MC Notify | |
(8) | | |< ---------| |
| | MC Notify | | |
(9) | |< -------------------------| Multicast |
| | single | | packets |
(10)| multiple | tunnel | |< ----------|
(11)| tunnels |< #########################| |
(12)|< ============| | | |
Figure 3: Call flow of Multicast MIP4 FA CoA
(0) HA forwards the IGMP host membership query message down to MNs
via the bi-directional tunnels periodically.
(1) MNs should report their multicast group membership by the IGMP
host 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 MFA with the information of related MN
addresses and multicast addresses. It may also put some other
streams related messages inside the notification message. MFA will
store this information inside the Multicast Serving Table (MST). HA
Deng Expires December 22, 2008 [Page 5]
Internet-Draft Multimob MIP4 June 2008
will also store the triple-units of (MN, MFA, Multicast Address) in
the local cache.
(3) HA receives one multicast stream from the multicast router. HA
will check the cached (MN, MFA, multicast address) based on the
multicast address of incoming multicast stream.
(4) HA will tunnel the stream to the related MFA with single tunnel.
The Outer IP header is from HA to MFA. The inner IP packet is the
original multicast packet.
(5) At MFA, it will check the MST and get the addresses of MNs who
have subsribes this multicast stream. MFA will make duplication of
the received tunnel packet based on the number of related MNs. then,
it will replace the destination addresses of the outer tunnel headers
with the home address 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 MFA, it will finish RRQ/
RRP procedure firstly with HA.
(8) On parallel, HA sends notification to the new MFA with the
information of multicast addresses =and MN addresses. The new MFA
stores this information inside the (MST) of it's own.
(9) HA notifies the old MFA 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, MFA, multicast address) based on the
multicast address of incoming multicast stream.
(11) The multicast packet will be tunneled to the new MFA
accordingly. The Outer IP header is from HA to new MFA. The inner
IP packet is the original multicast packet.
(12) The new MFA will do the same tunnel duplication and address
replacement as step (5)
Deng Expires December 22, 2008 [Page 6]
Internet-Draft Multimob MIP4 June 2008
4. Operation of Multicast Foreign Agent (MFA)
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.
4.1. Tunnel manipulation
The logical packet of the tunnel from HA is showed below:
+----------+------------+---------+--------------+---------+
| HA's Addr| MFA'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 MFA's address and HA's address
respectively. The inner IP packet is the original IP multicast
packet from the corresponding node(CN).
In MFA, 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 Home Address(HoA) 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 HoA |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 [RFC3344]. So, the
MN do not need to be modified in this solution.
4.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
information is sometimes useful for the stream manipulation. The
initiation, update and termination of MST entries should only be done
Deng Expires December 22, 2008 [Page 7]
Internet-Draft Multimob MIP4 June 2008
based on the notification messages from HA.
4.3. Operation of Multicast notification message
The definition of multicast notification message is a specific
message or extension to a generic notification message. Detail
definition explained as the below.
Subtype
(TBD) Multicast traffic notification message.
MD: Message Direction
1 -- Message sent by the home agent to the foreign agent.
A
This bit MUST be set to "1" to indicate that the multicast
notification message MUST be acknowledged by the foreign agent.
Deng Expires December 22, 2008 [Page 8]
Internet-Draft Multimob MIP4 June 2008
5. Security Considerations
This solution basically does not break the security framework of
MIPv4. Because IGMP membership messages should be tunneled, the data
traffic between HA and MN should be protected by authentication
extension. Notification messages could be protected by HA FA
authentication extension.
Deng Expires December 22, 2008 [Page 9]
Internet-Draft Multimob MIP4 June 2008
6. IANA Considerations
This document requests IANA to assign subtype 5 in generic
notification message to indicate this message is for the purpose of
multicast support.
Deng Expires December 22, 2008 [Page 10]
Internet-Draft Multimob MIP4 June 2008
7. Conclusion
This document extend the generic notification message to notify the
extended foreign agent to support multicast traffic in mobile IPv4.
Deng Expires December 22, 2008 [Page 11]
Internet-Draft Multimob MIP4 June 2008
8. Normative References
[Deng08] Deng, H., "Generic Notification Message for Mobile IPv4",
draft-ietf-mip4-generic-notification-message-03.txt (work
in progress), January 2008.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Deng Expires December 22, 2008 [Page 12]
Internet-Draft Multimob MIP4 June 2008
Author's Address
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui02@gmail.com
Deng Expires December 22, 2008 [Page 13]
Internet-Draft Multimob MIP4 June 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.
Deng Expires December 22, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:14:01 |