IETF MIPSHOP Working Group Kyungjoo Suh
Internet Draft Samsung Electronics
Dong-Hee Kwon
Young-Joo Suh
POSTECH
Youngjun Park
Samsung Electronics
Document: draft-suh-mipshop-fmcast-mip6-00.txt
Expires: July 2004 January 2004
Fast Multicast Protocol for Mobile IPv6
in the fast handovers environments
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This document defines the Fast Multicast Protocol for Mobile IPv6
[2] in the Fast Handovers environments whereby a mobile node (MN)
can receive multicast data with reduced loss and delay after
handoffs. The proposed protocol can be implemented by the simple
modification of the Fast Handovers protocol [1] so that it can be
easily applied to the Fast Handovers for Mobile IPv6. This document
does not need a certain assumption of a specific multicast routing
protocol, so that any existing multicast routing protocol can be
used with the proposed protocol.
Suh, et al [Page 1]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Fast Multicast protocol . . . . . . . . . . . . . . . 4
4. Fast Multicast Protocol Operation . . . . . . . . . . . . . . . . 5
4.1 Fast Multicast in Predictive Fast Handovers environment . . . 7
4.2 Fast Multicast in Reactive Fast Handovers environment . . . . 8
4.3 Message Format in Fast Multicast protocol . . . . . . . . . 9
4.3.1 Modified PrRtAdv Message Format . . . . . . . . . . . . 9
4.3.2 MH Multicast Address Option Format . . . . . . . . . . 10
4.3.3 ICMP Multicast Address Option Format . . . . . . . . . 11
5. Security Consideration . . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Suh, et al [Page 2]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
1. Introduction
Mobile IP has been proposed to provide a seamless connection when
a MN changes the point of attachment to the network. In general,
in the basic Mobile IPv6 [2], the multicast data delivery schemes
are defined in addition to the unicast data delivery. In the Mobile
IP, some packets for the MN may be lost when a MN handoffs between
two access routers. Although the Fast Handovers protocol [1] is
proposed to reduce such loss and delay, it focuses on the unicast
data delivery. This means the Fast Handovers protocol cannot
reduce the multicast data loss and delay during MN's handoffs.
If a MN wants to receive a multicast data, it should subscribe to
a corresponding multicast group. When a MN handoffs to a new
network that does not subscribe to a multicast group in which a MN
interests, it should initiate a procedure to subscribe to a
multicast group after finishing a handoff procedure. The fact
causes a multicast data loss and delay.
This document describes a Fast Multicast protocol to reduce a
multicast data loss and delay. In the proposed protocol, a MN sends
the information about a multicast group to which MN subscribes, to
the current access router before a MN handoffs to another network.
After receiving this information, the current access router sends
this information to the nearby access router to which the MN will
handoff in order to subscribe to a multicast group. When the MN
handoffs to another network, the access router of the network can
deliver multicast data packets to the MN, because it already
subscribes to a multicast group. Therefore the MN can receive
multicast data with reduced loss and delay after handoffs. The
proposed protocol can be implemented by the simple modification of
Fast Handovers protocol [1] so that it can be easily applied to Fast
Handovers protocol for Mobile IPv6.
2. Terminology
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 describe in RFC 2119.
In this document, some terminologies are same as defined in the
Fast Handovers protocol [1] such as MN, AR, NAR, PAR, RtSolPr,
PrRtAdv, HI, Hack, FBU, FBack, FNA, etc. The following terminologies
are used in this document.
Multicast Service
One to many communication service by which a node joining in a
specific multicast group can receive data from a multicast
sender.
Suh, et al [Page 3]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
Multicast Latency
The time difference between when a MN is last able to send
and/or receive a multicast data packet by way of the PAR, and
when the MN is able to send and/or receive a multicast data
packet through the NAR.
3. Overview of Fast Multicast protocol
Fast Multicast protocol presents MNs with a fast and seamless
multicast data delivery by exchanging information related to a
multicast group between ARs (PAR and NAR). By Fast Multicast
operations, a NAR can learn, in advance, the information on a
multicast group in which the MN interests. The main goal of the
Fast Multicast is minimizing the Multicast Latency that is
required when a MN moves from one AR to another while receiving
a Multicast Service. The Fast Multicast can be applied to the Fast
Handovers protocol with slight modification. Furthermore, the Fast
Multicast is independent of multicast routing protocols.
If a MN wants to receive a Multicast Service continuously after
handoffs to a network managed by NAR, the Fast Multicast protocol
lets a NAR subscribe to a multicast group, in advance, before the
MN handoffs to its network. During a Fast Handovers protocol
process, MN sends a FBU message to a PAR with new multicast address
option. The new multicast address option contains a multicast
address(es) which a MN subscribes to and wants to receive a
multicast service after handoffs to a NAR network. After receiving
a FBU message, a PAR exchanges HI/Hack messages between a NAR and
itself. A PAR sends multicast address option when it sends a HI
message to a NAR. A NAR subscribes to a multicast group contained
in the multicast address option when receiving a HI message. If a
NAR refuses to subscribe to a multicast group, it sends that
information to a PAR with HAck message and a PAR to a MN with FBack
message. Through this procedure, a MN can receive a multicast data
from the NAR when it completes a Fast Handovers procedure.
If there are some multicast groups that a NAR refuses to subscribe
to, a MN receives a multicast data from a PAR using established
tunnel between a PAR and a NAR. When a multicast receiver is a MN
which handoffs to a neighbor network, a PAR forwards a MLD Query
message to the MN using tunnel between a PAR and a NAR. If the MN
replies to the MLD Query message with a MLD Report message, a PAR
forwards a multicast data packet to the MN. Therefore the MN can
receive a multicast data packet.
Suh, et al [Page 4]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
4. Fast Multicast Protocol Operation
Figure 1 and Figure 2 show a Fast Multicast protocol operation in
a Predictive and Reactive Fast Handovers environment.
In the Fast Multicast protocol, one new flag and two new options
are defined as followings:
Multicast Service (M) bit
It indicates whether the AR which a MN requests a L3 information
in a RtSolPr message supports a multicast service or not.
Mobility Header Multicast Address Option
It is a new mobility header option which contains a multicast
address(es) that a MN subscribes to. It is refered as MH
Multicast Address Option in this document. The format of this
option is defined in section 4.3.
ICMPv6 Multicast Address Option
It is a new ICMPv6 option which contains a similar information
of a Mobility Header Multicast Address Option. The proposed
protocol also defines a new ICMPv6 option that has similar
information because HI and HAck messages of a Fast Handovers
protocol are delivered using ICMPv6. It is refered as ICMP
Multicast Address Option in this document. The format of this
option is defined in section 4.3.
In a Predictive Fast Handovers protocol, when the PAR receives a FBU
message, it knows that the MN handoffs soon and informs the NAR of
this information through the exchange of HI and HAck messages. The
PAR includes ICMP Multicast Address Option in the HI message to
transmit a multicast address(es) if a MN wants to receive a
Multicast Service in a network managed by NAR. The NAR receiving HI
message transmits HAck message with an ICMP Multicast Address Option
which informs whether it supports requested Multicast Service or not.
If the NAR accepts a request, it joins a multicast group(s). The PAR
receiving HAck message copies the multicast address(es) in the ICMP
Multicast Address Option to the MH Multicast Address Option in the
FBack message, and sends the message to the MN to inform the MN of
success or failure of the Multicast Service request. Therefore,
the MN knows success or failure of Multicast Service request when
receives the FBack message. If Multicast Service request succeeds,
the MN informs the NAR of its arriving after handoffs by sending
FNA message with MH Multicast Address Option. The MH Multicast
Address Option in the FNA message requests the NAR to forward the
multicast data to the MN.
In a Reactive Fast Handovers protocol, the MN does not receive FBack
message on the PAR network. The MN sends FNA message as soon as it
attaches to the NAR with FBU message. In order to enable the NAR to
Suh, et al [Page 5]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
MN PAR NAR
| | |
|--------RtSolPr---------->| |
|<----- PrRtAdv(M bit) ----| |
| | |
|-----------FBU----------->|----------HI------------>|
| (MH Multicast Option) | (ICMP Multicast Option) |
| | Join to
| | Multicast
| | Group
| |<--------HAck------------|
| | (ICMP Multicast Option) |
| | |
| <----FBack-----|----FBack-----> |
| (MH Multicast Option) | (MH Multicast Option) |
| | |
disconnect forward |
| packets====================>|
| | |
| | |
connect | |
| | |
|------------- FNA (MH Multicast Option) ----------->|
|<=============================================== deliver
| | packets
| | |
Figure 1: Fast Multicast in Predictive Fast Handover
MN PAR NAR
| | |
|--------RtSolPr---------->| |
|<----- PrRtAdv(M bit) ----| |
| | |
disconnect | |
| | |
connect | |
| | |
|-------- FNA[FBU(MH Multicast Option)] ------------>|
| | Join to
| | Multicast
| | Group
| |<-------- FBU -----------|
| | |
| |-------- FBack --------->|
| | |
| forward |
| packets====================>|
| | |
|<=============================================== deliver
| | packets
| | |
Figure 2: Fast Multicast in Reactive Fast Handover
Suh, et al [Page 6]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
forward packets immediately (when FBU message has been processed),
the MN encapsulates FBU message in FNA message. The exchange
procedure of the FBU and FBack message between PAR and NAR is
defined in the Fast Handovers protocol. The NAR subscribes to a
multicast group using the multicast address informed by the MH
Multicast Address Option. Except this, other operations are same
as defined in the Fast Multicast protocol when the Predictive Fast
Handovers Protoocl is used.
4.1 Fast Multicast in Predictive Fast Handovers environment
All description of this section makes use of Figure 1 as the
reference.
When a MN determines to handoff soon, it sends a RtSolPr message
to a PAR as defined in the Fast Handovers protocol. In response,
the PAR sends a PrRtAdv message including M bit that represents
whether the corresponding NAR supports a Multicast Service or not.
The method by which Access Routers exchange information about the
Multicast Service support of their neighbors is outside the scope
of this document. If the NAR supports a Multicast Service, this
bit SHOULD be set to 1. With the information provided in the
PrRtAdv message, the MN knows whether the NAR can support a
Multicast Service or not. If the MN does not interest in a
Multicast Service, it silently ignores the M bit. After then the
MN sends a FBU message including a MH Multicast Address Option.
The purpose of MH Multicast Address Option is to inform the PAR
of the multicast address(es) which a MN subscribes to.
The PAR receiving a FBU message with a MH Multicast Address Option
SHOULD send the HI message to the NAR with an ICMP Multicast
Address Option which is derived from the MH Multicast Address Option
of the FBU message. Through ICMP Multicast Address Option in a HI
message, the NAR knows that the MN wants to receive a Multicast
Service after handoffs. Therefore the NAR checks whether it can
support Multicast Service or not. If the NAR cannot support a
requested Multicast Service, it SHOULD send the HAck message to the
PAR with an ICMP Multicast Address Option. The purpose of this ICMP
Multicast Address Option is to inform the MN of the multicast
address(es) that the NAR cannot subscribe to. When the NAR can
support of some of multicast Services, only address(es) that the
NAR refused to subscribe is included in the ICMP Multicast Address
Option. Therefore there is no ICMP Multicast Address Option if the
NAR can support all of the Multicast Service requested in
the ICMP Multicast Address Option of a HI message.
The NAR also joins the multicast group to which it subscribe for
supporting MN. The method by which the NAR joins to a multicast
group is outside the scope of this document. After the PAR receives
a Hack Message from the NAR, it sends a FBack message to the MN.
This message also includes the MH Multicast Adddress Option derived
from the ICMP Multicast Address Option of the HACK message. The
purpose the MH Multicast Address Option is the same as the ICMP
Suh, et al [Page 7]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
Multicast Address Option of the Hack Message.
If the MN receives FBack message without MH Multicast Address Option
the NAR can support all of the Multicast Service requested by the MN.
In that case, the MN sends a FNA message with MH Multicast Address
Option which the MN wants to subscribes to after complete the
handover procedure. Through the multicast address(es) of this
option, the NAR can send multicast data to the MN.
If the NAR refuses the MN's request, the MN cannot receive a
Multicast Service at the NAR's network after handoffs. In this
case, some other methods are required to support seamless Multicast
Service. In the proposed protocol, the PAR forwards a multicast
data to the MN using tunnel between the PCoA and the NCoA. The ICMP
MLD protocol is assumed to manage multicast group members in the
proposed protocol.
The PAR sends periodically an ICMP MLD Query message to its network.
If a multicast receiver exists in a different network, the PAR
forwards an ICMP MLD Query message to a remote multicast receiver
(e.g. MN) when the tunnel exits. In the proposed protocol, the
tunnel is created between a PCoA and a NCoA as defined in the Fast
Handovers protocol. When the MN receives a MLD Query message from
the PAR through a tunnel, it sends a MLD Report message in response
to a MLD Query message if it wants to receive a Multicast Service
from the PAR.
When the PAR receives multicast data, it checks whether the tunnel
exists between the PCoA and the NCoA, and then checks whether it
should forward the multicast data through the tunnel or not. The PAR
forwards a multicast data through the tunnel when the tunnel exists
and there is a multicast receiver. Based on these procedures, the MN
can receive seamless Multicast Service within the network where the
Multicast Service is not supported.
This method can be also applied to a case in which the NAR accepts
a Multicast Service but the join procedure has not been finished yet
after MN's handover. In this case, the MN replies to the MLD Query
Message from the PAR by the MLD Report message to maintain tunnel
until the join procedure is finished. Therefore the MN can receive
multicast data from the PAR. When the join procedure is finished,
the NAR starts to send the MLD Qurey message and the MN sends a MLD
Report message in response. As the MN replies to the MLD Query
message from the PAR by the MLD Done message, the PAR does not
forward the multicast data to the MN any more.
4.2 Fast Multicast in Reactive Fast Handover environment
All description of this section makes use of Figures 2 as a
reference.
Suh, et al [Page 8]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
In the Reactive Fast Handover protocol, the MN does not receive a
FBack message at the PAR's network. Therefore the MN should send
immediately a FNA with FBU message when it detects an attachment to
a NAR's network. The MN also sends a MH Multicast Address Option in
the FBU message. When the NAR receives a FNA with FBU message from
a MN, it sends a FBU message included in the FNA message to the PAR.
Before the NAR sends a FBU message to the PAR, it joins to a
multicast group(s) which a MN requests to subscribe to. The PAR
sends a FBack message to the NAR in response to the FBU message.
In addition, the PAR forwards a MLD Query message to the MN. Through
this procedure, the MN can receive a Multicast Service at the NAR
network when the Reactive Fast Handovers protocol is used.
4.3 Message Formats in Fast Multicast protocol
Basic message formats of the proposed Fast Multicast Protocol are
the same as defined in the Fast Handovers protocol. Only the PrRtAdv
message is slightly modified. The proposed protocol also defines
new MH Multicast Option and ICMP Multicast Option.
4.3.1 Modified PrRtAdv Message Format
The Proposed protocol modifies the format of PrRtAdv message by
adding a single flag bit in the Reserved field to indicate whether the
neighbor AR which a MN request in RtSolPr message
supports multicast service or not. When the MN does not interest
in a multicast service, it silently ignores this bit. The format of
the PrRtAdv Message is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally
specified in the Fast Handovers protocol[1]:
Multicast Service (M)
The Multicast Service (M) bit is set in PrRtAdv message to indicate
that the AR which MN requests in RtSolPr message also supports
multicast service
Suh, et al [Page 9]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
Reserved
Reduced from a 16-bits field to a 15-bits field on account of
the addition of the above bit
The PrRtAdv message MAY have options. These options MUST use the
Option format defined in Fast Handovers [1].
4.3.2 MH Multicast Address Option Format
The proposed protocol defines a new mobility option, Multicast
Address option, that can be used in a FBU and FNA messages to
indicate the multicast address(es) which a MN wishes to subscribe
to. The format of the MH Multicast Address option is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8-bit unsigned integer, representing the length in octets of the
mobility options, not including the Type and Length field
Number
Number of the multicast address which presents in Multicast
Address field.
Reserved
Must be set to zero by the sender and ignored by the receiver.
Multicast Address
Multicast address which a MN currently subscribes to. MAY be more
than one because MN can subscribe to several multicast addresses.
Suh, et al [Page 10]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
4.3.3 ICMP Multicast Address Option Format
The proposed protocol defines a new ICMPv6 option, Multicast Address
option, used in a HI and HAck messages. In the HI messages, this
option notifies a NAR of the multicast address(es) which a MN
continuously wants to subscribe to after connected to NAR's network.
In the HAck message, this option notifies a PAR, a NAR through a
FBack message, of the multicast address(es) which a NAR cannot
support. The format of the ICMP Multicast Address option is as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8-bit unsigned integer, representing the length in octets of the
mobility options, not including the Type and Length field
Sub-Type
0
Number
Number of the multicast address which presents in Multicast
Address field.
Multicast Address
Multicast address which is copied from Fast Binding Update. MAY
be more than one because MN can send Fast Binding Update to PAR
with several multicast addresses.
Suh, et al [Page 11]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
5. Security Considerations
The security considerations resulting from the use of this framework
do not offer any higher level of security in basic mobile IP
operation. Therefore, in the next version of this document will
include an appropriate level of security for Fast Multicast protocol.
Acknowledgements
The authors would like to acknowledge the contribution from Woo-Jae Kim
to improve this specification.
References
[1] Rajeev Koodli, "Fast Handovers for Mobile IPv6", Internet Draft,
draft-ietf-mipshop-fast-mipv6-00.txt, October 2003
[2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24.txt, June 2003
[3] C.perkins, "IP Mobility Support for IPv4", RFC3344, August 2002
[4] S. Deering, W. Fenner and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999
Author's Address
Questions about this memo can be directed to:
Kyungjoo Suh (Joo Suh)
Global Standards and Strategy team
Telecommunication R & D Center
Samsung Electronics Co., LTD.
Dong Suwon P.O. BOX 105,
416, Maetan-3dong, Youngtong-gu,
Suwon-city, Gyeonggi-do, 442-600
Korea
Phone: +82-31-279-5123
Email: joo.suh@samsung.com
Fax: +82-31-279-5130
Dong-Hee Kwon
POSTECH
Dept. of Computer Science and Engineering
Pohang, KOREA
Phone: +82-54-279-5671
E-Mail: ddal@postech.edu
Fax: +82-54-279-5699
Suh, et al [Page 12]
INTERNET-DRAFT Fast Multicast Protocol for Mobile IPv6 January 2004
Young-Joo Suh
POSTECH
Dept. of Computer Science and Engineering
Pohang, KOREA
Phone: +82-54-279-2243
E-Mail: yjsuh@postech.edu
Fax: +82-54-279-5699
Youngjun Park
Global Standards and Strategy team
Telecommunication R & D Center
Samsung Electronics Co., LTD.
Dong Suwon P.O. BOX 105,
416, Maetan-3dong, Youngtong-gu,
Suwon-city, Gyeonggi-do, 442-600
Korea
Phone: +82-31-279-5979
Email: youngjun74.park@samsung.com
Fax: +82-31-279-5130
Suh, et al [Page 13]