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]