MobilityFirst: A Robust and Trustworthy Mobility-Centric ...€¦ · MobilityFirst FIA Team...

MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future InternetNSF FIA MeetingNov 15-16, 2010

Contact: D. [email protected]

MobilityFirst Project Team

MobilityFirst FIA Team Presentation Nov 15, 2010

MobilityFirst Project: Collaborating Institutions

(LEAD)

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

D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar

S. Bannerjee W. LehrZ. Morley Mao

B. Ramamurthy

G. ChenX. Yang, R. RoyChowdhury

A. Venkataramani, J. Kurose, D. Towsley

M. Reiter

MobilityFirst Vision


INTERNETINTERNET

Vision: Mobility as the key driver for the future Internet

Historic shift from PC’s to mobile computing and embedded devices…

~4 B cell phones vs. ~1B Internet-connected PC’s in 2010Mobile data growing exponentially – Cisco white paper predicts >1exabyte per month (surpassing wired PC traffic) by 2012Sensor deployment just starting, ~5-10B units by 2020

WirelessEdge Network


INTERNETINTERNET

~1B server/PC’s, ~700M smart phones

~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors

~2010 ~2020




INTERNETINTERNET

Vision: Near-term “mobile Internet” usage scenario – cellular convergence

~4-5B new cellular devices in just a few years will drive convergence of technical standards and business models

Currently involves 2 sets of addresses (cellular number & IP), 2 sets of protocols (3GPP and IP), and protocol gateways (GGSN, PDN GW, etc.)Scalability, performance and security problems when bridging 2 networksEven more complicated with multiple radio access systemsLack of a single unified standard inhibits mobile Internet app development across diverse networks and platforms

Cellular –Internet

GW

Cellular –Internet

GW MOBILE INTERNET

MOBILE INTERNET

Cellular system A

Cellular system B

Radio Access Net A

Radio Access B

Radio Access C


Vision: Near-term “mobile Internet” usage scenario – Mobile P2P and InfostationsP2P and Infostations (DTN-like) modes for content delivery becoming mainstream

Heterogeneous access; network may be disconnected at timesInvolves both terminal and router mobility; dynamic trust establishmentRequires content caching and opportunistic data delivery

Mobile DTN Router

Roadway Sensors

Mobile DTN User/Router

Ad-HocNetwork

OpportunisticHigh-Speed Link(MB/s)

Mobile P2P User

InfostationsRouter

MOBILE INTERNETMOBILE INTERNET


Vision: Future “mobile Internet” usage scenarios – vehicular networks

100’s of million cars will be equipped with radios by ~2015Both V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) modesInvolves capabilities such as location services, georouting, reliable multicastImportant new trust (security and privacy) requirements in this scenario

Irrelevant vehicles in radio range for few seconds

Passing vehicle,in radio range for seconds

Following vehicle,in radio range for minutes

V2I

V2V


Vision: Emerging “mobile Internet” usage scenarios – pervasive (ubiquitous) systems

The next generation of Internet applications will involve interfacing human beings with the physical world

Wide range of usage scenarios including healthcare, smart grids, etc.Networking requires awareness of location and context, along with embedded computational resourcesChallenges - flexible network computing model, security and robustness

Vehicles with Sensors & Wireless

HealthcareApplication

Robotics Application

Network Connectivity& Computation

“Human in the Loop”

To Actuators

Virtualized physicalworld object

Content & LocationAware Routers

Computation& StorageProtocol

module

Ambient interfaces

Global Pervasive Network(Future Internet)

DataFromSensors

Smart Grids

“Cloud” Applications


Vision: Protocol Design for the future Mobile/Wireless World

Fundamental change in design goals and assumptions~10B+ mobile/wireless end-points as “first-class” Internet devicesMobility as the norm for end-points and access networksWireless access – varying link BW/quality, multiple radios, disconnectionsStronger security/trust requirements due to:

open radio mediumneed for dynamic trust association for mobile devices/users, increased privacy concerns (e.g. location tracking)greater potential for network failure

Mobile applications involve location/content/context and energy constraints

Technology has also changed a lot in the ~40 yrs since IP was designed

Moore’s law improvements in computing and storage (~5-6 orders-of-magnitude gain in cost performance since 1970)Edge/core disparity, fast fiber but continuing shortage of radio spectrum


Vision: Protocol Design for the future Mobile/Wireless World (cont.)

Proposed MobilityFirst architecture motivated by these considerations

Clean-slate protocol design that directly addresses the problems of mobility at scale, while also strengthening the trust model

End-point and network mobility at scaleIntrinsic properties of wireless mediumMore stringent security/trust requirementsSpecial needs of emerging mobile applications

Fixed internet access is treated as a special case of the more general designAlthough the “sweet spot” of our protocol is wireless/mobile, we believe that our design provides important benefits to fixed network applications

Security/trustRobustnessFault toleranceContext/content

Architecture Overview


Architecture: MobilityFirst Network Overview

Base Station

Wireless Router

AP

Core Network(flat label routing)

Router

Global Name Resolution Service

Control & Management Plane

Computing BladeBuffer StorageForwarding Engine

MobilityFirstRouter withIntegrated

Computing & Storage

Hop-by-HopTransport

GDTN Routing

Name <-> PKI address mapping

Data blockDataPlane

MobilityFirst key protocol features:

Fast global naming serviceSelf-certifying public key namesDynamic mapping of name to topological network address(es)Routers support both flat name and hierarchical address routingStorage-aware (generalized DTN) routing in accessHop-by-hop (segmented) transportProgrammable computing layerSupport for content/context/locationSeparate network mgmt plane

New components, very distinct from IP, intended to achieve key mobility and trust goals

More detailed rationale for the architecture in the following slides


Architecture: MobilityFirst Protocol StackCore elements of protocol stack (“narrow waist)

Global Name Resolution & Routing ServicesStorage-aware routing (GDTN) protocolHop-by-hop (segmented) transportServices and management API’s

Multiple TP and link layer options + programmable services

Link Layer A(e.g fiber)

Link Layer B(e.g LTE)

Link Layer C(e.g WiFi)

Link Layer D(e.g Ethernet

ManagementProtocol

Storage Aware Routing (GDTN)

Hop-by-Hop In-Network Transport

E2ETransport Protocol 1

E2ETransport Protocol 2

M-Socket

D-Socket D-Socket

M-APP

APP-1 APP-n

“Narrow Waist”

Global NameResolution

Service

NetworkService A

(e.g. Privacy)

NetworkService B

(e.g. Location)….

Network services (socket calls)Include:- send (name, data)

- Send(name1..name n, data)- Get (content_name)-- send/get (context_ID, data)-- send (location, data)

GlobalRoutingService

Programmable Services API


Protocol Design: Name-Address Separation

Separation of names (ID) from network addressesGlobally unique name for each network end-point

User name, device ID, content, context, AS name, and so onMultiple domain-specific naming services

Fast resolution & update from name address(es)Alternative designs possible

Routing on flat name spaceFlat name space with indirection to hierarchical topological addresses

Globally Unique Flat Identifier (GID)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host NamingService

Network

SensorNamingService

ContentNamingService

Fast GID-Address Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB


Protocol Design: Global Name Resolution Service

Fast Global Name Resolution a central feature of architectureDistributed service hosted by routers

Multiple competing providers to avoid single root of trustFast updates ~50-100 ms to support dynamic mobility (..home agent optional)Service will scale to ~10B names via P2P/DHT techniques, Moore’s law

AP

Global Name-Address Resolution Service A

Data Plane

Service B(competing providers)

Host Name

Network – NA2

Network – NA1

Network Address 1

Registrationupdate

Mobile nodetrajectory

Initialregistration

Name, Context_ID or Content_ID Network Address

Host Name

Network Address 2

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


Protocol Design: Flat Name Routing Option

One option under consideration is a flat network identifier with a locally unique host identifier network address = net_ID.local_IDInterdomain routing based on flat network identifierSecurity through use of PKI-based self-certifying addresses (..similar to AIP)Some weaknesses: limited routing aggregation, no multi-homing, etc.

GID/ServiceHeader

Data Object

Name-GID Mapping

Flat Name Routing TableName GID

server@winlab Net123.localxyzDest GID Path

Net123 Net1, net2, ..

*MF Protocol Data Unit (PDU)for flat GID routing

GID/ServiceHeader

Data Object

Data Object

*Note1: MobilityFirst PDU contains the entire data objectranging from short message to large media file ~ GB

with hop-by-hop transport and storage (explained later)

*Note1: MobilityFirst PDU also contains a service definition fieldthat makes the PDU self-defining at each router in network. Thegeneral philosophy is to minimize per-packet/session/flow state at routers, and make basic services stateless.


Protocol Design: Hybrid Name/Address Routing Option

Another option under consideration is a hybrid scheme with support for both name (GID) and topological address (NA) routingNA header used for “fast” path, with fallback to GID resolution as neededAdditional level of indirection helps with router aggregation and supports more general name to address bindings e.g. dual-homing, content, geocast..

GID/ServiceHeader

Data Object

GID-Address Mapping

Routing Table

GID NA

12345.. xxyy, xxzz

GID/ServceHeader

Data Object

NA Header

Dest NA Path

xxyy Net1, net2, ..

Flat GID Routing(slow path)

Topological Address Routing(fast path)

Name-GID Mapping

Name GID

server@winlab Net123.localxyz GID/ServiceHeader

Data File

NA Header

Data Object PDU with name PDU with nameand address


Protocol Design: Storage Aware RoutingStorage aware (generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnectionRouting algorithm adapts seamlessly adapts from switching (good path) to store-and-forward (poor link BW/disconnected)Storage has benefits for wired networks as well..

Storage Router

Low BW cellular link

MobileDevicetrajectory

High BW WiFi link

TemporaryStorage atRouter

Initial Routing Path

Re-routed pathFor delivery

Sample CNF routing result

PDU


Protocol Design: Segmented TransportSegment-by-segment transport between routers with storage, in contrast to end-to-end TCP used todayUnit of transport (PDU) is a content file or max size fragmentHop TP provides improved throughput for time-varying wireless links, and also helps deal with disconnectionsAlso 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 #4TemporarilyStored PDU

BS

GID/Service Hdr

Mux Hdr

Net Address Hdr

Data Frag 1 Data

Frag 2Data Frag n

……

Hop-by-HopTransport

More details ofTP layer fragmentswith addl mux hdr


Protocol Design: Context Aware Services

Context-aware network services supported at two layers by MF architecture

Dynamic mapping of arbitrary context or content label by global name serviceSame mechanism used to handle named contentOptional software services implemented at the computing layer

MobileDevicetrajectory

context_ID = geo-coordinates & Rutgers_student

Send (context_iD, data_pkt)

Context-basedMulticast delivery

Dest_Name=Context_ID

Context Name Resolution service

xx yyaa bb


Protocol Design: Computing LayerProgrammable computing layer provides service flexibility and evolution/growth path

Routers include a virtual computing layer to support new network servicesPackets carry service tags and are directed to optional services where applicableProgramming API for service creation provided as integral part of architectureSupport for virtualization of services

...... ......

Packet forwarding/routing

Computing layer CPU Storage

Virtual ServiceProvider

ContentCaching

Privacyrouting

anony

anony


Protocol Design: Management Plane

Separate mgmt plane designed into MF architectureProvides interface for cross layer parameters, configuration, faults, etc.Useful for querying time-varying connectivity of mobile user/networkMechanism for detecting and controlling security problemsClient-assisted collection of management dataDecentralized implementation of mgmt services via computing layer

AP

Control & Management

PlaneNet Mgmt Interface

(performance queries,

configuration, faults, security, ..)

Data Plane

Data packets

Concluding Remarks

MobilityFirst FIA Meeting Presentation Nov 15, 2010

Research Challenges, Hard Problems:Fast global fast name resolution service for ~10-100B end-pointsUnified support for mobile devices, context, location, content,… as an integral capability of the networkScalable routing protocol for flat name identifiers, taking into account unique mobility requirements (multi-homing, anycast, multicast, disconnection, location-awareness, …)

Design of storage-aware routing algorithms which are robust to disconnection and bandwidth variation across wired & wireless netsTechniques for interdomain network aggregation applicable to name-based and storage-aware routing under consideration

Integrating security and privacy features into network services – self-certification, multiple roots of trust, Byzantine fault-tolerance, …Design of network management plane features to achieve a high level of transparency and accountabilityNetwork neutrality, economic feasibility, …Evaluation & validation at scale!

Website: winlab.mobiltyfirst.rutgers.edu


Concluding Remarks:The team is truly excited about the prospect of designing, building and deploying a comprehensive Internet architecture We believe our approach has a number of novel components and is unique in its focus on mobility and future pervasive computing needsSome of the key building blocks of the MobilityFirst architecture are:

Fast name resolution serviceFlat identifier (or hybrid) routing with self-certifying ID’sStorage-aware routing (GDTN) and hop-by-hop transportSupport for advanced context, content and mobility servicesProgrammable computing layer for future in-network services

The project is still at an early stage and the design is expected to evolve over the next 9-12 months – watch for future updates!Outcomes of the project include architectural evaluation, dissemination to related Internet & mobile network communities, laboratory prototyping and real-world evaluations using GENI

Website: winlab.mobiltyfirst.rutgers.edu

Backup Slides:Prototyping Plan


Prototyping Plan: Phased ApproachMultiple stages of prototyping leading up to a full MobilityFirst protocol deployment by year 3 of the project

Prototyping of key protocol components for validation and measurement Early proof-of-concept, small-scale lab prototypes for controlled experiments Multi-site network, medium scale prototype for internetwork experiments Deployment of the MobilityFirst protocol as a stable, long-running VN on GENI campus networks for application trials with real opt-in users and evaluation of usability, trust

IndividualPrototypingOf KeyComponents

Small-scaleLab prototypeFor controlledExperiments

Multi-site Medium scalePrototype forInternetworkingValidation

MobilityFirstProtocolDeployment onGENI NetworkFor ApplicationTrials

Significant leverage/technical risk reduction from earlier protocol research projects at collaborating institutions, e.g. CNF at Rutgers, Hop TP at UMass/Amherst, Wireless net mgmt – Wisconsin and UMich; Internetwork routing – UMich; Android platform- UMass/Lowell

Year 1 Year 1,2 Year 2 Year 3


TP‐1TP‐1 TP‐2TP‐2

Network Layer

LL‐1 LL‐2

ComputingLayer forServices

LL‐3

Forwarding &

StorageEngine

NameResolutionService

ContentStorage

RoutingProtocol

RouterMemory

API‐1 API‐2

Compute API

ManagementPlane

Prototyping Plan: Router Software Implementation

Core router software implemented on Linux OSPortable to various networking platforms including Open BS, WiFi, Click and OpenFlowDistributed implementation (Naming Service – UMass; Routing/TP – Rutgers; Management – Wisconsin; Compute Layer – Duke) with integration at Rutgers

Click orOpenFlowRouter

Open BaseStation

Open AP


Prototyping Plan: Client Software

Linux and Android mobile implementation for clientsApplication repository including mobile social networking, content delivery and context-aware messaging

WiMax + WiFi Android Client

Also Linux PC/laptopClients with WiMAX and WiFI


Prototyping Plan: Experimental Platforms & Testbeds – ORBIT/GENI Testbed at Rutgers

ORBIT radio grid for reproducible evaluation at scaleOutdoor wireless network with open WiMAX BS, open AP and vehicular nodes for real world mobility experimentsTestbed connected to GENI backbone via L2 fiber (I2 PoP at Phila)

WiMAXOpen BS

VehicularNode

ORBIT Radio Grid ORBIT Radio Grid


Prototyping Plan: GENI/OpenFlow Campus Network at Rutgers

Outdoor ORBIT

GENI Open Base Station

(WiMax)Outdoor RU

Wireless

3.) Rutgers Outdoor Network

To MEGPI PoP(Philadelphia)

Rutgers Core Network

L3 -> L2

2.) ORBIT Grid

L2

Cook Campus

Busch Campus

AR

L2

OpenFlowEnabled Switch

OpenFlowEnabled Router

ARAccess Router(not OF)

LEGEND:

1.) SB9Outdoor ORBIT

GENI Open Base Station

(WiMax)Outdoor RU

Wireless

3.) Rutgers Outdoor Network

NetFPGA

NetFPGA

IP8800 IP8800

IP8800IP8800

GENI campus network with WiFi, WiMAX and OpenFlow to be used forinitial system level evaluations at Rutgers


Prototyping Plan: Outdoor Wireless Networks at UMass and Wisconsin

Madison Metro Transit city-buses thatinteract with WiFi mesh, WiMAX, and

3G cellular (60 sq. miles)

GPRS1

WLAN

EvDOWiMAX

WiFi

Mt. Toby

MA1

CSB

10.6 Km

Topology of the MA OTG testbed

Weather Observatory NetworkAt UMass

Dieselnet TestbedAt UMass

Additional campus networks at UMass, Wisconsin to be used for multi-site evaluation during second phase of prototyping

UMass and Wisconsin equipped with both WiMAX and WiFi (GENI Spiral 2)

Additional GENI campus site with WiMax planned for UMich under GENI Spiral 3


GENI Spiral 1 connectivity (figure courtesy of GPO at BBN Technologies)

Wisconsin

UMass

Rutgers

DukeTo GENI/I2Backbone

Open WiMAX/3GBase Station

End-user Android mobilePhones or Linux netbooks

with WiMax and WiFi

CampusTestbed

OpenFlow+ Blade ServerRouter Platform

Typical campusNetwork

MFA ClientSoftware

MFA Router Software

Campus sites

Prototyping Plan: Experimental Platforms & Testbeds – Multi-site GENI NetworkMulti-site GENI campus networks used for real-world evaluation of MF protocol during final stage of evaluation in year 3Involves realistic applications and opt-in users with both Linux PC’s or Android mobile devicesMF protocol as a long-running “slice” on GENI network

MobilityFirst: A Robust and Trustworthy Mobility-Centric ...€¦ · MobilityFirst FIA Team...

Documents

Transcript of MobilityFirst: A Robust and Trustworthy Mobility-Centric ...€¦ · MobilityFirst FIA Team...