idnits 2.17.1 draft-hui-multimob-fast-handover-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'N' on line 343 == Outdated reference: A later version (-11) exists of draft-asaeda-multimob-pmip6-extension-01 ** Obsolete normative reference: RFC 5268 (ref. '2') (Obsoleted by RFC 5568) -- No information found for draft-irtf-mipshop-pfmipv6 - is the name correct? -- No information found for draft-zhao-multimob-pmipv6-solution - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Area M.Hui 2 Internet Draft H.Deng 3 Intended status: Informational D.Liu 4 Expires: Sep. 13, 2012 China Mobile 5 March 13, 2012 7 Fast Handover for Multicast in Proxy Mobile IPv6 8 draft-hui-multimob-fast-handover-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on Jan 01, 2011. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 38 Relating to IETF Documents (http://trustee.ietf.org/license-info) 39 in effect on the date of publication of this document. Please 40 review these documents carefully, as they describe your rights and 41 restrictions with respect to this document. 43 Abstract 45 This document specifies the predictive fast handover mechanism to solve 46 the problem of handover latency and packet loss in Proxy Mobile IPv6 47 Multicast. Necessary extensions are specified for Handover Initiate 48 (HI) and Handover Acknowledgement (HAck) messages to support 49 multicast handover procedure. 51 Table of Contents 53 1. Introduction................................................4 54 2. Problem Statement...........................................5 55 3. Terminology.................................................6 56 4. Protocol Operation..........................................7 57 5. Message Format.............................................11 58 6. Security Considerations.....................................13 59 7. IANA Considerations........................................14 60 8. References.................................................15 61 8.1. Normative References...................................15 62 8.2. Informative References.................................15 63 Author's Addresses............................................16 65 1. Introduction 67 Proxy Mobile IPv6 (PMIPv6) protocol provides local mobility 68 management to a mobile node without requiring any modification of the 69 mobile node. The Local Mobility Anchor (LMA) and Mobile Access 70 Gateway (MAG) perform the mobility management signaling on behalf of 71 the mobile node. Extensions for LMA and MAG are specified in [1] to 72 support IP multicast in PMIPv6. Nevertheless, the basic performance 73 including handover latency and packet loss is not considered 74 different form that of PMIPv6. 76 Fast handover for Mobile IPv6 is specified in [2]. [3] extends the 77 FMIPv6 and applies it to the PMIPv6 in order to decrease handover 78 latency and packet loss as well as transfer of network-resident 79 contexts. However, IP multicast is not considered in fast handover 80 for PMIPv6. 82 We propose a fast handover mechanism to support multicast for PMIPv6. 83 Necessary extensions are specified in HI and HAck message to transfer 84 the multicast node's context information and deliver the multicast 85 data before the set up of tunnel between n-MAG and LMA. 87 2. Problem Statement 89 The existing solution for PMIPv6 multicast [1] specifies that, only 90 after the bi-directional tunnel is built between n-MAG and LMA using 91 extended PBU (PBU-M) message, the multicast packet can be 92 continuously delivered to MN. It inevitably causes the latency and 93 loss of packet during handover process. 95 The solution presents two ways to acquire the MN's profile, which 96 includes MN' ID and multicast state information. One way is to use 97 the Context Transfer Protocol (CXTP) [4] to transfer MN's profile 98 from p-MAG to n-MAG. In the other way, if MN's profile is stored in a 99 policy store [5], n-MAG obtains MN's multicast state by the same 100 mechanism used to acquire MN' ID and profile during MN's attachment 101 process [5]. 103 In another PMIPv6 multicast solution [6], the author proposes normal 104 handover and fast handover for proxy mobile multicast service. There 105 is no any optimization in normal handover, the handover involves MN 106 by running the MLDv2 [7] protocol with n-MAG to receive the related 107 multicast packet. In the fast handover procedure, similar to the 108 first method used in [1],the context transfer is used to provide 109 multicast information. Although n-MAG can acquire the MN' multicast 110 information before MN handovers to it, only after n-MAG joins the 111 multicast group, it can receive the multicast data. 113 3. Terminology 115 This document refers to [1] [2] [3] for terminology. The following 116 terms and abbreviations are additionally used in this document. The 117 reference network is illustrated in Figure 1. 119 Previous Mobile Access Gateway (p-MAG): 121 The MAG that manages mobility related signaling for the MN 122 before handover. 124 New Mobile Access Gateway (n-MAG): 126 The MAG that manages mobility related signaling for the MN after 127 handover. 129 HO-Initiate: 131 A generic signaling that indicates the handover of the MN sent 132 from the MN to the p-MAG. It is assumed that HO-Initiate can 133 carry the information to identify the MN and to assist the p-MAG 134 to resolve the n-MAG. 136 4. Protocol Operation 138 The architecture of fast handover for multicast in Proxy Mobile IPv6 139 is shown in Figure 1. A multicast tunnel is established to transfer 140 the multicast data from p-MAG to n-MAG before the n-MAG joins the 141 multicast group, so that whenever the MN handovers to the n-MAG, it 142 can receive the multicast data from n-MAG. 144 +----------+ 145 | LMA | 146 | | 147 +----------+ 148 / \ 149 / \ 150 / \ 151 +........../..+ +..\..........+ 152 . +-------+-+ .______. +-+-------+ . 153 . | p-MAG |()_______)| n-MAG | . 154 . +----+----+ . . +----+----+ . 155 . | . . | . 156 . | . . | . 157 . +----+ . . +----+ . 158 . | MN | ----------> | MN | . 159 . +----+ . . +----+ . 160 +.............+ +.............+ 162 Figure 1: Reference network for fast handover 164 In order to decrease the handover latency and packet loss, this 165 document specifies a bi-directional tunnel between the Previous MAG 166 (p-MAG) and the New MAG (n-MAG). As the n-MAG needs the multicast 167 node's context information to set up a bi-directional tunnel to 168 continuous deliver multicast packet to mobile node, the HI and HAck 169 messages are extended to support mobile multicast node's context 170 transfer, in which parameters such as MN ID, MN Multicast State, are 171 transferred from the p-MAG to the n-MAG. The sequence of events 172 illustrating the fast handover for multicast is shown in Figure 2. 174 MN p-MAG n-MAG LMA 176 | | | | 178 (1) | HO Initiate | | | 180 | --(MN ID,-->| | | 181 | n-MAG ID) | | | 183 (2) | | HI | | 185 | | --(MN ID, --> | | 187 | MN Multicast State) | 189 | | | | 191 (3) | | <---HAck--- | | 193 | | (MN ID) | | 195 | | | | 197 | | HI/HAck | | 199 (4) | |<------------->| | 201 | | | | 203 (5) | | M data | | 205 | |====tunnel====>| | 207 (6) ~~~ | | | 209 ~~~ | | | 211 | | | | 213 (7) |<==========M data============| | 215 | | | | 217 (8) | | |------PBU-M------->| 219 | | | | 221 (9) | | |<-----PBA----------| 223 | | | | 225 (10) | | | M data | 227 | | |<==bi-dir tunnel==>| 228 | | | | 230 (11) | | HI/HAck | | 232 | |<------------->| | 234 | | | | 236 Figure 2: Fast handover for PMIPv6 multicast 238 The detailed descriptions are as follows: 240 (1)The MN detects that a handover is imminent and reports the 242 MN ID and n-MAG ID. 244 (2)The p-MAG sends the HI to the n-MAG. The HI message includes 246 MN ID and MN Multicast State. 248 (3)The n-MAG sends the HAck back to the p-MAG. 250 (4)The n-MAG requests the p-MAG to forward multicast packets by 252 setting F flags in the HI message. 254 (5)A tunnel is established between the p-MAG and n-MAG and multicast 256 packets destined for the MN are forwarded from the p-MAG to the 258 n-MAG over this tunnel. 260 (6)The MN undergoes handover to n-MAG. 262 (7)The n-MAG starts to forward multicast packets destined for the MN. 264 (8)The n-MAG sends the Proxy Binding Update with multicast extension 266 (PBU-M)(proposed in [1]) to the LMA. 268 (9)The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 270 n-MAG. 272 (10)A bi-directional tunnel is set up for forwarding corresponding 274 multicast data. 276 (11)Multicast packet forwarding is completed between p-MAG and n-MAG. 278 5. Message Format 280 This document defines new Mobility Header messages for the extended 281 HI and HAck and new mobility options for delivering context 282 information. 284 0 1 2 3 285 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 286 +---------------+-+-+-----------+ 287 | Code |U|F|M| Reserved| 288 +-------------------------------+---------------+-+-+-----------+ 289 | Reserved | Identifier | 290 +-------------------------------+-------------------------------+ 291 | | 292 . . 293 . Mobility options . 294 . . 295 | | 296 +---------------------------------------------------------------+ 297 Figure 3: HI Mobility Header message with multicast extension 299 A new flag (M) is included in the HI Mobility Header message with 300 multicast extension. The rest of the message format remains the same 301 as defined in [3]. 303 When (M) flag is specified in HI Mobility Header message, the 304 mobility options field needs to be extended to include the multicast 305 addresses. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Record Type | Aux Data Len | Number of Sources (N) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 * * 314 | | 315 * Multicast Address * 316 | | 317 * * 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 * * 322 | | 323 * Source Address [1] * 324 | | 325 * * 326 | | 327 +- -+ 328 | | 329 * * 330 | | 331 * Source Address [2] * 332 | | 333 * * 334 | | 335 +- -+ 336 . . . 337 . . . 338 . . . 339 +- -+ 340 | | 341 * * 342 | | 343 * Source Address [N] * 344 | | 345 * * 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 . . 350 . Auxiliary Data . 351 . . 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 6. Security Considerations 357 TBD. 359 7. IANA Considerations 361 This document does not require any IANA action. 363 8. References 365 8.1. Normative References 367 [1] H. Asaeda, P. Seite, J. Xia, "PMIPv6 Extensions for Multicast", 368 draft-asaeda-multimob-pmip6-extension-01.txt (work in progress), 369 July 2009. 371 [2] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 373 [3] H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia, "Fast 374 Handovers for Proxy Mobile IPv6", 375 draft-irtf-mipshop-pfmipv6-00.txt (work in progress), October 2008. 377 [4] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,"Context 378 Transfer Protocol (CXTP)", RFC 4067, July 2005. 380 [5] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,and B. 381 Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 383 [6] Y K. ZHAO, P. Seite, "The Solution for Pmipv6 Multicast Service", 384 draft-zhao-multimob-pmipv6-solution-02.txt (work in progress), 385 November 2008. 387 [7] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 388 (MLDv2) for IPv6", RFC 3810, June 2004. 390 8.2. Informative References 391 Author's Addresses 393 Min Hui 394 China Mobile 395 53A,Xibianmennei Ave., 396 Xuanwu District, 397 Beijing 100053 398 China 399 Email: huimin.cmcc@gmail.com 401 Hui Deng 402 China Mobile 403 53A,Xibianmennei Ave., 404 Xuanwu District, 405 Beijing 100053 406 China 407 Email: denghui02@gmail.com 409 Dapeng Liu 410 China Mobile 411 53A,Xibianmennei Ave., 412 Xuanwu District, 413 Beijing 100053 414 China 415 EMail: liudapeng@chinamobile.com