1 / 20

Architectural Challenges and Initial Approaches

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 ].

fionn
Download Presentation

Architectural Challenges and Initial Approaches

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architectural Challenges and Initial Approaches

  2. Location Service

  3. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec Locate(Host) Data Name servers Host[NA:NA1] Host[NA:NA2] NA2 NA1 NA

  4. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec • Metrics: • Query/Update delay (<50ms) • Response staleness (<500ms) • Load balance • Fault tolerance Name servers

  5. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec • Design issues: • In-situ routing deflection (?) • Structured local scope IDs (?) • Authoritative name servers (?) • Network anycast to name servers Name servers API

  6. Location Service for Popular Content • Function: Resolve Content  [NA1:HA1, NA2:HA2,…] • Design issues: • Ensuring proximate content retrieval • Leveraging traffic enggflexibility • Storage-aware routing using opportunistic caching/retrieval Name servers API

  7. Routing

  8. Interdomain Routing: Design Decisions • 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 Bob Alice R5 R4 R6

  9. Interdomain Routing: Design Challenges R2 R3 R1 R5 R4 R6 • Store and update the loose source routes in a scalable and lightweight manner. • Supporting multiple interfaces • Each interface has an address. • Need to handle cases when interfaces change (e.g., the 3G unavailable). Bob Alice

  10. DT Routing: Robustness to Diversity • Goal: Protocol stack robust to diverse, changing network conditions Connectivity • 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

  11. E2E Routing: Enabling Path Diversity • 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 Management Plane ISP1 ISP2 path1, path2, path3 req_paths(…) ISP3

  12. Security

  13. Architecture: Design Goals • Host + network mobility • No global root of trust • Intentional data receipt • Byzantine robustness • Content addressability • Evolvable network The above goals G1-G6 are not met by today’sInternet.

  14. 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

  15. Security: Hijacking/Spoofing • Alice wants to talk to Bob Mapping Service 1. Bob’s name in human readable fmt 2. Bob’s ID & addr Routing Service 3. Send Alice’s handshake data signed by Alice’s ID To Bob’s address Alice Bob 6. Verify using Bob’s self-certifying ID 5. Send Bob’s handshake data signed by Bob’s ID To Alice’s address

  16. Security: No single point of subversion Goal: • Scalable Byzantine fault-tolerance (BFT) for naming, routing Approach: • 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

  17. Security: Intentional receipt for DDos Congestion policing feedback (2) (1) Ra Rb Hd Hs congested mon mon mon nop (3) (4) Policing Goal: Scalable fair resource allocationwithintentional data receipt Approach: Packets carry unspoofable congestion policing feedback Congested routers use pair-wise keys for congestion policing feedback Receivers use it as capability tokens Access routers police senders’ traffic to guarantee per-sender fairness without per-sender queues

  18. Research Agenda: Privacy Considerations Goal: Quantifiable privacy Privacy Mechanisms Lookup Service NA:HA NA:HA Allow Home Agent Redirection 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 Allow Host Pseudonyms Home Agent AS 1 AS 2 Hospital HA Pseudonyms Swap

  19. Conclusions/Questions

  20. Research Agenda: Scalable Routing • 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 NA1 NA3 NA4 NA1:NA3:HA4 ISP1 (NA1) ISP2 (NA2) Customer1 (NA3) Router with Storage Routing Table Customer2 (NA4) NA1:NA4:HA3 NA1:NA4:HA1 NA1:NA4:HA2

More Related