* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download The NSF Future Internet Architecture (FIA) Program
Survey
Document related concepts
Transcript
The NSF Future Internet Architecture (FIA) Program • • • • Successor to 5 years of FIND and NetSE Future Internet Summit – Fall 2009 FIA solicitation 2010 Four awards Fall 2010 – – – – Named Data Networking – UCLA NEBULA – University of Pennsylvania eXpressive Internet Architecture – CMU MobilityFirst – Rutgers • See <http://www.nets-fia.net/> 1 The NEBULA Future Internet Architecture: A Research Agenda 2 A Comprehensive Architecture • NEBULA is an architecture for the cloud-based future Internet – Cloud is 1960s computing utility – Requires a new kind of net • Key goals – – – – More secure and reliable Deployable and evolvable Truly clean slate Co-design Tech, Econ and Policy IMP Front and Back, CRS-1 3 NEBULA: A Network Architecture to Enable Security NDP – NEBULA Data Plane – distributed multiple-path establishment and policy enforcement (availability and policy enforcement) NVENT - NEBULA Virtual and Extensible Networking Techniques – extensible control plane (extensibility + policy specification and entry) NCore – NEBULA Core – redundantly connected high-availability routers (availability) 4 Enforcing policy at high speed? • Data plane must check that path is authorized • Data plane must check that path was followed – This is a hard technical problem • Status quo not even close (BGP only advisory) • Target environment rules out previous techniques – Backbone speeds preclude digital signatures – Federated nature of Internet precludes central root of trust, pre-configured shared secrets, etc. 5 NDP in a nutshell • Use cryptography for: • Proof of consent (PoC) – route authorized? • Proof of path (PoP) – route followed? 6 bytes 1 byte counter hop # 42n bytes hop 1 info Domain ID ... 6 bytes hop n info Proof of Path other fields Proof of Consent payload MPLS-style token 42 bytes 6 NDP Research Questions: • Must NDP run on all paths? • Realm management (roughly AS-like?) • Mapping to intra-domain/inter-domain? – Economic / policy implications? • Public-key infrastructure challenges – Revocation, etc. • Control of enforcement 7 NEBULA Virtual and Extensible Network Techniques (NVENT) request Application Interface paths Service Discovery (Database) NDP (policy2) IPV6 Network Services NDP (policy1) • Secure control plane for naming, path exchange, etc. • Service access • New service injection • Generalized path discovery for specifying policies, multiple paths and dynamic path construction via NDP 8 NVENT Research Questions: • How do NVENT nodes peer? • What is the right division between roles of NVENT: 1) API, 2) Policy/Consent server, 3) means for introducing and offering new services / slicing up services? • Policy specification and management? • (Soft)-state management versus dynamics? • Changes in dynamics if routers more resilient? 9 Ncore redundancy: paths • High availability via redundant high-throughput links • A routing complex from multiple chassis • Sufficient capacity for easy VM replication/migration 10 Ncore redundancy: software • Highavailability router control software • Ideas from distributed systems and cluster computing Process i (Line Card B) Process j (Line Card C) Process m (Line Card K) Availability Middleware Resource and Fabric Management External (e.g., OpenFlow) Internal Open Source Internal Proprietary Line Card G Line Card A Fabric Line Card F Line Card K 11 Ncore Research Questions: • What are the scalability barriers? • What are the technical/economic tradeoffs among redundancy: 1) inside routers, 2) inside data centers and 3) between routers? • Algorithms and Interfaces for path management • Interfaces with NDP and NVENT 12 NEBULA Architectural Choices Design Goal Communication must continue despite loss of networks, links, or gateways. NEBULA NEBULA uses multiple dynamically allocated paths and reliable transport. Allow host attachment and operation with a NVENT/NDP is as easy to automate and use low level of effort as DHCP/IP. Support secure communication (authentication, authorization, integrity, confidentiality) among trusted nodes. Mutually suspicious NDP nodes self-select paths exhibiting cryptographic proofs of properties required for security. Provide a cost-effective communications infrastructure Ncore places resources where architecturally needed; regulatory/policy analysis. Implement network and user policies Policies implemented with NDP and NVENT. The architecture must accommodate a variety of networks. NDP sends packets by encapsulation, NVENT networks by virtualization The architecture must permit distributed management of its resources. NDP path establishment decentralized, NVENT 13 NEBULA Research Questions: • Can we design the overall system for Byzantine Faults? – E.g., an entire nation’s routers “go bad”… • Economic implications for (new?) industry? – Customer demand for NEBULA features? • How does NEBULA interact with regulatory requirements? • Nebula policies, versus, e.g., Net Neutrality? 14 Realization Progress and Plan • Router emulation environment – Currently on Cisco-provided cluster in San Jose – Extend to LTS cluster and other PIs/institutions – Cisco-provided access to CRS-1 for experimentation • NVENT, NDP and Ncore designed for multiple iterations of independent development – Elements of NEBULA architecture can (and will) be independently developed and incrementally deployed 15 Acknowledgements • NEBULA is supported by the National Science Foundation under its Future Internet Architecture program • NEBULA is also supported by Cisco Systems 16 Thank you! 17 www.internet2.edu Tom Anderson The NEBULA Team Ken Birman Robert Broberg Matthew Caesar Douglas Comer Chase Cotton Michael Freedman Andreas Haeberlen Zack Ives Arvind Krishnamurthy William Lehr Boon Thau Loo David Mazieres Antonio Nicolosi Jonathan Smith Ion Stoica Robbert van Renesse Michael Walfish Hakim Weatherspoon Christopher Yoo 19 20 NDP and NVENT roles: NVENT 2 policy engine 5 1 policy engine policy engine 2 3 consent engine policy engine consent engine consent engine consent engine 4 path req d a t a d a t a path spec 6 7 SLA 1 d a t a SLA 2 8 d a t a 9 employees lan gst 10 d a t a NDP 21