[PPT] - IP-Layer Soft Handoff Implementation in ILNP Ditchaphong (Dean) PowerPoint Presentation

SLIDE 1

IP-Layer Soft Handoff Implementation in ILNP

Ditchaphong (Dean) Phoomikiattisak, Saleem Bhatti School of Computer Science, University of St Andrews {dp32|saleem}@st-andrews.ac.uk

SLIDE 2

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 2

Outline

■ Goals ■ Problems ■ Overview of ILNP ■ ILNPv6 Implementation in Linux ■ Performance Evaluation ■ Conclusions & Future Works

SLIDE 3

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 3

Goals

■ Enable IP Mobility using totally end-to-end model:

– Eliminate additional network entities – Minimise complexity and overhead

■ Minimise packet loss during handoff:

– “IP-Layer Soft Handoff”

SLIDE 4

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 4

Problems of Mobility using IP Addresses

Protocol Layer IP

Application FQDN, IP address Transport IP address

(+ port number)

Network IP address (Interface) IP address

MH ¡

IP1 ¡

MH ¡

IP2 ¡

Site ¡Network ¡2 ¡ Site ¡Network ¡1 ¡ MH: Mobile Host

SLIDE 5

Problems of IP Addresses

5 Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk

“IP addresses considered harmful”, (editorial) Brian Carpenter, ACM SIGCOMM CCR, Apr 2014

SLIDE 6

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 6

Many proposed solutions

■ MIPv6 (RFC 6275) and extensions:

– FMIPv6 (RFC 5568) – HMIPv6 (RFC 5380)

■ PMIPv6 (RFC 6543) ■ HIP (RFC 5201, RFC 5206) ■ LISP (RFC 6830) ■ SHIM6 (RFC 5533) ■ Multipath TCP (RFC 6824) ■ ILNP (RFC 6740)

SLIDE 7

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 7

Overview of ILNP

■ “Identifier Locator Network Protocol” ■ RFCs 6740-6748 (IRTF RRG, Experimental) ■ Replace IP address with Node Identifier (NID) and

Locator (L64)

■ End-to-end architecture: no new entity required

SLIDE 8

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 8

Overview of ILNP

ILNP FQDN

(RFC1958)

Node Identifier

(+ port number)

Locator

(dynamic mapping)

Protocol Layer IP Application FQDN or IP address Transport IP address

(+ port number)

Network IP address (Interface) IP address

SLIDE 9

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 9

Overview of ILNP

■ NID:

– Is not topologically significant – Name a node, not an interface – Upper layer protocol bind only to NID

■ L64:

– Is topologically significant – Names a (sub)network (as today's network prefix) – Used only for routing and forwarding in the core

SLIDE 10

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 10

ILNPv6 Implementation in Linux

■ ILNPv6:

– ILNP implemented as a superset of IPv6

■ Dual-stack approach:

– Re-use IPv6 codes

■ Kernel version 3.8.0

SLIDE 11

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 11

ILNPv6 Implementation in Linux – Encoding NID and L64

same ¡syntax ¡and ¡seman+cs ¡as ¡ IPv6 ¡rou+ng ¡(address) ¡prefix ¡ so ¡IPv6 ¡core ¡routers ¡work ¡as ¡today ¡ IPv6 ¡rou+ng ¡(address) ¡prefix ¡ same ¡syntax, ¡different ¡seman+cs ¡ these ¡bits ¡only ¡examined ¡and ¡ acted ¡upon ¡by ¡end ¡systems ¡

SLIDE 12

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 12

ILNPv6 Implementation in Linux – Name Resolution

■ Add new syntax in /etc/hosts: L64 | preference, NID hostname

e.g.

2001:1111:0000:0000|10,225:90ff:fe10:4959 ilnp1 ■ getaddrinfo() is modified to interpret this new syntax

For experimental purposes only

DNS also possible (RFC6742, BIND 9.9.3-P1)

SLIDE 13

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 13

ILNPv6 Implementation in Linux – ILNP Communication Cache (ILCC)

■ Store information of current active ILNP sessions

– Local/Remote NID – Local/Remote L64 – Local/Remote Nonce (bidirectional, for now)

■ Add when a communication session start ■ Update when a node handoff ■ Expire after idle time

SLIDE 14

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 14

ILNPv6 Implementation in Linux – Session Initiation

X Y

NID_local L64_local NID_remote L64_remote Nonce

ILCC (Y)

NID_local L64_local NID_remote L64_remote Nonce

ILCC (X)

/etc/hosts (DNS) [NIDY, LY] Who is Y?

NIDY LY (Active) NXY NIDX L1X (Active)

First Packet (with NXY)

NIDY LY (Active) NIDX L1X (Active) NXY

SLIDE 15

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 15

ILNPv6 Implementation in Linux – Handoff: Hard Handoff

X

L2

X

L1

X

L2

■ Change of network:

– simple – change L64 value from L1 to L2 – gratuitous packet loss (similar to Mobile IP)

SLIDE 16

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 16

ILNPv6 Implementation in Linux – Handoff: Soft Handoff

X

L2

X

L1 L2

X

L1

■ Unique to ILNP:

– use L1 and L2 simultaneously (analogous to radio soft handoff) – minimises gratuitous packet loss

SLIDE 17

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 17

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

X Y

new prefix received

NID_local NIDY L64_local LY (Active) NID_remote NIDX L64_remote L1X (Active) Nonce NXY

ILCC (Y)

NID_local NIDX L64_local L1X (Active) NID_remote NIDY L64_remote LY (Active) Nonce NXY

ILCC (X)

SLIDE 18

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 18

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

X Y

new prefix received

NID_local NIDY L64_local LY (Active) NID_remote NIDX L64_remote L1X (Active) Nonce NXY

ILCC (Y)

NID_local NIDX L64_local L1X (Expired* or Valid+) L2X (Active) NID_remote NIDY L64_remote LY (Active) Nonce NXY

ILCC (X)

* Hard Handoff

+ Soft Handoff

LU (L2X) with NXY

SLIDE 19

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 19

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

X Y

new prefix received

NID_local NIDY L64_local LY (Active) NID_remote NIDX L64_remote L1X (Expired) L2X (Active) Nonce NXY

ILCC (Y)

NID_local NIDX L64_local L1X (Expired* or Valid+) L2X (Active) NID_remote NIDY L64_remote LY (Active) Nonce NXY

ILCC (X)

* Hard Handoff

+ Soft Handoff

LU (L2X) with NXY L U

A

C K ( L2X ) w i t h NXY

SLIDE 20

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 20

Performance Evaluation

■ Aim:

– Performance of Layer 3 handoff provided by ILNP – Performance of overall application flow

■ Ignore for now:

– Layer 2 handoff – QoE at the application

SLIDE 21

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 21

Performance Evaluation

■ Real systems, wired connection ■ Streamed UDP (emulated VoIP and ViIP) from H1 to H2 ■ H2 handoff every 9 sec, with 5 sec in overlap area

R1 H1 site network L1 site network L2 H2 site network L3 H2 R2 R router H physical device / host H2 Emulated Loss and Delay for WiFi Emulated Loss and Delay for 3G

SLIDE 22

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 22

Results: Packet Loss

1 2 3 4 5 VoIP Video Experienced Gratuitous Loss (%) Test Scenario The mean gratuitous packet loss Hard Handoff Soft Handoff

Hard handoff: gratuitous loss observed Soft handoff: nearly zero gratuitous loss

SLIDE 23

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 23

Results: Delay

20 40 60 80 100 120 140 160 180 200 VoIP Video Experienced Delay (ms) Test Scenario The mean packet delay of WiFi/3G-A network Emulated Delay Hard Handoff Soft Handoff 100 200 300 400 500 600 VoIP Video Handoff Delay (ms) Test Scenario The mean hand-off delay RTT Hard Handoff Soft Handoff

Hard handoff and soft handoff provide similar behaviour

SLIDE 24

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 24

Conclusion

■ Implementation of ILNPv6 is not a huge work

– Dual-stack implementation is possible:

Does extend current IPv6 code

■ ILNPv6 could enable seamless mobility

– Soft Handoff:

Minimise Packet loss
Enable smooth vertical handoff

– Low handoff delay:

1 RTT

SLIDE 25

Ditchaphong Phoomikiattisak dp32@st-andrews.ac.uk 25

Future Works

■ Evaluation with wireless networks ■ Direct performance comparison with Mobile IPv6 ■ More scenarios e.g. simultaneous movement

IP-Layer Soft Handoff Implementation in ILNP

Ditchaphong (Dean) Phoomikiattisak, Saleem Bhatti School of Computer Science, University of St Andrews {dp32|saleem}@st-andrews.ac.uk

Outline

Goals

– Eliminate additional network entities – Minimise complexity and overhead

– “IP-Layer Soft Handoff”

Problems of Mobility using IP Addresses

Protocol Layer IP

Application FQDN, IP address Transport IP address

(+ port number)

Network IP address (Interface) IP address

IP1 ¡

IP2 ¡

Problems of IP Addresses

“IP addresses considered harmful”, (editorial) Brian Carpenter, ACM SIGCOMM CCR, Apr 2014

Many proposed solutions

– FMIPv6 (RFC 5568) – HMIPv6 (RFC 5380)

Overview of ILNP

Locator (L64)

Overview of ILNP

ILNP FQDN

(RFC1958)

Node Identifier

(+ port number)

Locator

(dynamic mapping)

Protocol Layer IP Application FQDN or IP address Transport IP address

(+ port number)

Network IP address (Interface) IP address

Overview of ILNP

– Is not topologically significant – Name a node, not an interface – Upper layer protocol bind only to NID

– Is topologically significant – Names a (sub)network (as today's network prefix) – Used only for routing and forwarding in the core

ILNPv6 Implementation in Linux

– ILNP implemented as a superset of IPv6

– Re-use IPv6 codes

ILNPv6 Implementation in Linux – Encoding NID and L64

ILNPv6 Implementation in Linux – Name Resolution

e.g.

**For experimental purposes only**

DNS also possible (RFC6742, BIND 9.9.3-P1)

ILNPv6 Implementation in Linux – ILNP Communication Cache (ILCC)

– Local/Remote NID – Local/Remote L64 – Local/Remote Nonce (bidirectional, for now)

ILNPv6 Implementation in Linux – Session Initiation

ILNPv6 Implementation in Linux – Handoff: Hard Handoff

L2

L1

L2

– simple – change L64 value from L1 to L2 – gratuitous packet loss (similar to Mobile IP)

ILNPv6 Implementation in Linux – Handoff: Soft Handoff

L2

L1 L2

L1

– use L1 and L2 simultaneously (analogous to radio soft handoff) – minimises gratuitous packet loss

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

ILNPv6 Implementation in Linux – Handoff: Locator Update (LU)

Performance Evaluation

– Performance of Layer 3 handoff provided by ILNP – Performance of overall application flow

– Layer 2 handoff – QoE at the application

Performance Evaluation

Results: Packet Loss

Hard handoff: gratuitous loss observed Soft handoff: nearly zero gratuitous loss

Results: Delay

Hard handoff and soft handoff provide similar behaviour

Conclusion

– Dual-stack implementation is possible:

– Soft Handoff:

– Low handoff delay:

Future Works

http://ilnp.cs.st-andrews.ac.uk/

For experimental purposes only