idnits 2.17.1 draft-gohar-fmipv6-ftj-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 62 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 25, 2009) is 5329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FBU' is mentioned on line 290, but not defined == Unused Reference: 'RFC2119' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 346, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 5268 (ref. '4') (Obsoleted by RFC 5568) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Working Group Name Moneeb Gohar 2 Internet Draft Kyungpook National University 3 Intended status: Informational Seok Joo Koh 4 Expires: February 2010 Kyungpook National University 5 August 25, 2009 7 Fast Tree Join for Seamless Multicast Handover in Wireless/Mobile 8 Networks 9 draft-gohar-fmipv6-ftj-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may not be modified, 15 and derivative works of it may not be created, except to publish it 16 as an RFC and to translate it into languages other than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on February 25,2010 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This draft describes a fast handover mechanism to provide seamless 50 multicast services in the wireless/mobile networks based on the Fast 51 Mobile IPv6 (FMIPv6). When a mobile node (MN) moves from one access 52 router to another, it may encounter data loss. In the tree joining 53 case of the existing scheme, there is a problem of buffer overflow 54 during the packet forwarding from Previous Access Router (PAR) to New 55 Access Router (NAR), in which many packet losses may occur due to the 56 buffer overflow. In order to reduce this buffer overflow and the 57 concerned packet losses, we propose a new scheme of a fast tree join 58 for seamless multicast handover, which allows the NAR to join the 59 multicast tree before the FMIPv6 handover is completed. In the 60 proposed scheme, we consider the two specific cases: 1) the short 61 tree joining time, in which no packet forwarding will be required and 62 thus NAR can receive the multicast data from an upstream multicast 63 router before the FMIPv6 handover is completed, 2) the long tree 64 joining time, in which the packet forwarding will be required and 65 thus NAR will receive the multicast data after the FMIPv6 handover. 67 Table of Contents 69 1.Introduction.................................................. 2 70 2.Conventions used in this document............................. 6 71 3.Fast Tree Join for FMIPv6 Multicast Handover...................6 72 4.Conclusions....................................................8 73 5.References.....................................................9 74 5.1.Normative References......................................9 75 5.2.Informative References....................................9 76 Author's Addresses...............................................10 78 1. Introduction 80 The wireless data communication technologies are rapidly growing in 81 the communication industry [1]. Therefore, the movement or handover 82 in the wireless networks becomes one of the crucial issues to be 83 addressed [2]. The movement in the wireless/mobile networks can be 84 managed by using the Mobile IP (MIPv6) [3]. The MIPv6 was designed to 85 manage the movement of MN from one access router to another. To 86 improve the handover performance of MIPv6, the Fast Mobile IP 87 (FMIPv6) was proposed [4]. 89 In the modern era of data communication technology, the users have 90 demanded the multicast services in the wireless mobile networks, such 91 as Internet broadcasting and multiple video/audio conferencing. Some 92 schemes are needed to support the mobile multicasting such as 94 Gohar and Koh 95 construction of a multicast tree, the delivery of multicast data, and 96 joining and leaving the multicast group [5]. 98 This internet draft, describes a fast join to multicast tree for 99 seamless multicast handover to reduce handover latency with packet 100 losses and the signaling costs required for multicast handover. 102 The FMIPv6 is an extension of MIPv6 [4]. FMIPv6 can support the fast 103 handover, and reduce the handover latency and data loss. FMIPv6 can 104 also be used for fast handover of multicast sessions. Some works for 105 multicast fast handover have been proposed. One of these schemes the 106 work in [6] proposed to use the multicast group information option in 107 the fast binding update message (FBU) and in the handover initiation 108 message (HI). In the scheme, the PAR transmits the multicast group 109 information to the NAR through FBU, which may has taken a long join 110 delay. Recently, another scheme has been proposed for efficient 111 multicast [1], which introduced the new multicast options in the 112 mobility header to record the multicast group information. This 113 scheme also establishes a tunnel between PAR and NAR. 115 We note that a scheme of FMIPv6-based multicast handover that was 116 proposed in [7], where the ''Fast handover based on Mobile IP for 117 Multicasting'' (denoted by FMIP-M) scheme, as presented in Fig. 1 119 Gohar and Koh 120 MN PAR NAR HA RP 122 | | | | | 124 |--RtSolPr->| | | | 126 |<-PrRtAdv--| | | | 128 |---FBU---->| | | | 130 | |----HI-------------> | | | 132 | |<---HACK------------ | | | 134 | <--FBACK--|---FBACK---> | | | 136 Disconnect | | | | 138 | |=Path Extension=====>| | | 140 | |=Packet Forwarding==>| | | 142 | | |--------PIM JOIN------->| 144 | | |<-------PIM JOIN ACK----| 146 | | |<===Multicast Tree Data=| 148 | |<--HO COMPLETE------ | | | 150 Connect | | | | 152 |----------UNA------------------> | | | 154 | | |----BU------>| | 156 | | |<----BU ACK--| | 158 | | |<=Tunneling==| | 160 | |<---HO COMPLETE----- | | | 162 |<====Multicast Data Delivery=====| | | 164 Figure 1. Existing FMIP-M scheme 166 Gohar and Koh 167 In the FMIP-M scheme, MN receives an L2 trigger and sends a Router 168 Solicitation for Proxy (RtSolPr) to the PAR. The PAR replies to MN 169 with a Proxy Router Advertisement (PrRtAdv). MN then obtains a new 170 care of address (nCoA). The fast handover procedure actually starts 171 by sending a Fast Binding Update (FBU) message towards PAR that 172 contains a multicast group address. Given the information contained 173 in the FBU message, PAR sends a Handover Initiation (HI) message to 174 NAR. The HI message contains the information about Multicast Status 175 (M-Status), Hop Count (HC) from the multicast tree, and multicast 176 group address. The NAR will check the validity and uniqueness of the 177 nCoA. After that, NAR can reply to the PAR with a Handover 178 acknowledgement (HACK) message. It contains the M-Dec field, which 179 indicates a specific method used by NAR for multicast handover. In 180 addition, the HACK message may also contain the information of the 181 sequence number of data packets that will be maintained in the new 182 access router's buffer (denoted by SEQNARBuff in [7]), which is used 183 only when the M-Dec is set to 3. This SEQNARBuff represents the 184 sequence number of the first packet that will be stored in the NAR 185 buffer. The PAR then sends the Fast Binding Acknowledge (F-BACK) 186 message to MN and NAR both. 188 After sending the F-BACK message, the PAR begins to forward the 189 multicast data packets to NAR, in which the four specific cases can 190 be considered, as described in [7], which will be indicated by using 191 the M-Dec field of the HACK message. These four schemes can be 192 summarized as follows: 194 . Case 1 (Path Extension), in which the multicast service path is 195 extended from PAR to NAR. In this case, after the PAR received this 196 decision from the HACK message, the PAR started to forward the 197 multicast packets to NAR. This packet forwarding is performed until 198 NAR requests PAR to terminate the path extension; 199 . Case 2 (Bi-directional tunneling from Home Agent (HA)), in which in 200 this case, the PAR starts to forward the multicast packets (received 201 via the bi-directional tunneling) from the HA to NAR. This packet 202 forwarding will be continued until PAR receives the HO COMPLETE 203 message from NAR. 204 . Case 3 (Remote Subscription), in which NAR sends a tree join message 205 (PIM JOIN) to the upstream multicast source, which is indicated as 206 Rendezvous Point (RP) in Fig. 1. For the join message, the RP will 207 respond to NAR with a Join Ack (PIM JOIN-ACK) message, and then the 208 multicast data packets are now delivered to the NAR by using the 209 newly configured multicast tree. In this case, the PAR will also 210 forward the multicast packets, if any, to NAR. 212 Gohar and Koh 213 . Case 4, in which it is assumed that one of the users in the NAR 214 region has already joined the same multicast group and thus the NAR 215 is receiving the corresponding group data packets. So, in this case, 216 the PAR had only to forward the previously buffered multicast packets 217 to NAR. 218 On the other hand, when MN moves to the new network, it will send an 219 Unsolicitated Neighbor Advertisement (UNA) message to the NAR to 220 indicate that the handover has been completed, as done in the FMIPv6. 222 It is noted that the existing scheme may incur the 'buffer 223 overflow problem' in the buffer of PAR during the tree join process. 224 That is, if the tree join by NAR to RP takes a long time, the buffer 225 of PAR for packet forwarding may overflow and thus a significant 226 amount of data packets could be lost. In addition, the existing 227 scheme also tends to give have the large signaling and packet 228 forwarding costs. 230 In this draft, we propose a fast tree join scheme for seamless 231 multicast handover, in which the NAR will try to join the multicast 232 tree as soon as the handover event is detected (i.e., when NAR 233 receives the HI message from the PAR). The proposed scheme can also 234 reduce the signaling costs associated with the multicast handover. 236 2. Conventions used in this document 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 240 document are to be interpreted as described in RFC-2119 Error! 241 Reference source not found.. 243 3. Fast Tree Join for FMIPv6 Multicast Handover 245 In this draft, we describe a fast tree join (FTJ) scheme for seamless 246 multicast handover based on the FMIPv6 protocol, which is denoted by 247 FTJ-FMIP in this paper. The proposed scheme focuses on how to combine 248 the multicast service with the existing fast handover procedure for a 249 fast and reliable multicast packet delivery. In the proposed scheme, we 250 consider the following three cases: Path Extension method, Bi- 251 Directional Tunneling, and Remote Subscription. The fourth case, in 252 which NAR has already joined the tree, is not considered, since it is 253 too much trivial. 255 Gohar and Koh 256 In the tree joining case, we consider the following two scenarios: (a) 257 short tree join, in which the tree join process is completed before NAR 258 receive the FBACK message from PAR, and (b) long tree join, in which the 259 tree join is completed after NAR receives the FBACK message. In the 260 first case (short tree join), the PAR does not need to forward the data 261 packets to NAR, and instead NAR will receive the multicast data packets 262 directly from the multicast tree, and then send the HO COMPLETE message 263 to PAR On the other hand, in the second case, the NAR will receive some 264 of multicast data packets from PAR, until the tree join process is 265 completed. 267 Figure 2 shows the basic operation of the proposed FMIPv6-FTJ 268 scheme. 270 Upon receiving an indication from a wireless link-layer trigger, MN 271 initiates the handover by sending a message RtSolPr that contains both 272 the FBU option and the multicast address. After receiving the RtSolPr 273 message, PAR sends the PrRtAdv message to MN. At the same time, PAR will 274 send the HI message to the NAR. 276 When receiving the HI message, the NAR will immediately respond 277 with the HACK message to PAR, and then begin the tree join to the RP by 278 sending the PIM JOIN message. (FMIPv6-FTJ with Remote Subscription): in 279 which the tree join is completed earlier (i.e., before the NAR receives 280 the FBACK message from PAR). In this case, the NAR will receive the PIM 281 JOIN-ACK message from the upstream RP, and then send the HO-COMPLETE 282 message to the PAR. Accordingly, the PAR will not perform the packet 283 forwarding to NAR. 285 Gohar and Koh 286 MN PAR NAR RP 288 | | | | 290 |-RtSolPr[FBU] ->| | | 292 |<-PrRtAdv------ |----HI-------------> |--------PIM JOIN-------->| 294 | |<---HACK------------ | | 296 | | | | 298 | | |<-------PIM JOIN ACK-----| 300 | | |<===Multicast Tree Data==| 302 | |<---HO COMPLETE----- | | 304 | <--FBACK--|---FBACK---> | | 306 Disconnect | | | 308 | | | | 310 | | | | 312 | | | | 314 Connect | | | 316 |----------UNA------------------------>| | 318 |<======Multicast Data Delivery========| | 320 Figure 2. Proposed FMIPv6-FTJ scheme 322 To support the proposed FMIPv6-FTJ scheme, we suggest to use the three 323 modified messages. The existing RtSolPr and FBU messages are merged into 324 a single RtSolPr message that contains the FBU option and multicast 325 address. Note that the other two messages, HI and HACK, are changed to 326 include the MN ID (Home Address of MN) and the multicast address. 328 4. Conclusions 330 This internet draft describes a fast tree join for seamless multicast 331 handover in the FMIPv6-based wireless/mobile networks. In the 332 existing scheme, there may be a buffer overflow problem during the 334 Gohar and Koh 335 tree join process. Due to this buffer overflow problem, many packets 336 may be lost. TO overcome this drawback, the proposed scheme will 337 begin to join the multicast tree, as soon as the handover is detected. 339 5. References 341 5.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 347 Syntax Specifications: ABNF", RFC 2234, Internet Mail 348 Consortium and Demon Internet Ltd., November 1997. 350 5.2. Informative References 352 [1] D. H. Kwon, et al., Design and implementation of an efficient 353 multicast support scheme for FMIPv6, INFOCOMM2006, pp. 1- -12, 2006. 355 [2] Nicolas Montavont and Thomas noel, ''Handover Management for 356 Mobile Nodes in IPv6 Networks,'' IEEE Communication Magazine, August 357 2002. 359 [3] D. Johnson, et al., ''Mobility Support in IPv6'', IETF RFC 3775, 360 2004. 362 [4] R. Koodli, ''Mobile IPv6 Fast Handovers'', IETF RFC 5268, 2008. 364 [5] Y. Min-hau, et al., ''The Implementation of Multicast in Mobile 365 IP'', IEEE Wireless Communications and Networking Conference, pp. 366 1796- -1800, 2003. 368 [6] F. Xia, and B. Sarikaya, FMIPv6 extension for multicast Handover, 369 draft-xia-mipshop-fmip-multicast-01, work in progress, March 2007. 371 [7] SANG-JO YOO and SEAK-JAE SHIN, ''Fast Handover Mechanism for 372 Seamless Multicasting Services in Mobile IPv6Wireless Networks,'' 373 Wireless Personal Communications 42:509- -526, 2007. 375 Gohar and Koh 376 Author's Addresses 378 Moneeb Gohar 379 Kyungpook National University, KOREA 381 Email: moneebgohar@gmail.com 383 Seok Joo Koh 384 Kyungpook National University, KOREA 386 Email: sjkoh@knu.ac.kr 388 Gohar and Koh