mobilityfirst: a robust and: a robust and trustworthy...

9/13/2010

1

MobilityFirst: A Robust andMobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future InternetNSF FIA Project Summary

MobilityFirst Project Team

Contact: D. Raychaudhuri

[email protected]

MobilityFirst Project TeamSeptember 2010

MobilityFirst Project: Collaborating Institutions

(LEAD)

MobilityFirst FIA Overview Slides Sept, 2010

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

9/13/2010

2

Vision: Mobility as the key driver for the future Internet

Historic shift from PC’s to mobile computing and embedded devices… 4 B ll h 1B I t t t d PC’ i 2010 ~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

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

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

WirelessEdge


INTERNET

WirelessEdge Network

INTERNET

~2010~2020

NetworkEdge Network

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 )

INTERNET

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 MOBILE


Cellular –Internet

GW

Internet GW

MOBILE INTERNET

Cellular system A

Cellular system B

Radio Access Net A

Radio Access B

Radio Access C

9/13/2010

3

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

MOBILE INTERNET


Roadway Sensors

Mobile DTN User/Router

Ad-HocNetwork

OpportunisticHigh-Speed Link(MB/s)

Mobile P2P User

InfostationsRouter

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

V2I


Passing vehicle,in radio range for seconds

Following vehicle,in radio range for minutes

V2V

9/13/2010

4

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.g g g , g ,

Networking requires awareness of location and context, along with embedded computational resources

Challenges - flexible network computing model, security and robustness

“Human in the Loop”

Ambient interfaces

Global Pervasive Network(Future Internet)

“Cloud” Applications


Vehicles with Sensors & Wireless

HealthcareApplication

Robotics Application

Network Connectivity& Computation

To Actuators

Virtualized physicalworld object

Content & LocationAware Routers

Computation& StorageProtocol

module

(Future Internet)

DataFromSensors

Smart Grids

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: open radio medium

need for dynamic trust association for mobile devices/users,

increased privacy concerns (e.g. location tracking)

greater potential for network failure

M bil li ti i l l ti / t t/ t t d t i t


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

9/13/2010

5

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


Although the sweet spot of our protocol is wireless/mobile, we believe that our design provides important benefits to fixed network applications Security/trust

Robustness

Fault tolerance

Context/content

Architecture: MobilityFirst Network Overview

Computing BladeBuffer Storage

MobilityFirst

MobilityFirst key protocol features: Fast global naming service

Base Station

Wireless Router

AP

Core Network(flat label routing)

Router

Global Name Resolution Service

Buffer StorageForwarding Engine

Router withIntegrated

Computing & Storage

Hop-by-HopTransport

GDTN Routing

Data blockDataPlane

g g Self-certifying public key

addresses Flat label addressing in core Storage-aware (generalized

DTN) routing in access Hop-by-hop (segmented)

transport Programmable computing layer Support for

content/context/locationS t t k t l

MobilityFirst FIA Team Presentation July 9, 2010

Resolution Service

Control & Management Plane

Name <-> PKI address mapping

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

9/13/2010

6

Architecture: Design Goals

1. Host + network mobility

2 No global root of trust2. No global root of trust

3. Intentional data receipt

4. Byzantine robustness

5. Content addressability

6. Evolvable network


The above goals G1-G6 are not met by today’s IP network

Architecture: Additional Design Principles

1. Visibility and choice

2 Usability2. Usability

3. Manageability

4. Simplicity

5. Regulability

6. Commercializability


y

7. Technology-awareness

9/13/2010

7

Architecture: MobilityFirst Protocol Stack

Core elements of protocol stack (“narrow waist) Global Name Resolution Service

Storage-aware routing (GDTN)

Hop by hop (segmented) transport Hop-by-hop (segmented) transport

Services and management API’s

Multiple TP and link layer options + programmable services

E2ETransport

E2ETransport

M-Socket

D-Socket D-Socket

M-APP

APP-1 APP-n

Global NameResolution

Service

NetworkService A

(e.g. Privacy)

NetworkService B

(e.g. Location)

….

Network ssrvices (socket calls)Include:- send (name, data)- Send(name1..name n, data)- Get (content_name)

send/get (context ID data)


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

Protocol 1 Protocol 2

“Narrow Waist”

-- send/get (context_ID, data)-- send (location, data)

Services API

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

Data Plane

Network – NA1

Registrationupdate

Mobile nodetrajectory

Host Name

NA1.local_ID


AP

Global Name Resolution Service A

Service B(competing providers)

Host Name

Network – NA2

NA2.local_ID

Initialregistration

Name, Context_ID or Content_ID Network Address

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

9/13/2010

8

Protocol Design: Public Key Addressing

Public keys used for all host and network addresses

Strong authentication for every host access to network

All network elements are self-certifyingy g

Addressing Network Address (NA)

Host Address (HA)

Local identifier string P within NA

For multi-homing, one HA maps to multiple NA’s HA


HANA

PNA

Signed by HAHANA

or

Signed by HA&NA

PNA

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)(good path) to store-and-forward (poor link BW/disconnected)

Storage has benefits for wired networks as well..

Low BW cellular link

TemporaryStorage atRouter

Initial Routing Path


Storage Router

MobileDevicetrajectory

High BW WiFi link

Re-routed pathFor delivery

Sample CNF routing result

9/13/2010

9

Protocol Design: Interdomain Routing

Flat label interdomain 1 B 3 hab

routing Use of public key based self-

certifying flat network address

Locally assigned host address for one level of routing aggregation

Packet with destination address NA,HA forwarded to any NA gateway

naa

nab

NA Gateway

NA Gateway

NCS

1.B2.hab

Location Service

3.hab4.nab,hab

NA Gateway

A (haa)

5.data


gateway

Large interdomain routing tables feasible with today’s technology

Device A (NA=naa, HA=haa) initiates communication with Device B (NA=nab, HA=hab)

B (hab)

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 fragmentUnit 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.

Segmented (Hop-by-Hop TP)Data File (PDU)

Hop #3 BS


Storage Router

Low BW cellular link

Optical Router

(no storage)

Hop #1 Hop #2

Hop #4

TemporarilyStored PDU

9/13/2010

10

Protocol Design: Network Mobility

Network mobility can be handled through “mobile ISP” approach with suppressed routing updates at provider

Provider ASPeer AS

Customer AS

Customer link

Peering

link

Provider link

Customer linkCreate an entry for MP in Routing table

Suppress routing updates at common provider


MP updates do not propagate to customers or non-tier1 peers

MISP 1MISP 1

Mobile NetworkIbus, airplane,..)

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

Context-basedMulticast delivery

Dest_Name=Context_ID

Global Name Resolution service

xx yyaa bb


MobileDevicetrajectory

context_ID = geo-coordinates & Rutgers_student

Send (context_iD, data_pkt)

9/13/2010

11

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

Virtual ServiceProvider

ContentCaching

Privacyrouting


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

Packet forwarding/routing

Computing layer CPUStorage

anony anony

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


AP

Control & Management

PlaneNet Mgmt Interface

(performance queries,

configuration, faults, security, ..)

Data Plane

Data packets

9/13/2010

12

1. Public keys addresses for hosts & networks; forms basis for Ensuring accountability of traffic

Ubiquitous access-control infrastructure

Protocol Design: Security Principles

Ubiquitous access control infrastructure

Robust routing protocols

Preventing address hijacking

2. Support deployment of policies that constrain the traffic that a network or node receives In the limit, a “default-disconnected” posture

3. No globally trusted root for naming or addressing Opens naming to innovation to combat naming-related abuses


Opens naming to innovation to combat naming related abuses

Removes obstacles to adoption of secure routing protocols

4. Systematically consider Trusted Computing Base of designs Promote TCB reduction technologies (e.g., Byzantine fault tolerance)

Protocol Design: Privacy

1. Public keys as addresses enables their use as pseudonyms1. Public keys as addresses enables their use as pseudonyms Can be changed frequently by end-users to interfere with profiling

Flat-label PKI addresses provide an additional layer of routing privacy

2. Openness in naming & addressing introduces competition on grounds of privacy E.g., enable retrieval of mappings in a privacy-preserving way

3. Virtual service provider framework can optionally provide enhanced support for privacy


enhanced support for privacy E.g., constant-rate traffic between routers to defeat traffic analysis

4. Route transparency and selection supports user choice on privacy grounds

9/13/2010

13

Contact Information & Links

Project PI: Prof. D. Raychaudhuri, WINLAB, Rutgers University,Project PI: Prof. D. Raychaudhuri, WINLAB, Rutgers University, [email protected]

Associate project manager: Prof. Arun Venkataramani, CS Dept, UMass-Amherst, [email protected]

Project Website: mobilityfirst.winlab.rutgers.edu


mobilityfirst: a robust and: a robust and trustworthy...

Documents