| TOC |
|
Proxy Mobile IPv6 (PMIPv6) supports multihoming where a mobile node can connect to a PMIPv6 domain through multiple interfaces for simultaneous access or inter-technology handoff. However, for an inter-technology handoff, PMIPv6 does not allow simultaneous access since all the home network prefixes associated with one interface are delivered to another interface of a mobile node. In addition, if we assume that the flow is classified by home network prefix, then the PMIPv6 cannot support flow mobility since it requires moving just some home network prefixes between interfaces. 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. By using these two different home network prefix models, it can support flow mobility that some home network prefixes are moved to another interface and some home network prefixes are remained at existing interface.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on April 28, 2011.
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 Simplified BSD License.
1.
Introduction
2.
Requirements Language
3.
Problem statement of multihoming support in PMIPv6
4.
Hybrid home network prefix assignment
5.
Security Considerations
6.
IANA Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
§
Authors' Addresses
| TOC |
Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and Mobile IPv4 [RFC3344] (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] (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) [I‑D.devarapalli‑netext‑multi‑interface‑support‑00] (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 and manage a handover event [I‑D.krishnan‑netext‑intertech‑ps] (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 supports 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. If we assume that the flow is classified by home network prefix, then the PMIPv6 cannot support flow mobility since it requires moving just some home network prefixes between interfaces.
Fundamentally, this problem has been caused due to the fact that each of the attached interfaces must be assigned one or more unique prefixes to in PMIPv6. Therefore, to solve 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 after inter-technology handoff, a dynamic home network prefix is used on both interfaces.
| TOC |
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| 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 delivered to 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 (PBU) 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 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 inter-technology
//\\ handoff)
+---------//--\\-------------+ -----------------
( // \\ PMIPv6 ) MN:if_1 [HNP_1] --> MAG1
( // \\ domain ) MN:if_2 [HNP_2] --> MAG2
+------//--------\\----------+
// \\
// \\ LMA BC entry
+----+ +----+ (after inter-technology
|MAG1| |MAG2| handoff)
+----+ +----+ -----------------
| |
| | 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.
First, since the LMA moves the same home network prefix assigned to the first interface 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 [I‑D.devarapalli‑netext‑multi‑interface‑support‑00] (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. If we assume that the flow is classified by home network prefix, then the PMIPv6 cannot support flow mobility since it requires moving just some home network prefixes between interfaces.
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 handoff between interfaces [I‑D.krishnan‑netext‑intertech‑ps] (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 [I‑D.jeyatharan‑netext‑multihoming‑ps] (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, after performing an inter-technology handoff based on the per-MN prefix model, simultaneous access to the PMIPv6 domain is not allowed. If we assume that the flow is classified by home network prefix, then the PMIPv6 cannot support flow mobility since it requires moving just some home network prefixes between interfaces.
If it is able to separate prefix for 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 and it may support flow mobility where some flow related to specific prefix only moved to another interface. 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 static home network prefixes and dynamic home network prefixes. The static home network prefix (based on the per-MN prefix model) is used for simultaneous access. On the other hand, the dynamic home network prefix is employed for only inter-technology handoff.
+--------------------------------+
| |
| +----------------+---------------+
| | | |
| HNP_1 | HNP_2 | HNP_3 |
|(static prefix)|(dynamic prefix)|(static prefix)|
| | | |
| +----------------+---------------+
| | if_2
+--------------------------------+
if_1
| Figure 3: Prefix model in HHNPA |
In the HHNPA, dynamic prefixes are assigned to multiple interfaces and they are switchable between interfaces. But, dynamic prefixes are not used in multiple interfaces simultaneously. At a specific time, the dynamic prefix is activated on only one interface. 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 if_1. After that, the MN is attached the PMIPv6 domain through MAG_2 using if_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 Proxy Binding Acknowledgement (PBA) messages to MAG_1 and MAG_2. The two PBA messages destined to MAG_1 and MAG_2 include 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 inter-technology handoff of the MN are as depicted in Figure 6 and Figure 7. As shown in Figure 6, before inter-technology handoff, the dynamic prefix HNP_2 is activated in if_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. As shown in Figure 6, after inter-technology handoff, the dynamic prefix HNP_2 is activated in if_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 exists in routing table, 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 MAG2
| | -----------------
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 |
If the MN in HHNPA scheme utilizes a logical interface, it can hide the change of network interface from the host IP layer [I‑D.ietf‑netext‑logical‑interface‑support‑00] (Melia, T. and S. Gundavelli, “Logical Interface Support for multi-mode IP Hosts, draft-ietf-netext-logical-interface-support-00 (work in progress),” July 2010.). If one typical application uses dynamic prefixes at the starting time of communication, the session continuity through inter-technology handoff is supported. But, if the typical application uses static prefixes at the starting time of communication, inter-technology handoff is not supported. As described in internet draft [I‑D.hong‑netext‑scenario‑logical‑interface‑00] (Hong, Y. and J. Youn, “Scenarios of the usage of multiple home network prefixes on a logical interface, draft-hong-netext-scenario-logical-interface-00 (work in progress),” July 2010.), if the logical interface supports the change of network interface and also the change of home network prefix (only one home network prefix is shown to IP host stack), the typical application that uses static prefix at the starting time of communication has also session continuity through inter-technology handoff.
| TOC |
TBD.
| TOC |
This document has no actions for IANA.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3344] | Perkins, C., “IP Mobility Support for IPv4,” RFC 3344, August 2002 (TXT). |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC3963] | Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, January 2005 (TXT). |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| TOC |
| [I-D.devarapalli-netext-multi-interface-support-00] | 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. |
| [I-D.hong-netext-scenario-logical-interface-00] | Hong, Y. and J. Youn, “Scenarios of the usage of multiple home network prefixes on a logical interface, draft-hong-netext-scenario-logical-interface-00 (work in progress),” July 2010. |
| [I-D.ietf-netext-logical-interface-support-00] | Melia, T. and S. Gundavelli, “Logical Interface Support for multi-mode IP Hosts, draft-ietf-netext-logical-interface-support-00 (work in progress),” July 2010. |
| [I-D.jeyatharan-netext-multihoming-ps] | Jeyatharan, M. and C. Ng, “Multihoming Problem Statement in NetLMM, draft-jeyatharan-netext-multihoming-ps-01,” March 2009. |
| [I-D.krishnan-netext-intertech-ps] | Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, “Issues with network based inter-technology handovers, draft-krishnan-netext-intertech-ps-02,” July 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 |