Presentation is loading. Please wait.

Presentation is loading. Please wait.

15-849: Hot Topics in Networking Four Next Generation Architectures Srinivasan Seshan 1.

Similar presentations


Presentation on theme: "15-849: Hot Topics in Networking Four Next Generation Architectures Srinivasan Seshan 1."— Presentation transcript:

1 15-849: Hot Topics in Networking Four Next Generation Architectures Srinivasan Seshan 1

2 Key Questions How do these proposals differ in addressing similar problems? Routing Addressing Service interface Security Economics/Policy Mobility Naming 2

3 Key Questions What are the key hurdles for each project? Scalability Difficult scenarios/usage models Inherent complexity Handling real-world incentives/economics Evolution from current network 3

4 Key Questions Do you believe in basic motivations of each project? Do we really need a new Internet arch? If so, how do we deploy this? What about IPv6? 4

5 NSF Programs Stagnation 100x100  Clean Slate Design PlanetLab Overcoming the Internet Impasse through Virtualization  GENI FIND  FIA (aka FIND phase 2) Phase 1 – 50 “small” projects Phase 2 – 4 large “integrative” projects Named Data Networking MobilityFirst NEBULA eXpressive Internet Architecture 5

6 Named Data Networking In the beginning... –First applications strictly focused on host-to-host interprocess communication: Remote login, file transfer,... –Internet was built around this host-to-host model. –Architecture is well-suited for communication between pairs of stationary hosts.... while today –Vast majority of Internet usage is data retrieval and service access. –Users care about the content and are oblivious to location. They are often oblivious as to delivery time: Fetching headlines from CNN, videos from YouTube, TV from Tivo Accessing a bank account at 6

7 To the beginning... What if you could re-architect the way “bulk” data transfer applications worked HTTP FTP etc.... knowing what we know now? 7

8 Biggest content source Third largest ISP source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al. Level(3)Google Global Crossing Google… 8

9 : Textbook Internet 2009: Rise of the Hyper Giants source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al. 9

10 ISP What does the network look like… 10

11 ISP What should the network look like… 11

12 Communication vs. Distribution 12

13 CCN Model Packets say ‘what’ not ‘who’ (no src or dst) communication is to local peer(s) upstream performance is measurable memory makes loops impossible Data 13

14 Context Awareness? Like IP, CCN imposes no semantics on names. ‘Meaning’ comes from application, institution and global conventions: /parc.com/people/van/presentations/CCN /parc.com/people/van/calendar/freeTimeForMeet ing /thisRoom/projector /thisMeeting/documents /nearBy/available/parking /thisHouse/demandReduction/2KW 14

15 Signed by nytimes.com/web/george CCN Names/Security /nytimes.com/web/frontPage/v /s0/0x3fdc96a4... Signed by nytimes.com/web 0x1b signature key nytimes.com/web/george/desktop public key Signed by nytimes.com Per-packet signatures using public key Packet also contain link to public key 15

16 Names Route Interests FIB lookups are longest match (like IP prefix lookups) which helps guarantee log(n) state scaling for globally accessible data. Although CCN names are longer than IP identifiers, their explicit structure allows lookups as efficient as IP’s. Since nothing can loop, state can be approximate (e.g., bloom filters). 16

17 CCN node model 17

18 CCN node model get /parc.com/videos/WidgetA.mpg/ v3/s2 /parc.com/videos/WidgetA.mpg/v3/s2 0 P 18

19 Flow/Congestion Control One Interest pkt  one data packet All xfers are done hop-by-hop – so no need for congestion control Sequence numbers are part of the name space 19

20 What about connections/VoIP? Key challenge - rendezvous Need to support requesting ability to request content that has not yet been published E.g., route request to potential publishers, and have them create the desired content in response 20

21 21

22 Trust in NDN 22

23 MobilityFirst Fundamental change in design goals and assumptions ~10B+ mobile/wireless end-points as “first-class” Internet devices Mobility as the norm for end-points and access networks Wireless access – varying link BW/quality, multiple radios, disconnections Stronger security/trust requirements due to: open radio medium need for dynamic trust association for mobile devices/users increased privacy concerns (e.g. location tracking) greater potential for network failure Mobile applications involve location/content/context and energy constraints Technology has also changed a lot in the ~40 yrs since IP was designed Moore’s law improvements in computing and storage (~5-6 orders-of- magnitude gain in cost performance since 1970) Edge/core disparity, fast fiber but continuing shortage of radio spectrum 23

24 MobilityFirst Clean-slate protocol design that directly addresses the problems of mobility at scale, while also strengthening the trust model End-point and network mobility at scale Intrinsic properties of wireless medium More stringent security/trust requirements Special needs of emerging mobile applications Fixed internet access is treated as a special case of the more general design Although the “sweet spot” of our protocol is wireless/mobile, we believe that our design provides important benefits to fixed network applications Security/trust Robustness Fault tolerance Context/content 24

25 Goals 1.Host + network mobility 2.No global root of trust 3.Intentional data receipt 4.Byzantine robustness 5.Content addressability 6.Evolvable network 25

26 Additional Design Principles 1.Visibility and choice 2.Usability 3.Manageability 4.Simplicity 5.Regulability 6.Commercializability 7.Technology-awareness 26

27 MobilityFirst Architecture 27

28 Protocol Stack 28

29 Name-Address Separation 29

30 Name Resolution 30

31 Storage Aware Routing 31

32 Security 1. Public keys global identifiers for hosts & networks; forms basis for: Ensuring accountability of traffic Ubiquitous access-control infrastructure Robust routing protocols Preventing address hijacking 2. Support deployment of policies that constrain the traffic that a network or node receives In the limit, a “default-disconnected” posture 3. No single globally trusted root for naming or addressing Opens naming to innovation to combat naming-related abuses Removes obstacles to adoption of secure routing protocols 4. Systematically consider Trusted Computing Base of designs Promote TCB reduction technologies (e.g., Byzantine fault tolerance) 32

33 NEBULA NEBULA is an architecture for the cloud-based future Internet More secure and reliable Deployable and evolvable Truly clean slate Availability: At risk of network outages Security: Poor endpoint authentication HIPAA policy restrictions not expressible with existing routing protocols Consistency: Communications end--‐point focused, not data focused Cloud systems have embraced weak consistency (CAP Theorem) 33

34 Architecture 34

35 Network Security The “big I” Internet Is federated: Policies must be enforced across realms (e.g., DDoS) NEBULA addresses problems at right places: Extensibility+Policy: new control plane Policy Enforcement: new data plane Availability: high-performance, redundant- path core with high‐availability core routers 35

36 NDP 36

37 NEBULA Virtual and Extensible Network Techniques (NVENT) 37

38 NEBULA Core (NCore) 38

39 XIA Vision We envision a future Internet that: Is trustworthy Security broadly defined is the biggest challenge Supports long-term evolution of usage models Including host-host, content retrieval, services, … Supports long term technology evolution Not just for link technologies, but also for storage and computing capabilities in the network and end-points Allows all actors to operate effectively Despite differences in roles, goals and incentives 39

40 Today’s Internet Client retrieves document from a specific web server But client mostly cares about correctness of content, timeliness Specific server, file name, etc. are not of interest Transfer is between wrong principals What if the server fails? Optimizing transfer using local caches is hard Need to use application-specific overlay or transparent proxy – bad! Src: Client IP Dest: Server IP Client IP Server IP TCP 40

41 eXpressive Internet Architecture Client expresses communication intent for content explicitly Network uses content identifier to retrieve content from appropriate location How does client know the content is correct? Intrinsic security! Verify content using self-certifying id: hash(content) = content id How does source know it is talking to the right client? Intrinsic security! Self-certifying host identifiers Src: Client ID Dest: Content ID PDA Content 41

42 A Bit More Detail … Hash( ) = CID? Anywhere Dest: Client ID Content ID Dest: Service ID Content Name? Dest: Content ID Flexible Trust Management Diverse Communicating Entities Intrinsic Security XIA Transformational Ideas 42

43 P1: Evolvable Set of Principals Identifying the intended communicating entities reduces complexity and overhead No need to force all communication at a lower level (hosts), as in today’s Internet Allows the network to evolve 43 Host Content Services Future Entities a581fe9... d9389fa … 024e881 … 39c0348 …

44 P2: Security as Intrinsic as Possible Security properties are a direct result of the design of the system Do not rely on correctness of external configurations, actions, data bases Malicious actions can be easily identified 44 Host Content Services Future Entities a581fe9... d9389fa … 024e881 … 39c0348 …

45 P3: Narrow Waist for Trust Management Ensure that the inputs to the intrinsically secure system match the trust assumptions and intensions of the user Certificate authorities, reputation, personal, … Narrow waist allows leveraging diverse mechanisms for trust management 45 Declaration of Independence Trust Management 043e49af3890dd a90cd2199

46 P4: Narrow Waist for All Principals Extends today’s host-based narrow waist to all principals: hosts, services, content, … Defines the API between the principals and the network protocol mechanisms 46 IP: Evolvability of: Applications Link technologies XIA adds evolvability at the waist: Applications Evolving set of principals Link technologies

47 P5: All other Network Functions are Explicit Services DNS, firewalls, … Causes problems in IP Covers all functions not part of the narrow waist XIA provides a principal type for services Keeps the architecture simple and easy to reason about 47

48 XIA: eXpressive Internet Architecture Each communication operation expresses the intent of the operation Also: explicit trust management, APIs among actors XIA is a single inter-network in which all principals are connected Not a collection of architectures implemented through, e.g., virtualization, overlays Not based on a “preferred” principal (host, content), that has to support all communication 48

49 Network-Network User-Network XIA Components and Interactions eXpressive Internet Protocol Host Support Host Support Content Support Content Support Services Support Services Support … Applications Users Services Intrinsic Security 49 Trustworthy Network Operation

50 What Applications Does XIA Support Since XIA supports host-based communication, today’s applications continue to work Will benefit from the intrinsic security properties New applications can express the right principal Can also specify other principals (host based) as fallbacks Content-centric applications Explicit reliance on network services Mobile users As yet unknown usage models 50


Download ppt "15-849: Hot Topics in Networking Four Next Generation Architectures Srinivasan Seshan 1."

Similar presentations


Ads by Google