MobilityFirst FIA Project: Status Summary & Technical Overview NSF Visit, Oct 6, 2011

Contact: D. Raychaudhuri WINLAB, Rutgers University Technology Centre of NJ 671 Route 1, North Brunswick, NJ 08902, USA ray@winlab.rutgers.edu

MobilityFirst Project: Collaborating Institutions

(LEAD)
D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson M. Reiter A. Venkataramani, J. Kurose, D. Towsley

S. Bannerjee

W. Lehr Z. Morley Mao

B. Ramamurthy X. Yang, R. RoyChowdhury G. Chen

Project Funded by the US National Science Foundation (NSF) Under the Future Internet Architecture (FIA) Program, CISE

+ Also industrial R&D collaborations with AT&T Labs, Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others

WINLAB

Project Status

Status Summary: Project Goals

MobilityFirst objectives from the NSF FIA project abstract (Aug 2010):

This project is aimed at the design and experimental validation of a comprehensive clean-slate future Internet architecture. The major design goals of the architecture are: mobility as the norm with dynamic host and network mobility at scale; robustness with respect to intrinsic properties of the wireless medium; trustworthiness in the form of enhanced security and privacy; usability features such as support for context-aware services, evolvability, manageability and economic viability. The projects scope includes architectural design, validation of key protocol components, testbed prototyping of the MobilityFirst architecture as a whole, and real-world protocol deployment on the GENI experimental infrastructure. WINLAB

Status Summary: Project Phases

The MobilityFirst project is now past the one-year mark Year 1 focus was on:

Broad exploration of architectural space Investigation of key concepts/techniques for inclusion Building team consensus on protocol design Initiating phased proof-of-concept prototyping effort Full v1.0 protocol specification with team agreement Algorithms and design details to support protocol spec Development of complete MF network prototype Small and medium scale evaluations on ORBIT, GENI, etc. Large-scale and end-user evaluations v2.0 protocol spec based on feedback from experimental studies, etc. Hardware/software implementation & related optimizations Industry and standards outreach, etc.

Year 2 focus will be on:

Year 3 goals include

WINLAB

Status Summary: Project Organization

The project is organized into several working groups

Architecture WG Naming/Addressing/Routing Security & Privacy Context/Content Services Economics & Policy Evaluation & Analysis System-level prototyping

Each WG represents a cluster of activity each involving ~3-5 people. Project structure is based on cooperation among peers rather than hierarchy. The WINLAB prototyping team serves as the central point for specification & development. Coordination done by weekly teleconferences and ad hoc WG calls; also ~3 team meetings (not including FIA) in year 1 for brainstorming and consensus building.

WINLAB

Status Summary: Project Map (by site)

G. Chen Network Management System Prototyping

W. Lehr Economics & Policy Analysis

Android Mobile Client and mobile apps

S. Bannerjee

Interdomain Routing Architecture, Security Z. Morley Mao

Architecture, Name Resolution Service, Routing (Intra and Interdomain), Evaluation Models, Content Services, Security, System Prototyping A. Venkataramani, J. Kurose, D. Towsley, D. Westbrook Architecture, Routing (Intra and Interdomain), Global Name Resolution Service, Content Services, Context Services, Security, Privacy, Economic Models, Mobile Applications, System Prototyping & GENI Integration

Optical Network Interface, Net Mgmt

B. Ramamurthy

D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson, J. Li

Security, Name Resolution & Routing M. Reiter Computing Layer DOS Resistance Context-Aware Apps X. Yang, R. RoyChowdhury

WINLAB

Status Summary: Project Map (by WG topic)

MF Click Router

Prototyping

DTN

GNRS

GSTAR/R3 Routing

GENI Integration

Interdomain Routing

Android client

Computing Layer

Network Mgmt

Cross-cutting Tasks

Evaluation

Storage Routing Analysis

Content Delivery Models

Multipath Routing Evaluation

GNRS Scaling Evaluation

Simulation Models

Large-scale Network models

Architecture

Mobile/Pervasive Requirements Study

Name-Address Separation concepts

GUID Routing Etc.

Security Model

API

Content- and Context services

Name assignment services Inter-domain protocol GSTAR Protocol Vertical Tasks Routing algorithms: Late binding, mcast, .. Hybrid GUID/NA Routing Storage Routing Design GNRS Design B GNRS Design A

Privacy design Context-aware Applications

Security analysis & attack scenarios DOS resistance/ Intentional receipt Secure Interdomain Routing Secure GNRS

DOS Detection Tools etc.

Privacy Policy Policy Analysis for MF architecture

Spectrum Coordination

Geographic Services

MF Measurement Tools & Library Independent NMS Routing scheme

Sensor/M2M Use Case

Network SLAs & incenstives

Name Certification Services Public Key GUID

Context Service Model

Net Neutrality Study

Client-assisted measurements

Content Delivery & Mobile Cache

4G/LTE BB Mobile Study

Naming/Routing

Security/Privacy

Network Mgmt

Pervasive Mobile

Network Economics

* Note that the above is only a representative set of projects, not intended to be exhaustive

WINLAB

Status Summary: Year 1 Progress

Year 1 progress highlights include

Consensus on High-level MF architecture concepts (name-address separation, public key names, GUID service layer, hybrid GUID/NA routing, storage-aware routing, hop-by-hop TP, content- and context services, etc.) Design and evaluation of global name resolution service (GNRS) Design and evaluation of storage-aware intra-domain routing (GSTAR) Concepts and baseline design for context-aware services Baseline security and privacy architecture design (cont. on next slide)

WINLAB

Status Summary: Year 1 Progress

Year 1 progress highlights (cont.)

Prototyping of several key components including GNRS, MF Router with storage routing, context service, content delivery, Android mobile, etc. GEC-12 demo of MF protocol stack running over multiple campus routers and wireless BS/APs under development for Nov 2011 Ongoing research on

Network management requirements and design Computing layer for optional service plug-ins Analysis models for MF networks including GNRS, multipath, content, .. Inter-domain routing options and related algorithms for mcast, anycast, dualhoming, etc. Security and privacy mechanism details and attack scenarios Network services for content, context, network trust, etc. Economic models and policy issues Optical network interface

WINLAB

Status Summary: Near-term Goals

Global Name Resolution Service (GNRS) validation & selection Consensus on 1-2 Interdomain routing approaches & implementation of corresponding protocols/algorithms Baseline algorithms for advanced routing services mobile, mcast, multi-homing, mpath, late binding, etc. v1.0 MF protocol spec GEC-12 demo system integration and application design Details of baseline security protocols & implementation Service API with content- and context-aware use cases Design for intentional receipt/DoS resistance Initial prototyping of computing layer
WINLAB

Status Summary: Longer Term Research Goals

Large-scale GNRS models with ~10B mobile end-points Conclusive validation of storage routing seamless across various wired and wireless network scenarios Proving robustness (Byzantine fault tolerance) properties Details of the MF trust model, including support for mobile nodes, networks, DTN, p2p, virtual nets, Security against malicious network nodes Privacy preserving mechanisms Understanding context services & future mobile/pervasive application requirements Technology realization from IP routers to GUID/storage routers with optional computing .
WINLAB

Protocol Design Highlights

MobilityFirst Protocol Stack: Overview

Core elements of MF protocol stack

GUID services layer, supported by control protocols for bootstrap & updates GUID to network address mapping (GNRS) for dynamic mapping of GUID Generalized storage-aware routing (GSTAR) with supporting control protocols Reliable hop-by-hop block transfer between routers Management plane protocol with its own routing scheme Multiple TP options and plug-in programmable services at GUID layer
APP-1 APP-2 APP-n

Name Certification Service A

E2E Transport Protocol A

E2E Transport Protocol B

..

E2E Transport Protocol B

Mgmt Apps

Routing Apps

GUID Services Control Protocols

GUID Service Layer GUID-to-Net Address Mapping

Computing Layer Service Plug-ins

Management Plane Protocols (incl. routing)

Routing Control Protocols

Storage-Aware Routing (GSTAR) Hop-by-hop Block Transfer Protocol

Link Layer A (e.g fiber) Link Layer B (e.g LTE) Link Layer C (e.g WiFi) Link Layer D (e.g Ethernet

WINLAB

MobilityFirst Protocol Stack: NameAddress Separation

Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects

Sues_mobile_2 Server_1234 Sensor@XYZ

Media File_ABC

Taxis in NB

Johns _laptop_1

User name, device ID, content, context, AS name, and so on Multiple competing application specific name certification services

Host Naming Service

Sensor Naming Service

Content Naming Service

Context Naming Service

Globally Unique Flat Identifier (GUID) Global Name Resolution Service

Global Name Resolution Service for GUID NA mappings

Network

Hybrid GUID/NA approach

Both name/address headers in PDU Fast path when NA is available GUID resolution, late binding option
Network address Net1.local_ID

Net2.local_ID

WINLAB

MobilityFirst Protocol Stack: Service Abstractions

MobilityFirst API proposes a new multipoint/multipath/time delivery abstraction that reflects the intrinsic broadcast & multi-homing nature of the wireless medium along with in-network storage Replaces the communication link abstraction provided by IP
MF Abstraction: Network Object with multipath reachability
Send(IP=X, data)

IP Abstraction: Virtual Link

MF Abstraction: Network Object Group with broadcast reachability

Send(GUID=Y, data, options) ..options for mpath & time delivery

Send(GUID=Z, data, options) ..option for mcast delivery

Network IP Addr=X Interface Static MAC=X binding

NA=X1

NA=X2

NA=X3 NA=X2 Dynamic GUID NA bindings

Broadcast Medium

Dest Device

Name= MAC

GUID=Y Network Attached Object

Group GUID = Z

GUID1

GUID2

GUID3

WINLAB

MobilityFirst Protocol Stack: Packet Headers

Packet headers at various levels of MF protocol stack

-GUID is the authoritative header in all packets SID provides service definition such as anycast, delayed delivery, Optional NA list for fast path in routing layer
Network Routing Layer GUID Service Layer Application Transport Layer

NA list (optional) SID GUID (src/dest) TP/Seq #

SID GUID (src/dest)

TP/Seq # Data PDU (protocol data unit)

TP/Seq #

PDU (protocol data unit)

PDU (protocol data unit)

MAC/LL header

LL Pkt
Service API e.g. assign(GUID, handle) & Send (GUID, data), Get (GUID), etc.

WINLAB

MF Protocol Stack: Packet Headers and Forwarding with Hybrid GIUD/NetAddr

Hybrid scheme in which packet headers contain both the object name (GUID) and topological address (NA) routing NA header used for fast path, with fallback to GUID resolution where needed Enables flexibility for multicast, anycast and other late binding services
Optional list of NAs - Destination NA - Source route - Intermediate NA - Partial source route GUID/Service Header NA Header GUID based forwarding (slow path) GID-Address Mapping GUID xz1756.. NA Net 1194 GID/Service Header NA Header

Name-GID Mapping Name server@winlab GUID xy17519bbd

GUID/Service Header

PDU with GUID Header only Data Object (100B-1GB)

PDU with GUID and NA headers Routing Table Dest NA Net 123 Path Net11, net2, ..

GUID Header Components

GUID/Public Key Hash
SID (Service Identifier) Network Address Based Routing (fast path)

WINLAB

Architecture Concepts: Global Name Resolution Service for Dynamic Name <-> Address Binding

Fast Global Name Resolution a central feature of architecture

GUID <-> network address (NA) mappings Fast updates ~50-100 ms to support dynamic mobility Service can scale to ~10B names via P2P/DHT techniques, Moores law
Host GUID Registration update

Distributed service, possibly hosted directly on routers

Network NA2
Mobile node trajectory

NA2

Data Plane
AP

Network NA1
Host GUID Initial registration

Global NameAddress Resolution Service

Network Address

Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network

NA1

Host Name, Context_ID or Content_ID

WINLAB

Protocol Design: Direct Hash 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)

1 0.9 C m la u u tive D istrib tio F n n (C F u n u ctio D) 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 K = 5, 95th Percentile at 91 ms K = 1, 95 th Percentile at 202 ms

K K K K K 10 20 50 100 Round Trip Query Latency in milliseconds (log scale)

= = = = =

1 2 3 4 5 1,000

Internet Scale Simulation Results Using DIMES database

WINLAB

Architecture Concepts: MobilityFirst Routing Design Goals

Routing protocol should seamlessly support a wide range of usage scenarios, from wired mobile ad hoc DTN

Device, content and network mobility Heterogeneous devices and radio access Robustness to varying BW, disconnection Dynamic network formation & flexible boundaries

Core

4G

Connectivity
Wired WirelessMesh/Cellular MobileAdHoc DTN

WINLAB

Architecture Concepts: Exploiting InNetwork Storage for Routing

Take advantage of cheap storage in the network (storage-aware routing)

~100MB,dataintransit ~10GB,innetworkstorage ~1TB,contentcaching

Expands routing options

Store and/or replicate as feasible routing options Enables late binding routing algorithms

Generalized Storage-Aware Routing

Actively monitor link qualities of network Router store or forward decision based on: 1. Short and long term link qualities 2. Available storage along path 3. Connectivity to destination

Hop-by-hop transport

Large blocks reliably transferred at link layer Entire block can be stored or cached at each router

Protocol Design: Storage-Aware 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..
Temporary Storage at Router

Initial Routing Path

Low BW cellular link

Re-routed path For delivery Mobile Device trajectory

PDU

Storage Router
High BW WiFi link Sample CNF routing result

WINLAB

Protocol 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.
PDU Segmented (Hop-by-Hop TP) Hop #3 Hop #1 Hop #2 Hop #4 Temporarily Stored PDU Low BW cellular link BS

Storage Router
Hop-by-Hop Transport

Optical Router (no storage)

GID/Service Hdr Mux Hdr

More details of TP layer fragments with addl mux header

Data Frag 1

Data Frag 2

Data Frag n

Net Address Hdr

WINLAB

Architecture Concepts: MobilityFirst Interdomain Routing

Requirements include: flexible network boundaries, dynamic formation, virtual nets, network mobility, DTN mode, support for path selection, multipath, multi-homing, improved security, etc. Motivates rethinking of todays 2-tier IP/BGP architecture (interAS, intranet) MobilityFirst interdomain approach uses GNRS service + enhanced path vector routing to achieve design goals still evaluating multiple design options.
Core Net 17 Core Net 23 Access Net 500 Access Net 200

Path Vector+ Path Vector+ Routing protocol Routing Plane Provides reachability & path info between networks

Mobile Net 1

Mobile Net 2

GNRS provides Global GNRS Net name <-> addr mapping directory

WINLAB

Protocol Design: MobilityFirst Interdomain Routing

One approach under consideration is to enhance BGP-like protocols with summary node/link info (Vnode graph)

Summary knowledge of access net properties (Mbps, % avail, etc.), ingress/egress points and alternate paths exchanged between networks/ASs Network topology information for identifying multiple paths, storage points, etc.

Inspired by Vnode concept in Pathlet routing (Godfrey, 2008) Support for multicast, anycast, multihoming and multipath
Edge Network
Example of dual=homing route Supported by routing protocol

Transit Network V21

V71

V74

V22

V72
Aggregated Vnode properties & path info

V23 V73

V11

V12

V13

WINLAB

Protocol Design: MobilityFirst Services

MobilityFirst API (or socket interface) provides a new set of services corresponding to the MF protocol stacks 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) Lightweight transport protocol choices for end-to-end reliability and flow control 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) Get(GUID=X, SvcFlags/SID=anycast+content query, options, data_buffer, len) .

Socket interface examples:

WINLAB

Protocol Design: GUID socket interface

GUID-based addressing available at host, service/application, socket, and file level

GUIDs can also address groups of entities Each application end-point can have a separate GUID No port contention, and no assumed well-known ports for services Applications may choose to use host-GUID with a demux appID Demux identifiers advertised at local directory services

Port-less addressing of application end-points

GUID aggregation and Service Directories

Port-less, 1 GUID per endpoint

APP-1 APP-2 APP-3 APP-4

GUID Aggregation and Service Directory

APP-1 APP-2 APP-3 APP-4 appID-1 appID-2 appID-3 appID-4

Host

Transport Layer Directory Service

Host
GUID-1 GUID-2 GUID-3 GUID-4 GUID-0 GUID-0

WINLAB

Protocol Design: Content Delivery in MobilityFirst

Content delivery handled efficiently by proposed MF architecture

Content objects identified by unique GUID Multiple instances of content file identified by GNRS via GUID to NA mapping Routing protocol used for reverse anycast to nearest content object

Approach differs from NDN/CCN, where content attributes are carried in packet headers MF uses content GUID naming service & GNRS to keep things general and avoidStore #2 interpreting content semantics inside network Content
GUID=13247..99
NA43 NA31

GUID=13247..99

NA99

GUID=13247..99

Content cache at mobile Operators network NA99

NA29

GNRS Query

GNRS query Returns list: NA99,31,22,43

Data fetch from NA99

GUID=13247..99
NA22

Content Store #1 (owner)

Data fetch from NA43

Get (content_GUID) User mobility

Get (content_GUID)

WINLAB

Protocol Design: Context Aware Delivery

Context-aware network services supported by MF architecture

Dynamic mapping of structured context or content label by global name service Context attributes include location, time, person/group, network state Context naming service provides multicast GUID mapped to NA by GNRS Similar to mechanism used to handle named content

Context = geo-coordinates & first_responder 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

Protocol Design: Management Plane

Separate mgmt plane designed into MF architecture

Provides visibility into key mobile network aspects such as name resolution, disconnected operation, wireless access quality, contextaware services, location, privacy, Includes mechanism for network-assisted dynamic spectrum assignment (DSA) as a basic capability Intended to improve transparency and support add-on mgmt apps

Data Plane
Data packets
AP

Net Mgmt Interface (performance queries, configuration, faults, security, ..)

Control & Management Plane

WINLAB

Protocol Design: Management Plane (cont.)

Support for dynamic spectrum assignment (DSA)

Given that the majority of end-user devices are wireless, Internet spectrum should be assigned on demand Management plane mechanism for exchange of spectrum use data
Distributed Spectrum Coordination Algorithm Software (runs on all radio devices)

Region B Radio Coverage Region A Region C

Geo-cast Spectrum Update Service

Mobility First Control & Management Plane

Region D
AP

Aggregate Spectrum Updates Between Routers

Spectrum Use Update (from Radios) Spectrum Occupancy Map (from Routers)

WINLAB

Protocol Design: Computing Layer

Programmable computing layer provides service flexibility and evolution/growth path

Routers include a virtual computing layer to support new network services Packets carry service tags and are directed to optional services where applicable Programming API for service creation provided as integral part of architecture Computing load can be reasonable with per-file (PDU) operations (vs. per packet) Virtual Service Provider

Content Caching

Privacy routing

Computinglayer

CPU

Storage

Packetforwarding/routing
anony anony

......

......

WINLAB

Security Considerations:

Public key GUIDs for hosts & networks; forms basis for

Ensuring accountability of traffic Ubiquitous access-control infrastructure Secure routing; no address hijacking

Emphasis on achieving robust performance under network stress or failure

Byzantine fault tolerance as a goal Transform malicious attacks into benign failure Performance observability (in management plane) Every MF node can revert to GUID level to check authenticity, add filters, .. Opens naming to innovation to combat naming-related abuses Removes obstacles to adoption of secure routing protocols

Intentional receipt policies at networks and end-user nodes

No globally trusted root for naming or addressing

WINLAB

Security Considerations: Trust Model

Host Naming Service X Content Naming Service Y Context Naming Service Y Other Naming Services TBD Network Naming Service B Network Naming Service A Name assignment & certification services (..can incorporate various kinds of trust including CA, group membership, reputation, etc

GUID = public Key

GNRS
GUID <-> NA binding

Secure Host Name Service Lookup

Secure GNRS Update

NET NA7

Secure Network Name Service Lookup

Secure InterNetwork Routing Protocol NET NA1 NET NA33

NA 14

Aggregate NA166: NA14, NA88, NA 33 NA 88

NA 51 Secure Data Path Protocol

NA 99

Public Key object and network names enable us to build secure protocols for each interface shown

WINLAB

Privacy Considerations:

Public key GUIDs provide a basic level of privacy

Semantics of GUID in packet header not known to an observer But, GUIDs locator/NA can be tracked through repeated queries to GNRS Solutions such as disposable GUIDs or white-listing in GNRS

Enhanced privacy services possible through plug-ins at computing layer

e.g. optional onion routing for designated SID

Architecture supports a range of privacy policy options to be discussed further

WINLAB

Use Cases: GUID/Address Routing Scenarios Multicast/Anycast/Geocast

Multicast scenario below also uses GUID <-> Network Address resolution (latebinding) at a router closer to destination (..GUID tunnel)
DATA NetAddr=NA1,PA1

GUID NetAddr=NA1:PA1,PA2,PA9; NA7,PA22

NetAddr=NA1,PA2 Late GUID <-> addr Binding at NA1 Port 1

Port 2 Net 1

Net 7

Port 22

DATA

NetAddr=NA7,PA22

GUID = mcast group

DATA

NetAddr= NA1

GUID/SID Send data file to WINLAB students

Intermediate network address NA1 provided by GNRS

WINLAB

Use Cases: GUID/Address Routing Scenarios Dual Homing

The combination of GUID and network address helps to support new mobility related services including multi-homing, anycast, DTN, context, location Dual-homing scenario below allows for multiple NA:PAs per name
DATA

GUID NA1:PA22; NA7:PA13 Router bifurcates PDU to NA1 & NA7 (no GUID resolution needed) GUID
Net 1 DATA

NetAddr= NA1.PA22

Alices laptop GUID = xxx

Data Plane

Net 7

Dual-homed mobile device

DATA

DATA

GUID NetAddr= NA7.PA13

GUID/SID NA1:PA22; NA7:PA13

DATA

GUID & SID Send data file to Alices laptop

Current network addresses provided by GNRS; NA1:PA22 ; NA7:PA13

WINLAB

Use Cases: GUID/Address Routing Scenarios Handling Disconnection

Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment

DATA

GUID

NetAddr= NA1.PA9 - Delivery failure

PDU Stored in router - GUID resolution for redirection DAT A

GUID

Mobility Trajectory Net 1 Disconnected Region

Data Plane

Net 7

DATA

GUID
DATA

NetAddr= NA1.PA7 GUID

DATA

GUID/SID Send data file to Alices laptop

Current network address provided by GNRS; NA1 network part; PA9 port address

NetAddr= NA7.PA3 Successful redelivery after connection

WINLAB

Prototyping & Evaluation

MobilityFirst Prototyping: Phased Approach

Context Addressi ngStack Content Addressi ngStack Host/Device Addressing Stack

Encoding/CertifyingLayer

GlobalNameResolutionService(GNRS)

StorageAware Routing ContextAware/ LatebindRouting

LocatorXRouting (e.g.,GUIDbased)

Simulation/Emulation

Emulation/LimitedTestbed

Testbed/LiveDeployment

EvaluationPlatform
Standalone Components SystemIntegration Deploymentready

PrototypingStatus
WINLAB

MobilityFirst Prototyping: Software Router

Linuxbasedsoftwarerouterwithtwolevelimplementation

MFAppServices

Portable user-level implementation

OpenFlowController
MFNameResolution

XORP
MFRouting&Mgmt.

Quagga
OpenFlow switchhost

UserLevelControl Plane

ForwardingEngine

Linuxrouting

Click
NetFPGA

CommodityHardware

WINLAB

42

MobilityFirst Prototyping: GENI Deployment Plan (Phase 3)

Domain1

Legend
Domain2 Domain3

Services

Internet 2 National Lambda Rail OpenFLow Backbones OpenFlow

Wireless Edge (4G & WiFI) Router Wireless Edge (4G & WiFI)

Full MF Stack at routers, BS, etc.

Router Wireless Egde (4G & WiFI) Router Router

Intra-domain mobility

WiMAX ShadowNet

MappingontoGENI Infrastructure
ProtoGENI nodes, OpenFlowswitches, GENIRacks, WiMAX/outdoorORBIT nodes,DieselNet bus, etc.

Router Opt-in users Router Inter-domain mobility

DeploymentTarget:
Largescale,multisite Mobilitycentric Realistic,live

WINLAB

43

Resources

Project website: http://mobilityfirst.rutgers.edu GENI website: www.geni.net ORBIT website: www.orbit-lab.org

WINLAB