Upload
vudat
View
217
Download
0
Embed Size (px)
Citation preview
Next-Generation Mobile Networks and
Convergence with Future Internet
Architecture
Wireless Technology Summit
Tokyo, Japan
March 7, 2014
D. Raychaudhuri
WINLAB, Rutgers University
Introduction
WINLAB
Introduction: Wireless Mobile Technology
Trend Many core technologies under development, but network architecture is critically important!
5G Radio
Wideband Cognitive Radio
Programmable NetFPGA Router
Programmable OpenFlow SDN Switch
Multi-Radio Android Device
LTE Base Station LTE Small Cell
Next-Gen Network?
60 Ghz 802.11ad
“5G” Enabling Technologies
WINLAB
Introduction: Wireless/Mobile Technology
Trend (cont.)
Services
Network
Radio
2000 2010 2020
OFDM
MIMO
Network
MIMO CDMA
4G Standards 3G Standards
802.11a,g
802.11ac
Cloud RAN
Cognitive Software Defined Radio
Dynamic Spectrum Assignment
mm Wave
Cellular 60 Ghz
802.11ad
“5G” Standards
Network
coding
Femto-cell
WiMax LTE-A
3GPP standards
GGSN, SGSN
Direct IP Tunnel
Vertical
Handover
“Flat” IP Network Cellular-IP GW
Mobile IP
IP-based SAE/LTE spec
Host Identity
Protocol
Fast DNS
Software Defined Networks (SDN)
Information
Centric Network (ICN)
Mobility-Centric
Network Architecture
Next-Gen Internet+M Spec
SMS
Web Services
Location Services Mobile Cloud
Services
Content Delivery
Networks
Mobile Content
Virtual Network
Services
M2M
V2V Real-time
CPS
Video
Context-Aware Comm
Mpath TCP
HetNet
Small-Cell
Service Requirements
Radio Tech Requirements
Next-Gen Mobile Network
FIA
LTE
WINLAB
Introduction: Internet Trend – Exponential
Growth in Mobile Data Services…
Historic shift from PC’s to mobile computing and embedded devices… ~6 B mobile phones vs. ~1B PC’s in 2012
Mobile data growing exponentially – exceeds wired
network traffic in ~2013 (3.6 Exabytes/mo in 2014)
Sensor/IoT/V2V just starting, ~5-10B units by 2020
INTERNET Cellular
Edge
Network
INTERNET
~1B server/PC’s, ~700M smart phones
~2B servers/PC’s, ~10-20B smartphones, pads and sensors
~2010 ~2020
Wireless
Edge
Network
WINLAB
Introduction: Cellular-Internet Convergence
Radio Technology Trend
Internet Service Trend
Future “Mobile Internet”
New wireless/mobile
functions, enhanced
security, services
Higher speeds/scale,
“network of networks”
Wireless
Edge Network
Internet (IP
Network)
SGW
MME
Mobile Internet (Future IP)
No Gateways! Single Protocol (IP+)
Unified security & mobility services
5G more than just faster radio design of the network also critical to realizing service vision…
Converged Internet
Architecture truly responsive to
the needs of mobile devices
WINLAB
Introduction: Current Cellular Network
Architecture
High access network cost, gateway bottlenecks,
latency, protocol interworking complexity…
+
-
Fine-grained control over quality of service
WINLAB
Introduction: Current WLAN Network
Architecture
Low cost: Free spectrum, low cost infrastructure
Increased latency, redundancy in control functions
+
-
WINLAB
Introduction: Future Mobility-Centric
Internet Architecture
Interchangeable access tech, low latency,
improved scalability, advanced mobile services
… Needs a new global networking standard in long run
+
-
WINLAB
Operator Network
Running future IP
Protocols
Introduction: Next-Steps Towards Cellular-
Internet Convergence Truly flat “future IP” architecture under consideration
No gateways – mobility functionality distributed between routers/BSs/APs running
the same control and data protocols; standard mobility & service control API’s
Multiple radio access technologies simply plug-in to universal mobile Internet
Generalized view of mobility service requirements, not limited to simple device
mobility – e.g. multicast, content addressability, context delivery, …
Edge Networks with
Mobility Services
RAN A
RAN B
RAN A RAN
Net B
RAN C
Enhanced Packet Core
(Operator Network)
MME
SGW
Standard
IP Router
Future IP control plane
w/ mobility support
To/From Global
Internet
futureIP
Intra-Domain
Router
futureIP
Inter-Domain
Router
Next-Gen Wireless
Network Requirements
WINLAB
Next-Generation Wireless Network Requirements
Heterogeneous
Technologies
multi-
homing
100B+ Wireless
Devices
Wide-Area Internet
Access
Network
Seamless
Integration
Cloud
Services
Content
Services
Strong
Security/Privacy
Low end-to-end
latency
Local
cache/
cloud
Global
Mobility
High-
Speed
~Gbps
radio
Next-Gen wireless requirements driven by fast growth in cellular data + emerging scenarios
Key requirements:
- Scale/Capacity (100B+)
- Speed (Gbps+)
- Latency (<10ms)
- Integrated mobility
- Multipath, multicast,
multihoming ..
- Robustness/DTN
- Context-aware
- Energy aware
- ..others
Dynamic
spectrum
M2M
Vehicular
WINLAB
Next-Gen Network Requirements: (1) Mobility
End-point mobility as a basic service of the future Internet
Any network connected object or device should be reachable on an efficiently
routed path as it migrates from one network to another
Eliminate service gateways (bottleneck points), IP tunnels, etc. (“flat”)
Fast authentication, dynamic handoff (vertical), and global roaming
Mobility service should be scalable (billions of devices) and fast ~50-100 ms
Implications for core naming/routing/security architecture of Internet
INTERNET
AS99
(LTE)
AS2
User/Device
Mobility
AS49
AS39
(WiFi
)
Inter-AS Roaming
Agreement
“Mobile Peering”
Measured Inter-Network Mobility Traces
(Prof. J. Kurose, UMass, 2013)
WINLAB
Next-Gen Network Requirements :
(2) Handling Disconnection & BW Variation Wireless medium has inherent fluctuations in bit-rate (as much
as 10:1 in 4G access), heterogeneity and disconnection Poses a fundamental protocol design challenge
New requirements include in-network storage/delay tolerant delivery, dynamic rerouting (late binding), etc.
Transport layer implications end-to-end TCP vs. hop-by-hop
INTERNET
Wireless
Access Net #3
Wireless
Access
Network #2
BS-1
AP-2
Mobile devices with varying BW due to SNR variation,
Shared media access and heterogeneous technologies
Time Disconnection
interval
Bit
Rate
(Mbps)
Dis-
connect
AP-2
BS-1
WINLAB
Next-Gen Network Requirements:
(3) Multicast as a Basic Service 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
INTERNET
Session level Multicast Overlay (e.g. PIM-SIM)
Wireless
Access Net #11
INTERNET
Access
Network
(Eithernet)
Radio
Broadcast
Medium
Packet-level Multicast at Routers/AP’s/BSs
RP
Wireless
Access
Net #32
Pkt Mcast at Routers
WINLAB
Wireless
Access Net #3
Next-Gen Network Requirements :
(4) Multi-Homing as a Standard Feature Multiple/heterogeneous radio access technologies (e.g.
4G/5G and WiFi) increasingly the norm Improved service quality/capacity via opportunistic high BW access
Improved throughput in hetnet (WiFi/small cell + cellular) scenarios
Can also be used to realize ultra-high bit-rate services using multiple technologies, e.g. 60 Ghz supplement to LTE
Implications for naming and routing in the Internet
INTERNET
Wireless
Access Net #3
Wireless
Access
Network
#2
LTE BS
WiFi
AP
Multihomed devices may utilize two or more interfaces to improve communications
quality/cost, with policies such as “deliver on best interface” or “deliver only on WiFi”
or “deliver on all interfaces”
Mobile device
With dual-radio NICs
60 Ghz BS
(supplement to LTE)
WINLAB
Next-Gen Network Requirements: (5)Multi-
Network Access Multi-network access an advantage for wireless over wired!
A mobile device typically sees >10 networks, including at least 3-4 cellular WAN and 5-6 short-range WLAN
Multiple paths can be used to improve availability and sustained bit-rate
Motivates network layer features to support multi-path
INTERNET
Single “virtual link” in wired Internet Wireless
Access Net #1
(LTE1) Wireless
Access Network
Wireless
Access Net #3
(60 Ghz)
Wireless
Access
Network
(LTE2)
INTERNET
Access
Network
(Eithernet)
BS-1
BS-2
BS-3
BS4
Mobile device with multi-path reachability
Multi
Radio
NIC’s
Ethernet
NiC
Multiple
Potential
Paths
WINLAB
Next-Gen Network Requirements:
(6) Efficient Content Delivery
Content Owner’s
Server
In-network cache
Get (“content_ID”) Send(“content_ID”, “user_ID”))
In-network
cache
Alternative paths
for retrieval
or delivery
Delivery of content to/from mobile devices a key service requirement in future networks (…”ICN”, etc.)
This requirement currently served by overlay CDN’s
In-network support for content addressability and caching is desirable service primitives such as get(content-ID, ..)
WINLAB
Context-aware delivery associated with mobile services, M2M 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
Mobile
Device
trajectory
Context = geo-coordinates & first_responder
Send (context, data)
Context-based
Multicast delivery
Context
GUID
Global Name
Resolution service
ba123
341x
Context
Naming
Service
NA1:P7, NA1:P9, NA2,P21, ..
Next-Gen Network Requirements:
(7) Context-Aware Services
WINLAB
Next-Gen Network Requirements: (8) Edge
Cloud Services
User Mobility
Edge Cloud
Service
A
Edge Cloud
Service
B
“Nearest” Cloud Service
Low latency, dynamic migration
Mobile Internet
Access Network A
Access Network B
Efficient, low-latency cloud services important for emerging
mobile data and cyber physical applications Tight integration of cloud service with access network
Service “anycast” feature
Low latency, dynamic migration of state
Get(“service_ID, data)
WINLAB
Access
Network
)
Next-Gen Network Requirements:
(9) Edge Peering and Ad Hoc Networks 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 along the edge
Requires rethinking of inter-domain routing, trust model, etc. Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility
INTERNET
Access
Network
)
V2V Network
V2I
WINLAB
Next-Gen Network Requirements: (10) Radio
Resource Visibility in Control Plane
As more data is carried by unlicensed wireless networks, RRM such
as spectrum management can be offered as a network service
Management plane offers global visibility for cooperative setting of
radio resource parameters across independent access networks
WiFi AP locations in a 0.4x0.5 sq.mile area in Manhattan, NY
Network Management Plane
Interface for Radio Parameter Map
(e.g. Frequency, Power, Rate, ..)
Inter-network spectrum
coordination procedures
MobilityFirst Protocol
Design
WINLAB
MobilityFirst Design: Architecture Features
Routers with Integrated
Storage & Computing Heterogeneous
Wireless Access
End-Point mobility
with multi-homing In-network
content cache
Network Mobility &
Disconnected Mode
Hop-by-hop
file transport Edge-aware
Inter-domain
routing
Named devices, content,
and context
11001101011100100…0011
Public Key Based
Global Identifier (GUID)
Storage-aware
Intra-domain
routing
Service API with
unicast, multi-homing,
mcast, anycast, content
query, etc.
Strong authentication, privacy
Ad-hoc p2p
mode
Human-readable
name
Connectionless Packet Switched Network
with hybrid name/address routing
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
WINLAB
MobilityFirst Design: Technology Solution
Global Name
Resolution Service
(GNRS)
Hybrid GUID/NA
Global Routing (Edge-aware, mobile,
Late binding, etc.)
Storage-Aware
& DTN Routing
(GSTAR)
in Edge Networks
Optional
Compute Layer
Plug-Ins (cache, privacy, etc.)
Hop-by-Hop
Transport
(w/bypass option)
Name-Based
Services (mobility, mcast,
content, context,
M2M)
Name Certification
Service (NCS)
Meta-level
Network Services
Core Transport
Services
Pure connectionless packet switching with in-network storage
Flexible name-based network service layer
WINLAB
MF Design: Protocol Stack
IP
Hop-by-Hop Block Transfer
Link Layer 1
(802.11)
Link Layer 2
(LTE)
Link Layer 3
(Ethernet)
Link Layer 4
(SONET)
Link Layer 5
(etc.)
GSTAR Routing MF Inter-Domain
E2E TP1 E2E TP2 E2E TP3 E2E TP4
App 1 App 2 App 3 App 4
GUID Service Layer Narrow Waist GNRS
MF Routing
Control Protocol
NCS Name
Certification
& Assignment
Service
Global Name
Resolution
Service
Data Plane Control Plane
Socket API
Switching
Option
Optional Compute
Layer
Plug-In A
WINLAB
MF Design: Name-Address Separation
GUIDs Separation of names (ID) from
network addresses (NA)
Globally unique name (GUID)
for network attached objects User name, device ID, content, context,
AS name, and so on
Multiple domain-specific naming
services
Global Name Resolution Service
for GUID NA mappings
Hybrid GUID/NA approach Both name/address headers in PDU
“Fast path” when NA is available
GUID resolution, late binding option
Globally Unique Flat Identifier (GUID)
John’s _laptop_1
Sue’s_mobile_2
Server_1234
Sensor@XYZ
Media File_ABC
Host
Naming
Service
Network
Sensor
Naming
Service
Content
Naming
Service
Global Name Resolution Service
Network address
Net1.local_ID
Net2.local_ID
Context
Naming
Service
Taxis in NB
WINLAB
MF Protocol Example: Mobility Service via
Name Resolution at Device End-Points
MobilityFirst Network
(Data Plane)
GNRS
Register “John Smith22’s devices” with NCS
GUID lookup
from directory
GUID assigned
GUID = 11011..011
Represents network
object with 2 devices
Send (GUID = 11011..011, SID=01, data)
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
GUID <-> NA lookup
NA99
NA32
GNRS update
(after link-layer association)
DATA
SID
NAs
Packet sent out by host
GNRS query
GUID
Service API capabilities:
- send (GUID, options, data)
Options = anycast, mcast, time, ..
- get (content_GUID, options)
Options = nearest, all, ..
Name Certification
Services (NCS)
WINLAB
MF Protocol Design: Global Name
Resolution Service (GNRS)
Fast GNRS implementation based on DHT between routers GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID)
Results in distributed in-network directory with fast access (~100 ms)
Internet Scale Simulation Results
Using DIMES database
WINLAB
MF Protocol Design: Storage-Aware
Intra-Domain Routing (GSTAR) Storage aware (CNF, generalized DTN) routing exploits in-network
storage to deal with varying link quality and disconnection
Routing algorithm adapts seamlessly adapts from switching (good
path) to store-and-forward (poor link BW/short disconnection) to
DTN (longer disconnections)
Storage has benefits for wired networks as well..
Storage
Router
Low BW
cellular link
Mobile
Device
trajectory
High BW
WiFi link
Temporary
Storage at
Router
Initial Routing Path
Re-routed path
For delivery
Sample CNF routing result
PDU
WINLAB
MF architecture uses a new “edge-aware” inter-domain routing protocol based on link-state and “pathlet” concepts Aggregation nodes (aNode) and virtual link(vLink)
Telescopic link state protocol for dissemination of NSPs NSP contains aNode, vLink state including AS internal topology and
aggregate edge network quality info; NSP update rate decreases with distance
“Late binding” from name-to-address at routers Router has capability of rebinding <GUID=>Address> for packets in transit
MF Protocol Design: Edge-Aware Inter-
Domain Routing
aNode
vLink
AS virtual topology as
advertised by network
AS993
AS640
AS90
Edge Network
Transit Network
AS#, aNodes, vLinks, params..
NSP packet
1 NSP/sec 0.5 NSP/sec 0.1 NSP/sec
Alternate Path
Routed Path
For Multi-homing
Service
EIR Inter Domain Routing Concept
Router decision based
On edge network path
Quality – late binding
AS541
AS009
WINLAB
MobilityFirst Design: Segmented Transport
Segment-by-segment transport between routers with storage,
in contrast to end-to-end TCP used today
Unit of transport (PDU) is a content file or max size fragment
Hop TP provides improved throughput for time-varying
wireless links, and also helps deal with disconnections
Also supports content caching, location services, etc.
Storage
Router
Low BW
cellular link
Segmented (Hop-by-Hop TP)
Optical
Router
(no storage)
PDU
Hop #1 Hop #2
Hop #3
Hop #4
Temporarily
Stored PDU
BS
GID/Service Hdr
Mux Hdr
Net Address Hdr
Data
Frag 1
Data
Frag 2
Data
Frag n
……
Hop-by-Hop
Transport
More details of
TP layer fragments
with addl mux header
WINLAB
MF Protocol Design: Hybrid GUID/NA
Storage Router in MobilityFirst
GUID-Address Mapping – virtual DHT table
NA Forwarding Table – stored physically at router
GUID NA
11001..11 NA99,32
Dest NA Port #, Next Hop
NA99 Port 5, NA11
GUID –based forwarding
(slow path)
Network Address Based Forwarding
(fast path)
Router
Storage
Store when:
- Poor short-term path quality
- Delivery failure, no NA entry
- GNRS query failure
- etc.
NA32 Port 7, NA51
DATA
SID GUID=
11001…11 NA99,NA32
NA62 Port 5, NA11
To NA11
To NA51
Look up GUID-NA table when:
- no NAs in pkt header
- encapsulated GUID
- delivery failure or expired NA entry
Look up NA-next hop table when:
- pkt header includes NAs
- valid NA to next hop entry
DATA
DATA
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
WINLAB
MF Protocol Example: Handling Disconnection
Data Plane
Send data file to “John Smith22’s
laptop”, SID= 11 (unicast, mobile
delivery)
NA99
NA75
Delivery failure at NA99 due to device mobility
Router stores & periodically checks GNRS binding
Deliver to new network NA75 when GNRS updates
GUID NA75
DATA
GUID NA99 rebind to NA75
DATA
DATA
GUID SID
DATA
SID GUID
NA99
Device
mobility
Disconnection
interval
Store-and-forward mobility service example
WINLAB
MF GNRS + Storage Routing Performance
Result for WiFi Mobility Scenario
Detailed NS3 Simulations to
compare MF with TCP/IP
Hotspot AP Deployment:
Includes gaps and overlaps
Cars move according to realistic
traces & request browsing type
traffic (req. size: 10KB to 5MB)
0 10 20 30 40 50 60 700
0.2
0.4
0.6
0.8
1
File Transfer Time (sec)
CD
F
Empirical CDF of file transfer time
MF: d = 200
TCP/IP: d = 200
MF: Avg. d = 400
TCP/IP: d = 400
d: Average distance between APs
0 50 100 150 2000
20
40
60
80
100
Time (sec)
To
tal D
ata
Re
ce
ive
d (
MB
its)
Single Car: Aggregate Throughput vs.Time
TCP/IP-30miles/hr
TCP/IP-50miles/hr
TCP/IP-70miles/hr
MF-30miles/hr
MF-50miles/hr
MF-70miles/hr
WINLAB
LTE/WiFi HetNet Results: MF vs. TCP
MF provides several benefits in a heterogeneous wireless
environment: Seamless mobility across network domains via dynamic GUID-NA bindings
Routers automatically store packets in transit during periods of disconnection
Simultaneous use of multiple networks is also possible
0 20 40 60 80 100 1200
100
200
300
400
500
600
700
800
900
1000
Time (sec)
Ag
gre
ga
te T
hro
ug
hp
ut (M
Byte
s)
Aggregate Throughput with Time
MobilityFirst
TCP/IP
Throughput boost
due to
transmission of
stored packets
TCP takes more time to
re-start session (DHCP
+ Application reset)
WINLAB
MF Protocol Example: Dual Homing Service
Data Plane
Send data file to “John Smith22’s
laptop”, SID= 129 (multihoming –
all interfaces)
NA99
NA32
Router bifurcates PDU to NA99 & NA32
(no GUID resolution needed)
GUID NetAddr= NA32
DATA
GUID NetAddr= NA99
DATA
DATA
GUID SID
DATA
SID GUID=
11001…11 NA99,NA32
DATA
Multihoming service example: LTE + WiFi or LTE + 60 Ghz or LTE1+LTE2
WINLAB
MF Multi-Homing Example Result
Multipath service with data striping between LTE and WiFi
Using backpressure propagation and path quality info
GNRS Server
DataGUIDYChunk
NA1
Receiver: GUIDY
Sender: GUIDX
Query:(GUIDY)
Response:(NA1,NA2, Policy: Stripe)
DataGUIDY
Chunk
NA1
NA2
Chunk
Chunk Chunk
ChunkChunk
Chunk
DataGUIDY NA2
Backpressure
Path QualityNet Addr4NA1
36NA2
SplittingLogic
Back-pressure
0 10 20 30 40 50 60 70 80 90 1000
200
400
600
800
1000
Time (sec)
Ag
gre
ga
te T
hro
ug
hp
ut (M
b)
MobilityFirst Multihoming
Oracle Application
Using only LTE
Using only Wi-Fi
5meters/s 10meters/s 20meters/s 30meters/s0
50
100
150
200
250
300
350
400
450
Speed of Vehicle
File
Tra
nsfe
r C
om
ple
tio
n T
ime
(se
cs)
use both WiFi and LTE
use only WiFi
use only LTE
Multi-homing technique can also be combined
with Network Coding …
WINLAB
MF Protocol Example: Enhanced CDN
Service Using Compute Layer Feature
Content cache at mobile
Operator’s network – NA99
User mobility
Content Owner’s
Server
GUID=13247..99
GUID=13247..99 GUID=13247..99
GUID=13247..99
GNRS query
Returns list:
NA99,31,22,43
NA22
NA31
NA99
NA29
NA43
Data fetch from
NA99
Data fetch from
NA43
GNRS
Query
Get (content_GUID,
SID=128 - cache service)
Get (content_GUID)
Enhanced service example – content delivery with in-network caching & transcoding
MF Compute Layer
with Content Cache
Service plug-in
Query
SID=128 (enhanced service) GUID=13247..99
Filter on
SID=128
Mobile’s GUID
Content file
MobilityFirst Protocol
Prototyping & Validation
WINLAB
MobilityFirst Prototyping: Phased Strategy
43
Global Name Resolution Service (GNRS)
Storage Aware Routing
Context-Aware / Late-bind Routing
Context Addressing Stack
Content Addressing Stack
Host/Device Addressing
Stack
Encoding/Certifying Layer
Locator-X Routing (e.g., GUID-based)
Simulation and Emulation Smaller Scale Testbed
Standalone Modules
Distributed Testbed E.g. ‘Live’ on GENI
Deployable s/w pkg., box
Phase 1 Phase 2 Phase 3
Prototype
Evaluation
Integrated MF Protocol Stack and Services
WINLAB
MF Host Protocol Stack
44
Network API
E2E Transport
GUID Services
Routing
‘Hop’ Link Transport
Interface Manager
WiFi WiMAX
App-1 App-2
Security
‘Socket’ API open send send_to recv recv_from close
Network Layer
User policies
Linux PC/laptop with WiMAX & WiFi
Android device with WiMAX & WiFi
Device: HTC Evo 4G, Android v2.3 (rooted), NDK (C++ dev)
Integrate
Early Dev.
Context API
App-3
Context Services
Sensors
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:
Network Emulation
3. Commercial cloud
platform
1. GENI Wide Area
Deployment
2. ORBIT lab with net.
emulation
WINLAB
MF Click Software Router
46
Inter-Domain (EIR)
Multicast
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
WINLAB
MF Routing Prototype on ORBIT Click-based prototyping of edge-aware inter-domain routing
(EIR) on Orbit nodes
Implementation on 200+ nodes on the grid
Routing protocol uses “aNode” concept to disseminate full topology
and aggregated edge network properties
Telescopic NSP (network state packet) advertisement for scalability
SID 3
EIR Click router
EIR forwarding engine
RIB OSPF w.
Telescoping
Link state advs
NSP
GNRSd
Binding request
SID 2
NextHop
Table
SID 1
Data Packets Data Packet
WINLAB
OpenFlow/SDN Implementation of MF
48
MF Protocol Stack
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
WINLAB
MF Router Prototype on FLARE SDN
Platform from U Tokyo (Nakao)
Objectives Multi-site deployment of MobilityFirst
routing and name resolution services
Impact of large RTTs on MobilityFirst
network protocols
High performance evaluation of
MobilityFirst delivery services on
FLARE - 1Gbps, 10Gbps
Augmented Click router elements
compiled down to FLARE native
Evaluation of FLARE platform for
design and evaluation of next-
generation network protocols
Demo at GEC-16, March 2013
WINLAB
MF Multi-Site Deployment on GENI
Salt Lake, UT
Cambridge,
MA
N. Brunswick,
NJ
Ann Arbor, MI Madison, WI
Tokyo, Japan
Lincoln, NE
Los Angeles,
CA Clemson,
SC
Long-term (non-
GENI)
MobilityFirst Access
Net
Short-term
Wide Area ProtoGENI
Palo Alto, CA
ProtoGENI
MobilityFirst
Routing and Name
Resolution
Service Sites
I2
NL
R
Atlanta, GA
WINLAB
GENI Deployment of MobilityFirst at
GEC18, Oct 2013 MF Routing and Naming
Services deployed at 5 GENI rack sites with Internet2’s AL2S providing cross-site layer-2 connectivity
Rutgers and NYU Poly (with rack at NYU) routers connected to WiFi and WiMAX access networks
Android phones with WiFi/WiMAX connectivity ran MF stack and demo application (Drop It)
3/7/2014 WINLAB, Rutgers University 51
Wisconsin
GENI rack
Utah
GEN
I
rack
BBN
GENI
rack GENI Internet2
Core
GENI
Edge
GENI
Edge
WiMAX
BTS
WiMAX
BTS
MobilityFirst
Software Router
with GNRS
Dual homed
Android phone
with WiFi/WiMAX
with MF stack
ORBIT radio
node with WiFi
as MF AP
Sample “GeoTag”
context-aware
application
WINLAB
Resources
Project website: http://mobilityfirst.winlab.rutgers.edu
GENI website: www.geni.net
ORBIT website: www.orbit-lab.org
WINLAB website: www.winlab.rutgers.edu