Next-Generation Mobile Networks and Convergence with Future Internet Architecture Wireless Technology Summit Tokyo, Japan March 7, 2014

D. Raychaudhuri WINLAB, Rutgers University

ray@winlab.rutgers.edu

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

E-Mail

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, …

Ope Ne

Edge Networks with Mobility Services

RAN A

RAN B

RAN A RAN Net B

RAN C B

Enhanced Packet Core (Operator Network)

MME

SGW

Standard IP Router

Future IP control plane w/ mobility support

To/From Global Internet

CRAN C

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

IN

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 TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

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)

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

Wireless Access Net #11

INTERNET

Access Network (Eithernet)

Radio Broadcast Medium

Packet-level Multicast at Routers/AP’s/BSs

RP

RBBBBBBBBBBBBBBBBBBBMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

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

Access

INTERNET

WireWireless 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

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

AccessWireless 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

m

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

BNetwork 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 = 200TCP/IP: d = 200MF: Avg. d = 400TCP/IP: d = 400

d: Average distance between APs

0 50 100 150 2000

20

40

60

80

100

Time (sec)

Tota

l Dat

a R

ecei

ved

(MB

its)

Single Car: Aggregate Throughput vs.Time

TCP/IP-30miles/hrTCP/IP-50miles/hrTCP/IP-70miles/hrMF-30miles/hrMF-50miles/hrMF-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)

Agg

rega

te T

hrou

ghpu

t (M

Byt

es)

Aggregate Throughput with Time

MobilityFirstTCP/IP

Throughput boost due to transmission of stored packets

TCP takes more time to re-start session (DHCP + Application reset)

oP

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)

Agg

rega

te T

hrou

ghpu

t (M

b)

MobilityFirst MultihomingOracle ApplicationUsing only LTEUsing 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 Com

plet

ion

Tim

e (s

ecs)

use both WiFi and LTEuse only WiFiuse 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

WWWWWIN46

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 3

SID 2

NextHop Table

SID 1

Data Packets Data Packet

WINLAB

OpenFlow/SDN Implementation of MF

48 WINLAB

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 AAAAAAAAAAAAAAAAnAnAAAAAAAAAMadison, WI

Tokyo, Japan

Lincoln, NE

Los Angeles, CA Clemson,

SC

Long-term (non-GENI)

MobilityFirst Access Net

GENI)GENI)Short-term

Wide Area ProtoGENI

Palo Alto, CA

WINLABProtoGENI

MobilityFirst Routing and Name Resolution Service Sites

I2

NLR

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 GENI 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