idnits 2.17.1 draft-kwon-qmipv4-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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 41 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 5357 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 311, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '2') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft SH.Kwon 2 Intended status: Experimental SJ.Koh 3 Expires: February 2010 Kyoung-pook National University 4 August 25, 2009 6 QMIP: Query-based Mobile IP 7 draft-kwon-qmipv4-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on February 25, 2009. 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 Abstract 44 Mobile IP (MIP) suffers from the so-called triangular routing problem. 45 Moreover, MIP Home Agent (HA) tends to undergo severe data traffic 46 load, since it should deliver all the data packets toward mobile 47 nodes. This paper proposes a simple extension of MIP, called Query- 48 based MIP (QMIP), in which the binding query to HA will be used to 49 get the care-of address of a mobile node and to deliver the 50 subsequent data packets over the optimized data path. The proposed 51 QMIP scheme can be applied to MIPv4 and Proxy MIPv6 as well. 53 Table of Contents 55 1. Introduction ................................................ 2 56 2. Conventions used in this document ............................ 3 57 3. Query-Based MIPv4 ........................................... 3 58 3.1. Data Transmission with Binding Query .................... 3 59 3.2. Comparison with MIPv4 ................................... 4 60 3.3. New Message for QMIPv4 .................................. 6 61 3.4. Consider of Query-Based Proxy MIPv6 ..................... 7 62 4. Security Considerations ...................................... 8 63 5. IANA Considerations ......................................... 8 64 6. Conclusions ................................................. 8 65 7. References .................................................. 8 66 7.1. Normative References .................................... 8 67 7.2. Informative References .................................. 8 68 8. Acknowledgments ............................................. 8 70 1. Introduction 72 The Mobile IP (MIP) was designed to support IP mobility [2]. However, 73 it suffers from the well-known 'triangular routing' problem, in which 74 Correspondent Node (CN) should transmit data packets to Mobile Node 75 (MN) via Home Agent (HA) over a non-optimized data path, until the 76 route optimization is additionally performed between CN and MN. 77 Another crucial concern of MIP is the excessive data traffic load at 78 HA, since all the data packets from CNs toward MNs should be 79 delivered by way of HA. Such overhead at HA will become much severe, 80 as the number of MNs increases in the network. 82 This paper proposes a simple extension of MIPv4, called Query-based 83 MIPv4 (QMIPv4), in which the Access Router (AR) attached to CN will 84 perform the binding query to HA, so as to get the Care-of Address 85 (CoA) of MN and to deliver all the subsequent data packets over the 86 optimized data path. For this purpose, we define the two new 87 messages: Binding Query Request and Binding Query Reply. 89 The proposed QMIP scheme can also be applied to the Proxy MIPv6 90 (PMIPv6) [3], rather than MIPv6 [4], since PMIPv6 has the similar 91 structure with MIPv4. We will first present QMIPv4, and then discuss 92 Query-based PMIPv6. 94 2. Conventions used in this document 96 In examples, "C:" and "S:" indicate lines sent by the client and 97 server respectively. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC-2119 [1]. 103 3. Query-Based MIPv4 105 3.1. Data Transmission with Binding Query 107 We consider a simple network model for QMIPv4, as depicted in Fig. 1. 108 In the figure, MN performs the MIPv4 registration (or binding update), 109 and then CN tries to communicate with MN. The AR attached to CN acts 110 as a normal router with its own Query Cache (QC) table. This QC table 111 will be referred to by AR to identify the CoA of MN. Note that this 112 AR may also function as a Foreign Agent (FA) in the network. 114 Now, CN transmits data packets to MN over Home Address (HoA) of MN. 115 On reception of the first data packet destined to MN, the AR will 116 first look for CoA of MN in its QC table. If the corresponding CoA is 117 found in the table (we call it Cache Hit), AR will deliver the data 118 packet directly to MN by using the IP-in-IP tunneling. Otherwise, if 119 the CoA is not found (we call it Cache Miss), the AR will send a 120 Binding Query Request message to HA so as to get the CoA. Then, HA 121 responds with a Binding Query Reply message (containing CoA of MN) to 122 AR. The resulting information of mapping between HoA and CoA of MN 123 will be recorded into the QC table of AR, which will be referred to 124 by AR in the subsequent data transmissions to MN. 126 +--+ 127 |HA| 128 +--+ 129 // \\ 130 Binding Query // \\Binding Update 131 // \\ 132 // \\ 133 +--+ +--+ +--+ +--+ 134 |CN| <=====> |AR| <====> |FA| <=====> |MN| 135 +--+ +--+ +--+ +--+ 136 +-----+ 137 |Query| 138 |Cache| 139 +-----+ 141 AR: Access Router // Control Signal 142 FA: Foreign Agent <=> User Data Transport 143 CN: Correspondent Node 144 MN: Mobile Node 146 Figure 1 Network model for QMIPv4 148 3.2. Comparison with MIPv4 150 Fig. 2 compares the information flows of MIPv4 and QMIPv4. 152 +--+ +--+ +--+ +--+ +--+ 153 |CN| |AR| |HA| |FA| |MN| 154 +--+ +--+ +--+ +--+ +--+ 155 | | | MIP Binding Update | 156 | | | <-------> | <-------> | 157 | |Initial Data Transport | | 158 |=========> |=========> |=========> |=========> | 159 | | | | | 160 |<========= |<===================== |<========= | 161 | | | | | 162 | | . | . | | 163 | | . | . | | 164 | | | | | 165 | |MIP Route Optimization | | 166 | |<--------------------> | | 167 | | | | | 168 | | Data Transport after | | 169 | | Route Optimization | | 170 |<========> |<====================> |<========> | 171 | | | | | 172 (a)MIPv4 174 +--+ +--+ +--+ +--+ +--+ 175 |CN| |AR| |HA| |FA| |MN| 176 +--+ +--+ +--+ +--+ +--+ 177 | | | MIP Binding Update | 178 | | | <-------> | <-------> | 179 |Cache Miss |QMIP Bind- | | | 180 | \|ing Query | | | 181 |=========> |<--------> | | | 182 | | Data Transport | | 183 | |=====================> |=========> | 184 | Cache Hit | | | | 185 | \| | | | 186 |<========> |<====================> |<========> | 187 | | | | | 188 (b)QMIPv4 190 Figure 2 Information flows of MIPv4 and QMIPv4 192 In MIPv4, MN will perform the registration with HA. All the data 193 packets transmitted by CN will be forwarded to HA and delivered by HA 194 to MN using the IP-in-IP tunneling, whereas MN will transmit its data 195 packets directly to CN, and hence the triangular routing occurs. Just 196 after the route optimization, CN can use the optimized path for data 197 delivery to MN. 199 The QMIPv4 is the same with MIPv4, other than the binding query 200 operation with HA. When the first data packet arrives from CN, AR 201 will search for the corresponding CoA of MN in its QC table. In case 202 of Cache Hit that the CoA is found in the table, AR can transmit the 203 data packet directly to MN over the optimized path. However, in case 204 of Cache Miss, AR should perform the binding query to HA. After this, 205 all the subsequent data packets will be delivered to MN over the 206 optimized route, without further binding query operations. 208 Note that in MIPv4 the data transport between MN and CN will be done 209 over the optimized route, just after the route optimization is 210 completed, whereas the proposed QMIPv4 can intrinsically realize the 211 route optimization with a single binding query operation. Moreover, 212 in QMIPv4, Cache Hit may occur even for the first data packet of CN 213 (i.e., the binding query operation can be omitted), if another CN in 214 the same AR region is already communicating with the identical MN at 215 that time. 217 With the data transport over the optimized path, QMIPv4 can reduce 218 the transmission delays of data packets, compared to MIPv4. In 219 addition, QMIPv4 can avoid the problem of the excessive data traffic 220 load at HA, since the data transmission to MN will be performed by 221 the concerned AR, instead of HA, in the distributed manner. 223 3.3. New Message for QMIPv4 225 To support the QMIPv4, the two messages need to be newly defined: 226 Binding Query Request (from AR to HA) and Binding Query Reply (from 227 HA to AR). These messages can be defined in the similar format with 228 the MIP registration request/reply messages, as shown in Fig. 3. 230 +----------+----------+-------------------+ 231 | Type | Code | Lifetime | 232 +-----------------------------------------+ 233 | Home Address | 234 +-----------------------------------------+ 235 | Home Agent | 236 +-----------------------------------------+ 237 | | 238 | Identification | 239 | | 240 +-----------------------------------------+ 241 | Extensions | 242 +-----------------------------------------+ 243 (a)Binding Query Request 245 +----------+----------+-------------------+ 246 | Type | Code | Lifetime | 247 +-----------------------------------------+ 248 | Home Address | 249 +-----------------------------------------+ 250 | Home Agent | 251 +-----------------------------------------+ 252 | Care-of Address | 253 +-----------------------------------------+ 254 | | 255 | Identification | 256 | | 257 +-----------------------------------------+ 258 | Extensions | 259 +-----------------------------------------+ 260 (b)Binding Query Reply 262 Figure 3 Add a caption as here. 264 As shown in the figure, the Binding Query Request message contains 265 the information on HA and HoA of MN, whereas the Binding Query Reply 266 message additionally includes CoA of MN. The specific types of 267 messages are for further study. 269 3.4. Consider of Query-Based Proxy MIPv6 271 The Query-based MIP scheme can also be applied to the Proxy MIPv6. In 272 this case, the PMIPv6 Mobile Access Gateway will function as the 273 QMIPv4 AR and/or FA, and the PMIPv6 Localized Mobility Agent acts as 274 the QMIPv4 HA. In addition, the PMIPv6 Proxy Binding Update messages 275 may need to be extended to support the binding query operation. 276 Details of the Query-based PMIPv6 are for further study. 278 4. Security Considerations 280 To be continue. 282 5. IANA Considerations 284 This specification has no actions for IANA. 286 6. Conclusions 288 This paper presents the Query-based MIP scheme that uses the binding 289 query to HA so as to get the optimized data path. The proposed QMIP 290 scheme can be applied to both MIPv4 and PMIPv6. In QMIP, we can 291 achieve much smaller transmission delay of data packets than MIP in 292 the usual case. Moreover, the QMIP is helpful to avoid the excessive 293 data traffic load at HA, since the data transmission to MN will be 294 performed by AR in the network, instead of HA. 296 7. References 298 7.1. Normative References 300 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 301 Levels", BCP 14, RFC 2119, March 1997. 303 7.2. Informative References 305 [2] IETF RFC 3344, IP Mobility Support for IPv4, August 2002 307 [3] IETF RFC 5213, Proxy Mobile IPv6, August 2008 309 [4] IETF RFC 3775, Mobility Support in IPv6, June 2004 311 [5] IETF RFC 4988, Mobile IPv4 Fast Handovers, October 2007. 313 8. Acknowledgments 315 Thanks goes to Hee Young Jung who have made insightful comments with 316 respect to interworking and careful review. 318 This document was prepared using 2-Word-v2.0.template.dot. 320 Authors' Addresses 322 Soon Hong Kwon 323 Kyoung-pook National University 324 Email: K.soonhong@gmail.com 326 Seok Joo Koh 327 Kyoung-pook National University 328 Email: sjkoh@knu.ac.kr