Personal INTERNET DRAFT Gopal Dommety Category: Informational cisco Systems Title: draft-dommety-mobileip-min-handoffv4and6-00.txt July 2001 Expires December 2001 Handoff Optimization with no prediction and minimal L2 Trigger information draft-dommety-mobileip-min-handoffv4and6-01.txt Status of this Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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. Abstract Currently Mobile IP WG is carrying out very interesting work in the area of Fast/Low latency handoffs for Mobile IPv6 and Mobile IPv4. The high level goal of this work is to reduce the latency during the change of point of attachement to the Internet (AKA Handoff). This document discusses one simple case that in the author's opinion is very common and can be optimized to achevie lower latency than that proposed by the various solutions. This scenario applies to both IPv6 and IPv4 work. The solution at a high level is the same, but realization will be different as the frame work in IPv6 case is different from that of the IPv4 case. 1. Introduction Currently Mobile IP WG is carrying out very interesting work in the area of Fast/Low latency handoffs for Mobile IPv6 and Mobile IPv4. The high level goal of this work is to reduce the latency during the change of point of attachement to the Internet (AKA Handoff) This document discusses one simple case that in the author's opinion is very common and can be optimized to achevie lower latency than that proposed by the various solutions. This scenario applies to both IPv6 and IPv4 work. The solution at a high level is the same, but realization will be different as the frame work in IPv6 case is different from that of the IPv4 case. 2. Senario Description When the mobile moves from one AR to another the following scenarios can be envisioned in the break-before make case of handoff. 1. If the movement of the mobile can be predicted the in advnace (i.e. before the handoff), a lowlatency/fast handoff can be acheived as described in [FMIPv6] and in PRE-REGISTRATION HANDOFF of FMIPv4. 2. If L2 triggers as described in [BETH, FMIPv4] are avialable, POST-REGISTRATION in FMIPv4 or using the Extensions suggested in [BETH] can be used to acheive a fast handoff. There are scenarios where it is not possible to predict the movement well ahead in advance and sufficient L2 Triggers are not avialable. One such scenario is one in which the mobile moves to a new access router and realizes that is moved (by way of a L2 trigger at the mobile). The goal of this document is to suggest solutions to achenving handoffs in such scenarios in a least latency fashion. An example network where in such a scenario occurs is Wireless LAN or 802.11 based network. In this scenario, and in the absense of appropriate L2 triggers, the handoff currently prescribed is that of one specified in Mobile IPv6 or Mobile IPv4. 2.1 Solution space This solution assumes that when a mobile associates with a new AP (access point ) it obtains the informaiton regarding the newAR/newFA (IP address and MAC). For example, in 802.11 networks today, 802.11 messages can contain "elements" which are "type,length,value" triples. Several products already support such elements. Such mechanisims can be used to inform the mobile of the required parameters. The basic idea is as follows: 1. The mobile sends a message to the Old or New AR (or FA) indicating of the handoff. 2. A temporary bidirectional tunnel is created between old and new ARs after authenticating the mobile. Once this is created, traffic is forwarded to and from the mobile through this tunnel. 3. Once fast handoff is completed, the mobile can perform regular mobile IP procedures such a Registration, Regional Registration, or Sending Binding Update. 3. Handoff for IPv6 3.1 Problem Currently in IPv6, in the above described scenario, the mobile needs to obtain a CoA using a stateless (obtain the network prefix, form a CoA, perfom DAD) or stateful mechanisim. Then perform Mobile IPv6 procedures. This will incur latency beyond what is acceptable for realtime communicaiton. 3.2 Solution The basic idea is to tunnel the packtes (destined to the mobile) from the oAR to the nAR (i.e. encapsulates the packets or routes them through a tunnel interface). On the other end of the tunnel, the nAR decapsulates the packets and forwards them to the mobile. It is assumed that the mobile performs a regular mobile IP procedure soon after. The Following figure illustrates the message sequence: +-----+ 1. FFBu +-----+ | | <---------------------------+ | | 2. Hrsq | | | | | -----------------> | | | | oAR | 3. HRply | nAR | | | |<----------------- | | | | | 4. FBAck | | | | |=-=-=-=-=-=-=-=-=-=-|--+ | | +-----+ +-----+ | | | | |1.FBu | ^ V | +-----+ Movement +-------+ | MN | - - - - - - - - - -> | MN | +-----+ +-------+ Assumption of movement: In this draft the mobile is assumed that the mobile obtains an L2 trigger indicating that it has moved ARs (For example the L2 driver can indicate to the upper layer in the mobile that a L2 point of attachment has changed. This does not necessarly mean that the L3 point of attachment has changed, but for simplicity assume that the mobile can deduce that information and also obtain the IP and MAC address of the new L3 point of attachment - See Appendix for further discussion). 1. Once the mobile determines that the L3 point of attachment has changed, it sends a FFBu (Faster Fast BU :-) to the oAR. The FFBu serves the purpose of informing the oAR that the mobile has moved to the nAR and also authenticate the mobile to the oAR. (See Ingress filtering issue). The FFBu contains the CoA of the mobile, Home address of the mobile, the Link Layer of the mobile, and address of the New AR. FFBu is an extension of FBu[FMIPv6]. 2. The oAR sends Hrsq as sepcified in [BETH] with additional options. It contains CoA of the mobile, Home address of the mobile, the Link Layer of the mobile and address of the Old AR . The oAR configures all the required tunnels and routing information (but does not start tunneling). 3. The nAR sends HRply as specified in [BETH]. Before sending this message the nAR setsup the required tunnel and updates the routing information for two way tunneling (tunneled data is sent to the mobile and data from the mobile is tunneled to the oAr). 4. On recepit of Hrply the oAR starts forwarding the data through the Tunnel. It also sends the FBack to the mobile (this message is also tunneled via the BET created). The lifetime of the BET is the one agreed in the Hrply and informed to the mobile in FBack. 3.2.1 Proposed Extensions 3.2.1.1 Modified FBu A Flag in FBU to indicate that this is Bit to FBU. 3.2.1.2 New error code in FBAck when oAR cannot perform a Fast handoff for different reasons 3.2.1.2 An indication in Advertisement that the AR supports Fast Handoff 3.3 Issues 3.3.1 L2 Assumptions It is assumed that the mobile knows the IP address and the MAC address of the nAR when it moves to the new AP. Discussion on obtaining this (IP address and MAC) information and how to this basic procedure can be operated without the knowledge of IP address of the nAR is given in the Appendix. 3.4.2 Ingress Filterning 3.4.3 Buffering Once the oAR authenticates the FFBu packets can be buffered till it receives a Hrply. On recepit of the Hrply the buffer can be released. Bicasting might also help in these situations. 3.4.4 Anchor AR The FFBu can also be sent to the Anchor AR as defined in [BETH]. 4. Solution in IPv4 4.1 Problem With the fast handoff soltions that have been proposed in FMIPv4. In the absense of Prediction or L2 Triggers, the mobile has to perform Mobile IP registration. Which incurs latency as discussed earlier. 4.2 Solution The basic idea is to tunnel the packtes (destined to the mobile) from the oFA to the nFA (i.e. encapsulates the packets or routes them through a tunnel interface). On the other end of the tunnel, the nFA decapsulates the packets and forwards them to the mobile. It is assumed that the mobile performs a regular mobile IP procedure soon after. +-----+ 2.Handoff Request* +-----+ | | <----------------- | | | oFA | | nFA | | | 3.Handoff Reply* | | +-----+ -----------------> +-----+ ^ | 1. MN-Handoff Request | | 4. MN-Handoff Reply | v +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ This soltion is an extension to [FMIPv4]. *denotes extension to the current functionaly of the messages. 1. Once the mobile determines that the L3 point of attachment has changed, it sends a MN-Handoff Request to the nFA. The MN-Handoff Request is protected by an MN-oFA authentication extension. The MN-Handoff Request serves the purpose of informing the oFA via the nFA that the mobile has moved to the nFA and also authenticate the mobile to the oFA. 2. The nFA sends Handoff Request with additional options to the oFA. One of the new option contains the authentication information required for the MN-oFA authentication. Once the MN is authenticated, the oFA setsup the Tunnels. 3. The oFA sends a Handoff Reply to the nFA with the MN-Handoff Reply as one of the extensions. 4. On recepit of Handoff reply, it sends the MN-Handoff Reply to the Mobile node. 4.3 Extensions to Mobile IPv4 messages 4.3.1 Old Foreign Agent IP address extension 4.4 Issues: 4.4.1 L2 Assumptions It is assumed that the mobile knows the IP address and the MAC address of the nFA when it moves to the new AP. 4.4.2 Security It is assumed that there is a security association between the mobile and the old FA, and old FA and the New FA. 5. References [MIPv4] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [FMIPv4] El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4," draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, a work in progress. [FMIPv6] Tsirtsis, G., "Fast Handovers for Mobile IPv6," draft-ietf- mobileip-fast-mipv6-01.txt, a work in progress. [MIPv6] Johnson, D., and Perkins, C., "Mobility Support in IPv6," draft- ietf-mobileip-ipv6-13.txt, a work in progress. [BETH] Kempf, J., et al. "Bidirectional Edge Tunnel Handover for IPv6," draft-kempf-beth-ipv6-01.txt, a work in progress. Dommety [Page 4] Internet Draft Authors Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Appendix: 1. How to get the IP and MAC address 2. What can be done when we don't know the IP address 3. Do we need a bit in the advertisement message to indicate that the the AR/FA support fast handoff. Expires December 2001