1. Fast L3 Handoff in 802.11 Wireless LANs Andrea G. Forte Sangho Shin Henning Schulzrinne

2. L3 Handoff AP Router 160.38.x.x128.59.x.x Mobile Node Static Node

3. DHCP - Overview DHCP Server Assigns IP addresses to clients that request them via the DHCP protocol. It directly serve clients in its subnet while it needs the Relay Agent in order to server clients in a different subnet than its own. Relay Agent (RA) We usually have one RA per subnet and usually the RA is located on the router/gateway of that subnet. The RA needs to relay DHCP packets between its network and the DHCP server. The server will know to which subnet a client belongs to (and which IP address to assign) according to which RA the packets came from.

4. DHCP Procedure - Overview MN DHCP DISCOVER DHCP REQUEST DHCP ACK L2 Handoff Complete DHCP Server DHCP OFFER DAD

5. Current DHCP Performance

6. Fast L3 Handoff IP address acquisition time is too big for seamless inter-subnet handoffs. Our mobility scenario  VoIP + SIP. Many entities involved in the process: DHCP server/client Correspondent Node (CN) SIP server

7. Fast Layer 3 Handoff - Cache Spatial locality  Cache We use an extension of the L2 cache: Current AP (KEY)Best APSecond best AP MAC AMAC BMAC C Channel 1Channel 11Channel 6 Gateway DGateway EGateway F + LEASE FILE

8. Fast L3 Handoff We optimize the layer 3 handoff time as follows: Subnet Discovery. IP address acquisition. Multimedia session update (SIP).

9. Subnet Discovery (1/2) Current solutions Router advertisements Usually with a frequency on the order of several minutes. DNA working group (IETF) Detecting network attachments in IPv6 networks only. No solution in IPv4 networks for detecting a subnet change in a timely manner.

10. Subnet Discovery (2/2) Our approach Send bogus DHCP_REQUEST (using loopback address). DHCP server responds with a DHCP_NAK From the NAK we can extract subnet information such as default router IP address. The client saves the default router IP address in cache. If old AP and new AP have different default router, the subnet has changed.

11. Fast Address Acquisition  IP address acquisition This is the most time consuming part of the L3 handoff process  DAD takes most of the time. We optimize the IP address acquisition time as follows:  Checking DHCP client lease file for a valid IP.  Temporary IP (“Lease miss”)  The client “picks” a candidate IP using particular heuristics.  SIP re-invite  The CN will update its session with the TEMP_IP.  Normal DHCP procedure to acquire the final IP.  SIP re-invite  The CN will update its session with the final IP. While acquiring a new IP address via DHCP, we do not have any disruption regardless of how long the DHCP procedure will be. We can use the TEMP_IP as a valid IP for that subnet until the DHCP procedure ends.

12. Session Update Multimedia session update (SIP) After a change in IP address, we have to inform the Correspondent Node (CN) about it. This is usually done with a re-Invite. The data stream will be resumed right after the 200 OK has been received. MN SIP Re-INVITE RTP Data SIP ACK New IP CN SIP OK

13. Handoff Scenarios Scenario 1 The MN enters in a new subnet for the first time ever. Scenario 2 The MN enters in a new subnet it has been before and it has an expired lease for that subnet. Scenario 3 The MN enters in a new subnet it has been before and still has a valid lease for that subnet.

14. TEMP_IP Selection (1/3) Scenario 1 Select random IP address starting from the router’s IP address (first in the pool). MN sends 10 ARP requests in parallel starting from the random IP selected before. Scenario 2 Same than scenario 1 except that we start to send ARP requests to 10 IP addresses in parallel, starting from the IP we last used in that subnet. Scenario 3 We do not need TEMP_IP as we have a valid lease. We just renew the lease.

15. TEMP_IP Selection (2/3) Critical factor: time to wait for an ARP response. Too small  higher probability for a duplicate IP. Too big  increases total handoff time. TEMP_IP: for ongoing sessions only Only MN and CN are aware of the TEMP_IP If any of the steps involved in the fast handoff fail, MNs can always rely on legacy 802.11 mechanisms such as scanning.

16. TEMP_IP Selection (3/3) # of IPs used IP usage rate

17. Fast Layer 3 - Implementation SIP client (mca) Wireless card driver (HostAP driver) DHCP client User Space Kernel Space (version 2.4.20) Red Hat 9.0  MCA: SIP client for PDAs by SIPquest Inc.  DHCP client by Internet System Consortium (ISC)  HostAP wireless driver

18. Parameters used Consecutive IP addresses in use had a 99th percentile value of 5. ARP waiting time had a 90th percentile of 130ms and a 99th percentile of 230ms. Subnet detection time: from L2 assoc response to DHCP_NAK from bogus request. IP address acquisition time: from the first ARP req. to the expiration of the ARP waiting timer (ARP requests are sent in parallel). SIP signaling time: from the moment the INVITE is sent to the moment the 200 OK has been received. Client processing time: gap between components for processing internal signals, etc.

19. ARP Req. NAK MNDHCPd DHCP Req. ARP Req. Router ARP Resp. CN SIP INVITE SIP OK SIP ACK RTP packets (TEMP_IP) 138 ms 22 ms 4 ms 29 ms Waiting time IP acquisition SIP signaling L2 handoff complete Detecting subnet change Processing overhead Experimental Results (1/2)

20. Experimental Results (2/2)

21. Conclusions & Future Work Modifications in client side only (requirement). Forced us to introduce some limitations in our approach. Works today, in any network. Much faster than DHCP although not seamless in some cases. Scenario 3 obvious but … Windows XP ARP timeout  critical factor  SIP presence SIP presence approach (Network support) Other stations in the new subnet can send ARP requests on behalf of the MN and see if an IP address is used or not. The MN can wait for an ARP response as long as needed since it is still in the old subnet. Passive DAD (draft-forte-dhc-passive-dad-02.txt)

22. Thank You! For more information: Web: http://www.cs.columbia.edu/~andreaf http://www.cs.columbia.edu/IRT E-mail: andreaf@cs.columbia.edu