IP Mobility Optimizations (Mob T. Melia Opts) RG NEC Internet-Draft J. Korhonen Expires: September 6, 2006 TeliaSonera R. Aguiar IT March 5, 2006 Network initiated handovers problem statement draft-melia-mobopts-niho-ps-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This is a first document describing the rational about network support for decision making and execution of handovers. Starting from existing technologies and considering new trends from mobile operators, we draw potential deployment scenarios and derive a set of associated functionalities. These functionalities and associated Melia, et al. Expires September 6, 2006 [Page 1] Internet-Draft Network Initiated Handovers March 2006 assumptions are listed in the document. Application areas for network initiated handovers are then illustrated specifying a set of goals and non-goals to be addressed in a future version. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of the problem . . . . . . . . . . . . . . . . . 4 1.2. Definition of Network Initiated Handover . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Administrative domain wise considerations . . . . . . . . 9 3.2. Technology wise considerations . . . . . . . . . . . . . . 12 3.3. NIHO Application Areas . . . . . . . . . . . . . . . . . . 12 4. General Requirements . . . . . . . . . . . . . . . . . . . . . 13 4.1. Network assistance with global mobility management . . . . 13 4.2. Network assistance with local mobility management . . . . 14 4.3. Inter-domain handovers . . . . . . . . . . . . . . . . . . 14 5. Framework and Functional Components . . . . . . . . . . . . . 15 6. Design considerations . . . . . . . . . . . . . . . . . . . . 16 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Melia, et al. Expires September 6, 2006 [Page 2] Internet-Draft Network Initiated Handovers March 2006 1. Introduction Standards based IP mobility enabling protocols such as Mobile IP [RFC3344] [RFC3775], HIP [I-D.ietf-hip-arch], MOBIKE [I-D.ietf- mobike-design] and SCTP with address management support [I-D.ietf- tsvwg-addip-sctp] [mSCTP] are all mobile node centric: the handover related decision making is mostly done in the mobile node only. Public mobile network access is gaining increased diversity, both in terms of the types of access technologies, in terms of the diversity of the offer (with clear separation of roles between access and service providers), and in terms of the size of that offer. This diversity has been compounded by increasing number of multi-access capable terminals equipped with IP technologies, and of operator- provided multi-technology mobile connection software. Overall, this creates a complex environment, where the mobile terminal might not have enough information or even the possibility to make an intelligent handover decision (as is often the case of operator- provided software). In fact, handover decisions and inherent target network selection is not necessarily anymore based on access availability but further depends on policies and commercial roaming arrangements on access network level, access provider level and service provider level. Furthermore, the information required for an intelligent target network selection might change periodically with such a frequency that maintaining all knowledge (and intelligence) in the mobile node might not be viable anymore. Some of this information is only available for network elements. However, none of the mobility protocols above referred have capabilities or procedures to significantly involve network side entities in intelligent handover decision making. A good example of the type of information only available at network entities is radio resource usage. It is expected that radio resource usage optimization will be a task of major relevance in future wireless network environments, with millions of users roaming between access routers across multiple technologies (i.e. 802.11, 802.16, e.g. [draft-cui-mobopts-hcf-wlan-00]). This task can resort to mechanisms and algorithms able to gather measurements and force terminal handovers between cells. The handover can be issued according to predefined mobility patterns, mechanisms for intelligent flow balancing, mechanisms for optimized resource re-allocation, mechanisms for user-traffic performance optimization, or mechanisms for user profiling (e.g. access rights) - all of them ultimately leading to better service to be provided to the users, with additional increased resource usage for the network operator. For these expectations to be realized, network control capabilities are required to instruct specific terminals to perform handovers, either between access points or between different technologies. Melia, et al. Expires September 6, 2006 [Page 3] Internet-Draft Network Initiated Handovers March 2006 Going even further, handovers over administrative domains i.e. inter- domain handovers are not explicitly prohibited with the existing IP mobility enabling protocols, but at the same time these protocols are not designed or optimized for such cases in any way. Also a general network controlled triggering mechanism for a handover from an administrative domain to another does not currently exists. Some initial work in this direction is introduced in [I-D.nakhjiri-aaa- hokey-ps]. The document describes how EAP keying material combined with hierarchical schemes could enhance roaming scenarios. This problem statement document describes various scenarios where handovers could be network initiated, even over administrative domains, presenting some ideas on functional components and protocol operations required to fulfill the above requirements. This, however, will further require a new handover triggering mechanism that originates from entities located in the network side, and is acted upon by entities on the mobile node. These network side entities may also be located in other administrative domains than the one the mobile node is currently visiting. This document also discusses and lists a set of goals and non-goals for further work that aims at enabling network initiated and assisted handovers, even over administrative domains. 1.1. Overview of the problem Current standard mobility protocols provide Internet connectivity to mobile nodes roaming from one access router to another. To reduce handover latency, extensions to mobility protocols are available (e.g. [RFC4068], [RFC4140]). Although some of the approaches support network initiation of the handover procedure, none of them takes into consideration the existence of a backend combining mobility, resource management and roaming scenarios. In this document we present a list of requirements according to which this characteristic is not adequate, and the protocols need to be extended with handover initiation by the network. In [I-D.sreemanthula-es-cs-problem] two kinds of handovers are identified. "Opportunistic handovers", performed for resource optimization and handovers performed for link layer conditions changed (e.g. degradation of the received signal level). While the first case is quite well explained, the second one is left for further study. The draft describes the IEEE 802.21 protocol operation executed for handover initiation and its interaction with existing mobility protocols. The major issue to be tackled is the fact that the network needs to assess the mobile terminal view of the network. High degree of terminal mobility and channel interference impact the freshness of the conveyed information. Melia, et al. Expires September 6, 2006 [Page 4] Internet-Draft Network Initiated Handovers March 2006 In [I-D.mohan-nflm-proto] a network based fast handoff based mechanism is proposed. The scenario considers a mobility anchor point controlling several access routers. On behalf of the mobile node the serving access routers updates routes and binding caches allowing the traffic to be routed to the new location. The trigger comes from the mobile node. There has been work started in the last months to split local mobility from global mobility. Local mobility in the access network mainly optimizes control signaling by reducing the need to update the home/visited network about user mobility. Local mobility can be handled independently of the global mobility. As an example, in [I-D.ietf-netlmm-nohost-ps] a list of requirements is given in order to identify desired functionalities. In the proposed document mobile devices are able to move across an access network by reducing to the minimum the complexity in the terminal itself. Therefore the network is requested to handle user mobility by means of appropriate schemes. In this last proposal the trigger for host route update executed by the network (which is actually an handover execution) is originating in the terminal. By means of layer two mechanisms (e.g. link up or link down in IEEE 802.11) or layer three mechanisms (e.g. Neighbor discovery) the terminal is detected on the new link and the route to the host updated for packet delivery. Thus, the whole network intervention is simply the support of route update. The real trigger/decision comes, once again, from the terminal. Following the split between global mobility domain and local mobility domain, [3GPP.23.882] provides additional scenarios where the network controlled and initiated handovers are also considered. The key point is that is the initiator of the handover procedure is mainly the serving radio access network, in contrast to the above explained methods. More short term deployable solutions have also been proposed. In [draft-cui-mobopts-hcf-wlan-00] a WLAN scenario is presented and extensions to Mobile IPv6 messages are introduced to support an handover control function for handover decision. [I-D.melia-mobopts- niho-fmip] proposes a fast mobile IP based approach where both mobile terminal and network initiated handovers are possible. Network initiated handovers are combined with advanced admission control mechanisms and potential race conditions are solved by appropriate protocol operations. Additional ways of providing information to the network enabling handover decisions are presented in [I-D.korhonen-mobopts-link- characteristics-ps]. Methods are provided to enable Mobile IPv6 and Mobile IPv4 capable nodes to exchange link information with the HA Melia, et al. Expires September 6, 2006 [Page 5] Internet-Draft Network Initiated Handovers March 2006 and any CN. However, to generalize the approach, the link characteristics exchange should happen during the handover process, since the Binding Update handshake conclude the handover process, when (bicasted) packets are already routed to the new Care-of Address (nCoA). For instance, specialized traffic shapers could be installed in the ARs to adapt a selected MT-CN flow to the specific underlying wireless/wire line access technology. Or (re)INVITE messages could be issued, in 3GPP multimedia communications. In the above mentioned examples we note an increasing involvement of the network in the mobility management problem. The aim of this document is to identify common lines to existing solutions and to derive the set of functionalities required to perform this kind of handovers. 1.2. Definition of Network Initiated Handover As mentioned above, available solutions rely on the existence of triggers generated in the mobile terminal and conveyed with some means to respective network components which then will take adequate actions. However, recently we have been assisting to new different trends [3GPP.23.882] where the serving radio access network issue handover preparation/execution by means of different events gathered at different levels (e.g. radio conditions, QoS requirements). We therefore are required to define use cases in which the network takes active decisions without requiring the terminal to perform expensive operations. In this document by network initiated handover we identify the action taken in the network to initiate the handover based on: o Link events originated in the mobile node. In this case the terminal sends link events to the network. The event might be generated because of radio variations, powering on of new network devices or new service requirements. In all cases the measurement action is required to be performed also in critical conditions. For instance speed dynamic effects on terminal mobility have to be taken into account as well as variable round trip time. Positioning of the decision function is a critical issue. o Events generated in the network for e.g. resource management reasons. It should be noted that the Mobile Operator can initiate an handover procedure also based on location and current services. Multihoming could be an interesting scenario. The action described is similar to exiting behavior of current GSM/3G systems. Measurements are performed by the network assisted by the mobile terminal. The results of these measurements, combined with Melia, et al. Expires September 6, 2006 [Page 6] Internet-Draft Network Initiated Handovers March 2006 current QoS conditions and other user profile requirements, could result in the execution of an handover. Measurements are a key issue in indoor wireless LANs environments, affected also by different user mobility patterns. 1.3. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [1]. This document frequently uses the following terms: NAP Network Access Provider. A network operator that provides direct IP packet forwarding to and from the end host. MRMH Mobility and Roaming Manager, usually located at home network. The Roaming Manager part is aware of administrative relationships between the home network, various ISPs and possibly with various NAPs as well. MRMV Mobility and Roaming Manager located at visited network. MRMV is generally a local representative of MRMH in the visited network. MSP Mobility Service provider. A service provider that provides IP mobility services. In order to obtain such service, the mobile node must be authenticated and prove authorization to obtain the service. NIHO Network initiated and assisted handover. AN Access Network composed of several access routers. Identified as well as local mobility domain. Melia, et al. Expires September 6, 2006 [Page 7] Internet-Draft Network Initiated Handovers March 2006 2. Assumptions This document has some few fundamental assumptions concerning the general networking environment and network initiated handovers. The rest of the document makes use of the following assumptions: o Reusing existing security mechanisms -- The mobile node should reuse the existing security associations it created while establishing the initial access to the network and its mobility service provider (MSP). Applicable scenarios are identified in [I-D.nakhjiri-aaa-hokey-ps]. o All mobile nodes within the scope of this document are expected to support at least one (potentially modified) existing or future IP mobility enabling protocol. However, if a MN does not support network initiated handover functionality, the network might refuse to give service to that MN. o All mobile nodes, correspondent nodes and mobility management nodes are not expected to understand or support network initiated and assisted handovers. When either peer lacks support for network initiated and assisted handover triggering and signaling the peer supporting these features must fall back to the base IP mobility protocol mechanisms. o The network initiated handover concept relies on the presence of a centralized functional entity. This entity controls the network side and implement the intelligence to select nodes and targets access routers. It is not in the scope of this document to specify the policies that will be implemented here. o To provide adequate scalable support, distributed functions are required to support the above functional entity. This gives more flexibility to the overall architecture and protocol operation. o It is envisioned the presence of multi wireless access, such as 802.11, 802.16, UMTS, forming an heterogeneous composition of macro and micro cells. The network support SHOULD leverage user mobility focusing on vertical handovers. Hence, the terminal does not need to apply filtering criteria to select a target network (which could be an expensive operation in heterogeneous environments). Solutions similar to the 3GPP interface between the Home Subscriber Server (HSS) and any application server, for downloading of filtering criteria at registration time, could be applied here - being the HSS a AAA backend, and the application server the MRMV/MRMH. Melia, et al. Expires September 6, 2006 [Page 8] Internet-Draft Network Initiated Handovers March 2006 o Performing network initiated handover has the main implication that the network has first to assess the terminal view of the network. Signal level evaluation is a important matter when coming down to user mobility. This is typically very well handled with terminal initiated handovers and automatic evaluation of signal level. Different methods apply to different technologies. o Neighborhood discovery relates to the above assumption when neighborhood scanning is requested from the network. It is expected these functions to be available on the terminal side. 3. Scenarios This section describes few usage scenarios where the network initiated and assisted handover could be justified and deployed. Also we list here initial requirements for the general network initiated and assisted handover functionality. 3.1. Administrative domain wise considerations Figure 1 and Figure 2 introduce two different possible scenarios. In the first case one single administrative scenario is described. The Mobile Operator (MO) owns both the ISPs and the NAPs. It provides as well mobility services. This is the simplest case where security restrictions are less relevant. The MO has therefore full control. Figure 2 illustrates another example architecture, where the signaling and triggering relationship between home network domain, ISP domain, NAP domain and the mobile node domain are shown. Each of previously mentioned technical domains may belong to a different administrative domain. Melia, et al. Expires September 6, 2006 [Page 9] Internet-Draft Network Initiated Handovers March 2006 .--. <-++ Mobile Operator _( `. |S Home Network ( MRMH ) |i ( ` . ) ) |n `--(___.-' |g ^ |l NIHO / triggers signaling |e / | .--. V |a _( `. |d ( ISP ) |m ( ` . ) ) |i `--(___.-' |n ^ ^ |i / NIHO \ triggers signaling |s / \ |t V V |r .--. .--. |a _( `. _( `. |t ( NAP ) ( NAP ) |i ( ` . ) ) ( ` . ) ) |v `--(___.-' `--(___.-' |e | | | ) |d V ) ) NIHO trigger & signaling |o ____ ) ) ) |m |____|_Y |a /_____/ |i |n <--+ Figure 1: An overall architecture for network initiated and assisted handover. Single Administrative domain Melia, et al. Expires September 6, 2006 [Page 10] Internet-Draft Network Initiated Handovers March 2006 .--. <-+ _( `. | Home Network ( MRMH ) | ( ` . ) ) | `--(___.-' | D ^ ^ | o NIHO / triggers \ signaling | m / \ | a .--. V V .--. | i _( `. NIHO triggers _( `. | n <--- ( ISP A ) <---------------> ( ISP B ) ---> | ( ` . ) ) signaling ( ` . ) ) | `--(___.-' `--(___.-' | 1 ^ ^ ^ ^ ^ | / NIHO \ \ triggers / \ signaling | / \ \ / \ <-+ V V \ V V | D .--. .--. \ .--. .--. | o _( `. _( `. V _( `. _( `. | m ( NAP A ) ( NAP A ) ( NAP B ) ( NAP C ) | a ( ` . ) ) ( ` . ) ) ( ` . ) ) ( ` . ) ) | i `--(___.-' `--(___.-' `--(___.-' `--(___.-' | n | 2 | ) <-+ V ) ) NIHO trigger & signaling | D ____ ) ) ) | o |____|_Y | m /_____/ | 3 <-+ Figure 2: An overall architecture for network initiated and assisted handovers over multiple administrative domains The architecture in Figure 2 has been divided into three different domains. Domain 1 represents the home network or the services provider that owns and manages user's subscription. It eventually contains Internet Service Providers (ISPs) as well. Domain 2 contains Network Access Providers (NAPs). A NAP provides access services for one or more Home Networks. Domain 3 is the mobile node and may also represent the end user. The end user does not need to have any relationship with NAPs or ISPs in order the gain access to the services accessible through the home network. Along these lines [I-D.nakhjiri-aaa-hokey-ps] proposes a distributed Melia, et al. Expires September 6, 2006 [Page 11] Internet-Draft Network Initiated Handovers March 2006 system interacting with a AAA backend. The introduced key Holder element acting as a AAA client for the AAA server COULD here be implemented at the boundaries of each single cloud, belonging either to a NAP or to an ISP. SAs presented in the document can be mapped to the mechanisms depicted in Figure 2. 3.2. Technology wise considerations In the previous section we provided an high level view of network relationships between the different entities involved. Figure 1 and Figure 2 describes a general network view without describing which technologies are supported and where optimizations take place. It is clear MO will have different environment deployments. In the following we give some examples on how technologies can be mapped to NAP implementing several Access Networks and creating complex overlapping of macro and micro cells scenarios. +=====================================+ = UMTS MACROCELL = = = = = = +--------------------------+ = = | 802.16 CELL | = = | | = = | 802.11 | = = | oo xx @@ | = = | o o x x @ @ | = = | o ox x@ @ | = = | o xo @x @ | = = | o ox x@ @ | = = | o o x x @ @ | = = | oo xx @@ | = = +--------------------------+ = = = +=====================================+ Figure 3: An example of overlapping Micro and Micro cells These cells can be actually owned by the same or by different NAPs. In any case, the MRMH will collect information about all these cells (as visible from the terminal) across the different domains. 3.3. NIHO Application Areas At this point in time we foresee three possible application areas that are listed and briefly described in the following section. Each application area uses the NIHO triggering and signaling as part of Melia, et al. Expires September 6, 2006 [Page 12] Internet-Draft Network Initiated Handovers March 2006 their tasks. o Application for Mobility Reasons The general idea is to handle user mobility from the network side assisted by the mobile terminal. This particular application requires network capabilities to request measurements and evaluate technologies specific link conditions. The approach can be considered similar to what current mobile networks do. The most challenging aspect is the freshness of the reported information. Particular scenarios, such as WLAN, could impose stringent requirements. o Application for Resource Optimization Reasons As mentioned before, network optimization is a delicate issue when resources are scarce, especially in the wireless access network. Standards that able to support natively quality of services capabilities are becoming mature to be sold on the market (802.11e). A cross layer design is therefore required to convey link layer specific information to decision points located in the access network. These decision points can combine standard admission control mechanisms with advanced NIHO functionalities, resulting in a new dimension of mobility management (i.e. more terminals can be granted with network access). o Application for inter-domain handover Handovers that cause the mobile to cross administrative domain borders involve inter-domain signaling. One example of this kind of scenario is when the mobile node moves between different NAPs under the same ISP or when even the ISP changes as a result of the movement. In both of these scenarios the NIHO signaling could be used to prepare the new target domain (either ISP and/or NAP) for the arriving mobile node. Especially if the handover was initiated from the network side, the handover initiating network could help distributing all security, policies, billing and service related material cross administrative domains before the mobile node arrives. 4. General Requirements 4.1. Network assistance with global mobility management This aspect is particularly important for inter-domain handovers. Melia, et al. Expires September 6, 2006 [Page 13] Internet-Draft Network Initiated Handovers March 2006 The network will provide information required for speeding the handover. This information is related with two types of data: i) operator related data, such as billing information, policies, etc..; ii) terminal related data, such as security associations. 4.2. Network assistance with local mobility management This aspect is particularly important for resource optimization and intra-domain handovers. The network will provide information to lead (or impose) the mobile terminal to associate to specific access points. 4.3. Inter-domain handovers Inter-domain handovers and inter-domain handover preparations require entities involved in the triggering and signaling to have security relationships in place between them. For example the MRMH located at the home network (service provider) must have a security relationship between all ISPs the end user can use for accessing services. Also ISPs must have security relationship between all NAPs the end user can use for accessing services. However, NAPs do no necessarily need to have any relationship with the actual service provider. And going even further the end user does not need to have any relationship between NAPs and ISPs, only with the service provider. It is service provider's duty to grant access to services via any NAP and ISP the service provider has a direct or indirect pre-setup relationship. In addition to obvious security and AAA related challenges between the service operator, ISPs and NAPs, the general when and why to trigger a handover towards the mobile node is not a trivial task. The service provider's home network needs to have rather exact and up to date knowledge of the mobile node's current topological location and surrounding network conditions before it should trigger a handover on the mobile node due same policy decision at the home network. Example of such policy decisions is when a mobile node roams (after a handover) to a target network the home network does not want the end user to use for the active service set the end user has requested. As a consequence the home network MRMH triggers a new handover suggestion towards the mobile node indicating a more feasible target network (based on the information the mobile node has previously signaled to the home network MRMH). Another home network policy decision could be distributing roaming end users in visited networks based on some distribution criteria. Such criteria could, for example, be directing voice users to ISP A network, where as data service users to ISP B network. A simpler rationale can be simply redirecting the user to the mobile network whose charges are lower at that time. The IEEE 802.21 Information service, for instance, could help in this process. Melia, et al. Expires September 6, 2006 [Page 14] Internet-Draft Network Initiated Handovers March 2006 The whole policy mechanism in the home network MRMH is a complex issue and out of scope of this document. However, the home network MRMH needs information of its end users from dedicated NAP and ISP entities. These information aggregating entities are discussed in more detail in Section 5. 5. Framework and Functional Components In the previous sections the need to implement decision points in the network as well as measurements and aggregation functions has been justified. We can draw on the previous considerations to derive a framework view. o Policy Decision Point This could be on the MRMH or MRML depending on the case. In the IEEE 802.21 draft event and command services for network initiated handovers are associated with the Point of Services (PoS). In [3GPP.23.882]the MME takes decision about initiating the handover. Generalizing the approach we call this functional entity Policy Decision Point. It is envisioned to place the PDP at the edge of a localized mobility domain or in the home network. In case of a ISP or NAP the PDP needs to have in place a SA with the home domain of the mobile user as specified in [I-D.nakhjiri-aaa-hokey-ps]. The PDP can trigger/enforce a horizontal or vertical handover, depending on the user device. It is also envisioned the possibility to detect multihomed devices as part of the resource management process. o Policy Enforcement Point Enforcement points participating to the signalling, and contributing to the scalable approach, are necessary. PEP are mainly access routers terminating different kind of transport protocols (e.g. ICMPv6 over the last hop and SCTP between network components). o Measurements Functions Measurements functions are critical components considering the overall procedure, being collectively distributed between the access routers and the mobile terminals. As mentioned before, the network, prior to any action, needs to assess the terminal view (i.e. link signal quality) of the access network. Currently none of the available protocols can support such feature. Options Melia, et al. Expires September 6, 2006 [Page 15] Internet-Draft Network Initiated Handovers March 2006 could be specified, though scalability and security have to be deeply studied. It is well understood measurements are requested from the network to the mobile terminal. o Aggregators Components To increase the overall scalability of the procedure aggregation points could be installed in different places in the access networks. Aggregated reports to PDP about QoS conditions, service availability, network load help in the decision process contributing to build an overall picture of the access network conditions. reports could be periodic or event based. In either cases information of several hundreds of mobile terminals could be carried. Generally, the PDP acts upon events and combines required actions with user profiles. Depending on billing rates, user preferences action A instead of action B can be issued. The transfer and definition of such profiles is not in scope of this document. 6. Design considerations 6.1. Goals This section lists the general goals for the network initiated and assisted handovers framework design. The network initiated and assisted handover framework solution MUST fulfill all the goals listed below: G1 Independent of the IP mobility management mechanism -- The network initiated and assisted handover triggering mechanism must be independent of any particular IP mobility management protocol. However, there might be mappings/implementations of the triggering mechanism to a specific IP mobility protocol such as Mobile IP. G2 Work over administrative domains e.g. in inter-domain handover cases or when a multi-homed host is attached to multiple ISPs. G3 Provide similar degree of security as existing with the current security protocols. 6.2. Non-goals This section lists issues that are considered as strictly out of scope of this problem statement and requirements document. Melia, et al. Expires September 6, 2006 [Page 16] Internet-Draft Network Initiated Handovers March 2006 o Designing a new security framework in order to enable network initiated and assisted handover triggering. o Initial bootstrapping problem -- The mechanism to gain the initial access to some network is out of scope of. 7. IANA Considerations This document does not define any new name spaces to be managed by IANA. This document does not either reserve any new numbers or names under any existing name space managed by IANA. 8. Security Considerations At the time of writing this document, the threats to network initiated and assisted IP handovers in general, and signaling and triggering between the mobile node and corresponding network entities are not widely understood, particularly in the inter-domain handover case when the signaling and triggering takes place across administrative domains. Part of the experimental task in preparing network initiated and assisted handovers (even across administrative domains) for eventual standards track will be to better characterize threats to network initiated and assisted handovers, inter-domain triggering and signaling, and design specific mechanisms to counter them. Work along these lines already started. [I-D.nakhjiri-aaa-hokey-ps] presents initial ideas how the problems described in this document could be solved. 9. Acknowledgments The authors would like to thank Rajeev Koodli for his valuable comments and suggestions. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Melia, et al. Expires September 6, 2006 [Page 17] Internet-Draft Network Initiated Handovers March 2006 10.2. Informative References [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [I-D.ietf-hip-arch] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-03 (work in progress), July 2005. [I-D.ietf-tsvwg-addip-sctp] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-12 (work in progress), June 2005. [mSCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and prototypical implementation of an end-to-end mobility concept", October 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [draft-cui-mobopts-hcf-wlan-00] Cui, Y., "Handover Control Function Based Handover for Mobile IPv6", draft-cui-mobopts-hcf-wlan-00 (work in progress), July 2005. [draft-daniel-mip-link-characteristic-02] Park, S., "Link Characteristics Information for Mobile IP", draft-daniel-mip-link-characteristic-02 (work in progress), June 2005. [3GPP.23.882] 3GPP, "3GPP system architecture evolution (SAE): Report on technical options and conclusions", 3GPP TR 23.882 0.10.1, February 2006. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work in progress), January 2006. Melia, et al. Expires September 6, 2006 [Page 18] Internet-Draft Network Initiated Handovers March 2006 [I-D.vidya-mipshop-handover-keys-aaa] Narayanan, V., "Handover Keys Using AAA", draft-vidya-mipshop-handover-keys-aaa-01 (work in progress), October 2005. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for IP Local Mobility", draft-ietf-netlmm-nohost-ps-00 (work in progress), February 2006. [I-D.mohan-nflm-proto] Parthasarathy, M., "Network-based Fast Handovers for Local Mobility (NFLM)", draft-mohan-nflm-proto-00 (work in progress), October 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [I-D.sreemanthula-es-cs-problem] Sreemanthula, S., "A Problem Statement for Event Services and Command Services for Media Independent Handovers", draft-sreemanthula-es-cs-problem-01 (work in progress), October 2005. [I-D.melia-mobopts-niho-fmip] Melia, T., "Network initiated handover in fast mobile IPv6", draft-melia-mobopts-niho-fmip-01 (work in progress), July 2005. [I-D.korhonen-mobopts-link-characteristics-ps] Korhonen, J., "Link Characteristic Information for IP Mobility Problem Statement", draft-korhonen-mobopts-link-characteristics-ps-00 (work in progress), October 2005. Melia, et al. Expires September 6, 2006 [Page 19] Internet-Draft Network Initiated Handovers March 2006 Authors' Addresses Telemaco Melia NEC Europe Network Laboratories Kufuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 42 Email: telemaco.melia@netlab.nec.de Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Rui L.A. Aguiar Instituto de Telecomunicacoes Universidade de Aveiro Aveiro 3810 Portugal Phone: +351 234 377900 Email: ruilaa@det.ua.pt Melia, et al. Expires September 6, 2006 [Page 20] Internet-Draft Network Initiated Handovers March 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Melia, et al. Expires September 6, 2006 [Page 21]