Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Standards Track S. Gundavelli
Expires: February 23, 2009 K. Leung
Cisco
August 22, 2008
Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6
draft-yokota-netlmm-pmipv6-mn-itho-support-00.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 February 23, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Yokota, et al. Expires February 23, 2009 [Page 1]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Yokota, et al. Expires February 23, 2009 [Page 2]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 [1].
Yokota, et al. Expires February 23, 2009 [Page 3]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
2. Introduction
RFC4831[3] 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
[2] 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.
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 February 23, 2009 [Page 4]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 February 23, 2009 [Page 5]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 February 23, 2009 [Page 6]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 February 23, 2009 [Page 7]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 February 23, 2009 [Page 8]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
6. Security Considerations
This document discusses the internal behavior of the mobile node and
no additional security concern is introduced.
Yokota, et al. Expires February 23, 2009 [Page 9]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
7. IANA Consideration
This document does not require any assignment by IANA.
Yokota, et al. Expires February 23, 2009 [Page 10]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[3] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
Yokota, et al. Expires February 23, 2009 [Page 11]
Internet-Draft PMIPv6 Inter-Tech HO Support August 2008
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 February 23, 2009 [Page 12]
Internet-Draft PMIPv6 Inter-Tech HO Support August 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).
Yokota, et al. Expires February 23, 2009 [Page 13]