Transcript Slides II - NSF Future Internet Architecture Project

MobilityFirst Project Update
FIA PI Meeting, March 18-19, 2013
Part-II – Protocol Details, Use
Cases & Prototyping
D. Raychaudhuri & Arun Venkataramani
WINLAB, Rutgers University CS Dept, Umass - Amherst
[email protected]
[email protected]
MobilityFirst Protocol
MobilityFirst Protocol: Feature Summary
Named devices, content,
and context
Strong authentication, privacy
11001101011100100…0011
Public Key Based
Global Identifier (GUID)
Human-readable
name
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
MobilityFirst Protocol Design Goals:
-
10B+ mobile/wireless devices
Mobility as a basic service
BW variation & disconnection tolerance
Ad-hoc edge networks & network mobility
Multihoming, multipath, multicast
Content & context-aware services
Strong security/trust and privacy model
Connectionless Packet Switched Network
with hybrid name/address routing
Network Mobility &
Disconnected Mode
Ad-hoc p2p
mode
WINLAB
MobilityFirst Protocol: Technology Solution
Name Certification
Service (NCS)
Flexible name-based network service layer
Global Name
Resolution Service
(GNRS)
Hybrid GUID/NA
Global Routing
(Edge-aware, mobile,
Late binding, etc.)
Name-Based
Services
(mobility, mcast,
content, context,
M2M)
Storage-Aware
& DTN Routing
(GSTAR)
in Edge Networks
Optional
Compute Layer
Plug-Ins
Meta-level
Network Services
(cache, privacy, etc.)
Hop-by-Hop
Transport
(w/bypass option)
Core Transport
Services
Pure connectionless packet switching with in-network storage
WINLAB
MobilityFirst Protocol: The Protocol Stack
App 1
App 2
App 3
App 4
E2E TP3
E2E TP4
Socket API
Name
Certification
& Assignment
Service
NCS
E2E TP1
E2E TP2
Optional Compute
Layer
Plug-In A
Global Name
Resolution
Service
GNRS
MF Routing
Control Protocol
GUID Service Layer
GSTAR Routing
MF Inter-Domain
Hop-by-Hop Block Transfer
Link Layer 1
(802.11)
Link Layer 2
(LTE)
Narrow Waist
Link Layer 3
(Ethernet)
IP
Switching
Option
Link Layer 4
(SONET)
Link Layer 5
(etc.)
Control Plane
Data Plane
WINLAB
MF Protocol: Name-Address
Separation  GUIDs

Separation of names (ID) from
network addresses (NA)
Globally unique name (GUID)
for network attached objects
Sue’s_mobile_2





User name, device ID, content, context,
AS name, and so on
Multiple domain-specific naming
services
Server_1234
John’s _laptop_1
Host
Naming
Service
Media File_ABC
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
for GUID  NA mappings
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
Net2.local_ID
Network address
Net1.local_ID
Taxis in NB
WINLAB
MF Protocol: Hybrid GUID/NA Storage
Router in MobilityFirst

Hybrid name-address based routing in MobilityFirst requires a new
router design with in-network storage and two lookup tables:



“Virtual DHT” table for GUID-to-NA lookup as needed
Conventional NA-to-port # forwarding table for “fast path”
Also, enhanced routing algorithm for store/forward decisions
GUID –based forwarding
(slow path)
GUID-Address Mapping – virtual DHT table
Look up GUID-NA table when:
- no NAs in pkt header
- encapsulated GUID
- delivery failure or expired NA entry
GUID
NA
11001..11
NA99,32
DATA
To NA11
Router
Storage
DATA
SID
GUID=
11001…11
NA99,NA32
To NA51
Store when:
- Poor short-term path quality
- Delivery failure, no NA entry
- GNRS query failure
- etc.
NA Forwarding Table – stored physically at router
Dest NA
Look up NA-next hop table when:
- pkt header includes NAs
- valid NA to next hop entry
Port #, Next Hop
NA99
Port 5, NA11
NA62
Port 5, NA11
Port 7, NA51
NA32
DATA
Network Address Based Forwarding
(fast path)
WINLAB
MF Protocol: Service Abstractions (1)



MobilityFirst offers a named-object service API that supports
mobility, disconnection, multi-homing, multicast in a natural way
Replaces the point-to-point virtual link abstraction of IP …
Example: Sending to a mobile device with multiple interfaces
IP Abstraction: Virtual Link
MF Abstraction: Multi-homed Network Object
Send(IP=X, data)
Send(GUID=Y, data, options)
..options for multi-homing & late binding
NA=X1
Network
IP Addr=X
Interface
Dest
Device
Name=
MAC
Static
MAC=X
binding
Dynamic
GUID – NA
bindings
NA=X2
GUID=Y
NA=X3
Network
Attached
Object
e.g., Y may be a mobile device with 3 interfaces (WiFi & 2 cellular)
WINLAB
MF Protocol: Service Abstractions (2)

Use of MF Service API for content retrieval and dynamic group
multicast (..membership may be specified by context)
MF Abstraction: Get Replicated Content Object
MF Abstraction: Send to Group Object with
Multicast reachability
Get (Content_GUID=A, options)
..option for shortest path
NA=X1
NA=X2
Send (GUID=Z, data, options)
..option for mcast delivery
NA=X3
NA=X2
Broadcast Medium
Content Object
With GUID=A
GUID=A
GUID=A
e.g., A is a replicated content object at multiple network locations
Group
GUID = Z
GUID1
GUID2
GUID3
e.g., Z may be a context group of M2M devices or a cloud service
WINLAB
MobilityFirst Protocol Stack: GUID addressing

GUID-based addressing available at host, service/application,
socket, and file level


GUIDs can also address groups of entities
Port-less addressing of application end-points

Each application end-point can have a separate GUID
 No port contention, and no assumed well-known ports for services

GUID aggregation and Service Directories
Applications may choose to use host-GUID with a demux – appID
 Demux identifiers advertised at local directory services

Port-less, 1 GUID per endpoint
APP-1
APP-2
GUID Aggregation and Service Directory
APP-3
APP-1
APP-4
appID-1
Host
APP-2
APP-3
appID-2
APP-4
appID-3
appID-4
Transport Layer Directory Service
Host
GUID-1
GUID-2
GUID-3
GUID-4
GUID-0
GUID-0
WINLAB
MobilityFirst Protocol Stack: Service API


MobilityFirst API (or “socket” interface) provides a new set of
services corresponding to the MF protocol stack’s
capabilities
Key features are:





GUID as the unique identifier right up to application level (no need for port #)
Service identifier choice including: basic unicast/mcast, anycast, dual-homing,
late binding mobile delivery, delayed delivery, content query, context delivery,
plug-in computing service, etc. (others TBD)
Unicast vs multicast determined
Lightweight transport protocol choices for end-to-end reliability and flow control
Socket interface examples:








Open(URL, myGUID, TP=A, TP_options) - identity specification and stack
customization
Send(GUID=X, SvcFlags/SID=anycast, data, len)
Send(GUID=X, SvcFlags/SID=unicast, TP=B, data, len)
Send(GUID=X, SvcFlags/SID=late binding, options, data)
Send(GUID=X, SvcFlags/SID=anycast+, data)
Recv(data_buffer, len, GUID_allow={X, Y, X})
Get(GUID=X, SvcFlags/SID=anycast+content query, options, data_buffer, len)
….
WINLAB
MobilityFirst Protocol Stack: Network Service
API

open (profile-URL, src-GUID, [profile-options])
A profile declares the customization of the stack such as choice of transport and
security features for the duration of a session. Profile option parameterize a
profile
 Optional source GUID identifies the initiating end-point and results in an update
of attachment point to the GNRS.


send (message, dst-GUID, [service-option])

GUID based endpoint addressing
 Options include: MULTICAST, ANYCAST, GET (content), CACHE (a directive to
allow content caching), MULTI-PATH, MULTI-HOME, DTN (delay-tolerant),
REALTIME (with delay constraints), COMPUTE (with GUID of compute service) …

recv (buffer, [GUID-set])

Intentional data receipt - GUID-set defined white list
 Synchronous and asynchronous implementations

get (content-GUID, buffer, [service-options])

Content-centric apps: native network support for direct (GUID-based) content
discovery and retrieval of content
 ANYCAST service: retrieval attempted from the closest among replicas listed in
GNRS
WINLAB
MobilityFirst Protocol Stack: Network Service
API (Contd.)

attach (GUID-set)
Publishes network reachability for the specified GUID(s)
 GUID services layer initiates an association request for each GUID
 Network cooperation (co-sign) to publish attachment point locator to GNRS
 Periodic association exchanged keeps locator bindings ‘fresh’ at GNRS


close ()

Terminates a session by clearing stack state and performing a clean
disassociation from network
 Locator bindings from GNRS can be removed or allowed to expire
WINLAB
Wireless/Mobile Use Case
Wireless/Mobile Use Case

MobilityFirst enables a stitched-together architecture for
mobile networks
Current Mobile Networks
•
•
•
•
•
•
AAA Server
GSM/CDMA/
LTE
Control Path Elements
Mobility Management
Entity (MME)
Data Path Elements
Make-before-break
Handover
Controlled QoS inside network
Wi-Fi
Internet
Gateway
Node
ISP 1
MF Network-of-Networks
Internet
GSM/CDMA/
LTE
ISP 2
Mobility Support
Through GNRS
Planned Deployment
Licensed Spectrum
Fine-grained Managed QoS
Centralized Mobility Support
Homogeneous Topology
Network-wide Authentication
Global Name
Resolution
Service
•
•
•
•
•
•
Ad-hoc Deployment
Unlicensed Spectrum
Coarse-grained Managed
In-network Mobility Support
Heterogeneous topology
Authentication at APs
ISP 3
Wireless Cooperation
through Geographic Routing
WINLAB
Wireless/Mobile Use Case:
Service Capability Examples

MF provides several useful capabilities for mobile networks,
e.g. mobility, multi-homing, multi-network access, late binding,
BS1
multicast, ..
Wireless
Access Net
#3
INTERNET
Wireless
Access
Network
#2
BS2
User/Device
Mobility
(1) Mobile Device with Seamless Service
BS-1
Wireless
Access Net
#1
LTE BS
Wireless
Access Net
#3
BS-2
Wireless
Access
Network
Wireless
Access Net
#3
BS-3
INTERNET
Wireless
Access
Network
#2
Wireless
INTERNETEdge
WiFi
AP
Network
AP1
Mobile device
With dual-radio NICs
(2) Mobile device with dual-homing
(3) Mobile device with Multi-network access
WINLAB
Multiple
Potential
Paths
Protocol Example: Mobility Service via
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)
GNRS update
(after link-layer association)
NA32
GNRS
GUID <-> NA lookup
GNRS query
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
GUID = 11011..011
Represents network
object with 2 devices
DATA
GUID
SID
NAs
Packet sent out by host
WINLAB
Protocol Example: Dual Homing Service via
Named-Object / GNRS
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
SID
GUID=
11001…11
NA99,NA32
DATA
GUID SID
Send data file to “John Smith22’s
laptop”, SID= 129 (multihoming –
all interfaces)
WINLAB
Protocol Example: Handling Disconnection
via Late Binding
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)
WINLAB
Sample Results: MF vs TCP/IP for WiFi
Roaming
Quantifying the benefits of in-network mobility management &
storage aware routing
• NS3 Simulation with full 802.11 stack,
different vehicular speeds & offered load
• Comparing TCP/IP with MF
Transmission of stored packets  Throughput Jumps
Total Data Received (MBytes)

Speed = 30 miles/hr
Speed = 50 miles/hr
100
Speed = 70 miles/hr
100
100
80
80
80
60
60
60
40
40
40
20
20
20
0
0
50
100
150
Time (sec)
200
0
0
50
100
150
Time (sec)
200
0
MobilityFirst
TCP/IP
0
50
100
WINLAB
Time (sec)
150
200
Sample Results: MF vs. TCP/IP for
LTE/WiFi Switching
MF provides several benefits in a heterogeneous wireless
environment:

Mobility Mgmt. is not specific to each network
 Automatic storage of packets in transition
 Simultaneous use of multiple networks
Aggregate Throughput with Time
1000
900
Aggregate Throughput (MBytes)

Throughput boost
due to transmission
of stored packets
800
TCP takes more time to
re-start session (DHCP +
Application reset)
700
600
500
400
300
200
MobilityFirst
TCP/IP
100
0
0
20
40
60
Time (sec)
80
100
120
WINLAB
Content & Context/M2M
Use Cases
[22]
Content Delivery Use Case:
Content Retrieval via GUID Name


Network support for content addressability and caching 
service primitives such as get(content-ID, ..)
Optional computing layer plug-in for enhanced services
GUID=12379…78
Content Cache
In-network cache
NA94
In-network
cache
GUID=12379…78
NA22
Content Owner’s
Server
Send(“content_GUID”, dest_GUID)
Alternative paths
for retrieval
or delivery
Content Cache
GUID=12379…78
Get (“content_GUID”)
GNRS query with CGUID returns NA94, NA22
WINLAB
Content Delivery Use Case: Enhanced CDN
Service
Enhanced service example – content delivery with in-network caching & transcoding
MF Compute Layer
with Content Cache
Service plug-in
GUID=13247..99
Content cache at mobile
Operator’s network – NA99
NA43
NA31
GUID=13247..99
Filter on
SID=128
GUID=13247..99
NA99
GNRS query
Returns list:
NA99,31,22,43
NA29
GNRS
Query
GUID=13247..99
Content file
NA22
Content Owner’s
Server
Data fetch from
NA99
Mobile’s GUID
Data fetch from
NA43
Get (content_GUID,
SID=128 - cache service)
Get (content_GUID)
Query
User mobility
GUID=13247..99 SID=128 (enhanced service)
WINLAB
M2M Use Case:
Supporting Context-Aware Services

Context-aware delivery often associated with M2M services
Examples of context are group membership, location, network state, …
 Requires framework for defining and addressing context (e.g. “taxis in New
Brunswick”)
 Anycast and multicast services for message delivery to dynamic group

Context = geo-coordinates & taxi group
Send (context, data)
Context
Naming
Service
Context
GUID
Global Name
Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory
WINLAB
M2M Use Case: Protocol Example



M2M: S1 data is picked up by Mobile GW and sent to MF for A1 that subscribes it
Context: T1, conf@WINLAB, is subscribed by P1 …P4;A2 sends a file to T1 reaches P1..P4
via MF
M2M/Context server updates MF-GNRS for mappings: S1 A1 and T1  P1…P4
Context T1
Conf @WINLAB
Subscriber P1
Lookup S2, T1 &
Subscribe T1
P2
P3
Lookup S1, C1, subscribe S1
M2M / Context (Naming)
Server, GUID
Assign & Publish
(S1, S2, C1, T1)
Application A2
Lookup Context T1
Lookup S1
NA2
P4
Presentation
DATA
NA3
DATA
Sensor S2
(location)
UPDATE
Sensor S1
(temperature)
Actuator C1
(air conditioning)
March 11, 2013
Application A1
Internet
(MobilityFirst)
NA4
UPDATE
M2M
GateWay
GNRS: Global Name
Resolution Service
NA1
GNRS
Entries:
S1 -> A1
C1 -> NA1
S2T1, T1P1..P4
P1 -> NA2, P2->NA2
P3 -> NA2, P4->NA3
MobilityFirst Review Meeting
SmartGrid App
A1 -> NA4
WINLAB
Mobility First Prototyping
& Deployment Status
[27]
MF Software Router and Host Protocol Stack
Click-based MF Router
Android/Linux MF Protocol Stack
Storage-aware routing (GSTAR)
- Name resolution server (GNRS)
- Reliable hop-by-hop link transport (Hop)
- Network API
- Hop
- Dual homing (WiFi/WiMAX)
-
Native,
user-level
implementation
on Android
runtime
WiFi AP
MF Router
MF Router
28
MF Router
WiMAX BTS
WINLAB
MF Android Mobile Client
App 2
App 1
App ...
MF JAVA Client API
E2E Transport
Protocol A
E2E Transport
Protocol B

GUID Service Layer

Storage-Aware Routing (GSTAR)

Hop-by-Hop Block Transport Protocol
Link Layer A
(e.g. WIFI)
Link Layer B
(e.g. WIMAX)

JAVA (Android) and C
(Linux) API prototype
Usable with ARM based
Android devices
Multihoming capabilities for
WiMAX enabled devices
Distributed as a system
library and jar library for
easiness of deployment in
Android SDK based
applications
WINLAB
MF GNRS Implementation

Two alternate designs:

network-level one-hop map service; co-located with routing (Dmap)
 Locality-aware, cloud-hosted service (Auspice)

Three alternate evaluation platforms:
1. GENI Wide Area
Deployment
2. ORBIT lab with net.
emulation
3. Commercial cloud
platform
Network Emulation
WINLAB
MF Click Software Router
Lightweight, scalable multicast
• GNRS for maintenance of
multicast memberships
• Heuristic approaches to
reduce network load, limit
duplicated buffering, and
improve aggregate delivery
delays
• Click prototype, with SID for
multicast flows
• Evaluating hail a cab
application as a example
multipoint delivery scenario
31
Multicast
Inter-Domain
(EIR)
WINLAB
OpenFlow/SDN Implementation of MF
Protocol stack embedded within controller
Label switching, NA or GUID-based routing (incl. GNRS lookup)
Controllers interact with other controllers and network support
services such as GNRS
Flow rule is set up for the remaining packets in the chunk based on
Hop ID (which is inserted as a VLAN tag in all packets)
E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101
=> OUT PORT = 16




32
MF Protocol Stack
WINLAB
MF Prototype Deployment on GENI
(GEC-12 Recap)
Washington
Physical Topology
Wisconsin
BBN
NLR
Seattle
Indiana
MF Routers at 7 campuses across
US on ProtoGENI hosts
Layer2 links: Internet2 & NLR
backbones, OpenFlow switches
Edge networks: WiFi and WiMAX
access at BBN & Rutgers



NLR
Denver
NLR
SUNW
NLR
Chicago
I2
New York
Rutgers
Clemson
I2
Los Angeles
I2
Washington
Georgia Tech.
I2
Atlanta
Stanford
I2
Houston
I2 OF Switch
VLAN 3715
NLR OF Switch
VLAN 3716
Edge OF Switch
NA
DATA
DATA
Content
Subscriber
DATA
DATA
WiFi AP
Robust Content Delivery
•
•
•
Dual-homed mobile subscriber with WiFi + WiMAX
Adapt to disconnection and variable link quality (GSTAR)
Dual-homed delivery
WiFi AP
DATA
GUID & SID
DATA
DATA
Content
Publisher WiMAX BTS
BBN Wireless Edge
33
WiMAX BTS
ProtoGENI Backbone
Rutgers Wireless Edge
WINLAB
MF Multi-Site Deployment (GEC-16)
NL
R
Cambridge,
MA
Madison, WI Ann Arbor, MI
Lincoln, NE
Palo Alto, CA
N. Brunswick,
NJ
Salt Lake, UT
Tokyo, Japan
Los Angeles,
CA
I2
Atlanta, GA
MobilityFirst
Routing and Name
Resolution
Service Sites
MobilityFirst Access
Net
Clemson,
SC
Long-term (nonGENI)
Short-term
Wide Area ProtoGENI
ProtoGENI
WINLAB
MF/GENI Connectivity: VLAN Stitching
Salt Lake, UT
Cambridge,
MA
Madison, WI Ann Arbor, MI
VLAN
Lincoln, NE
VLAN Y
912
Palo Alto, CA
New Brunswick,
NJ
Tokyo, Japan
Los Angeles,
CA
Atlanta, GA
Wide Area ProtoGENI
nodes connect on VLAN
3716 at: Internet2 PoP
OR
NLR PoP
MobilityFirst
Routing and Name
Resolution
Service Sites
MobilityFirst Access
Net
Clemson,
SC
Long-term (nonGENI)
Short-term
Wide Area ProtoGENI
ProtoGENI
WINLAB
MF/GENI Setup: Emulated Topology
Cambridge,
MA
Madison, WI Ann Arbor, MI
Salt Lake, UT
Lincoln, NE
Palo Alto,
CA
New Brunswick,
NJ
Tokyo, Japan
Los Angeles,
CA
Clemson,
Atlanta, GA SC
MobilityFirst
Routing and Name
Resolution
Service Sites
MobilityFirst Access
Net
Long-term (nonGENI)
Short-term
Wide Area ProtoGENI
ProtoGENI
WINLAB