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

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