Future Internet Architecture
CSC/ECE 573, Section 001
Fall 2012
Recent Trend in Internet Research
“Internet architecture was last visited 40 years ago”
 Does not necessarily mean it is broken

–

BUT:
–
–
–
–

Simplicity
Unified view
Evolvability
Maintainability
NSF-sposored FIND and FIA programs
–
–

In fact it is spectacularly not broken
Quick (partial) tour of some FIND and FIA projects
(Apologies to concerned people for mangling)
Other initiatives elsewhere, e.g. FIRE in Europe
Virtualization

Diversified Internet Architecture
–
–

Jon Turner, Patrick Crowley, Sergey Gorinsky, John
Lockwood
Enable diverse metanetworks within common
substrate
Objectives
–
–
–
enable diverse metanetworks to co-exist
allow introduction of new network architectures at
any time
stimulate development of applications
Bulk-Data Transfer

Within Virtualization
–

Sergey Gorinsky
Bottomline - ideal transport layer for bulk-data
application is different from established wisdom
in transport layer, and cannot be obtained by
simple tweaks of current transport layers
Service Architectures

Services Architectures –Network Intermediaries
and End-to-end Abstractions
–

Dan Duchamp, Tilman Wolf
Session Layer Management of Network
Intermediaries - Dan Duchamp
–
Bottomline - transport layer connections should be
long-lived, virtual connections, and application flows
should be managed as session layer contexts
Foreseen Philosophical
Problems
Unambitious: just what we don’t need—
another hack to the socket/TCP/IP model
 Network is still pretty dumb: should know
more about session semantics?
 If L5 handles end-to-end delivery
semantics, what does L4 do?

Relation to FIND/GENI
Yes, it’s true—L5 is just a tweak, not a
new architecture
 But: gives a concrete base for experiments
with certain architectural issues:

 What
is a service? Where is it implemented?
Who really provides it—network or host?
 State management
 Semantics/protocol for control signaling
between end system & intermediary
 Mapping of function to layers
Questions




What services should the network provide?
Should the network offer service at the application level
rather than at the datagram level?
Should anybody be allowed to provide services or not
(and thus reduce potential for spam, phishing, spyware,
etc.)?
Will ease/speed of new service deployment be as
important in the future as it has been in the past? Will the
rate increase or decrease?
Questions (cont.)





Capitalists would like to know: how should
accounting/billing work?
Should we construct a network that could, for example,
bill per page view?
Socialists would like to know: how can "undesirable
uses" of the Internet be limited?
What is the appropriate position for network architects to
take regarding the design of censor-able, tap-able, spyable Internet?
What is the right technical tradeoff point between (1) a
"civilized" appropriately-governable Internet, and (2) an
Internet permitted "free expression"?
End-Middle-End

End-Middle-End, EME IRTF Research group
–


Paul Francis
Essential idea: E2E model pushes all policy, access,
etc. to the edges, but this is not practical. Sometimes
you just have to put some processing in the middle
Need an architecture that allows all stakeholders in a
connection to:
–
–
Know what is going on
Assert their policies: Access control, Steering, Security,
Transport
Secure Routing

Threats and lessons
–

Z Morley Mao
New routing services could enable network
security services
Q&A
• Questions to consider
– What role should routing play to mitigate against data-plane
attacks?
– How should data plane filtering be better integrated with control
plane filtering (packet filters with route filters)?
– What is the role of management plane for routing and dataplane?
– How do we enforce networks to practice good network
configurations?
Source Controlled Routes

Security implications of source routing etc.
–

Xiowei Yang
Secure routing depends on source routes
–
–
But security is the #1 reason to disable source routes
How we can reconcile these two
Conclusion
No
control

Choose paths
knowing entities on
the paths
Explicitly list the routers
The desirable goals


Deflect without
Knowing the
paths
Byzantine-tolerant, accountability, availability, economic incentives,
overhead, QoS, manageability…
The right balance of control and exposure

Source-controlled routing  Source routing option in IPv4 or Routing
header in IPv6
Market-Enabling Architecture

John Musacchio, Jean Walrand, Venkat
Ananthram, Galina Schwartz, Shyam Parekh
–
–
User should be offered choice between network
services and informed of benefits, then the market
can play itself out
Security could be achieved by “security insurance”
provided by Certification Agency
Service Choice

Users offered real-time choice: “red” and “blue”
–
“Red” and “blue” not specified to users in detail
–
ISP incentivized to improve along dimensions that matter
–
Unlike ATM, IntServ, DiffServ, service definitions not
standardized
John Musacchio
Internet Today – Security Inadequacy
ANALOGY
Zzzz


Drivers do not bear full
cost of reckless driving.

Liability insurance
incentivizes drivers to
be careful.
Users do not bear full
cost of poor computer
maintenance
John Musacchio
Markets for Security

Example:
–
Users pay to be certified by a Certification Agency (CA)
$
–
CA takes on liability for attacks traced back to user
Zzzz
–
CA incentivized to encourage users to take due care
OS Update
Antivirus Update
John Musacchio
User Controlled Routes

Economic implications, this time
–

User choice in routing stimulates competition
and competition fosters innovation
–

Xiaowei Yang
User choice may preserve the competitiveness in the
backbone market, and reward innovative providers
Effectively, similar to Market-Enabling
Architecture proposal
Contract Switching

A “paradigm shift” from packet-switching
–

Contracts formed, create labels
–
–

Incentives compared at switching points
Appropriately switched
Effectively, virtual ckt-switching with attached
financial / economic information
–

Aparna Gupta, Shivkumar Kalyanaraman, Murat
Yuksel
(caveat: over-simplification?)
Also, provide user with techno-economic choice
–
In this case, also providers
Postcards from the Edge

Roy Yates, Dipankar Raychaudhuri, Sanjoy
Paul, James Kurose
 Cache-and-forward
–
Reliable hop-by-hop transport of large files
– Push-pull architecture for opportunistic delivery of
files both to and from the wired network
– Enhanced naming to provide location information for
mobile terminals
– Distributed caching of popular content to make peerto-peer file sharing a first-class service and to enable
efficient reliable multicast.
Architectural Support for SelectivelyConnected End Systems

Mark Allman, Vern Paxson, Ken Christensen,
Bruce Nordman
 Enable an energy-efficient future Internet
 Baked-in assumption of always-on
–
–
–

Fate sharing
Soft-state
E2E
Study how architecture should change for real
current devices
–
Proxy, “limbo”, assistant
Economic Viability

On the Economic Viability of Network
Architectures
–

Roch Guerin, Kartik Hosanagar, Andrew Odlyzko,
Zhi-Li Zhang
Focus: what will happen to the Internet and its
economics while clean-slate architectures are
being deployed? Assess chances of success,
economic impact of various architectures
Background and Motivation
• We are embarking in far-reaching explorations of new
technology alternatives for tomorrow’s Internet
– But clean-slate does not mean “green field”
• There is a behemoth of an incumbent to deal with, and it’s far
from standing still
• The eventual relevance and success of new alternatives is not
just a function of technical superiority
– Economic aspects are likely to be equally, if not more important
• What can we do to explore the economic viability of emerging
“Next Generation Internet” alternatives?
24
Project Scope
• Three main thrust areas for assessing the economic viability of
new network architectures
1. Investigate and quantify the potential benefits of key proposed
architectural features
–
Virtualization, integration, diversity
2. Explore when and why the existence of a formidable incumbent
can affect the emergence of new technologies
3. Develop models that account for how the openness and
flexibility of an architecture can foster the adoption of new
technology, and its ultimate success
25
SILO: A Reconstructed Protocol
Stack
App
App
Transport
App
App
App
App
m11
m11
m13
m21
m21
Transport
Network
CrossService
Tuning
m31
m21
m31
m31
silo &
service
mgmt
Data Link
m42
Physical
Physical Channels
Tuning
strategies,
hints
m62
m43
m62
m61
Physical Channels
Composability
Constraints
A Big Picture
Stratified Network - Graded Entry
“Transport in layers, control and secure across layers”
Control Agent
Single Point of Policy and Certification
Generic Authentication
Need-based
per-flow stacks
Composable Service with Control Interface
Portable Configuration
Redundant Path Delivery
Smooth integration of evolving security
Presentation to NSF Oct 07 by SILO Team
??? (Future Service)
27
Things Not Discussed Much
• Billing & accountability:
– Future network could have forms of billing that tie
fine-grained user actions to $$
• E.g., QoS, services accessed
– This will necessarily drive notions of identity,
accountability
– DoS becomes $$ from end sources
– Is there anything we can assume (or anti-assume)
in this regard?
Things Not Discussed Much, con’t
• DRM:
– Inevitable this will spill over into the network?
– Implications for content inspection, caching?
• Infrastructure threats beyond DoS:
– Theft-of-service, theft-of-customer
Things Not Discussed Much, con’t
• For new services, how to validate/audit that
it’s fully/correctly provided?
– …. in the presence of adversaries
• For both this and forms of network inspection,
how to conduct these
– At varying semantic levels
– With non-global knowledge?
Things Not Discussed Much, con’t
• Interdependence between security and
management
– What sort of security can management services
themselves draw upon …
– … given that they have to work when things
(including security mechanisms) are broken?
Things Not Discussed Much, con’t
• What about leveraging mutual aid and the fact
that there are many more benign actual users
than malicious ones?
– E.g., collaborative filtering, aggregated/shared
analysis
– E.g., mechanisms for our friends / social networks to
help us in times of overload or uncertainty
– “In the real world, selective trust is what makes
society work”
Things That Gave Me Pause
• Some assumptions that security issues could
be addressed external to an effort
– True: for pinpoint crypto ~ securing a session
– False: for system properties / vulnerabilities
– How do we best address this division?
• Distributed algorithms for which
– Adversarial inputs not under consideration
• These differ from failures / misconfigurations
– Or assumed readily thwarted (e.g., crypto)
Things We Should Work Out Soon
• Identity building blocks
• Assumptions about trusted hardware
• Maybe: role of billing / accountability
• Capture:
– Spectrum of properties being assumed
– Spectrum of properties being provided
– And for these, what “buy-in” costs / assumptions
do they entail?
Summary
•
1.5 day Meeting at WINLAB, Rutgers University, May 29-30
•
5 groups: 3 FIND projects and 2 external groups with projects in related space
F
I
N
D
– Transient Network Architecture (TNA) -- CNRI/UNM: Henry Jerez
– Day After Network (DAN) --- UIUC: Robin Kravets
– Postcards from the Edge: A Cache and Forward Architecture – Rutgers & UMASS:
Sanjoy Paul, Dipankar Raychoudhuri and Jim Kurose
– SPINDLE/DTN – BBN: Rajesh Krishnan
– Ambient Networks – EU (Ericsson): Lars Lundgren
Roy Yates,
•
Goal: explore synergies, identify gaps, define a comprehensive project in the area
•
Agenda:
•
Summary of results to be presented at FIND meeting
•
Detailed agenda, slides, etc. posted at:
– 20-30 min talk from each of the 5 groups
– Look for Similarities and Synergies
– Use of GENI: What kind of experimental facility (say in GENI) be most valuable to instantiate
the specific research project
– Identify open issues/"holes"
– http://gaia.cs.umass.edu/rutgers_FIND_meeting
ChoiceNet Architecture
 Envisions new fundamental high-level entities and interactions
 “Economy Plane” to allow alternative representation at all levels
 Direct to consumer: funnel reward to each actual provider
 Coarse grain: service/transport/path choices
 Fine grain: modulation / transcoding algorithm choices  innovation
 “Use Plane” for actually using/running purchased service
 “Measurement Plane” creating third-party verification opportunities
Use
plane
Alternatives
for protocol
stacks, paths,
and innetwork
services
Endsystem
Marketplace
Service negotiation /
payment
Advertisement
Alternative selection
Trust/
reputation
Alternatives
Introspection
Composed service offerings
Setup
Protocol
alternatives
control
Data plane
Control plane
Economy
plane
Endsystem
In-network
services
control
Setup
Path
alternatives
control
Router w/
service
Router
Service
proofs
Management
Payment
verification
Router
Router
Router
Router
Router
Router w/
service
Encourage
Alternatives
Vote with
Your Wallet
Know What
Happened
 Measurement plane
relevant for wireless
 Richer measurement in
network than typical
netw. management
 Network itself can be
sensor for CPS
 Location, timestamp
enriched, correlated
information
 All become more
difficult, yet more
necessary, for networks
with large number of
moving nodes
MobilityFirst Vision: Mobility as the key
driver for the future Internet

Historic shift from PC’s to mobile computing and
embedded devices…



~4 B cell phones vs. ~1B Internet-connected PC’s in 2010
Mobile data growing exponentially – Cisco white paper predicts >1exabyte
per month (surpassing wired PC traffic) by 2012
Sensor deployment just starting, ~5-10B units by 2020
~2B servers/PC’s, ~10B notebooks, PDA’s, smart phones, sensors
~1B server/PC’s, ~700M smart phones
Wireless
Edge
Network
INTERNET
INTERNET
Wireless
Edge
Network
~2010
MobilityFirst Summary
~2020
May 2011
MobilityFirst : High-Level Design Goals

Mobility-centric design
Migration of 10B network-attached objects (devices, content, users, …)
 Robustness in presence of channel impairments & disconnections


Support for network mobility & dynamic network-of-networks formation
 Socket API’s designed explicitly for mobility use cases: multicast, anycast,
context- or location-aware delivery, etc. (…service innovation at the edge)

Strong security and privacy

Standard security services (authentication, secrecy, confidentiality, nonrepudiation, ..) built into architecture
 Resistance to common IP network attacks, e.g. address hijacking, DDoS, ..
 Network protocols designed to be resilient against failures/attacks


No single root of trust, flexible trust domains/mechanisms
No per-flow state, low control overhead

No signaling, reduced end-to-end chatter (back to packet switching basics..)
MobilityFirst Summary
May 2011
MobilityFirst Summary: Protocol Highlights

Separation of naming and addressing

Clear distinction between identify of network-attached endpoint and net addr
 Name (GUID) = “self-certifying” public key; address = flat NA

Multiplicity of name assignment and trust management
services – encourages specialization & competition


Fast global name resolution service (GNRS)


High-level services for managing content, context, network trust, etc
Integral part of network protocol, resolves GUID  NA in ~100 ms
Hybrid GUID/NA routing with self-defining packets

NA routing for fast path; late binding GUID routing for advanced services
 Multicast/anycast as the norm with unicast as special case

In-network storage and computing options at routers

Seamless integration of switching, storage and DTN modes
 Hop-by-hop (or segment-by-segment) transport vs. end-to-end TCP
MobilityFirst Summary
May 2011
Architecture Concepts: Name-Address
Separation

Separation of names (ID) from
network addresses (NA)
Globally unique name (GUID)
for network attached objects
Sue’s_mobile_2





User name, device ID, content, context,
AS name, and so on
Multiple domain-specific naming
services
Server_1234
John’s _laptop_1
Host
Naming
Service
Media File_ABC
Taxis in NB
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
for GUID  NA mappings
Global Name Resolution Service
Network
Hybrid GUID/NA approach

Both name/address headers in PDU
 “Fast path” when NA is available
 GUID resolution, late binding option
MobilityFirst Summary
Net2.local_ID
Network address
Net1.local_ID
May 2011
Architecture Concepts: Global Name Resolution
Service

Fast Global Name Resolution a central feature of architecture


GUID <-> network address & port number (also called “locator”) mappings
Distributed service, possibly hosted directly on routers

Fast updates ~50-100 ms to support dynamic mobility
 Service can scale to ~10B names via P2P/DHT techniques, Moore’s law
Host GUID
Registration
update
NA2
Network – NA2
Mobile node
trajectory
Data Plane
AP
Network – NA1
Host GUID
Initial
registration
Global NameAddress Resolution
Service
Decentralixed name services
Hosted by subset of ~100,000+
Gatway routers in network
NA1
Name, Context_ID or Content_ID
MobilityFirst Summary
Network Address
May 2011
Architecture Concepts: Storage-Aware Routing
(GSTAR)



Storage aware (CNF, generalized DTN) routing exploits in-network
storage to deal with varying link quality and disconnection
Routing algorithm adapts seamlessly adapts from switching (good
path) to store-and-forward (poor link BW/disconnected)
Storage has benefits for wired networks as well..
Temporary
Storage at
Router
Initial Routing Path
Low BW
cellular link
Re-routed path
For delivery
Mobile
Device
trajectory
PDU
Storage
Router
High BW
WiFi link
MobilityFirst Summary
Mayresult
2011
Sample CNF routing
Architecture Concepts: Segmented
Transport




Segment-by-segment transport between routers with storage,
in contrast to end-to-end TCP used today
Unit of transport (PDU) is a content file or max size fragment
Hop TP provides improved throughput for time-varying
wireless links, and also helps deal with disconnections
Also supports content caching, location services, etc.
PDU
Segmented (Hop-by-Hop TP)
Hop #3
Hop #1
BS
Hop #2
Hop #4
Temporarily
Stored PDU
Low BW
cellular link
Storage
Router
Optical
Router
(no storage)
Hop-by-Hop
Transport
GID/Service Hdr
Mux Hdr
More details of
TP layer fragments
with addl mux header
Data
Frag 1
Data
Frag 2
……
Data
Frag n
Net Address Hdr
MobilityFirst Summary
May 2011
Architecture Concepts: Context Aware
Delivery

Context-aware network services supported by MF architecture

Dynamic mapping of structured context or content label by global name service
 Context attributes include location, time, person/group, network state
 Context naming service provides multicast GUID – mapped to NA by GNRS
 Similar mechanism used to handle named content
Context = geo-coordinates & first_responder
Send (context, data)
Context
Naming
Service
Global Name
Resolution service
Context
GUID
NA1:P7, NA1:P9, NA2,P21, ..
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory
MobilityFirst Summary
May 2011
Summary

Many threads of research focusing on
architectural issues
–

Some common concerns recur
–
–
–
–

“Architecture” at various levels and granularities
Security, accountability
Economics, non-monopoly, choice
Wireless, mobility
Aggregation, scalability
Consensus on problems that need to be dealt
with, if not solutions