idnits 2.17.1 draft-han-netlmm-fast-pmipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 03, 2008) is 5776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.xia-netlmm-fmip-mnagno' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) == Outdated reference: A later version (-03) exists of draft-yokota-mipshop-pfmipv6-02 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG Y. Han 3 Internet-Draft KUT 4 Intended status: Informational B. Park 5 Expires: February 4, 2009 KT 6 July 03, 2008 8 A Fast Handover Scheme in Proxy Mobile IPv6 9 draft-han-netlmm-fast-pmipv6-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 1, 2009. 36 Abstract 38 This memo proposes a scheme that supports a fast handover effectively 39 in Proxy Mobile IPv6 by optimizing the associated data and signaling 40 flows during the handover. New signaling messages, Fast PBU and 41 Reverse PBU, are defined and utilized to expedite the handover 42 procedure. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Handoff Type Considerations . . . . . . . . . . . . . . . . . . 6 50 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 52 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 54 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Intellectual Property and Copyright Statements . . . . . . . . . . 9 58 1. Introduction 60 The PMIPv6 (Proxy Mobile IPv6) protocol provides local mobility 61 management to a mobile node without requiring any modification of the 62 mobile node. But, PMIPv6's handover could cause undesirable delay to 63 the mobile nodes running real time applications like VoIP. This memo 64 proposes a scheme that supports a fast handover effectively in PMIPv6 65 by optimizing the associated data and signaling flows during the 66 handover. 68 FMIPv6 (Fast Handover for Mobile IPv6) [RFC5268] is a well-known fast 69 handover scheme for the host-based Mobile IPv6. It may be harnessed 70 to enhance PMIPv6's handover performance. Actually, some schemes 71 have been proposed based on the FMIPv6's strategy (see [I-D.xia- 72 netlmm-fmip-mnagno] and [I-D.yokota-mipshop-pfmipv6]). However, they 73 induce unnecessary processing overhead for re-tunneling at the MAGs, 74 as well as inefficient usage of network bandwidth if there are no 75 direct secure links between them. The main reason for this is that 76 the data transport of PMIPv6 is based on the tunneling from the LMA 77 to the MAG, not between MAGs, while the FMIPv6 and the existing 78 schemes use the tunneling between the previous AR (PAR) and new AR 79 (NAR) for fast handover. 81 We propose a new PMIPv6's fast handover scheme to overcome such 82 ineffectiveness by defining the signaling messages between LAM and 83 MAG. The proposed scheme utilizes only pre-established bi- 84 directional tunnels between LMA and MAGs, and does not create and 85 utilize a bi-directional tunnel between MAGs. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 The terminology in this document is based on the definitions in 94 [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in 95 this section: 97 o Previous Mobile Access Gateway (PMAG): The MAG that manages 98 mobility related signaling for the MN before handover. 100 o New Mobile Access Gateway (NMAG): The MAG that manages mobility 101 related signaling for the MN after handover. 103 o Previous Point of Attachment (P-PoA): The access network device to 104 which the MN is attached before handover. 106 o New Point of Attachment (N-PoA): The access network device to 107 which the MN is attached after handover. 109 o Fast Proxy Binding Update (Fast PBU): A request message sent by an 110 MAG to a mobile node's LMA for expediting the handover procedure. 112 o Fast Proxy Binding Acknowledgement (Fast PBA): A reply message 113 sent by an LMA in response to a Fast PBU message that it received 114 from a MAG. 116 o Reverse Proxy Binding Update (Reverse PBU): A request message sent 117 by LMA to a mobile node's new MAG after establishing a binding 118 between the home network prefix assigned to the mobile node and 119 its new care-of address (Proxy-CoA). 121 o Reverse Proxy Binding Acknowledgement (Reverse PBA): A reply 122 message sent by a MAG in response to a Reverse PBU message that it 123 received from an LMA. 125 3. Protocol Operation 127 Because a mobile node is not directly involved with IPv6 mobility 128 management, it is also unaware of fast handover procedure defined in 129 this memo. All new signaling messages defined in this memo are 130 exchanged by the MAG and the LMA. The proposed scheme is not based 131 on the fast handover strategy defined in [RFC5268]. 133 To reduce the handover latency due to signaling between the MAGs and 134 the LMA, this memo only utilizes the bi-directional tunnels between 135 the LMA and the PMAG/NMAG. That is, no tunnel creation between MAGs 136 is required. The bi-directional tunnel between the LMA and the PMAG 137 has been always established to provide a visited mobile node with the 138 packet delivery service. The bi-directional tunnel between the LMA 139 and the NMAG may be also already established because the tunnels are 140 shared for multiple mobile nodes in PMIPv6. 142 MN P-PoA N-PoA PMAG NMAG LMA 143 | | | | | | 144 |Link-specific | | | | 145 (a) |Pre-handover | | | | 146 |procedure | | | | | 147 |<--------->| HO Initiate | | | 148 (b) | |-(MN ID, New AP ID)->| | | 149 | | | | Fast PBU | 150 (c) | | | |----(MN ID, New PCoA)--->| 151 | | | | | | 152 | | | | Fast PBA | 153 (d) | | | |<------------------------| 154 | | | | | | 155 | | | | | Reverse PBU | 156 (e) | | | | |<--(MN ID,---| 157 | | | | | HNP) | 158 | | | | | | 159 (f) | | | | | Reverse PBA | 160 | | | | |------------>| 161 (g) | | | | |<==DL data===| 162 ~~~ | | | |\ | 163 (h) | | | | |buffering | 164 ~~~ | | | | | | 165 | MN:N-PoA connection | N-PoA:MAG connection| | | 166 (h) |<---establishment---->|<---establishment---->| | | 167 | | | | |/ | 168 (i) |<=================DL data====================| | 169 | | | | | | 170 (j) |==================UL data===================>| | 171 | | | | |===UL data==>| 172 | | | | | | 174 The proposed handover procedure. 176 Figure 1 178 The procedure is as follows (see Figure 1): 180 (a) A handover is imminent and a link-specific pre-handover 181 procedure is performed. The pre-handover procedure can be 182 host-initiated or network-initiated. The exact procedure is 183 out of scope. 185 (b) P-PoA, to which the MN is currently attached, indicates the 186 handover of the mobile node to the PMAG. The exact procedure 187 of this indication is also out of scope. 189 (c) The PMAG sends the Fast PBU to the LMA. The Fast PBU message 190 MUST include the MN ID and the new PCoA, the address of NMAG, 191 which is resolved by the New AP ID. 193 (d) The LMA sends back the Fast PBA to the PMAG. 195 (e) The LMA establishes a binding between the home network prefix 196 (HNP) assigned to the mobile node and its new PCoA. The LMA 197 sends the Reverse PBU to the NMAG. The Reverse PBU message 198 MUST include the MN ID and the HNP of the mobile node. 200 (f) The NMAG sends back the Reverse PBA to the LMA. 202 (g) If the bi-directional tunnel is not established between the 203 NMAG and the LMA, a new tunnel is established. The LMA 204 starts to transfer packets destined for the mobile node via 205 the NMAG. If the mobile node has not established a 206 connection with NMAG at this time, the NMAG starts to buffer 207 the packets. 209 (h) The mobile node hands over to the New Access Network. 211 (i) The mobile node establishes a connection (e.g. radio channel) 212 with the N-PoA, which in turn triggers the establishment of 213 the connection between the N-PoA and NMAG. The exact 214 procedure of this procedure is also out of scope. 216 (j) The NMAG starts to transfer packets destined for the mobile 217 node via the N-PoA. 219 (k) The uplink packets from the mobile node are sent to the NMAG 220 via the N-PoA and the NMAG forwards them to the LMA. 222 It is noted that the Reverse PBU and PBA are the alternates of the 223 original PBU and PBU of PMIPv6. That is, the proposed scheme 224 incorporates the main part of PMIPv6 procedure in the fast handover 225 procedure, and thus any subsequent PMIPv6 procedure is not necessary. 227 4. Handoff Type Considerations 229 TBD 231 5. Message Format 233 TBD 235 6. Security Considerations 237 TBD 239 7. References 241 7.1. Normative References 243 [I-D.ietf-netlmm-proxymip6] 244 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 245 and B. Patil, "Proxy Mobile IPv6", 246 draft-ietf-netlmm-proxymip6-18 (work in progress), 247 May 2008. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, 253 June 2008. 255 7.2. Informative References 257 [I-D.xia-netlmm-fmip-mnagno] 258 Xia, F. and B. Sarikaya, "Mobile Node Agnostic Fast 259 Handovers for Proxy Mobile IPv6", 260 draft-xia-netlmm-fmip-mnagno-02 (work in progress), 261 November 2007. 263 [I-D.yokota-mipshop-pfmipv6] 264 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 265 Xia, "Fast Handovers for PMIPv6", 266 draft-yokota-mipshop-pfmipv6-02 (work in progress), 267 February 2008. 269 Authors' Addresses 271 Youn-Hee Han 272 KUT 273 Gajeon-Ri, 307, Byeongcheon-Myeon 274 Cheonan, Chungnam 275 Korea 277 Phone: +82 41 560 1486 278 Email: yhhan@kut.ac.kr 279 Byungjoo Park 280 KT 281 Jeonmin-Dong, Yusung-Go 282 Deajoen, Chungnam 283 Korea 285 Email: bjpark@kt.co.kr 287 Full Copyright Statement 289 Copyright (C) The IETF Trust (2008). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 299 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 300 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org.