Transcript PPT Version

DHCP-based Fast Handover protocol
draft-ogawa-fhopt-00.txt
NTT Network service systems laboratories
2005. 3. 10
Takeshi Ogawa
62nd IETF - Minneapolis ｄｈｃ wg
1
Status of this draft
• This draft is submitted to dhc wg.
• The main purpose of this draft is to realize
Fast Handover with plain ARs.
• It was Introduced in last Mobopts RG meeting,
but, has not accepted as RG item (yet).
2
Outline
•
•
•
•
•
Motivation
Problem statement
Proposed protocol
HO sequence example
Test system current situation
3
Motivation
• IP layer Fast Handover function is needed for
real time application.
• A protocol, that realize FH function inexpensive
and that will be available soon, is required.
• FMIP(MIPSHOP) and Fast RA(DNA) can reduce
IP layer HO time.
• However, there are 4 problems in both method.
4
Problems of FMIP and Fast RA (1/3)
1. Many facilities to be up graded (expensive)
With FMIP or Fast RA, all of ARs in service area
MUST be up graded, and the ARs need to
exchange messages for HOs.
So, the number of facilities to be upgraded may be
numerous, and connectivity between every pair of
different venders and kinds of ARs shall be assured.
The fewer facilities to be upgraded the better, and less
correlation between facilities is better.
5
Problems of FMIP and Fast RA (2/3)
2. Handling of stateful address (not defined yet)
Plain IP nodes (usually) uses DHCP to get stateful
IP addresses.
With FMIP, a new stateful IP address to be used
after handover is distributed by PrRtAdv
message (introduced in FMIP).
We suppose unified method is better.
With Fast RA, there is no function to distribute
stateful IP addresses quickly.
... as long as I know.
6
Problems of FMIP and Fast RA (3/3)
3. Security association (SA) set-up method between MN
and NAR. (being discussed in Mobopts now)
With FMIP, FBU messages MUST be authenticated by
AR to prevent service from being stolen.
However, the SA set–up method for it is not defined, it
might take long time...
4. How to reduce L2 HO time. (not defined yet)
In the FMIP and the Fast RA, there is no function to
reduce the L2 HO processing time.
7
Proposed DHCP-based FH protocol
With the protocol, DHCP server sends "Fast Handover
Options" to MN before handovers.
Those options include essence of FMIP, link layer and
IP layer information, to be used by the MN after
handovers, so that the MN can complete HO
sequence quickly.
CN
HA
IPv6
network
Fast HO
function
AR
AR
AR
CN
HA
IPv6
network
Current FMIP and Fast RA
DHCP
server
AR
AR
AR
MN
Fast HO
function
AR
AR
MN
Proposed method
8
It solves the 4 problems (1/2)
It is based on DHCP so,
1. Facilities to be up graded
Fewer than FMIP and Fast RA (inexpensive)
With this protocol plain access routers (if they have
the DHCP relay function) can be used.
2. Handling of stateful address
Unified in DHCP manner. (defined)
3. SA set-up method
Not problem with this protocol.
SA between MN and DHCP server can be used after
handover. (no problem)
(usually the DHCP server is not changed)
9
It solves the 4 problems (2/2)
Furthermore,
4. L2 HO time
Reduced by sending L2 information to MN
before HO. (defined (wireless LAN))
For example, wireless LAN channel number used
by new APs are sent to an MN, and the MN can
search for the notified channel only instead
of all channels and can reduce layer 2 HO time.
10
Seamless HO for MIP sequence example
with this protocol
MN
PAR
（DHCP client）
DHCP REQUEST/REPLAY
DHCP
server
HA
CN
Fast
Handover
options
BU/BA
User’s IP packets
Search available
channel only
HO trigger
It could be
less than a
hundred
millisecond(?)
(wireless LAN to
wireless LAN HO)
Standard messages
Proposed messages
Defined in other draft
Tunnel
Bufferring
(Moor)
BU/BA (request buffering)
Layer2 switch
Access
authentication
NAR
802.11i
BU/BA (request sending)
NS（DAD)
User’s IP packets
DHCP CONFIRM/REPLY
Opt DAD
(Moor)
No need if the MN is
still in same DHCP11
domain
Test system implementing status
We are currently implementing the test system in
Linux. The basic protocol functions are to be checked
by the end of March.
MobileIPv6
HomeAgent
(HA)
DHCPv6
server
CN
L2SW
CISCO 3745
L2SW
AP1
L2SW
AP2
MN
AP3
DHCPv6
(Server/Client)
Sourceforge
0.10)
MobileIPv6
(MN/HA)
MIPL (Version 2.0)
OS
Linux FedoraCore 3,
kernel 2.6.8.1
Wireless LAN
Atheros, madwifi
(CVS)
12
Summary
• A DHCP-based FH protocol is proposed.
• Main functions of it are ported from FMIP.
• It could offer FH function inexpensive and would
be available soon if you give me a help.
• Any comments welcome!
• Thank you in advance!
13
Annex
14
Functions of proposed method
It has 5 main Functions.
(A), (B) and (C) are almost the same as FMIP, but (D)
and (E) are new functions that FMIP does not offer.
15
Functions of proposed protocol
(A) RA proxying function and (B) DHCP proxying
function.
Fast Handover Options carry information to MNs on
old links, which are to be carried by the standard RA
and DHCP IA options on new links, and MNs do not
need to exchange RS/RA and DHCP solicit
messages on new links.
16
Functions of proposed protocol
(C) Movement detection function
A unique ID for link (L3-information-ID) is
introduced. Fast Handover Options carry new
AP's ID (e.g., BSSID) and its corresponding L3information-ID to MNs on old links, and MNs can
detect movement using those IDs without NUD
on a new link.
17
Functions of proposed protocol
(D) Layer 2 information distribution function
Fast Handover Options also carry new link
information, for example, wireless LAN channel
number used by new APs, and MNs can search for
the notified channel only instead of all channels
and can reduce layer 2 handover.
18
Functions of proposed protocol
(E) Confirm Message solicit function
A unique ID for DHCP-domains is also introduced.
Fast Handover Options carry the IDs, and a MN can
know whether it has entered a new DHCP-domain
after handover. If the MN is still in the same DHCPdomain, it does not need to send a confirm Message
to a DHCP server on a new link.
19
Functions not supported
*Smooth HO function
Tunnel Buffering may be applied
*Prevent interruption during DAD
Opt DAD may be applied.
*Quick user authentication
To be discussed but out of scope of this protocol now.
*Context Transfer of AR
This protocol can not offer this function.
20