[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Individual Submission                                      B. Patil, Ed.
Internet-Draft                                                     Nokia
Intended status: Informational                               C. Williams
Expires: May 3, 2012                                           MCSR Labs
                                                             J. Korhonen
                                                  Nokia Siemens Networks
                                                        October 31, 2011


Approaches to Distributed mobility management using Mobile IPv6 and its
                               extensions
                   draft-patil-mext-dmm-approaches-02

Abstract

   Mobility solutions at the IP layer have been specified in the IETF
   for IPv4 and IPv6.  These solutions include host and network based
   mobility.  All of the mobility protocols enable IP session continuity
   by providing the mobile host with an IP address or prefix that
   remains constant even as the host moves and attaches to different
   access networks and points of attachment.  Mobile hosts are anchored
   at a gateway via a tunnel and the address/prefix provided to the host
   via the gateway remains unchanged across mobility events.  All IP
   sessions initiated or terminated at a mobile host are anchored via
   the gateway.  A gateway centric approach raises certain concerns in
   terms of cost and efficiency.  A mobility model wherein the mobility
   functions are distributed is a way of alleviating the concerns of a
   gateway centric approach.  This document considers ways to alleviate
   anchored mobility issues with approaches that could be considered in
   a deployment.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2012.




Patil, et al.              Expires May 3, 2012                  [Page 1]


Internet-Draft                DMM with MIP6                 October 2011


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Issues with current mobility models  . . . . . . . . . . . . .  5
     4.1.  Backhauling all traffic to a centralized GW  . . . . . . .  5
     4.2.  Latency Considerations . . . . . . . . . . . . . . . . . .  6
     4.3.  Inefficient Routing and signaling overhead . . . . . . . .  6
     4.4.  Scalability and cost . . . . . . . . . . . . . . . . . . .  6
   5.  Enhancements to improve mobility . . . . . . . . . . . . . . .  7
     5.1.  HMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Dynamic assignment of HA . . . . . . . . . . . . . . . . .  7
     5.3.  Route Optimization . . . . . . . . . . . . . . . . . . . .  7
   6.  Distributed mobility - What does it imply  . . . . . . . . . .  8
   7.  Approaches using current protocols for distributed mobility  .  9
   8.  Potential future work  . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 11
   12. Informative References . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12













Patil, et al.              Expires May 3, 2012                  [Page 2]


Internet-Draft                DMM with MIP6                 October 2011


1.  Introduction

   Mobility solutions at the IP layer have been specified in the IETF
   for IPv4 and IPv6.  These solutions include host and network based
   mobility.  All of the mobility protocols enable IP session continuity
   by providing the mobile host with an IP address or prefix that
   remains constant even as the host moves and attaches to different
   access networks and points of attachment.  Mobile hosts are anchored
   at a gateway via a tunnel and the address/prefix provided to the host
   via the gateway remains unchanged across mobility events.  All IP
   sessions initiated or terminated at a mobile host are anchored via
   the gateway.  There are issues and concerns with such a mobility
   model which are discussed in this document.  A mobility model wherein
   the mobility functions are distributed is a way of alleviating the
   concerns of a gateway centric approach.  This document also considers
   ways to alleviate anchored mobility issues with approaches that could
   be considered in a deployment.

   Mobile IPv6 as specified in [RFC6275] [RFC3776] is a host based
   mobility protocol.  It requires the MN to be anchored at a home
   agent.  The home agent assigns the MN an IPv6 address or prefix that
   is static for the duration of the registration period.  Similarly
   Proxy Mobile IPv6 [RFC5213] is a network based mobility protocol in
   which the mobility access gateway (MAG) assigns the MN a prefix
   provided by the local mobility anchor (LMA) for the duration of a
   valid registration.  This prefix does not change across mobility
   events.  The home agent and LMA entities can be viewed as centralized
   gateways.  These gateways generally serve a large number of mobile
   hosts.  All traffic to/from mobile hosts associated with an HA/LMA is
   routed through these gateways and as a result raises concerns such as
   :

   1.  single point of failure,

   2.  backhauling traffic to the gateway,

   3.  latency as a result of backhauling and additional processing,

   4.  cost and complexity, etc.

   These issues are discussed in further detail in the document.  It
   should also be noted that in addition to mobility for hosts, there is
   also specifications that deal with networks that are mobile.  Network
   mobility is specified in [RFC3963]

   The mobility working groups in the IETF have extended the basic
   protocols to address various issues and concerns.  Hierarchical
   Mobile IP [RFC5380] and flow mobility [RFC6088], [RFC6089] are just a



Patil, et al.              Expires May 3, 2012                  [Page 3]


Internet-Draft                DMM with MIP6                 October 2011


   few examples.  Many of these extensions can be utilized in
   deployments to alleviate the issues that arise from an anchored
   mobility solution.  A few approaches to how a distributed mobility
   model could be deployed using current protocols and extensions are
   also discussed in this document.


2.  Terminology

   Distributed Mobility

      The term distributed mobility refers to an architecture in which
      the mobility function is distributed across multiple levels in a
      deployment.  The mobility function could be provided by an access
      point or base-station or it could be a part of the access network.
      Distributed mobility would enable session continuity for hosts
      while not requiring that they be anchored at a single gateway
      (home agent) all the time.


3.  Problem statement

   The lack of support for mobility at the IP layer has been addressed
   in IPv6 with the specification of Mobile IPv6 [RFC6275].  Various
   extensions to the protocol such as support for multiple care-of-
   addresses as well as the ability to operate while attached to an IPv4
   network using Dual-stack Mobile IPv6 [RFC5555] have been specified.
   The protocol has not been widely implemented or deployed as of date
   for various reasons.

   The Internet has evolved to support real-time applications such as
   voice, multimedia streaming etc.  These applications require low
   latency as well as no (or minimal) interruptions when switching
   interfaces or networks.  Current IP mobility solutions based on
   Mobile IPv6 are well suited for non-real-time applications which are
   able to handle the delay which is caused by a mobile node doing a
   handover between networks or switching interfaces.  Optimizations to
   support real time applications have also been specified such as
   FMIPv6 [RFC5568].  The centralized gateway approach of Mobile IPv6
   has multiple issues and raises concerns that are captured in this
   document.  One of the ideas is to move the mobility gateway closer to
   the actual point of attachment.  This has benefits in terms of
   reduced latency but it also causes other issues such as the ability
   to support mobility when the MN moves to a different access network
   or the ability to do charging at a central node.  Distributed
   mobility is an approach that has some merit and worth studying
   further.  At the same time the issues that are driving the mobility
   solutions towards a different model can be addressed by existing



Patil, et al.              Expires May 3, 2012                  [Page 4]


Internet-Draft                DMM with MIP6                 October 2011


   protocols with various extensions.  The problems of a centralized
   gateway approach and reasons for considering distributed mobility
   need to be deeply analyzed and understood before beginning work on
   entirely new protocols for solving IP mobility.


4.  Issues with current mobility models

   Current mobility protocols have been designed with a stable
   topologically correct anchoring gateway in mind.  They just do not
   tolerate mid-session anchor relocation.  HMIP6, HA Switch, HA-
   reliability and LMA Redirect are attempts in that direction but fail
   or fall short.

   In addition, one of the key deployment considerations of Mobile IPv6
   is the location of each of the home agents or gateways, both
   initially and over time.  Each operator has unique requirements;
   therefore, no single deployment model will suit all operators.  The
   operator's own organizational structure could also influence the
   mobility architecture.  Some operators have network OAM
   responsibilities that are assigned geographically, while others use a
   more centralized model.  The deployment architecture that has been
   traditionally put forth is to have centralized gateway elements where
   all mobility control and data traffic is routed through them.

4.1.  Backhauling all traffic to a centralized GW

   A centralized home agent/gateway approach leads to backhauling all
   traffic to the node which has unfavorable operational consequences.

   The sheer volume of the aggregated throughput traffic to backhaul all
   user data from a local aggregation anchor to centralized data centers
   with home gateways can be expensive in many scenarios.  With high
   density deployments, the centralized architecture leads to heavy
   backhaul utilization, and the inability to distribute load quickly
   manifests unfavorably.  In addition, local user traffic does not
   remain local.  User traffic must travel all the way to the
   centralized gateway and back, even if the corresponding peer is
   topologically closer.

   In addition, a centralized gateway model increases the cost of
   backhaul by preventing the off-loading of high-bandwidth services
   locally.  Instead high-bandwidth services have their traffic
   backhauled to a centralized gateway in a data center.  This will
   increase the distances and possibly the capacity associated with any
   backhaul.





Patil, et al.              Expires May 3, 2012                  [Page 5]


Internet-Draft                DMM with MIP6                 October 2011


4.2.  Latency Considerations

   While the support for Internet offload of user data can significantly
   reduce the core network backhaul, the mobility management element may
   be strategically positioned deeper in the network to efficiently
   set-up and process the signaling and control including optional
   policies.  Such a hybrid architecture can provide for supporting a
   mix of real-time and non-real-time broadband services.  Real-time
   applications can benefit from lower latencies by having data closer
   to the subscriber and peers and not backhauled.  Non-real-time
   applications (such as e-mail) derive no such performance benefit and
   may have a more centralized traffic approach.

   Current mobility models handle offload cases poorly.  A consideration
   may be to clearly make a working toolbox for applications to select a
   prefix with anchored mobility and a prefix without anchoring.

4.3.  Inefficient Routing and signaling overhead

   Inefficient routing mechanism of a completely centralized mobility
   deployment approach causes QoS deterioration and may lead to heavy
   network congestion in the core.

   In the centralized approach only the HA and the CNs manage a nodes
   mobility.  Mobility signaling occurs each time a mobile node changes
   its point-of-attachment regardless of the locality and amplitude of
   its movement.  As a consequence, the same level of signaling load is
   introduced independently of the user's mobility pattern.  For
   example, if the HA and/or CNs are far from the MN, even if the MNs
   movement is small, the mobility signaling messages travel across
   several IP networks, the latencies of which reduce handover speed.
   Furthermore, route optimization which supports direct routing from
   CNs to the mobile node, generates excessive mobility messages and
   adds a significant extra load to the network.

4.4.  Scalability and cost

   In a completely centralized Mobile IPv6-based deployment approach,
   the home agent becomes a single point of failure.  Also, a
   distributed deployment approach may provide better overall capacity
   and performance, but this must be weighed against the increase in
   capital costs for deployment of local distributed gateways.  In
   addition, a completely centralized deployment model makes it
   difficult to scale with a large number of mobile nodes.  Scalability
   costs are weighted from many perspectives such as the number of nodes
   in the overall system, the geographic distance of the traffic, the
   number of autonomous parties in the deployment approach and others.




Patil, et al.              Expires May 3, 2012                  [Page 6]


Internet-Draft                DMM with MIP6                 October 2011


5.  Enhancements to improve mobility

   Enhancements to the Mobile IPv6 protocol have been done to improve
   mobile communications in certain scenarios so that mobility
   operations are efficient and optimized..  A key area of enhancements
   is in reducing the delays in the data path redirection operation that
   is defined in Mobile IPv6 operations.  Mobile IPv6 has adopted route
   optimization and HMIPv6 to reduce the traversal of data traffic to
   the mobile nodes new location changes in its point of attachment.
   Delays in data traffic redirection will depend upon the location of
   the anchor agent that performs the redirection.  As such enhancements
   focus on moving these anchor agents closer to the mobile node.

5.1.  HMIPv6

   Using Mobile IPv6, a mobile node sends location updates to any node
   it corresponds with each time it changes its location, and at
   intermittent intervals otherwise.  This involves a lot of signaling
   and processing, and requires a lot of resources.  Furthermore,
   although it is not necessary for external hosts to be updated when a
   mobile nodes moves locally, these updates occur for both local and
   global moves.  Hierarchical Mobile IPv6 (HMIPv6)is designed to
   enhance mobility support in MIPv6 and micro-mobility management.  The
   benefit of the HMIPv6 enhancement is to reduce the amount of
   signaling required and to improve handoff speed.

   The key concept behind HMIPv6 is to locally handle handovers by the
   usage of an entity called the Mobility Anchor Point (MAP) located at
   any level in a hierarchical network of routers.  The major issue on
   HMIPv6 is designing the MAP selection scheme that can reduce frequent
   handover mobility signaling and improve handover performance.

5.2.  Dynamic assignment of HA

   Dynamic assignment of HA is an enhancement to reduce both the
   signaling traffic and the data traffic to the home network.  The
   dynamic HA assignment may take into account the geographical
   proximity of the HA to the mobile node.  It may also consider
   performance factors such as HA load-balancing or other criteria.

5.3.  Route Optimization

   Mobile IPv6 Route optimization is an enhancement to optimize the data
   path between two communicating nodes despite changes in the IP
   connectivity on the mobile node side.  The data path reduction
   between the communicating nodes helps to reduce one way packet delay
   when both nodes are under the same localized domain and the mobility
   gateway is far away.  The process of reducing data path is referred



Patil, et al.              Expires May 3, 2012                  [Page 7]


Internet-Draft                DMM with MIP6                 October 2011


   to as route optimization.  Route optimization helps reduce the delay
   and thus important for real-time applications.  An enhanced version
   of route optimization may also enable continued communications during
   periods of temporary home-agent unavailability.


6.  Distributed mobility - What does it imply

   Mobility is a service that provides significant value to a network
   operator.  The ability to offer connectivity and services that work
   seamlessly across mobility events such as the switching of an access
   network type etc. creates a much superior end-user experience and
   thereby a demand for such service.  Cellular networks have offered
   mobility for voice and messaging (short message service) since the
   late 80s and early 90s.  These networks have been evolving and are
   now offering broadband data services and Internet connectivity.  The
   network architectures are also using Internet protocols and
   technologies to a significant extent.  Traditionally the
   architectures of these networks has been hierarchical in nature.
   While such an architecture served operators well in the past, it has
   limitations when it comes to offering data services and Internet
   connectivity.  There is an effort to distribute functionality that
   generally has resided in centralized gateways much more closer to the
   edge of the network.  The line between the access and core network is
   fading and hence a need to rethink how mobility service is affected
   in such an evolving architecture.

   Distributed mobility is a way to deploy existing mobility solutions
   that do not require a mobile host to be anchored at a gateway all the
   time but instead be attached to different mobility agents/gateways in
   the network depending on the access, location and other factors.
   Session continuity via distributed mobility is expected to be on par
   with that provided by an anchored mobility solution.

   Does it require an entirely new approach to mobility architectures
   that would be based on the goal of distributing mobility related
   functions?  It is an easy option to consider redesigning on a clean
   sheet of paper.  However this is not a pragmatic approach.  It is
   much more optimal to consider what are the issues that are created as
   a result of a centralized gateway architecture and then develop
   extensions to the protocols and, deployment models, that can address
   those issues.  The implications of distributed mobility architectures
   on access and core networks needs to be also considered in any
   design.







Patil, et al.              Expires May 3, 2012                  [Page 8]


Internet-Draft                DMM with MIP6                 October 2011


7.  Approaches using current protocols for distributed mobility

   We believe that most of the needed basic protocol functionality for
   distributed mobility management is already there.  What is missing
   seem to be related to general system level design and lack of
   mobility aware APIs for application developers.  One of the simple
   approaches for distributed mobility management is to avoid
   traditional "anchored mobility" like Mobile IPv6 when possible and
   rather use local (care-of) addresses for the communication.  Use of
   local addressing also implies less mobility related signaling load in
   the network.  For example [RFC5014] already provides means for an
   application to explicitly request for a prefix that has mobility
   characteristics (IPV6_PREFER_SRC_HOME) or a prefix that is local to
   the current access network (IPV6_PREFER_SRC_COA).  It is not
   guaranteed that the IP stack in the MN would always respect the
   suggestion received from the application.  In general it is also
   important that possible solutions in distributed mobility management
   space requires minimal changes in mobile hosts.

   Another aspect that is in interest of distributed mobility management
   concentrates on allocating mobility anchors that are topologically
   close to the MN.  Existing protocols such as HMIPv6 [RFC5380] provide
   a solution that is close what is needed.  What might be needed in
   addition is a mechanism to "chain" multiple MAP-domain to extend the
   micro-mobility area, or provide another RFC5014 like prefix type
   (IPV6_PREFER_SRC_MAP).  We could also consider Mobile IPv6 + Proxy
   Mobile IPv6 interactions Scenario A.1 in
   [I-D.ietf-netlmm-mip-interactions] a similar solution.  Finally, yet
   another approach for exploiting locality are Proxy Mobile IPv6
   localized routing solutions [I-D.ietf-netext-pmip6-lr-ps] which
   allows bypassing the remote central Local Mobility Anchor when ever
   possible and have a direct communication via closer to MNs Mobile
   Access Gateways.

   Home Agent Switch [RFC5142] extension to Mobile IPv6, Runtime LMA
   assignment [I-D.ietf-netext-redirect] extension to Proxy Mobile IPv6
   and Mobile IPv4 Dynamic HA Assignment [RFC4433] all provide solutions
   to dynamically assign a mobility anchor to the MN.  What is missing
   from these solutions, is a protocol or rather a system level solution
   for a "seamless mobility anchor relocation" during an existing
   mobility session.  However, that would be rather challenging due the
   fact that a mobility anchor relocation usually implies topological
   location chance in the network, which would also mean different
   prefixes/subnetworks for home addresses from the IP routing point of
   view.  Within a reasonably small autonomous system or otherwise
   restricted area maybe some kind of interior routing solution could be
   used to assist mobility anchor relocation.




Patil, et al.              Expires May 3, 2012                  [Page 9]


Internet-Draft                DMM with MIP6                 October 2011


8.  Potential future work

   As the MEXT working group evolves and transitions to one that is
   focused on dealing with distributed mobility, there is a need to
   clearly understand the drivers for such an approach and whether these
   could be dealt with via a framework that uses existing mobility
   protocols and extensions and can be applied in a manner that deals
   with those concerns.

   One of the key efforts could be in understanding the key concerns
   driving the need for a distributed mobility solution and identifying
   various approaches using existing protocols and extensions to
   overcome them.

   1.  Work on the generic solution for anchor relocation.  This might
       be a architecture describing work, rather than protocol work.  I
       believe we have most protocols already in place but not glued
       together.

   2.  Work on address selection beyond RFC 5014 (with coloring i.e. the
       end host stack knows properties of the prefix it got) and rapid
       deprecation/renumbering of prefixes (needed when CoAs change and
       applications try to use CoA for something local).  This could
       potentially be new protocol work an containers for coloring
       prefixes (RA and DHCPv6) and how to handle local prefix
       deprecation during handovers.

   3.  Work on localized mobility that does not involve signaling with
       gateways or "mobility signaling".  This could lead to work below
       the IP layer, e.g. intra-AS mobility is handled using some
       interior routing protocol enhancement.


9.  IANA Considerations

   This document has no requests to IANA.


10.  Security Considerations

   This document is a discussion of distributed mobility solutions.
   Some of the approaches that are considered for deployment do have
   security implications.  However since the approaches being discussed
   are based on existing mobility specifications developed within the
   IETF, they have already been reviewed for security.  This document
   does not raise any new security concerns.





Patil, et al.              Expires May 3, 2012                 [Page 10]


Internet-Draft                DMM with MIP6                 October 2011


11.  Summary and Conclusion

   Distributed mobility is a way of deploying mobility protocols that
   minimise the issues that arise from a centralized gateway centric
   approach that comes from a hierarchical model.  As the amount of
   traffic in a network grows, operators are less willing to transport
   all the traffic to a centralized gateway just for the sake of
   enabling mobility.  The mobility models have to evolve to meet the
   changing environment of mobile networks and traffic patterns.

   Using many of the extensions and protocols that have been defined for
   Mobile IPv6 it is possible to deploy a mobility solution that meets
   the criteria of distributed mobility architecture.  The concerns fo a
   centralized gateway approach can be addressed using deployment
   techniques effectively.


12.  Informative References

   [I-D.ietf-netext-pmip6-lr-ps]
              Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
              Routing Problem Statement",
              draft-ietf-netext-pmip6-lr-ps-06 (work in progress),
              March 2011.

   [I-D.ietf-netext-redirect]
              Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
              "Runtime LMA Assignment Support for Proxy Mobile IPv6",
              draft-ietf-netext-redirect-12 (work in progress),
              October 2011.

   [I-D.ietf-netlmm-mip-interactions]
              Giaretta, G., "Interactions between PMIPv6 and MIPv6:
              scenarios and related issues",
              draft-ietf-netlmm-mip-interactions-07 (work in progress),
              October 2010.

   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4433]  Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4
              Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006.




Patil, et al.              Expires May 3, 2012                 [Page 11]


Internet-Draft                DMM with MIP6                 October 2011


   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              September 2007.

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              January 2011.

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089,
              January 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.


Authors' Addresses

   Basavaraj Patil (editor)
   Nokia
   6021 Connection drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nokia.com








Patil, et al.              Expires May 3, 2012                 [Page 12]


Internet-Draft                DMM with MIP6                 October 2011


   Carl Williams
   MCSR Labs
   Palo Alto, CA  94306
   USA

   Email: carlw@mcsr-labs.org


   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   FINLAND

   Email: jouni.nospam@gmail.com




































Patil, et al.              Expires May 3, 2012                 [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/