9/13/2010 1 MobilityFirst: A Robust and MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet NSF FIA Project Summary MobilityFirst Project Team Contact: D. Raychaudhuri [email protected]MobilityFirst Project Team September 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
13
Embed
MobilityFirst: A Robust and: A Robust and Trustworthy ...mobilityfirst.winlab.rutgers.edu/documents/... · 9/13/2010 2 Vision: Mobility as the key driver for the future Internet Historic
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
9/13/2010
1
MobilityFirst: A Robust andMobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future InternetNSF FIA Project Summary
+ 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
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
MobilityFirst FIA Overview Slides Sept, 2010
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
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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,
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Team Presentation July 9, 2010
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
MobilityFirst FIA Team Presentation July 9, 2010
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)
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
...... ......
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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
MobilityFirst FIA Overview Slides Sept, 2010
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]