mobilityfirst high level architectural updates
Download
Skip this Video
Download Presentation
MobilityFirst : High-level Architectural Updates

Loading in 2 Seconds...

play fullscreen
1 / 29

MobilityFirst : High-level Architectural Updates - PowerPoint PPT Presentation


  • 146 Views
  • Uploaded on

MobilityFirst : High-level Architectural Updates. Arun Venkataramani, Dipankar Raychaudhuri. From Design Goals to Current Architecture. Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability. Global name service.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' MobilityFirst : High-level Architectural Updates' - ardara


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
mobilityfirst high level architectural updates

MobilityFirst: High-level Architectural Updates

Arun Venkataramani, DipankarRaychaudhuri

from design goals to current architecture
From Design Goals to Current Architecture
  • Host + network mobility
  • No global root of trust
  • Intentional data receipt
  • Proportional robustness
  • Content-awareness
  • Evolvability

Global name service

Name certification

Name resolution

Content storage & retrieval

Context & M2M services

Service migration

Computing

layer

Segmented

transport

Inter-,intra-domain

routing

Management

plane

Key insight: Logically centralized global name service

enhances mobility, security, and network-layer functions

architecture global name service
Architecture: Global name service

Global name service

Name certification

human_readable_name GUID

Name resolution: Auspice, DMap

“Darleen Fisher’s phone”  1A348F76

Content storage & retrieval

self-certifying GUID = hash(public-key) permits bilateral authentication

Context & M2M services

Service migration

GUID flexibly identifies principals:

interface, device, person, group, service, network, etc.

architecture global name service1
Architecture: Global name service

GUID  NA

Global name service

Name certification

resolve(GUID)

Name resolution: Auspice, DMap

GUIDNA2

GUIDNA1

GUIDNA1

GUIDNA2

Content storage & retrieval

Context & M2M services

Service migration

data

NA1

NA2

global name service content retrieval
Global name service: Content retrieval

Global name service

Name certification

Name resolution: Auspice, DMap

Content storage & retrieval

Context & M2M services

Service migration

global name service content retrieval1
Global name service: Content retrieval
  • Content CGUID  [NA1, NA2, … ]
    • Opportunistic caching + request interception

GNRS

CGUID

CGUID

get(CGUID, NA1)

[NA1,NA2,…]

NA1

CGUID

CGUID

CGUID

NA2

CGUID

CGUID

get(CGUID)

global name service content retrieval2
Global name service: Content retrieval

Global name service

Name certification

Name resolution: Auspice, DMap

Content storage & retrieval

Context & M2M services

Service migration

i ndirection and grouping
Indirection and grouping
  • Indirection: D1  D2
  • Grouping: D  {D1, D2, …, Dk}

Indirection and grouping enable context-aware services,

content mobility, and group mobility

indirection grouping context awareness
Indirection+grouping: Context-awareness
  • GUID_cabi [T1, {“type””yellowcab”, “geo””Times Sq.”}]
  • At source: CAID {T1, T2, …, Tk} // terminal networks
  • At terminal n/w: CAID  {members(CAID) | Ti} // late binding

GNRS

CAID1members(CAID){T1, T2, …, Tk}

T1

send_data(CAID,T1)

CAID

{T1,T2,…,Tk}

T2

send_data(CAID,T2)

send_data(CAID,T3)

Tk

from design goals to current architecture1
From Design Goals to Current Architecture
  • Host + network mobility
  • No global root of trust
  • Intentional data receipt
  • Proportional robustness
  • Content-awareness
  • Evolvability

Global name service

Name certification

Name resolution

Content storage & retrieval

Context & M2M services

Service migration

Inter-,intra-domain

routing

Computing

layer

Segmented

transport

Management

plane

Key insight: Logically centralized global name service

enhances mobility, security, and network-layer functions

architecture scaling interdomain routing
Architecture: Scaling interdomain routing
  • Function: Route to [email protected]
  • Scale: Millions of NA’s  huge forwarding tables

send([email protected], data)

NA2

NA3

NA1

architecture scaling interdomain routing1
Architecture: Scaling interdomain routing
  • Few interdomain routing design efforts maturing
    • Vnode + pathlet routing + link-state + telescoping updates
    • Bloom routing
    • Core-edge routing with *-cast through name service
  • Function: Route to [email protected] scalably
  • Approach: Core and edge networks to reduce state

Global name service

GUID

[X2,T4]

T4

T5

T1

T2

T3

T6

GUID

X2,T4

data

X1

X2

X3

from design goals to current architecture2
From Design Goals to Current Architecture
  • Host + network mobility
  • No global root of trust
  • Intentional data receipt
  • Proportional robustness
  • Content-awareness
  • Evolvability

Global name service

Name certification

Name resolution

Content storage & retrieval

Context & M2M services

Service migration

Inter-,intra-domain

routing

Computing

layer

Segmented

transport

Management

plane

Key insight: Logically centralized global name service

enhances mobility, security, and network-layer functions

architecture c omputing layer

Virtual

Service

Provider

Content

Caching

Privacy

routing

CPU

Computing layer

Storage

Packet forwarding/routing

anon

anon

......

......

Architecture: Computing layer
  • Programmable computing layer enables service flexibility and evolvability
    • Routers support new network services off the critical path
    • Packets carry (optional) service tags for demuxing
    • Integration with “active” GUID resolution in global name service
from design goals to current architecture3
From Design Goals to Current Architecture
  • Host + network mobility
  • No global root of trust
  • Intentional data receipt
  • Proportional robustness
  • Content-awareness
  • Evolvability

Global name service

Name certification

Name resolution

Content storage & retrieval

Context & M2M services

Service migration

Inter-,intra-domain

routing

Computing

layer

Segmented

transport

Management

plane

Key insight: Logically centralized global name service

enhances mobility, security, and network-layer functions

from design goals to current architecture4
From Design Goals to Current Architecture
  • Host + network mobility
  • No global root of trust
  • Intentional data receipt
  • Proportional robustness
  • Content-awareness
  • Evolvability

Global name service

Name certification

Name resolution

Content storage & retrieval

Context & M2M services

Service migration

Inter-,intra-domain

routing

Computing

layer

Segmented

transport

Management

plane

Key insight: Logically centralized global name service

enhances mobility, security, and network-layer functions

architecture why logically centralized
Architecture: Why logically centralized?
  • Indirection-based
  • Logically centralized
  • Network-layer
auspice a global name service for a highly mobile internetwork

Auspice: A Global Name Service for a Highly Mobile Internetwork

Arun Venkataramani

(with Abhigyan Sharma, Xiaozheng Tie, David Westbrook, HardeepUppal, Emmanuel Cecchet)

University of Massachusetts Amherst

global name service as geo distributed key value store
Global name service as geo-distributed key-value store

Global name service

GUID: {

{NAs:[[X1,T1],[X2,T2],…},

{geoloc:[lat, long]},

{TE_prefs: [“prefer WiFi”,…]},

{ACL: {whitelist: […]}},

}

resolve(GUID,…)

value(s)

resolve(GUID,…)

value(s)

auspice design goals
Auspice design goals
  • Low response time: Replicas of each name’s resolver should be placed close to querying end-users
  • Low update cost: Number of resolver replicas should be limited to reduce replica consistency overhead
  • Load balance: Placement of replicas across all names should prevent load hotspots at any single site
  • Availability: Sufficient number of replicas so as to ensure availability amidst crash or malicious faults
  • Consistency: Each name resolver’s consistency requirements must be preserved
trade offs of t raditional approaches
Trade-offs of traditional approaches
  • Replicate everything everywhere:
    • + Low response times
    • - High update cost under mobility, load imbalance
  • Few primary replica plus edge caching:
    • + Low update bandwidth cost
    • - Consistency requirements may limit caching benefits
    • - Load balance vs. response time trade-offs
  • Consistent hashing with replication
    • + Good load balance
    • - High response times (randomization, locality at odds)
    • - Dynamic replication, consistency coordination, load balance
auspice resolver replica placement
Auspice resolver replica placement

Locality-aware

Load-aware

auspice resolver placement engine
Auspice resolver placement engine

X

X

Replicacontrollers

Mapping algorithm + Paxos to compute active replica locations

X

Migrate

replicas

Load reports

X

X

X

X

X

X

X

Active

replicas

Locality-aware,

load-aware,

consistent

First request for name X

Typical request for name X to nearby active replica

End-hosts or local name servers

auspice service migration in progress
Auspice service migration (in-progress)

Paxos

Paxos

create_replica(.)

shutdown_replica(.)

migrate_replica(.)

report_load(.)

Sequential consistency

Lineariazability

America

Europe

Asia

Paxos

Paxos

auspice implementation evaluation
Auspice implementation & evaluation
  • Implemented mostly in Java (~22K lines of code)
    • Supports mysql, MongoDB, Cassandra, in-memory store
    • HTTP API for request/responses
  • Flexible keys and values
    • [GUID, NA], [GUID, IP], [name, IP]
  • Near-beta version deployed on eight geo-distributed Amazon EC2 locations
    • Extensive evaluation on larger clusters and PlanetLab settings
  • Mobile socket library for seamless mid-session client and server migration
application scenario e mergency geo cast
Application scenario: Emergency geo-cast
  • Demo by Emmanuel Cecchet
    • http://www.youtube.com/watch?v=tTmOArfXSsw
questions
Questions?
  • http://www.cs.umass.edu/~arun/MobilityFirst
ad