20
Architectural Challenges and Initial Approaches

Architectural Challenges and Initial Approaches

  • Upload
    fionn

  • View
    38

  • Download
    0

Embed Size (px)

DESCRIPTION

Architectural Challenges and Initial Approaches. Location Service. Location Service: Scalability to billions of mobiles. Function : Resolve Host  [NA1, NA 2 ,…] Scale : 10B devices, 100 networks/day  10M/sec. Locate(Host). Data. Name servers. Host [ NA : NA1 ]. Host [ NA : NA2 ]. - PowerPoint PPT Presentation

Citation preview

Page 1: Architectural Challenges and Initial Approaches

Architectural Challenges and Initial Approaches

Page 2: Architectural Challenges and Initial Approaches

Location Service

Page 3: Architectural Challenges and Initial Approaches

NA

Location Service: Scalability to billions of mobiles

Name servers

NA1 NA2

Host[NA:NA1]

Locate(Host)

Host[NA:NA2]

Data

Function: Resolve Host [NA1, NA2,…] Scale: 10B devices, 100 networks/day 10M/sec

Page 4: Architectural Challenges and Initial Approaches

Name servers

Metrics:1. Query/Update delay (<50ms)2. Response staleness (<500ms)3. Load balance4. Fault tolerance

Function: Resolve Host [NA1, NA2,…] Scale: 10B devices, 100 networks/day 10M/sec

Location Service: Scalability to billions of mobiles

Page 5: Architectural Challenges and Initial Approaches

Name servers

Design issues:1. In-situ routing deflection (?)2. Structured local scope IDs (?)3. Authoritative name servers (?) 4. Network anycast to name servers

Function: Resolve Host [NA1, NA2,…] Scale: 10B devices, 100 networks/day 10M/sec

API

Location Service: Scalability to billions of mobiles

Page 6: Architectural Challenges and Initial Approaches

Name servers

Design issues:1. Ensuring proximate content

retrieval 2. Leveraging traffic engg flexibility3. Storage-aware routing using

opportunistic caching/retrieval

Function: Resolve Content [NA1:HA1, NA2:HA2,…]

API

Location Service for Popular Content

Page 7: Architectural Challenges and Initial Approaches

Routing

Page 8: Architectural Challenges and Initial Approaches

Use traditional address scheme (i.e., today’s IP addresses)

Embed loose source route in the address Makes the routing infrastructure more scalable Mapping database should handle updates of the loose source routes

(notified by the routers) due to failure, traffic engineering, etc. Support multi-paths

Interdomain Routing: Design Decisions

AliceBob

R4

R5

R6

Page 9: Architectural Challenges and Initial Approaches

Interdomain Routing: Design Challenges

(1) Store and update the loose source routes in a scalable and lightweight manner.

(2) Supporting multiple interfaces• Each interface has an address.• Need to handle cases when interfaces change (e.g., the 3G unavailable).

AliceBob

R1R2 R3

R4

R5

R6

Page 10: Architectural Challenges and Initial Approaches

DT Routing: Robustness to Diversity

Well-connected (wired networks)

WiFi, Cellular, WiMax, LTE

Sparsely-connected

(Mobile DTNs)

Connectivity

Replication (Highly unpredictable

DTNs)

Best-path forwarding (Low

load)

Multipath forwarding (High

load)

Goal: Protocol stack robust to diverse, changing network conditions

Approach: Hop-by-hop transport with in-network storage when needed

Gracefully degrades with challenging network conditions Uncertainty-driven routing algorithms unifying storage & transmission

capabilities of the network

Page 11: Architectural Challenges and Initial Approaches

E2E Routing: Enabling Path Diversity

ISP1 ISP2

ISP3

req_paths(…)path1, path2,path3

Management Plane

Goal: Path diversity for Optimizing performance, cost,

power, security Improved mobile connectivity

with heterogeneous radio access Approach: Multipath

routing mechanisms Multi-homing support in routing Detour routers Randomized path “unchoking” Coordinated path rate controller Mobile trajectory prediction

Page 12: Architectural Challenges and Initial Approaches

Security

Page 13: Architectural Challenges and Initial Approaches

MobilityFirst FIA Team Presentation Nov 15, 2010

Architecture: Design Goals

1. Host + network mobility2. No global root of trust3. Intentional data receipt4. Byzantine robustness5. Content addressability6. Evolvable network

The above goals G1-G6 are not met by today’s Internet.

Page 14: Architectural Challenges and Initial Approaches

Security: Decentralizing Trust in Naming

Goal: No single root of trust

Approach: Multiple name service

providers (NSP) Many-to-many mapping

from namespaces to NSPs Quorum-based certification

Page 15: Architectural Challenges and Initial Approaches

Security: Hijacking/Spoofing

• Alice wants to talk to Bob

Mapping Service

Routing Service

Alice Bob

1. Bob’s n

ame

in human readable fm

t

2. Bob’s I

D & addr

3. Send Alice’shandshake datasigned by Alice’s IDTo Bob’s address

5. Send Bob’shandshake datasigned by Bob’s IDTo Alice’s address

6. Verify usingBob’s self-certifying ID

Page 16: Architectural Challenges and Initial Approaches

Security: No single point of subversion

Goal: Scalable Byzantine fault-tolerance

(BFT) for naming, routingApproach: Naming:

Fault-scalable BFT Throughput scales nearly linearly with

addition of new servers (prior work) Geographic scaling support

Routing Securable protocol design, eg, consensus

interdomain routing Integrate with naming and intradomain

routing

Page 17: Architectural Challenges and Initial Approaches

MobilityFirst FIA Team Presentation Nov 15, 2010

Security: Intentional receipt for DDos

nop

Congestion policing feedback

(1) mon

mon

HsHd

Ra

mon

Policing

(2)

(3)(4)

Rb

congested

Goal: Scalable fair resource allocation with intentional data receiptApproach:

Packets carry unspoofable congestion policing feedback1. Congested routers use pair-wise keys for congestion policing feedback2. Receivers use it as capability tokens3. Access routers police senders’ traffic to guarantee per-sender fairness without

per-sender queues

Page 18: Architectural Challenges and Initial Approaches

Research Agenda: Privacy Considerations

Privacy Mechanisms

AS 1 AS 2

Lookup Service

NA:HANA:HA

Hospital

Allow Host Pseudony

ms

HA Pseudonyms

Swap

HomeAgent

Allow HomeAgent

Redirection

Goal: Quantifiable privacy

Approach: Identifying privacy concerns:

Separate host identifiers allows linking traffic to specific devices

Self-certifying addresses reduce plausible deniability

Lookup service could enable geo-tracking by third parties

Page 19: Architectural Challenges and Initial Approaches

Conclusions/Questions

Page 20: Architectural Challenges and Initial Approaches

Research Agenda: Scalable Routing

Customer2(NA4)

ISP2(NA2)

ISP1(NA1)

Customer1(NA3)

NA1:NA4:HA2

NA1:NA4:HA3

NA1:NA4:HA1

NA1:NA3:HA4NA1NA3NA4

Routing

Table

Router withStorage

Goal: Scaling interdomain routing to ~1M Ases Storage-awareness Efficient integration with fiber

Approach: Routing table size scaling

Routing state partition within AS Structured local scope to hide

internal addresses Hierarchical routing to limit routing

state across ASes Storage-aware routing metrics and

policy routing Routing aggregation for fiber

switched core networks