Mobilityfirst high level architectural updates
Download
1 / 29

MobilityFirst : High-level Architectural Updates - PowerPoint PPT Presentation


  • 145 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 Internetwork

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 Internetworkgoals

  • 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 t Internetworkraditional 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 Internetwork

Locality-aware

Load-aware


Auspice resolver placement engine
Auspice resolver placement engine Internetwork

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

Paxos

Paxos

create_replica(.)

shutdown_replica(.)

migrate_replica(.)

report_load(.)

Sequential consistency

Lineariazability

America

Europe

Asia

Paxos

Paxos


Auspice implementation evaluation
Auspice implementation & evaluation Internetwork

  • 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: InternetworkEmergency geo-cast

  • Demo by Emmanuel Cecchet

    • http://www.youtube.com/watch?v=tTmOArfXSsw


Questions
Questions? Internetwork

  • http://www.cs.umass.edu/~arun/MobilityFirst


ad