Internet DRAFT - draft-hong-netext-hybrid-hnp
draft-hong-netext-hybrid-hnp
Network Working Group Y. Hong
Internet-Draft ETRI
Intended status: Informational J. Youn
Expires: April 28, 2011 DONG-EUI Univ.
October 25, 2010
Hybrid home network prefix for multihoming in PMIPv6
draft-hong-netext-hybrid-hnp-03
Abstract
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.
Status of this Memo
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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Hong & Youn Expires April 28, 2011 [Page 1]
Internet-Draft Hybrid Home Network Prefix October 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement of multihoming support in PMIPv6 . . . . . . 5
4. Hybrid home network prefix assignment . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hong & Youn Expires April 28, 2011 [Page 2]
Internet-Draft Hybrid Home Network Prefix October 2010
1. Introduction
Mobile IPv6 [RFC3775] and Mobile IPv4 [RFC3344] are host based IP
mobility support protocols. On the other hand, Proxy Mobile IPv6
(PMIPv6) [RFC5213] 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]. 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].
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.
Hong & Youn Expires April 28, 2011 [Page 3]
Internet-Draft Hybrid Home Network Prefix October 2010
2. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
Hong & Youn Expires April 28, 2011 [Page 4]
Internet-Draft Hybrid Home Network Prefix October 2010
3. Problem statement of multihoming support in PMIPv6
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.
Hong & Youn Expires April 28, 2011 [Page 5]
Internet-Draft Hybrid Home Network Prefix October 2010
+----+
|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
Hong & Youn Expires April 28, 2011 [Page 6]
Internet-Draft Hybrid Home Network Prefix October 2010
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].
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].
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]. To address these issues, we
propose a hybrid home network prefix assignment scheme in the next
section.
Hong & Youn Expires April 28, 2011 [Page 7]
Internet-Draft Hybrid Home Network Prefix October 2010
4. Hybrid home network prefix assignment
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
Hong & Youn Expires April 28, 2011 [Page 8]
Internet-Draft Hybrid Home Network Prefix October 2010
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).
Hong & Youn Expires April 28, 2011 [Page 9]
Internet-Draft Hybrid Home Network Prefix October 2010
+------+ +-----+ +-----+ +-----+
| 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
Hong & Youn Expires April 28, 2011 [Page 10]
Internet-Draft Hybrid Home Network Prefix October 2010
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.
Hong & Youn Expires April 28, 2011 [Page 11]
Internet-Draft Hybrid Home Network Prefix October 2010
+----+
|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]. 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], 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.
Hong & Youn Expires April 28, 2011 [Page 12]
Internet-Draft Hybrid Home Network Prefix October 2010
5. Security Considerations
TBD.
Hong & Youn Expires April 28, 2011 [Page 13]
Internet-Draft Hybrid Home Network Prefix October 2010
6. IANA Considerations
This document has no actions for IANA.
Hong & Youn Expires April 28, 2011 [Page 14]
Internet-Draft Hybrid Home Network Prefix October 2010
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
7.2. Informative References
[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,
Hong & Youn Expires April 28, 2011 [Page 15]
Internet-Draft Hybrid Home Network Prefix October 2010
draft-krishnan-netext-intertech-ps-02", July 2009.
Hong & Youn Expires April 28, 2011 [Page 16]
Internet-Draft Hybrid Home Network Prefix October 2010
Authors' Addresses
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
Hong & Youn Expires April 28, 2011 [Page 17]
