Network Working Group J. Park
Internet-Draft H. Kim
Intended status: Informational ETRI
Expires: January 13, 2011 July 12, 2010
Multihoming extension of PMIPv6 using 2-level Prefix Model
draft-park-multihoming-ext-pmipv6-2level-prefix-01
Abstract
This document discusses the use of multiple interfaces in mobile
host. Especially, Horizontal handover and flow handover in 2-level
prefix model are resolved.
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 January 13, 2011.
Copyright Notice
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.
Park & Kim Expires January 13, 2011 [Page 1]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Types of handover . . . . . . . . . . . . . . . . . . . . . . 3
3. New 2-level prefix model . . . . . . . . . . . . . . . . . . . 6
4. New 2-level flow identifier model . . . . . . . . . . . . . . 8
5. Usage scenarios for the 2-level prefix model . . . . . . . . . 8
5.1. Scenario 1 - simultaneous attachment . . . . . . . . . . . 8
5.1.1. Initial Stage in scenario 1 . . . . . . . . . . . . . 9
5.1.2. Second Stage in scenario 1 . . . . . . . . . . . . . . 10
5.2. Scenario 2 - Sequential attachment . . . . . . . . . . . . 14
5.2.1. Initial stage in scenario 2 . . . . . . . . . . . . . 14
5.2.2. Second stage in scenario 2 . . . . . . . . . . . . . . 15
5.2.3. Third stage in scenario 2 . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Park & Kim Expires January 13, 2011 [Page 2]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
1. Introduction
Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management
protocol. In here, Mobile Host (MH) does not know the changes of
network access caused by MH movement. That is, Mobile Access
Gateways (MAGs) and Local Mobility Anchors (LMAs) support the whole
mobiltiy management. However, they do not define the protocol
procedures for supporting multiple interfaces and flow handover in
MH.
This document clarifies the types of handover. and describes the
protocol procedures about multihoming extensin of PMIPv6 in 2-level
prefix model.
2. Types of handover
Even though this classification is not common, this document
describes the types of handover to understand the protocol procedures
easily.
o Inter-access Handover (IAHO)
o Inter-interface Handover (IIHO)
o Partial Flow Handover (PFHO)
o Full Flow Handover (FFHO)
First, Inter-access Handover (IAHO) occurs between MAGs. That is,
MN's interface is not changed. The attached MAG is only changed.
Park & Kim Expires January 13, 2011 [Page 3]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
+----+ +----+ LMA Binding Cache (Before)
|LMA | |LMA | -----------------------------
+----+ +----+ MN:if1[HNP_1,flow1] --> MAG1
//\\ //\\
+----//--\\----+ +----//--\\----+ LMA Binding Cache (After)
( // \\ ) ( // \\ ) -----------------------------
( // \\ ) ( // \\ ) MN:if1[HNP_1,flow1] --> MAG2
+-//--------\\-+ +-//--------\\-+
// \\ // \\
// \\ // \\
+----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG1| |MAG2|
+----+ +----+ +----+ +----+
| |
| |
| if1 if2 | if1 if2
+----[MN]---- +----[MN]----
Figure 1: Inter-access Handover(IAHO)
Secondly, Inter-interface Handover (IIHO) considers the MH with
multiple interfaces. IIHO occurs among multiple interfaces in the
same MH. In this case, original interface will be broken by some
reasons. Therefore, all flow under control of original interface
will be moved to the other interface.
The IAHO and IIHO in LMA processing are same in case of the MH with
logical interface. That is, the HNP is assigned to logical interface
only. The MAC address of logical interface is informed to LMA. LMA
does not know the existence of multiple interfaces.
Park & Kim Expires January 13, 2011 [Page 4]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
+----+ +----+ LMA Binding Cache (Before)
|LMA | |LMA | -------------------------
+----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1
//\\ //\\
+----//--\\----+ +----//--\\----+ LMA Binding Cache (After)
( // \\ ) ( // \\ ) -------------------------
( // \\ ) ( // \\ ) MN:if2 [HNP_1,flow1]-->MAG2
+-//--------\\-+ +-//--------\\-+
// \\ // \\
// \\ // \\
+----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG1| |MAG2|
+----+ +----+ +----+ +----+
| |
| |
|flow1 flow1|
+----[MN]---- ----[MN]----+
if1 if2 if1 if2
Figure 2: Inter-interface Handover(IIHO)
Lastly, Paritial and Full Flow Handover (PFHO/FFHO) are used in case
of simulteneous attachment between MAGs in MH with multiple
interfaces. PFHO means partial transfer among application flows.
FFHO means all flow transfer from one interface to the other. The
difference between IIHO and FFHO is the policy of keeping the
mobility session on the original interface. FFHO keeps the mobility
session because of the possibility of reverse flow handover. So,
original information in LMA or MAG will be kept for some time with
idle(I) flag.
In this document, new prefix model will be used to support the flow
handover. The next section will describe in detailss.
Park & Kim Expires January 13, 2011 [Page 5]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
+----+ +----+ LMA Binding Cache (Before)
|LMA | |LMA | -------------------------
+----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1[A]
//\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1[A]
+----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2[A]
( // \\ ) ( // \\ )
( // \\ ) ( // \\ ) LMA Binding Cache (After)
+-//--------\\-+ +-//--------\\-+ -------------------------
// \\ // \\ MN:if1 [HNP_1,flow1]-->MAG1[A]
// \\ // \\ MN:if2 [HNP_1,flow2]-->MAG1[I]
+----+ +----+ +----+ +----+ MN:if2 [HNP_1,flow2]-->MAG2[A]
|MAG1| |MAG2| |MAG1| |MAG2| MN:if2 [HNP_2,flow3]-->MAG2[A]
+----+ +----+ +----+ +----+
| | | |
|flow1 flow3| |flow1 flow3|
|flow2 | | flow2|
+----[MN]-----+ +----[MN]-----+
if1 if2 if1 if2
Figure 3: Partial Flow Handover(PFHO)
+----+ +----+ LMA Binding Cache (Before)
|LMA | |LMA | -------------------------
+----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1[A]
//\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1[A]
+----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2[A]
( // \\ ) ( // \\ )
( // \\ ) ( // \\ ) LMA Binding Cache (After)
+-//--------\\-+ +-//--------\\-+ -------------------------
// \\ // \\ MN:if2 [HNP_1,flow1]-->MAG2[A]
// \\ // \\ MN:if2 [HNP_1,flow2]-->MAG2[A]
+----+ +----+ +----+ +----+ MN:if2 [HNP_2,flow3]-->MAG2[A]
|MAG1| |MAG2| |MAG1| |MAG2| MN:if2 [HNP_1,flow1]-->MAG1[I]
+----+ +----+ +----+ +----+ MN:if2 [HNP_1,flow2]-->MAG1[I]
|flow1 | | flow1| MN:if2 [HNP_2,flow3]-->MAG1[I]
|flow2 | | flow2|
|flow3 | | flow3|
+----[MN]-----+ +----[MN]-----+
if1 if2 if1 if2
Figure 4: Full Flow Handover (FFHO)
3. New 2-level prefix model
This document defines and uses 2-level prefix model like the
following figure. In here, pref_A1 and pref_B1 are called by level 1
Park & Kim Expires January 13, 2011 [Page 6]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
prefix. It is allocated and managed by LMA. Especially, pref_A1 is
a permanent prefix, which is indicated by flag(P). It is used to
support inter-interface and inter-access handover. And logical
interface will use the permanent prefix.
On the other hand, pref_B1 is a temporal prefix, which is indicated
by flag(T). If the distinguished prefix ranges are assigned for
permanet and temporal prefixes in each, these flags may be not
required. It is used to support flow handover. pref_B1 will be
allocated by LMA to MAGs before initiation of mobility session. Each
MAG already knows the other's temporal prefixes. And then, pref_01,
called by level 2 prefix, will be allocated for MH. Pref_01 will be
allocated and managed by each MAG or LMA. Basically MAG is better
for distribution of load for flow management.
+---------+---------+---------+------+
| 2-level | For_LMA | For_MAG | Flag |
+=========+=========+=========+======+
| level 1 | pref_A1 | x | P |
+---------+---------+---------+------+
| level 1 | pref_B1 | - | T |
+---------+---------+---------+------+
| level 2 | pref_B1 | pref_01 | T |
+---------+---------+---------+------+
Figure 5: 2-level Prefix Model
In the following section, HNP_x(P) and HNP_x_y(T) notation will be
used. In here, x means inteface identifer and y means level 2 prefix
identifer and P/T is flag, which distinguishs the prefix. As
mensioned before, P means permanent prefix and T means temporal
prefix. The following examples will be used in this document.
o HNP_1(P) = pref_A1 (e.g., 2002:1:1:0::/64)
o HNP_2(P) = pref_A2 (e.g., 2002:1:2:0::/64)
o HNP_1(T) = pref_B1 (e.g., 2002:2:1:0::/64)
o HNP_2(T) = pref_B2 (e.g., 2002:2:2:0::/64)
o
o HNP_1_1(T) = pref_B1 + pref_01 (e.g.,2002:2:1:1::/64)
o HNP_2_1(T) = pref_B2 + pref_01 (e.g.,2002:2:2:1::/64)
In here, there are 2 types of prefixes: permanet and temporal. The
Park & Kim Expires January 13, 2011 [Page 7]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
permanent prefix without the part of level 2 prefix will be allocated
to the logical interface in order to support inter-technology
handover. If we do not consider the logical interface concept, the
type of services will be checked to use the proper prefix. Even
though the quality of service will be decreased during MH movement,
we do not want to support the handover and flow mobility. In that
case, we will use the permanent prefixes. In other case, we will use
the temporal prefixes.
4. New 2-level flow identifier model
There are 2 types of flow identifier(FID). These flow ids are
managed separately in MN, MAG and LMA. That is,the uniqueness of
flow ids are satified just in each node.
o Input FID (IFID) = level-1 flow id(IFID1) + level-2 flow id(IFID2)
or none
o output FID(OFID) = level-1 flow id(OFID1) + level-2 flow id(OFID2)
or none
After PBU and PBA exchange, level-1 input flow ids are exchanged
between MAGs and LMA. And then, level-2 flow ids are allocated
according to emerging each data flow. After the receiving RA
messages, MH gets level-1 flow id from MAG. On the other hand, MAG
makes level-1 flow id after the recognizing L2 attachment or the
first data receiving form MH. And then level-2 flow ids are
allocated during the data transmission.
MH decides anf forwards the data from logical interface to physical
interfaces by referring flow ids. And then, MAG and LMA just decides
and forwards the service flow by using ouput flow ids.
5. Usage scenarios for the 2-level prefix model
This document considers the MH with multiple interfaces, each
interface of whose has multiple prefixes. This section describes the
simultaneous use and horizontal handover in 2-level prefix model.
5.1. Scenario 1 - simultaneous attachment
This scenario considers the nearly same attachment of multiple
interfaces.
Park & Kim Expires January 13, 2011 [Page 8]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
5.1.1. Initial Stage in scenario 1
Initial attachment procedures of each interface are operated
independently. The following functions will be performed between MH
and MAG or between MAG and LMA.
o The mobility session for all interfaces in MH
o Prefix allocation and maintenance in LMA and MAG
o Flow id generation and Distribution in LMA
LMA State
+----+ ---------
|LMA | MH:if1 [HNP_1(P),flow1,flow2] --> MAG1
+----+ MH:if2 [HNP_2(P),flow3] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+ MAG2 State
|MAG1| |MAG2| ----------
+----+ +----+ MH: if2[HNP_2(P),flow3]-->MAG2
| | MH: if2[HNP_2(T)] -->MAG2
| | MH: if2[HNP_2_1(T)] -->MAG2
| |
| | MAG1 State
| if1 if2 | ----------
+-----+-----+-----+ MH: if1[HNP_1(P),flow1,flow2] -->MAG1
| MH | MH: if1[HNP_1(T)] -->MAG1
+--+--+ MH: if1[HNP_1_1(T),HNP_1_2(T)]-->MAG1
|
|
|vi [HNP_1(P) or HNP_2(P)]
Figure 6: Scenario 1 - Initial Stage
The initial attach procedures are following:
1. The if1 will be attached the network through MAG1.
Park & Kim Expires January 13, 2011 [Page 9]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
2. MAG1 sends the PBU to the LMA. In here, HI option is 1 (initial
attachment).
3. LMA allocates the HNP_1(P) for if1 of MH. LMA sends PBA with
HNP_1(P) option.
4. MAG1 sends RA message with HNP_1(P) and HNP_1_1(T). In here,
HNP_1(P) has been obtained from PBA message. HNP_1_1(T) will be
allocated by MAG1 using HNP_1(T) prefix, which had been
distributed from LMA.
5. MH configures the HNP_1(P) and HNP_1_1(T) to the if1.
6. The if2 also does the above procedures. After then, MH
configures the HNP_2(P) and HNP_2_1(T) to the if2.
7. MH allocates HNP Address for logical Interface (LI). HNP_1(P) or
HNP_2(P) is randomly selected. In here, we suppose that HNP_1(P)
was selected.
8. Application services will be started. For example, VoIP and web
services have been started through if1. IPTV service has been
also started through if2. In here, VoIP service has been
assigned to flow1 by LMA. The flow1 is flow identifier for VoIP
service. flow2 for web service and flow3 for IPTV service is also
assigned by LMA.
9. If we have the policy that only LI has the HNPs, the procedure 5
and 6 are not required. And the HNP assigend in LI is shown to
all application services.
5.1.2. Second Stage in scenario 1
After initial stage, the following handover will be occured in
according to network changes or user requirement.
o Inter-access Handover from MAG1 to MAG2
* MH: if1 is attached to network through the MAG2.
* MAG1: After receiving L2 hints, new tunnel may be configured
between MAG1 and MAG2. This tunnel is used to transfer the
data, which are targeted to if1 through MAG1.
* MAG2: MAG2 sends PBU with HI(3) to the LMA.
* LMA: After receiving the PBU with HNP_1(P), all MAG1-related
entries will be changed to the MAG22. In addtion, LMA sends
Park & Kim Expires January 13, 2011 [Page 10]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
the PBA to MAG2 with HNP_1(P).
* MAG2: After receiving the PBA, new BULE with if1 will be added.
o Inter-interface Handover from if1 and if2
* MH: No action.
* MAG1: After receiving L2 hints, new tunnel may be configured
between MAG1 and MAG2. This tunnel is used to transfer the
data, which are targeted to if1 through MAG1.
* MAG2: MAG2 sends PBU with HI(2) to the LMA.
* LMA: After receiving the PBU with HNP_1(P) from MAG2, all MAG1-
related entries will be changed to the MAG2. LMA sends the PBA
with HNP_1(P).
* MAG2: After receiving the PBA, new BULE with HNP_1(P) will be
added.
Park & Kim Expires January 13, 2011 [Page 11]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
LMA State (Before)
---------
MH:if1 [HNP_1(P),HNP_1(T)]--> MAG1
MH:if2 [HNP_2(P),HNP_2(T)]--> MAG2
LMA State (After)
---------
MH:if1 [HNP_1(P),HNP_1(T)] --> MAG1
MH:if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1
MH:if2 [HNP_2(P),HNP_2(T)] --> MAG2
MH:if2 [HNP_2_1(T),HNP_2_2(T)]--> MAG2
+----+
|LMA |
+----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG2 State (Before)
+----+ +----+ ----------
|MAG1| |MAG2| MH: if2[HNP_2(P)] -->MAG2
+----+ +----+ MH: if2[HNP_2_1(T)]-->MAG2
| |
| | MAG2 State (After)
| | ----------
| | MH: if2[HNP_2(P)] -->MAG2
| | MH: if2[HNP_2_1(T)]-->MAG2
| | MH: if2[HNP_1_2(T)]-->MAG2
| if1 if2 |
+-----+-----+-----+ MAG1 State (Before)
| MH | ----------
+--+--+ MH: if1[HNP_1(P)] -->MAG1
| MH: if1[HNP_1_1(T),HNP_1_2(T)]-->MAG1
|vi
MAG1 State (After)
----------
MH: if1[HNP_1(P)] -->MAG1
MH: if1[HNP_1_1(T)] -->MAG1
MH: if1[HNP_1_2(T)] -->MAG1[Idle]
Figure 7: Scenario 1 - Second Stage: PFHO
Park & Kim Expires January 13, 2011 [Page 12]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
o Partial Flow Handover using temporal prefixes
* MH: VoIP service is using HNP_1_1(T) as flow identifier.
HNP_1_2(T) for Web service and HNP_2_1(T) for IPTV service are
used. In this scenario, Web service will be transfered from
if1 and if2.
* MAG1: After receiving the L2 hints, MAG1 and MAG2 know the user
requirement about the partial flow handover.
* MAG2: MAG2 sends the PBU with HI(5). In addition, PBU has a
HNP option. In HNP option, HNP_1_2(T) will be included in
order to inform the flow handover.
* LMA: After receiving the PBU(HI=5) with HNP option, LMA updates
the BCE using HNP option. That is, LMA knows the change of web
service flow.
* MAG2: After receiving the PBA, MAG2's BULE will be changed.
o Full Flow Handover using temporal prefixes
* MH: HNP_1_1(T) for VoIP service, HNP_1_2(T) for Web service and
HNP_2_1(T) for IPTV service are used as the flow identifier.
In this scenario, all services from if1 will be transferred to
if2.
* MAG1: After receiving the L2 hints, MAG1 and MAG2 maybe know
the user requirement about the full flow handover.
* MAG2: MAG2 sends the PBU with HI(5). In addition, PBU has the
HNP options. In HNP options, HNP_1_1(T) and HNP_1_2(T) will be
included in order to inform the full flow handover. In here,
the aggregated HNP_1(T) for HNP_1_1(T) and HNP_1_2(T) will be
included in PBU.
* LMA: After receiving the PBU(HI=5) with HNP options, LMA
updates the BCE using HNP options. That is, LMA knows the
transfer of all service flows. In this case, original mobility
session for if1 will be kept in order to support the reverse
partial or full flow handover.
* MAG2: After receiving the PBA, MAG2's BULE will be changed.
Park & Kim Expires January 13, 2011 [Page 13]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
5.2. Scenario 2 - Sequential attachment
This scenario considers the sequential attachment of multiple
interfaces in MH.
5.2.1. Initial stage in scenario 2
A interface will be attached to the network. The following functions
will be performed between MH and MAG and LMA.
o The mobility session for one interface
o Prefix Allocation and Maintenance in LMA and MAG
o Flow id Generation and Distribution in LMA
LMA State
+----+ ---------
|LMA | MH:if1 [HNP_1(P),flow1,flow2] --> MAG1
+----+
//
+---------//-----------------+
( // ) PMIPv6 domain
( // )
+------//--------------------+
//
//
+----+ +----+ MAG2 State
|MAG1| |MAG2| ----------
+----+ +----+
| |
| |
| | MAG1 State
| if1 if2 | ----------
+-----+-----+-----+ MH: if1 [HNP_1(P),flow1,flow2] --> MAG1
| MH | MH: if1 [HNP_1(T)] --> MAG1
+--+--+ MH: if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1
|
|vi [HNP_1(P)]
Figure 8: Scenario 2 - Initial Stage
TBD.
Park & Kim Expires January 13, 2011 [Page 14]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
5.2.2. Second stage in scenario 2
After initial stage, the other interfaces will be attached to the
network. The following functions will be performed between MH and
MAG and LMA.
o Initial attachment of the other interface
o Inter-access Handover
o Partial Flow Handover
o Full Flow Handover
LMA State
---------
MH:if1 [HNP_1(P),flow1,flow2]--> MAG1
+----+ MH:if1 [HNP_1(T)] --> MAG1
|LMA | MH:if2 [HNP_1(P),flow3] --> MAG2
+----+ MH:if2 [HNP_2(T)] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+ MAG2 State
|MAG1| |MAG2| ----------
+----+ +----+ MH: if2 [HNP_1(P),flow3]--> MAG2
| | MH: if2 [HNP_2(T)] --> MAG2
| | MH: if2 [HNP_2_1(T)] --> MAG2
| |
| | MAG1 State
| if1 if2 | ----------
+-----+-----+-----+ MH: if1 [HNP_1(P),flow1,flow2] --> MAG1
| MH | MH: if1 [HNP_1(T)] --> MAG1
+--+--+ MH: if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1
|
|vi [HNP_1(P)]
Figure 9: Scenario 2 - Second Stage
TBD.
Park & Kim Expires January 13, 2011 [Page 15]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
5.2.3. Third stage in scenario 2
After second stage, Inter-interface handover will be occurred
generally. The other functions will be same alike that of the second
state.
o Inter-access Handover
o Inter-interface Handover
o Partial Flow Handover
o Full Flow Handover
TBD.
6. IANA Considerations
IANA considerations are not required.
7. Security Considerations
TBD.
8. References
8.1. Normative References
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[4] Devarapalli, V., "Multiple Interface Support with Proxy Mobile
IPv6, draft-devarapalli-netlmm-multihoming-03 (work in
progress)", August 2008.
[5] Jeyatharan, M. and C. Ng, "Multihoming Problem Statement in
NetLMM, draft-jeyatharan-netext-multihoming-ps-01 (work in
Park & Kim Expires January 13, 2011 [Page 16]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
progress)", 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 (work in progress)",
July 2009.
[7] Tran, T. and Y. Hong, "Virtual interface for supporting
multihoming and inter technology handover,
draft-trung-netext-virtual-interface-01 (work in progress)",
October 2009.
[8] Hong, Y. and J. Youn, "Virtual network interface model for
multiple network interfaces in a host,
draft-hong-netext-dynamic-hnp-00 (work in progress)",
February 2010.
[9] Sarikaya, B. and F. Xia, "Local Mobility Anchor Initiated Flow
Binding for Proxy Mobile IPv6,
draft-sarikaya-netext-lma-init-flow-binding-00 (work in
progress)", February 2010.
[10] Xia, F., "Flow Binding in Proxy Mobile
IPv6,draft-xia-netext-flow-binding-00 (work in progress)",
February 2009.
[11] Sarikaya, B. and F. Xia, "PMIPv6 Multihoming Support for Flow
Mobility, draft-sarikaya-netext-fb-support-extensions-00 (work
in progress)", February 2010.
[12] IEEE Std 802.11r-2008, "IEEE Std Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications
Amendment 2: Fast Basic Service Set (BSS) Transition",
July 2008.
Authors' Addresses
Jungsoo Park
ETRI/SRC
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-700
Korea
Phone: +82 42 860 6514
Email: fnumber@gmail.com
Park & Kim Expires January 13, 2011 [Page 17]
Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010
HyeongJun Kim
ETRI/SRC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6576
Email: khj@etri.re.kr
Park & Kim Expires January 13, 2011 [Page 18]