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