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
Architectural Challenges and Initial Approaches
Location Service
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
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
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
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
Routing
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
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
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
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
Security
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.
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
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
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
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
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
Conclusions/Questions
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