[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,Editor
  Internet Draft                                                   K. Leung
  Document: draft-ietf-netlmm-nohost-ps-01.txt                   P. Roberts
                                                                 K. Nishida
                                                                G. Giaretta
                                                                 M. Liebsch
  
  
  Expires: October, 2006                                        April, 2006
  
  
                        Problem Statement for IP Local Mobility
                         (draft-ietf-netlmm-nohost-ps-01.txt)
  
  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
     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.
  
  Abstract
  
     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.......................................4
     3.0  Scenarios for Localized Mobility Management......................6
     4.0  Problems with Existing Solutions.................................7
     5.0  Security Considerations..........................................9
     6.0  Author Information...............................................9
     7.0  Informative References..........................................10
     8.0  IPR Statements..................................................10
  
  
     Kempf, et. al.               Expires October, 2006               [Page 1]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
     9.0  Disclaimer of Validity..........................................11
     10.0 Copyright Notice................................................11
  
  
   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 October 2006              [Page 2]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 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.
  
        Localized Mobility Management Protocol
          A protocol that supports localized mobility management.
  
        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 may also allow the mobile node to maintain a
          mapping between a permanent address and a temporary address on the
          local network for rendezvous with nodes that want to initiate a
          connection. 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 maintains a permanent
          address and a mapping between the permanent address and the local
          temporary address where the mobile node happens to be currently
          located. The Global Mobility Anchor Point may be used for purposes of
          rendezvous and possibly traffic forwarding. For Mobile IPv6 [1], this
          is the home agent. For HIP [4], this may be the rendezvous server. For
          Mobike [5], this is the VPN tunnel gateway in the home network.
  
        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.
  
  
  
     Kempf, et. al.                 Expires October 2006              [Page 3]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
   2.0 The Local Mobility Problem
  
     The local mobility problem is restricted to providing IP mobility management
     for mobile nodes within an access network. The access network 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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Kempf, et. al.                 Expires October 2006              [Page 4]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
                    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 \
            ------     ------   ------       ------     ------
  
             +--+      +--+      +--+         +--+
             |MN|----->|MN|----->|MN|-------->|MN|
             +--+      +--+      +--+         +--+
              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 permanent address and temporary local address at the global
     mobility anchor point, or even end to end by changing the temporary local
     address directly at the node with which the mobile node is corresponding. 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:
  
  
     Kempf, et. al.                 Expires October 2006              [Page 5]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
        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 temporary local address and are
           essentially dropped.
        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 permanent to temporary local address mapping. The
           signaling volume may negatively impact wireless bandwidth usage and
           real time service performance.
        3) Location privacy.  The change in temporary local 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
     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
     attractive.
  
  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
  
     Kempf, et. al.                 Expires October 2006              [Page 6]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
     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
  
     Existing solutions for localized mobility management fall into three
     classes:
  
     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 mobile node 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
        network.
     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.
  
     Kempf, et. al.                 Expires October 2006              [Page 7]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
     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
        scalability.
     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
        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
     solution. Mobility routing anchor points within the backbone network
     maintain a collection of routes for individual mobile nodes. The routes
     point to the access routers on which mobile nodes currently are located.
     Packets for the mobile node are routed to and from the mobile node through
     the mobility anchor point. When a mobile node moves from one access router
     to another, the access routers send a route update to the mobility anchor
     point. While some mobile node involvement is necessary and expected for
     generic mobility functions such as movement detection and to inform the
     access router about mobile node movement, no specific mobile node to network
     protocol will be required for localized mobility management itself.
  
     The advantages that this solution has over the Solutions 1 through 3 above
     are as follows:
  
     1) Compared with Solution 1, a network-based solution requires no localized
        mobility management support on the mobile node and is independent of
        global mobility management protocol, so it can be used with any or none
  
     Kempf, et. al.                 Expires October 2006              [Page 8]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
        of the existing global mobility management protocols. The result is a
        more modular mobility management architecture that better accommodates
        changing technology and market requirements.
     2) Compared with Solution 2, an IP level network-based localized mobility
        management solution works for link protocols other than Ethernet, and for
        wide area networks.
     3) Compared with Solution 3, the framework described above for network-based
        localized mobility management only requires the involvement of the access
        routers and the mobility anchor. All other routers within the localized
        mobility management domain do not need to handle host routes, making the
        architecture more scalable. In addition, because updating the routes
        requires communication between only two routers, propagation of routes on
        handover is likely to be much faster.
  
   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
        USA
        Phone: +1 408 451 4711
        Email: kempf@docomolabs-usa.com
  
        Kent Leung
        Cisco Systems, Inc.
        170 West Tasman Drive
        San Jose, CA 95134
        USA
        EMail: kleung@cisco.com
  
        Phil Roberts
        Motorola Labs
        Schaumberg, IL
        USA
        Email: phil.roberts@motorola.com
  
        Katsutoshi Nishida
        NTT DoCoMo Inc.
        3-5 Hikarino-oka, Yokosuka-shi
        Kanagawa,
        Japan
        Phone: +81 46 840 3545
  
     Kempf, et. al.                 Expires October 2006              [Page 9]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
        Email: nishidak@nttdocomo.co.jp
  
        Gerardo Giaretta
        Telecom Italia Lab
        via G. Reiss Romoli, 274
        10148 Torino
        Italy
        Phone: +39 011 2286904
        Email: gerardo.giaretta@tilab.com
  
        Marco Liebsch
        NEC Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Germany
        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,
          2005.
      [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-
          info/23882.htm.
  
  
   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
  
  
     Kempf, et. al.                 Expires October 2006              [Page 10]
  

     Internet Draft      Problem Statement for IP Local Mobility   April, 2006
  
     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.
  
     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
     IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
     SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
     TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
     LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
     INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
     FOR A PARTICULAR PURPOSE.
  
   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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Kempf, et. al.                 Expires October 2006              [Page 11]
  

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