| TOC |
|
Proxy Mobile IPv6 (PMIPv6) supports multihoming where a mobile node can connect to a PMIPv6 domain through multiple interfaces for simultaneous access. However, for an inter-technology handoff, PMIPv6 does not allow simultaneous access since all the home network prefixes associated with one interface are associated with another interface of a mobile node. In this document, we propose a hybrid home network prefix assignment (HHNPA) scheme where both the static prefix model and the dynamic prefix model are used for simultaneous access. The static prefix model is used within the general PMIPv6 domain. On the other hand, the dynamic prefix model is employed for inter-technology handoff. That is, for IP session continuity during inter-technology handoff, a dynamic prefix model is used on both interfaces.
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 September 2, 2010.
Copyright (c) 2010 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 BSD License.
1.
Introduction
2.
Problem statement of multihoming support in PMIPv6
3.
Hybrid home network prefix assignment
4.
Security Considerations
5.
IANA Considerations
6.
References
6.1.
Normative References
6.2.
Informative References
§
Authors' Addresses
| TOC |
Mobile IPv6 [RFC3775][1] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and Mobile IPv4 [RFC3344][2] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) are host based IP mobility support protocols. On the other hand, Proxy Mobile IPv6 (PMIPv6) [RFC5213][3] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) is a network based IP mobility support protocol, which does not require any modifications to mobile nodes(MNs). PMIPv6 makes it possible to support mobility for IPv6 nodes without an involvement of a MN. That is, on behalf of MNs, a mobile access gateway (MAG) in the network performs the signaling for mobility management with a local mobility anchor (LMA).
PMIPv6 defines basic operations for registration, deregistration, and tunnel management. However, it does not define protocol operations for supporting seamless handover for a MN with multiple network interfaces (i.e., inter-technology handoff) [5] (Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00,” March 2009.). While PMIPv6 itself supports handover across different interfaces and access types, there are several issues for efficient inter-technology handoff, e.g., how to set interface identifier, how to use the same address on multiple interfaces, how to select an access technology, and how to detect a handover event [6] (Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, “Issues with network based inter-technology handovers, draft-krishnan-netext-intertech-ps-02,” July 2009.).
PMIPv6 basically support multihoming where a MN can connect to a PMIPv6 domain through multiple interfaces for simultaneous access and inter-technology handoff between different multiple interfaces. If a MN with multiple interfaces connects to a PMIPv6 domain over multiple access networks, the LMA will allocate a unique set of home network prefixes (HNPs) for each of the connected interfaces. However, when the MN performs an inter-technology handoff, the LMA will newly assign all the home network prefixes, which are associated with the first interface, to the second interface. Consequently, the existing mobility sessions with the second interface will be disrupted. Fundamentally, this problem has been caused due to the fact that each of the attached interfaces must be assigned one or more unique prefixes in PMIPv6. Therefore, to address this problem, we propose a hybrid home network prefix assignment (HHNPA) scheme where both the static prefix model and the dynamic prefix model are employed and dynamically selected. That is, for IP session continuity, a dynamic home network prefix is used on both interfaces.
| TOC |
To support multiple mobility sessions for a single MN with multiple interfaces, PMIPv6 creates mobility sessions per interface and each mobility session should be managed as a separate binding cache (BC) entry. Note that although the LMA can allocate more than one home network prefix to an interface, all these prefixes are managed by one mobility session. The LMA allows a handoff between two different interfaces of a MN. In such a scenario, all the home network prefixes associated with one interface will be associated with another interface of the MN. The decisions on when to create a new mobility session and when to update an existing mobility session are based on the handover hint included in the Proxy Binding Update message.
Basic operations for multiple interfaces in PMIPv6 are as follows. First of all, the MAG decides whether to inform the LMA of the attachment of the second interface (or an inter-technology handoff), and then the MAG sends a Proxy Binding Update (PBU) message. When the LMA receives the PBU message, it verifies the request message. If the PBU message includes a handoff indicator flag of 1 (i.e., initial attachment), the LMA allocates a new mobility session for second interface and thus the LMA has multiple Binding Cache entries. On the other hand, if the PBU message has a handoff indicator flag of 2 (i.e., inter-technology handoff), all the home network prefixes associated with the first interface will be associated with the second interface. Figures 1 and 2 describe the operations of two cases: initial attachment and inter-technology handoff. In particular, as shown in Figure 2, for inter-technology handoff, HNP_2 is overwritten with HNP_1 and then the existing mobility session 1 is removed from the binding cache entry at the LMA.
+----+
|LMA | LMA BC entry
+----+ (before assigning
//\\ multiple mobility sessions)
+---------//--\\-------------+ -----------------
( // \\ PMIPv6 ) MN:if_1 [HNP_1] --> MAG1
( // \\ domain )
+------//--------\\----------+
// \\
// \\ LMA BC entry
+----+ +----+ (after assigning
|MAG1| |MAG2| multiple mobility sessions)
+----+ +----+ -----------------
| | MN:if_1 [HNP_1] --> MAG1
| | MN:if_2 [HNP_2] --> MAG2
HNP_1 | if_1 if_2 | HNP_2
+------[MN]------+
| Figure 1: Multihoming in PMIPv6 : Initial attachment |
+----+
|LMA | LMA BC entry
+----+ (before assigning
//\\ multiple mobility sessions)
+---------//--\\-------------+ -----------------
( // \\ PMIPv6 ) MN:if_1 [HNP_1] --> MAG1
( // \\ domain ) MN:if_2 [HNP_2] --> MAG2
+------//--------\\----------+
// \\
// \\ LMA BC entry
+----+ +----+ (after assigning
|MAG1| |MAG2| multiple mobility sessions)
+----+ +----+ -----------------
| |
| | MN:if_2 [HNP_1] --> MAG2
HNP_1 | if_1 if_2 | HNP_2
+------[MN]------+
| Figure 2: Multihoming in PMIPv6 : Inter-technology handoff |
These multihoming operations in PMIPv6 have the following problems.
Fist, since the LMA assigns the same home network prefix to the second interface after inter-technology handoff and updates the existing Binding Cache entry, the previous binding information of the second interface can be removed. Therefore, the existing flows through the second interface may be disrupted [5] (Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00,” March 2009.).
In addition, since there is no way to enable flow-specific handoffs, compelled handoff of unwanted IP flows can be performed due to inter-technology handoff. The existing multihoming operations have drawbacks in terms of implementation.
As mentioned before, the MAG should set the handoff indicator flag (e.g., 1 for initial attachment or 2 for inter-technology handoff). However, the MAG does not have sufficient information on multihoming support and thus it is not an easy task to distinguish initial attachment and interface handoff [6] (Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, “Issues with network based inter-technology handovers, draft-krishnan-netext-intertech-ps-02,” July 2009.).
Moreover, all home network prefixes are determined when the first mobility session is generated for a corresponding interface. Therefore, there is no way to add or delete a new home network prefix [7] (Jeyatharan, M. and C. Ng, “Multihoming Problem Statement in NetLMM, draft-jeyatharan-netext-multihoming-ps-01,” March 2009.). To address these issues, we propose a hybrid home network prefix assignment scheme in the next section.
| TOC |
In terms of home network prefix allocation in PMIPv6, the per-MN prefix model is mandatory whereas the shared prefix model is not supported. In the per-MN prefix model, home network prefixes are assigned to a MN and these prefixes are exclusively used by the MN; no other MNs share the home network prefix. Note that all assigned prefixes are unique and they are parts of one mobility session. If the MN simultaneously attaches to a PMIPv6 domain through multiple interfaces, each of the attached interfaces must be assigned one or more unique prefixes. Therefore, when performing an inter-technology handoff based on the per-MN prefix model, simultaneous access to the PMIPv6 domain is not allowed. If it is able to separate prefixes into the purpose of inter-technology handoff and the purpose of simultaneous access, PMIPv6 may support both interface handoff and simultaneous access at the same time. Based on this idea, we propose a hybrid home network prefix assignment (HHNPA) scheme to use both the static and dynamic home network prefix models.
Figure 3 introduces the concept of the HHNPA scheme where the LMA divides home network prefixes into a static home network prefix and a dynamic home network prefix. The static home network prefix (based on the per-MN prefix model) is used within the PMIPv6 domain. On the other hand, the dynamic home network prefix is employed for inter-technology handoffs.
+--------------------------------+
| |
| +----------------+---------------+
| | | |
| HNP_1 | HNP_2 | HNP_3 |
|(static prefix)|(dynamic prefix)|(static prefix)|
| | | |
| +----------------+---------------+
| | if_2
+--------------------------------+
if_1
| Figure 3: Prefix model in HHNPA |
In the dynamic prefix model, dynamic prefixes are assigned into only one interface and they are switchable between interfaces. Dynamic prefixes are not used multiple interfaces simultaneously. In contrast to dynamic prefixes, static prefixes cannot be switchable between interfaces. As shown in Figure 4, HNP_1 is static prefix and it is used at only if_1. HNP_3 is static prefix and it is used at only if_2. HNP_2 is dynamic prefix and it can be used both if_1 and if_2. In this figure, HNP_1 and HNP_3 are used for simultaneous access and HNP_2 is used for inter-technology handoff.
+----+
|LMA |
+----+
//\\
+---------//--\\-------------+
( // \\ PMIPv6 )
( // \\ domain )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1|<--HNP_2-->|MAG2|
+----+ +----+
| |
| |
HNP_1 | if_1 if_2 | HNP_3
+------[MN]------+
| Figure 4: Usage scenario of HHNPA scheme |
Figure 5 describes the message flow in the HHNPA scheme. At the starting time, a MN is attached the PMIPv6 domain through MAG_1 using interface 1. After that, the MN is attached the PMIPv6 domain through MAG_2 using interface 2. When second interface of the MN is attached to the LMA, the LMA acknowledges that the MN is a multiple interfaces node and prepares to allocate a dynamic prefix. The LMA sends two PBA messages to MAG_1 and MAG_2. The two PBA messages destined to MAG_1 and MAG_2 includes a home network prefix option (HNP_2: dynamic prefix).
+------+ +-----+ +-----+ +-----+
| MN | |MAG_1| |MAG_2| | LMA |
+------+ +-----+ +-----+ +-----+
| | | | |
| |MN[if_1] attach MAG_1 | |
| |-------------------->| (MN-ID, if_1, ...) |
| | |---------------PBU--------------->|
| | | | |
| | |(MN-ID, if_1, HNP_1:static prefix)|
| | |<--------------PBA----------------|
| | | | |
| | |========= Bi-Dir Tunnel ==========|
| |<---RtAdv[HNP_1]-----| | |
| | |<----------data to HNP_1----------|
| |<---data to HNP_1----| |
| | | | |
|- - - MN[if_2] attach MAG_2--------->| (MN-ID, if_2, ...) |
| | | |----------PBU-------->|
| | | | |
| | | (MN-ID, if_2, HNP_3:static prefix)
| | | |<--------PBA----------|
| | | | |
| | | |===== Bi-Dir Tunnel===|
|<-------RtAdv[HNP_3]-----------------| |
| | | | |
| | | (MN-ID, if_2, HNP_2:dynamic prefix)
| | | |<-------*PBA*---------|
|<-------RtAdv[HNP_2]-----------------| |
| | | | |
| | | (MN-ID, if_1, HNP_2:dynamic prefix)
| | |<--------------*PBA*--------------|
| |<---RtAdv[HNP_2]-----| | |
| | | |<----data to HNP3-----|
| |<---data to HNP3-----------------| |
| | | | |
[if_2][if_1]
| Figure 5: Message flow of HHNPA scheme |
After the completion of attachment of the MN through two interfaces, the operations of interface handoff of the MN are as depicted in Figure 6 and Figure 7. As shown in Figure 6, the dynamic prefix HNP_2 is assigned into interface 1. If the MN wants inter-technology handoff, the MN gives some hint of inter-technology handoff to the MAG_2. The MAG_2 which receives hint of inter-technology handoff sends a PBU message with a handoff indicator value of 2 to the LMA. The LMA which receives this PBU message updates the Binding Cache entry filed which is related to dynamic prefix HNP_2. The updated fields of Binding Cache entry are interface and tunnel information. After the completion of updating of Binding Cache entry, the LMA sends data which is relation to HNP_2 to the MAG_2.
+----+
|LMA | LMA BC entry
+----+ (before inter-handoff)
//\\ -----------------
+---------//--\\-------------+ MN:if_1 [HNP_1] --> MAG1
( // \\ PMIPv6 ) MN:if_2 [HNP_3] --> MAG2
( // \\ domain ) MN:if_1 [HNP_2] --> MAG1
+------//--------\\----------+
// \\
// \\ LMA BC entry
+----+ +----+ (after inter-handoff)
|MAG1|-->HNP_2-->|MAG2| -----------------
+----+ +----+ MN:if_1 [HNP_1] --> MAG1
| | MN:if_2 [HNP_3] --> MAG2
| | MN:if_2 [HNP_2] --> MAG2
HNP_1 | if_1 if_2 | HNP_3
+------[MN]------+
| Figure 6: Usage scenario of dynamic prefix in HHNPA scheme |
The HHNPA scheme has advantages of deciding a handoff indication flag. After the LMA assigns static and dynamic home network prefixes to MAGs, if MAG_2 receives handoff hint, MAG_2 checks the existence of the MN_identifier. If the MN_identifier related to the dynamic prefix HNP_2 is exist, the MAG_2 acknowledges that there is a mobility session of inter-technology handoff. So, the MAG_2 can easily determine the value of handoff indication. This operation is depicted in Figure 7.
+----+
|LMA | LMA BC entry
+----+ (before inter-handoff)
//\\ -----------------
+---------//--\\-------------+ MN:if_1 [HNP_1] --> MAG1
( // \\ PMIPv6 ) MN:if_2 [HNP_3] --> MAG2
( // \\ domain ) MN:if_1 [HNP_2] --> MAG1
+------//--------\\----------+
// \\
// \\ Routing table in MAG1
+----+ +----+ -----------------
|MAG1|-->HNP_2-->|MAG2| HNP_1, HNP_2(dynamic) -> MN:if_1
+----+ +----+
| | Routing table in MAG1
| | -----------------
HNP_1 | if_1 if_2 | HNP_3 HNP_3, HNP_2(dynamic) -> MN:if_2
+------[MN]------+
| Figure 7: Setting of handoff indicator flag in HHNPA scheme |
| TOC |
TBD.
| TOC |
This document has no actions for IANA.
| TOC |
| TOC |
| [1] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [2] | Perkins, C., “IP Mobility Support for IPv4,” RFC 3344, August 2002 (TXT). |
| [3] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| [4] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005 (TXT). |
| TOC |
| [5] | Devarapalli, V., Kant, N., Lim, H., and C. Vogt, “Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support-00,” March 2009. |
| [6] | Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, “Issues with network based inter-technology handovers, draft-krishnan-netext-intertech-ps-02,” July 2009. |
| [7] | Jeyatharan, M. and C. Ng, “Multihoming Problem Statement in NetLMM, draft-jeyatharan-netext-multihoming-ps-01,” March 2009. |
| TOC |
| Yong-Geun Hong | |
| ETRI | |
| 161 Gajeong-Dong Yuseung-Gu | |
| Daejeon, 305-700 | |
| Korea | |
| Phone: | +82 42 860 6557 |
| Email: | yonggeun.hong@gmail.com |
| Joo-Sang Youn | |
| DONG-EUI Univ. | |
| Busan, | |
| Korea | |
| Phone: | +82 51 890 1993 |
| Email: | joosang.youn@gmail.com |