NetLMM Working Group Eric Njedjou, Ed. Internet Draft Pierrick Seite Expires April 2007 Lucian Suciu Julien Riera France Telecom Jean-Marie Bonnin ENST-B October 2006 Implications of Network Initiation support on the NetLMM protocol draft-njedjou-netlmm-nih-00.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 April, 25th, 2007. Copyright Notice Copyright © The Internet Society (2006) Abstract This document discusses the architecture and protocol implications of making network initiation support easier with NetLMM. The framework is restricted to inter-technology mobility within a single NETLMM domain. It is proposed to add a new NetLMM message from the LMA to the MAG, which function is to trigger, upon various events, the Eric Njedjou Expires April 2007 [Page 1] Internet Draft NETLMM Network Initiated Handovers October 2006 location registration procedure. Further, it is indicated how to complement NetLMM with 802.21 control mechanisms to achieve adequate network initiation. Table of Contents 1. Introduction................................................2 2. Terminology.................................................4 3. Deployment scenarios and use cases..........................5 3.1. Targeted cooperation scenario of access systems.............5 3.2. Inter access Mobility management architecture...............6 3.3. Use cases...................................................7 4. IEEE 802.21-MIH protocol for Inter-access mobility..........8 5. Implications of the 802.21 reference model in a NetLMM architecture.............................................10 5.1. NetLMM solution status.....................................10 5.2. NetLMM in a nutshell.......................................10 5.3. NetLMM architecture with MIH functionalities support.......11 5.3.1. One single active radio interface..........................12 5.3.2. Several active radio interface at the same time............13 5.3.3. Resulting NetLMM protocol modification.....................13 5.3.4. Message format.............................................15 6. The "No host support" problem..............................16 7. Security considerations....................................16 8. Conclusion.................................................16 9. Acknowledgements...........................................16 10. References.................................................17 10.1. Normative references........................................17 10.2. Informative references......................................17 Appendix A. Distributed approach of the MIH support...............17 11. Authors Addresses..........................................18 1. Introduction [GOMM] describes various problems encountered when using traditional mobility management protocols as MIP to achieve host mobility between subnets. The following requirements were listed in [GOMM], in search for a solution to those issues; . The need to avoid additional signalling on the radio link already suffering latency and throughput issues in some technologies, especially cellular. . The need to lower software and protocol support on hosts, already running several radio technologies. This is namely required by device manufacturers that want to satisfy providers roadmaps. . The need to ease network side initiation of mobility for various criteria. This is required by operators that have to manage rare resources and want to provide the best experience to their users by giving them the best available connection. Eric Njedjou Expires April 2007 [Page 2] Internet Draft NETLMM Network Initiated Handovers October 2006 A solution addressing these requirements will contribute to an easier acceptance and break into the market of IP mobility solutions. This will also provide the ability to give a better user experience of mobility. With the creation of the NetLMM Working Group, the IETF Internet Area has recently sponsored the design of a new system to achieve host mobility. It turns out that the design goals of the NetLMM solution address only the two first of the three basic requirements that are listed above. The present document provides ways to address the "network side initiation of mobility" requirement of [GOMM], not addressed by [NetLMM]. Indeed by addressing this remaining requirement, the goals of [GOMM] would be considered as reached, considering what is now defined as local mobility in [NetLMM]. Actually, as far as [NetLMM] defines a way to achieve layer 3 mobility, the initiation of the mobility is at first sight an orthogonal problem with respect to NetLMM goal. Indeed, providing mechanisms to initiate mobility not only complement the description of the NetLMM solution, but also slightly affects it. The basic principle of NetLMM is about detecting (at the IP layer) that a host has moved into the realm of a new IP link, and initiating the appropriate information exchange with other nodes of the network involved in managing the mobility of the host. Such an information exchange is aimed at updating the IP location of the host. The point of NetLMM is that everything happens without any host involvement. Even though NetLMM operates via an initiation of the mobility management by the edge of the network (i.e. through MAG), NETLMM gives no possibility to involve any node located in the rest of the network. When considering a multi-technology terminal located in an area covered by several access networks, network initiation of the mobility may happen not only as the consequence of the host arriving in a new IP realm. A mobile host should be able to check connectivity with the new access router without being handed over, especially because the host would already have an attachment on another interface. It then becomes a policy matter to decide to handover the IP flow on the new access router (new interface on MN). Therefore it should be allowed that a central network entity having the policies participates in initiating the NetLMM procedure. Policies would include criteria as load balancing or the need to always connect the host with the best possible access network (the one access that has the best throughput, the best suited for the operator, the less expensive for the user…). The LMA may have such a good central position, in which case it would be an appropriate node to initiate the mobility. Indeed, in an inter-access system deployment scenario, MAGs would not be suited to apply the network policy that has to be transverse to all access systems. Eric Njedjou Expires April 2007 [Page 3] Internet Draft NETLMM Network Initiated Handovers October 2006 This document is not aimed at bringing policies considerations in NETLMM (which are out of scope). It only tries to discuss how NetLMM can be made compatible with policy in the network. The Media Independent Handover (MIH) framework of 802.21 has been designed to facilitate inter-access mobility management with awarness of policies. Therefore, the MIH reference model can help in solving the identified problem, i.e. how to initiate the mobility by the network and this for other motivations than the host pre-attachment to a MAG. For this purpose, the document first presents the underlying deployment scenarios, then details and discusses the alternatives ways of including MIH functions in the NetLMM architecture. Considerations about the transport of MIH signalling between NetLMM nodes or other such considerations are clearly considered out of the intended scope of this document. The present proposal relies on two existing building blocks, namely NetLMM and 802.21 reference model, to work out a solution to the network initiation problem. For this purpose, the document envisages the appropriate combination of these blocks. 2. Terminology This terminology is derived from [RFC3753] and [NetLMM]. Access System An IP network that includes one or more access points, access routers and access control points. Inter-access mobility function This is a function which can be located inside a provider aggregation network. It collects various information that help for target decision (done by the PDP). Local Mobility Anchor (LMA) The local mobility anchor (LMA) is a router that maintains reachability to a mobile node's address while the mobile node moves around within the Netlmm infrastructure. It is responsible for maintaining forwarding information for the mobile nodes which includes a set of mappings to associate mobile nodes by their identifiers with their address information, associating the mobile nodes with their serving MAGs and the relationship between the LMA and the MAGs. There may be one or more LMAs in a Netlmm infrastructure. Media Independent Handover (MIH) Service Eric Njedjou Expires April 2007 [Page 4] Internet Draft NETLMM Network Initiated Handovers October 2006 A framework that enables seamless continuity while an MN switches between heterogeneous link-layer technologies. The framework relies on the identification of a mobility-management protocol stack within the network elements that support handover as well as on a reference model [802.21]. MN Initiated Handover The MN is the one that makes the initial decision to initiate the execution of the handover. Mobile Access Gateway (MAG) The Mobile Access Gateway (MAG) is a router that a mobile node is attached to as the first hop router in the Netlmm infrastructure. The MAG is connected to the mobile node over some specific link provided by a link layer technology while the Netlmm infrastructure is agnostic about the latter. Each MAG has its own identifier used in Netlmm protocol messaging between the MAG and the LMA. The important interfaces between link layer specific functions and the Netlmm function reside on the MAG. There are multiple MAGs in a Netlmm infrastructure. Network Initiated Handover (NIH) The network makes the initial decision to initiate the execution of the handover. Policy Decision Point (PDP) A function that decide of the best access system as target for an MN, based on several criteria and information. 3. Deployment scenarios and use cases 3.1. Targeted cooperation scenario of access systems Wireless broadband operators worldwide have hard-worked the deployment of WLAN infrastructures to serve the increasing demand for high speed internet access in delimited areas as airports, hotels and conference centers. Today, the demand is wider, including not only internet access but also services as voice over IP. Also, the wireless access needs to be ubiquitous (stadiums, motorways, parks, and other metropolitan areas)and mobile. Wimax has been designed to undertake this challenge. Eric Njedjou Expires April 2007 [Page 5] Internet Draft NETLMM Network Initiated Handovers October 2006 The Wimax Network architecture specification, [Wimax], basically recommends that the radio sub-system (defined at IEEE 802) and the network sub-system be coupled in a very specific manner (Access Service Network Gateway). Therefore, integrating Wimax in an operator network would certainly require plugging the Wimax system alongside the already deployed IP access stratum used for WLAN architectures for example. At a minimum, if the existing IP access was to be re-used, the routers would have to be changed to be interoperable with the Wimax radio sub-system. Still, it would be needed in some areas of the topology to deploy new Wimax specific access routers. Therefore the following deployment figure sounds reasonable as a starting hypothesis. - - - - - - - - - - - | Provider | | Aggregation network | | | - - - - - - - - - - @ @ @ @ @ @ @ @ +---------------------+ +-----------------+ | Wimax IP Access | | WLAN IP access | +---------------------+ +-----------------+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /BS\ /BS\ /BS\ /AP\ /AP\ / 1 \ / 2 \ / 3 \ / 1 \ / 2 \ ------ ------ ------ ------ ------ Figure 1: access system cooperation deployment scenario 3.2. Inter access Mobility management architecture Because the system wants to provide the users with the connection that best suits their needs, and also because of other resource management purposes such as load balancing, there are situations where a host should be indicated which link or access system to switch to. To this end, a multi access system provider may want to deploy mobility functions inside their network. The following figure depicts an architecture to manage mobility with a model of cooperation as presented in the precedent paragraph. Eric Njedjou Expires April 2007 [Page 6] Internet Draft NETLMM Network Initiated Handovers October 2006 In such a cooperation architecture, the inter-access mobility function manages the overall user mobility by performing the following actions: . Monitoring terminals conditions . Monitoring the capacity of every access system. . Instructing the terminal to handover between the access systems. This should triggers IP mobility procedures. Note that this inter-access mobility function can be co-located to the node acting as the IP Mobility anchor. - - - - - - - - - - - | Provider | | Aggregation network | | | + ----------+ | | |Inter-access| | | Mobility | | | | function | | + ----------+ | | | - - - - - - - - - - @ @ @ @ @ @ @ @ +---------------------+ +-----------------+ | Wimax IP Access | | WLAN IP access | +---------------------+ +-----------------+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /BS\ /BS\ /BS\ /AP\ /AP\ / 1 \ / 2 \ / 3 \ / 1 \ / 2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|-------->|MN| +--+ +--+ Figure 2: inter-access mobility architecture for an integrated system 3.3. Use cases The following use-cases illustrate why network initiated access mobility upon best connection or load balancing criteria makes sense for an integrated access networks system. Eric Njedjou Expires April 2007 [Page 7] Internet Draft NETLMM Network Initiated Handovers October 2006 We consider here an access network provider operating both WLAN and WiMAX access services in the same geographical area. Indeed, that might be a possible deployment scenario in an airport. . When a node, attached to WLAN requests a VoIP session, the inter-system mobility function (depicted above) may instruct the node to handover to Wimax because not enough capacity is remaining on the WLAN system. Based on the cooperation scenario of Figure 2, a layer 3 handover would also be required. This is where the IP mobility protocols as Mobile IP or NetLMM come into play. However, because of the requirements listed in the introduction, Mobile IP is not a good candidate for this layer 3 movement (see [GOMM] for details). . When the Wimax BS becomes overloaded, the inter-system mobility function may wish to handover some nodes to the WLAN access in order to keep the Wimax capacity for highly demanding QoS users. It is to be made clear however that policies considerations are beyond the scope of this document. It is also to be noted that, in both use cases, the handover need is not generated by the discovery of a new IP connectivity. Still, layer 3 movement would be required because of the previous motivations. 4. IEEE 802.21-MIH protocol for Inter-access mobility It is commonly accepted that the handover initiation and the handover decision policy (i.e., access selection) are out-of-the-scope of mobility management protocols such as MIP or NetLMM (these protocols are only concerned with packet delivery on new path and/or possible address update). The IEEE 802.21 Working Group is currently proposing a specification which facilitates, among other things, the handover initiation phase across different (heterogeneous) access technologies. Accordingly, 802.21 implements a set of media independent events and commands which allows both mobile-initiated and network-initiated handovers. However, this draft only discusses the network-initiated case (just as NetLMM). The figure below shows how the 802.21 reference model can be used in the inter-access system architecture of an integrated provider as described in section 3.1.Here, the MIH Point of Service has a transversal view on the access systems. - - - - - - - - - - - | Provider | | Aggregation network | | | + ----------+ | | | MIH | | | Service | | | + ----------+ | Eric Njedjou Expires April 2007 [Page 8] Internet Draft NETLMM Network Initiated Handovers October 2006 | | - - - - - - - - - - @ @ @ @ @ @ @ @ +---------------------+ +-----------------+ | Access system 1 | | Access system 2 | +---------------------+ +-----------------+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ / \ / \ / \ / \ / \ /PoA \ /PoA \ /PoA \ /PoA \ /PoA \ / 11 \ / 12 \ / 13 \ / 21 \ / 22 \ ------ ------ ------ ------ ------ | | | | | | +-----+ +-----+ | MN |------>| MN | | MIH | | MIH | +-----+ +-----+ Figure 3: MIH service for inter-access mobility architecture 802.21 would basically serve to prepare and execute the switch between the involved access systems. When such a handover at layer 2 requires a handover at layer 3, protocols from the IETF would then have to be invoked. +-----+ +---------+ +--------+ +---+ +----------+ | MN | | Access | | MIH | | | | Mobility | | MIH | | Systems | |Service | |PDP| | Anchor | +-----+ +---------+ +--------+ +---+ +----------+ | | | | | | | | | | ******************************************* | | * events monitoring * | | * * | | ******************************************* | | | | | | | | | | ************* | | | | * Access * | | | | * Network * | | | | * Selection * | | | | ************* | | 1. MIH_switch.request | | | Eric Njedjou Expires April 2007 [Page 9] Internet Draft NETLMM Network Initiated Handovers October 2006 |<--------------------------------------| | | | | | | | | 2. MIH_Switch.response | | | |-------------------------------------->| | | | | | | | *************************************************************** * IP mobility management (e.g. Netlmm) * *************************************************************** | | | | | | | | | | Figure 4: MIH protocol exchange for Network Initiated Handover The precedent figure simply pictures the different functions and protocol messages that intervene in the process of managing the inter-access mobility. The next section discusses how these functions can be put together inside a provider architecture. 5. Implications of the 802.21 reference model in a NetLMM architecture 5.1. NetLMM solution status NetLMM is a solution to avoid the host involvement in the IP level mobility management. When the host does not participate into that function, signalling on the wireless link is reduced, aside other advantages. The NetLMM designed team has issued a third draft in October. The next section recalls its basic principles. It is reminded that the solution described in [NetLMM] is the result of a work still in progress, thus subject to modifications. 5.2. NetLMM in a nutshell [NetlMM] describes a process by which a MN changes its attachment from one Access Router (called Media Access Gateways - MAG) to another while communicating and remaining reachable from anywhere in the Internet. The MN pre-attaches to a new MAG via stateless or stateful address configuration upon arrival in the MAG "domain". The reception of a pre-attachment request (NDP/SLAAC, DHCP...) triggers a location update process between the two MAGs (the new and the old one) and a so-called Local Mobility Anchor (LMA) as shown on the following picture. For the sake of simplicity, this figure only shows the registration to the new MAG and not the deregistration from the old MAG. The LMA maintains connectivity of the MN with the rest of the Internet. After the location update process is completed, the MN gains IP connectivity with the new MAG by completing the network attachment process (NDP/SLAAC, DHCP...). It is to be noted that the MN keeps the same IP prefix (previously assigned by the LMA) when switching from the old to the new MAG. For details see [NetLMM]. Eric Njedjou Expires April 2007 [Page 10] Internet Draft NETLMM Network Initiated Handovers October 2006 MAGs and LMA get connectivity with each other via a specific secured association process. +-----+ +---------+ +--------+ +----------+ | MN | | new | | LMA | | PDP | | | | MAG | | | | | +-----+ +---------+ +--------+ +----------+ | | | | | |<- -Association- ->| | | | | | | | | | |1. Pre-attachment | | | | process | | | |<----------------->| | | | | 2. Location | | | | Registration | | | |<----------------->| | | | | | |3.IP connectivity | | | |<----------------->| | | | | | | | | | | | | | | Figure 5: NetLMM operat ion overview 5.3. NetLMM architecture with MIH functionalities support This section depicts a possible introduction of the MIH reference model inside a NetLMM architecture where access networks are integrated and belong to the same NetLMM domain. As explained earlier, such an integration aims at handling inter-access mobility with control in the network. Because the MN is not involved in the IP mobility management process, it is a requirement that the MN keeps the same IP address while moving from one access system to the other. In this architecture, it is suggested to co-locate the MIH service in the network with the LMA function. In an inter-access system deployment scenario with a MAG per system as depicted below, it looks convenient to deploy the LMA in the aggregated network. This is exactly where the MIH service was introduced above (figure 3). Overall, the model of the picture below aims at supporting 802.21 with minimal network impact. Such a requirement is essential for providers and manufacturers. * * * * * * +------------ + Eric Njedjou Expires April 2007 [Page 11] Internet Draft NETLMM Network Initiated Handovers October 2006 * | LMA | * | MIH service | * +------------ + * * * * * * * * * * * * * +------+ +------+ Access |MAG A1| |MAG B1| Access Network A +------+ +------+ Network B * * * * * * * * * * * * /\ /\ /\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / B1 \ ------ ------ ------ | | | | | | +----+ +----+ |MN | |MN | |MIH |----->|MIH | +----+ +----+ Figure 6: NetLMM architecture with 802.21 reference model Two possible scenarios exist regarding NetLMM operation as approached in this document. 5.3.1. One single active radio interface Some terminals may be configured to operate a single radio interface at a time. In such a case, when the MN is instructed to handover, it basically switches-off its current radio and powers on the target one. The node would very probably then proceed to neighbour discovery, which will automatically trigger NetLMM on the new MAG. The MAG would in turn perform the location update as usual. Therefore this scenario is naturally adapted to NetLMM. Indeed, when the MN pre-attaches to the new MAG, it no more has any connectivity and is bound to an IP layer handover. However, it is to be noted that having a single interface active at a time may induce more delay to the overall handover process. The tendency is clearly toward an integration of radio technologies that run in parallel. The document is not really intended to address this scenario. Eric Njedjou Expires April 2007 [Page 12] Internet Draft NETLMM Network Initiated Handovers October 2006 5.3.2. Several active radio interface at the same time In order to address the seamless continuity requirement, it may be needed that the terminal has at least two interfaces that can be active at the same time. Otherwise the seamlessness of the handover would in many cases hardly be guaranteed. Having an interface active supposes that the IP configuration on that interface has completed successfully. When the involved access router is a MAG, it can be assumed that the NetLMM procedure has taken place. The problem arises when a second radio on a second interface is powered up or attaches to a new Access Point. Upon such an event, neighbour discovery may start on the interface. According to NetLMM, the new MAG (assuming the APs on the two interfaces do not share the same MAG-deployment scenario above) is expected to start the location registration. Effectively, in [NetLMM] the location update procedure automatically starts after the MN_Access_Network API has performed. This gives no possibility to launch the execution of that procedure for different reasons and at a different time. Actually a PDP might want to control the time at which the the NetLMM location update is started. The reasons follow; . To provide the better connection available to the MN: the new link may not necessarily bring more quality for the ongoing communication of the MN in which case doing the NETLMM location upate would damage the service. . To load-balance the MNs between the systems (whenever this has the consequence of modifying the attachment of the MN from a MAG to another) The remainder of this document always assumes the second scenario presented earlier is considered. 5.3.3. Resulting NetLMM protocol modification The following message flow suggests an initiation of NetLMM that would address the precedent problem, i.e. to better control the location registration of NetLMM. It is assumed that at the start of the procedure depicted below, the MN has an already active interface. It is connected to its current MAG. Also, the MN MIH status is assumed to be registered in the network MIH service. The MIH status basically indicates the current access system used by the MN. The MN is also considered to have registered for link and MIH events. A new NETLMM message is added. The following describes the protocol operation including exchanges with the PDP. Clearly, description of communication with the PDP is out-of-scope but useful as a matter of illustration for a better understanding. Interaction with the PDP (informative only) Eric Njedjou Expires April 2007 [Page 13] Internet Draft NETLMM Network Initiated Handovers October 2006 It is suggested that after the "MN_Access_Network API" primitive has completed, the new MAG sends a request to the PDP to inform that the MN has pre-attached. This request is called "MN attachment notify". At this stage, the NETLMM process has to remain frozen until the PDP deems necessary to decide that the MN should handover. When such a decision is made, the network MIH (co-located here with the LMA) is informed with a "Target Notify" message. It in turn requests the terminal to switch its IP flows between links (MIH_Switch.request and MIH_Switch.response ). Actually, in a multi radio access environment the multi-interfaces MN must be notified of the handover decision even if it keeps the same IP address across IP realms. This allows the switch of flows from one interface to the other. The "MIH_switch" command is one among other means to reach this requirement. NETLMM modification (normative) Further, complementary to what is described in [NETLMM], at this point (after the switch order), the LMA sends an "Update Start" message to the new MAG. It is only when the new MAG receives the "Update Start" message that it starts the location registration update. The "Location registration" message serves as an acknowledgment to the "Update start". In this way, the NETLMM process is made compatible with the network policy. +-----+ +-----+ +-----+ +-----+ | MN | | New | | LMA | | PDP | | MIH | | MAG | | MIH | | | +-----+ +-----+ +-----+ +-----+ | | | | *********************************************** | * MIH Registration and Event Subscription * | *********************************************** | | | | | | | | | | | | | * 0. MN Attachment | | | | | | | | | | | | 1."MN_Access_Network API" | | | (MN ID,LMA ID) | | | | | | | * | | | | | | | | 2.MN Attachment notify | | | (MN ID, MAG ID) | | |-------------------------------------->| | | | | | | 3.Acknowledgement | | | (MN ID) | Eric Njedjou Expires April 2007 [Page 14] Internet Draft NETLMM Network Initiated Handovers October 2006 | |<------------------------------------- | | | | | | | | | | | | 4. Target notify | | | | (MN ID) | | | |<----------------- | | | | | | | |5. Acknowledgement | | | | (MN ID,Status) | | | |------------------>| | MIH_Switch.request | | |<----------------- --------------------| | | | | | | MIH_Switch.response | | |-------------------------------------->| | | | | | | | | | | | 6. Update Start | | | | (MN ID) | | | |<------------------| | | | | | | | | | | |7.Location Reg. | | | |(MN ID,MAG ID,LMA ID) | | |------------------>| | | | | | | |8.Acknowledgement | | | |(MN ID,MAG ID,LMA ID,Prefix, Status) | | |<------------------| | . . . . . . . . . . . . | | | | Figure 7: NetLMM protocol with prior PDP target decision 5.3.4. Message format Request Message Type: 6 Required options: MAG handle, LMA handle, MN ID, Timestamp Implementation: Mandatory Use: Optional The Update Start message is sent from the LMA to the MAG when the LMA is notified (by exemple by a PDP) that the location registration can be started. Reception of this message by the MAG results in the sending of a Location Registration message to the LMA. As soon as the LMA sends the Update Start message, it triggers a timer within which it expects the MAG to send a Location Registration request. It is let Eric Njedjou Expires April 2007 [Page 15] Internet Draft NETLMM Network Initiated Handovers October 2006 at the discretion of the implementation to decide to re-send the message when at the expiration of the timer. 6. The "No host support" problem The whole point of NetLMM is to keep the layer 3 mobility procedure transparent to the host. However, the MN would always have to switch between links in order to maintain connectivity. These links could be of different nature, in which case mechanisms as the MIH protocol are needed to optimize the transition. Therefore, even if the MN appears to be directly interacting with the LMA in the operation described above, such an interaction is aimed at addressing the vertical handover (inter-layer 2) and not the layer 3 mobility. Hence the "no host involvement principle" of NetLMM is not violated with the suggested amendment. 7. Security considerations The mechanisms used for the transport of the MIH messages between the Mn-MIH and the LMA-MIH are out of scope. So are the surrounding security considerations. The NetLMM message added here has the same security requirements as those of [NetLMM]. 8. Conclusion This document is an effort to add the support of network initiation of the handover to the NetLMM protocol. In a NetLMM normal operation, the handover is already initiated by the network but the only motivation to do so is that the MN has pre-attached to a new MAG. In order to take into account other criteria for starting the location update, the document suggests two things; . An adequate integration of the 802.21 MIH reference model in the NetLMM architecture . A modification of the NetLMM protocol operation including the state machine. The resulting number of NetLMM messages can still be minimized. However the author's primary intent not to modify the existing NetLMM messages exchange, was put forward in resolving the problem. 9. Acknowledgements The authors would like to thank Karine Guillouard, Jean-Michel Combes and Philippe Bertin from France Telecom for the valuable inputs they had as reviewers of this document. Eric Njedjou Expires April 2007 [Page 16] Internet Draft NETLMM Network Initiated Handovers October 2006 10. References 10.1. Normative references [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004 10.2. Informative references [GOMM] Njedjou, E., Riera J., "Problem Statement for Global IP Mobility Management", draft-njedjou-globalmm-ps-00.txt, May 2006 [NetLMM] Levkowetz, H. et al., "The NetLMM Protocol", draft-giaretta- netlmm-dt-protocol-02.txt" (work in progress), October 2006 [802.21] IEEE P802.21/D2.00 Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, (work in progress), September 2006 [Wimax] Wimax forum NWG, "Wimax End-to-End Network Systems Architecture", release 1, (work in progress), August 2006 Appendix A. Distributed approach of the MIH support Better scalability could be reached by distributing the MIH functions over MNs, LMA and MAGs. Figure 8 depicts the mobility management architecture with MIH functions distributed over NetLMM entities. The mobility management process can be summarized as follows. The MIH capable node attached to the access network A communicates with the MIH service, collocated to the MAG A1. MAGs MIH functions subscribe to MN events and monitor the points of attachment under its control so as to be alerted about the need to trigger handover for some MNs for different reasons. The LMA MIH has a global view of the whole system and intervenes when a MAG is not able to handle the needs of the MN. If this approach is intended to bring scalability it would clearly increase protocol complexity and impact of MIH support on NetLMM infrastructure; especially because it requires MIH interface between MAGs and additional MIH exchange between LMA and MAGs. * * * * * +-------------+ * | LMA | * | MIH service | * +-------------+ * * * Eric Njedjou Expires April 2007 [Page 17] Internet Draft NETLMM Network Initiated Handovers October 2006 * * * * * * * * * * +-------+ +-------+ Access |MAG A1 | |MAG B1 | Access Network A |MIH | | MIH | network B +-------+ +-------+ * * * * * * * * * * * * /\ /\ /\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / B1 \ ------- ------- ------- | | | | | | +----+ +----+ |MN | |MN | |MIH |----->|MIH | +----+ +----+ Figure 8: NetLMM architecture with 802.21 distributed reference model 11. Authors Addresses Eric Njedjou France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 France Phone: +33299124878 Email: eric.njedjou@orange-ftgroup.com Pierrick Seite France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 France Phone: +33 299 124680 Email: pierrick.seite@orange-ftgroup.com Lucian Suciu France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 Eric Njedjou Expires April 2007 [Page 18] Internet Draft NETLMM Network Initiated Handovers October 2006 France Phone: +33 299 124088 Email: lucian.suciu@orange-ftgroup.com Julien Riera France Telecom 38/40, rue du Général Leclerc 92794 Issy Les Moulineaux Cedex 9 France Phone: +33 145 298994 Email: julien.riera@orange-ftgroup.com Jean-Marie Bonnin ENST-Bretagne 2 rue de la Chataigneraie - CS 17607 35576 Cesson Sevigne Cedex Phone: +33 299 127026 Email: jm.bonnin@enst-bretagne.fr 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 Eric Njedjou Expires April 2007 [Page 19] Internet Draft NETLMM Network Initiated Handovers October 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Eric Njedjou Expires April 2007 [Page 20]