DNA Working Group S. Aust Internet-Draft C. G÷rg Expires: August 25, 2005 ComNets-ikom, Uni Bremen C. Pampu Siemens AG February 21, 2005 Policy Based Mobile IPv6 Handover Decision (POLIMAND) draft-iponair-dna-polimand-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 August 2005. Abstract A handover is the process during which a mobile node is handed over between access networks. Especially for vertical handovers in overlay networks the mobile node changes the access network using multiple interfaces including different link layers, e.g., WLAN, GPRS, and UMTS. Handovers occur as a consequence of lower layer (i.e., link- layer) handovers that signify a switch of the physical connection to a new location. For the duration of a handover, a mobile node is unable to send or receive traffic. The length of this disruption is considered critical because it affects the performance of the communication. An additional factor is the link layer selection. It implies the selection of the most suitable link layer from which a mobile node should receive services. With the help of DNA it is possible on one side to provide proactive handover decision for mobility protocols (e.g., for MIPv6) and on the other side to select the best link layer including multiple interface support. This draft describes a method that allows seamless handovers IPonAir Expires August 25, 2005 [Page 1] Internet-Draft POLIMAND February 2005 and optimal link layer selection using a proactive handover decision that is based on a policy. The policy considers L2 information and DNA assumptions. Table of Contents 1. Introduction....................................................2 2. Conventions used in this document...............................2 3. Terminology.....................................................3 4. Seamless Handovers in Wireless Networks û Problem Overview......3 5. Reactive/Proactive Handover Decision............................4 5.1 Reactive Handover Decision.....................................5 5.2 Proactive Handover Decision....................................5 6. Link Layer Information..........................................6 7. Handover Policy.................................................6 7.1 Handover Policy Decision Function..............................7 7.2 Definition of the Handover Policy Decision Function............7 7.3 Handover Policy Enhancements...................................8 8. Security Considerations.........................................8 9. References......................................................8 Authors' Addresses.................................................8 Intellectual Property Statement....................................9 Disclaimer of Validity.............................................9 Full Copyright Statement...........................................9 Acknowledgment.....................................................9 1. Introduction In cellular and wireless networks, handover decision can benefit from DNA information that is available for each link layer. Proactive handover decision reduces the packet loss during handovers. This draft describes a method that considers the aforementioned DNA information that is indicative of the status of any underlying link layer to determine when a handover should be forced. Due to the wide range of wireless technologies such as WLAN, GPRS, and UMTS, a mobile node will have multiple interfaces to include such systems for seamless mobility support. However, seamless handovers have to be forced defined by system or user requirements and mainly based on the available bearer information, e.g., link layer information. Link layer information can be derived by DNA and allow the control of handover for seamless mobility support, e.g., for Mobile IPv6. Especially for vertical handover in overlay networks, e.g., handover between WLAN hot spots and cellular systems, a handover decision based on DNA consideration is required. Hence, this draft includes a problem analysis and describes a policy for handover decisions for mobile terminals with different link layers. 2. Conventions used in this document 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 RFC-2119 [1]. IPonAir Expires August 25, 2005 [Page 2] Internet-Draft POLIMAND February 2005 3. Terminology This document uses the following terms: Home Agent (HA) As defined in [2]. Correspondent Node (CN) As defined in [2]. Mobile Node (MN) As defined in [2]. Neighbor Discovery (ND) As defined in [3]. Neighbor Unreachablility Detection As defined in [3]. Router Advertisement (RA) As defined in [3]. Router As defined in [4]. Host As defined in [4]. Link As defined in [4]. Address As defined in [4]. Stateful/Stateless IPv6 Address Autoconfiguration As described in [4]. 4. Seamless Handovers in Wireless Networks û Problem Overview Seamless handovers in heterogeneous wireless networks are mainly based on movement detection that forces handovers from the previous network to the new network. Movement detection in Mobile IPv6 uses agent advertisements [2] that are used by mobile nodes to detect whether an access network is reachable for data transmission or not. The statements in [2] have to be considered to determine whether the movement detection is appropriate for seamless handovers in heterogeneous and overlay networks. The conclusion is that generic movement detection is not suitable to support seamless handovers with a reduction of packet loss during handovers. In [2] it is described how often the router advertisements have to be broadcasted by access routers to support movement detection in heterogeneous networks, so- called unsolicited router advertisements. Movement detection which is described in [2] is based on Neighbor Discovery/Neighbor Unreachability Detection [3] and on router advertisements which are frequently broadcasted by the access routers. Movement detection which is based on Neighbor Unreachability Detection is not appropriate for seamless mobility due to the fact IPonAir Expires August 25, 2005 [Page 3] Internet-Draft POLIMAND February 2005 that the previous link breaks before the handover is performed. This causes too long service disruptions, because the Neighbor Unreachability Detection detects that the link cannot be used for further communication only after the previous link breaks. It has to be understood that all statements in [2] and [3] describe movement detection and neighbor unreachability detection after the previous link breaks. However, a decision how to trigger a Mobile IPv6 handover between access networks or interfaces is not defined in [2]. Handover decision that is defined in the following is based on L2 information that is derived from DNA policies. The following describes how the handover decision can be enhanced by using so- called proactive handovers in heterogeneous networks without major changes to the mobility protocols. In fig.1 a mobility scenario is described which is the basis for the assumptions within this draft. Although there are only two different access routers (AR) described in fig.1, the mobile node (MN) includes different wireless interfaces for current and future wireless bearer technologies. The mobile node is able to force horizontal handovers within the same bearer technology and vertical handovers in overlay networks. +-----+ +--+ | | +--+ |CN|------|Inter|------|HA| +--+ | net | +--+ --------| |-------- | +-----+ | previous | | new network | * * | network | * * | +-------+ * * +-------+ | AR(n) | ** |AR(n+1)| +-------+ ** +-------+ . ** . Link(n) . * * . Link(n+1) +--+ * * +--+ |MN| ==*======*=> |MN| +--+ *movement* +--+ AR(n) coverage * * AR(n+1) coverage area * * area * * * * * * * * * * Figure 1: Handover scenario from Link(n) to Link (n+1). 5. Reactive/Proactive Handover Decision There are two different handover decisions which have to be considered for the design of seamless and lossless handovers, reactive and proactive handover decision. The reactive handover provides an active link connection to the previous access network until the previous link breaks. Afterwards it establishes an active link to the new access network. For the proactive handover the mobile node has an active link connection to the new access network before the link breaks and maintains the previous link even when the handover from the previous IPonAir Expires August 25, 2005 [Page 4] Internet-Draft POLIMAND February 2005 access network to the new access network has been established. In that case the handover can be established before the previous link breaks. The proactive handover from one access network to another may be forced due to DNA assumptions which are based on link layer information about the link conditions. A list of link layer parameters which are available in different bearer systems is given in [5]. In the following the reactive handover decision and the proactive handover decision are described to show the advantages on the proactive handover decision to reduce packet loss during Mobile IPv6 handovers. 5.1 Reactive Handover Decision In fig.2 the mobile node roams between (n) different access networks. Link(n) is the connection to the router in network(n) and Link(n+1) is the connection to the router in network(n+1). While Link(n) is permanently reachable, Link(n+1) changes its link characteristics (good/bad link layer conditions). When the previous link breaks due to bad conditions, the mobile node starts the stateful/stateless IPv6 address autoconfiguration [4] to the new link. After successful address configuration the new IPv6 address is used by the mobile node for data transmission via the new link. The handover duration between the previous link and the new link is named as link disruption. Link disruption is the reason for packet loss during handovers between the previous network and the new network. It should be reduced to minimize packet loss during Mobile IPv6 handovers. Active Link(n) Link(n) |---------------------------------------------------- Active Link(n+1) Link(n+1) stale | Link(n+1) |----------|----------| | Good Bad | Conditions Conditions Lifetime Addr. Link(n) | expires config. active | |--------|-------|------------- | Handover Link | Link(n+1)/Link(n) disruption \|/ |----------------| Figure 2: Handover from Link(n+1) to Link (n) based on a reactive handover scenario. In [6] a reactive handover design is described which is based on link layer hints for L3 handovers after the previous link breaks. It forces an IPv6 address autoconfiguration during the handover to the new access router after the previous link is lost by the mobile node. 5.2 Proactive Handover Decision For the proactive handover decision the mobile node has a link connection to a new network before the link of the previous network breaks (simultaneous use of wireless interfaces). Hence, the proactive handover decision differs from the reactive scenario that has no link connection during the handover. IPonAir Expires August 25, 2005 [Page 5] Internet-Draft POLIMAND February 2005 In fig. 3 the characteristic of Link(n+1) changes and a hint is used to establish a handover. The hint contains information (e.g., L2 information and DNA considerations) about the link characteristic and is used to control L3 handovers. The hint triggers an anticipated IPv6 (stateful/stateless) address configuration [4]. When the new IPv6 address is available and is used by the mobile node (Link(n+1)), the handover is established and the new link is used for data transmission. Active Link(n) Link(n) |---------------------------------------------------- Active Link(n+1) Link(n+1) stale | Link(n+1) |----------|----------| | Good Bad | Conditions|Conditions | | | Link(n+1) Hint |Lifetime Addr. Link(n) | \|/expires config. active | |--------|-------|------------------------ | Hanover Link | Link(n+1)/Link(n) disruption \|/ |-----| Figure 3: Handover from Link(n+1) to Link(n) based on a proactive handover scenario. The proactive handover decision reduces link disruption to a minimum because a new link will be established for ongoing data transmission while the previous link is still in use. It reduces the packet loss during handovers and supports anticipated handover scenarios. 6. Link Layer Information There are different bearer systems available which provide different link layer information. Different bearer systems like IEEE 802.11a/b/g, hiperLAN2, GSM, GPRS and UMTS are currently available and are used in IP networks. These bearer systems use various link layers with different types of link layer information. Different link layer information requires a generic platform which combines link layer information from different link layer systems. However, a list of different link layer parameters from various network systems is required that simplifies the control of L3 handovers between different access networks. A detailed list of different link layer parameters is given in [5]. 7. Handover Policy This draft proposes a so-called Handover Policy Decision Function. It is a proactive and seamless handover decision method, which is the basis for less or zero packet loss during vertical handovers in heterogeneous overlay networks. This method forces L3 handovers before the previous link breaks based on a policy. The policy based handover has the advantage of using a more suitable link instead of the previous link, which may not provide adequate link conditions or may be stale. It minimizes packet loss and provides seamless and reliable link connectivity of the mobile node during movements. IPonAir Expires August 25, 2005 [Page 6] Internet-Draft POLIMAND February 2005 The Handover Policy Decision Function uses L2 information to decide if there is a handover required from the previous network to a new network. Fig. 4 shows the control of L3 handovers based on link layer information and considers DNA assumptions. +--------------------------------------------+ | Network Layer | +--------------------------------------------+ | Handover Policy Decision Function | +--------------+--------------+--------------+ | Link Layer 1 | Link Layer 2 | Link Layer n | | L2/DNA | L2/DNA | L2/DNA | | WLAN 802.11x | 2,2.5,3G | 3G Beyond | +--------------+--------------+--------------+ Figure 4: Interaction of the Handover Policy Decision Function between different link layers and the network layer 7.1 Handover Policy Decision Function The Handover Policy Decision Function establishes L3 handovers from the previous network to the new network when the link characteristic is no longer adequate for data transmission. Hence, a policy is required when the handover has to be forced. The policy should be based on a combination of different link layer information to control the handovers. 7.2 Definition of the Handover Policy Decision Function In the following the Handover Policy Decision Function is defined. It is a generic definition that includes assumptions about available and future wireless link layer technologies. Generic handover policy function: Handover(a1*Link Layer 1, a2*Link Layer 2, ..., an*Link Layer n) The Handover Policy Decision Function considers different link layer technologies. Each link layer contains a number of different L2 hints (matrix h) that is listed in [5]. Due to system or user requirements the L2 information is differently weighted (matrix a). Handover policy definition: Link Layer 1= a11*h11 + a12*h12 + ...+ a1n*h1n Link Layer 2= a21*h21 + a22*h22 + ...+ a2n*h2n ... Link Layer n= am1*hm1 + am2*hm2 + ...+ amn*hmn The handover decision is based on the policy definition and the link layer characteristic. The characteristic of each link layer is considered by the vector l. The policy of the handover definition is used to select the target link layer from the available wireless interfaces. Handover policy: IPonAir Expires August 25, 2005 [Page 7] Internet-Draft POLIMAND February 2005 Target Link Layer = (l1*Link Layer 1 + l2*Link Layer 2 + , ..., + ln*Link Layer n) The target link layer is the new link layer at the mobile node. A handover has to be forced from the previous link layer to the new target link layer when the link layer characteristic has changed due to policy considerations. 7.3 Handover Policy Enhancements The Handover Policy Decision Function should be enhanced to consider the functionality of other mobility protocols, e.g., Hierarchical Mobile IPv6 [7] and Fast Mobile IPv6 [8]. HMIPv6 and FMIPv6 may use the Handover Policy Decision Function to reduce link disruption and to minimize packet loss during vertical handovers in heterogeneous overlay networks. 8. Security Considerations This document discusses considerations for handover decisions based on DNA assumptions for multiple link layers. The associated security issues will be discussed as future work. 9. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [2] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IP6. RFC 3775, June 2004. [3] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998. [4] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, December 1998. [5] P. Bertin, T. Noel, N. Montavont. Parameters for Link Hints. Internet Draft (work in progress), August 2003. [6] S. D. Park, E. Njedjou, N. Montavont. L2 Triggers Optimized Mobile IPv6 Vertical Handover. Internet Draft (work in progress), January 2004. [7] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier. Hierarchical Mobile IPv6 Mobility Management (HMIPv6). Internet Draft (work in progress), December 2004. [8] R. Koodli. Fast Handovers for Mobile IPv6. Internet Draft (work in progress), October 2004. Authors' Addresses Stefan Aust Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen D-28359 Bremen Phone: +49-421-218-8264 Germany Email: aust@comnets.uni-bremen.de Carmelita Goerg Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen IPonAir Expires August 25, 2005 [Page 8] Internet-Draft POLIMAND February 2005 28359 Bremen Phone: +49-421-218-2277 Germany Email: cg@comnets.uni-bremen.de Cornel Pampu Siemens AG ICM N PG NT RC PN Siemensdamm 62 D-13623 Berlin Phone: +49-30-386-20265 Germany Email: Cornel.Pampu@siemens.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 an 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 is 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 NAY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 This work was done within the framework of the IPonAir project which is partly funded by the German Ministry of Education and Research (BMB+F), http://www.iponair.de IPonAir Expires August 25, 2005 [Page 9] Internet-Draft POLIMAND February 2005 IPonAir Expires August 25, 2005 [Page 10] Internet-Draft POLIMAND February 2005