Internet DRAFT - draft-njedjou-netlmm-globalmm-ps

draft-njedjou-netlmm-globalmm-ps




 


Network Working Group                                 Eric Njedjou 
                                                      Julien Riera 
Internet Draft                                       France Telecom 
Expires November 2006                                 May 2006 
 
 
           Problem Statement for Global IP Mobility Management 
               draft-njedjou-netlmm-globalmm-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 a "work in progress." 
 
The  list  of  current  Internet-Drafts  can  be  accessed  at 
http://www.ietf.org/1id-abstracts.html 
 
The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html" 
 
This Internet-Draft will expire on November 2, 2006. 
   
Copyright Notice 
   
  Copyright © The Internet Society (2006) 
   
   
Abstract 
   
  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 
  model.  
  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 
  statement. 
   
   
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.  
   
   
  Care-of-address 
   
  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 
       handover 
     . 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 
        procedure 
     . 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 
   problem.  
   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 
                                     
                                     
                        +--+                  +--+                
                        |MN|----------------->|MN|                
                       +--+                  +--+    
    
    
  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. 
    
    
                                    *   *    
                                 *          *   
                              *                * 
                            *    + ----------+   *  
                                 |Inter-System| 
                          *      |  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 \       
          ------     ------   ------       ------     ------  
                       |                     |  
                       |                     | 
                       |                     | 
                      +--+                  +--+                
                      |MN|----------------->|MN|  
                      +--+                  +--+       
    
    
       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 
   network. 
 
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 
   information.  
    
    
5.   Issues and problems with Existing global IP mobility management 
   (gmm)solutions 
    
   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 
   802.21. 
    
  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 
   scale.  
    
  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 
   network.  

 
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 \       
            ------     ------   ------         ------     ------  
                         |                       |  
                         |                       | 
                         |                       | 
                        +--+                    +--+                
                        |MN|------------------->|MN|  
                        +--+                    +--+       
    
  Figure 4: Mobility between mobility management domains of a single 
   operator 
    
    
   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 \       
            ------     ------   ------         ------     ------  
                         |                       |  
                         |                       | 
                         |                       | 
                        +--+                    +--+                
                        |MN|------------------->|MN|  
                        +--+                    +--+       
    
  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 
   requirements. 
    
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 
   solutions. 
   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 
   France 
   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 
   France 
   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 
   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. 
    
    
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 
   rights. 
 
Njedjou                  Expires November 2006                [Page 17] 
 
 
Internet-Draft             problem statement                   May 2006 
                                     
                                     
   
   
Acknowledgment 
   
   Funding for the RFC Editor function is currently provided by the 
   Internet Society.                                                                                 













































 
Njedjou                  Expires November 2006                [Page 18]