TOC |
|
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 April 23, 2010.
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.
The Proxy Mobile IPv6 supports a mobile node to perform inter-technology handover as well as multihoming. However the inter-technology handover requires the new interface to use the same network prefix with the old one and all the IP address/prefix at the old interface are removed. These requirements disable multihoming function which requires different network prefixes for different interfaces. In this Internet draft we address this problem and suggest a solution using virtual interface mechanism at the mobile node.
1.
Introduction
2.
Inter technology handover and multihoming scenario
3.
Virtual interface support at mobile node
4.
PMIPv6 operations with the supporting of virtual interface at mobile node
5.
Conclusion
6.
Security Considerations
7.
IANA Considerations
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
TOC |
In the real system, a mobile node can connect to the network by using multiple interfaces with different access technologies such as WiFi, CDMA. At the same time it can perform multiple connections for multiple services such as video, voice, or just chatting. As time goes by, due to the changing of network status or other reasons, it may want to perform partial handoff [4] (Jeyatharan, M., Gundavelli, S., and V. Devarapalli, “Partial Handoff Support in PMIPv6, draft-jeyatharan-netext-pmip-partial-handoff-00 (work in progress),” March 2009.). Some connections are moved to a new interface, while the other ones keep using the current interface. The draft [5] (Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00 (work in progress),” March 2009.) describes the minimum requirements on the mobile node for handovers across interfaces using Proxy Mobile IPv6 [1] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.). First, the mobile node removes the IP address/prefix from the old interface, and then sets the same IP address/prefix on the new interface. Finally, it updates active socket structures to the new interface. When removing an IP address from an interface, its link-layer connection is torn down, leading to the removal of the entire auto configured IP addresses/prefixes of the old interface. In addition, at local mobility anchor, all of the home network prefixes associated with the old interface will be associated with a new one. These practices can terminate all other connections using the old interface and disable the multihoming function.
The Internet draft [4] (Jeyatharan, M., Gundavelli, S., and V. Devarapalli, “Partial Handoff Support in PMIPv6, draft-jeyatharan-netext-pmip-partial-handoff-00 (work in progress),” March 2009.) outlines extensions to PMIPv6 protocol in order to support a multiple interfaced mobile node to achieve such partial vertical handoff of selected prefixes. In their solution, the multihoming sessions are protected while moving some flows from an interface to another. However it requires the application sessions at a mobile node to be aware of the interface changing. In addition the local mobility anchor also has to track the interface changing of each connection at the mobile node. These limitations may threat the survivability of sessions across handovers.
In this draft we suggest to use virtual interface to hide the multiple physical interfaces involved in the handover and multihoming. We introduce the inter-technology handover and multihoming scenario in section 2.
TOC |
The draft [5] (Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00 (work in progress),” March 2009.) discusses about the multiple interfaces scenarios in detail. In this draft we consider a scenario that can support multiple access technologies using multiple mobile access gateways. A local mobility anchor is used to manage the mobility of all the mobile nodes. A multiple local mobility anchors scenario is out of the scope of this draft. Each mobile node in the Proxy Mobile IPv6 domain can be equipped with more than one interface using different technologies such as WiFi, HSDP or CDMA. At the same time, the mobile node can connect to the Proxy Mobile IPv6 domain using multiple interfaces simultaneously, called multihoming support. When moving across the mobile access gateways, or when suffering from the instability of network status, the mobile node can move some flows from an interface to others, called inter technology/interfaces handover. Figure 1 shows a use case that is considered in this draft.
+----+ |LMA | +----+ //\\ +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ // \\ +----+ +----+ (WIMAX) |MAG1| |MAG2| (WiFi) +----+ +----+ \ / \ / \ / +----\---------/----+ |IF1|---|VIF|---|IF2| |-------------------| | MN | +-------------------+
Figure 1: A Proxy Mobile IPv6 domain with multiple access technologies |
TOC |
Most of the current systems, such as Linux, MAC-OS or Window, offer support to create a virtual interface over multiple physical interfaces. The virtual interface represents for all other physical interfaces and provides a single IP link for the upper layers. All of the changes of physical interfaces are transparent to the upper layers. Meanwhile the physical interfaces are limited to any global IP addresses, they have only link-local addresses. The applications only recognize the global IP address of the virtual interface. Figure 2 shows an example of a virtual interface architecture implemented at a mobile node. The detailed configuration parameters are showed in the table 1. We can see in this example that only the virtual interface is assigned a global IP address, 2009:1234:5678:BBBB::15. The MAC address of virtual interface is set to the MAC address of a physical interface, IF1.
ID | Global IP Address | MAC Address |
---|---|---|
VIF | 2009:1234:5678:BBBB::15 | 00-0C-F1-56-98-AA |
IF1 | None | 00-0C-F1-56-98-AA |
IF2 | None | 00-0C-F1-56-98-BB |
Table 1: The address configuration of a mobile node using virtual interface mechanism |
+----------------------------+ | Application | +----------------------------+ | TCP/UDP | +----------------------------+ | IP | +----------------------------+ | Virtual Interface | +----------------------------+ |(IF1) |(IF2) | ..... | (IFn)| +------+------+ +------+ | | | WIMAX WiFi CDMA | | | +----------------------------+ | Access networks | +----------------------------+
Figure 2: The virtual interface support at a mobile node |
There are several ways for setting a virtual interface at mobile node. The detailed discussion of setting procedures is out of the scope of this draft. For further information we can refer to NET:BRIDGE [6] (, “Net:Bridge,” .) or Interface bonding [7] (, “Linux Port Bonding,” .).
TOC |
Since the mobile node uses a virtual interface, from the layer 3 point of view, all of the links of multiple interfaces are hidden under a single IP link. As a result, the mobile node is offered a capability to hide interface changes due to handovers so as to preserve the same home network prefix in use.
When the mapping between the virtual interface and the multiple interfaces is available, the mobile node can connect to Proxy Mobile IPv6 by using multiple links simultaneously. All of these links will use the same home network prefix of the virtual interface.
However, when all of the links share the same home network prefix, the local mobility anchor should be able to identify the flows that need to be forwarded to corresponding interfaces.
For PMIPv6 to work with the mobile node using virtual interface, we suggest to extend the signaling between the mobile access gateway and the local mobility anchor, as well as to modify the control logic at local mobility anchor.
The mobile access gateway should include the flow information in the Proxy Binding Update sent to the local mobility anchor. To get the flow information, the mobile access gateway can collect information about the service identifier at layer 2 when a mobile node attach to it. We can refer to the draft [8] (Soliman, H., Montavonte, N., Fikouras, N., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and Nemo Basic Support,draft-ietf-mext-flow-binding-03 (work in progress),” May 2008.) for more detail about the service identifier. The mobile access gateway can inform the flow information to the local mobility anchor by using the Service Selection option in the Proxy Binding Update as discussed in [2] (Korhonen, J., Nilsson, U., and V. Devarapalli, “Service Selection for Mobile IPv6,” February 2008.).
When receiving the Proxy Binding Update message from the mobile access gateway, the local mobility anchor checks the flow information and creates or updates the flow filters. The flow filters then may be stored in the binding cache entry for the mobile node.
The figure 3 shows an example of use case with address configuration of using virtual interface at mobile node. The virtual interface of the mobile node is then assigned to the same network prefix with the access interface of the mobile access gateway 1 and 2. The detail address configuration is showed in the table 2. Note that the physical interfaces of the mobile node are not assigned any global IP address. It has only local-link MAC address as showed in the table 1.
LMA's binding state +----+ ------------------- |LMA | MN_ID, Addr, Flow1 -> MAG1 +----+ MN_ID, Addr, Flow2 -> MAG2 //\\ +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA1 // \\ PCoA2 +----+ +----+ (WIMAX) |MAG1| |MAG2| (WiFi) +----+ +----+ MAGA1 (P2) \ / MAGA2 (P2) \ / \ VIFA (P2) / +----\---------/----+ |IF1|---|VIF|---|IF2| |-------------------| | MN | +-------------------+
Figure 3: Use case with address configuration |
ID | Network prefix | Global IP Address |
---|---|---|
MAGA1 | 2009:1234:5678:BBBB::/64 | ~::1 |
MAGA2 | 2009:1234:5678:BBBB::/64 | ~::2 |
VIFA | 2009:1234:5678:BBBB::/64 | ~::200 |
IF1 | FE80::/10 | None |
IF2 | FE80::/10 | None |
Table 2: Address configuration table |
TOC |
Supporting both multihoming and inter technology handoff using PMIPv6 is challenge since no mobile node involvement is allowed. Modifying the mobile node is also limited. In this draft we introduce a solution that can support and solve the problems of both multihoming and inter technology handoff by using virtual interface at the mobile node. The key advantage of virtual interface architecture is that it can hide all the changing of physical interface from upper layers. From that the mobile node can performs seamless handoff between interfaces without any session loss. The mobile node can also perform multihoming when the maping between virtual interface and multiple physical interfaces is available.
In the future work we will discuss more detail about several technical requirements in section 4.
TOC |
This document doesn't intend to provide the NETEXT security analysis but one will be required.
TOC |
This document has no actions for IANA.
TOC |
TOC |
[1] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
[2] | Korhonen, J., Nilsson, U., and V. Devarapalli, “Service Selection for Mobile IPv6,” RFC 5149, February 2008 (TXT). |
[3] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
TOC |
[4] | Jeyatharan, M., Gundavelli, S., and V. Devarapalli, “Partial Handoff Support in PMIPv6, draft-jeyatharan-netext-pmip-partial-handoff-00 (work in progress),” March 2009. |
[5] | Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00 (work in progress),” March 2009. |
[6] | “Net:Bridge.” |
[7] | “Linux Port Bonding.” |
[8] | Soliman, H., Montavonte, N., Fikouras, N., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and Nemo Basic Support,draft-ietf-mext-flow-binding-03 (work in progress),” May 2008. |
TOC |
Tran Minh Trung | |
ETRI | |
161 Gajeong-Dong Yuseung-Gu | |
Daejeon, 305-700 | |
Korea | |
Phone: | +82 42 860 1132 |
Email: | trungtm2909@gmail.com |
Yong-Geun Hong | |
ETRI | |
161 Gajeong-Dong Yuseung-Gu | |
Daejeon, 305-700 | |
Korea | |
Phone: | +82 42 860 6557 |
Email: | yonggeun.hong@gmail.com |