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.