NETEXT WG S. Gundavelli
Internet-Draft Cisco
Intended status: Informational May 05, 2009
Expires: November 6, 2009
Extensions to Proxy Mobile IPv6 - Motivation
draft-gundavelli-netext-extensions-motivation-00.txt
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 November 6, 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.
Gundavelli Expires November 6, 2009 [Page 1]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
Abstract
Proxy Mobile IPv6 is a network-based mobility management protocol
standardized in IETF and is being specified in various system
architectures as a protocol for building a common and access
independent mobile core. Currently, there are number of proposals
and a huge amount of interest in NETEXT working group for extending
the protocol to support various mobility extensions. This document
identifies some of the critical extensions that are absolutely
required and builds a case as why these extensions have to be
supported.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Client-based and Network-based Mobility Management
Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Mobile IPv6 Client Stack Support . . . . . . . . . . . . . . . 7
5. Proxy Mobile IPv6 Extensions & Motivation . . . . . . . . . . 9
5.1. Mobile Device and Networks Characteristics . . . . . . . . 9
5.2. Mobility Requirements . . . . . . . . . . . . . . . . . . 9
5.3. Protocol Assumptions on the Host Capabilities . . . . . . 10
6. Response to draft-tsirtsis-netext-controversy . . . . . . . . 12
6.1. PMIP with Host Signaling & Historic Reasons -
Clarification . . . . . . . . . . . . . . . . . . . . . . 13
6.2. MAG ... the new FA ? . . . . . . . . . . . . . . . . . . . 14
6.3. The Internet, the Interface, and the Host . . . . . . . . 15
6.4. What is wrong with PMIP so far ? Nothing ! . . . . . . . . 15
6.5. Its not a Tool Proliferation ! . . . . . . . . . . . . . . 16
7. Conclusions & Recommendations . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. Informative References . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Gundavelli Expires November 6, 2009 [Page 2]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
1. Introduction
The NETEXT working group was created recently in IETF to work on
specifying extensions to the Proxy Mobile IPv6 protocol [RFC-5213].
There is large amount of interest from the IETF community for
extending the protocol to support some real, practical and immediate
use-cases. These extensions are primarily for enabling the mobile
node to perform flow management and have the ability for it to
express attachment, handoff and flow preferences to the network.
However, there is also some resistance from a small group of people
who believe that the client-based mobility solution should be the
only option for solving these use-cases. This document analyses
these extensions in question and makes a case as why extensions are
critical and why these work items have to be adopted. The structure
of this document is as specified below.
The introductory sections of this document provide a brief history on
the evolution of two different mobility management approaches, the
client-based and the network-based mobility management. It provides
some background and the current trends in the industry with respect
to the solution preference.
Next, the draft reviews the deployment configurations and maps the
mobility requirements. It identifies the basic and the minimal
constructs required for the host to operate in a Proxy Mobile IPv6
network, and the resulting benefits of choosing that network-based
mobility management approach. It also reminds that the protocol
benefits from having the host to have the basic capability of
providing attachment, handoff and flow preferences to the network and
points to the MN-AR Interface document
[draft-ietf-netlmm-mn-ar-if-03].
The draft in Section 6.0, responds to the comments made in
[draft-tsirtsis-netext-controversy], which opposes many of the
proposed new extensions to Proxy Mobile IPv6, and tags them as
"controversial". This draft in a good faith attempts to understand
the concerns raised in that document and provides a response to those
comments. This draft also identifies the fundamental flaws in the
arguments presented in that document and reminds that similar
arguments have been made prior to the standardization of a network-
based mobility approach, however, the IETF community did not agree to
those comments and decided to design a protocol based on this
approach. This draft provides the reasoning as why these extensions
backed by the large internet community are non-controversial, how
they align perfectly well with the Internet or the host design
principles and why these extensions are needed for the advancement of
the Proxy Mobile IPv6 technology.
Gundavelli Expires November 6, 2009 [Page 3]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
Finally, in the concluding section, this draft makes certain
recommendations to NETEXT working group. It asks for reviving the
MN-AR interface [draft-ietf-netlmm-mn-ar-if-03] document as initially
planned, and for adopting flow mobility and inter-technology handoff
extensions into the charter on a faster track. It emphasizes that
the MN-AR interface was always factored in to design of Proxy Mobile
IPv6 [RFC-5213] and is required not only for supporting any new
extensions, but also for having a non-SDO specific interface between
the mobile node and the mobile access gateway.
Gundavelli Expires November 6, 2009 [Page 4]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119].
Gundavelli Expires November 6, 2009 [Page 5]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
3. The Client-based and Network-based Mobility Management Approaches
Mobile IP protocol [RFC-3344] was designed in the mid 90s' and the
early protocol in the absence of any data on how the protocol will be
used, restricted itself to a single design approach, client-based
mobility management. As part of any protocol evolution, the work was
later specified for IPv6 and thus Mobile IPv6 protocol [RFC-3775]
with the same approach of host-based mobility was standardized.
However, the Mobile IP as a technology was not a phenomenal success,
compared to MPLS or other technologies that were designed around that
period. The protocol was not adopted by large cellular standard
bodies, such as in 3GPP and was also not leveraged in enterprise
wireless architectures for solving the micro-mobility problems. The
protocol largely existed in CDMA/Flarion world, and remained as a
topic of fundamental interest to many graduate students in
Universities, almost for a decade. The reason for this limited
adoption is mostly to do with the design approach of, "client-based"
mobility, requiring the client to perform all aspects of mobility
management and requiring massive amount of software logic and system
resources on the tiny mobile devices.
The IETF community pushed for a slightly modified model, a network-
based mobility management approach, with minimal client
participation. Some of the SDO bodies already support such models
and also have made formal requests to IETF, for standardizing such
approaches. As a result of this, the Proxy Mobile IPv6 [RFC-5213], a
network-based mobility management protocol was standardized in 2008.
The protocol largely leveraged all the signaling and messaging
semantics from the Mobile IPv6 protocol, but chose the approach of
network-based mobility management. The protocol was designed with
the goal that the network will perform the mobility management on
behalf of the client, it will keep the client involvement to minimal
proportions, such as allowing it to perform inter-technology handoffs
or allowing it to express handoff or flow preferences. This design
choice resulted in a simple client with minimal software
requirements, such as a connection manager which can perform these
minimal required functions. The protocol was quickly adopted in 3GPP
and in WiMAX architectures on various interfaces and now many
extensions are being planned.
Gundavelli Expires November 6, 2009 [Page 6]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
4. Mobile IPv6 Client Stack Support
For attempting to understand why there is a large internet community
and vendor backing behind network-based mobility approaches, such as
Proxy Mobile IPv6 [RFC-5213] or Generic Tunneling Protocol (GTP), it
is important to review the current deployment and tool availability
status of one of the key components in the client-based mobility
management protocol, the Mobile IPv6 client [RFC-3775]. Following
are the author's own observations:
o The Mobile IP client, Mobile IPv4 or Mobile IPv6, is not shipped
to-date as part of any of the major Operating Systems. To name a
few, its not part of any of the Microsoft Windows released
versions, its not shipped with MAC OS/X, its not shipped with any
of the standard Linux distributions (Fedora, Redhat, ubuntu ..)
and is not shipped as part of any of the BSD distributions.
o Looking beyond the default Operating System shipments, there are
close to zero, or may be one or two commercial stack vendors.
Further, expecting these vendors to release Mobile IPv6 [RFC-
3775], Dual-Stack Mobile IPv6 [ID-DSMIP6], MCoA [ID-MCOA6], IKEv2
[RFC-4306], IPsec [RFC-4301] on all variants of Windows, Android,
iPhone, Linux and BSD systems requires lot of efforts, patience,
faith and hope. However, to give a fair perspective, it may be
supported in some of the wireless chipsets, by at least one chip
vendor, but that represents a low and insignificant adoption rate.
Furthermore, having such mobility function in a common radio
layer, restricts the host from using any of its interfaces that
are outside the common radio layer for its mobility support and
does not qualify as a true mobility client.
o So, it is reasonable to assume that there are significant
challenges in pushing a client-based mobility management approach
which requires massive amount of development efforts and $$
investment. Given the fact that there is no vendor commitment, no
tools in the market and considering the number of years since some
of these specs have been standardized, it is unreasonable to
continue to force the client-based mobility management approach as
the only solution and without giving any alternative choices.
Given the multitude of operating systems and variants, it is not a
trivial task to have a Mobile IPv6 client that includes IKEv2,
IPSec, Dual-Stack Mobile IPv6 and MCOA, and have it tested across
all these platforms and be available in the time frame when the
industry needs this work. This may happen eventually, but for the
current time frame, the market is looking for other solutions and
network-based mobility is the preferred approach which requires
minimal host support with a small application module that any
Gundavelli Expires November 6, 2009 [Page 7]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
vendor can develop in no time. This fact needs to be realized and
appreciated.
Gundavelli Expires November 6, 2009 [Page 8]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
5. Proxy Mobile IPv6 Extensions & Motivation
This section provides the motivation behind the proposed new
extensions. It maps these requirements from the potential deployment
configurations and the use-cases.
5.1. Mobile Device and Networks Characteristics
Most of the mobile devices that are available today in the market are
equipped with multiple radio interfaces, such as LTE, WiMAX, eHRPD,
WiFi etc, and in any combination. So, it is reasonable to assume
that a mobile nodes can potentially attach to the network using one
or more interfaces and be using all of those interfaces
simultaneously for its data sessions.
It is given that the networks in which these mobile nodes are attach
will be a true heterogeneous networks with multiple access
technologies. A mobile operator can potentially be managing more
than one access technology in their core network. Or, they may have
partnerships with other operators that support a different access
technology. Even for other reasons such as during migration, an
operator may support nation wide 3G network with one access
technology and be supporting a different access technology while
bringing up the 4G network in some pockets; this would be the natural
migration for CDMA operators from eHRPD to LTE. Or, for the most
obvious reason of a dual-mode LTE/WiFI, or WiMAX/WiFI handset
operating in multiple access networks.
5.2. Mobility Requirements
The above described mobile device capabilities coupled with the
availability of a heterogeneous network with multiple access
technologies, requires some special support for providing any
reasonable end-user experience. These requirements are very obvious
and is a basic expectation from any mobility protocol. Following are
the some of the key mobility related considerations:
1. Roaming in a homogeneous network - A mobile node should have the
ability to seamlessly roam and change its point of attachment
within a single access domain.
2. Roaming between heterogeneous networks - A mobile node should
have the ability to seamlessly roam between two different access
networks. For example, a mobile node initially attached to an
LTE network, later when in the vicinity of a WiFi network, should
have the ability to perform an inter-technology handoff and move
its IP address configuration and all its network sessions to the
WiFi interface. Or, to support handoffs such as between eHRPD/
Gundavelli Expires November 6, 2009 [Page 9]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
LTE, LTE/WiFI, WiMAX/WiFI or WiMAX/LTE.
3. Multihoming Support - A mobile node should have the ability to
attach to network using multiple interfaces and be able to use
any one or more of its interfaces for network connectivity.
4. Flow Mobility Support - A mobile node should have the ability to
move the flows between interfaces on a selective basis. For
example, a mobile node initially attached to an LTE network,
later when in the vicinity of a WiFi network, should have the
ability to move certain high bandwidth intensive flows to the
WiFI network. The 3GPP is exploring such uses cases and are
documented in [3GPP-TR-23.861].
The base Proxy Mobile IPv6 base specification has support for some of
the above requirements and the new proposals are intended for
supporting the remaining requirements and in a more complete and
explicit way.
5.3. Protocol Assumptions on the Host Capabilities
For supporting the above requirements, the protocol places certain
assumptions on the multihomed host. Typically, all multihomed hosts
in the considered operating environment are required to have an
application module, such as a connection manager. The requirement
for this module is not a Proxy Mobile IPv6 requirement, but rather
the requirement of a multihomed host. This module essentially will
have the user specified policies with respect to network attachment
or flow mobility preferences, and may need these minor extensions.
o The ability for the host to notify if the current attachment over
a given interface is as a result of inter-technology handoff, or
for the bringup of a new interface. In most cases, the network
can derive this information and project the right prefixes, but
this can be certainly be an explicit notification from the client.
o The host identifying the flows that it chooses to move between
interfaces and notifying to the network. This semantic may not be
needed if the flow policies are synchronized between the host and
the network.
o The use of virtual interface configuration for supporting inter-
technology handoffs. In most systems, this is matter of running a
tool to keep the physical interfaces in a bridged mode and using a
single virtual interface for its address configuration.
So, it is reasonable to state that we need a connection manager on
the host that can potentially manage the user preferences with
Gundavelli Expires November 6, 2009 [Page 10]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
respect to network attachment, flow management and for it to manage
the interface configuration and express these preferences to the
network, such as in [draft-ietf-netlmm-mn-ar-if-03], using a SDO
specific interface.
Gundavelli Expires November 6, 2009 [Page 11]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
6. Response to draft-tsirtsis-netext-controversy
The [draft-tsirtsis-netext-controversy] argues that IETF should not
allow the proposed new extensions to Proxy Mobile IPv6. It is
unfortunate that the draft was not written in a constructive and an
impartial manner. Its clear, the basic purpose of the draft is to
favor client-based solution. That is fine. One can certainly
disregard these comments as one's opinion, affiliation or attachment
to a specific technology as the reason for strong and a one sided
view. But, to an innocent reader who may not know all the technical
details may be misled reading such views. So, its important to
respond to these comments.
The draft mostly argues on legal grounds and makes number of
assumptions which are incorrect and continues to build the case based
on those assumptions and finally arrives at its own conclusions. To
state a few:
o The draft assumes that the mobile node in a Proxy Mobile IPv6
domain has no ability, or it should not be able to express
attachment, handoff or flow preferences to the network. The
document builds the entire case based on this argument. It
completely ignores the operating environment and does not even
mention about the MN-AR Interface document
[draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces,
which was always considered in the protocol design.
o The draft fails to differentiate between a mobile node expressing
minimal hints to the network, such as attachment, connection or
flow preferences, to a full blown mobile node with all the complex
software requiring massive system resources and performing all
aspects of mobility management. It equates both as one and the
same with the conclusion that any software on the host is the same
as client-based mobility. But, it does not see the difference,
boiling a glass of water to boiling an ocean.
o The draft reviews some of the multihoming and flow mobility
scenario's and makes a case that it is not possible to perform
flow mobility or support complex handoff scenario's without the
mobile node being aware and which is correct. Ack ! But, again
it ignores the MN-AR Interface or SDO specific layer which can be
used for such purpose.
o The draft ignores the market direction and the industry
preferences for network-based mobility management, either in the
form of Proxy Mobile IPv6 or Generic Tunneling Protocol [GTP], and
the resulting benefits in that approach.
Gundavelli Expires November 6, 2009 [Page 12]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
o The draft disregards the amount of scrutiny, reviews and the
external validations that went into the base protocol design for
ensuring the protocol followed the IETF design principles.
The following sections respond to more specific comments, on section
by section basis.
6.1. PMIP with Host Signaling & Historic Reasons - Clarification
There is a comment, a mobile node in a Proxy Mobile IPv6 domain is
not allowed to have any intelligence. And there will point you to
some incomplete and ambiguous line in the charter that was never ever
discussed widely during the formation of NETLMM working group and
which went practically unnoticed. Even if it did, it does not mean
much and is not relevant. In any case, following is the response to
that comment.
Proxy Mobile IPv6 was certainly created with the goal that the mobile
node will not perform any mobility signaling with its local mobility
anchor. So far it is correct. However, no where in the base
protocol specification, it ever stated and assumed that:
o that the mobile node that attached to a Proxy Mobile IPv6 domain
will be a dumb and a stupid terminal which can do only a single
attachment, cannot dynamically manage its interfaces or cannot
configure an address dynamically on a real or on a virtual
interface.
o that it will be disallowed from providing handoff, attachment or
flow preferences to the network, through a SDO specific interface
layer.
o that an operator cannot install any intelligent application
software, such as connection manager which using the configured
policies or user inputs, makes the network attachment decisions.
o that it will be disallowed from being aware of the operating
environment.
These restrictions do not make any sense and are not needed.
Providing attachment and handoff preferences was always factored in
to the design. The MN-AR Interface document
[draft-ietf-netlmm-mn-ar-if-03] which was a working document prior to
the adoption of the initial Proxy Mobile IPv6 document, was specified
for that purpose. The protocol also allowed this interface to be
defined in a SDO specific manner, specifying the protocol between the
network nodes only by reacting to the provided events. This is not a
design flaw, but allowing the room for all the extensions to come in
Gundavelli Expires November 6, 2009 [Page 13]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
place in a evolutionary manner.
An application software such as connection manager is a basic host
requirement for any multihomed terminal and is not a Proxy Mobile
IPv6 requirement. This component cannot be avoided on any multihomed
host. The behavior of any host will be unpredictable and unreliable
with respect to the choices it makes for all its network connections.
Proxy Mobile IPv6 only requires few additional hooks on such software
module, that too for supporting some features.
6.2. MAG ... the new FA ?
Section 5.2.2 of [draft-tsirtsis-controversy-00] tries hard to imply
that functional element, mobile access gateway is the same as foreign
agent in Mobile IPv4, with the objective to prove that any software
requirement on the client maps to Mobile IPv4 model. Sure, the
models map in the mobility element count, but there are role
differences in each of those models and the argument completely
discounts this aspect.
In a network-based mobility model, there is an element on the network
that is designated to perform the mobility management functions. We
can call this a foreign agent, mobile access gateway or a mobility
proxy, but the functional role has a specific purpose and the model
is not Mobile IPv4. The functional role of the mobile node is not
beyond than managing its interfaces, address configuration and
expressing handoff and flow preferences to the network. It plays a
mere passive role and allowing the mobile access gateway to play the
active role on the aspects of mobility management. So, there is a
fundamental difference between this when compared to the Mobile IPv4.
In any case, the comparison that is needed is in relation to client-
based mobility. Following are the fundamental differences between
all the three models:
o In Mobile IPv4 (FA-CoA Mode), the mode of active client and
passive network node, the mobile node plays an active role,
performs all aspects of mobility management, while the foreign
agent plays mere passive role
o In Proxy Mobile IPv6, the mode of passive client and active
network node, the mobile node plays a mere passive role in the
mobility management. It does not perform any mobility signaling
with the local mobility anchor. It is only expected to provide
attachment, handoff and flow preferences to the network, while the
mobile access gateway is responsible for performing all aspects of
mobility management.
Gundavelli Expires November 6, 2009 [Page 14]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
o In Mobile IPv6, the mode of active client, the mobile node plays
the active role and performs all aspects of mobility management.
It requires Mobile IPv6 client [RFC-3775], DSMIP6 [ID-DSMIP6],
MCOA [ID-MCOA6], IKEv2 [RFC-4306] and IPsec [RFC-4301] stacks.
Its requires significant amount of software and system resources
on the client.
6.3. The Internet, the Interface, and the Host
And we got a ticket ! We are breaking the Internet building blocks.
Section 3.0 of [draft-tsirtsis-controversy-00] is not clear on what
the concern is. Following are the clarifications.
o The IP mobility is above network layer, it is a service layer and
as specified in Section 6.6 of [RFC-5213], a mobile node on
attaching to the Proxy Mobile IPv6 network is required to present
its identify. So, the mobile access gateway has a clear relation
between a mobile node's identify, its link-layer identifier and on
the offered mobility service along with the assigned prefix. But,
this relation is preserved in an application layer and at the IP
layer its just the standard protocol operation confirming to all
the standard IETF protocols.
o When looked at from the perspective of IP layer, the MN-AR link is
any other IP link. Its a point-to-point link and with the mobile
access gateway functioning as the IPv6 router on the link. The
prefix set that it projects on the link is always tied to that
mobile node's interface, but that relation is preserved in
application layer and the network layer has no understanding of
any of this relation. Its a normal IPv6 link with the presence of
two nodes on the link and a set of hosted IPv6 prefixes.
o The comment on NDP operation for multihomed hosts is not
applicable. The MN-AR link is a point-to-point link, with only
one interface of the mobile node, either real or a virtual
interface, is present. So, the protocol does not modify the low
level building blocks of the Internet and so the allegation is not
correct.
6.4. What is wrong with PMIP so far ? Nothing !
Clarifications to Section 4.0 of [draft-tsirtsis-controversy-00] in
the same order.
1. The absence of MN-AR interface, as an IETF specified interface
does not imply the protocol is broken. For example, the IP layer
is built with the assumption that the layer-2 driver for a given
access technology will provide the required hooks for the IP
Gundavelli Expires November 6, 2009 [Page 15]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
layer. Its the same thing here. A given SDO can define such
interface.
2. It is indeed correct that there is no concept of a MAC address in
certain link-layer technologies, but that's only in CDMA and in
LTE. The absence of such semantic in these two technologies is
not a problem for the current operating environment.
- the protocol uses the Access Technology Type for the
uniqueness and for a dual-mode terminal that are going to be
in the market, it is highly unlikely there are multiple
radio's of the same type.
- even otherwise, a simple semantic allowing the mobile node
to present an identifier as part of the attachment preferences
will be just fine.
3. The use of virtual interfaces is a host specific semantic. It is
perfectly valid for a host to use the physical interfaces in a
bridged mode and present a virtual link-layer identifier. This
is perfectly valid and many protocols such as HRRP or VRRP use
such mode. This has no implication on the IPv6 link or on the
link neighbors.
4. It is true that the mobile node can potentially specify if the
given attachment is due to an handoff or as result of a new
interface bringup. But, the absence of such event is fine in
most cases. The network through context transfer procedures or
through other means, can derive that information. We can
certainly add this in the IETF specified MN-AR interface layer.
6.5. Its not a Tool Proliferation !
A comment was made in Section 5.2.3 of
[draft-tsirtsis-controversy-00], that allowing host participation in
any level, is equivalent to client performing all aspects of mobility
management and results in redundant tool proliferation.
Its not always a binary logic. No host involvement in mobility
management does not imply the host has zero awareness of the
operating environment, or that it is disallowed from running any
intelligent software such as connection manager, or that is a
violation for it express its connection or flow preferences to the
network. That was never a basis for the design of the Proxy Mobile
IPv6 protocol. Allowing the host to have such capabilities only
improves the protocol and cannot be considered as a tool
proliferation.
Gundavelli Expires November 6, 2009 [Page 16]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
Even otherwise, new ideas, fresh discoveries on how to deploy a
technology in a real-world network and when coupled by urgent
customer needs, always can re-shape a technology. A technology
solution that start with Protocol-A need not be restricted to that
protocol, but instead can go with Protocol-B, if that happens to be a
better protocol and if market wants that solution. There are many
instances in IETF, where it allowed multiple technologies to co-exist
and let the market adopt what is right, to name a few:
o (Mobile IPv4 + DSMIP4) vs. (Mobile IPv6 + DSMIP6). (Note: the
author and some of the reviewers of
[draft-tsirtsis-controversy-00] have authored both these competing
DSMIP standards.)
o CMOT Abandoned and SNMP Moves On ..
o SCTP in the presence of the giant TCP,
o OSPF vs. Dual IS-IS
o RTP vs. DCCP
o MOBIKE Overlap with Mobile IP, for the mobile VPN solution
o ... the list goes on ...
It is in this context that I'd like to point to [RFC-5218] ("What
Makes for a Successful Protocol?"), No where in that, it said, the
success of a protocol depends on eliminating or restricting better or
alternative approaches for solving a given problem. But, rather win
by market acceptance and make the competing standard and a mere
document.
This is by no means to imply that a solution based on network-based
mobility is better than client-based mobility solution, or other way
around. The author of this document has interest in both the
technologies. We are not competing. The point is about the need to
allow both the protocols to shape-up and find its place, its not up
to IETF to decide the market for these protocols.
Gundavelli Expires November 6, 2009 [Page 17]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
7. Conclusions & Recommendations
This draft makes the following recommendations to the NETEXT working
group and asks the IESG to give a careful consideration to the
following points.
o The client-based and network-based mobility management protocols
are two different approaches adopted equally widely by the
industry. These protocols are not mutually exclusive. Success of
one protocol does not diminish the value of the other protocol.
Both the protocols can co-exist and have their respective places.
Its not the business of the IETF to endorse one to the other, as
there are business implications. IETF as a neutral body should
not favor one, specially, when both the solutions are adopted by
different SDO bodies and when it is impossible to compare and
qualify one as a better protocol to the other. Let both the
protocols evolve, be feature-rich, as per the interests of the
large internet community and mobility experts, let deployments
pick the one that best suits their operating environment.
o Multihoming and Inter-technology handoffs are the integral part of
the Proxy Mobile IPv6 protocol and is the basis for its existence.
The protocol was designed primarily for solving inter-technology
handoffs and for a multihomed terminal, such as handoff between
various access technologies, WiMAX, eHRPD, LTE and WiFI. The
working group should ensure any new extensions are intended only
to improve on these aspects, fix any missing gaps, but not create
some artificial restrictions.
o Improve the host awareness with respect to its presence in the
Proxy Mobile IPv6 environment.
o Revive the MN-AR Interface document [draft-ietf-netlmm-mn-ar-if].
The document was a working group document, however, due to lack of
reviewers at the time when the working group was busy with the
base protocol design, the NETLMM Chairs decided to take that work
out of the charter. There was minimal or not much thought that
went into this decision. It was a quick decision that largely
went unnoticed. Extend the MN-AR Interface document with the
required handoff hints for supporting inter-technology handoffs as
required in the base Proxy Mobile IPv6 and for supporting any new
extensions such as, flow mobility support.
o Make it clear in the charter that it is perfectly reasonable and
valid to require changes on the host in the form of application
requirements for supporting inter-technology handoffs or any other
extensions that helps the protocol or its deployments. There are
many other protocols in IETF that constantly evolve the client
Gundavelli Expires November 6, 2009 [Page 18]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
stacks and any special restrictions only to this protocol is not
needed. It is to be noted that the change here is more from the
perspective of its ability to manage its interfaces, connections
and the ability to convey the connection and flow preferences to
the network. However, the working group should be conscious to
keep these requirements as minimal as possible and not to loose
the strategic advantage of a network-based mobility protocol, with
minimal host support requirements. The assumptions and the
requirements on the host in the form of connection manager at the
minimum can be limited to:
1. Interface management/Address Configuration on the interface,
2. Exchanging the attachment, handoff and flow preferences with
the network
3. Understanding the operating environment
Bottom line: The industry needs this work and in a timely fashion.
Delaying this work only hurts the mobility technology and its
adoption. Right when SDO bodies are exploring the solutions for
supporting inter-technology handoffs, such as WiMAX/WiFI, LTE/WiFI,
WiMAX/LTE, LTE/eHRPD, its is important to realize that the proposed
work items, such as multihoming and flow mobility, and with massive
community backing, are critical and are the key requirements for the
protocol adoption and should be taken up on a fast track.
Gundavelli Expires November 6, 2009 [Page 19]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
8. IANA Considerations
This specification does not require IANA actions.
Gundavelli Expires November 6, 2009 [Page 20]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
9. Security Considerations
This document does not require any security considerations.
Gundavelli Expires November 6, 2009 [Page 21]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
10. Acknowledgements
The author would like to acknowledge the prior discussions on this
topic in the netext mailing list. Thanks to Fred Baker, for citing
some of the many instances where IETF allowed multiple solutions for
the same problem. Also, thanks to Mohana Jeyatharan for providing
the 3GPP specific flow mobility requirements.
Gundavelli Expires November 6, 2009 [Page 22]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
11. Informative References
[RFC-2119] 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.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2003.
[RFC-5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC-5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", July, 2008.
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-10.txt, April 2009.
[ID-MCOA6] R. Wakikawa et al, "Multiple Care-of Addresses
Registration", draft-ietf-monami6-multicoa-13.txt, April 2009.
[draft-ietf-netlmm-mn-ar-if-03] Laganier, J., Narayanan, S. and P.
McCann, "Interface between a Proxy MIPv6 Mobility Access Gateway and
a Mobile", February, 2008.
[draft-yokota-netlmm-pmipv6-mn-itho-support-01.txt] Yokota, H.,
Gundavelli, S., and Leung, K., "Inter-Technology Handoff support in
Mobile Node for Proxy Mobile IPv6", April 2009.
[draft-jeyatharan-netext-pmip-partial-handoff-00.txt], M. Jeyatharan
et al, "Partial Handoff Support in PMIPv6", March 2009.
[draft-jeyatharan-netext-multihoming-ps-01], M. Jeyatharan et al
"Multihoming Problem Statement in NetLMM", March 2009.
[3GPP-TR-23.861] "Multi access PDN connectivity and Flow Mobility".
3GPP TR 23.861, May 2009.
Gundavelli Expires November 6, 2009 [Page 23]
Internet-Draft Extensions to Proxy Mobile IPv6 May 2009
Author's Address
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Gundavelli Expires November 6, 2009 [Page 24]