Enabling IP Mobility with Identifier-Locator Network Protocol (ILNP)-PGTips
•
1 like•695 views
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.
Recommended
More Related Content
Similar to Enabling IP Mobility with Identifier-Locator Network Protocol (ILNP)-PGTips
Similar to Enabling IP Mobility with Identifier-Locator Network Protocol (ILNP)-PGTips (20)
Recently uploaded
Recently uploaded (20)
Enabling IP Mobility with Identifier-Locator Network Protocol (ILNP)-PGTips
- 2. Outline! • Goal! • Problems! • Current!Approach:!Mobile!IP! • ILNP!Approach! • EvaluaIon! • Conclusion! 2!Ditchaphong!Phoomikia?sak!
- 3. Goal! Enable IP Mobility by using end hosts only, without changing current network infrastructure.! 3!Ditchaphong!Phoomikia?sak!
- 5. 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
- 6. 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
- 7. 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
- 9. 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
- 10. 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!
- 14. 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.!!
- 15. 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!
- 16. 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!
- 17. EvaluaIon!–!Handoff!delay! 17! 1 2 5 10 20 50 100 200 LAN MAN WANHandoffDelay(ms) Test Scenario The mean hand-off delay of Video traffic No emulated loss 10% Emulated Loss 20% Emulated Loss 1 2 5 10 20 50 100 200 LAN MAN WAN HandoffDelay(ms) Test Scenario The mean hand-off delay of VoIP traffic No emulated loss 10% Emulated Loss 20% Emulated Loss Ditchaphong!Phoomikia?sak! Handoff(delay(slightly(increases(as(packet(loss(increases(
- 18. Result!–!Observed!Packet!Loss! 18! 0 5 10 15 20 25 LAN MAN WAN ExperiencedLoss(%) Test Scenario The mean packet loss of Video traffic No emulated loss 10% Emulated Loss 20% Emulated Loss 0 5 10 15 20 25 LAN MAN WAN ExperiencedLoss(%) Test Scenario The mean packet loss of VoIP traffic No emulated loss 10% Emulated Loss 20% Emulated Loss No(gratuitous(loss(for(applica3on(level(flows( Ditchaphong!Phoomikia?sak!
- 19. 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!
- 20. 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!