idnits 2.17.1 draft-jaehwoon-netlmm-flush-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 328. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (February 18, 2008) is 5911 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM Working Group Jaehwoon Lee 3 Internet Draft Dongguk University 4 Expires: August 17, 2008 Gyungchul Sihn 5 Hyunseo Park 6 ETRI 7 Sanghynn Ahn 8 University of Seoul 9 Younghan Kim 10 Soongsil University 11 February 18, 2008 13 Flushing Mechanism for Routing Optimization in PMIPv6 14 draft-jaehwoon-netlmm-flush-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on August 17, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 In order to solve the inefficient route problem of PMIPv6, a mechanism 48 to optimize the route between two mobile nodes within the same PMIPv6 49 domain has been proposed. However, this route optimization mechanism 50 may result in the out-of-order packet delivery problem. 51 In this draft, we propose a mechanism that can resolve the out-of- 52 order packet delivery problem by introducing the Flush message that 53 notifies the change of the tunnel endpoint and allows the in-order 54 delivery of packets even in the case of the route optimization. 56 Table of Contents 58 1. Introduction..................................................3 59 2. Terminology...................................................4 60 3. Protocol Description..........................................4 61 4. Flush Message Format..........................................7 62 5. Security Considerations.......................................7 63 6. IANA Considerations...........................................7 64 References.......................................................7 65 Author's Addresses...............................................8 66 Intellectual Property and Copyright Statements ..................9 68 1. Introduction 70 The Proxy Mobile IPv6 (PMIPv6) defines the Mobile Access Gateway (MAG) 71 for the support of the mobility of mobile nodes (MNs) by the network, 72 not by MN themselves [1]. The MAG acts as the default gateway of the 73 access link to which an MN is connected. Also, the Localized Mobility 74 Anchor (LMA) is defined as the Home Agent (HA) of an MN within the 75 PMIPv6 domain. The tunnel between the MAG and the LMA is established 76 according to the procedure defined in the PMIPv6. An IP packet from 77 an MN (MN1) is received by the MAG that encapsulates the packet with 78 the outer header and transmits the encapsulated packet to the LMA 79 via tunneling. The LMA removes the outer header of the packet and 80 transmits the decapsulated packet to the CN. An IP packet from the 81 CN is received by the LMA which encapsulates the packet and transmits 82 the encapsulated packet to the MAG via tunneling. Then, the MAG 83 decapsulates the received packet and sends the decapsulated packet to 84 MN1. If the CN is an MN (MN2) within the same PMIPv6 domain of MN1, 85 packets from MN1 are delivered to the LMA via tunneling from 86 the MAG (MAG1) of MN1 and then forwarded to the MAG (MAG2) of MN2 87 via tunneling. Then MAG2 decapsulates the packets and sends them 88 to MN2. This may result in an inefficient route. To resolve this 89 problem, a mechanism to provide an optimal route between two MNs 90 within the same PMIPv6 domain was proposed [2]. In this mechanism, 91 if the LMA which knows that an MN and its CN are within the same 92 PMIPv6 domain sends a Route Optimization Initiate (RO Init) message 93 to MAG1, MAG1 establishes a tunnel between MAG1 and MAG2 by sending 94 an RO Setup message to MAG2. In [2], without the route optimization 95 in action, packets from MN1 travel through MAG1, LMA, MAG2, and, 96 finally, arrive at MN2. Once the route optimization is completed, 97 packets from MN1 are sent to MN2 via MAG1 and MAG2. Hence, packets 98 sent before the route optimization may arrive later than those sent 99 after the route optimization. This out-of-order packet delivery may 100 significantly deteriorate the performance of application programs. 102 In this draft, we propose a mechanism that can resolve the 103 out-of-order packet delivery problem of [2]. In the proposed 104 mechanism, the MAG having received an RO Setup message sends a 105 Flush message to another MAG to notify the change of the tunnel 106 endpoint. The Flush message is the last packet transmitted via the 107 LMA. After transmitting the Flush message, the MAG changes the tunnel 108 endpoint and, then, sends packets through the route established by 109 the route optimization procedure. 111 2. Terminology 113 In this draft, we use the terms defined in [1] and [2], 114 except for the terms defined in the following. 116 Flush: the message that is transmitted to another MAG from a MAG 117 to notify that the MAG is going to update its own binding 118 cache entry for the MN as soon as it sends out the Flush 119 message 121 3. Protocol Description 123 MN1 MAG1 LMA MAG2 MN2 124 | | | | | 125 |---------->|===============>|=================>|---------->| 126 | Data Packet from MN1 to MN2 via LMA | 127 | | | | | 128 | | |---- RO Init ---->| | 129 | | |<-- Ro Init Ack --| | 130 | | | | | 131 | |<---------- RO Setup -------------| | 132 | |--------------->|----------------->| | 133 | Flush message from MAG1 to MAG2 via LMA | 134 | (Update Binding | | | 135 | Cache Entry) | | | 136 | |---------> RO Setup Ack ---------->| | 137 | |<---------------|<-----------------| | 138 | Flush Message from MAG2 to MAG1 via LMA | 139 | | | (Update Binding | 140 | | | Cache Entry) | 141 | | | | | 142 | | |<--- RO Report ---| | 143 | | |- RO Report Ack ->| | 144 |---------->|===================================|---------->| 145 | Data Pacekt from MN1 to MN2 via optimized route | 146 | | | | | 148 Figure 1: Message exchange scenario in case of one LMA in the topology 149 Figure 1 shows the The message exchange scenario considered in the 150 proposed mechanism of this draft when when two MNs are registered 151 with the same LMA. Once an MN (MN1) connects to the PMIPv6 domain, 152 the MAG (MAG1) connected to the same access network of MN1 advertises 153 an MN1's home network prefix (MN1-HNP) to MN1 using the procedure 154 defined in the PMIPv6 protocol. After that, MAG1 establishes a tunnel 155 with the LMA. Then, packets from MN1 are delivered via the tunnel 156 between MAG1 and the LMA. If another MN (MN2) connects to the same 157 PMIPv6 domain, the MAG (MAG2) connected to MN2 advertises an MN2-HNP 158 to MN2, and MAG2 establishes a tunnel with the LMA. After that, 159 packets from MN2 are delivered via the tunnel between MAG2 and the 160 LMA. In the case when MN1 and MN2 communicate, a packet from MN1 is 161 received by MAG1 that encapsulates the packet and forwards it to the 162 LMA via the tunnel between them. The LMA decapsulates the packet and 163 checks its binding cache entries to see if MN1 and MN2 are registered 164 with it. The LMA sends the packet to MAG2 via the tunnel between 165 them. MAG2 removes the outer header of the packet and sends it to 166 MN2. The LMA sends an RO Init message to MAG2 in order to 167 initiate the route optimization procedure, indicating that MN1 and 168 MN2 are within the same PMIPv6 domain. After receiving the RO Init 169 message, MAG2 sends an RO Setup message to MAG1. Before receiving 170 the RO Setup message from MAG2, MAG1 transmits packets from MN1 to 171 the LMA via tunneling. Once the RO Setup message from MAG2 is 172 received, MAG1 sends a Flush message to MAG2 to notify the update 173 of its binding cache entries. The Flush message is the last packet 174 delivered from MAG1 to MAG2 via the LMA. Then, MAG1 changes the 175 tunnel endpoint for MN2 from the LMA to MAG2, and sends an RO Setup 176 Ack message to MAG2. After receiving the RO Setup Ack message from 177 MAG1, MAG2 sends a Flush message to MAG1 to notify the change of the 178 tunnel endpoint for MN1 from the LMA to MAG1. This Flush message 179 becomes the last packet sent from MAG2 to MAG1 via the LMA. After 180 that, MAG2 establishes a tunnel with MAG1. Because there exists 181 some time delay for the RO Setup message to be delivered from MAG2 182 to MAG1 and for the binding cache entries of MAG1 to be updated, 183 during this time duration, packets from MN1 are delivered from MAG1 184 to MN2 via the LMA and MAG2. After the route optimization procedure 185 is completed, packets from MN1 are transmitted to MN2 from MAG1 via 186 MAG2. For the prevention of the out-of-order packet delivery, packets 187 from MAG1 to MAG2 via the LMA have to be delivered to MN2 ahead of 188 those directly delivered from MAG1 to MAG2. In the case when packets 189 via the tunnel between the LMA and MAG2 and those via the tunnel 190 between MAG1 and MAG2 arrive in an intermingled fashion, MAG2 has to 191 deliver to MN2 those packets via the tunnel between the LMA and MAG2 192 prior to those via the tunnel between MAG1 and MAG2, and has to 193 buffer the packets through the optimized route for the later delivery 194 to MN2. Upon receiving the Flush message, MAG2 delivers the packets 195 in the buffer to MN2 with assuming that no more packets from MN1 will 196 arrive via the LMA. With this proposed mechanism, we can avoid the 197 out-of-order packet delivery problem which can occur when the route 198 optimization mechanism is applied. 200 Figure 2 shows the message exchange scenario when two MNs are 201 registered with the different LMAs. Even though two MNs are 202 registered with the different LMAs, time to send Flush message is 203 just the same with one LMA case. 205 MN1 MAG1 LMA1 LMA2 MAG2 MN2 206 | | | | | | 207 |<--->|<==============>|<==============>|<===============>|<---->| 208 | Data Packet transfer between MN1 and MN2 via LMA1 and LMA2 | 209 | | | | | | 210 | | |--- RO Init --->| | | 211 | | |<--Ro Init Ack--| | | 212 | | | |--- RO Init ---->| | 213 | | | |<--Ro Init Ack --| | 214 | |<----------------- RO Setup ----------------------| | 215 | |--------------->|--------------->|---------------->| | 216 | | Flush message from MAG1 to MAG2 via LMA1 and LMA2 | | 217 | (Update Binding | | | | 218 | Cache Entry) | | | | 219 | |------------------ RO Setup Ack ------------------>| | 220 | |<---------------|<---------------|<----------------| | 221 | | Flush Message from MAG2 to MAG1 via LMA2 and LMA1 | | 222 | | | | (Update Binding | 223 | | | | Cache Entry) | 224 | | | | | | 225 | | | |<-- RO Report ---| | 226 | | | |-RO Report Ack-->| | 227 | | |<-RO Report --- | | | 228 | | |-RO Report Ack->| | | 229 |<--->|<=================================================>|<---->| 230 | Data Pacekt transfer between MN1 and MN2 via optimized route | 231 | | | | | | 233 Figure 2: Message exchange scenario with two relevant LMAs 235 4. Flush message format 237 Flush message is an extension to [1] and identified by the MH type. 238 Details on the message format and options are to be defined. 240 5. Security Consideration 242 There is no special security considerations in this draft. 244 6. IANA Considerations 246 This draft document defines a new Flush message. An MH Type value 247 for the Flush message must be assigned by IANA. 249 References 251 [1] S. Gundavelli et al, "Proxy Mobile IPv6", 252 draft-ietf-netlmm-proxymip6-10 (work in progress), Feb 2008. 254 [2] M. Liebsch, L. Le and J. Abeille, "Route Optimization for Proxy 255 Mobile IPv6", draft-abeille-netlmm-proxymip6ro-01 256 (work in progress), Nov. 2007. 258 Author's Addresses 260 Jaehwoon Lee 261 Dongguk University 262 26, 3-ga Pil-dong, Chung-gu 263 Seoul 100-715, KOREA 264 Email: jaehwoon@dongguk.edu 266 Gyungchul Sihn 267 ETRI 268 161, Gajeong-dong, Yuseong-gu 269 Daejeon, 305-350 Korea 270 Email: neuro@etri.re.kr 272 Hyunseo Park 273 ETRI 274 161, Gajeong-dong, Yuseong-gu 275 Daejeon, 305-350 Korea 276 Email: hspark@etri.re.kr 278 Sanghyun Ahn 279 University of Seoul 280 90, Cheonnong-dong, Tongdaemun-gu 281 Seoul 130-743, KOREA 282 Email: ahn@uos.ac.kr 284 Younghan Kim 285 Soongsil University 286 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 287 Dongjak-Gu, Seoul 156-743 Korea 288 E-main: yhkim@dcn.ssu.ac.kr 290 Full Copyright Statement 292 Copyright (C) The IETF Trust (2008). 294 This document is subject to the rights, licenses and restrictions 295 contained in BCP 78, and except as set forth therein, the authors 296 retain all their rights. 298 This document and the information contained herein are provided on an 299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 301 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 302 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 303 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Intellectual Property 308 The IETF takes no position regarding the validity or scope of any 309 Intellectual Property Rights or other rights that might be claimed to 310 pertain to the implementation or use of the technology described in 311 this document or the extent to which any license under such rights 312 might or might not be available; nor does it represent that it has 313 made any independent effort to identify any such rights. Information 314 on the procedures with respect to rights in RFC documents can be 315 found in BCP 78 and BCP 79. 317 Copies of IPR disclosures made to the IETF Secretariat and any 318 assurances of licenses to be made available, or the result of an 319 attempt made to obtain a general license or permission for the use of 320 such proprietary rights by implementers or users of this 321 specification can be obtained from the IETF on-line IPR repository at 322 http://www.ietf.org/ipr. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights that may cover technology that may be required to implement 327 this standard. Please address the information to the IETF at 328 ietf-ipr@ietf.org. 330 Acknowledgment 332 Funding for the RFC Editor function is provided by the IETF 333 Administrative Support Activity (IASA).