Transcript Slides:PPT

Fast L3 Handoff in 802.11
Wireless LANs
Andrea G. Forte
Sangho Shin
Henning Schulzrinne
L3 Handoff
Router
Router
160.38.x.x
128.59.x.x
AP
Mobile Node
AP
Static
Node
DHCP - Overview

DHCP Server

Relay Agent (RA)
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.
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.
DHCP Procedure - Overview
DHCP Server
MN
L2 Handoff
Complete
DHCP DISCOVER
DAD
DHCP OFFER
DHCP REQUEST
DHCP ACK
Current DHCP Performance
Original DHCP acquisition time
1200
1000
msec
800
ACK
600
Offer
400
200
0
1
2
3
4
6
10
11
12
13
14
15
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
Fast Layer 3 Handoff - Cache

Spatial locality  Cache

We use an extension of the L2 cache:
Current AP (KEY)
Best AP
Second best AP
MAC A
MAC B
MAC C
Channel 1
Channel 11
Channel 6
Gateway D
Gateway E
Gateway F
+
LEASE FILE
Fast L3 Handoff

We optimize the layer 3 handoff time as
follows:



Subnet Discovery.
IP address acquisition.
Multimedia session update (SIP).
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.
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.
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.
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.
CN
MN
New IP
SIP Re-INVITE
SIP OK
RTP Data
SIP ACK
Handoff Scenarios

Scenario 1


Scenario 2


The MN enters in a new subnet for the first time
ever.
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.
TEMP_IP Selection (1/3)

Scenario 1


Scenario 2


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.
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.
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.
TEMP_IP Selection (3/3)
140
100
90
120
100
70
60
80
50
60
%
# of IPs used
80
40
30
40
20
20
10
0
0
Time
# of IPs used
IP usage rate
Fast Layer 3 - Implementation
Red Hat 9.0
SIP client
(mca)
DHCP
client
User Space
Wireless card driver
(HostAP driver)
Kernel Space
(version 2.4.20)
 MCA: SIP client for PDAs by SIPquest Inc.
 DHCP client by Internet System Consortium (ISC)
 HostAP wireless driver
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.
Experimental Results (1/2)
MN
DHCPd
Router
CN
L2 handoff
complete
DHCP Req.
ARP Req.
22 ms
NAK
Detecting
subnet change
138 ms
Waiting time
IP acquisition
ARP Req.
4 ms
ARP Resp.
4 ms
Processing
overhead
29 ms
SIP signaling
SIP INVITE
SIP OK
RTP packets (TEMP_IP)
SIP ACK
Experimental Results (2/2)
600
29
8
500
ms
400
300
SIP Signaling
Client processing
IP acquisition
Detection of subnet change
518
200
29
8
29
8
138
100
138
22
0
Current
approach
29
8
22
Scenario 1
Scenario 2
Scenario 3
Conclusions & Future Work

Modifications in client side only (requirement).





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)


Forced us to introduce some limitations in our approach.
Works today, in any network.
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)
Thank You!
For more information:
Web:
http://www.cs.columbia.edu/~andreaf
http://www.cs.columbia.edu/IRT
E-mail:
[email protected]