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]