edge handovers for mobile ipv6 - swincaia.swin.edu.au/talks/caia-talk-050921a.pdf · edge handovers...
TRANSCRIPT
Edge Handovers for Mobile IPv6
Nick Moore
Monash CTIE / ATcrc
... an interoperable enhancement to Mobile IPv6 to reduce handover latency
for movement within an edge network, and to reduce handover signalling
outside the edge network.
Nick Moore – Monash CTIE / ATcrc – 2/42
Converged Services
• Modern mobile networks carry different types of traffic:
� “Real-time services” – Voice, Video, Games
� “Packet services” – Web, Email, More Games
• Any given device or applications may need to use both kinds of traffic
• “Converged Services” – both kinds of traffic use same routing (etc)
infrastructure.
• Can use packet traffic over voice channel but it’s inefficient, inflexible.
Nick Moore – Monash CTIE / ATcrc – 3/42
Real-time Services over IPv6
• Session initiation with SIP
• Bandwidth allocation with RTP / QoS
• Lots of audio & video codecs
What about mobility?
Nick Moore – Monash CTIE / ATcrc – 4/42
Mobile IPv6
• IPv6 routing is designed for a static Internet.
• MIPv6 provides ‘overlay routing’ for mobile devices.
• Uses a Home Agent to redirect traffic to a Mobile Node.
Nick Moore – Monash CTIE / ATcrc – 5/42
HACN
Internet
MN
AR2 AR3AR1
• Mobile Node (MN) moves between
Access Routers (ARs).
• MN sends Binding Updates (BUs)
to Home Agent (HA).
Nick Moore – Monash CTIE / ATcrc – 6/42
HACN
Internet
MN
AR2 AR3AR1
• HA forwards traffic to MN.
• no Foreign Agent needed.
Nick Moore – Monash CTIE / ATcrc – 7/42
HACN
Internet
MN
AR2 AR3AR1
• MN sends data and BU direct to
CN.
Nick Moore – Monash CTIE / ATcrc – 8/42
HACN
Internet
MN
AR2 AR3AR1
• CN and MN can now correspond di-
rectly.
Nick Moore – Monash CTIE / ATcrc – 9/42
HACN
Internet
AR2 AR3AR1
MN
• If MN moves, it sends BU to HA,
CN.
• CN starts sending data to new lo-
cation.
• HA sends new connections to new
location.
Nick Moore – Monash CTIE / ATcrc – 10/42
Fast Handovers
• IPv6 handovers are not sufficiently fast for real-time services – over
3000ms avg. if fully compliant.
• Handover latency is due to the time taken for the MN to establish itself
on the foreign network.
• If we can predict where our new location will be, we can prepare the way
and thus establish more quickly.
• Difficult at best.
• RFC4068: Fast Handovers for Mobile IPv6
R. Koodli, Ed.
Nick Moore – Monash CTIE / ATcrc – 11/42
Four Delays
Handover delay can be broken down into four parts:
Movement Detection Delay ... “Are we there yet?”
Router Advertisement Delay ... “Where am I?”
Address Configuration Delay ... “Is this number free?”
Binding Update RTT ... “Dear Home Agent ...”
Nick Moore – Monash CTIE / ATcrc – 12/42
Four Delays: Solutions
Rather than trying to solve whole problem at once, address the causes of
delay individually:
Movement Detection Delay DNA WG; L2 Triggers
Router Advertisement Delay Fast RA; FRD
Address Configuration Delay Optimistic DAD
Binding Update RTT HMIPv6; Edge Handovers
Nick Moore – Monash CTIE / ATcrc – 13/42
Localized Mobility Management
We’re making some assumptions about the characteristics of the Edge
Network compared to the Internet:
• High bandwidth
• Low latency
• Low Cost
Localized Mobility Management spends Edge Network resources to save
Internet resources.
Nick Moore – Monash CTIE / ATcrc – 14/42
HMIPv6
AR1 AR2 AR3 AR4 AR5
MAP1 MAP2
HA
• RFC4140: Hierarchical Mobile IPv6 Mobility Management
H. Soliman, C. Castelluccia, K. El Malki, L. Bellier
• Mobility Anchor Point (MAP) between HA and MN.
• Signalling to HA only required when MN leaves coverage area of its MAP.
• Establishes Bindings from a Regional Care-of Address (RCoA) to a Local
Care-of Address (LCoA).
Nick Moore – Monash CTIE / ATcrc – 15/42
HACN
Internet
MN
AR2 AR3AR1
MAP
• MN tells MAP its location (LBU).
• MN tells HA location of MAP
(BU).
Nick Moore – Monash CTIE / ATcrc – 16/42
HACN
Internet
MN
AR2 AR3AR1
MAP
• HA forwards traffic via MAP.
Nick Moore – Monash CTIE / ATcrc – 17/42
HACN
Internet
MN
AR2 AR3AR1
MAP
• MN tells CN its address on the
MAP
• Route is optimized.
Nick Moore – Monash CTIE / ATcrc – 18/42
HACN
Internet
AR2 AR3AR1
MAP
MN
• Now when the MN moves it need
only tell the MAP.
• The MAP is much closer to the ARs
than the HA was, so less latency.
Nick Moore – Monash CTIE / ATcrc – 19/42
Problems with HMIP
• Trend is towards ‘stupid network’ with intelligence at edge –
MAP is not at edge.
• Where should the MAP be?
� Close to the edge: lower latency for faster handovers.
� Far from the edge: larger coverage area thus less MAP-to-MAP
handovers.
• MAP is single point of failure.
Nick Moore – Monash CTIE / ATcrc – 20/42
HMIPv6 at the Edge
AR1
MAP1 MAP2 MAP3 MAP4 MAP5
AR2 AR3 AR4 AR5
HA
• Migrate MAPs down to access routers.
• Described in section 10.2 of the HMIPv6 draft.
• Degenerate case of HMIP? (1-hop tunnels, RCoA and LCoA)
• To be useful, improved MAP-to-MAP handovers are needed.
Nick Moore – Monash CTIE / ATcrc – 21/42
Edge Mesh
AR1 AR2 AR3 AR4 AR5
MAP5MAP1 MAP3MAP2 MAP4
HA
• If MAP1 could continue to provide service to the MN for some time after
it moves to AR2, the signalling required for the handover to MAP2 would
be removed from the critical path of the handover.
• If MAP1 could continue providing service for the MN when it moves from
AR2 to AR3, the handover to MAP2 need not be performed, eliminating
that MAP-to-MAP handover entirely.
Nick Moore – Monash CTIE / ATcrc – 22/42
Edge Network
AR1 AR2 AR3 AR4 AR5
MAP5MAP1 MAP3MAP2 MAP4
HA
• MAP functionality can be integrated into the AR for a simplified network.
• A single physical device can easily perform both MAP and AR functions
at each location.
Nick Moore – Monash CTIE / ATcrc – 23/42
Edge Handovers
• draft-moore-mobopts-edge-handovers-01
N. Moore, JH. Choi, B. Pentland
• draft-moore-mobopts-tunnel-buffering-00
N. Moore, JH. Choi, B. Pentland
Nick Moore – Monash CTIE / ATcrc – 24/42
Forwarding
One very simple thing we can do to improve handovers is to forward traffic
bound for the old address to the new address instead:
MN: LBU(ORCoA, NLCoA) → OAR
• Described in section 8 of the HMIPv6 draft.
• We’ve extended this behaviour.
Nick Moore – Monash CTIE / ATcrc – 25/42
Buffering
If we don’t know where we’re going, request the old MAP/AR to buffer traffic
for us by sending an update to ‘nowhere’.
MN: LBU(ORCoA, ::) → OAR
This could easily be introduced into HMIPv6, too.
Precedent:
• Suggested to us by Richard Nelson (Waikato)
• draft-krishnamurthi-mobileip-buffer6-01
Nick Moore – Monash CTIE / ATcrc – 26/42
MAP-to-MAP-to-MAP handovers
• The Bound Regional Care-of Address (BRCoA) is the RCoA for which
you most recently received a BAck from your HA.
• The Bound Access Router (BAR) is the AR which provided you with the
BRCoA. It is the AR which is acting as your MAP.
Nick Moore – Monash CTIE / ATcrc – 27/42
MN
Edge Network
HA
LCoA
RCoA
EH−AR2EH−AR1 EH−AR3
BU(HAddr, RCoA)
Nick Moore – Monash CTIE / ATcrc – 28/42
MN
Edge Network
HA
LCoA
RCoA
EH−AR2EH−AR1 EH−AR3
TRAFFIC
BAck(HAddr, RCoA)
Nick Moore – Monash CTIE / ATcrc – 29/42
MN
Edge Network
HA
LCoA
BRCoA
BAck(HAddr, RCoA)
EH−AR2EH−AR1 EH−AR3BAR
Nick Moore – Monash CTIE / ATcrc – 30/42
Edge Network
HA
BRCoA
EH−AR2EH−AR1 EH−AR3
MN
NARBAR,OAR
NLCoA
LBU(BRCoA, NLCoA)
NRCoA
Nick Moore – Monash CTIE / ATcrc – 31/42
Edge Network
HA
BRCoA
EH−AR2EH−AR1 EH−AR3
MN
NARBAR,OAR
NLCoA
LBU(BRCoA, NLCoA)
TRAFFIC
NRCoA
Nick Moore – Monash CTIE / ATcrc – 32/42
Edge Network
HA
BRCoA
EH−AR2EH−AR1 EH−AR3
MN
NLCoA
LBU(BRCoA, NLCoA)
NAROARBAR
ORCoA NRCoA
Nick Moore – Monash CTIE / ATcrc – 33/42
Edge Network
HA
BRCoA
EH−AR2EH−AR1 EH−AR3
TRAFFIC
MN
NLCoA
LBU(BRCoA, NLCoA)
NAROARBAR
ORCoA NRCoA
Nick Moore – Monash CTIE / ATcrc – 34/42
Edge Network
HA
EH−AR2EH−AR1 EH−AR3
TRAFFIC
MN
NAR
NRCoA
BU(HAddr,NRCoA)
OARBAR
Nick Moore – Monash CTIE / ATcrc – 35/42
Edge Network
HA
EH−AR2EH−AR1 EH−AR3
MN
NAR
NRCoA
BAck
TRAFFIC
OARBAR
Nick Moore – Monash CTIE / ATcrc – 36/42
Edge Network
HA
EH−AR2EH−AR1 EH−AR3
MN
BAR
BRCoA
BAck
TRAFFIC
Nick Moore – Monash CTIE / ATcrc – 37/42
Handover Heuristic
The MN must choose when to update its Home Agent and thus change its
BAR.
• as soon as the critical path of the handover is complete.
• every N seconds.
• every N handovers.
• once the MN has been on the same AR for N seconds.
• if a handover has crossed an administrative domain.
• The LBAck has taken > N routing hops.
• ???
Nick Moore – Monash CTIE / ATcrc – 38/42
CR /MAP
AR2
10ms
AR6
10msCN
100ms
HA100ms
AR310ms
AR5
10msAP
AP
AP
AR7
10ms
AR8
10ms
AP
AP
AP
AP
AP
AP
AR410ms
APAP
AP
AP
AP
AP
AP
AP
AP
AR9 10ms
APAP
AP
AP
AP
AP
Simulation
• OMNeT++
• IPv6Suite
Campus Network
• 24 Access Points
• 8 Access Routers
• 1 Core Router / MAP
• 1 Home Agent
• 1 Correspondant Node
• 50 Mobile Nodes
Nick Moore – Monash CTIE / ATcrc – 39/42
Results
• HMIP: CR is the MAP
• EH: All ARs are EH capable.
• Handover Heuristic: change BAR every 10 seconds
• Measured time between L2 Up signal and the next ...
� MIP: BAck from HA.
� HMIP: LBAck from MAP.
� EH: LBack from BAR.
Nick Moore – Monash CTIE / ATcrc – 40/42
0
10
20
30
40
50
0 50 100 150 200 250 300 350 400
%
latency (ms)
med=289ms MIPmed=110ms HMIP
med= 92ms EH
Nick Moore – Monash CTIE / ATcrc – 41/42
0
5
10
15
20
25
40 60 80 100 120 140
%
latency (ms)
HMIPEH
Nick Moore – Monash CTIE / ATcrc – 42/42
Ongoing Work
• Larger Scenarios.
• Mesh Scenarios.
• More investigation of Handover Heuristic.
• Release of Linux implementation.
• IETF standardization.
Acknowledgements
• JinHyeock Choi and Brett Pentland, my co-authors.
• Johnny Lai for writing the simulation code and running experiments.
• Ahmet Sekercioglu for getting this project underway.
• Samsung SAIT for funding this research via ATcrc.