enabling ip mobility with identifier-locator network protocol (ilnp)-pgtips
DESCRIPTION
Mobility becomes an increasingly important aspect of communication for the Internet. However, the current Internet protocol, IP, was not originally designed to support mobility over the Internet. Mobile users currently suffer from connection disruption when they move around, and the device switch the connection between different wireless technology (perform a vertical handoff). While the IETF Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) solutions have been defined for sometime, and implementations are available, they have seen little deployment due to its complexity. We propose an alternative approach, called the Identifier-Locator Network Protocol (ILNP). ILNP can be implemented by enhancing IPv6 header, named ILNPv6, therefore could be deploy over the current IPv6 network infrastructure without require any changes. Only the mobile host need to be upgraded to understand the new addressing scheme. We have created an overlay implementation of ILNPv6, and our performance evaluation shows that ILNPv6 has a good potential to enable IP mobility through the Internet. The implementation of ILNPv6 in system kernel is an on-going work.TRANSCRIPT
Enabling(IP(Mobility(with(Iden3fier6Locator(Network(
Protocol((ILNP)(
!School!of!Computer!Science,!University!of!St!Andrews!
!
1!Ditchaphong!Phoomikia?sak!
Ditchaphong(Phoomikia@sak([email protected]!
!
Outline!
• Goal!• Problems!• Current!Approach:!Mobile!IP!• ILNP!Approach!• EvaluaIon!• Conclusion!
2!Ditchaphong!Phoomikia?sak!
Goal!
Enable IP Mobility by using end hosts only, without changing current network infrastructure.!
3!Ditchaphong!Phoomikia?sak!
Mobility!and!Handoff!
4!Ditchaphong!Phoomikia?sak!
3G!
WiFi!(AP2)!
WiFi!(AP1)!
MN! MN! MN!Vertical Handoff
Horizontal Handoff
Problems:!Use!of!names!in!IP!
5!
Protocol(Layer( Use(of(name(
ApplicaIon! FQDN,!IP!address!
Transport! IP!address!(+!port!number)!
Network! IP!address!
(Interface)! IP!address!
Entanglement(!(
Ditchaphong!Phoomikia?sak!
MH! IP1!
MH!IP2!
Site%Network%2%(3G)%
Site%Network%1%(WiFi)%
MH: Mobile Host CN: Correspondent Node
MH! IP2!
CN!
IP: Connection break
Current!Approach:!Mobile!IP!
• IETF!Standard!• Allow!a!mobile!host!to!have!2!IP!addresses:!Home!Address!(HoA)!and!CareWofWAddress!(CoA)!
• Transport!Layer!protocols!bind!to!HoA!
• Only!CoA!change!when!handoff!
6!Ditchaphong!Phoomikia?sak!
MH!HoA!
MH! CoA1!
Site%Network%1%(3G)%
Home%Network%(WiFi)%
HA!
HA: Home Agent MH: Mobile Host CN: Correspondent Node
MH! CoA1!
CN!
MIP: Hard Handoff
Problems!in!Mobile!IP!• Require!new!network!enIIes:!Home!Agent!(HA)!
• HA!become!single!point!of!failure!and!performance!bo[lenecks!
• Triangular!RouIng!(MIPv4) • Packet!loss!during!handoff!process (minimised!by!FMIPv6,!HMIPv6,!etc.)!
• Protocol!overhead:!– IPWinWIP!tunnel!between!HA!and!MH!at!CoA!
7!Ditchaphong!Phoomikia?sak!
MH!HoA!
MH! CoA1!
Site%Network%1%(3G)%
Home%Network%(WiFi)%
HA!
HA: Home Agent MH: Mobile Host CN: Correspondent Node
MH! CoA1!
CN!
MIP: Hard Handoff
AlternaIve!Approach:!ILNP!
• IdenIfierWLocator!Network!Protocol!– RFCs:!6740!–!6748!(Experimental)!– Use!IdenIfier/Locator!split!architecture!
• Take!an!endWtoWend!approach!using!naming:!– no!addiIonal!network!enIIes!– no!triangular!rouIng!(use!normal!IP!rouIng)!– no!tunneling!– sod!handoff!to!reduce!packet!loss!
8!Ditchaphong!Phoomikia?sak!
AlternaIve!Approach:!ILNP!
9!
Protocol(Layer( Use(of(name(
ApplicaIon! FQDN!or!!app.Wspecific!
Transport! Node!IdenIfier!(NID)!(+!port!number)!
Network! Locator!(L64)!
(Interface)! dynamic(binding(
Separa3on("(
Ditchaphong!Phoomikia?sak!
MH! [NID1,L1]!
MH![NID1,L1],!![NID1,L2]!!
MH! [NID1,L2]!
Site%Network%2%(3G)%
Site%Network%1%(WiFi)%
MH: Mobile Host CN: Correspondent Node
CN!
ILNP: Soft Handoff
ILNP!Architecture!• Replace!IP!address!with!Node!IdenIfier!(NID)!and!!Locator!(L64)!
• 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!rouIng!and!forwarding!in!the!core!
10!Ditchaphong!Phoomikia?sak!
ILNPv6:!L64!+!NID!value!encoding!
11!
same(syntax(and(seman3cs(as(IPv6(rou3ng((address)(prefix(
so(IPv6(core(routers(work(as(today(
IPv6(rou3ng((address)(prefix( same(syntax,(different(seman3cs(
these(bits(only(examined(and(acted(upon(by(end(systems(
Ditchaphong!Phoomikia?sak!
Mobility!with!ILNPv6!
Two!required!funcIons:!• Rendezvous:!permit!incoming!connecIons!to!a!mobile!host!
• Handoff:!allow!a!mobile!host!to!maintain!communicaIon!sessions!during!locaIon!changes!!
Ditchaphong!Phoomikia?sak! 12!
Mobility!with!ILNPv6!
For!ILNPv6:!• Rendezvous:!use!of!DNS!!
– New!records!(NID!and!L64),!currently!supported!by!some!commercial!DNS!
• Handoff:!!– Sod!Handoff!– Locator!Update!(LU)!to!all!CNs!– Secure!dynamic!update!to!DNS!
Ditchaphong!Phoomikia?sak! 13!
Preliminary!Test!–!Overlay!ImplementaIon!
14!Ditchaphong!Phoomikia?sak!
• Built!ILNPv6!as!an!overlay!network!on!top!of!UDP/IPv6!network!
• Emulate!handoff!between!different!network!while!a!flow!is!onWgoing!
• Evaluate!performance!(e.g.!Loss!and!Delay)!• Paper:!
– D.!Phoomikia?sak,!S.!N.!Bha?.!Network%Layer%So8%Handoff%for%IP%Mobility.!Proceedings!of!the!8th!ACM!workshop!on!Performance!Monitoring!and!Measurement!of!Heterogeneous!Wireless!and!Wired!Networks!(PM2HW2N).!Barcelona,!Spain.!Nov!2013.!!
EvaluaIon!–!Overlay!ImplementaIon!
15!Ditchaphong!Phoomikia?sak!
Protocol(Layer( Protocol( Comments(
ApplicaIon! Packet!transfer! Packets!with!a!numeric!ID,!emulate!VoIP!and!video!!
Transport! Simple!Transport!Protocol!(STP)!
Our!own!dummy!protocol!
Network! ILNPv6! ILNPv6!Overlay!
Link! UDP/IPv6! Unreliable!link!layer!
EvaluaIon!–!Topology!
16!
R1
Emulated Loss and Delay
H1
site network L1
site network L2
H2 R2
site network L3
H2 R3
R router H physical device / host
H2
Traffics:!VoIP:!64kbps,!pkt!size:!300bytes!Video:!658!kbps,!pkt!size:!1400bytes!!Emulate!networks:!LAN:!delay!0ms!MAN:!delay!10ms!WAN:!delay!100ms!0%,!10%,!20%!loss!are!applied!for!each!delay!!
Ditchaphong!Phoomikia?sak!
EvaluaIon!–!Handoff!delay!
17!
1 2
5 10 20
50 100 200
LAN MAN WANH
ando
ff D
elay
(ms)
Test Scenario
The mean hand-off delay of Video traffic
No emulated loss10% Emulated Loss20% Emulated Loss
1 2
5 10 20
50 100 200
LAN MAN WAN
Han
doff
Del
ay (m
s)
Test Scenario
The mean hand-off delay of VoIP traffic
No emulated loss10% Emulated Loss20% Emulated Loss
Ditchaphong!Phoomikia?sak!
Handoff(delay(slightly(increases(as(packet(loss(increases(
Result!–!Observed!Packet!Loss!
18!
0
5
10
15
20
25
LAN MAN WAN
Expe
rienc
ed L
oss (
%)
Test Scenario
The mean packet loss of Video traffic
No emulated loss10% Emulated Loss20% Emulated Loss
0
5
10
15
20
25
LAN MAN WAN
Expe
rienc
ed L
oss (
%)
Test Scenario
The mean packet loss of VoIP traffic
No emulated loss10% Emulated Loss20% Emulated Loss
No(gratuitous(loss(for(applica3on(level(flows(Ditchaphong!Phoomikia?sak!
ILNPv6!vs!MIPv6!(and!extensions)!
19!
Issues( ILNPv6( MIPv6(&(Extensions(
Complexity!and!Scale!
No!addiIonal!enIIes!to!the!network!
Require!addiIonal!enIIes!to!the!network!
Signaling!Overhead!
LU!/!LUWACK!and!DNS!update!
Variable!(depends!on!extension!e.g.!BU!/!BUWACK!for!MIPv6)!
Security! No!new!security!risks!(as!secure!as!IPv6)!
Possible!new!a[ack!vectors!through!new!enIIes!
Ditchaphong!Phoomikia?sak!
Conclusion!
• ILNPv6!has!a!good!potenIal!to!enable!mobility!over!the!Internet!
• So8%Handoff:!– packet!loss!is!minimal!
• EndCtoCend%model:!– No!new!network!enIIes!required!– Low!overhead!(no!tunneling)!
• For!more!info:!h[p://ilnp.cs.stWandrews.ac.uk/!
20!Ditchaphong!Phoomikia?sak!
Future!Works!
• ImplementaIon!of!ILNP!in!a!system’s!network!stack!(Linux!3.9!is!chosen)!
• Performance!evaluaIon!and!comparison!to!current!approach!(Mobile!IPv6)!
21!Ditchaphong!Phoomikia?sak!
Thank(you(
Q(&(A!
22!Ditchaphong!Phoomikia?sak!