NetLMM Working Group Jaehwoon Lee Internet Draft Dongguk University Expires: August 17, 2008 Gyungchul Sihn Hyunseo Park ETRI Sanghynn Ahn University of Seoul Younghan Kim Soongsil University February 18, 2008 Flushing Mechanism for Routing Optimization in PMIPv6 draft-jaehwoon-netlmm-flush-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Jaehwoon Lee, et al. Expires August 17, 2008 [Page 1] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 Abstract In order to solve the inefficient route problem of PMIPv6, a mechanism to optimize the route between two mobile nodes within the same PMIPv6 domain has been proposed. However, this route optimization mechanism may result in the out-of-order packet delivery problem. In this draft, we propose a mechanism that can resolve the out-of- order packet delivery problem by introducing the Flush message that notifies the change of the tunnel endpoint and allows the in-order delivery of packets even in the case of the route optimization. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. Protocol Description..........................................4 4. Flush Message Format..........................................7 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 References.......................................................7 Author's Addresses...............................................8 Intellectual Property and Copyright Statements ..................9 Jaehwoon Lee, et al. Expires August 17, 2008 [Page 2] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 1. Introduction The Proxy Mobile IPv6 (PMIPv6) defines the Mobile Access Gateway (MAG) for the support of the mobility of mobile nodes (MNs) by the network, not by MN themselves [1]. The MAG acts as the default gateway of the access link to which an MN is connected. Also, the Localized Mobility Anchor (LMA) is defined as the Home Agent (HA) of an MN within the PMIPv6 domain. The tunnel between the MAG and the LMA is established according to the procedure defined in the PMIPv6. An IP packet from an MN (MN1) is received by the MAG that encapsulates the packet with the outer header and transmits the encapsulated packet to the LMA via tunneling. The LMA removes the outer header of the packet and transmits the decapsulated packet to the CN. An IP packet from the CN is received by the LMA which encapsulates the packet and transmits the encapsulated packet to the MAG via tunneling. Then, the MAG decapsulates the received packet and sends the decapsulated packet to MN1. If the CN is an MN (MN2) within the same PMIPv6 domain of MN1, packets from MN1 are delivered to the LMA via tunneling from the MAG (MAG1) of MN1 and then forwarded to the MAG (MAG2) of MN2 via tunneling. Then MAG2 decapsulates the packets and sends them to MN2. This may result in an inefficient route. To resolve this problem, a mechanism to provide an optimal route between two MNs within the same PMIPv6 domain was proposed [2]. In this mechanism, if the LMA which knows that an MN and its CN are within the same PMIPv6 domain sends a Route Optimization Initiate (RO Init) message to MAG1, MAG1 establishes a tunnel between MAG1 and MAG2 by sending an RO Setup message to MAG2. In [2], without the route optimization in action, packets from MN1 travel through MAG1, LMA, MAG2, and, finally, arrive at MN2. Once the route optimization is completed, packets from MN1 are sent to MN2 via MAG1 and MAG2. Hence, packets sent before the route optimization may arrive later than those sent after the route optimization. This out-of-order packet delivery may significantly deteriorate the performance of application programs. In this draft, we propose a mechanism that can resolve the out-of-order packet delivery problem of [2]. In the proposed mechanism, the MAG having received an RO Setup message sends a Flush message to another MAG to notify the change of the tunnel endpoint. The Flush message is the last packet transmitted via the LMA. After transmitting the Flush message, the MAG changes the tunnel endpoint and, then, sends packets through the route established by the route optimization procedure. Jaehwoon Lee, et al. Expires August 17, 2008 [Page 3] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 2. Terminology In this draft, we use the terms defined in [1] and [2], except for the terms defined in the following. Flush: the message that is transmitted to another MAG from a MAG to notify that the MAG is going to update its own binding cache entry for the MN as soon as it sends out the Flush message 3. Protocol Description MN1 MAG1 LMA MAG2 MN2 | | | | | |---------->|===============>|=================>|---------->| | Data Packet from MN1 to MN2 via LMA | | | | | | | | |---- RO Init ---->| | | | |<-- Ro Init Ack --| | | | | | | | |<---------- RO Setup -------------| | | |--------------->|----------------->| | | Flush message from MAG1 to MAG2 via LMA | | (Update Binding | | | | Cache Entry) | | | | |---------> RO Setup Ack ---------->| | | |<---------------|<-----------------| | | Flush Message from MAG2 to MAG1 via LMA | | | | (Update Binding | | | | Cache Entry) | | | | | | | | |<--- RO Report ---| | | | |- RO Report Ack ->| | |---------->|===================================|---------->| | Data Pacekt from MN1 to MN2 via optimized route | | | | | | Figure 1: Message exchange scenario in case of one LMA in the topology Jaehwoon Lee, et al. Expires August 17, 2008 [Page 4] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 Figure 1 shows the The message exchange scenario considered in the proposed mechanism of this draft when when two MNs are registered with the same LMA. Once an MN (MN1) connects to the PMIPv6 domain, the MAG (MAG1) connected to the same access network of MN1 advertises an MN1's home network prefix (MN1-HNP) to MN1 using the procedure defined in the PMIPv6 protocol. After that, MAG1 establishes a tunnel with the LMA. Then, packets from MN1 are delivered via the tunnel between MAG1 and the LMA. If another MN (MN2) connects to the same PMIPv6 domain, the MAG (MAG2) connected to MN2 advertises an MN2-HNP to MN2, and MAG2 establishes a tunnel with the LMA. After that, packets from MN2 are delivered via the tunnel between MAG2 and the LMA. In the case when MN1 and MN2 communicate, a packet from MN1 is received by MAG1 that encapsulates the packet and forwards it to the LMA via the tunnel between them. The LMA decapsulates the packet and checks its binding cache entries to see if MN1 and MN2 are registered with it. The LMA sends the packet to MAG2 via the tunnel between them. MAG2 removes the outer header of the packet and sends it to MN2. The LMA sends an RO Init message to MAG2 in order to initiate the route optimization procedure, indicating that MN1 and MN2 are within the same PMIPv6 domain. After receiving the RO Init message, MAG2 sends an RO Setup message to MAG1. Before receiving the RO Setup message from MAG2, MAG1 transmits packets from MN1 to the LMA via tunneling. Once the RO Setup message from MAG2 is received, MAG1 sends a Flush message to MAG2 to notify the update of its binding cache entries. The Flush message is the last packet delivered from MAG1 to MAG2 via the LMA. Then, MAG1 changes the tunnel endpoint for MN2 from the LMA to MAG2, and sends an RO Setup Ack message to MAG2. After receiving the RO Setup Ack message from MAG1, MAG2 sends a Flush message to MAG1 to notify the change of the tunnel endpoint for MN1 from the LMA to MAG1. This Flush message becomes the last packet sent from MAG2 to MAG1 via the LMA. After that, MAG2 establishes a tunnel with MAG1. Because there exists some time delay for the RO Setup message to be delivered from MAG2 to MAG1 and for the binding cache entries of MAG1 to be updated, during this time duration, packets from MN1 are delivered from MAG1 to MN2 via the LMA and MAG2. After the route optimization procedure is completed, packets from MN1 are transmitted to MN2 from MAG1 via MAG2. For the prevention of the out-of-order packet delivery, packets from MAG1 to MAG2 via the LMA have to be delivered to MN2 ahead of those directly delivered from MAG1 to MAG2. In the case when packets via the tunnel between the LMA and MAG2 and those via the tunnel between MAG1 and MAG2 arrive in an intermingled fashion, MAG2 has to deliver to MN2 those packets via the tunnel between the LMA and MAG2 Jaehwoon Lee, et al. Expires August 17, 2008 [Page 5] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 prior to those via the tunnel between MAG1 and MAG2, and has to buffer the packets through the optimized route for the later delivery to MN2. Upon receiving the Flush message, MAG2 delivers the packets in the buffer to MN2 with assuming that no more packets from MN1 will arrive via the LMA. With this proposed mechanism, we can avoid the out-of-order packet delivery problem which can occur when the route optimization mechanism is applied. Figure 2 shows the message exchange scenario when two MNs are registered with the different LMAs. Even though two MNs are registered with the different LMAs, time to send Flush message is just the same with one LMA case. MN1 MAG1 LMA1 LMA2 MAG2 MN2 | | | | | | |<--->|<==============>|<==============>|<===============>|<---->| | Data Packet transfer between MN1 and MN2 via LMA1 and LMA2 | | | | | | | | | |--- RO Init --->| | | | | |<--Ro Init Ack--| | | | | | |--- RO Init ---->| | | | | |<--Ro Init Ack --| | | |<----------------- RO Setup ----------------------| | | |--------------->|--------------->|---------------->| | | | Flush message from MAG1 to MAG2 via LMA1 and LMA2 | | | (Update Binding | | | | | Cache Entry) | | | | | |------------------ RO Setup Ack ------------------>| | | |<---------------|<---------------|<----------------| | | | Flush Message from MAG2 to MAG1 via LMA2 and LMA1 | | | | | | (Update Binding | | | | | Cache Entry) | | | | | | | | | | |<-- RO Report ---| | | | | |-RO Report Ack-->| | | | |<-RO Report --- | | | | | |-RO Report Ack->| | | |<--->|<=================================================>|<---->| | Data Pacekt transfer between MN1 and MN2 via optimized route | | | | | | | Figure 2: Message exchange scenario with two relevant LMAs Jaehwoon Lee, et al. Expires August 17, 2008 [Page 6] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 4. Flush message format Flush message is an extension to [1] and identified by the MH type. Details on the message format and options are to be defined. 5. Security Consideration There is no special security considerations in this draft. 6. IANA Considerations This draft document defines a new Flush message. An MH Type value for the Flush message must be assigned by IANA. References [1] S. Gundavelli et al, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), Feb 2008. [2] M. Liebsch, L. Le and J. Abeille, "Route Optimization for Proxy Mobile IPv6", draft-abeille-netlmm-proxymip6ro-01 (work in progress), Nov. 2007. Jaehwoon Lee, et al. Expires August 17, 2008 [Page 7] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 Author's Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Gyungchul Sihn ETRI 161, Gajeong-dong, Yuseong-gu Daejeon, 305-350 Korea Email: neuro@etri.re.kr Hyunseo Park ETRI 161, Gajeong-dong, Yuseong-gu Daejeon, 305-350 Korea Email: hspark@etri.re.kr Sanghyun Ahn University of Seoul 90, Cheonnong-dong, Tongdaemun-gu Seoul 130-743, KOREA Email: ahn@uos.ac.kr Younghan Kim Soongsil University 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea E-main: yhkim@dcn.ssu.ac.kr Jaehwoon Lee, et al. Expires August 17, 2008 [Page 8] Internet-Draft Flushing Mechanism for RO in PMIPv6 February 18, 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jaehwoon Lee, et al. Expires August 17, 2008 [Page 9]