MobilityFirst : A Robust and Trustworthy Mobility-Centric - - PowerPoint PPT Presentation

MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet NSF FIA Meeting Nov 15-16, 2010

Contact: D. Raychaudhuri ray@winlab.rutgers.edu

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. Lehr
• Z. Morley Mao
• B. Ramamurthy
• G. Chen
• X. Yang, R. RoyChowdhury
• A. Venkataramani, J. Kurose, D. Towsley
• M. Reiter

MobilityFirst Vision

MobilityFirst FIA Team Presentation

Nov 15, 2010

INTERNET INTERNET

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 2010 Mobile data growing exponentially – Cisco white paper predicts >1exabyte

per month (surpassing wired PC traffic) by 2012

Sensor deployment just starting, ~5-10B units by 2020

Wireless Edge Network Wireless Edge Network

INTERNET INTERNET

~1B server/PC’s, ~700M smart phones ~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors

~2010 ~2020

Wireless Edge Network Wireless Edge Network

MobilityFirst FIA Team Presentation

Nov 15, 2010

INTERNET INTERNET

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 networks Even more complicated with multiple radio access systems Lack 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

MobilityFirst FIA Team Presentation

Nov 15, 2010

Vision: Near-term “mobile Internet” usage scenario – Mobile P2P and Infostations

P2P and Infostations (DTN-like) modes for content delivery

becoming mainstream

Heterogeneous access; network may be disconnected at times Involves both terminal and router mobility; dynamic trust establishment Requires content caching and opportunistic data delivery Mobile DTN Router

Roadway Sensors Mobile DTN User/Router

Ad-Hoc Network Opportunistic High-Speed Link (MB/s)

Mobile P2P User Infostations Router

MOBILE INTERNET MOBILE INTERNET

MobilityFirst FIA Team Presentation

Nov 15, 2010

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

100’s of million cars will be equipped with radios by ~2015

Both V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) modes Involves capabilities such as location services, georouting, reliable multicast Important 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

MobilityFirst FIA Team Presentation

Nov 15, 2010

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 resources

Challenges - flexible network computing model, security and robustness

Vehicles with Sensors & Wireless Healthcare Application Robotics Application

Network Connectivity & Computation

“Human in the Loop” To Actuators Virtualized physical world object Content & Location Aware Routers Computation & Storage Protocol module Ambient interfaces

Global Pervasive Network (Future Internet)

Data From Sensors Smart Grids “Cloud” Applications

MobilityFirst FIA Team Presentation

Nov 15, 2010

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 devices Mobility as the norm for end-points and access networks Wireless access – varying link BW/quality, multiple radios, disconnections Stronger security/trust requirements due to:

• pen radio medium

need 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

MobilityFirst FIA Team Presentation

Nov 15, 2010

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 scale
• Intrinsic properties of wireless medium
• More stringent security/trust requirements
• Special needs of emerging mobile applications

Fixed internet access is treated as a special case of the more general design Although the “sweet spot” of our protocol is wireless/mobile, we believe that

• ur design provides important benefits to fixed network applications
• Security/trust
• Robustness
• Fault tolerance
• Context/content

Architecture Overview

MobilityFirst FIA Team Presentation

Nov 15, 2010

Architecture: MobilityFirst Network Overview

Base Station

Core Network (flat label routing) Router Global Name Resolution Service Control & Management Plane Computing Blade Buffer Storage Forwarding Engine MobilityFirst Router with Integrated Computing & Storage Hop-by-Hop Transport GDTN Routing Name <-> PKI address mapping Data block Data Plane

MobilityFirst key protocol

features:

• Fast global naming service
• Self-certifying public key names
• Dynamic mapping of name to

topological network address(es)

• Routers support both flat name

and hierarchical address routing

• Storage-aware (generalized DTN)

routing in access

• Hop-by-hop (segmented) transport
• Programmable computing layer
• Support for

content/context/location

• Separate 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

MobilityFirst FIA Team Presentation

Nov 15, 2010

Architecture: MobilityFirst Protocol Stack

Core elements of protocol stack (“narrow waist)

Global Name Resolution & Routing Services Storage-aware routing (GDTN) protocol Hop-by-hop (segmented) transport Services 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 Management Protocol

Storage Aware Routing (GDTN) Hop-by-Hop In-Network Transport

E2E Transport Protocol 1 E2E Transport Protocol 2 M-Socket D-Socket D-Socket M-APP APP-1 APP-n

“Narrow Waist”

Global Name Resolution Service Network Service A (e.g. Privacy) Network Service 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)

Global Routing Service Programmable Services API

MobilityFirst FIA Team Presentation

Nov 15, 2010

Protocol Design: Name-Address Separation

Separation of names (ID)

from network addresses

Globally unique name for

each network end-point

User name, device ID, content,

context, AS name, and so on

Multiple domain-specific naming

services Fast resolution & update from

name address(es)

Alternative designs possible

Routing on flat name space Flat 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 Naming Service Network Sensor Naming Service Content Naming Service

Fast GID-Address Resolution Service

Network address Net1.local_ID Net2.local_ID Context Naming Service Taxis in NB

MobilityFirst FIA Team Presentation

Nov 15, 2010

Protocol Design: Global Name Resolution Service

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

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

Global Name-Address Resolution Service A Data Plane Service B (competing providers)

Host Name

Network – NA2 Network – NA1

Network Address 1 Registration update Mobile node trajectory Initial registration

Name, Context_ID or Content_ID Network Address

Host Name Network Address 2 Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network

MobilityFirst FIA Team Presentation

Nov 15, 2010

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_ID

• Interdomain routing based on flat network identifier
• Security through use of PKI-based self-certifying addresses (..similar to AIP)
• Some weaknesses: limited routing aggregation, no multi-homing, etc.

GID/Service Header Data Object Name-GID Mapping Flat Name Routing Table Name GID server@winlab Net123.localxyz Dest GID Path Net123 Net1, net2, .. *MF Protocol Data Unit (PDU) for flat GID routing GID/Service Header Data Object Data Object *Note1: MobilityFirst PDU contains the entire data object ranging 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 field that makes the PDU self-defining at each router in network. The general philosophy is to minimize per-packet/session/flow state at routers, and make basic services stateless.

MobilityFirst FIA Team Presentation

Nov 15, 2010

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) routing

• NA header used for “fast” path, with fallback to GID resolution as needed
• Additional level of indirection helps with router aggregation and supports more

general name to address bindings e.g. dual-homing, content, geocast..

GID/Service Header Data Object GID-Address Mapping Routing Table GID NA 12345.. xxyy, xxzz GID/Servce Header 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/Service Header Data File NA Header Data Object PDU with name PDU with name and address

MobilityFirst FIA Team Presentation

Nov 15, 2010

Protocol Design: Storage Aware Routing

Storage aware (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/disconnected)

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

MobilityFirst FIA Team Presentation

Nov 15, 2010

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.

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 hdr

MobilityFirst FIA Team Presentation

Nov 15, 2010

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 service Same mechanism used to handle named content Optional software services implemented at the computing layer

Mobile Device trajectory

context_ID = geo-coordinates & Rutgers_student Send (context_iD, data_pkt)

Context-based Multicast delivery Dest_Name =Context_ID Context Name Resolution service xx yy aa bb

MobilityFirst FIA Team Presentation

Nov 15, 2010

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 Support for virtualization of services

...... ...... Packet forwarding/routing Computing layer

CPU

Storage

Virtual Service Provider

Content Caching Privacy routing

anon y anon y

MobilityFirst FIA Team Presentation

Nov 15, 2010

Protocol Design: Management Plane

Separate mgmt plane designed into MF architecture

Provides interface for cross layer parameters, configuration, faults, etc. Useful for querying time-varying connectivity of mobile user/network Mechanism for detecting and controlling security problems Client-assisted collection of management data Decentralized implementation of mgmt services via computing layer

Control & Management Plane

Net 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-points Unified support for mobile devices, context, location, content,… as

an integral capability of the network

Scalable 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 nets

• Techniques 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 accountability

Network neutrality, economic feasibility, … Evaluation & validation at scale!

Website: winlab.mobiltyfirst.rutgers.edu

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

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 needs

Some of the key building blocks of the MobilityFirst architecture are:

• Fast name resolution service
• Flat identifier (or hybrid) routing with self-certifying ID’s
• Storage-aware routing (GDTN) and hop-by-hop transport
• Support for advanced context, content and mobility services
• Programmable 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

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

Prototyping Plan: Phased Approach

Multiple 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

Individual Prototyping Of Key Components Small-scale Lab prototype For controlled Experiments Multi-site Medium scale Prototype for Internetworking Validation MobilityFirst Protocol Deployment on GENI Network For Application Trials 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

MobilityFirst FIA Meeting Presentation

Nov 15, 2010 TP‐1 TP‐1 TP‐2 TP‐2

Network Layer

LL‐1 LL‐2 Computing Layer for Services LL‐3 Forwarding & Storage Engine Name Resolution Service Content Storage Routing Protocol Router Memory API‐1 API‐2 Compute API Management Plane

Prototyping Plan: Router Software Implementation

Core router software implemented on Linux OS

Portable to various networking platforms including Open BS, WiFi, Click and OpenFlow Distributed implementation (Naming Service – UMass; Routing/TP – Rutgers;

Management – Wisconsin; Compute Layer – Duke) with integration at Rutgers

Click or OpenFlow Router Open Base Station Open AP

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

Prototyping Plan: Client Software

Linux and Android mobile implementation for clients Application repository including mobile social networking,

content delivery and context-aware messaging

WiMax + WiFi Android Client Also Linux PC/laptop Clients with WiMAX and WiFI

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

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

ORBIT radio grid for reproducible evaluation at scale Outdoor wireless network with open WiMAX BS, open AP and

vehicular nodes for real world mobility experiments

Testbed connected to GENI backbone via L2 fiber (I2 PoP at Phila)

WiMAX Open BS Vehicular Node ORBIT Radio Grid ORBIT Radio Grid

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

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 OpenFlow Enabled Switch OpenFlow Enabled Router

AR

Access Router (not OF) LEGEND:

1.) SB9

Outdoor ORBIT GENI Open Base Station (WiMax) Outdoor RU Wireless

3.) Rutgers Outdoor Network

NetFPGA NetFPGA IP8800 IP8800 IP8800 IP8800

GENI campus network with WiFi, WiMAX and OpenFlow to be used for

initial system level evaluations at Rutgers

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

Prototyping Plan: Outdoor Wireless Networks at UMass and Wisconsin

Madison Metro Transit city-buses that interact with WiFi mesh, WiMAX, and 3G cellular (60 sq. miles)

G P R S 1

WLAN

EvDO

WiMAX

WiFi

• Mt. Toby

MA1 CSB 10.6 Km

Topology of the MA OTG testbed

Weather Observatory Network At UMass Dieselnet Testbed At 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

MobilityFirst FIA Meeting Presentation

Nov 15, 2010

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

Wisconsin UMass Rutgers Duke To GENI/I2 Backbone

Open WiMAX/3G Base Station

End-user Android mobile Phones or Linux netbooks with WiMax and WiFi Campus Testbed OpenFlow + Blade Server Router Platform Typical campus Network MFA Client Software MFA Router Software Campus sites

Prototyping Plan: Experimental Platforms & Testbeds – Multi-site GENI Network

Multi-site GENI campus networks used for real-world evaluation of MF

protocol during final stage of evaluation in year 3

Involves realistic applications and opt-in users with both Linux PC’s or

Android mobile devices

MF protocol as a long-running “slice” on GENI network