Internet DRAFT - draft-han-mipshop-reverse-binding
draft-han-mipshop-reverse-binding
MIPSHOP WG Y. Han
Internet-Draft KUT
Intended status: Informational P. Kim
Expires: January 9, 2010 KPU
B. Ahn
Network Research Division, ETRI
July 8, 2009
Reverse Binding for Proxy Mobile IPv6
draft-han-mipshop-reverse-binding-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Han, et al. Expires January 9, 2010 [Page 1]
Internet-Draft Reverse Binding for PMIPv6 July 2009
Abstract
This memo proposes a scheme that utilizes only pre-established bi-
directional tunnels between LMA and MAGs to support a fast handover
effectively in Proxy Mobile IPv6. To expedite the handover
procedure, we define new signaling messages, Fast PBU/PBA and Reverse
PBU/PBA, exchanged by LMA and MAGs. Because any signaling messages
exchanged by two MAGs are neither created nor utilized and thus bi-
directional tunnel between MAGs is not created, the proposed scheme
puts less overload upon network than the existing fast handover
scheme for PMIPv6. It can also tackle effectively with the so-called
ping-pong movement of mobile nodes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Binding Cache Entry Management . . . . . . . . . . . . . . . . 7
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Fast Proxy Binding Update . . . . . . . . . . . . . . . . . 8
5.2. Fast Proxy Binding Acknowledgment . . . . . . . . . . . . . 8
5.3. Reverse Proxy Binding Update . . . . . . . . . . . . . . . 8
5.4. Reverse Proxy Binding Acknowledgment . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Han, et al. Expires January 9, 2010 [Page 2]
Internet-Draft Reverse Binding for PMIPv6 July 2009
1. Introduction
The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local
mobility management to a mobile node without requiring any
modification of the mobile node. But, PMIPv6's handover could cause
undesirable delay to the mobile nodes running real time applications
like VoIP. This memo proposes a scheme that supports a fast handover
effectively in PMIPv6 by optimizing the associated data and signaling
flows during the handover.
FMIPv6 (Fast Handover for Mobile IPv6) [RFC5268] is a well-known fast
handover scheme for the host-based Mobile IPv6 [RFC3775], and its
strategy has been also harnessed to enhance PMIPv6's handover
performance. Actually, a scheme has been proposed based on the
FMIPv6's strategy (see [I-D.draft-ietf-mipshop-pfmipv6]). Although
the data transport of PMIPv6 utilizes the tunnelings from the LMA to
the MAGs, not between MAGs, the FMIPv6 and the existing scheme
[I-D.draft-ietf-mipshop-pfmipv6] still use the bi-directional tunnel
between the previous MAG and new MAG to forward the data in transit
during handover. However, it includes unnecessary processing
overhead to establish bi-directional tunnels between the MAGs. Such
a tunnel setup can also cause inefficient usage of network bandwidth
if there are no direct secure links between them.
In addition to that, the FMIPv6 and the existing scheme
[I-D.draft-ietf-mipshop-pfmipv6] compell a mobile node's uplink
traffic to be tunnelled to the previous MAG, and then again to the
LMA in the cource of handover. This zigzag path of data traffic can
produce poor throughput. Besides, as
[I-D.draft-ietf-mipshop-transient-bce-pmipv6] mentioned, currently
and as per PMIPv6 base protocol [RFC5268], the LMA forwards a mobile
node's uplink traffic received from a tunnel only as long as the
source IP address of the node's uplink traffic matches the IP address
of the node's registered Proxy-CoA in the associated binding cache
entry. As a result, packets received at the LMA from the node's
previous MAG after the LMA has already switched the tunnel to point
to the new MAG will be dropped.
We propose a new PMIPv6's fast handover scheme to overcome such
ineffectiveness by defining new signaling messages, Fast PBU/PBA and
Reverse PBU/PBA, exchanged between LAM and MAGs. The proposed scheme
utilizes only pre-established bi-directional tunnels between LMA and
MAGs. Because any signaling messages exchanged by two MAGs are
neither created nor utilized and thus bi-directional tunnel between
MAGs is not created, the proposed scheme puts less overload upon
network than the existing fast handover scheme for PMIPv6. It can
also tackle effectively with the so-called ping-pong movement of
mobile nodes.
Han, et al. Expires January 9, 2010 [Page 3]
Internet-Draft Reverse Binding for PMIPv6 July 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The terminology in this document is based on the definitions in
[RFC5213], in addition to the ones specified in this section:
o Previous Mobile Access Gateway (PMAG): The MAG that manages
mobility related signaling for the MN before handover.
o New Mobile Access Gateway (NMAG): The MAG that manages mobility
related signaling for the MN after handover.
o Previous Point of Attachment (P-PoA): The access network device to
which the MN is attached before handover.
o New Point of Attachment (N-PoA): The access network device to
which the MN is attached after handover.
o Fast Proxy Binding Update (Fast PBU): A request message sent by an
MAG to a mobile node's LMA for expediting the handover procedure.
o Fast Proxy Binding Acknowledgment (Fast PBA): A reply message sent
by the LMA in response to a Fast PBU message that it received from
a MAG.
o Reverse Proxy Binding Update (Reverse PBU): A request message sent
by the LMA to a mobile node's new MAG after establishing a binding
between the home network prefix assigned to the mobile node and
its new care-of address (Proxy-CoA).
o Reverse Proxy Binding Acknowledgment (Reverse PBA): A reply
message sent by an MAG in response to a Reverse PBU message that
it received from the LMA.
3. Protocol Operation
Because a mobile node is not directly involved with IPv6 mobility
management, it is also unaware of fast handover procedure defined in
this memo. All new signaling messages defined in this memo are
exchanged by MAGs and the LMA.
To reduce the handover latency due to signaling between the MAGs and
the LMA, this memo only utilizes the bi-directional tunnels between
the LMA and the PMAG/NMAG. That is, no tunnel creation between MAGs
Han, et al. Expires January 9, 2010 [Page 4]
Internet-Draft Reverse Binding for PMIPv6 July 2009
is required. The bi-directional tunnel between the LMA and the PMAG
has been already established to provide a visited mobile node with
the packet delivery service. The bi-directional tunnel between the
LMA and the NMAG may be also already established because the tunnels
are shared for multiple mobile nodes in PMIPv6. If there is no
tunnel between the LMA and the NMAG, a new one should be created
during the proposed procedure. It is also recommended that the bi-
directional tunnels between the LMA and all MAGs should be statically
pre-established to make the proposed scheme operate efficiently.
Figure 1 shows the procedure of the proposed scheme.
MN P-PoA N-PoA PMAG NMAG LMA
| | | | | |
|Link-specific | | | |
(a) |Pre-handover | | | |
|procedure | | | | |
|<--------->| HO Initiate | | |
(b) | |-(MN ID, New AP ID)->| | |
| | | | Fast PBU |
(c) | | | |----(MN ID, New PCoA)--->|
| | | | | |
| | | | Fast PBA |
(d) | | | |<------------------------|
| | | | | |
| | | | | Reverse PBU |
(e) | | | | |<--(MN ID,---|
| | | | | HNP) |
| | | | | |
(f) | | | | | Reverse PBA |
| | | | |------------>|
(g) | | | | |<==DL data===|
~~~ | | | |\ |
(h) | | | | | |
~~~ | | | | |buffering |
| MN:N-PoA connection | N-PoA:MAG connection | | |
(i) |<---establishment---->|<---establishment---->|/ PBU |
(j) | | | | |------------>|
(k) |<=================DL data====================| |
| | | | | |
(l) |==================UL data===================>| |
| | | | |===UL data==>|
| | | | | |
The proposed handover procedure.
Figure 1
Han, et al. Expires January 9, 2010 [Page 5]
Internet-Draft Reverse Binding for PMIPv6 July 2009
The procedure is as follows (see Figure 1):
(a) A handover is imminent and a link-specific pre-handover
procedure is performed. The pre-handover procedure can be
host-initiated or network-initiated. The exact procedure is
out of scope.
(b) P-PoA, to which the MN is currently attached, indicates the
handover of the mobile node to the PMAG. The exact procedure
of this indication is also out of scope.
(c) The PMAG sends the Fast PBU to the LMA. The Fast PBU message
MUST include the MN ID and the new PCoA, the address of NMAG,
which is resolved by the New AP ID.
(d) The LMA sends back the Fast PBA to the PMAG.
(e) The LMA establishes a binding between the home network prefix
(HNP) assigned to the mobile node and its new PCoA. The LMA
sends the Reverse PBU to the NMAG. The Reverse PBU message
MUST include the MN ID and the HNP of the mobile node.
(f) The NMAG sends back the Reverse PBA to the LMA.
(g) If the bi-directional tunnel is not established between the
NMAG and the LMA, a new tunnel is established. The LMA
starts to transfer packets destined for the mobile node via
the NMAG. If the mobile node has not established a
connection with NMAG at this time, the NMAG starts to buffer
the packets.
(h) The mobile node hands over to the New Access Network.
(i) The mobile node establishes a connection (e.g. radio channel)
with the N-PoA, which in turn triggers the establishment of
connection between the N-PoA and NMAG. The exact procedure
of this procedure is also out of scope. When the NMAG does
know that the MN makes the establishment of connection, it
flushes out the buffered data.
(j) The NMAG sends the PBU message to the LMA. This PBU message
is sent by the procedure defined in PMIPv6. However, since
the PBU message is used by the LMA to check if the MN
actually connects to the NMAG, the LMA does not have to send
a response to the PBU message.
Han, et al. Expires January 9, 2010 [Page 6]
Internet-Draft Reverse Binding for PMIPv6 July 2009
(k) The NMAG starts to transfer packets destined for the mobile
node via the N-PoA.
(l) The uplink packets from the mobile node are sent to the NMAG
via the N-PoA and the NMAG forwards them to the LMA.
As the name implies, the reverse PBU message is sent by the LMA and
the recipient of it is the NMAG. Just before the LMA sends the
reverse PBU message, it creates a new binding update list entry.
Upon receiving it, the NMAG creates a new binding cache entry and
establishes a new bi-directional tunnel if it does not exist. After
doing them, the NMAG replies to the LMA by sending the reverse PBA
message.
It is also noted that the Reverse PBU and PBA are the alternates of
the original PBU and PBU of PMIPv6. That is, the proposed scheme
incorporates the main part of PMIPv6 procedure in the fast handover
procedure, and thus any subsequent PMIPv6 procedure may be not
necessary. However, the NMAG sends the PBU message to the LMA in
order for the LMA to check if the MN actually connects to the NMAG.
However, any response to the PBU message is not required.
4. Binding Cache Entry Management
The use of Fast PBU/PBA and Reverse PBU/PBA during an MN's handover
enables a great control on the fast update of the MN's binding cache
entry at LMA and the fast forwarding to the NMAG for the traffic
destined for the MN. When the LMA sends the Reverse PBU to an MN's
NMAG and receives the Reverse PBA from the NMAG, it creates a
transient binding cache entry for the MN. A transient binding cache
entry is identical to a normal PMIPv6 binding cache entry except that
it could be deleted if the LMA does not receive a normal PMIPv6 PBU
from the NMAG within a predefined time. That is, a transient binding
cache entry has a lifetime associated and its deletion does not need
any signaling.
The LMA should maintain the status of an MN's binding and the
lifetime associated with a transient binding cache entry in their
binding cache. TIMEOUT is set according to the Lifetime value in a
Reverse PBU. If the LMA receives a normal PMIPv6 PBU from the NMAG
within the lifetime, the transient binding cache entry changes to the
normal binding cache entry.
5. Message Format
Han, et al. Expires January 9, 2010 [Page 7]
Internet-Draft Reverse Binding for PMIPv6 July 2009
5.1. Fast Proxy Binding Update
TBD
5.2. Fast Proxy Binding Acknowledgment
TBD
5.3. Reverse Proxy Binding Update
TBD
5.4. Reverse Proxy Binding Acknowledgment
TBD
6. Security Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008.
7.2. Informative References
[I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-05 (work in progress),
June 2009.
[I-D.ietf-mipshop-transient-bce-pmipv6]
Liebsch, M., Muhanna, A., and O. Blume, "Transient Binding
Han, et al. Expires January 9, 2010 [Page 8]
Internet-Draft Reverse Binding for PMIPv6 July 2009
for Proxy Mobile IPv6",
draft-ietf-mipshop-transient-bce-pmipv6-03 (work in
progress), June 2009.
Authors' Addresses
Youn-Hee Han
KUT
Gajeon-Ri, 307, Byeongcheon-Myeon
Cheonan, Chungnam
Korea
Phone: +82 41 560 1486
Email: yhhan@kut.ac.kr
Pyung-Soo Kim
KPU
2121 Jungwang-Dong
Shiheung, Gyeonggi
Korea
Phone: +82 31 8041 0489
Email: pskim@kpu.ac.kr
Byung-Jun Ahn
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Go
Deajoen, Chungnam
Korea
Email: bjahn@etri.re.kr
Han, et al. Expires January 9, 2010 [Page 9]
