Transcript Mobility and Future Internet_2015

Mobility and Future Internet
Networking Lab.
Department of Computer Engineering
Kyung Hee University
Choong Seon Hong
Outline
Introduction to MIPv4, MIPv6, and PMIPv6
Current Internet Architecture
Why ID/Locator Separation Architecture?
ID/Locator Separation Architecture Overview
Related Works on ID/Locator Separation
Proposed ID/Locator Separation-based Lightweight Mobility Architecture in
Wireless Sensor Network
Conclusion
MobilityFirst
2
Mobile IPv4
Motivation for Mobile IP
 TCP session needs to keep the same IP address for the life of
the session
 IP needs to change the IP address when mobile node moves to a
new location
Mobile Node has two IP addresses (2-tier addressing)
 Home-of Address (HoA) : its identifier
 Care-of Address (CoA) : its locator
New Entity : Home Agent (HA), Foreign Agent (FA)
 Router on the home link and foreign link
 Tracks the MN’s current point of attachment
3
Mobile IPv4 Operation
Foreign Link
Home Link
Mobile Node
(MN)
Home Agent(HA)
Move
Registration Request
Reply
Data
Foreign Agent (FA)
Agent Advertisement
Solicitation
Home Address
- CoA
1. MN Moves to FA
2. Agent Solicitation
3. Agent Advertisement
4. MN registers CoA to HA.
5. Creating HA Turnneling
Data
Corresponding Node (CN)
6. CN Sends data to MN
through Turnneling
7. MN sends data to CN
directly
4
Mobile IPv6
C.Perkins et al., “Mobile Support in IPv6”, RFC 3775, June 2004.
Address Auto-configuration
 Movement detection by monitoring advertisement of new prefix
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header




Home Test Init / Home Test
Care-of Test Init /Care-of Test
Binding Update / Binding Acknowledgement
Binding Refresh Request / Binding Error
Binding Updates to CN as well as HA in the context of Route
Optimization
Home Address destination option
 Replace MN’s CoA with MN’s HoA for the source address of packets sent
from MN to CN
Type 2 Routing Header option
 Replace MN’s CoA with MN’s HoA for the destination address of packets
sent from CN to MN
5
Mobile IPv6 Operation
Mobile Node registers at its Home Agent
Network B
R
Network A

.

R
Internet
Mobile Node
Home Agent
R
Network C
Correspondent
Node C
 Mobile Node used Auto-configuration and Neighbor discovery to obtain a
global IPv6 address. (No Foreign Agent needed)
 Mobile Node sends Binding Update to HA
 Home Agent replies with Binding Acknowledgement to MN
6
Mobile IPv6 Operation
Triangular Routing during Initial Phase
R
Network B
Network A

R
Internet
Mobile Node

Home Agent
Network C
R

 Correspondent Node C initiates connection and sends
packets to the Home Address of the Mobile Node
 Home Agent intercepts packets and tunnels them
Correspondent
Node C
to the Mobile Node
 Mobile Node sends answer directly to Host C
7
Mobile IPv6 Operation
Route Optimization Operation
R

Network B
Network A
R
Home Agent
Internet
Mobile Node
Network C
R

 Mobile Node sends Binding Update to Correspondent
Node C
Correspondent
Node
 Now Correspondent Node can address the CoA of the
Mobile Node directly
8
Mobile IPv4 vs Mobile IPv6
There is no need for Foreign Agents since the MN can use the
Address Auto-configuration protocol to obtain a dynamic careof address
Binding updates are supplied by encoding them as TLV
destination options in the IP header
IPv6 provides security protocols hence simplifying the
authentication process
Route Optimization is Mandatory
Return Routerability is checked for the security reason
9
Proxy Mobile IPv6
Network-based Mobility
 Mobility handled by the network, often transparent to the mobile node
 Directly or indirectly triggered by the mobile node
Host-based Mobility
 Mobility handled by the mobile node
 Full involvement of the mobile node
Binding Update
Binding Update
A) Host-based Mobility
Management
B) Network-based Mobility
Management
10
Proxy Mobile IPv6
Host-based Mobile IPv4/v6 (RFC 3344/3775) has not been yet
deployed that much.
 Why host-based MIP is not deployed yet?
 Too heavy specification to be implemented at a small terminal
• RFC 3344 (MIPv4): 99 pages
• RFC 3775 (MIPv6): 165 pages
 Battery problem
 Waste of air resource
 No Stable MIPv4/v6 stack executed in Microsoft Windows OS
3GPP, 3GPP2 and WiMAX operators showed their STRONG
interests for network-based IP mobility solution
 They even deployed their non-standardized network-based IP mobility
solution (not Mobile IPv4/v6!).
11
Proxy Mobile IPv6
Goal of PMIPv6
 PMIPv6 protocol is for providing mobility support to any IPv6 host
within a restricted and topologically localized portion of the network
and without requiring the host to participate in any mobility related
signaling.
registration
PMIPv6 Scenario
(being extended)
12
Proxy Mobile IPv6 Operation
LMA: Localized Mobility Agent
MAG: Mobile Access Gateway
IP Tunnel
IP-in-IP tunnel between LMA and MAG
LMA
Home Network
MN’s Home Network
(Topological Anchor Point)
MAG
LMA Address (LMAA)
movement
MN’s Home Network Prefix (MN-HNP)
CAFE:2:/64
MN’ Home Address (MN-HoA)
MN continues to use it as long as it roams
within a same domain
MAG
That will be the tunnel entry-point
LMM
(Localized Mobility Management)
Domain
Proxy Binding Update (PBU)
Control message sent by MAG to LMA to
establish a binding between MN-HoA and
Proxy-CoA
Proxy Care of Address (Proxy-CoA)
The address of MAG
That will be the tunnel end-point
13
Current Internet Architecture
Application Layer
IP address
Identify application
by IP address
Use IP address as Identifier
Transport Layer
IP address
Network Layer
IP address
Identify socket
by IP address
Routing
by IP address
Use IP address as Locator
In the current Internet architecture, IP addresses act as both
node identifiers and locators.
14
Why ID/Locator Separation Architecture?– Problems of the current Int
ernet
 Roles of IP address in the current Internet Architecture
 Two roles combined :
− End-point Identifiers (names of interfaces on hosts)
− Locators (names of topological locations)
 Basically, the current Internet architecture requires IP addresses to remain
unchanged during a session.
 Change of IP address indicates change of endpoint ID.
 Communication session or security association terminates
 Multiple roles of IP address are not suitable for mobile environments in the
future Internet.
 In the future mobile environments, the demand of mobility and multi-homing
needs to change of IP addresses.
 Many solutions are proposed for supporting mobility: MIPv4, MIPv6, PMIPv6,
mSCTP, mSIP, etc.
 These solutions do not integrate nicely mobility control as the form of patch-on
 added complexity
15
Why ID/Locator Separation Architecture? – New requirements to Internet
Mobility support for mobile terminals
 Get new locators on move while keeping IDs
Mobility support for sensor devices (and group)
 Quite many sensor nodes to be connected to Internet
 Hundred billions or more of Internet nodes (Internet of Things)
Dynamic network configuration for various applications
 Self-configuration, optimization, dynamic deployment
More flexible and reliable routing
 Huge number of routing table entries
Multi-homing support
 Switch locators dynamically while keeping IDs
Separation of data and control paths
Heterogeneous network support (such as sensor networks)
 Solutions : ID/Locator Separation Architecture
• Separate identifiers used by apps from addresses (locators) used by routing
16
ID/Locator Separation Architecture Overview
Application
Layer
Identifier
Transport
Layer
Identifier
Identify
Layer
Identifier
Network
Layer
mapping
Name
Specify hosts by ID
Recognize hosts by ID
mapping
Locators
Locators
Locators
Map host ID to locator
Locators
Locators
Locators
Routing by Locator
New Identify layer on hosts is inserted between network and
transport layer
 Identify layer maps between ID and Locator
Use of locator is transparent to applications and transport
17
Related Works on ID/Locator Separation
IRTF/IETF
 Routing Research Group (RRG)
 Developing a technical framework for ID/locator split-based routing
architectures
 Host Identify Protocol (HIP) Working Groups
 Developing an ID/locator split-based host protocols for secure mobility and
multi-homing
 SHIM6 Working Group
 Developing protocols to support site multi-homing in IPv6
 Locator/Identifier Separation Protocol (LISP) Working Group
 LISP supports the separation of the IPv4 and IPv6 address space following a
network-based map-and-encapsulate scheme
ITU-T
 Study Group 13
 Y.2015 (2009): General requirements for ID/locator separation in NGN
 Y.FAid-loc-split (Q.5/13), Y.ipv6split (Q.7/13) in progress
AKARI Project : (NICT’s initiation to clean-slate design of New Generation
Network)
 Includes research on ID/locator split architectures
18
Proposed ID/Locator Separation-based
Lightweight Mobility Architecture
in Wireless Sensor Network
Refer to : Jinho Kim, Jun Lee, Hyoeng Kyu Kang, Dae Sun Kim, Choong Seon Hong, Sungwon
Lee, "An ID/Locator Separation-based Mobility Management Architecture for WSNs," IEEE
Transactions on Mobile Computing (IEEE TMC), Vol.13, No.10, pp.2240-2254, October 2014
19
Introduction
This work focuses on the scheme which supports the mobility
for IPv6-based Wireless Sensor Network (i.e., 6LoWPAN).
Mobility in 6LoWPAN is utilized in realizing many applications
where sensor nodes sense and transmit the gathered data to a
monitoring server.
 e.g., Healthcare, Logistics, Intelligent Transport System, etc.
Sensor nodes with Internet connection ensures that the sensor
data can be accessed anytime and anywhere.
Propose a lightweight global mobility support scheme for both
sensor node mobility & network mobility, based on the new
ID/Locator separation architecture.
20
Research Goals
Sensor devices (and group of them) mobility for Internet
of Things
New ID/Locator separation architecture for 6LoWPAN
mobility
Energy-efficient mobility support
ID-based communication with location-based routing
Separation of identifier and locator
Fully network-based mobility control
Separation of mobility control from data transport
Packet route optimization
21
Overview of IPv6 over Low power WPAN (6LoWPAN)
6LoWPAN Architecture

No method exists to make IP run over IEEE 802.15.4 networks
 Worst case IEEE 802.15.4 PDU 81 octets, IPv6 MTU requirements 1280 octets

Stacking IP and above layers may not fit within one 802.15.4 frame
 IPv6 40 octets, TCP 20 octets, UDP 8 octets + other layers (security, routing, etc) leaving few bytes
for data
 Adaptation Layer
 IPv6 packet Fragmentation, Reassembly, Mesh Routing, Packet Compression, Decompression
22
Conventional Mobility Management Protocols in 6LoWPAN
Host-based Mobility Approach

6LoWPAN with MANET (Mobile Ad-hoc Network)
 Only Intra-PAN mobility is supported by MANET routing
protocol

HA
6LoWPAN with MIPv6 (Mobile IPv6)
 When a 6LoWPAN node moves to another PAN, it requires
an exchange of signaling messages with its home agent.
 This approach is unsuitable for energy-constrained sensor
nodes.
 All of the 6LoWPAN nodes should have a mobility
stack.
IPv6 Network
AR
AR
MN
MN
The host-based mobility approach is unsuitable for
energy-constrained sensor nodes.
23
Mobility Management Protocols in 6LoWPAN
Network-based Mobility Approach
2. BU
3. BA
Router
HA
 6LoWPAN with NEMO
(Network Mobility)
Router
[ IPv6 Network ]
1. Compressed BU
4. Establish
Bi-directional
Tunnel
5. Compressed BA
Full Function Device
6LoWPAN Mobile
Network Node
6LoWPAN Mobile Router
6LoWPAN Gateway
(6LoWPAN Coordinator)
 6LoWPAN nodes can maintain connectivity
with the Internet through the 6LoWPAN
mobile router (MR) as a network unit.
 Propose a new header compression scheme
for mobility headers in 6LoWPAN networks
 Propose a lightweight NEMO protocol to
minimize the signaling overhead by using a
compressed mobility header
 NEMO has been assumed that the sensor nodes will move together under mobile router.
• The NEMO is unable to provide the solution for the individual or scattered mobility of the host.
• Nested NEMO & Route Optimization problem
24
Mobility Management Protocols in 6LoWPAN
Network-based Mobility Approach
Local Mobility Anchor
(LMA)
AAA
IPv6 Network
Router
Router
6LoWPAN
Gateway 2
6LoWPAN
Gateway 1
PAN#2
PAN#1
6LoWPAN
FFDs
6LoWPAN
Mobile
Sensor Node
6LoWPAN
FFDs
 6LoWPAN with PMIPv6
(Proxy Mobile IPv6)
 The 6LoWPAN sensor node itself does not
require any mobility related to the signal
messages.
 The conventional PMIPv6 protocol cannot
be applied to multi-hop-based 6LoWPAN
networks.
 Propose a PAN attachment detection
scheme for 6LoWPAN sensor nodes.
 PMIPv6 has been assumed that the sensor nodes will move within the PMIPv6 domain.
• The PMIPv6 supports only localized mobility, and PMIPv6 is unable to provide the NEMO protocol.
Refer to: Jinho Kim, Rim Haw, Eung Jun Cho, Choong Seon Hong, Sungwon Lee, "A 6LoWPAN Sensor Node Mobility Scheme
Based on Proxy Mobile IPv6," IEEE Transactions on Mobile Computing, VOL. 11, NO. 12, pp. 2060-2072, December 2012
25
Overview of Lightweight Mobility Management Architecture
DINS
Static Mapping Table
• Device Name
• Device ID
• Device’s ILMA
Device Name
Lookup
Device ID Naming Server
(DINS)
Signaling
Control
Network
ILMA
Dynamic Mapping Table
• Device ID
• Device Locator
Home Registration
Global IPv6-based
Core Network
(Location-based
Communication)
Location Update
ID/Locator Mapping Agent
(ILMA)
Edge
Router
Edge
Router
6LoWPAN GW
Dynamic Mapping Table
• Device ID
• 16-bit short ID
• CN’s ID/Locator
6LoWPAN Gateway
(Location)
6LoWPAN
(Device ID-based
Communication)
…
6LoWPAN Mobile Node (ID)
6LoWPAN Mobile Node (ID)
26
Device Identifying Structure
Device Name
 Human readable character (ex. terminal1@myhome)
 Identify devices for communication initialization
Device ID





Location independent
Used as control information and headers
Globally unique device ID (128-bit) in the sensor network
All devices should be identified by Device ID.
CID (Corresponding ID), LID (Local Device ID)
Nation
(16)
Region
(16)
Network
Type (16)
PAN ID
(16)
IEEE 802.15.4 MAC address(64)
Device ID (128-bit)
Locator






To represent locations of a device in the sensor network topology
Locators are temporal; change due to the device mobility
Re-use of IPv6 global address as Locator (128-bit)
Egress Interface address of the Gateway
RLOC (Remote Locator), LLOC (Local Locator)
16-bit short address (temporary within the PAN area)
27
Mobility Scenario
DINS
Device ID Naming Server
(DINS)
F-ILMA
(Foreign-ID/Locator
Mapping Agent)
H-ILMA
(Home-ID/Locator
Mapping Agent)
GW
GW
GW
GW
GW
GW
MR
MR
Intra-PAN
Mobility
Inter-PAN
Mobility
Inter-Domain
Mobility
Inter-PAN
Mobility
(into the NEMO)
Network
Mobility
(NEMO)
28
Movement Detection & Association
PAN#1
PAN#2
6LoWPAN
Gateway 1
6LoWPAN
Gateway 2
Inter-PAN
Mobility
6LoWPAN
Mobile Sensor Node
Inter-PAN
Mobility
Intra-PAN
Mobility
(b) Active Scan
(a) Intra-PAN and Inter-PAN mobility
Receive beacon messages
with PAN ID from neighbor 6LoFFDs
(c) Measurement for RSSI of beacon
Send beacon
request message
(broadcast)
PAN#1
PAN#2
(d) Associated with the new PAN
29
Default Gateway Discovery
 To discover the Default Gateway in the current PAN area
 Using modified Router Solicitation (RS) & Router Advertisement (RA) messages
 RS and RA messages should contain the mesh header for multi-hop routing.
 6LoWPAN mobile node and mobile router’s 16-bit short address option is included in the RA message.
 6LoWPAN Gateway assigns a 16-bit short ID, and it has a list of all the 6LoWPAN nodes.
Gateway
RS
Gateway
RA
RS
Gateway
RA
MR
MR
RS
RA
Proposed Router Solicitation (RS) Message Format
MN (64) GW (16) DSP HC1
IPv6
6LoWPAN Mesh 6LoWPAN IP (addressing) header
header
RS
header
RS option
Router Solicitation
Proposed Router Advertisement (RA) Message Format
GW (16) MN (64)
6LoWPAN Mesh
header
RA
16-bit short
header
ID option
6LoWPAN IP (addressing) header Router Advertisement
DSP HC1
IPv6
30
ID Registration
 To register the 6LoWPAN device ID to the 6LoWPAN Gateway
 Using proposed ID Update (IDU) & ID Acknowledgement (IDA) messages
 Upon receipt of IDU message, the 6LoWPAN Gateway updates the mapping table .
 (Device ID : 16-bit short ID)
Gateway
IDU
IDA
Gateway
MR IDU
Gateway
Proxy IDA
MR IDA
Proxy IDU
MR
MR
IDU
IDA
Proposed ID Update (IDU) Message Format
MN (16) GW (16) DSP HC1 MHD
6LoWPAN Mesh
header
IPv6
6LoWPAN IP
(addressing) header
IDU
IDU, MR IDU, Proxy IDU
Proposed ID Acknowledgement (IDA) Message Format
GW (16) MN (16)
6LoWPAN Mesh
header
DSP HC1 MHD
IPv6
6LoWPAN IP
(addressing) header
IDA
IDA, MR IDA, Proxy IDA
31
ID Registration – New IDU & IDA Messages Format
IEEE 802.15.4 Frame Format
FCF
DSN
Dst EUID 64
Len
Preamble
SFD
Dst pan
Dst16
Src pan
Src EUID 64
MESH : Mesh Header
Dispatch (DSP) : LOWPAN_MH Mobility Header
HC1 : Src. & Dest: Link Local, Next header=Mobility Header
IP : Hop Limit
MHD : Mobility Header Dispatch
IDU: Sequence Number, Lifetime, Flags, Device ID
IDA: Sequence Number, Lifetime, Status
Network Header & Application Data
Src16
Fchk
M
E
S
H
Max 127 bytes
D H M
IDU
I
S C H
P
P 1 D
IDA or
• Proposed LOWPAN_MH
Dispatch Header Pattern (1 byte)
• Dispatch Header Patterns
• Proposed Compressed IPv6
Header (HC1 header : 1byte)
Pattern
Pattern Name
Pattern Meaning
00 xxxxxx
NALP
Not a LoWPAN frame
01 000001
IPv6
uncompressed IPv6 Addresses
01 000010
LOWPAN_HC1
LOWPAN_HC1 compressed IPv6
01 000011
LOWPAN_MH
LOWPAN_MH Mobility Header Dispatch
01 000100
LOWPAN_LD
LOWPAN_LD Locator Discovery Dispatch
……
reserved
Reserved for future use
01 010000
LOWPAN_BC0
LOWPAN_BC0 broadcast
……
reserved
Reserved for future use
• Source prefix compressed
• Source interface identifier compressed
• Destination prefix compressed
• Destination interface identified compressed
• Traffic and Flow Label zero
• Next Header
00:Mobility Header, 01:Locator Discovery, 10, 11:reserved
01 111111
ESC
Additional Dispatch byte follows
• Additional HC2 compression header follows
0
1
2
3
4
5
6
7
0
1
0
0
0
0
1
1
0
1
2
3
4
5
6
7
32
ID Registration – New IDU & IDA Messages Format
IEEE 802.15.4 Frame Format
FCF
DSN
Dst EUID 64
Len
Preamble
SFD
Dst pan
Src pan
Dst16
Src EUID 64
Network Header & Application Data
Src16
Fchk
M
E
S
H
Max 127 bytes
D H M
IDU
I
S C H
P
P 1 D
IDA or
• Proposed LOWPAN_MH Dispatch (1 byte)
• ID Update (IDU) message
0
0
7
1
2
3
4
5
6
Sequence # Lifetime
IDU (if 0)
IDA (else if 1)
IDU
IDA
Device ID
7
1byte
1.
2.
3.
4.
5.
6.
7.
MESH : Mesh Header
Dispatch (DSP) : LOWPAN_MH Mobility Header
HC1 : Src. & Dest: Link Local, Next header=Mobility Header
IP : Hop Limit
MHD : Mobility Header Dispatch
IDU: Sequence Number, Lifetime, Flags, Device ID
IDA: Sequence Number, Lifetime, Status
Sequence Number compressed
Lifetime compressed
Acknowledgement bit
Home Registration bit
Device ID bit
Mobile Router bit
Proxy IDU bit
1byte
16 bytes
• ID Acknowledgement (IDA) message
Sequence # Lifetime
1byte
1byte
1. Sequence Number compressed
2. Lifetime compressed
3~7 Status
33
Location Update
DINS
(Device ID
Naming
Server)
(7) Response
(6) Device ID Lookup
(5) Query (Device’s Home Location ??)
(9) Device ID/Locator
Mapping Table Update
(8) Home Registration
H-ILMA
(Home-ID/Locator
Mapping Agent)
C-ILMA
(CorrespondingID/Locator
Mapping Agent)
F-ILMA
(Foreign-ID/Locator
Mapping Agent)
(10) Home Registration Ack
(13) Binding Request
(MN : CN)
(11) Location Ack
(4) Location Update
(16) Location Update
(14) De-Registration Gateway
(15) Transfer the Binding
Gateway
Gateway
(17) Location Ack
(12)
(3)
(2)
IDU
RA
(1)IDA
RS
Movement
CN
34
Locator Discovery
(4) Device ID Lookup
DINS
(Device ID
Naming
Server)
(6) Query
F-ILMA
(Foreign-ID/Locator
Mapping Agent)
(2) Locator Request
(with Corresponding ID)
(7) Response
C-ILMA
(CorrespondingID/Locator
Mapping Agent)
(8) Locator Reply
(with Corresponding
Locator)
Remote
Locator
Local
Locator
Gateway
IPv6 Network
Corresponding
Router
CN
(9) Mapping table
update
(1) Compressed Locator
Request (Target
Corresponding ID)
(10) Compressed Locator Reply
(with Corresponding
16-bit ID)
Device 16-bit short ID
based communication
Locator-based Communication (IPv6)
ID-based
communication
35
Locator Discovery – New CLREQ & CLREP Messages Format
IEEE 802.15.4 Frame Format
FCF
DSN
Dst EUID 64
Len
Preamble
SFD
Dst pan
Src pan
Dst16
Src EUID 64
MESH : Mesh Header
Dispatch (DSP) : Locator Discovery
HC1 : Sour. & Dest: Link Local, Next header=Locator Discovery
IP : Hop Limit
LD : Locator Discovery Dispatch
CLREQ: Sequence Number, Lifetime, Target Corresponding
Device ID
CLREP: Sequence Number, Lifetime, Corresponding 16-bit ID
Network Header & Application Data
Src16
Fchk
Max 127 bytes
M
E
S
H
• Proposed LOWPAN_LD
Dispatch Header Pattern (1 byte)
0
1
2
3
4
5
6
7
0
1
0
0
0
1
0
0
D H
S C
P 1
CLREQ
I
P
CLREP
or
• Proposed Compressed IPv6
Header (HC1 header : 1byte)
0
1
2
3
4
• Source prefix compressed
• Source interface identifier compressed
• Destination prefix compressed
• Destination interface identified compressed
• Traffic and Flow Label zero
• Next Header
00:Mobility Header, 01:Locator Discovery, 10, 11:reserved
5
6
• Compressed Locator Request (CLREQ) message
7
Sequence # Lifetime
1byte
Target Corresponding ID
16 bytes
1byte
• Compressed Locator Reply (CLREP) message
Sequence # Lifetime
1byte
1byte
Corresponding 16-bit ID
2bytes
• Additional HC2 compression header follows
36
Communication Procedure after Location Discovery
Corresponding
Node
6LoWPAN
Node
Src:
Local ID
Dst:
C ID
Corresponding Router
(Remote Locator)
6LoWPAN Gateway
(Local Locator)
TCP / UDP
Network Layer (IPv6)
Network Layer
(IPv6)
Src:
Local ID
Adaptation Layer
Adaptation Layer
Mapping table
LID : 16-bit ID
CID : 16-bit ID
Mapping table
LID : 16-bit ID
CID : 16-bit ID
IEEE 802.15.4
MAC / PHY
IEEE 802.15.4
MAC / PHY
Src: 16-bit
Local ID
Dst: 16-bit
C ID
Routed by
16-bit ID
Ethernet or other
MAC / PHY
Src:
Local ID
Dst:
C ID
Src:
Local ID
Dst:
C ID
Network Layer (IPv6)
Mapping table
LID : LLOC
CID : RLOC
Dst:
C ID
TCP / UDP
Mapping table
LID : LLOC
CID : RLOC
Ethernet or other
MAC / PHY
Ethernet or other
MAC / PHY
Ethernet or other
MAC / PHY
Src:
Dst:
Local Locator Remote Locator
Routed by
Locator
Network Layer
(IPv6)
Src:
Local ID
Dst:
C ID
Routed by
Device ID
37
Signaling & Data Flow
MN
GW
F-ILMA
H-ILMA
DINS
CR
CN
Beacon (PAN ID)
RS
RA
IDU
Location Update
Query
Response
Home Registration
Home Registration Ack
Location Ack
IDA
[s:CN-d:MN]
ID
[s:CR-d:GW][s:CN-d:MN]
Locator : ID
[s:CN-d:MN]
ID
38
Example of Application – healthcare scenario
DINS Mapping Table
Device Name
Device ID
Device’s ILMA
Mobile Sensor Node A
Mobile Sensor Node B
Mobile Sensor Node C
Mobile Router A
0001
0002
0003
0004
ILMA-A
ILMA-A
ILMA-A
ILMA-A
Device ID Naming
Server (DINS)
ILMA-B Mapping Table
Query
Response
ILMA-A Mapping Table
Device ID
ID/Locator Mapping
Agent (ILMA-A)
Device locator
0001
0002
0003
0004
Location
Location
Location
Location
A
B
A
C
D
F
C
E
Device ID
Device locator
0003
0004
0004
ID/Locator Mapping
Agent (ILMA-B)
Home
HomeRegistration
RegistrationAck
Location F
E
Location E
Location
Update
Ack
Location
Update
Ack
6LoWPAN
Node (FFD)
6LoWPAN
Gateway
Location A(2F)
IDU
IDA
RA
RS
Location
Update
Ack
6LoWPAN
Mobile Sensor
Node C
Location
Update
Ack
RA
RS
Location F (1F)
6LoWPAN
Mobile Sensor
Node A
Location C (Hospital A)
6LoWPAN
Mobile Sensor
Node B
6LoWPAN
Mobile Sensor
Node A
IDU
IDA
RA
RS
Proxy
IDA
IDU
6LoWPAN
Mobile Sensor
Node B
Intra-PAN
Mobility
Inter-PAN
Mobility
Network Mobility
(Inter-domain)
Inter-PAN
Mobility
Mobile
Router
Location E (Hospital B)
RA IDA
RS
MR
IDU
IDU
IDA
RA
RS
Location B (1F)
Inter-PAN
Mobility
6LoWPAN
Mobile
Sensor
6LoWPAN
Mobile Sensor Node C
Node C
Location D (Ambulance)
6LoWPAN
Mobile Sensor
Node C
39
Example of Application – logistics scenario
DINS Mapping Table
Device Name
Device ID
Device’s ILMA
Mobile Sensor Node A
Mobile Sensor Node B
Mobile Router A
0001
0002
0003
ILMA-A
ILMA-A
ILMA-A
Device ID Naming
Server (DINS)
ILMA-B Mapping Table
Query
Response
ILMA-A Mapping Table
Device ID
Device locator
0001
0002
0003
Location B
A
Location F
C
D
Location E
C
ID/Locator Mapping
Agent (ILMA-A)
ID/Locator Mapping
Agent (ILMA-B)
Home Registration Ack
Warehouse A
6LoWPAN
Gateway
Location
Update
Ack
6LoWPAN
Mobile Sensor
Node A
0003
0002
Location E
Location F
Location
Update
Ack
6LoWPAN
Gateway
Location
Update
Ack
6LoWPAN
Mobile Sensor
Node A
6LoWPAN
IDA
RA
RS
Mobile SensorIDU
Node A
Device locator
Location
Update
Ack
6LoWPAN
Gateway
RA
RS
Device ID
Warehouse C
RA
RS
IDU
IDA
6LoWPAN
Mobile Sensor
Node B
6LoWPAN
RS
MR IDU
IDA Mobile Sensor
RA
Node B
Inter-PAN
Location A
Location B
Warehouse B
Intra-PAN
Network
Inter-PAN
Mobility
Mobility
Mobility
Inter-PAN
6LoWPAN
Mobility
Mobile Sensor
Node B
6LoWPAN
Mobile Sensor
Node B
Location C (Warehouse C)
Location E (Warehouse
C)
Mobility
Location F (In
(1F)Warehouse C)
Mobile
Router
6LoWPAN
Gateway
6LoWPAN
Gateway
RS
IDU
RA
IDA
Location D (Truck)
40
Example of Application – healthcare scenario
DINS Mapping Table
Device Name
Device ID
Device’s ILMA
Mobile Sensor Node A
Mobile Router A
Mobile Router B
Mobile Router C
0001
0002
0003
0004
ILMA-A
ILMA-A
ILMA-A
ILMA-B
ILMA-A Mapping Table
Device ID
Device locator
0001
0002
0003
Location D
A
B
Location C
A
Location C
Device ID Naming
Server (DINS)
ID/Locator Mapping
Agent (ILMA-A)
Mobile Sensor
Node A
Network Mobility
(Inter-domain)
Location A(Home)
Proxy IDA
IDU
Heart Rate
101 / 60 sec
Blood Pressure
120 / 80 mmHg
ILMA-B Mapping Table
ID/Locator Mapping
Agent (ILMA-B)
Location
Update
Ack
Location
6LoWPAN Update
Ack
Main Server Bio Info Table
Main Server
6LoWPAN
Mobile Sensor
Node A
Device ID
Device locator
0004
Location H
Mobile
Router B
Location D(Airplane)
RA
RS
IDA
IDU
Mobile
Router A
Location B(Car)
IDA
IDU
RA
RS
Inter-PAN
Mobility
6LoWPAN
Mobile Sensor
Node A
Proxy IDA
IDU
MRIDU
RA
RS
MRIDA
6LoWPAN
Mobile Sensor
Node A
Location C(Airport)
41
Example of Application
DINS Mapping Table
Device Name
Device ID
Device’s ILMA
Mobile Sensor Node A
Mobile Router A
Mobile Router B
Mobile Router C
0001
0002
0003
0004
ILMA-A
ILMA-A
ILMA-A
ILMA-B
Device ID Naming
Server (DINS)
Main Server Bio Info Table
Main Server
Heart Rate
101 / 60 sec
Blood Pressure
120 / 80 mmHg
Query
Response
ILMA-A Mapping Table
Device ID
Device locator
0001
0002
0003
Location D
Location C
Location C
E
ID/Locator Mapping
Agent (ILMA-A)
ILMA-B Mapping Table
ID/Locator Mapping
Agent (ILMA-B)
Device ID
Device locator
0004
Location H
Location E
0003
Home
Registration
Ack
Home
Registration
Location
Update
Ack
Network Mobility
(Inter-domain)
KOREA
RS IDU
RA
MR
IDA
Location C(In-chon Airport)
Chile
Location E(Chile Airport)
42
Example of Application – healthcare scenario
DINS Mapping Table
Device Name
Device ID
Device’s ILMA
Mobile Sensor Node A
Mobile Router A
Mobile Router B
Mobile Router C
0001
0002
0003
0004
ILMA-A
ILMA-A
ILMA-A
ILMA-B
Device ID Naming
Server (DINS)
Main Server
Main Server Bio Info Table
Heart Rate
101
21 / 60 sec
Blood Pressure
120 / 95
160
80 mmHg
EMERGENCY
ILMA-A Mapping Table
Device ID
Device locator
0001
0002
0003
Location F
Location C
Location E
ID/Locator Mapping
Agent (ILMA-A)
ID/Locator Mapping
Agent (ILMA-B)
Location
Update
Ack
Bio Data
Inter-PAN
Mobility
Inter-PAN
Mobility
ILMA-B Mapping Table
Device ID
Device locator
0001
0004
0003
Location
Location F
G
I
Location F
H
Location E
Location Emergency Call
Ack
Update
Location
Ack
Inter-PAN Update
Mobility
Inter-PAN
MR
IDU
Mobility
MR
RS IDA
RA
Data Reply
Request
Mobile RS
IDU
IDA
RA
Router C
BioIDU
Data
Proxy
IDU
IDA
RA
RSIDA
Mobile
Router C
RS
IDU
IDA
RA
6LoWPAN
Mobile Sensor
Node A
Location I(3F)
Location G(Ambulance)
Location G(Ambulance)
Location H(Hospital)
Location F
43
Conclusion
ID/Locator separation architecture can be instrumental
for future Internet to efficiently support mobility,
multi-homing, scalable routing.
We proposed a new ID/Locator separation architecture
for supporting the lightweight mobility to both sensor
node mobility & network mobility.
 It is applicable in a sensor network mobility where many sensor
nodes support only lightweight communication.
The proposed scheme supports data/signaling split,
energy-efficient mobility, and packet route
optimization.
Also, the proposed approach supports minimum
signaling within the PAN, and multi-hop communication
between 6LoWPAN node and gateway.
44
MobilityFirst: A Robust and
Trustworthy Mobility-Centric
Architecture for the Future Internet
Introduction: NSF Future Internet Architecture (FIA) Program

FIA program started in Oct 2010 ( in 2014, again), with 4 teams
funded:
 XIA (led by CMU) – project aims to develop very flexible
architecture which can evolve to meet new requirements
 NEBULA (led by UPenn) – project aims to design fast/managed
flows to cloud services at the core of the Internet
 NDN (led by UCLA/PARC) – project aims to re-design Internet to
handle named content efficiently
 MobilityFirst (led by Rutgers) – project aims to develop
efficient and scalable architecture for emerging mobility
services

Scope of all these FIA projects includes architecture/design,
protocol validation and comprehensive evaluation of usability and
performance (using real-world applications in later stages)
45
MobilityFirst Project: Collaborating Institutions
(LEAD)
D. Raychaudhuri, M. Gruteser, W.
Trappe, R, Martin, Y. Zhang, I. Seskar,
A. Venkataramani, J. Kurose,
K. Nagaraja
B. D. Towsley
S. Bannerjee
X. Yang, R. RoyChowdhury
W. Lehr
M. Reiter
Z. Morley Mao
B. Ramamurthy
G. Chen
Project Funded by the US National Science Foundation (NSF)
Under the Future Internet Architecture (FIA) Program, CISE
+ Also industrial R&D
collaborations with AT&T Labs,
Bell Labs, NTT DoCoMo,
Toyota ITC, NEC,
Ericsson and others
46
Introduction: Mobility as the key driver for the future Internet
47
Introduction: Why Are Mobile Networks Different?
– BW Variation & Disconnection
The wireless medium has inherent fluctuations in bit-rate
(by as much as 10:1 in 3G/4G access, heterogeneity and
disconnection  fundamental protocol design challenge
Motivates in-network storage and hop-by-hop transport
(solutions such as CNF, DTN, ..)
Mobile devices with varying BW due to SNR variation,
Shared media access and heterogeneous technologies
Bit
Rate
(Mbps)
BS-1
Wireless
Access Net #
3
Disconnection
internal
INTERNET
Wireless
Access
Network
#2
Disconnect
AP-2
BS-1
Time
AP-2
48
Introduction: Why Are Mobile Networks Different? –
Multihoming, Multipath
Wired Internet devices typically have a single Ethernet interface
associated with a static network/AS
In contrast, mobile devices typically have ~2-3 radios and can see ~5-10
distinct networks/AS’s at any given location
Basic property - multiple paths to a single destination  leads to
fundamentally different routing, both intra and inter domain!
Mobile device with multi-path reachability
Single “virtual link” in wired Internet
BS-1
Wireless
Access Net
#1
Wireless
INTERNET
BS-2
Access
Wireless
Network
Access Net #
3
Access
Network
(Eithernet)
INTERNET
Ethernet
NiC
BS-3
Wireless
Edge
Network
Multiple
Potential
Paths
AP1
Dual
Radio
NIC’s
49
Introduction: Why Are Mobile Networks Different? – Multicast
Many mobility services (content, context) involve multicast
The wireless medium is inherently multicast, making it possible to
reach multiple end-user devices with a single transmission
Fine-grain packet level multicast desirable at network routers
Packet-level Multicast at Routers/AP’s/BSs
Session level Multicast Overlay (e.g. PIM-SIM)
Pkt Mcast at Routers
INTERNET
RP
Access
Network
(Eithernet)
Wireless
Access Net #
11
INTERNET
Wireless
Access N
et #32
Radio
Broadcast
Medium
50
Introduction: Why Are Mobile Networks Different? – Ad Hoc
& Network Mobility
Wireless devices can form ad hoc networks with or without
connectivity to the core Internet
These ad hoc networks may also be mobile and may be
capable of peering
Requires rethinking of interdomain routing, trust model, etc.
Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility
Access
Network
Access
Network
)
INTERNET
)
51
Introduction: Why Are Mobile Networks Different? – Content
& Context
Content and context aware message delivery often
associated with mobile services
 “Anycast” content retrieval from nearest storage location (cache)
 Context based message delivery specific by group, area, time, etc.
 Service typically involves dynamic binding of content or context to a
specific set of network addresses along with multicast delivery
Context = geo-coordinates & first_responder
Send (context, data)
Context
Naming
Service
Context
GUID
Global Name
Resolution service
ba123
341x
NA1:P7, NA1:P9, NA2,P21, ..
Context-based
Multicast delivery
Mobile
Device
trajectory
52
MobilityFirst Design: Architecture Feature
Named devices, content,
and context
Human-readable
name
Strong authentication, privacy
11001101011100100…0011
Public Key Based
Global Identifier (GUID)
Heterogeneous
Wireless Access
Service API with
unicast, multi-homing,
mcast, anycast, content
query, etc.
Routers with Integrated
Storage & Computing
End-Point mobility
with multi-homing
In-network
content cache
Storage-aware
Intra-domain
routing
Edge-aware
Inter-domain
routing
Hop-by-hop
file transport
Connectionless Packet Switched Network
with hybrid name/address routing
Network Mobility &
Disconnected Mode
Ad-hoc p2p
mode
53
MobilityFirst Design: Name-Address Separation
Separation of names (ID) from
network addresses (NA)
Sue’s_mobile_2
Globally unique name (GUID)
for network attached objects
Server_1234
Media File_ABC Taxis in NB
John’s _laptop_1
 User name, device ID, content,
context, AS name, and so on
 Multiple domain-specific naming
services
Host
Naming
Service
Global Name Resolution Service
for GUID  NA mappings
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
Network
Hybrid GUID/NA approach
 Both name/address headers in PDU
 “Fast path” when NA is available
 GUID resolution, late binding option
Network address
Net1.local_ID
Net2.local_ID
54
MobilityFirst Design: Protocol Example –
Name Resolution at Device End-Points
Service API capabilities:
- send (GUID, options, data)
Options = anycast, mcast, time, ..
- get (content_GUID, options)
Options = nearest, all, ..
Register “John Smith22’s devices” with NCS
Name Certification
Services (NCS)
GUID assigned
GUID lookup
from directory
NA99
MobilityFirst Network
(Data Plane)
Send (GUID = 11011..011, SID=01, data)
GUID <-> NA lookup
GNRS query
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
GNRS update
(after link-layer association)
NA32
GNRS
GUID = 11011..011
Represents network
object with 2 devices
DATA
GUID SID
NAs
Packet sent out by host
55
MobilityFirst Design: Protocol Example - Dual
Homing Service
Multihoming service example
DATA
DATA
Router bifurcates PDU to NA99 & NA32
(no GUID resolution needed)
GUID
NetAddr= NA99
NA99
Data Plane
NA32
DATA
DATA
GUID
NetAddr= NA32
GUID= SID
11001…11 NA99,NA32
DATA
GUID SID
Send data file to “John Smith22’s
laptop”, SID= 129 (multihoming
– all interfaces)
56
MobilityFirst Design: Protocol Example - Han
dling Disconnection
Store-and-forward mobility service example
DATA
GUID
NA99  rebind to NA75
Delivery failure at NA99 due to device mobility
Router stores & periodically checks GNRS binding
Deliver to new network NA75 when GNRS updates
NA99
Disconnection
interval
Data Plane
Device
mobility
NA75
DATA
DATA
GUID
NA75
GUID SID
NA99
DATA
GUID SID
Send data file to “John Smith22’s
laptop”, SID= 11 (unicast, mobile
delivery)
57
MobilityFirst Design: Protocol Example –
Enhanced CDN Service
Enhanced service example – content delivery with in-network storage
MF Compute Layer
with Content Cache
Service plug-in
GUID=13247..99
NA31
NA43
GUID=13247..99
Filter on
SID=128
Content cache at mobile
Operator’s network – NA99
GUID=13247..99
NA99
GNRS query
Returns list:
NA99,31,22,43
NA29
NA22
GNRS
Query
GUID=13247..99
Content Owner’s
Server
Data fetch from
NA43
Get (content_GUID)
Data fetch from
NA99
Content file
Mobile’s GUID
Get (content_GUID,
SID=128 - cache service)
Query
User mobility
GUID=13247..99 SID=128 (enhanced service)
58
MobilityFirst Prototyping: Click-based Router Implementation
Early Dev.
Inter-Domain
User-level
Processes
R3
Locality-Aware
DNS
GSTAR
DMap – DiHT
Routing
Name
Resolution
PacketCloud
Framework
Compute
Services
Host Rx Q
Click
Packet
Block
Classifier
Aggregator
Rx Q
Service
Classifier
Mgmt.
Host Tx Q
To/From Host
Forwarding Engine
Content
Cache Service
Forwarding
Table
To Nexthop Lookup
Rsrc
Control
Block
Segmentor
Tx Q
Next-hop
Look up
Wired and wireless i/f
Wired and wireless i/f
Integrate
Hold buffer
x86 hardware and runtime
59
MobilityFirst Prototyping: Host Protocol Stack
‘Socket’ API
open
send
send_to
recv
recv_from
close
App-1
App-2
Linux PC/laptop with WiMAX & WiFi
App-3
Context API
Network API
Context
Services
E2E Transport
GUID Services
Network Layer
Security
Sensors
Android device with WiMAX & WiFi
Routing
User policies
Interface Manager
‘Hop’ Link Transport
Early Dev.
WiFi
Integrate
WiMAX
Device: HTC Evo 4G, Android v2.3 (rooted), NDK (C++
dev)
60
MobilityFirst Prototyping: GENI Deployment
Legend
Internet 2
National Lambda Rail
OpenFlow Backbones
OpenFlow
WiMAX
ShadowNet
MobilityFirst Router &
GNRS Servers
Mobile Hosts
Static Hosts
Deployment Goals
Mapping onto GENI Infrastructure
• Large scale, multi-site
• Mobility centric
• Realistic, live
(ProtoGENI nodes, OpenFlow switches
, GENI Racks, DieselNET buses, WiMAX
/outdoor ORBIT nodes)
61
MobilityFirst Prototyping: Hot Mobile 2012
Delivery Services for Multi-Homed Devices with User preference of delivery interface
62
MobilityFirst Prototyping: GEC-13 Demo
(Mobility, Multi-homing)
Mobile, Multi-homed device (WiMAX + WiFi)
pg33@GeorgiaTech
pg50@Rutgers
pc1@BBN
WiFi AP
pg51@Rutgers
pc11@BBN
WiMAX BTS
GENI Mesoscale
MobilityFirst Router
hosted on Protogeni
node
Rutgers Wireless Edge
WiFi coverage
WiMAX coverage
63
References

GNAB presentation by CS Hong

Jinho Kim, Jun Lee, Hyoeng Kyu Kang, Dae Sun Kim,
Choong Seon Hong, Sungwon Lee, "An ID/Locator
Separation-based Mobility Management Architecture
for WSNs," IEEE Transactions on Mobile Computing (IEEE
TMC), Vol.13, No.10, pp.2240-2254, October 2014

Jinho Kim, Rim Haw, Eung Jun Cho, Choong Seon Hong,
Sungwon Lee, "A 6LoWPAN Sensor Node Mobility
Scheme Based on Proxy Mobile IPv6," IEEE Transactions
on Mobile Computing, VOL. 11, NO. 12, pp. 2060-2072,
December 2012

Project website: http://mobilityfirst.winlab.rutgers.edu
64
Thank you !
Q&A