Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Informational S. Gundavelli
Expires: October 12, 2009 K. Leung
Cisco
April 10, 2009
Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6
draft-yokota-netlmm-pmipv6-mn-itho-support-01.txt
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 October 12, 2009.
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.
Yokota, et al. Expires October 12, 2009 [Page 1]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
Abstract
Proxy Mobile IPv6 supports a handoff between different access
technologies, by which the assigned IP address is preserved
regardless of the access technology type. From the perspective of
the mobile node, this involves the change of the network interfaces,
through which the IP address is assigned and the IP session is
established. Some implementations, however, do not assume this
interface switching in the middle of the session and it could cause a
disconnection by the event of unavailability of the current
interface; hence it is not guaranteed to be able to maintain the IP
session simply by assigning the same IP address to the new interface.
This document analyzes the handling of the network interfaces on the
mobile node and presents several measures to avoid a disconnection
due to the interface switching.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Handover Scenarios and requirements on the mobile node . . . . 5
4. Operational issues . . . . . . . . . . . . . . . . . . . . . . 6
5. Example solutions for inter-technology handover support. . . . 7
5.1. Virtual interface adaptor . . . . . . . . . . . . . . . . 7
5.2. Direct support . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Yokota, et al. Expires October 12, 2009 [Page 2]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
1. Requirements notation
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].
Yokota, et al. Expires October 12, 2009 [Page 3]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
2. Introduction
RFC4831[RFC4831] addresses the support of an unmodified host as one
of the goals for NETLMM; however, it also foresees additional
functions in the physical and medium access control layers, typically
wireless interface driver, on the mobile node for handover support or
movement detection. This issue becomes more visible when Proxy
Mobile IPv6 [PMIP6] is applied to inter-technology handoff, where the
mobile node handles multiple interfaces. When the mobile node hands
off from one access technology to another, the corresponding
interfaces are also switched. Even if the same IP address (MN-HoA)
is assigned to both interfaces, this interface switching could cause
some problem. When some application on the mobile node establishes a
session, it binds a descriptor to the assigned IP address via the
socket interface. When this IP address is internally bound to one
network interface, at the time when this interface is detached from
the network and/or another interface is attached to the network, this
session may lose connectivity. Also, some point-to-point link device
is ephemeral, that is, it exists only the link-layer connection is
established. If this is the case, the session on that link may not
be transferred unless a new connection is established in a timely
manner. More detailed issues on network-based inter-technology
handovers are described in [ITHO-PS].
This document exhibits possible solutions to maintain sessions when
inter-technology handover is performed, whereby the network has only
to care about the IP address preservation. The scope of this
document is limited to the internal behavior of the mobile node and
no interaction between the mobile node and network is specified.
Yokota, et al. Expires October 12, 2009 [Page 4]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
3. Handover Scenarios and requirements on the mobile node
Suppose the mobile node has two interfaces. Depending on the policy
and/or radio environment, the following handover scenarios can be
considered.
IF#1 IF#2
(a) -----------------| |****************
T1 < T2
IF#1 IF#2
(b) -------------------||******************
T1 = T2
IF#1
(c) ----------------------| IF#2
|*********************
T2 < T1
Figure 1: Handoff scenarios
(a) There is a gap between the time when IF#1 is detached or
deactivated (T1) and the time when IF#2 is attached or activated
(T2). During the time segment (T1, T2), the connectivity to the
network is lost; however, the mobile node MUST retain all the
sessions associated with the MN-HoA. For incoming packets, all
that are sent to IF#1 after T1 and all that are sent to IF#2
before T2 will be lost if there is no buffering mechanism on the
network side (there is nothing to do on the mobile node side).
For outgoing packets, There SHOULD be a buffer on the mobile
node and the active interface SHOULD always be detected and
selected.
(b) Immediately after IF#1 is detached or deactivated, IF#2 is
attached or activated. For incoming packets, packet loss can be
avoided if the active interface is always detected and selected.
For outgoing packets, no buffer is required on the client side
since always one interface is active at any point in time.
(c) IF#2 is attached or activated (T2) before IF#1 is detached or
deactivated (T1). In this case, both interfaces are active
during the time segment (T2, T1). For incoming packets, both
interfaces SHOULD be able to receive them. For outgoing
packets, either one of the two interfaces SHOULD be selected at
any given time.
Yokota, et al. Expires October 12, 2009 [Page 5]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
4. Operational issues
This section exemplifies several operational issues on the mobile
node that can affect the behavior of inter-technology handoff. Some
of those issues are attributed to the constraints of hardware and/or
software implementations and also dependent on the operating system
in use on the mobile node.
o Simultaneous use of multiple interfaces:
Even if the mobile node has multiple interfaces, there could be
some limitation that only one interface can be active at any given
time due to the internal radio interferences. This mode of
operation is called the "single radio mode" and only scenario (a)
(or ideally (b)) is feasible. On the other hand, if multiple
interfaces can be active at the same time, which is called the
"dual (or multi) radio mode", scenario (c) becomes feasible.
o Address binding policy:
Some operating system does not allow assigning the same IP address
to multiple active interfaces. If this is the case, even if the
mobile node can run in dual radio mode, only scenario (a) (or
ideally (b)) is feasible. In the worst case, at the time when the
current interface is turned down (T1), on-going IP session(s) is/
are terminated.
o Relationship between network interfaces:
When a point-to-point connection (e.g., PPP) is established for IP
session(s), some operating system cannot retain that connection if
the underlying interface (e.g., radio) becomes unavailable. If
this point-to-point connection is tightly coupled with the
underlying interface, neither of the handoff scenarios is
feasible.
Yokota, et al. Expires October 12, 2009 [Page 6]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
5. Example solutions for inter-technology handover support.
There are multiple ways to retain sessions under the inter-technology
handover accompanying the switching of interfaces. This section
describes example (non exclusive) solutions.
5.1. Virtual interface adaptor
In this solution, an intermediate logical interface called "virtual
interface adaptor (VIA)" is used to hide the link movement from the
IP layer. The VIA is not bound to any physical interface and the MN-
HoA is assigned to this adaptor. Even if the active link is changed
or deleted, the transport session is not aware of it.
+----------------------------+
| TCP/UDP |
Session to IP +->| |
address binding | +----------------------------+
+->| IP |
IP to VIA +->| |
binding | +----------------------------+
+->| Virtual IF Adaptor |
VIA to physical +->| (MN-HoA) |
IF binding | +----------------------------+
+->| L2 | L2 | | L2 |
|(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 2: Virtual Interface Adaptor
This solution is effective when the operating system tries to bind
the assigned IP address to the active interface. Even if that
interface is disconnected or deactivated and there is a time gap
until a new interface is activated such as the handover scenario (a)
in Section 2, the VIA remains active and retains the session. Not
only for maintaining IP sessions, the VIA can also be the place to
control those network interfaces for scenarios (b) or (c).
Synchronizing with the network, the VIA switches from one interface
to another and/or selects the outgoing interface among multiple
active ones.
5.2. Direct support
Some operating system allows one IP address to be assigned to
multiple interfaces and to be maintained regardless of the status of
Yokota, et al. Expires October 12, 2009 [Page 7]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
those interfaces. In this case, by quickly switching one interface
to another, scenario (b) can be asymptotically realized. If dual
radio mode can be assumed, by activating two interfaces, both of
which have the same IP address, scenario (c) can be realized. In
either case, a proper trigger needs to be provided for the timing of
the interface switching and in scenario (c), a proper policy to
select the interface for outgoing packets needs to be provided as
well.
+----------------------------+
| TCP/UDP |
Session to IP +->| |
address binding | +----------------------------+
+->| IP |
IP address to +->| |
physical IF | +----------------------------+
binding +->| L2 | L2 | | L2 |
|(IF#1)|(IF#2)| ..... |(IF#n)|
+----^-+-^----+ +------+
| L1: | :L1 | | L1 |
| : | : | | |
+----:-+-:----+ +------+
:==>:
MN-HoA
Figure 3: Direct support
Yokota, et al. Expires October 12, 2009 [Page 8]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
6. Security Considerations
This document discusses the internal behavior of the mobile node and
no additional security concern is introduced.
Yokota, et al. Expires October 12, 2009 [Page 9]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
7. IANA Consideration
This document does not require any assignment by IANA.
Yokota, et al. Expires October 12, 2009 [Page 10]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PMIP6] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213,
August 2008.
8.2. Informative References
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[ITHO-PS] Krishnan, S., Yokota, H., and T. Melia, "Issues with
network based inter-technology handovers",
draft-krishnan-netext-intertech-ps-00.txt, February 2009.
Yokota, et al. Expires October 12, 2009 [Page 11]
Internet-Draft PMIPv6 Inter-Tech HO Support April 2009
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Email: yokota@kddilabs.jp
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
US
Email: sgundave@cisco.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
US
Email: kleung@cisco.com
Yokota, et al. Expires October 12, 2009 [Page 12]