Virtual interface for supporting multihoming and inter technology handover
draft-trung-netext-virtual-interface-01

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 April 30, 2010.

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.

Abstract

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 the necessary changes in PMIPv6 operations to support a mobile node to perform multihoming as well as seamless inter technology handover with virtual interface.

Table of Contents

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

1.  Introduction

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. Second, it 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.

The virtual interface is a well known technique [6] (Hong, Y. and J. Youn, “Virtual network interface model for multiple network interfaces in a host,” March 2009.). It can help us to hide all the changing of physical interfaces from application sessions and perform seamless inter technology handover without any interruption of multihoming sessions. However there are few documents that discuss about how to support virtual interface in PMIPv6. In this Internet draft we suggest the necessary changes in PMIPv6 operations to support the mobile nodes to perform multihoming as well as seamless inter technology handover with virtual interface.

2.  Inter technology handover and multihoming scenario

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         |
                        +-------------------+

3.  Virtual interface support at mobile node

Most of the current systems, such as Linux, MAC-OS or Windows, 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.

                    +----------------------------+
                    |        Application         |
                    +----------------------------+
                    |          TCP/UDP           |
                    +----------------------------+
                    |             IP             |
                    +----------------------------+
                    |     Virtual Interface      |
                    +----------------------------+
                    |(IF1) |(IF2) | ..... | (IFn)|
                    +------+------+       +------+
                       |      |              |
                     WIMAX   WiFi           CDMA
                       |      |              |
                    +----------------------------+
                    |       Access networks      |
                    +----------------------------+

There are several ways for setting a virtual interface at a 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 [7] (, “Net:Bridge,” .) or Interface bonding [8] (, “Linux Port Bonding,” .).

4.  PMIPv6 operations with the supporting of virtual interface at mobile node

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 domain 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 [9] (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 the mobile node. The virtual interface of the mobile node is assigned to the same network prefix with the access interface of the mobile access gateway 1 and 2 (MAGA1, MAGA2). The detail address configuration is showed in the table 2. Note that only the virtual interface, VIF, of the mobile node is assigned a global IP address, all of the physical interfaces, such as IF1 and IF2, are not assigned any global IP address. They have only link-local 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)
                     \             /
                      \    (P2)   /
                  +----\---------/----+
                  |IF1|---|VIF|---|IF2|
                  |-------------------|
                  |        MN         |
                  +-------------------+

5.  Conclusion

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 mapping 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.

6.  Security Considerations

This document doesn't intend to provide the NETEXT security analysis but one will be required.

7.  IANA Considerations

This document has no actions for IANA.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses