NetExt Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Standards Track Panasonic
Expires: September 5, 2009 S. Gundavelli
K. Leung
Cisco
V. Devarapalli
Wichorus
March 4, 2009
Partial Handoff Support in PMIPv6
draft-jeyatharan-netext-pmip-partial-handoff-00
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 September 5, 2009.
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.
Jeyatharan, et al. Expires September 5, 2009 [Page 1]
Internet-Draft Partial handoff March 2009
Abstract
Proxy Mobile IPv6 (PMIPv6) only supports session continuity for one
basic scenario of vertical handoff -- the transfer of all prefixes
assigned from one interface to another. However, there are some
other advanced scenarios associated with vertical handoff that
involves only transferring one (or some, but not all) of the prefixes
that are allocated to an existing interface to a newly powered on
interface. This draft outlines extensions to PMIPv6 protocol in
order for a multiple interfaced mobile node to achieve such partial
vertical handoff of selected prefix(es).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases for Partial Handoff . . . . . . . . . . . . . . . . 4
3. Overview of Partial Handoff . . . . . . . . . . . . . . . . . 6
3.1. Partial Handoff to a New Interface . . . . . . . . . . . . 6
3.2. Partial Handoff to an Existing Interface . . . . . . . . . 8
3.3. Partial Handoff after Shutting Down an Interface . . . . . 10
4. Signaling Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. Mobile Access Gateway Operation . . . . . . . . . . . . . 12
4.2. Local Mobility Anchor Operation . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Jeyatharan, et al. Expires September 5, 2009 [Page 2]
Internet-Draft Partial handoff March 2009
1. Introduction
Inter-access technology handoff is performed in various environments
and is one of the important handoff events in many standards
development organizations, including the Third Generation Partnership
Project (3GPP) mobility environment. In a generic sense, vertical
handoff refers to handing off of flows from one interface to another
interface. The most well known basic scenario associated with
vertical handoff is the shutting down of an interface and transfer of
flows from the shut down interface to a newly powered on interface.
The Proxy Mobile IPv6 protocol (RFC-5213 [1]) allows a mobile node to
perform a handoff by moving its address configuration from one
interface to the other. The mobile access gateway attached to the
access link where the mobile node is attached will provide this
handoff hint to the local mobility anchor and the local mobility
anchor will assign the same IPv6 home network prefix(es) and IPv4
home address to the currently attached interface that it previously
assigned to the other interface prior to the handoff. This handoff
will result in local mobility anchor changing the mobile node's IPv6
home network prefixes and the IPv4 home address association from one
interface to a different interface and also the resulting data path
adjustment.
There can be many reasons for a mobile node (MN) to perform such
basic vertical handoff. It can be due to discovery of a preferred
access technology type that can give cheaper services or the need to
transfer existing flows to the newly discovered access technology
type to achieve better quality of service (QoS) to the existing
flows. All mobility protocols has a requirement to support session
continuity in such vertical handoff scenarios. For example, in
Mobile IPv6 [3], a mobile node can send a binding update to the home
agent via its newly powered on interface using the same home address
used for the shut down interface in order to achieve vertical
handoff. PMIPv6 [1] incorporates a network based session continuity
mechanism to support the basic vertical handoff scenario. This
mechanism is such that all the home network prefixes associated with
the shut down interface are permanently transferred to the newly
powered on interface, when appropriate vertical Handoff Indicator is
inserted in the Proxy Binding Update (PBU) mobility signaling.
In PMIPv6, when the mobile node shuts down an interface and performs
a vertical handoff, the mobile access gateway (MAG) which the mobile
node attaches to using the newly powered on interface will send a
Proxy Binding Update with a Handoff Indication (HI) option that has a
value of "2". When the local mobility anchor (LMA) receives the
proxy binding update message, it will transfer all the prefixes
previously assigned to the shut down interface to the newly powered
Jeyatharan, et al. Expires September 5, 2009 [Page 3]
Internet-Draft Partial handoff March 2009
on interface.
However, there are other vertical handoff scenarios such as
transferring a subset of prefixes from one interface to an alternate
interface. A basic introduction to such requirement of transferring
a subset of prefixes is given in ID-NETEXT-MULTI-PS [4]. Such
selective transfers of one or more prefixes to a new interface (which
we call a "partial vertical handoff", or simply "partial handoff")
can take place due to mobile node's preference or network operations
for load balancing purposes. In this draft, we highlight some use
cases as given in Section 2 that are associated with the mobile node
triggering such partial vertical handoff from a given interface to an
alternate interface. In order to achieve this, we proposes a few
minor protocol extensions to RFC 5213. This is described in
Section 3 and Section 4.
2. Use Cases for Partial Handoff
Here, some use cases for partial vertical handoff are described in
three different scenarios:
o Partial Handoff to a New Interface
The mobile node could be initially attached to the PMIPv6 domain
via a cellular interface and at a later time may identify a
wireless local area network (WLAN). In such an event, the mobile
node may want only flows associated with a subset of prefixes that
are best suited to the WLAN access technology type (example video
flows) to be transferred to the WLAN interface when the mobile
node attaches to the WLAN. In general, the mobile node may want
the flows associated with a subset of prefixes to be transferred
to the newly powered on interface, due to less cost via the access
technology type, higher bandwidth provided, user preference, load
balancing purpose and/or better QoS. If the mobile node cannot
achieve flows tied to a certain group of prefixes to be
transferred via a preferred access technology in PMIPv6 domain, it
will impact on end user requirements and end user service
experience. Furthermore, if such partial transfer of prefixes is
not supported, the network unnecessarily needs to assign new
prefix for the newly powered on interface and maintain mobility
state for this prefix by means of Proxy Binding Update signaling.
o Partial Handoff to an Existing Interface
In another multihoming scenario in PMIPv6 domain, a mobile node
may already be simultaneously attached to the network via multiple
interfaces (e.g. via cellular and WLAN). In such scenario, due to
Jeyatharan, et al. Expires September 5, 2009 [Page 4]
Internet-Draft Partial handoff March 2009
either load balancing reason or to achieve better performance for
flows via an interface, the mobile node may trigger partial
handoff of a subset of prefixes from one connected interface to
another connected interface. In ID-MEXT-FLOW-BIND [5], there is
provided a mechanism for flow mobility in the granularity of a
single data connection. However in this draft, we refer to flow
mobility in the granularity of prefixes. If 3G access network is
congested, the mobile node may want to keep the prefixes
associated with flows that are ideal via 3G (e.g. Voice over IP)
and transfer other prefixes associated with other type of flows to
the WLAN access. Alternatively, if the access network is getting
congested, for load balancing purpose, the mobile node may assist
the network in identifying the flows that can be transferred to
another access technology without impacting on end user service
satisfaction.
o Partial Handoff from a Shut Down Interface
In some cases, a mobile node may shut down an interface and
transfer only a subset of prefixes and the associated flows to a
new interface or an existing interface. The use case to support
such a scenario is when the mobile node discovers that session
continuity for certain prefixes by means of PMIPv6 mobility
management mechanism is not required via the alternate interface.
This may be due to one or more prefixes are no longer being used,
or session continuity for one or more prefixes is not required
(e.g. only use for web browsing).
We note that in most of these use cases, the decision to perform a
partial handoff is purely based on mobile node's preference -- it
could be due to consideration on cost, quality of service, available
bandwidth and the types of flows associated with each prefix that the
mobile node is currently assigned.
Jeyatharan, et al. Expires September 5, 2009 [Page 5]
Internet-Draft Partial handoff March 2009
3. Overview of Partial Handoff
In this section, the partial handoff protocol operation is described
for three different advanced vertical handoff scenarios mentioned in
Section 2. We start off by first considering the initial scenario as
illustrated in Figure 1, where the a mobile node MN with two
interfaces IF1 (for 3G access) and IF2 (for WLAN access) is connected
to the PMIPv6 domain. Initially, the mobile node has only interface
IF1 connected to the PMIPv6 network, which is assigned with 3
prefixes: P1, P2 and P3. The binding cache entry created at the
local mobility anchor LMA for IF1 is shown by the first entry in
binding cache, which contains the home network prefixes, the proxy
care-of address, the network access identifier of mobile node, the
link layer identifier of the interface and the access technology
type.
+---------+ Binding Cache of LMA
| LMA | +------------+-----------+-------+-------+------+
| | | HNP | Proxy CoA | MN-ID | LL-ID | ATT |
+---------+ +------------+-----------+-------+-------+------+
/ \ | P1, P2, P3 | MAG1 addr | NAI | IF1 | ATT1 |
/ \ +------------+-----------+-------+-------+------+
/ \
/ \
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\
\
IF1(3G) \ / IF2(WLAN)
+--------+
| MN |
+--------+
Figure 1: Initial Scenario
3.1. Partial Handoff to a New Interface
After some time, the mobile node detects the availability of WLAN
access and wants to transfer all flows associated with P2 prefix to
the WLAN interface IF2. Figure 2 describes the partial handoff
process to achieve this.
Jeyatharan, et al. Expires September 5, 2009 [Page 6]
Internet-Draft Partial handoff March 2009
+-----+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +------------+ +-----+
| | | |
|<-- RA(P1,P2,P3) --| | |
| | | |
MN discoveres WLAN and decides | |
to transfer P2 to WLAN | |
| | | |
|------ L2 Attach & trigger for ----->| |
| transferring P2 | |
| | |--PBU(P2,HI=IANA-1)-->|
| | | |
| | |<--PBA(P2,HI=IANA-1)--|
|<-------------- RA(P2) --------------| |
| | |<=== Tunnel Est. ====>|
| |<-- Remove P2 | |
|<---- RA(P1,P3) ---| | |
Figure 2: Message Sequence for Partial Handoff to a New Interface
In Figure 2, mobile access gateway MAG1 initially advertises the
three prefixes P1, P2, and P3 that are assigned to IF1 of the mobile
node. When the mobile node MN detects the availability of WLAN
access, it wishes to transfer the flows associated with prefix P2 to
WLAN access. When the mobile node starts the first attachment via
IF2, it will trigger a layer 2 (L2) attach message to MAG2 by means
of access technology specific signaling. At the same time, the
mobile node will inform MAG2 on the partial handoff of the prefix P2.
How this is carried out is layer two specific and out of scope of
this draft (as an example, the trigger may be embedded in the attach
message, or sent by means of a new layer 2 message).
When MAG2 receives the trigger for transfer of P2 from the mobile
node, it will send a Proxy Binding Update message to the local
mobility anchor with P2 in the Home Network Prefix option and a new
value IANA-1 for the Handoff Indicator option. This new Handoff
Indicator value IANA-1 indicates that this is a partial handoff to a
new interface. When the local mobility anchor receives this Proxy
Binding Update message, it will perform the following actions. The
local mobility anchor will first locate an existing binding cache
entry for mobile node with home network prefix P2. If the entry is
present, the local mobility anchor will remove the prefix P2 from
this entry, and create a new binding entry for interface IF2 with
address of MAG2 as the proxy care-of address.
Jeyatharan, et al. Expires September 5, 2009 [Page 7]
Internet-Draft Partial handoff March 2009
MAG1 should also be informed to stop proxying for the prefix P2.
This can be done by LMA sending a remove P2 notification to MAG1
(such as through the use of binding revocation [6]) or by MAG2
through the use of context transfer signalling between MAG1 and MAG2.
After the partial handoff is completed, the new binding cache entry
created for IF2 will have P2 assigned and the binding cache entry for
IF1 will have prefixes P1 and P3 assigned. This is shown in
Figure 3.
Binding Cache of LMA
+---------+ +------------+-----------+-------+-------+------+
| LMA | | HNP | Proxy CoA | MN-ID | LL-ID | ATT |
| | +------------+-----------+-------+-------+------+
+---------+ | P1, P3 | MAG1 addr | NAI | IF1 | ATT1 |
/ \ +------------+-----------+-------+-------+------+
/ \ | P2 | MAG2 addr | NAI | IF2 | ATT2 |
/ \ +------------+-----------+-------+-------+------+
/ \
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\ /
\ /
IF1(3G) \ / IF2(WLAN)
+--------+
| MN |
+--------+
Figure 3: After Partial Handoff of P3
3.2. Partial Handoff to an Existing Interface
After a while, the mobile node finds that the bandwidth in WLAN is
quite under-utilized, and decides to transfer flows associated with
prefix P3 from IF1 (cellular) to IF2 (WLAN) as well.
Jeyatharan, et al. Expires September 5, 2009 [Page 8]
Internet-Draft Partial handoff March 2009
+-----+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +------------+ +-----+
| | | |
|<-------------- RA(P2) --------------| |
|<---- RA(P1,P3) ---| | |
| | | |
MN decides to transfer | | |
P3 to WLAN as well | | |
| | | |
|--------- L2 trigger for ----------->| |
| transferring P3 | |
| | |--PBU(P3,HI=IANA-2)-->|
| | | |
| | |<--PBA(P3,HI=IANA-2)--|
|<------------ RA(P2,P3) -------------| |
| |<-- Remove P3 | |
|<----- RA(P1) -----| | |
Figure 4: Message Sequence for Partial Handoff to a New Interface
Figure 4 shows the partial handoff of P3. As before, the mobile node
sends a L2 trigger to the mobile access gateway MAG2 to request a
transfer of prefix P3. MAG2 then sends a Proxy Binding Update
message containing prefix P3 and Handoff Indicator value of IANA-2 to
initiate the partial handoff of P3. This new HI value IANA-2
indicates that this is a partial handoff to an existing interface.
Once the local mobility anchor receives this Proxy Binding Update
message, it locates the existing binding cache entry for the mobile
node with home network prefix P3 and removes P3 from this binding
cache entry. Instead of creating a new entry for P3 (as is the case
when handoff indicator is IANA-1), the local mobility anchor adds P3
to the binding cache entry for MAG2. MAG1 will also be notified that
P3 is no longer assigned to IF1. The resulting binding cache is
shown in Figure 5.
Jeyatharan, et al. Expires September 5, 2009 [Page 9]
Internet-Draft Partial handoff March 2009
Binding Cache of LMA
+---------+ +------------+-----------+-------+-------+------+
| LMA | | HNP | Proxy CoA | MN-ID | LL-ID | ATT |
| | +------------+-----------+-------+-------+------+
+---------+ | P1 | MAG1 addr | NAI | IF1 | ATT1 |
/ \ +------------+-----------+-------+-------+------+
/ \ | P2, P3 | MAG2 addr | NAI | IF2 | ATT2 |
/ \ +------------+-----------+-------+-------+------+
/ \
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\ /
\ /
IF1(3G) \ / IF2(WLAN)
+--------+
| MN |
+--------+
Figure 5: After Partial Handoff of P3
3.3. Partial Handoff after Shutting Down an Interface
After a while, the mobile node finishes all the sessions associated
with prefix P3 (i.e. P3 is now unused). When the mobile node roams
out of the coverage of WLAN, instead of performing a normal vertical
handoff, it chooses to perform a partial vertical handoff to release
P3.
+-----+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +------------+ +-----+
| | | |
|<------------ RA(P2,P3) -------------| |
|<----- RA(P1) -----| | |
| | | |
MN roams out of WLAN | | |
| | | |
|--- L2 trigger --->| | |
|for transferring P2| | |
| |----------- PBU(P2,HI=IANA-2) --------->|
| | | |
| |<---------- PBA(P2,HI=IANA-2) ----------|
|<--- RA(P1,P2) ----| | |
Figure 6: Message Sequence for Partial Handoff after Shutting Down an
Jeyatharan, et al. Expires September 5, 2009 [Page 10]
Internet-Draft Partial handoff March 2009
Interface
Figure 6 shows the partial handoff of P2. As before, the mobile node
sends a layer 2 trigger to MAG1 to request a transfer of prefix P2.
MAG1 then sends a Proxy Binding Update message containing prefix P2
and Handoff Indicator value of IANA-2 to initiate the partial handoff
of P2. Once the local mobility anchor receives this Proxy Binding
Update message, it adds prefix P2 to the binding cache entry for
MAG1. The resulting binding cache is shown in Figure 7.
+---------+ Binding Cache of LMA
| LMA | +------------+-----------+-------+-------+------+
| | | HNP | Proxy CoA | MN-ID | LL-ID | ATT |
+---------+ +------------+-----------+-------+-------+------+
/ \ | P1, P2 | MAG1 addr | NAI | IF1 | ATT1 |
/ \ +------------+-----------+-------+-------+------+
/ \
/ \
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\
\
IF1(3G) \ / IF2(WLAN)
+--------+
| MN |
+--------+
Figure 7: After Partial Handoff of P2
Jeyatharan, et al. Expires September 5, 2009 [Page 11]
Internet-Draft Partial handoff March 2009
4. Signaling Considerations
For supporting Partial Handoff feature, this specification defines
two new Handoff Indicator values to be used in the Handoff Indicator
option [1] carried in Proxy Binding Update and Proxy Binding
Acknowledgement messages. Additionally, this specification defines
the following considerations for the local mobility anchor and the
mobile access gateway when using these Handoff Indicator values.
4.1. Mobile Access Gateway Operation
The mobile access gateway when sending a Proxy Binding Update message
to the local mobility anchor MUST follow the considerations specified
in RFC5213 [1] and ID-PMIP-IPv4 [2]. However, if the request is for
partial handoff support, the following additional considerations MUST
be applied.
o The specifics on how the mobile access gateway determines when to
request partial handoff support, or how it learns what prefixes it
chooses to handoff is out side the scope of this document. These
triggers can be from any of the following:
* In most cellular networks, handovers are controlled and the
network provides the details to the mobile access gateway on
what specific addresses or prefixes it needs to handover.
* As part of the context transfer procedure initiated by the
other mobile access gateway where the mobile node is currently
attached over a different interface, the serving mobile access
gateway can derive the partial handoff trigger.
* A layer-2 trigger originating directly from the mobile node to
the mobile access gateway on the list of prefixes or addresses
it chooses to handoff from one interface to a different
interface.
o The mobile access gateway MUST apply the below considerations when
choosing the value for the Handoff Indicator field.
* The Handoff Indicator field MUST be set to a value of IANA-1
(Partial handoff to a newly attached interface), if the handoff
is for moving addresses/prefixes from an existing attached
interface of a mobile node to a newly attached interface.
* The Handoff Indicator field MUST be set to a value of IANA-2
(Partial handoff to an existing attached interface), if the
handoff is for moving addresses/prefixes between two mobile
Jeyatharan, et al. Expires September 5, 2009 [Page 12]
Internet-Draft Partial handoff March 2009
node's attached interfaces, for each of which there is a
Binding Cache entry at the local mobility anchor.
* The mobile access gateway can initiate Partial Handoff request
(handoff value set to either IANA-1 or IANA-2), only if it is
certain that the mobile node is aware of this partial handoff
and has removed the addresses associated with these prefixes
that are being handed off from the other interface. Otherwise,
it MUST NOT initiate partial handoff request.
o When sending a Proxy Binding Update for initiating Partial Handoff
request (Handoff Indicator field value set to a value of IANA-1 or
IANA-2), the mobile access gateway MUST include exactly one Home
Network Prefix option for each of the prefixes that are being
handed to the current mobile node's interface attachment.
o On receiving a Proxy Binding Acknowledgement message with the
Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST check the Handoff Indicator value
specified in the Handoff Indicator option.
* If the value in the option equals to IANA-1, the mobile access
gateway MUST create a Binding Update List entry for the mobile
node.
* If the value in the option equals to IANA-2, the mobile access
gateway MUST add the prefix(es) specified in each of the Home
Network Prefix options to the mobile node's Binding Update List
entry
* The mobile access gateway MUST host each of the prefixes listed
in the Home Network Prefix option(s), as on-link prefixes on
the access link attached to the mobile node. It MUST include
these prefixes in the Router Advertisements that it sends to
the mobile node on that access link.
* The mobile access gateway MUST enable routing for the traffic
with the sources address of the packet set to these prefixes
over the tunnel established with the local mobility anchor
Jeyatharan, et al. Expires September 5, 2009 [Page 13]
Internet-Draft Partial handoff March 2009
4.2. Local Mobility Anchor Operation
The local mobility anchor on receiving a Proxy Binding Update message
from the mobile access gateway MUST follow the considerations
specified in RFC5213 [1] and ID-PMIP-IPv4 [2]. However, if the
request is for partial handoff support, the following additional
considerations MUST be applied.
o If the value in the Handoff Indicator option is set to a value of
IANA-1, the local mobility anchor MUST consider this request as a
request for handoff of addresses/prefixes from one of the mobile
node's mobility session for which there is an active Binding Cache
entry to a new mobility session yet to be created and associated
with the current mobile node's interface attachment.
o If the value in the Handoff Indicator option is set to a value of
IANA-2, the local mobility anchor MUST consider this request as a
request for partial handoff of addresses/prefixes between two
existing mobile node's mobility sessions for which there are
existing Binding Cache entries.
o The prefix(es) identified in the Home Network Prefix option(s)
present in the request MUST be used for performing the Binding
Cache entry lookup test . Considerations specified in Section
5.4.1.1 of [RFC-5213] MUST be applied for performing this Binding
Cache entry existence test. If those checks specified in Section
5.4.1.1 result in associating the request to an existing mobility
session, the local mobility anchor upon accepting the request MUST
use this as a source mobility session for shifting the identified
prefixes to the target mobility session. However, if there is no
existing Binding Cache entry containing the identified prefixes,
the local mobility anchor MUST send a response with a Proxy
Binding Acknowledgement message with the Status code of "155 -
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX".
o If the value in the Handoff Indicator option is set to a value of
IANA-1, the local mobility anchor upon accepting the request MUST
create a new Binding Cache entry and associate the request with
the current mobile node's interface attachment. The local
mobility anchor MUST use this as a target mobility session for
shifting the identified prefixes.
o If the value in the Handoff Indicator option is set to a value of
IANA-2, the local mobility anchor MUST use either the Mobile
Node's Interface Identifier option (if present) or the Proxy
Care-of address of the current mobile access gateway that sent the
request for performing Binding Cache entry lookup. The local
mobility anchor MUST use this as a target mobility session for
Jeyatharan, et al. Expires September 5, 2009 [Page 14]
Internet-Draft Partial handoff March 2009
shifting the identified prefixes.
o Upon performing the Partial handoff, the local mobility anchor
MUST update the routes for forwarding the traffic to the current
mobile access gateway that sent the request.
o Upon accepting the request, the local mobility anchor SHOULD send
a a Proxy Binding Acknowledgement message with a successful status
code. The Proxy Binding Acknowledgement message MUST also contain
the same Handoff Indicator option as in the corresponding Proxy
Binding Update message.
5. IANA Considerations
This draft introduces two new Handoff Indicator values that would
require IANA assignment. These values needs to be assigned from the
same numbering space as allocated for the Handoff Indicator option
(RFC-5213 [1]):
IANA-1: Partial handoff to a newly attached interface
IANA-2: Partial handoff to an existing attached interface
6. Security Considerations
All the security considerations from the base Proxy Mobile IPv6
protocol (RFC-5213 [1]) apply when using the extensions defined in
this document. These considerations will ensure the signaling
messages related to the partial handoff support specified in this
document are properly secured and authorized.
This document defines a new value for the handoff type, to be used in
the Handoff Indicator option. The use of this value in the Handoff
Indicator option, or the related processing considerations do not
introduce any new security vulnerabilities.
The mobile access gateway before initiating partial handoff request
to the local mobility anchor on behalf of a mobile node needs to
ensure that the mobile node is definitively notified of this partial
handoff action and that it is able to perform such address movement
between its interfaces. If this action is performed without proper
coordination between the mobile node and the mobile access gateway,
it may result in premature termination of certain sessions on the
mobile node.
Jeyatharan, et al. Expires September 5, 2009 [Page 15]
Internet-Draft Partial handoff March 2009
7. References
7.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[2] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 (work in
progress), January 2009.
7.2. Informative Reference
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Jeyatharan, M. and C. Ng, "Multihoming Problem Statement in
NetLMM", draft-jeyatharan-netext-multihoming-ps-00 (work in
progress), January 2009.
[5] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-01 (work in progress),
February 2009.
[6] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P.
Yegani, "Binding Revocation for IPv6 Mobility",
draft-ietf-mext-binding-revocation-03 (work in progress),
January 2009.
Authors' Addresses
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Jeyatharan, et al. Expires September 5, 2009 [Page 16]
Internet-Draft Partial handoff March 2009
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: kleung@cisco.com
Vijay Devarapalli
Wichorus
3590 North First Street
San Jose, CA 95134
USA
Email: vijay@wichorus.com
Jeyatharan, et al. Expires September 5, 2009 [Page 17]