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

Versions: (draft-kempf-netlmm-nohost-ps) 00 01 02 03 04 05 RFC 4830

                                                                  J. Kempf,
  Internet Draft                                                   K. Leung
  Document: draft-ietf-netlmm-nohost-ps-00.txt                   P. Roberts
                                                                 K. Nishida
                                                                G. Giaretta
                                                                 M. Liebsch
  Expires: August, 2006                                      Feburary, 2006
                        Problem Statement for IP Local Mobility
  Status of this Memo
     By  submitting  this  Internet-Draft,  each  author  represents  that  any
     applicable patent or other IPR claims of which he or she is aware have been
     or will be disclosed, and any of which he or she becomes aware will be
     disclosed, in accordance with Section 6 of 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
     The  list  of  Internet-Draft  Shadow  Directories  can  be  accessed  at
     In this document, the well-known problem of localized mobility management
     for IP link handover is given a fresh look. After a short discussion of the
     problem and a couple of scenarios, the principal shortcomings of existing
     solutions are discussed.
  Table of Contents
     1.0  Introduction.....................................................2
     2.0  The Local Mobility Problem.......................................3
     3.0  Scenarios for Localized Mobility Management......................6
     4.0  Most Serious Problems with Existing Solutions....................6
     5.0  Security Considerations..........................................8
     6.0  Author Information...............................................8
     7.0  Informative References...........................................9
     Kempf, et. al.               Expires August, 2006               [Page 1]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
     8.0  IPR Statements...................................................9
     9.0  Disclaimer of Validity..........................................10
     10.0 Copyright Notice................................................10
   1.0 Introduction
     Localized mobility management has been the topic of much work in the IETF
     for some time, and it may seem as if little remains to be said on the topic.
     The experimental protocols developed from previous work, namely FMIPv6 [1]
     and HMIPv6[2], involve host-based solutions that mimic to a greater or
     lesser extent the approach taken by Mobile IPv6 [3] for global mobility
     management.  However,  recent  developments  in  the  IETF  and  the  WLAN
     infrastructure market suggest that it may be time to take a fresh look at
     localized mobility management. Firstly, new IETF work on global mobility
     management protocols that are not Mobile IPv6, such as HIP [4] and Mobike
     [5], suggests that future wireless IP nodes may support a more diverse set
     of  global  mobility  protocols.  Secondly,  the  success  in  the  WLAN
     infrastructure market of WLAN switches, which perform localized mobility
     management without any host stack involvement, suggests a possible design
     paradigm that could be used to accommodate other global mobility management
     options on the mobile node while reducing host stack software complexity and
     expanding the range of mobile nodes that could be accommodated.
     This document briefly describes the local mobility problem and a few
     scenarios where localized mobility management would be desirable. Then, it
     describes the two most serious problems with existing protocols: the
     requirement for host stack support, and the complex security interactions
     required between the mobile node and the access network. More detailed
     requirements and gap analysis for existing protocols can be found in [6].
  1.1 Terminology
     Mobility terminology in this draft follows that in RFC 3753 [7], with the
     addition of some new and revised terminology given here:
        IP Link
          A set of routers, mobile nodes, and wireless access points that share
          link broadcast capability or its functional equivalent. This definition
          covers one or multiple access points under one or several access
          routers. In the past, such a set has been called a subnet, but this
          term is not strictly correct for IPv6, since multiple subnet prefixes
          can be assigned to an IP link in IPv6.
        Access Network (revised)
          An Access Network consists of following three components: wireless or
          other access points, access routers, access network gateways which form
          the boundary to other networks and may shield other networks from the
          specialized routing protocols (if any) run in the Access Network; and
          (optionally) other internal access network routers which may also be
          needed in some cases to achieve a specialized routing protocol.
        Local Mobility (revised)
     Kempf, et. al.                 Expires August 2006              [Page 2]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
          Local Mobility is mobility over a restricted area of the network
          topology. Note that, although the area of network topology over which
          the mobile node moves may be restricted, the actual geographic area
          could be quite large, depending on the mapping between the network
          topology and the wireless coverage area.
        Localized Mobility Management
          Localized Mobility Management is a generic term for protocols dealing
          with  IP  mobility  management  confined  within  the  access  network.
          Localized mobility management signaling is not routed outside the
          access  network,  although  a  handover  may  trigger  Global  Mobility
          Management signaling. Localized mobility management protocols exploit
          the locality of movement by confining movement related changes to the
          access network.
        Global Mobility Protocol
          A Global Mobility Protocol is a mobility protocol used by the mobile
          node to change the global, end-to-end routing of packets when movement
          causes a topology change and thus invalidates a global unicast address
          on the local IP link currently in active use by the mobile node. The
          Global Mobility Protocol allows the mobile node to maintain a mapping
          between a permanent rendezvous or home address and a temporary care-of
          address for rendezvous with nodes that want to initiate a connection,
          and it may also provide direct routing through the rendezvous node
          and/or optimized routing directly between correspondent nodes and the
          local address. Typically, this protocol will be Mobile IPv6 [1] but it
          could also be HIP [4] or Mobike [5] (Note: although Mobike is not
          considered a mobility management protocol in general, for purposes of
          this document, it will be so considered because it manages the address
          map and routing between a fixed VPN endpoint address and a changing
          local address).
        Global Mobility Anchor Point
          A node in the network where the mobile node has its fixed home address
          that maintains the mapping between the home address and care-of address
          for purposes of rendezvous and possibly traffic forwarding. For Mobile
          IPv6 [1], this is the home agent. For HIP [4], this is the rendezvous
          server. For Mobike [5], this is the VPN tunnel gateway in the home
        Intra-Link Mobility
          Intra-Link Mobility is mobility between wireless access points within
          an IP Link. Typically, this kind of mobility only involves Layer 2
          mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No
          IP link configuration is required upon movement since the link does not
          change, but some IP signaling may be required for the mobile node to
          confirm whether or not the change of wireless access point also
          resulted in a change of IP link. If the IP link consists of a single
          access  point/router  combination,  then  this  type  of  mobility  is
          typically absent. See Figure 1.
   2.0 The Local Mobility Problem
     Kempf, et. al.                 Expires August 2006              [Page 3]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
     The local mobility problem is restricted to providing IP mobility management
     for mobile nodes within an access network. An access network consists of a
     group of access routers connected to wired or wireless access points on the
     downlink side and a wired IP core through one or more aggregation routers on
     the side that is routed toward the border router and the Internet. The
     aggregation routers function as an access network gateway, although in this
     case, there is no specialized routing protocol and the routers function as a
     standard IP routed network. This is illustrated in Figure 1, where the
     aggregation routers are designated as "AggR". Transitions between service
     providers in separate autonomous systems or across broader topological
     "boundaries" within the same service provider are excluded.
     Figure 1 depicts the scope of local mobility in comparison to global
     mobility. The Aggregation Routers AggR A1 and B1 are gateways to the access
     network. The Access Routers AR A1 and A2 are in Access Network A, B1 is in
     Access Network B. Note that it is possible to have additional aggregation
     routers between AggR A1 and AggR B1 and the access routers if the access
     network is large. Access Points AP A1 through A3 are in Access Network A, B1
     and B2 are in Access Network B. Other Aggregation Routers, Access Routers,
     and Access Points are also possible. The figure implies a star topology for
     the access network deployment, and the star topology is the primary one of
     interest since it is quite common, but the problems discussed here are
     equally relevant to ring or mesh topologies in which access routers are
     directly connected through some part of the network.
                    Access Network A         Access Network B
                        +-------+                +-------+
                        |AggR A1| (other AggRs)  |AggR B1| (other AggRs)
                        +-------+                +-------+
                         @    @                     @
                        @      @                    @
                       @        @                   @
                      @          @                  @
                     @            @                 @
                    @              @                @
                 +-----+       +-----+            +-----+
                 |AR A1|       |AR A2|(other ARs) |AR B1|  (other ARs)
                 +-----+       +-----+            +-----+
                    *             *                  *
                   * *            *                 * *
                  *   *           *                *   *
                 *     *          *               *     *
                *       *         *              *       *
               *         *        * (other APs) *         * (other APs)
              /\         /\       /\           /\         /\
             /AP\       /AP\     /AP\         /AP\       /AP\
            / A1 \     / A2 \   / A3 \       / B1 \     / B2 \
            ------     ------   ------       ------     ------
             +--+      +--+      +--+         +--+
             +--+      +--+      +--+         +--+
     Kempf, et. al.                 Expires August 2006              [Page 4]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
              Intra-link    Local      Global
               Mobility    Mobility   Mobility
                 Figure 1. Scope of Local and Global Mobility Management
     As shown in the figure, a global mobility protocol is necessary when a
     mobile node (MN) moves between two access networks. Exactly what the scope
     of the access networks is depends on deployment considerations. Mobility
     between two access points under the same access router constitutes Intra-
     link mobility, and is typically handled by Layer 2 mobility protocols (if
     there is only one access point/cell per access router, then intra-link
     mobility may be lacking). Between these two lies local mobility. Local
     mobility occurs when a mobile node moves between two access points connected
     to two different access routers.
     Global mobility protocols allow a mobile node to maintain reachability when
     a change between access routers occurs, by updating the address mapping
     between the home address and care-of address at the global mobility anchor
     point, or even end to end by changing the care-of address directly at the
     correspondent node. A global mobility management protocol can therefore be
     used between access routers for handling local mobility. However, there are
     three well-known problems involved in using a global mobility protocols for
     every transition between access routers. Briefly, they are:
        1) Update  latency.    If  the  global  mobility  anchor  point  and/or
           correspondent node (for route optimized traffic) is at some distance
           from the mobile node's access network, the global mobility update may
           require a considerable amount of time, during which time packets
           continue to be routed to the old care-of address and are essentially
        2) Signaling overhead.  The amount of signaling required when a mobile
           node moves from one IP link to another can be quite extensive,
           including all the signaling required to configure an IP address on the
           new link and global mobility protocol signaling back into the network
           for changing the home to care-of address mapping. The signaling volume
           may negatively impact wireless bandwidth usage and real time service
        3) Location privacy.  The change in care-of address as the mobile node
           moves exposes the mobile node's topological location to correspondents
           and potentially to eavesdroppers. An attacker that can assemble a
           mapping between subnet prefixes in the mobile node's access network
           and geographical locations can determine exactly where the mobile node
           is located. This can expose the mobile node's user to threats on their
           location privacy.
     These problems suggest that a protocol to localize the management of
     topologically small movements is preferable to using a global mobility
     management protocol on each IP link move. In addition to these problems,
     localized mobility management can provide a measure of local control, so
     mobility management can be tuned for specialized local conditions. Note also
     that if localized mobility management is provided, it is not strictly
     required for a mobile node to support a global mobility management protocol
     since  movement  within  a  restricted  IP  access  network  can  still  be
     Kempf, et. al.                 Expires August 2006              [Page 5]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
     accommodated. Without such support, however, a mobile node experiences a
     disruption in its traffic when it moves beyond the border of the localized
     mobility management domain.
   3.0 Scenarios for Localized Mobility Management
     There are a variety of scenarios in which localized mobility management is
  3.1 Large Campus with Diverse Physical Interconnectivity
     One scenario where localized mobility management would be attractive is for
     a campus wireless LAN deployment in which parts of the campus are connected
     by links that are other than 802.3 or in which it is not possible to cover
     the campus by one VLAN. In this case, the campus is divided into separate IP
     links each served by one or more access routers. This kind of deployment is
     served today by wireless LAN switches that co-ordinate IP mobility between
     them, effectively providing localized mobility management at the link layer.
     Since the protocols are proprietary and not interoperable, any deployments
     that require IP mobility necessarily require switches from the same vendor.
  3.2 Advanced Cellular Network
     Next generation cellular protocols such as 802.16e [8] and Super 3G/3.9G [9]
     have the potential to run IP deeper into the access network than the current
     3G cellular protocols, similar to today's WLAN networks. This means that the
     access network can become a routed IP network. Interoperable localized
     mobility management can unify local mobility across a diverse set of
     wireless protocols all served by IP, including advanced cellular, WLAN, and
     personal area wireless technologies such as UWB and Bluetooth. Localized
     mobility management at the IP layer does not replace Layer 2 mobility (where
     available) but rather complements it. A standardized, interoperable
     localized mobility management protocol for IP can remove the dependence on
     IP layer localized mobility protocols that are specialized to specific link
     technologies or proprietary, which is the situation with today's 3G
     protocols. The expected benefit is a reduction in maintenance cost and
     deployment complexity. See [6] for a more detailed discussion of the
     requirements for localized mobility management.
  3.3 Picocellular Network with Small But Node-Dense IP Links
     Future radio link protocols at very high frequencies may be constrained to
     very short, line of sight operation. Even some existing protocols, such as
     UWB and Bluetooth, are designed for low power, short range operation. For
     such protocols, extremely small picocells become more practical. Although
     picocells do not necessarily imply "pico IP links", wireless sensors and
     other advanced applications may end up making such picocellular type
     networks node-dense, requiring subnets that cover small geographical areas,
     such as a single room. The ability to aggregate many subnets under a
     localized mobility management scheme can help reduce the amount of IP
     signaling required on IP link movement.
   4.0 Problems with Existing Solutions
     Kempf, et. al.                 Expires August 2006              [Page 6]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
     Existing solutions for localized mobility management fall into three
     1) Interoperable IP level protocols that require changes to the mobile node's
        IP stack and handle localized mobility management as a service provided to
        the host by the access network,
     2) Link specific or proprietary protocols that handle localized mobility for
        any mobile node but only for a specific type of link layer, namely 802.11
        running on an 802.3 wired network backhaul.
     3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and
        updating the host routes when the mobile node moves.
     For Solution 1, the following are specific problems:
     1) The host stack software requirement limits broad usage even if the
        modifications are small. The success of WLAN switches indicates that
        network operators and users prefer no host stack software modifications.
        This preference is likely to be independent of the lack of widespread
        Mobile IPv4 deployment, since it is much easier to deploy and use the
     2) Future mobile nodes may choose other global mobility management
        protocols, such as HIP or Mobike. The existing localized mobility
        management solutions all depend on Mobile IP or derivatives.
     3) Existing localized mobility management solutions do not support both IPv4
        and IPv6.
     4) Security for the existing localized mobility management solutions
        requires complex security associations with network elements for no
        improvement in security over what is available if localized mobility
        management is not used. In addition to the additional signaling required
        to set up these security associations, provisioning a mobile node with
        credentials for roaming to all the access networks where the mobile node
        might end up may prove difficult, acting as a barrier to deployment.
     Solution 2 has the following problems:
     1) Existing solutions only support WLAN networks with Ethernet backhaul and
        therefore are not available for advanced cellular networks or
        picocellular protocols, or other types of wired backhaul.
     2) Each WLAN switch vendor has its own proprietary protocol that does not
        interoperate with other vendor's equipment.
     3) Because the solutions are based on layer 2 routing, they may not scale up
        to a metropolitan area, or local province.
     Solution 3 has the following problems:
     1) Each router in the localized mobility management domain is required to
        maintain a host route table and to search the host route table for
        routing each packet, limiting the memory and processing power
     2) After handover, until host routes propagate back along the current path
        of traffic to the localized mobility management domain border, traffic
        packets for the mobile node are sent to the old router, causing the
        packets to drop. Since IGPs typically propagate routing updates through
     Kempf, et. al.                 Expires August 2006              [Page 7]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
        flooding, the delay in host route propagation also limits the topological
        span of the localized mobility management domain.
     3) Rapid movement by the mobile node faster than the rate at which flooding
        can propagate host routes could lead to a cascading series of host route
        messages that never stabilize.
     Having an interoperable, standardized localized mobility management protocol
     that is scalable to topologically large networks, but requires no host stack
     involvement for localized mobility management is a highly desirable
   5.0 Security Considerations
     Localized mobility management has certain security considerations, one of
     which - need for access network to mobile node security - was touched on in
     this document. Existing localized mobility management solutions increase the
     need for mobile node to access network signaling and provisioning of the
     mobile node with credentials without increasing the security beyond what is
     available if no localized mobility management solution is used. A more
     complete discussion of the security requirements for localized mobility
     management can be found in [6].
   6.0 Author Information
        James Kempf
        DoCoMo USA Labs
        181 Metro Drive, Suite 300
        San Jose, CA 95110
        Phone: +1 408 451 4711
        Email: kempf@docomolabs-usa.com
        Kent Leung
        Cisco Systems, Inc.
        170 West Tasman Drive
        San Jose, CA 95134
        EMail: kleung@cisco.com
        Phil Roberts
        Motorola Labs
        Schaumberg, IL
        Email: phil.roberts@motorola.com
        Katsutoshi Nishida
        NTT DoCoMo Inc.
        3-5 Hikarino-oka, Yokosuka-shi
        Phone: +81 46 840 3545
        Email: nishidak@nttdocomo.co.jp
        Gerardo Giaretta
     Kempf, et. al.                 Expires August 2006              [Page 8]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
        Telecom Italia Lab
        via G. Reiss Romoli, 274
        10148 Torino
        Phone: +39 011 2286904
        Email: gerardo.giaretta@tilab.com
        Marco Liebsch
        NEC Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Phone: +49 6221-90511-46
        Email: marco.liebsch@ccrle.nec.de
   7.0 Informative References
      [1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 4068, July,
      [2] Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility Management,"
          RFC 4140, August, 2005.
      [3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6,"
          RFC 3775.
      [4] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host
          Identity Protocol", Internet Draft, work in progress.
      [5] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol",
          Internet Draft, work in progress.
      [6] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., and
          Nishita, K.., "Requirements and Gap Analysis for Localized Mobility
          Management", Internet Draft, work in progress.
      [7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753,
          June, 2004.
      [8] IEEE, "Air Interface for Mobile Broadband Wireless Access Systems",
          802.16e, 2005.
      [9] 3GPP, "3GPP System Architecture Evolution: Report on Technical Options
          and Conclusions", TR 23.882, 2005, http://www.3gpp.org/ftp/Specs/html-
   8.0 IPR Statements
     The  IETF  takes  no  position  regarding  the  validity  or  scope  of  any
     Intellectual Property Rights or other rights that might be claimed to
     pertain to the implementation or use of the technology described in this
     document or the extent to which any license under such rights might or might
     not be available; nor does it represent that it has made any independent
     effort to identify any such rights. Information on the procedures with
     respect to rights in RFC documents can be found in BCP 78 and BCP 79.
     Kempf, et. al.                 Expires August 2006              [Page 9]

     Internet Draft      Problem Statement for IP Local Mobility   Feburary, 2006
     Copies of IPR disclosures made to the IETF Secretariat and any assurances of
     licenses to be made available, or the result of an attempt made to obtain a
     general license or permission for the use of such proprietary rights by
     implementers or users of this specification can be obtained from the IETF
     on-line IPR repository at http://www.ietf.org/ipr.
     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary rights that
     may cover technology that may be required to implement this standard.
     Please address the information to the IETF at ietf-ipr@ietf.org.
   9.0 Disclaimer of Validity
     This document and the information contained herein are provided on an "AS
   10.0   Copyright Notice
     Copyright (C) The Internet Society (2006).  This document is subject to the
     rights, licenses and restrictions contained in BCP 78, and except as set
     forth therein, the authors retain all their rights.
   11.0   Changes in 01 (remove before publication)
        - Added "revised" to those definitions in Section 1.1 that are revised
        from RFC 3753.
        - Changed "mobile host" to "mobile node" where the wireless device was
        meant, to avoid confusion about whether mobile routers are supported.
        - Added discussion in Section 4 of problems involving using a standard
        IGP for host route distribution.
     Kempf, et. al.                 Expires August 2006              [Page 10]

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/