Future Internet Architectures (FIA)
And GENI
Darleen Fisher
Program Director
Division of Computer & Network Systems
Directorate for Computer and Information Science and Engineering
National Science Foundation
1
Outline
• FIA Vision
• Future Internet Architecture (FIA) Projects
• FIA Projects’ Current Ideas about Using GENI
• Going Forward—What might be next for FIA &
GENI?
2
Future Internet – The Vision
• Society’s needs for an IT infrastructure may no longer be met
by the present trajectory of incremental changes to the
current Internet
• Society needs the research community to create the
trustworthy Future Internets that meet the needs and
challenges of the 21st Century.
• Research should include intellectually distinctive ideas,
driven by the requirement for long-range concepts unfettered
by the current limitations of or the requirement for immediate
application to the current Internet. Architecture includes all
needed functionalities (overarching architecture).
• Research on Future Internets create a community better
informed and educated about network architecture design
3
Future Internet Architectures (FIA)
NSF issued a call for proposals:
• To support innovative and creative projects that
conceive, design, and evaluate trustworthy
Future Internet architectures
• 4 projects awarded – A diverse portfolio
– (smaller projects under consideration and expected
submit to NeTS Large)
• http://www.nets-fia.net/
4
FIA Projects and their View of the Future
• Mobility First
– The future is mobile (Cellular, wireless sensors, machineto-machine, smart grid & vehicular nets integrate physical
world awareness and control into Internet applications)
• NEBULA
– 24x7 Utility for secure communication, computation and
storage
• Named Data Network (NDN)
– Content is the future driver
• eXpressive Internet Architecture (XIA)
– Design for evolution of: usage (host-host, content retrieval,
services) and technology (link, storage, computing)
– http://www.nets-fia.net/
5
MobilityFirst
• Principle Investigator: Dipankar Raychaudhuri, Rutgers
– Collaborating Institutions: Duke Univ., Massachusetts
Institute of Technology, Univ. of Massachusetts/Amherst,
Univ. of Massachusetts/Lowell, Univ. of Michigan, Univ. of
Nebraska/Lincoln, Univ. of North Carolina/Chapel Hill, Univ.
of Wisconsin/Madison
• Underlying architectural principles
– Mobility is the norm without gateways or overlay
accommodations
– The architecture uses generalized delay-tolerant networking
(GDTN) to provide robustness even in presence of
link/network disconnections. GDTN integrated with the use
of self-certifying public key addresses to provide an
inherently trustworthy network. Wired networks special case.
6
http://mobilityfirst.winlab.rutgers.edu
M-F Overview - Component Architecture
Location
Service
Context
Addressing
Other Application Services
Content
Addressing
Host/Entity
Addressing
Application Services
Encoding/Certifying Layer
Network-Support
Services
Global Name Resolution Service
(GNRS)
Storage Aware
Routing (STAR)
Locator-X Routing
(e.g., GUID-based)
Context-Aware /
Late-bind Routing
IP Routing
(DNS, BGP, IGP)
Management
Link state and Path
Measurements
Core Network Services
Monitor, Diagnosis
and Control
7
Named Data Networking
Principle Investigator: Lixia Zhang, UCLA
– Collaborating Institutions: Colorado State University, PARC, Univ.
of Arizona, Univ. of Illinois/Urbana-Champaign, UC Irvine, Univ. of
Memphis, UC San Diego, Washington Univ., and Yale Univ.
Underlying architectural principles
• Content is what users and applications care about; By naming data
not location data become a first-class entity.
• Underlying architectural principles
– Packets indicate what (content) , not who/where (IP address)
– Packet is a <name, data, signature>
• Securing named data potentially allows trust to be more user-centric.
– Retain the hourglass in the architecture
– Separate routing and forwarding
– http://www.named-data.net/index.htm
8
Named Data Networking (NDN)
♢
The architecture retains the hourglass shape
♢ Change the thin waist from using IP addresses
to using data names



♢
♢
Always retrieve data from closest copy on a path to
source; use memory for intrinsic multicast
distribution
IP addresses name locations; retrieving data by
names eliminates a fundamental hurdle in mobility
support
Retrieving data by names facilitates new
application development in sensor networking
Robust security from per packet signature
The new strategy layer enables intelligent data
delivery via broadcast, multicast, and multiple
paths
ISP
ISP
ISP
ISP
9
NEBULA
• Principle Investigator: Jonathan Smith, Univ. of Penn.
– Collaborating Institutions: Cornell Univ., Massachusetts Institute of Technology,
Princeton Univ., Purdue Univ., Stanford Univ., Stevens Institute of Technology,
Univ. of California/Berkley, Univ. of Delaware, Univ. of Illinois/UrbanaChampaign, Univ. of Texas, Univ. of Washington
• Underlying architectural principles
– Always-on utility where cloud computing data centers are the primary
repositories of data and the primary locus of computation
– Storage, computation, and applications move into the "cloud“
– Data centers are connected by a high-speed, extremely reliable and
secure backbone network.
– Parallel paths between data center and core
– Secure access and transit, policy-based path selection and
authentication during connection establishment
http://nebula.cis.upenn.edu/
10
NEBULA Architecture
NDP (NEBULA Data Plane) distributed multiple-path establishment
and policy enforcement
NVENT (NEBULA Virtual and Extensible Networking Technologies)
extensible control plane
Ncore (NEBULA Core) redundancy-connected, high-availability
routers
11
eXpressive Internet Architecture (XIA)
• Principle Investigator: Peter Steenkiste, Carnegie Mellon
Univ.
– Collaborating Institutions: Boston Univ., Univ. of
Wisconsin/Madison
• Underlying architectural principles
– XIA offers support for communication between current
communicating principals--including hosts, content, and services-while accommodating unknown future principals.
– For each type of principal, XIA defines a narrow waist that dictates
the application programming interface (API) for communication and
the network communication mechanisms.
– XIA enables flexible context-dependent mechanisms for
establishing trust between the communicating principals.
– http://www.cs.cmu.edu/~xia/
12
XIA Components and Interactions
13
FIA Projects’ Current Ideas to use GENI
Project:
• Just began September 1, 2010;
• Are at different levels of maturity; as are
• Their plans for experimentation and how
they might use GENI.
14
Potential use of GENI in NEBULA*
• GENI Technology:
-
Enables experiments involving multiple sites
Isolates NEBULA experiments to a single VLAN
Eliminates need for special HW & Address Translation
• Potential Uses:
-
Multisite student collaboration on Ncore (NEBULA Core)
Testbed for NDP (NEBULA Data Plane) experiments
Platform for NVENT (NEBULA extensible control plane)
* No GENI-enabled switches on NEBULA campuses-->so preliminary
thoughts
15
15
XIA Testbed Requirements
• Run fairly large, geographically diverse experiments
– Several tens or more nodes
• High speed packet processing platform
– Evaluating Openflow – XIA is very different from IP
• Diverse access network technologies
– Evaluate XIA over diverse networks using
applications
• Short learning curve for students
– Avoid time sink that takes away time from research
– Essential for UG and MS student participation
16
play attacks using signed interests, so embed a
interest “command”, that has as arguments the symmetric k
into each message before signing. Maintaining
encrypted under the device’s public key, and the requested ex
mestamp or a smaller counter, per fixture per
date and time.
sonable.
The device should reply with a Content Object, encrypted w
♢ Pervasive/mobile computing “infrastructure-less”
Watertight
enclosure
symmetric key, confirming its
installation
and actual expiratio
testbeds with embedded hardware
WiFi
router
and time allowed.
Battery
NDN Experimental Infrastructure
♢
♢
Real world settings for Internet-of-Things scenarios
Computer
Micropho
Open Network Lab (ONL)
♢
Controlled small-scale experiments, especially
ED Lighting
with Embedded Linux Interface
forwarding
♢ NDN Overlay Testbed on public Internet
of industry-standard
LED lighting
by Philips Color
♢ Live application
testing/use
under realistic
a proprietary UDP/IP protocol for fixture and power
conditions
onfiguration and control.
♢
Routing and incremental deployment
an embedded Linux controller (Gumstix Overo, 500
♢ PlanetLab
A7) that connects to an NDN network on one
experiments
network♢on Large-scale
the other.
♢ Supercharged
PlanetLab Platform
r supplies
are on the IP network
x Experiments So Far
♢
(SPP) Nodes
High-performance CCNx/NDN forwarding
ures via a multi-drop serial.
Python and C software to bootstrap, configure, and
es via NDN.
network has an asymmetric key pair: lighting fixtures,
bedded interfaces, and applications.
Figure 3: NDN Lighting Module
y Performance Analysis, API Feedback and Future
CCNx C API Feedback
17
NDN and GENI
• Using SPP nodes
– Initial software running on
5 nodes now
– Lead: Patrick Crowley
• No other clear needs
identified yet
• Possibilities:
– Large numbers of nodes
with significant topology
control including local
broadcast
– Running natively over
something other than IP
– NDN “PlanetLab”
NDN Participating Institutions
Deployed SPP Nodes
Yale
Washington DC
Salt Lake City
PARC
Kansas City
ColoState
UIUC
WashU
UCLA
UCI
CAIDA/UCSD
Arizona
Memphis
Atlanta
Houston
18
Mobility-First Phased Approach
Content
Addressi
ng Stack
Context
Addressi
ng Stack
Host/Device
Addressing
Stack
Encoding/Certifying Layer
Global Name Resolution Service (GNRS)
Storage Aware
Routing
Locator-X Routing
(e.g., GUID-based)
Context-Aware /
Late-bind Routing
Simulation/Emulation
Emulation/Limited Testbed
Testbed/‘Live’ Deployment
Evaluation Platform
Standalone
Components
Cross Layer Integration
Deployment ready
Prototyping Status
19
19
Phase1: Global Name Resolution Service (GNRS)
Evaluation - ProtoGENI Mapping
• Phase 1 evaluation of distributed network services, e.g. GNRS
• Backbone bandwidth and delay representative of Internet core
• Edge substrates interconnected via backbone
Required Testbed
Infrastructure
Domain-1
Domain-2
Router
Router
Domain-3
PoP
PoP
(ProtoGENI nodes,
OpenFlow switches,
GENI Racks, ORBIT
node clients)
PoP
Router
Router
Router
PoP
PoP
Clients
Clients
PoP
Clients
20
20
Phase 1: Wireless/Mobile Edge Substrate
• Phase 1 evaluation of storage-aware routing in edge
network
• Network: Ad hoc, multiple wireless technologies –
WiFi, WiMAX
• Evaluate routing with mobility, handoff, multi-homing
Single Wireless
Domain
Cell
tower
WiFi
BTS
WiMAX
AP
Handoff
Movemen
t
Ad hoc
network
Multihomed
device
Required Testbed
Infrastructure:
GENI WiMax,
ORBIT grid &
campus net,
DOME/DieselNET
WiNGS
21
Phase 1:


GENI WiMAX & ORBIT Testbeds
Multi-radio indoor and outdoor nodes - WiMAX, WiFi,
Linux-based Click implementation of routing protocols
22
22
Phase 2: Core + Edge Evaluations
• Multi-site experiments with both (wired) core and (wired +
wireless) edge networks
• Evaluate:
– Core-to-edge routing
– Cross-layer interaction between GNRS and routing services
– In-core router storage resources in STAR routing
1Gbps
Required Testbed
Infrastructure:
GENI WiMax/OF
campus nets, ORBIT,
ProtoGENI
23
23
Phase 3: Live Edge-Core-Edge Deployment
Legend
Domain-1
Services
Domain-3
Domain-2
Internet 2
National Lambda Rail
OpenFLow Backbones
OpenFlow
Full MF Stack
at routers, BS, etc.
Wireless Edge
(4G & WiFI)
WiMAX
ShadowNet
Router
Wireless Egde
(4G & WiFI)
Router
Wireless Edge
(4G & WiFI)
Router
Router
Intra-domain mobility
Router
Opt-in users
Mapping onto GENI
Infrastructure
ProtoGENI nodes,
OpenFlow switches, GENI
Racks, WiMAX/outdoor
ORBIT nodes, DieselNet
bus, etc.
Router
Inter-domain mobility
Deployment Target:
• Large scale, multi-site
• Mobility centric
• Realistic, live
24
24
Going Forward
FIA team members continue to participate in
GENI
GENI-FIA-like Workshop???
–
–
–
–
FIA testbed/experimentalists Reps
GENI GPO Reps
Working Groups Reps
Other researchers working on architecture
projects
Other ideas?
25