The Future Internet
Motivation, Bachground, and Basics Thomas Plagemann University of Oslo, Department of Informatics
Three Internet Anniversaries in 2009?
• 20 years World-Wide Web
• 30 years Usenet
• 40 years ARPANET
14. februar 2011 2
Acknowledgement
• Tutorial is based on insights gained by working
on the EU project ANA (Autonomic Network
Architecture) and DT-Stream • ANA is funded by Information Societies Technology—
Future Emerging Technologies (IST-FET)
• DT-Stream is funded by the Norwegian Research
Council in the VERDIKT programme
• Thanks also to the SpoVNet team – which
generously provided a *.ppt set!
14. februar 2011 3
Outline
• Future Internet Part 1: • Introduction and background
• Motivation
• Ongoing initiatives
• Requirements Analysis
• IP Issues
• Concepts & Case Study
• Summary
• Future Internet Part 2: • Concepts and Implementation in ANA
• Information Dispatch Points
• Information Channels
• Compartments
• Monitoring Framework
• Outlook 14. februar 2011 4
Today
Motivation
14. februar 2011 5
[Source: http://www.computerhistory.org/internet_history/]
Motivation (cont.)
14. februar 2011 6
Motivation (cont.)
14. februar 2011 7
[Opte.org]
Motivation (cont.)
14. februar 2011 8 [Source: www.ipligence.com/ worldmap/ ]
Motivation (cont.)
• Increasing dependency on the Internet in public,
commercial, and private sectors …… both number of users and importance of services
• Increasing heterogeneity …… network technologies never die – only new appear
…… from high-performance to sensors & nano-machines
• Increasing mobility
• Increasing threat level
14. februar 2011 9
Motivation (cont.)
• Variability in the Internet is above and below IP:
it's the "hour-glass" model.
14. februar 2011 10
IP
Application
layer
Link
layer
www, email, ftp, ssh, DNS,
peer-to-peer (eMule, BitTorrent)
VoIP (Skype), VoD, grid, …
Ethernet, wifi (802.11), ATM,
SONET/SDH, FrameRelay,
modem, ADSL, Cable, …
Changing/updating the Internet
core (e.g., IPv6, Multicast, MIP,
QoS, …) is difficult or impossible !
also called the "waist" of the Internet
Requirements Analysis
• ….. with smooth transition to concepts
• ….. based on our early ANA work
• …. paper at IEEE FTDCS 2007
• ….. followed up by insights from Postmodern
Internet Architecture Project (FIND)
14. februar 2011 11
12
Insight from Requirements Analysis
• Facts: • Lot of serious problems with Internet due to
architecture today
• Changing the core of the Internet is hard
• Future will be heterogeneous and somewhat
unpredictable
• Suggestions: • Design a new architecture core with minimal set of
hard-wired standards that can be used to build
different ‖network instances‖
• IP networks like Internet can live on this core
• Make ‖network instances‖ autonomic to solve many
hard problems of today
13
Outline
• Introduction
• Problems Experienced With the Internet Today
• Future Trends
• Fundamental Concepts for A Future Architecture
• Conclusions
14
Quest for Future Internet Architecture
• The Internet: • is not ready to integrate and manage the envisaged huge
numbers of dynamically attached devices (wireless revolution,
mobility, personal area networks etc)
• lacks integrated mechanisms, e.g. for monitoring and security
• Time is right for ‖clean slate‖ design of Future Internet • FIND (Future Internet Network Design) initative
• GENI (Global Environment for Network Innovations) initiative
• FIRE (Future Internet Research and Experimentation) initative
• ANA (Autonomic Network Architecture) project
• And others…
15
ANA Project
• Objective: clean slate design Future Internet Network
Architecture
• With autonomic flavor
• Strategy: ―grow‖ the architecture
• Two prototype cycles within the project lifetime
• Disruptive approach • Changing/updating the Internet core (e.g. IPv6) is very
difficult
• Expected impact
• ANA aims to be the seed of the evolved/future Inter-
Network
16
ANA Project Partners
• ETH Zurich • University of Basel • NEC • Lancaster University • Fokus • University of Liege • University Pierre et
Marie Curie • NKUA • University of Oslo • Telekom Austria • University of Waterloo
17
How does this work fit in?
• Our paper presents requirements analysis for
ANA project
• Industrial (Telekom Austria) and academic
(University of Oslo) views
• Two categories of knowledge • Own experience and expertise
• External sources • Major publications, insights from industry, and documentation
from initiatives and corresponding meetings on the future
Internet…
18
Problems Today:
Some Well-Known Issues
• Lack of infrastructure-level (and service-level)
support for e.g. • Monitoring
• Security
• Resilience • E.g. DTN Internet’s end-to-end principle
• Inertia towards change • IPv4, BGP…
19
Problems Today: Viewpoint of Commercial Service Providers
• Voice over IP • NAT traversal
• Voice security
• Emergency call handling
• Phone power supply
• Reliability
• QoS
• Delay
• Legacy Systems • Heterogeneity
• different technical, regulatory and legal requirements
• Lawful Interception (LI)
• ‖Tapping‖ a line with POTS vs. VoIP
• Mobility, end-to-end encryption in VoIP
20
Future trends: Approach
stakeholders
services &
applications
technology identify
requirements
workload
emerging
technologies
Future Internet
architecture
21
Future Trends
• Various stakeholders have differing/conflicting
requirements • End Users (Consumers)
• Telecommunications Service Provider (Network
Operator)
• Regulator & Other Government Agencies
• Protocol Developer / Standardization Bodies /
Hardware & SoftwareManufacturers
• Application Developers
• Military
22
Future Trends (cont.)
• Future Workload Through Services and Applications • Wide scale of throughput
• Low and high latencies
• Varying levels of resilience
• Heterogeneous addressing and naming (no more just IPvX)
• Different security and access control policies
• Future Technological Developments • Number of devices will increase
• Devices will be very heterogeneous
• Increasing number of networking technologies with
heterogeneous properties • Not device ―friendly‖ environments (e.g. in oil industry)
• Mobility: MANETs, VANETs, airplanes…
23
So what to conclude?
• Requirements analysis outcome • Different stakeholders want different things
• …and conflicting things
• Heterogeneity will reign
• Conclusion: No ”one-size-fits-all” solution
• What to do? • No patches to current Internet
• Architecture that supports evolution to meet future
(unknown) needs
• We propose a few fundamental concepts for future
architecture
24
Fundamental Concepts
1. Realms (= compartments in ANA)
2. Monitoring
3. Information and Knowledge Management
25
Fundamental Concepts:
Realms
• Implement different ‖network instances‖ • different properties to address different requirements • E.g. end-to-end transport or not • Note: current Internet is a kind of realm!
• Set of policies and rules • E.g. to determine data transmission protocols, addressing scheme, security
policies… • What should be hardwired as standards into a realm?
• This is what we will be stuck with (like IP,BGP) • Minimal set of assumptions and standards for maximum flexibility • ‖Bootstrap‖ process
• Analogy to booting up different OSs on a PC
• Inter-communicating realms • Translation/mapping by ‖realm gateways‖
• Self-* properties • Self-protecting, self-healing, self-configuring, self-optimizing • Autonomic realms
26
Realms: example
IP
network
Sensor
network
IPv6 addressing
Strict access control
Data-centric addressing
No access control
Fundamental Concepts: Monitoring
27
28
• Existing monitoring solutions:
• Monitoring is add-on
• Need to control
• ANA should integrate monitoring as 1st class citizen
• Dynamic, adaptive, and programmable monitoring
• Trigger monitoring component, e.g. start, pause,
resume, terminate
• Dynamic placement of monitoring components
• Adapt to changes, e.g. new anomalies to be detected
• Specify the monitoring tasks at run-time, e.g. CQL for Data
Stream Management Systems
Fundamental Concepts:
Monitoring
29
Fundamental Concepts: Information and Knowledge Management
• No a priori knowledge in the architecture • Because of minimal hard-wired standards
• Maximum flexibility
• Which network nodes can I contact? How can I talk to
those nodes?
• Enable components to dynamically explore the
available services, interfaces, data types, etc.
Information & knowledge mgmt
ANA
Entity
Which services do you provide?
How can I use them?
…. I measure xxx
My interfaces are yyy
A unified generic
interface
Self-describing
30
Conclusions
• Identified (some of) architecture related problems with the current Internet
• We studied future trends • different stakeholders often have different and contradicting
requirements • Supporting heterogeneity will be a key aspect
• Conclusion: no ”one-size-fits-all”
• a set of concepts for a future network architecture • Realms
• Boot up different ‖network instances‖ through a bootstrap process
• Monitoring as an integral part of the architecture • To enable autonomic behavior
• Information and knowledge management • Dynamically explore and use available services, interfaces, data
types, etc.
Concepts
• So far we identified as important concepts • Realms
• Monitoring as 1st class citizen
• Information and Knowledge Management
• Additional concerns • Separation of identification and location
• Separation of routing and forwarding
don’t “address” end-points!
14. februar 2011 31
IP
What is wrong with IP?
1. Why do we build networks?
2. What is IP and what are IP addresses?
3. How does routing in the Internet works?
4. What happens with mobility?
14. februar 2011 32
Why Networks?
14. februar 2011 33
What is IP and what are IP Addresses?
14. februar 2011 34
IP address:
-Identification = who
-Location = where
Routing = find a way to destination
Forwarding = send next hop on the way
UiO
UiTø
Uninett
What is IP and what are IP Addresses?
14. februar 2011 35
Addresses:
-Identification = who
-Location = where
Routing = find a way to destination
Forwarding = send next hop on the way
UiO
UiTø
Uninett
An IP address does not identify a specific computer. Instead, each IP
Address identifies a connection between a computer and a network. A
Computer with multiple network connections (e.g., a router) must be
Assigned one IP address for each connection.
[Computer Networks, D. Comer]
Amount of IP Adresses
14. februar 2011 36
Old classful addresses Classless addresses, CIDR notation
Amount of IP Adresses (cont.)
14. februar 2011 37
Amount of IP Adresses (cont.)
14. februar 2011 38
IPv6 Adresses: many more bits…
What happens with mobility?
14. februar 2011 39
UiO
UiTø
Uninett
Utested
But this has been fixed ….
• Solutions adopted so far :
• Patches to cope with challenges contradict the
initial design paradigms, e.g. mobile IP
• Incoherencies patches to the patches
14. februar 2011 40
Consensus in the research community that
a next step beyond the Internet is needed.
What should we do now?
• Evolution vs. Revolution
• Revolution • Clean-slate approach
• Disruptive research
• Evolution • Migration path and coexistence through overlay,
federation, virtualization
14. februar 2011 41
Ongoing Initiatives
• New Future Internet initiatives have been started all over the world • Disclaimer: the overview will neither be complete and might contain
outdated information!
• AsiaFI: • Asia Future Internet Forum(AsiaFI) was founded in 2007 to coordinate
research and development on Future Internet among countries in Asia
as well as with other continents.
• http://www.asiafi.net/
• China: • China Next Generation Internet (CNGI)
• Started 2004, second phase 2009~ )
• IPv6-based • http://www.edu.cn/cernet_1377/index.shtml
14. februar 2011 42
Ongoing Initiatives (cont.)
• Korea • Future Internet Forum
• The "Future Internet Forum" aims to provide an opportunity to
review the forefront information and knowledge on the timely subject
of new Internet architecture and related issues. A direction for the
future R&D in Internet is expected to be shaped as a result of the
presentations and discussion among the experts.
• http://www.fif.kr/
• Japan • New Generation Network Promotion Forum (NWGN)
• We aim to achieve a new-generation network that extends beyond
the conventional IP network through new design concepts and
technology.
• http://forum.nwgn.jp/english/index.html
14. februar 2011 43
Ongoing Initiatives (cont.)
• Europe (EU) • Future Internet Research & Experimentation (FIRE)
• FIRE is promoting the concept of experimentally-driven
research, joining the two ends of academic-driven visionary
research and industry-driven testing and experimentation.
• FP6 first set of projects 2006 – 2009
• FP7
• 1st ―wave of projects‖ 2008 - 40M Euro
• 2nd wave 26. 10. 09 – 50M Euro
• 3rd wave 2011
• http://cordis.europa.eu/fp7/ict/fire/
14. februar 2011 44
Ongoing Initiatives (cont.)
• US: • Future Internet Design (FIND)
• FIND invites the research community to consider what the
requirements should be for a global network of 15 years from now,
and how we could build such a network if we are not constrained by
the current Internet – if we could design it from scratch.
• www.nets-find.net
• Global Environment for Network Innovations (GENI)
• GENI is a virtual laboratory at the frontiers of network science and
engineering for exploring future internets at scale. GENI creates
major opportunities to understand, innovate and transform global
networks and their interactions with society.
• http://www.geni.net/
14. februar 2011 45
Ongoing Initiatives (cont.)
• Norway: • Core Competence and Value Creation in
ICT (VERDIKT)
• 200M NOK 2009
• 200M NOK 2010
• 150M NOK 2011
• The thematic research topics for this
call are Social networks, the Internet
of things and Mobile Internet. These
new research topics in the VERDIKT
programme are key drivers for the
development of the Future Internet,
which is the overall framework for this
call.
• http://www.rcn.no/
14. februar 2011 46
[Source: http://www.worldcountries.info/Maps/Region/Europe-450-Norway.jpg]
POMODO Alternative to IP
• Main points from K. Calverts presentation at
Dagstuhl Workshop on FI, April 2009
• Why do we build networks?
14. februar 2011 47 [Source: K. Calvert Dagstuhl April 2009]
POMODO Alternative to IP
• The network exists to share channels • So name channels instead
• Hmm what does this help us? • Don’t have to change names when changing levels of
abstraction
14. februar 2011 48
[Source: K. Calvert Dagstuhl April 2009]
Topology-based addressing
• Why: • Avoid need for address-assignment authority
• Hierarchical addresses leak information about other
addresses (i.e., attackers can easily guess/enumerate
host addresses)
• Instead: self-configuring, self-certifying Channel
IDs from a large, flat space • ID = hash of public key [cf. CGA]
14. februar 2011 49 [Source: K. Calvert Dagstuhl April 2009]
Base Case
• Link-state discovery of infrastructure channel topology • Nodes advertise willingness to relay packets between channels
• Optionally: QoS-related information
• E.g., classes of service w/pricing, long-term statistics
• Topology/routing service collects information about infrastructure
channels and connectivity
• Topology/routing service computes paths between infrastructure
channels
• Destinations register with EID-to-Locator (E2L) service
14. februar 2011 50 [Source: K. Calvert Dagstuhl April 2009]
Base case (cont.)
14. februar 2011 51 [Source: K. Calvert Dagstuhl April 2009]
Base case (cont.)
14. februar 2011 52 [Source: K. Calvert Dagstuhl April 2009]
Base case (cont.)
14. februar 2011 53 [Source: K. Calvert Dagstuhl April 2009]
Base case – Control Plane
• Locators • Topology/Routing service only knows about (shared)
infrastructure channels
• Locator ties EID to infrastructure topology
• (EID, {path1, ..., pathk})
• EID-to-locator resolution system (part of infrastructure)
• Consequences: • Destinations control whether they are ―findable‖
• Multhihoming is handled naturally
• Additional resolution step
14. februar 2011 54
Locator: (E2, {d, e})
[Source: K. Calvert Dagstuhl April 2009]
Base case – Control Plane (cont.)
14. februar 2011 55 [Source: K. Calvert Dagstuhl April 2009]
Base Case - Forwarding
14. februar 2011 56 [Source: K. Calvert Dagstuhl April 2009]
Base Case - Forwarding
14. februar 2011 57 [Source: K. Calvert Dagstuhl April 2009]
Base Case - Forwarding
14. februar 2011 58 [Source: K. Calvert Dagstuhl April 2009]
Base Case - Forwarding
14. februar 2011 59 [Source: K. Calvert Dagstuhl April 2009]
Base Case - Forwarding
14. februar 2011 60 [Source: K. Calvert Dagstuhl April 2009]
POMODO summary
• Goal of the POMODO presentation: show how we could
do networks without IP
• …. there are more nice ideas in POMODO…
• …. but we put now more emphasis on the ANA approach,
which has some commonalities with POMODO
• …. let’s get a glimps of ANA today and the details later in
the course
14. februar 2011 61
ANA Concepts and Abstractions
• Information Dispatch Point (IDP): address
communication start points
• Functional Block: building blocks to configure
protocols and services
• Information Channel (IC): connect IDPs
• Compartments: or realms, i.e., network units
• Integrated monitoring
• Self-description
14. februar 2011 62
ANA demo by Dani
14. februar 2011 63
Appendix
• Literature: • https://wiki.ittc.ku.edu/pomo_wiki/images/Broadnets.pdf
• Useful links: • https://www.ana-project.org/
• http://www.spovnet.de/
• http://www.dagstuhl.de/en/program/calendar/semhp/?semnr=091
62
• http://www.gta.ufrj.br/horizon/index.php/related-projects
• http://www.asiafi.net/
• See bibliography & links
• https://www.ntt-
review.jp/archive/ntttechnical.php?contents=ntr200905sf2.html
• http://www.springerlink.com/content/e240776641607136/
14. februar 2011 64