[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                 Eric Njedjou
                                                      Julien Riera
Internet Draft                                       France Telecom
Expires November 2006                                 May 2006

           Problem Statement for Global IP Mobility Management

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 a "work in progress."

The  list  of  current  Internet-Drafts  can  be  accessed  at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on November 2, 2006.

Copyright Notice

  Copyright © The Internet Society (2006)


  This document discusses the problem of global IP mobility
  management in a context where some mobile operators and service
  providers are looking for adequate solutions to the inter-system
  IP mobility problem. The document addresses the specific issue of
  moving between IP access domains that use different mobility
  management protocols and mechanisms. Indeed this type of movement
  would be an important subset of global IP mobility scenarios.

njedjou                  Expires November 2006                 [Page 1]

Internet-Draft             problem statement                   May 2006

Table of Contents

   1.      Introduction................................................2
   2.      Terminology.................................................4
   3.      Abbreviations...............................................6
   4.      Deployment scenarios considered.............................6
   4.1.    Movement between different access network systems
             assisted with a third party provider......................7
   4.2.    Movement within an integrated access network provider.......8
   5.      Issues and problems with Existing global IP mobility
             management (gmm)solutions................................10
   5.1.    Signaling volume over the radio............................10
   5.2.    Complexity of mobility management procedures...............11
   5.3.    Complexity of hosts........................................11
   5.4.    Network initiation of mobility.............................11
   5.5.    Terminal initiation of mobility............................12
   5.6.    Mobility between two heterogeneous mobility management
             domains owned by a same operator.........................12
   5.7.    Inter-system mobility in other SDOs........................15
   6.      Security Considerations....................................15
   7.      Conclusion.................................................15
   8.      References.................................................16
   9.      Acknowledgments............................................16
   10.     Authors Addresses..........................................16

  1.     Introduction

  Global mobility management protocols have been under design by the
  IETF for the past fifteen years or so (assuming the creation of
  the Mobile IP Working Group as a start). The basic goal pursued at
  the time of starting that effort, was the ability to continue an
  IP session when a host IP address had to change. The targeted IP
  sessions were those involving a transport level connection.

  No other motivation but to achieve session continuity has really
  been taken into account so far in defining the existing solutions
  for global IP mobility management. Effectively, the main goal has
  always been to hide the IP address change from the transport level
  as well as from the correspondent node perspective. In such a way,
  a host would keep its transport connection opened and continue to
  be reachable while moving.

  The functions achieved were;
     . Updating the network of the host IP configuration change
     . Having a mobility anchor node perform the route update (upon
       moving node alert) or notify correspondents that the moving
       host care-of address had changed

Njedjou                  Expires November 2006                 [Page 2]

Internet-Draft             problem statement                   May 2006

     . having a mapping on the host between a current and permanent
       address to deliver packet to applications
   Solutions as Mobile IP or HIP operate on that pattern.

  Actually, global mobility management architectures and protocols
  at IP layer have grown in more or less a parallel to those
  designed in other SDOs as 3GPP where other considerations were
  taken into account aside that of just continuing the session of a
  user. Indeed 3GPP would be motivated by other considerations as
  for example the need for the provider to control the selection of
  the target access network of attachment.
  And still, future global mobility systems will tend to marry
  existing mechanisms from different standardization actors (IETF,
  3GPP, IEEE802…) built with different purposes and motivations.
  This tendency will grow even wider as services will move to be
  all-IP based and access agnostic.

  With the previous picture taking place, there is a growing feeling
  that the match between these mobility mechanisms built in these
  different SDOs is far from being perfect and suitable. This is
  especially true when considering some market oriented requirements
  as can have;
     . Mobile operators owning several access networks of different
       types that they want to make cooperate to provide their
       users with global mobility
     . Third parties operators that want to provide IP mobility to
       customers, regardless of the operators to which these
       customers are subscribed for the accesses.

  Indeed the fact that an IP session handover has to be seamless
  should not be the only motivation when solving the global mobility
  problem. What appears as a simple movement actually involves a lot
  of external factors. While ensuring seamless continuity for the
  user, other objectives are to be fulfilled. Such objectives can be
  as numerous as:

     . Judiciously using the "newly" available radio capacity
       (Wifi, Wimax…) to relieve cellular systems and provide
       multimedia services;
     . Guaranteeing service level for the users by helping them
       determine the best system for the service they want to
       access to;
     . Optimizing the use of the radio resources (especially on
       cellular), so as to dedicate the radio spectrum to serving
       more data/voice by lowering the signaling overhead;
     . Making  integrated  (and  therefore  already  composite)
       architectures less complex, as well as minimizing protocols
       to render overall systems more scalable;
     . Lowering requirements and constraints on hosts for an easier
       support of inter-system mobility.

Njedjou                  Expires November 2006                 [Page 3]

Internet-Draft             problem statement                   May 2006

  Some of the previous bullets points basically require that the
  global mobility management system be network initiated/operated
  while other could be met independently of the mobility operation
  Therefore an IP mobility solution designed to enable the previous
  requirements should fit both terminal and network initiation and
  operation schemes. So that any service provider would be free to
  make the use of the solution they want, according to their
  architectures and services.

  Most of the listed requirements seem not to be in favor of the
  global mobility management solutions as they exist today. The
  remainder of this document is dedicated at developing the previous

2.   Terminology

  Terminology is an aspect of mobility management that is in
  constant change, because of often evolving requirements. The
  definitions précised below are wanted consensual enough not to
  confuse the reader.

  Aggregate router

  This is a specific router in an access network acting as its
  border router on the core network side.


  In this document, a care-of-address refers to an IP address
  temporarily acquired by a mobile host while visiting an IP access
  network, irrespective of which global mobility management protocol
  the host is running. Therefore, a host may have a care-of-address
  without running MIP. Coming revisions of this document might
  suggest an alternative expression to avoid ambiguity.

  IP location update

  This is a generic procedure whereby a host informs a mobility
  anchor in the network or a correspondent located anywhere on the
  internet that it has a new active care-of-address and therefore a
  new IP location. This procedure is called registration in Mobile
  IPv4 and re-association in HIP.

  Comprehensive Mobility management

Njedjou                  Expires November 2006                 [Page 4]

Internet-Draft             problem statement                   May 2006

  RFC 3753 defines local and global mobility management but the
   notion of mobility management itself is not defined. For the
   purposes of this document, comprehensive mobility management will
   be defined as the process of performing and sequencing the
   following actions;
     . Collect information from terminal, Radio Access Points and
       Resource Controllers to assess the need or opportunity for a
     . Choose a handover target, as a result of deciding the next
       Radio Access Network and Point of attachment based on
       collected information, QoS needs and other policies.
     . Execute the handover on the terminal. This generally
       consists in switching between radio links, preparing the IP
       configuration over the new link and performing the IP
       location update.
   This definition does not make any assumption of which side between
   the network and the terminal decides of the handoff target.

   Global IP mobility management

   IP Mobility management is said to be global in this document
   whenever it involves a mobile host that is moving between IP
   domains that use different mobility procedures and protocols.
   Heterogeneous access networks would basically constitutes such IP
   domains. These domains can be part of the same administrative
   boundaries, eg an operator integrating several access networks
   providers or belong to different network administrations. With
   this definition an UMTS/WLAN IP service transition will be global,
   as well as will be a movement between a NETLMM operated domain and
   a 3GPP LTE domain.

   Network global IP mobility management

   A global mobility management initiated or operated by the network

   Local IP mobility management

   Mobility management is said to be local whenever it involves a
   mobile host moving
     . Within an IP domain using a single mobility management
     . Between two IP domains that use the same mobility management
        procedures and protocols.
     With this definition, the movement of a host within a Wlan or
     Wimax domain will be considered local. Indeed, in such domains,
     a single IP mobility management protocol would basically be
     used. Also will be considered local, a transition between two
     NETLMM domains.

Njedjou                  Expires November 2006                 [Page 5]

Internet-Draft             problem statement                   May 2006

   Mobility anchor

  A mobility anchor is an IP node that either:
     . Performs the forwarding and path update of IP packets
       destined to the moving host
     . notifies correspondents that the moving host care-of address
       has changed
   With this definition, a mobility anchor only participates to the
   goal of making the moving host reachable. The Home Agent of MIP
   and the Rendez-Server of HIP are examples of defined mobility
   anchors. However this terminology does not necessarily relates to
   these nodes.

   Inter-System Mobility Agent

   This is a function typically located either in an integrated
   access operator network or in the terminal and that helps deciding
   of the mobile host target system (step 2 of comprehensive mobility
   management) based on several criteria. Such an agent is used in
   this document to illustrate the global mobility management
   Considerations associated with selection criteria are clearly out
   of scope.

3.   Abbreviations

   gmm: global IP mobility management
   NETLMM: network localized IP mobility management
   LTE: Long Term Evolution of the radio access network currently
   prepared by 3GPP
   MIH: Media Independent Handover. This is a functionality of the
   Draft IEEE 802.21 specification
   IMS: IP Multimedia Subsytem of 3GPP

4.   Deployment scenarios considered

   As said earlier, global mobility refers to the movement performed
   by a host as it changes its point of attachment from an IP domain
   to another that has a different mobility procedure.
   Such movements will either occur between two access networks of
   different providers or also between two access networks owned by
   the same service provider. The problem raised in this document
   addresses both categories of movement.

Njedjou                  Expires November 2006                 [Page 6]

Internet-Draft             problem statement                   May 2006

  4.1.       Movement between different access network systems assisted
   with a third party provider.

   The following figure depicts a deployment model where a host is
   moving between two access networks (as described previously)
   operated by different providers. Such providers will usually not
   cooperate for the purpose of comprehensive mobility management as
   defined earlier, nor cooperate with a third party that will serve
   the mobility between those access networks. Such a third party
   will typically own the IP mobility anchor.

                                   *     *     *
                               *                  *
                              *    | Mobility |    *
                                   |  Anchor  |
                               *   +----------+   *
                                   *     *    *
                                    *   *   *
                                 *             *
                                *    Internet   *
                                 *               *
                               *     *   *  *     *
                              *                    *
                             *                      *
                            *                        *
                        +-------+                +-------+
                        |AggR A1|                |AggR B1|
                        +-------+                +-------+
           AN A         @      @                     @       AN B
     Provider A        @        @                    @     Provider B
                      @          @                   @
                     @            @                  @
                 +-----+       +-----+            +-----+
                 |AR A1|       |AR A2|            |AR B1|
                 +-----+       +-----+            +-----+
                   * *            *                 * *
                 *     *          *               *     *
                *       *         *              *       *
               *         *        *             *         *
              /\         /\       /\           /\         /\
             /AP\       /AP\     /AP\         /AP\       /AP\
            / A1 \     / A2 \   / A3 \       / B1 \     / B2 \
            ------     ------   ------       ------     ------
                         |                     |
                         |                     |
                         |                     |

Njedjou                  Expires November 2006                 [Page 7]

Internet-Draft             problem statement                   May 2006

                        +--+                  +--+
                       +--+                  +--+

  Figure 1: example Deployment scenario for two access networks
   owned by different providers

   The terminal is in this case, the only entity in good position to
   initiate the mobility management functions. Indeed it is the only
   node capable of getting access networks information, necessary to
   decide of the movement. Global mobility management solutions as
   they are specified today (i.e basically host based) well apply to
   this deployment model. However, as said earlier, the right
   mobility architecture should be able to accommodate all deployment
   models and mobility controls schemes.

  4.2.       Movement within an integrated access network provider

   The following figure depicts a classical deployment scenario for
   an operator that is owner of several access networks that it can
   make cooperate, because of the need to ensure the goals and
   requirements as listed in the introduction.

                                    *   *
                                 *          *
                              *                *
                            *    + ----------+   *
                          *      |  Mobility  |    * Operator network
                                 |  function  |
                                 + ----------+
                          *                         *
                                 +---------- +
                           *     |IP Mobility|     *
                                 |  Anchor   |
                            *    +---------- +   *

                               *               *
                             *     *   *  *     *
                            *                    *
                           *                      *
                          *                        *
                      +-------+                +-------+
                      |AggR A1|                |AggR B1|
                      +-------+                +-------+
         AN A         @      @                     @       AN B
                     @        @                    @

Njedjou                  Expires November 2006                 [Page 8]

Internet-Draft             problem statement                   May 2006

                    @          @                   @
                   @            @                  @
               +-----+       +-----+            +-----+
               |AR A1|       |AR A2|            |AR B1|
               +-----+       +-----+            +-----+
                 * *            *                 * *
               *     *          *               *     *
              *       *         *              *       *
             *         *        *             *         *
            /\         /\       /\           /\         /\
           /AP\       /AP\     /AP\         /AP\       /AP\
          / A1 \     / A2 \   / A3 \       / B1 \     / B2 \
          ------     ------   ------       ------     ------
                       |                     |
                       |                     |
                       |                     |
                      +--+                  +--+
                      +--+                  +--+

       Figure 2: Deployment scenario for an integrated operator

  4.2.1.         Inter-System Mobility management

   In such an integrated operator scenario, the network is in good
   position to initiate mobility management. It is specifically able
   to watch over the capacity of every system and monitor terminal
   conditions so as to take the best decision for the user target. An
   Inter-System Mobility function would basically perform this IP
   handover preparation.

   Specifications as the 802.21 draft would see the MIH Point of
   Service into such a function (with a corresponding entity in the
   terminal and radio access points). Note that this inter-system
   mobility function can be co-located to the node acting as the IP
   Mobility anchor.
   However these considerations are informative only and out of scope
   here. IP mobility is clearly the focus of this document. However
   the authors intent is to make the point that IP mobility can not
   be discussed regardless of the inter-system mobility architectures
   that are likely to be deployed.

  4.2.2.         Knowledge of host care-of address change by the network

   When a core network is able to federate the IP domains,
   information can be easily exchanged between these domains and such
   a core network, belonging to the provider. Therefore, the current
   IP configuration of a host can be known in the provider home

Njedjou                  Expires November 2006                 [Page 9]

Internet-Draft             problem statement                   May 2006

   Effectively IP configuration assignment schemes of a provider
   would be managed from within the provider home network.

   On the event of a handover to another IP access domain of the
   integrated provider, the target IP configuration of the host
   (including the care-of-address to use) would be prepared in the
   home network so that the host would not have to make any
   notification back upon receiving that new configuration.
   However a mobility anchor would still have to perform the routing
   update  consequently  to  the  host  changing  its  active  IP
   connectivity from one domain to another.

   Therefore, the explicit IP location update as well as the
   necessity to keep association states between hosts and mobility
   anchor of existing global mobility solutions (Registration and REA
   procedures of MIP or HIP) can be avoided in this model. The next
   paragraph precisely describes the problem encountered when
   resorting to such an explicit IP location update and association
   with a IP mobility anchor.

   It is to be made explicitly clear that any specific procedure by
   which the network can be aware of the terminal new and old IP
   configuration is not assumed. Every implementation of the
   deployment model can figure out how they want to get the

5.   Issues and problems with Existing global IP mobility management

   This paragraph captures the reasons why classical gmm solutions
   are problematic with regards to driving requirements as presented
   in the introduction.

  5.1.       Signaling volume over the radio

   Global IP mobility management solutions known to date do not
   guarantee an efficient use of the radio capacity, especially with
   the need to associate to a mobility anchor and perform frequent
   explicit re-associations.
   Terminals are required to support more and more control planes as
   they are becoming convergent. A single terminal would have to
   support, multiple radios, as well as multiple authentications
   protocols, inter-system mobility, IMS… that all generate fair
   amount of signaling.

   Aside of IP session continuity, integrated mobility architecture
   will also have to address such transitions as VoIP to circuit
   switched voice. So will multi-systems terminals. This additional
   type of session continuity requires specific mobility anchors that
   are different from entities as Home Agents (that can only perform

Njedjou                  Expires November 2006                [Page 10]

Internet-Draft             problem statement                   May 2006

   the switch between two IP legs). Therefore, it is a strong
   requirement that signaling overhead from hosts to these different
   gateways do not grow as their number or type multiplies.

  5.2.       Complexity of mobility management procedures

   As said in the introduction, simplifying architectures and hosts,
   as well as minimizing the protocols is a requirement on the road
   to rendering next generation mobility architectures more scalable.

   Comprehensive mobility management procedures would basically
   require that a mechanism exist to perform the steps as described
   in section 2, basically collecting information to prepare a
   handover, and indicating the target to the terminal. Solutions for
   gmm do not provide these steps, which anyway they are not meant
   for. The very problem is that they were not thought to be included
   to the comprehensive procedures.
   Therefore the gmm mechanisms would usually superpose to the
   previous procedures to create complex state machines and heavy
   message exchange flows between hosts and the network.

   Also, usually the integrated architecture would already have
   mobility management states for every activated link (UMTS, Wimax…)
   on the terminal. To that, is superposed the global IP mobility
   management  protocol.  This  protocol  superposition  adds
   sensitiveness to the overall stability of the architecture. In the
   middle of that, the integrated architecture will necessarily have
   to support inter-media convergence functions such as the MIH of

  5.3.       Complexity of hosts

   Lowering software support requirements on hosts would facilitate
   early adoption of seamless mobility by reducing the time to market
   for terminals to be IP mobility compatible.
   This is already a requirement of NETLMM. However such a
   requirement difficulty applies for scenarios where the host has to
   move between domains operated by different administrations.
   Another example of ongoing standard specification where the
   principle to get rid of host support applied is the VCC (VoIP to
   Circuit Switched) transition work item carried out in 3GPP. This
   item is being addressed with no specific needed support on the
   host but native IMS.

  5.4.       Network initiation of mobility

   An integrated deployment model as presented in 3.2 has the ability
   to facilitate network initiation of handovers. This brings
   guarantee of service level to moving users. Indeed the integrated

Njedjou                  Expires November 2006                [Page 11]

Internet-Draft             problem statement                   May 2006

   provider can monitor the load of a base station before allowing a
   user application to move to that point of attachment. Network
   initiation also brings assurance that the capacity of the provider
   is efficiently spread across the wireless domains.

   Initiating an IP handover from the network requires that the re-
   association procedure should be initiated by the network. Taking
   the MIP example, a host would have to perform the registration
   update just after receiving an indication from the network to
   switch to a different system. Therefore, a specific requirement on
   the MIP stack would be to trigger the registration update exchange
   upon indication to switch between links.

   Furthermore, as the existing gmm solutions as MIP let it totally
   implementation dependant the set of events that trigger the IP
   location update procedure, it is practically impossible for all
   implementations to have the same state machine for triggering such
   a re-association.
   Therefore, implementations as would be wanted for network
   initiation will have to be featured in a way to perform the re-
   association procedure only after a network indication to do so.
   Flexibility of standard implementation is often desired but can be
   become cumbersome in such a case.
   Many integrated operators are building roadmaps for deploying
   seamless mobility for IP services with the requirements presented
   at the beginning of the document. Because of the previously
   identified problem of gmm solutions to date, such operators have
   to make specific requests for quotations to smart devices vendors
   to design implementations that fit their purposes. This burden
   becomes considerable when deployment is considered at a large

  5.5.       Terminal initiation of mobility

   For terminal initiated mobility scenarios, a similar problem is
   present. Despite the fact that it would be an inter-system
   mobility agent on the terminal that would decide to pass the
   traffic to a different link, the gmm protocol still has to be able
   to understand an order to do so.

  5.6.       Mobility between two heterogeneous mobility management domains
  owned by a same operator

   Two mobility management domains are said to be heterogeneous
   whenever the protocols they run for mobility are different.
   An alternative deployment scenario for an integrated provider
   willing to offer global mobility would via the aggregation of
   several heterogeneous mobility domains anchored to a unique core

Njedjou                  Expires November 2006                [Page 12]

Internet-Draft             problem statement                   May 2006

   Effectively, a mobile operator could deploy WiMax in a hotzone and
   LTE all around, with an IP mobility protocol (NETLMM for example)
   inside the Wimax zone.

                                     *  *
                                  *        *
                                 *           *
                                *  Operator's *
                                * Aggregation *
                                *   Network   *
                                 *           *
                                  *        *
                                 *   *  *   *
                               *              *
                            *                   *
                          *                       *
                    *  *                             *  *
                 *        *                       *        *
               *           *                     *           *
              * MM Domain A *                   * MM Domain B *
              *             *                   *              *
              *   IP based *                   *  3GPP based  *
               *         *                     *            *
    AN A         *        *                       *        *     AN B
                    *  *   *                         *  *
                   * *       *                        * *
                 *     *      *                     *     *
                *       *       *                  *       *
               *         *        *               *         *
              /\         /\       /\             /\         /\
             /AP\       /AP\     /AP\           /AP\       /AP\
            / A1 \     / A2 \   / A3 \         / B1 \     / B2 \
            ------     ------   ------         ------     ------
                         |                       |
                         |                       |
                         |                       |
                        +--+                    +--+
                        +--+                    +--+

  Figure 4: Mobility between mobility management domains of a single

   As in the scenario of figure 2, the fact that both domains belong
   to the same administration, make it possible the exchange of
   information for mobility management within the network.

Njedjou                  Expires November 2006                [Page 13]

Internet-Draft             problem statement                   May 2006

   As different localized mobility management protocols would be used
   in each access domain, a different  mobility protocol will have to
   be resorted to for the inter-domain transition.

   Again for architecture scalability and host simplicity, it would
   not be desirable to multiply such mobility protocols. Therefore,
   solutions as NETLMM would certainly better be commoditized for
   integrated architectures and made more compliant to global
   mobility, so that the hosts and the network do not require any
   additional mobility management protocol to achieve the inter-
   mobility management domain movement.
   Also if it eventually turns out that a host based solution as MIP
   is used for the movement from a NETLMM to another mobility
   management domain, and especially when these domains are owned by
   the same operator, it will not have been very useful to bring new
   solutions where the host is not involved.

   It is to be made clear that in the case where access domains A and
   B are operated by different administrations (eg. NETLMM domain
   owned by operator A and LTE domain owned by operated B), the
   moving host stands as the unique federation entity and would
   therefore have to be more implicated in the global mobility
   management. Domains owned by several operators will usually not
   exchange mobility management information.

                                      *  *
                                  *         *
                                 *third party*
                                *  mobility   *
                                *   anchor    *
                                *             *
                                 * Internet  *
                                  *        *
                                 *   *  *   *
                               *              *
                            *                   *
                          *                       *
                    *  *                             *  *
                 *        *                       *        *
               *           *                     *           *
              * MM Domain A *                   * MM Domain B *
              *             *                  *              *
              *   IP based *                   *  3GPP based  *
               *          *                     *            *
    AN A         *       *                       *         *     AN B
    Provider A     *  *  *                         *      *Provider B
                   * *      *                        * *
                 *     *      *                     *     *
                *       *       *                  *       *
               *         *        *               *         *

Njedjou                  Expires November 2006                [Page 14]

Internet-Draft             problem statement                   May 2006

              /\         /\       /\             /\         /\
             /AP\       /AP\     /AP\           /AP\       /AP\
            / A1 \     / A2 \   / A3 \         / B1 \     / B2 \
            ------     ------   ------         ------     ------
                         |                       |
                         |                       |
                         |                       |
                        +--+                    +--+
                        +--+                    +--+

  Figure 5: Mobility between mobility management domains of
   different access network providers

   As a general observation it is worth reminding that it is making
   more and more sense from the market perspective to work on
   mobility management solutions meeting the requirement of both
   terminal and network modes of mobility management

  5.7.       Inter-system mobility in other SDOs

   3GPP is working on evolved inter-system architectures that could
   require global IP mobility protocols for 3GPP to non-G3PP
   mobility. Solutions meeting requirements presented in this
   document would be particularly adapted to these new architectures.
   Available gmm solutions may still work from a pure technical point
   of view, but would not meet important requirements as system
   scalability, host complexity, signaling volume reduction and many
   others discussed earlier.

   IEEE 802.21 is defining procedures for managing the transition of
   a host across several media. For that purpose, a media independent
   handover protocol will have to be supported in the mobility
   architecture. Therefore the Internet mobility architecture is
   definitely to be adapted to the constraints of inter-media
   mobility scenarios that 802.21 is developing.

6.   Security Considerations

   Security issues linked with existing gmm solutions can not be said
   to be an obstacle to deploying architectures with network global
   mobility management. Therefore there is no security issue
   identified as such. However design goals of a solution to address
   the problem described here will have to state precise security

7.   Conclusion

Njedjou                  Expires November 2006                [Page 15]

Internet-Draft             problem statement                   May 2006

   This document has tried to illustrate the problem of performing IP
   mobility with IETF already defined solutions. The context has been
   confined to a specific family of deployment scenarios, deemed to
   have the potential to grow wide enough to legitimate dedicated
   It turns out that most of the issues that have been gone through
   were especially bad for network global mobility management. It can
   be said that existing solutions were thought in a terminal centric
   approach and as such match pretty well the needs of the types of
   deployments scenarios that where the host would have to initiate
   the mobility.

8.   References

   [MIPV4] "IP Mobility Support", C. Perkins (editor), RFC 2002,
   October 1996.

   [MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and
   Jari Arkko, RFC 3677, June 2004.

   [TERM] "Mobility Related Terminology", J. Manner, M., RFC 3753
   June 2004

   [HIP] "Host Identity Protocol", P. Jokela (editor), draft-ietf-
   hip-base-04, work in progress, October 2005

   [NETLMM] "Problem Statement for IP Local Mobility", J. Kemps
   (editor), draft-ietf-netlmm-nohost-ps-00.txt, work in progress,
   February 2006

   [NAH] "Motivation for Network Controlled Handoffs using IP
   mobility between heterogeneous Wireless Access Networks", E.
   Njedjou, P. Bertin, P. Reynolds, draft-njedjou-inter-an-handoffs-
   00.txt, February 2003.

9.   Acknowledgments

  The authors would like to thank Karine Guillouard, Servane
  Bonjour, Jean Christophe Rault from France Telecom for the
  valuable inputs they had as reviewers of this document.

10.   Authors Addresses

   Eric Njedjou
   France Telecom
   4, rue du CLos Courtel
   35512 Cesson Sévigné BP 91226
   Phone: +33299124878
   Email: eric.njedjou@france.telecom.com

Njedjou                  Expires November 2006                [Page 16]

Internet-Draft             problem statement                   May 2006

   Julien Riera
   France Telecom
   38/40, rue du Général Leclerc
   92794 Issy Les Moulineaux Cedex 9
   Phone: +33145298994
   Email: julien.riera@francetelecom.com

Intellectual Property Statement

  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.

  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.

Disclaimer of validity

   This document and the information contained herein are provided on

Copyright Statement

   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

Njedjou                  Expires November 2006                [Page 17]

Internet-Draft             problem statement                   May 2006


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Njedjou                  Expires November 2006                [Page 18]