Internet DRAFT - draft-cui-netext-pmipv6-shpmipv6
draft-cui-netext-pmipv6-shpmipv6
Network Working Group Y. Cui
Internet-Draft Tsinghua University
Intended status: Standards Track X. Xu
Expires: April 5, 2013 WD. Wang
XM. Li
Beijing University of Posts and
Telecommunications
YZ. Huo
W. Luo
ZTE Corporation
October 2, 2012
Seamless Handover for Multiple-Access Mobile Node in PMIPv6
draft-cui-netext-pmipv6-shpmipv6-00
Abstract
Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provide a mobile
node(MN) which requires no additional modification to MN with IP
mobility. Fast Handover for Proxy Mobile IPv6 (FHPMIPv6), specified
in[RFC5949], proposed two modes of fast handover, both of them use
single interface to transmate packets during handover, which requires
it to buffer packets in MAGs when interface performs handover.
Buffer packets in MAGs result in additional overhead, and increase
packets transmission delay. Unlike FHPMIPv6, this document proposed
a seamless handover scheme for multi-access mobile node with IP
mobility when one of MN's network interface performs handover from
one MAG to another. This scheme uses some other interface of the
multi-access mobile node to help process packets while handovering.
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 April 5, 2013.
Cui, et al. Expires April 5, 2013 [Page 1]
Internet-Draft SHPMIPv6 October 2012
Copyright Notice
Copyright (c) 2012 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 5
4.2. Mobile Node considerations . . . . . . . . . . . . . . . . 7
4.3. Mobile Access Gateway considerations . . . . . . . . . . . 7
4.4. Local Mobility Anchor considerations . . . . . . . . . . . 8
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Streamless Handover Initiate (SHI) message . . . . . . . . 8
5.2. Streamless Handover Acknowledge (SHAck) message . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Cui, et al. Expires April 5, 2013 [Page 2]
Internet-Draft SHPMIPv6 October 2012
1. Introduction
With the development of internet access technologies and mobile
terminal equipment, more and more hosts are operating in multiple-
interfaces, thus a terminal having access to multiple heterogeneous
network domain simultaneously has become possible. Proxy Mobile IPv6
is a network-based mobility protocol, it provids mobility support for
mobile node and requires no additional modification.
RFC 5949 FHPMIPv6 is a fast handover extension for PMIPv6, the
document proposed two modes of fast handover: reactive mode and
predictive mode. The main idea of the two modes of operations is to
establish a bi-directional tunnel between the Previous Mobile Access
Gateway (PMAG) and the New Mobile Access Gateway (NMAG). So, packets
destined for the Mobile Node are forward from the PMAG to the NMAG
over this tunnel. Both of the two modes of fast handover improve the
handover performance in terms of packet loss and latency, while none
of them takes full advantage of multi-access features of the mobile
node, as in both of the two handover modes, packets transmission on
the handover interface should be buffered at the PMAG or NMAG which
increases the requirement of storage volume forthe MAG. When there
are many MNs are handovering within the coverage area of the same
MAG, some packets may be lost due to cache insufficiency. The two
modes adopt cached and forwarded to deal with the packet while
handover will greatly increase the transmission delay, that may be
deadlly to delay-sensitive applications.
This document propose a seamless handover scheme for multiple-access
mobile node in PMIPv6, compared with the two kinds of handover modes
mentioned above.This seamless handover scheme doesn't need to buffer
the packets in MAG, which reduces the requirements on the MAG cache,
while reducing the transmission delay at the same time.
2. Requirements Language
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 [RFC2119].
3. Terminology
The following terminologys used in this document are define in
RFC5213:
Local Mobility Anchor (LMA).
Mobile Access Gateway (MAG).
Cui, et al. Expires April 5, 2013 [Page 3]
Internet-Draft SHPMIPv6 October 2012
Proxy Mobile IPv6 Domain (PMIPv6-Domain).
The following terminologys used in this document are define in
RFC5949:
Previous Mobile Access Gateway (PMAG).
New Mobile Access Gateway (NMAG).
The following terminologys are define and used in this document:
Stable Mobile Access Gateway (SMAG)
while one of MN's interface is handovering, The MAGs that connect
with some other interface of MN are called SMAG.
4. Protocol overview
+----------+
| LMA |
+----------+
|
|
+-----------+
| Router |
+-----------+
/ | \
/ | \
/ | \
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| PMAG | | SMAG | | NMAG |
+-----------+ +-----------+ +-----------+
\ / \ /
\ / \ /
\ / \ /
\ / \ /
IF1 | | IF2 IF2 | | IF1
+-----------+ +-----------+
| MN |---->| MN |
+-----------+ +-----------+
Figure 1 reference network for Multiple-Access Mobile Node handover
In order to alleviate the packet loss during handover, RFC5949
propsoed two kinds of fast handover schemes. In both of the two
handover scheme, the downlink packets need to be buffered either at
Cui, et al. Expires April 5, 2013 [Page 4]
Internet-Draft SHPMIPv6 October 2012
the PMAG or NMAG, depending on when the packet forwarding is
performed. This buffer and forwarding mechanism increase the cache
overhead in MAG and increase the data transmission delay. In this
document, we assume that mobile node have multiple network interface
access different MAG in the same PMIPv6-Domain and support weak host
model,that means MN can receive any locally destined packet
regardless of the network interface on which the packet was received.
The deployment scenario is illustrated in Figure 1.
In order to improve the performance during handover and reduce the
demand of the MAG buffer capacity, this document specifies a bi-
directional tunnel between the PMAG and SMAG to forward packets for
mobile node. If an interface is handovering, the packets
transmission on this interface was forwarded to SMAG then forwarded
to some other interface of MN. In order to build a bi-directional
tunnel between the PMAG and the SMAG, a new message called Streamless
Handover Initiate(SHI) and Streamless Handover Acknowledge (SHIA) was
define in Section 5. When multi-interface MN attach to MAG, MAG will
send PBU register message to LMA, then recevie a PBA message if
register succeeded, MAG will send SHI message to MAGs that connect
with MN's interface. Necessary extensions to LMA and MAG need to
support this handover scheme and the extentions are define in section
4.3 and section 4.4.
4.1. Protocol Operation
Unlike Predictive Fast Handover and Reactive Fast Handover, this
protocol build a bi-directional tunnel between MAGs that different
interfaces of the mobile node connects to. The sequence of event for
the seamless handover scheme for Multiple-Access Mobile Node is
illustrated in Figure 2.
+-----+ +------+ +------------+ +------+ +----+
| MN | | PMAG | | SMAG | | LMA | | CN |
+-----+ +------+ +------------+ +------+ +----+
IF1 IF2 | | | |
| | | | Flow X | |
|<--------------->|<--------------------------- --->|<-------->|
| | | | | |
| |------Router Solicitation-->| | |
| | | |---PBU(MN-ID)--->| |
| | | | | |
| | | | +----------------------+|
| | | | |Detect whether the MN ||
| | | | |have other interface ||
| | | | |has registered ||
| | | | +----------------------+|
| | | | | |
Cui, et al. Expires April 5, 2013 [Page 5]
Internet-Draft SHPMIPv6 October 2012
| | | |<-PBA(PMAG-Addr)-| |
| | | | | |
| |<----Router Advertisement---| | |
| | | |==Bi-Dir Tunnel==| |
| | | | | |
| | |<---SHI(MN-ID)-| | |
| | | | | |
| | |------SHIA---->| | |
| | | | | |
| | |=Bi-Dir Tunnel=| | |
+--------+| | | | |
|handover|| |<----------------------Flow X---------------|
+--------+| +-----------------------+| | |
| | | detection IF1 is || | |
| | | unreachable forword || | |
| | | Flow X to SMAG || | |
| | +-----------------------+| | |
| | | | | |
| | |-----Flow X--->| | |
| | | | | |
| |<---------Flow X------------| | |
| | | | | |
| | |------------PBU(dereg)---------->| |
| | | | | |
| | | | +----------------+ |
| | | | |forword Flow X | |
| | | | |to MAG2 | |
| | | | +----------------+ |
| | | | | |
| | | |<------------Flow X---------|
| |<---------Flow X------------| | |
| | | | | |
| | |<--------------PBA---------------| |
| | | | | |
Figure 2 the signaling process of streamless handover scheme for
Multiple-Access Mobile Node
The detailed descriptions are as follows:
o In the proxy mobile ipv6 network domain, MN has multiple interface
as illustrated in Figure 1, assumes that interface 1(IF1) has
already accessed PMIPv6 domain and data flow X transmitted through
the interface.
o IF2 accesses SMAG, and SMAG sends PBU message to LMA. If register
success, LMA send back PBA message to SMAG.
Cui, et al. Expires April 5, 2013 [Page 6]
Internet-Draft SHPMIPv6 October 2012
o When SMAG receives PBA message, it sends SHI message to PMAG,
noticing that the SHI message must include the MN-ID option. when
PMAG receives SHI message and finds that the MN connects to it,
PMAG sends a SHIA message to SMAG, otherwise PMAG send back MN not
attached SHIA message. When all this done, PMAG and SMAG detect
whether there exists any tunnel between them, if not, it will
build a bi-directional tunnel between them.notice that the tunnel
between MAGs are per-MAG-MAG.
o When IF1 performs a handover, first, if PMAG detects IF1 is
unreachable, it change the router and forwords the packet that
destination address is IF1 to SMAG. In this case , the
transmission path of flow X is LMA->PMAG->SMAG->IF2. Then PMAG
sends the DeReg PBU message to LMA.
o LMA receives the DeReg PBU message, first it changes the router
and forwards the packet of destination address IF1 to SMAG,.In
this case, the transmission path of flow X is LMA->SMAG->IF2.
Then LMA sends back DeReg PBA message to PMAG.
4.2. Mobile Node considerations
In this document, we assume that mobile node has multiple network
interfaces, and those interfaces access to the same PMIPv6-domain.
and all of the MN's network interfaces configuration the same home
network prefix. In order to support MNs that receive any locally
destined packet regardless of the network interface on which the
packet is received, the mobile node must support the weak host model.
While interface is handovering, it may re-config its IP address and
MN may not accept the packet that the destination address is the
handover interface, in this document, we assume MN can accept the
packet that the destination address is the handover interface's IP
address emporarily while the interface is handovering(details are out
of the scope of this document).
4.3. Mobile Access Gateway considerations
In the seamless handover scheme, when MAG receive a PBA message, it
need to send SHI message to some other MAGs that connect to MN, in
this document we assume that MAG knows the ip address of those MAG.
Notice that the SHI message at least includes MN-Id option. When MAG
receives SHI message, it detects whether the MN has a interface
connected with it, if so, MAG sends SHIA response message, and bulids
a bi-directional tunnel, otherwise, sends the response message of no
such node.
When MAG detects the departure of the MN's network interface, it
configures routing manner, the packets that sent to the interface are
Cui, et al. Expires April 5, 2013 [Page 7]
Internet-Draft SHPMIPv6 October 2012
forwarded through to SMAG through tunnels. As all the network
interfaces of MN's configured the same home network prefix, MAG can
forward packets to MN by prefix match.
4.4. Local Mobility Anchor considerations
When LMA receives a PBU message, it needs to detect wehther the MN
has another interface accessed the PMIPv6-domain, and associate all
MN's interface, in this document, we assume that LMA support flow
mobility, as [I-D.ietf-netext-pmipv6-flowmob] described
5. Message Formats
This section defines new mobility header messages for seamless
handover .
5.1. Streamless Handover Initiate (SHI) message
This message is created to bulid associate between MAGs that
different interfaces of MN connect to. The format of the Message
Data field in the Mobility Header is 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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence #
Must be set by the sender so replies can be matched to this message.
'A' flag
The Acknowledge (A) bit is set to request a Streamless Handover
Acknowledge be returned upon receipt of the SHI message.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver
Cui, et al. Expires April 5, 2013 [Page 8]
Internet-Draft SHPMIPv6 October 2012
Lifttime
16-bit unsigned integer. It represents the tunnel survival time.
Mobility Option
Same as [RFC5213]
5.2. Streamless Handover Acknowledge (SHAck) message
The Streamless Handover Acknowledge is used to acknowledge receipt of
a SHI message. The format of the Message Data field in the Mobility
Header is 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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence#
The Sequence Number in the Streamless Handover Acknowledge is copied
from the Sequence Number field in the SHI message.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Lifetime
16-bit unsigned integer. It represents the tunnel survival time.
Status
0: successed
128: Reason unspecfied
129: MN not attached
Cui, et al. Expires April 5, 2013 [Page 9]
Internet-Draft SHPMIPv6 October 2012
6. IANA Considerations
TBD
7. Security Considerations
TBD
8. Normative References
[I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6
Extensions to Support Flow
Mobility",
draft-ietf-netext-pmipv6-flowmob-04
(work in progress), July 2012.
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC5213] Gundavelli, S., Leung, K.,
Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RFC5949] Yokota, H., Chowdhury, K., Koodli,
R., Patil, B., and F. Xia, "Fast
Handovers for Proxy Mobile IPv6",
RFC 5949, September 2010.
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
EMail: cuiyong@tsinghua.edu.cn
Xin Xu
Beijing University of Posts and Telecommunications
Tsinghua University FIT Building 4-103
Beijing 100084
P.R.China
Cui, et al. Expires April 5, 2013 [Page 10]
Internet-Draft SHPMIPv6 October 2012
EMail: xuxin1988@gmail.com
Wendong Wang
Beijing University of Posts and Telecommunications
Room 609, teaching building 3,BUPT
Beijing 100876
P.R.China
EMail: wdwang@bupt.edu.cn
XiMing Li
Beijing University of Posts and Telecommunications
Tsinghua University FIT Building 4-103
Beijing 100084
P.R.China
EMail: xml@bupt.edu.cn
Yuzhen Huo
ZTE Corporation
No.68 Zijinghua Rd.,Yuhuatai District
Nanjing 210012
P.R.China
EMail: huo.yuzhen@zte.com.cn
Wen Luo
ZTE Corporation
No.68 Zijinghua Rd.,Yuhuatai District
Room 609, teaching building 3,BUPT 210012
P.R.China
EMail: EMail:luo.wen@zte.com.cn
Cui, et al. Expires April 5, 2013 [Page 11]
