Presentation is loading. Please wait.

Presentation is loading. Please wait.

MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Concept Summary – Oct 2011 Contact: D. Raychaudhuri WINLAB,

Similar presentations


Presentation on theme: "MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Concept Summary – Oct 2011 Contact: D. Raychaudhuri WINLAB,"— Presentation transcript:

1 MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Concept Summary – Oct 2011 Contact: D. Raychaudhuri WINLAB, Rutgers University Technology Centre of NJ 671 Route 1, North Brunswick, NJ 08902, USA ray@winlab.rutgers.edu

2 WINLAB MobilityFirst Project: Collaborating Institutions (LEAD) + Also industrial R&D collaborations with AT&T Labs, Bell Labs, NTT DoCoMo,, Toyota ITC, NEC, Ericsson and others D. Raychaudhuri, M. Gruteser, W. Trappe, R, Martin, Y. Zhang, I. Seskar, K. Nagaraja, S. Nelson S. Bannerjee W. Lehr Z. Morley Mao B. Ramamurthy G. Chen X. Yang, R. RoyChowdhury A. Venkataramani, J. Kurose, D. Towsley M. Reiter Project Funded by the US National Science Foundation (NSF) Under the Future Internet Architecture (FIA) Program, CISE

3 WINLAB 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 PC’s in 2010  Mobile data growing exponentially – Cisco white paper predicts 3.6 Exabytes by 2014, significantly exceeding wired Internet traffic  Sensor/IoT/V2V just starting, ~5-10B units by 2020 INTERNET Wireless Edge Network Wireless Edge Network INTERNET ~1B server/PC’s, ~700M smart phones ~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors ~2010 ~2020 Wireles s Edge Networ k Wireles s Edge Networ k

4 WINLAB 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/robustness requirements due to: open radio medium need for dynamic trust association for mobile devices/users/data/networks 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

5 WINLAB Architecture: MobilityFirst Network Overview Base Station Wireless Router AP 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 MF Arch designed to meet emerging mobile/wireless service requirements at scale Key MF protocol features:  Separation of naming & addressing  Public-key globally unique identifier (GUID) and flat network address (NA)  Storage-aware (GDTN) routing  Multicast, multipath, anycast services  Flexible inter-domain boundaries and aggregation level  Early binding/late binding options  Hop-by-hop (segmented) transport  Support for content & context  Strong security and privacy model  Separate mgmt & computing layers Several new protocol components, very distinct from today’s TCP/IP ….

6 WINLAB Architecture: MobilityFirst 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 … IP Abstraction: Virtual Link Dest Device Network Interface IP Addr=X Name= MAC Send(IP=X, data) Static MAC=X binding Dynamic GUID – NA bindings MF Abstraction: Network Object with multipath reachability NA=X1NA=X2 NA=X3 GUID=Y Network Attached Object Send(GUID=Y, data, options)..options for mpath & time delivery MF Abstraction: Network Object Group with broadcast reachability NA=X2 GUID1 GUID2 GUID3 Group GUID = Z Send(GUID=Z, data, options)..option for mcast delivery Broadcast Medium

7 WINLAB Architecture Concepts: Name-Address Separation Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects  User name, device ID, content, context, AS name, and so on  Multiple domain-specific naming services Global Name Resolution Service for GUID  NA mappings Hybrid GUID/NA approach  Both name/address headers in PDU  “Fast path” when NA is available  GUID resolution, late binding option Globally Unique Flat Identifier (GUID) 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 Global Name Resolution Service Network address Net1.local_ID Net2.local_ID Context Naming Service Taxis in NB

8 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 Distributed service, possibly hosted directly on routers  Fast updates ~50-100 ms to support dynamic mobility  Service can scale to ~10B names via P2P/DHT techniques, Moore’s law AP Global Name- Address Resolution Service Data Plane Host GUID Network – NA2 Network – NA1 NA1 Registration update Mobile node trajectory Initial registration Host Name, Context_ID or Content_ID Network Address Host GUID NA2 Decentralixed name services Hosted by subset of ~100,000+ Gatway routers in network

9 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) Internet Scale Simulation Results Using DIMES database

10 WINLAB 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 Connectivity WiredWireless Mesh / CellularMobile Ad-HocDTN 4G Core WiFi Architecture Concepts: MobilityFirst Routing Design Goals

11 Expands routing options  Store and/or replicate as feasible routing options  Enables “late binding” routing algorithms Hop-by-hop transport  Large blocks reliably transferred at link layer  Entire block can be stored or cached at each router Take advantage of cheap storage in the network (storage-aware routing) ~100MB, data in transit ~10GB, in-network storage ~1TB, content caching 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 Architecture Concepts: Exploiting In- Network Storage for Routing

12 WINLAB 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.. 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

13 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 avoid interpreting content semantics inside network Content Store #2 Content cache at mobile Operator’s network – NA99 User mobility Content Store #1 (owner) GUID=13247..99 GNRS query Returns list: NA99,31,22,43 NA22 NA31 NA99 NA29 NA43 Data fetch from NA99 Data fetch from NA43 GNRS Query Get (content_GUID)

14 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 Mobile Device trajectory Context = geo-coordinates & first_responder Send (context, data) Context-based Multicast delivery Context GUID Global Name Resolution service ba123 341x Context Naming Service NA1:P7, NA1:P9, NA2,P21,..

15 WINLAB Protocol Design: MF Stack 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 Link Layer A (e.g fiber) Link Layer B (e.g LTE) Link Layer C (e.g WiFi) Link Layer D (e.g Ethernet Routing Control Protocols GUID-to-Net Address Mapping E2E Transport Protocol B E2E Transport Protocol B Mgmt Apps APP-2 APP-n Hop-by-hop Block Transfer Protocol Management Plane Protocols (incl. routing) Storage-Aware Routing (GSTAR) GUID Service Layer Computing Layer Service Plug-ins GUID Services Control Protocols Name Certification Service A E2E Transport Protocol A APP-1 …….. Routing Apps

16 WINLAB Example 1: 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:PA’s per name Data Plane GUID & SID DATA Send data file to “Alice’s laptop” Net 1 Net 7 Current network addresses provided by GNRS; NA1:PA22 ; NA7:PA13 GUID/SID NA1:PA22; NA7:PA13 DATA GUID NA1:PA22; NA7:PA13 DATA Router bifurcates PDU to NA1 & NA7 (no GUID resolution needed) Dual-homed mobile device GUID NetAddr= NA7.PA13 DATA GUID NetAddr= NA1.PA22 DATA Alice’s laptop GUID = xxx

17 WINLAB Example 2: GUID/Address Routing Scenarios – Handling Disconnection Intermittent disconnection scenario below uses GUID based redirection (late binding) by router to new point of attachment Data Plane GUID/SID DATA GUID NetAddr= NA1.PA7 DATA Send data file to “Alice’s laptop” Mobility Trajectory Disconnected Region Net 1 Net 7 Current network address provided by GNRS; NA1 – network part; PA9 – port address GUID NetAddr= NA1.PA9 - Delivery failure DATA GUID DAT A PDU Stored in router - GUID resolution for redirection GUID NetAddr= NA7.PA3 Successful redelivery after connection DATA

18 WINLAB MobilityFirst Prototyping: Phased Approach Global Name Resolution Service (GNRS) Storage Aware Routing Context-Aware / Late-bind Routing Context Addressi ng Stack Content Addressi ng Stack Host/Device Addressing Stack Encoding/Certifying Layer Locator-X Routing (e.g., GUID-based) Evaluation Platform Prototyping Status Simulation/Emulation Emulation/Limited Testbed Standalone Components System Integration Testbed/‘Live’ Deployment Deployment ready

19 WINLAB OpenFLow Backbones OpenFlow WiMAX ShadowNet Internet 2 National Lambda Rail Legend MobilityFirst Prototyping: GENI Deployment Plan (Phase 3) Domain-1 Router Domain-2 Wireless Egde (4G & WiFI) Wireless Edge (4G & WiFI) Router Wireless Edge (4G & WiFI) Domain-3 Router Mapping onto GENI Infrastructure ProtoGENI nodes, OpenFlow switches, GENI Racks, WiMAX/outdoor ORBIT nodes, DieselNet bus, etc. Inter-domain mobility Intra-domain mobility 19 Deployment Target: Large scale, multi-site Mobility centric Realistic, live Full MF Stack at routers, BS, etc. Opt-in users Services

20 Edge networks NA-1, NA-2 connected to global core Each of NA-1, NA-2 are contained MF routing domains Each WiMAX BSS and WiFi AP is associated with a MF Router Node a is multi-homed within a network Node c is multi-homed across 2 networks 20 Android Client w/ WiMAX + WiFi Linux PC/laptop w/ WiMAX + WiFi WiMAX BSS WiFi AP MF Router Vehicular node w/ WiMAX Sensor node MF Sensor GW NA-1 NA-2 a b c d e MobilityFirst Prototype: Multi-Site GENI Demo (GEC12, ~4Q2011) GENI Core Campus Network (at Rutgers) Campus Network (at other GENI site)

21 WINLAB Resources Project website: http://mobilityfirst.rutgers.eduhttp://mobilityfirst.rutgers.edu GENI website: www.geni.netwww.geni.net “Emerging Wireless Technologies and the Future Mobile Internet”, Cambridge Press, 2011 – D. Raychaudhuri & M. Gerla (eds.)


Download ppt "MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Concept Summary – Oct 2011 Contact: D. Raychaudhuri WINLAB,"

Similar presentations


Ads by Google