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]