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]