Internet DRAFT - draft-yu-netext-pmipv6-handover
draft-yu-netext-pmipv6-handover
Network Wroking Group Hewei. Yu
Internet-Draft Ziliang. Li
Intended status: Informational South China University of Technology
Expires: October 18, 2015 April 17,2015
Fast Handover based on Registration in advance for Proxy Mobile IPv6
draft-yu-netext-pmipv6-handover-00
Abstract
This memo proposes an alternative handover scheme in Proxy Mobile
IPv6(PMIPv6) by making NMAG early registering to LMA before MN
attaches to NMAG. Therefore, when MN handover to NMAG, it can sends
the Router Advertisement message to MN immediately, because the
network-layer handoff has completed already.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 21, 2015.
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
The Proxy Mobile IPv6(PMIPv6) [RFC5213] protocol is a network-based
local mobility management which enable IP mobility for a host
without requiring its participation. It defines two new mobility
entities LMAG and MAG. The LMA is responsible for maintain the MN's
reachability state and is the topological anchor point for MN's
home network prefix (MN-HNP). The MAG acts as an access router
which performs the mobility management on behalf of MN. However,
the handover in PMIPv6 still has a undesirable delay to the mobile
nodes running real time applications.
Fast handover mechanism for PMIPv6 has been proposed in [RFC5949].
Before MN detached from the PMAG, it reports the information of
NMAG which is most likely to move to PMAG. It specifies a
bidirectional tunnel between the Previous MAG (PMAG) and the New
MAG (NMAG) to tunnel packets meant for the mobile node. After
decapsulation, those packets should be buffered at NMAG. As soon as
MN attaches to NMAG, the NMAG starts to forward packets destined
for MN and the uplink packets would be forward to PMAG by NMAG. The
PMAG then transfers the packets to the LMA which is serving MN.
This process can reduce packet loss, but it doesn't bring
significant reduction of handover delay. This is because it starts
the proxy registration procedure after MN's attachment which just
like the handover in [RFC5213].
This memo proposes an fast handover scheme based on NMAG
registration in advance for PMIPv6. Before MN detaches from PMAG,
NMAG registers to LMA on behalf of MN. So when MN handover to NMAG,
the NMAG could send Router Advertisement(RA) message to MN with MN-
HNP immediately. This can minimize handover delay.
2. Terminology
The terminology in this document is based on the definitions of
PMIPv6[RFC5213], in addition to the ones specified as follows:
Mobile Node (MN): The mobile node is an IP host or router and its
mobility is managed by the entities in the network.
Local Mobility Anchor (LMA): Local Mobility Anchor is the
topological anchor point for the MN's home network prefix and is
responsible to manage the MN's binding state.
Mobile Access Gateway (MAG): The function entity that manages the
mobility-related message for MN and initiates binding registrations
to the LMA which is currently serving MN.
Previous Mobile Access Gateway (PMAG): The MAG that manages mobility
-related signaling for mobile node before handover.
New Mobile Access Gateway (NMAG): The MAG that manages mobility-
related signaling after handover.
Mobile Node's Home Network Prefix (MN-HNP): The network prefix
assigned to MN by LMA. Every prefix should only be assigned to one
host.
3. FPMIPv6 based on Registration in Advance Protocol Overview
3.1 Protocol Overview
This memo describes fast handover scheme based on registration in
advance for Proxy Mobile IPv6 (PMIPv6) [RFC5213]. To further reduce
the handover latency, NMAG registers to LMA while MN is still on
the subnet of PMAG. A bi-directional tunnel between PMAG and NMAG
would be built to forward packet to NMAG by PMAG. The NMAG
decapsulates and buffers them prior MN's attachment. It alleviates
the packet loss.
In the proposed handover scheme, the MN has made two prediction of
handover. One is MN undergoes a handover but not handoff
immediately, the other is MN has decided to handoff and start link
layer handoff. It is assumed that the interval of these two
prediction is long enough for NMAG proceeds the registration
procedure ahead of time.
In PMIPv6 domain, the MN is not involved with IP mobility
management. In order to do the prediction of handover, it is
required that the MN has the capability to report link-layer
information to MAGs at a short interval. And that message should
help PMAG resolving the NMAG to which the MN is most likely moving.
The detail of this message are outside the scope of this memo.
In order to reduce the packet loss in handover, the downlink
packets meant for MN should be buffered at NAMG, as it shows at
step (i) of Figure 1. Therefore, it is required that all MAGs are
capable of buffering packets for the MN. The buffer zone size and
the rate of forwarding buffered packets are outside the scope of
this memo.
3.2 Protocol Operation
In [RFC5213] or [RFC5949], NMAG's registration proceeds after it
detects MN's attachment during handover. This memo presented an
fast handover scheme based on registration in advance.
When MN undergoes handover but still connected to PMAG, NMAG
registers to LMA and sets up the bidirectional tunnel between PMAG
and NMAG. Packets destined for MN would be transfered to NMAG by
LMA, then NMAG transfers them to PMAG over this tunnel. After MN
attaches to NMAG, NMAG sends the Router Advertisement (RA) message
which contains MN-HNP to MN quickly, cause the registration process
has been completed in advance.
The whole signaling call flow of proposed scheme is illustrated in
Figure 1.
MN PMAG LMA NMAG
| | | |
(a) |--Report-->| | |
| | | |
(b) | |---------------HI--------------->|
| | | |
(c) | | |<---------PBU--------|
| | | |
(d) | | |----------PBA------->|
| | | |
| | |<===Bir-Dir Tunnel==>|
| | | |
| | |=======DL data======>|=#
|<==========|<================================|
|==UL data=>|==========>| |
(e) | |<-------------HAck---------------|
| | | |
(f) | |<========Bir-Dir Tunnel=========>|
| | | |
(g) |==UL data=>|================================>|=#
| | |<====================|
| | | |
(h) |---L2 HO-->| | |
| | | |
(i) | |---------------HI--------------->| \
~~~ | | | |
~~~ | | | |
(j) |----------------Rtr Sol--------------------->| |
| | | | | buffering
(k) |<---------------Rtr Adv----------------------| |
| | | | |
(l) IP Address | | | |
Configuration | | | /
| | | |
(m) |<===========deliver packets==================|
| | | |
UL Uplink
DL Downlink
Figure 1: Signaling call flow of proposed scheme
The detailed description are as follows:
(a) MN detects that a handover is imminent and reports to PMAG its
identifier(MN-ID) and the New Access Point Identifier[RFC5568] to
which the MN is most likely to handover. This step is dependent on
access technology, and detail is out of scope.
(b) PMAG derives NMAG from the New AP ID , and collects all needed
information about MN, such as MN-ID, MN-HoA, MN-HNP, MN's MAC
address. Then the PMAG sends a Handover Initiate(HI) message to
NMAG with the 'R' flag set.
(c) NMAG sets up one tunnel to LMA and another to PMAG. The former
is for uplink and the latter is for downlink of MN. Then NMAG
sends a Proxy Binding Update(PBU) message to the LMA.
(d) Upon receipt of the PBU message, the LMA updates its binding
cache entry of MN, then removes the tunnel to PMAG and sets up a
tunnel to NMAG. After that, the LMA replies a PBA containing MN-HNP
to NMAG. By now, the entire downlink for MN has been established
and the process doesn't cost much time, which starts from LMA
removing tunnel to PMAG and ends by setting up tunnel to NMAG.
Before then, the downlink of MN is through LMA to PMAG.
(e) NMAG sends a Handover Acknowledge(HAck) message back to the
PMAG with 'T' flag set, which means PMAG should forwards the uplink
packets to NMAG after receiving this message.
(f) PMAG removes the tunnel to LMA and sets up a new one to NMAG
for the uplink of MN. So far, the entire uplink for MN has been
established and the process just take a short time, which starts
from PMAG removing the tunnel to LMA and ends by setting up the
tunnel to NMAG. Before then, the uplink is through PMAG to LMA by
the tunnel between them.
(g) During processes above, MN is still attaches to PMAG. Packets
meant for MN would be transfered to NMAG by LMA, then NMAG
transfers them to PMAG. Packets sent by MN would be forwarded to
NMAG by PMAG and NMAG forwarded them to LMA.
(h) L2 handover would be made immediately, MN sends L2-HO
information message to PMAG. The details on LH-HO is outside scope
of this memo.
(i) PMAG sends a HI message to NMAG with 'U' flag set, and NMAG
start buffering packets until MN's attachment.
(j) MN detaches from PMAG and attaches to NAMG's access link, and
sends a Router Solicitation(RS) message to NMAG.
(k) NMAG removes the tunnel to PMAG, updates its routing
information and replies a Router Advertisement(RA) message
containing MN-HNP.
(l) MN configures its interface using HNP received and gets one or
more IPv6 addresses.
(m) NMAG forwards the buffered packets to MN.
As described above, when MN handover to NMAG's access link, NMAG
has no need of registration to LMA. What NMAG needs to do is send a
RA message to MN after updating router state. Due to the
registration in advance, the handover latency can be greatly
reduced.
3.3 Handover Latency Analyze
We can divide the handover into two parts, link-layer handover and
network-layer handover. It would be thought that the proposed
handover scheme just proceeds network-layer handover ahead of time
and doesn't decrease the entire handover latency. However, it does
reduce the handover delay to a great extent.
Before step (c), PMAG would forward the downlink packets to MN from
LMA. After receiving PBU from NMAG, LMA updates the binding cache
and setup a new tunnel to NMAG. From now on, downlink packets would
be transferred to NMAG, and NMAG redirects them to PMAG. The first
part of proposed handover scheme is the time that LMA processes the
PBU message. At this moment, though PMAG hasn't set up a tunnel to
NMAG for uplink of MN, PMAG can transfer the uplink packets to LMA
by the original tunnel.
At step (e), PMAG receives the HAck message. It removes the tunnel
to LMA and set up a tunnel to NMAG for the uplink of MN. This is
the second part of proposed handover scheme.
The last part is the time that NMAG receives RS message and replies
RA message to MN, as shown of step (j) and (k). It is important to
note that the delay occurs only in step (c) and (e) before MN
detaches from PMAG. Outside that, MN can communicate with
correspondent node without obstacles.
Furthermore, if the NMAG needs to exchange message with AAA Server
for authentication of the MN, it wouldn't cause additional handover
delay in this proposed scheme. The authentication procedure would
be done when NMAG is in the early registration step, while MN can
communicate with the correspondent node via PMAG and LMA.
4. Message Format
4.1 Handover Initiate (HI)
This definition extents the HI message in [RFC5949]. The detail
format is shown as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|R|Rsv'd| Code | |
+-+-+-+-+-+-----+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
Distinguish Flag (R)
Registration flag. A new flag (R) is for PMAG to inform NMAG that
MN is imminent to handover. And the NMAG should start proxy
registration for MN in advance.
4.2 Handover Acknowledge (HAck)
This message definition extents the HAck message in [RFC5949].The
detail format is shown as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|U|P|F|T|Resv'd | Code | |
+-+-+-+-+-+-----+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
Distinguish Flag (T)
Transfer flag. A new flag (T) to request to transfer the packets
from the MN. PMAG should set up a tunnel to NMAG and forward the
uplink packets to NMAG after receiving HAck with 'T' flag. This is
different from 'F' flag which used to request to forward the
downlink packets of MN.
5. Security Consideration
Security threats for this memo follow those for PMIPv6 [RFC5213],
FMIPv6 [RFC5568] and FPMIPv6 [RFC5949]. Both MAGs and LMA must
implement IPsec [RFC4301] for protecting exchanged signaling
message. Like PBU and PBA message, the Handover Initiate (HI) and
Handover Acknowledge (HAck) must be protected using the mechanism
of Encapsulating Security Payload (ESP) [RFC4303] in transport
mode, to ensure integrity and data origin authentication.
6. References
6.1 Normative Reference
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July
2009.
6.2 Informative Reference
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September
2010.
Authors' Addresses
Hewei Yu
South China University of Technology
School of Computer Science & Engineering
South China University of Technology, Guangzhou, 510006
P.R. China
Email: hwyu@scut.edu.cn
Ziliang Li
South China University of Technology
School of Computer Science & Engineering
South China University of Technology, Guangzhou, 510006
P.R. China
Email: liziliang1989@gmail.com
This Internet-Draft will expire on October 18, 2015.
