Future Internet future internet - MDPI Open Access Journals Platform
Review and Prospect on Future Internet Architectures is an architecture for the Cloud-based Future...
Transcript of Review and Prospect on Future Internet Architectures is an architecture for the Cloud-based Future...
KRNET 2014 ⓒ Woojik Chun
Review and Prospect on
Future Internet Architectures
2
Contents
What is the Future Internet ? 1
3
4
5
Future Internet – Paradigm Shift
Future Internet – Technical Issues
6 Concluding Remarks
Future Internet - Prospects
2 Future Internet – Architecture Review
3
What is the Internet ?
The Internet joining many government, university and private computers
together
providing an infrastructure for the use of E-mail, bulletin boards, file archives, hypertext documents, databases and other computational services
A single huge space w.r.t IP address for delivering of data and messages From anywhere in a host to anywhere
in the world.
Space of the Internet Routing? Metric space (IGP) Topological space (BGP)
4
What is the Future Internet ?
Narrow Sense Solutions on Limitations of
the current TCP/IP based Internet
Broad Sense Future Networked Services
and Applications
Common Sense Shared Information Infra
Union of heterogeneous networks
A set of rules for interworking among autonomous systems
Service Infra
Network Infra
Services, Applications
Heterogeneous Networks
5
Future Internet : Two Different Views
Network Centric View Service Centric View
Limitation of
current Internet
New Core Tech.
(Content, virtualization)
Emerging New networked
applications
Clean slate
Internet Research
Outputs:
Novel network/protocol concepts
Future Internet architecture ideas
Influence on current IP standards
Approaches to fixed-mobile convergence
Possible clean-slate deployments
New classes of applications
Inte
rnet
by a
nd fo
r People
Inte
rnet o
f Conte
nts
and K
now
ledge
Inte
rnet
of T
hin
gs
In
tern
et
of S
erv
ices
Network Infra
(Internet of networks)
Future Networked Society
6
Future Internet : Major Researches
Named Data Networking (Lixia Zhang, UCLA) moves the communication paradigm from today's focus on
"where", i.e., addresses, servers, and hosts, to "what", i.e., the content that users and applications care about
NEBULA(Jonathan Smith, U Penn) addresses the technical challenges in creating a cloud-computing-
centric architecture
MobilityFirst (D. Raychaudhuri, Rutgers University) dealing with mobility as a first class entity allows functionalities
like context and location-aware services to fit naturally into the network
eXpressive Internet Architecture (P. Steenkiste, CMU) exploring the technical challenges in creating a single network
that offers inherent support for communication between current communicating principals--including hosts, content, and services--while accommodating unknown future entities
SAIL-NetInf (EU FP-7) focuses on the information itself, not on the location of the
information.
7
NDN (Named Data Networking)
Principal Investigator Lixia Zhang, UCLA
Collaborating Institutions Colorado State University,
PARC,
University of Arizona,
University of Illinois/Urbana-Champaign,
UC Irvine,
University of Memphis,
UC San Diego,
Washington University,
Yale University
http://www.named-data.net/
8
NDN: Motivation
9
NDN: Internet Today
src
dst
X
Path determined by global routing, not local choice
Structural asymmetry precludes market mechanisms and
encourages monopoly formation
10
Producer
Consumer
a/b
NDN: approach
Packets say ‘what’ not ‘where’ (no src or dst)
Forwarding decision is local
Upstream performance is measurable
11
Producer
Consumer
a/b/c/d
Data
a/b/c/d
Each Router may Cache the Contents at the Content Store
Structural asymmetry precludes market mechanisms and
encourages monopoly formation
NDN: approach
12
NDN : Operation
A
Pending Interest Table Forwarding Information Base
Face 2
:
Face 2
Face 1
Face 1
Face 1
Face 3
Content Store
6 hour
2 hour
:
movie.red.*
movie.blue.*
movie.green.*
movie.violet.*
movie.blue.*
movie.yellow
NDN Operation Example Ref: SNU MMLab
13
NDN : Summary
Send / Receive Publish / Subscribe (Interest)
Sender-driven Receiver-driven
Host Names Data Names
Host Reachability Information Scoping
Channel Security Self-Certifying Metadata
Unicacst Multicast
14
Nebula
Principal Investigator: Jonathan Smith, University of Pennsylvania
Collaborating Institutions: Cornell University,
Massachusetts Institute of Technology,
Princeton University,
Purdue University,
Stanford University,
Stevens Institute of Technology,
University of California/Berkley,
University of Delaware,
University of Illinois/Urbana-Champaign,
University of Texas,
University of Washington
15
Nebula : Motivation
NEBULA is an architecture for the Cloud-based Future Internet More secure and reliable
Deployable and evolvable
Truly clean-slate
Technology, Economics and Policy continue to evolve NEBULA co-design with Economist and Lawyer on team
Motivation for a new architecture: Availability: Risk of network outages
Security: Poor endpoint authentication
Consistency: Communications end point focused, not data focused
16
Nebula: Architecture and Principles
Architecture: Services provided by cloud data centers
Multiple cloud providers, that each use replication
Agreements for "roaming" allow user to connect to nearest center
Variety of access mechanisms (wired & wireless)
Transit networks to connect access to data centers
Principles Ultra reliable, high-speed core interconnecting data centers
Parallel paths between data center and core router
Secure access and transit
Policy-based path selection
Authentication during connection establishment
17
Nebula: Building Blocks
NDP – NEBULA Data Plane Distributed path establishment with guarantees
NVENT – NEBULA Virtual and Extensible Networking Techniques Extensible + Policy control plane
NCore - NEBULA Core Redundantly connected high availability routers
18
Nebula : summary
Architecture specific to the cloud service Access network
Transit network
Core network
Research Issues NDP run on multiple paths?
Realm ( ~ AS)
Mapping to intra-domain / inter-domain
Public-Key infrastructure
Control enforcement
19
MobilityFirst
Principal Investigator Dipankar Raychaudhuri,
Rutgers University/New Brunswick
Collaborating Institutions Duke University,
Massachusetts Institute of Technology,
University of Massachusetts/Amherst,
University of Massachusetts/Lowell,
University of Michigan,
University of Nebraska/Lincoln,
University of North Carolina/Chapel Hill
20
MobilityFirst: Motivations
Naming and addressing DNS binds a host name to an IP address.
DNS is designed to be queried frequently but updated slowly.
Caching enables scalability at the cost of update-propagation delay.
Routing Aggregation of IP addresses into prefixes is central to routing scalability.
Host mobility is assumed to be infrequent enough
an indirect routing approach inefficient
Network mobility (e.g., mobile networks of vehicles, planes, or VMs) scales poorly with the Internet's inter-domain routing protocol.
Disruption-tolerance TCP/IP stack assumes that hosts and routers are stationary long enough
the routing protocol can compute a contemporaneous end-to-end path
the transport protocol can respond to end-to-end loss and congestion signals.
TCP/IP stack falls short in emerging wireless scenarios (vehicular, sensor).
21
MobilityFirst: Principles
Mobility as the norm
Seamless host and network mobility at scale;
Multi-provider mobile network access
Heterogeneous wireless technologies.
Robustness
with respect to intrinsic properties of wireless medium
(disconnection, varying bandwidth, high error rates, scarce spectrum).
Trustworthiness
Enhanced security for mobile networks and wired infrastructure
Usability
Architectural support for context-aware pervasive mobile services
evolvable core network services
network manageability
economic viability, regulability and universal access.
22
MobilityFirst: Name and Address Separation
Separation of names (ID) from network addresses (NA)
Globally Unique Name(GUID) User Name, Device ID,
Context, AS name …
Multiple domain-specific naming service
Global Name Resolution Service GUID -> NA mapping
Hybrid GUID/NA approach Both name/address in PDU
“fast Path” when NA is available
Late binding option
23
MobilityFirst: Summary
Network = collection of independent access networks
Mapping from Host GUID to network addresses (NA) GNRS based on DHT
No recursion on networks
24
XIA (eXpressive Internet Architecture)
Principal Investigator Peter Steenkiste, Carnegie Mellon University
Collaborating Institutions Boston University,
University of Wisconsin/Madison
25
XIA: Visions
Users & appl. must be able to express their intent Principals express their intent
Multi-Principals supports communication between diverse entities (eg., hosts,
services, contents, …)
Support an evolvable set principals for comm.
allows “late binding'' to a particular host or set of hosts
Intrinsic Security extend AIP(Accountable Internet Protocol)
Communicating entities are named by their public keys
Narrow waist For trust management
Defines the API between principals and network protocol mechanisms
26
XIA: Multiple Principal Types
27
XIA : DAG with Fallbacks
A node can have multiple outgoing edges
Outgoing edges have priority among them Forwarding to HIDS is attempted if forwarding to CIDA is not
possible – Realization of fallbacks
CIDA
HIDS
Fallback edge (low priority edge)
27
Primary edges
Intermediate node
28
XIA : Path Selection in SCION
28
Source Destination
PCB PCB PCB PCB
Source/destination can choose among up/down hill paths Path control shared between ISPs,
receivers, senders
Desirable security properties: High availability, even in
presence of malicious parties
Explicit trust for operations
Minimal TCB: limit number of entities that must be trusted
No single root of trust
Simplicity, efficiency, flexibility, and scalability
29
XIA : Summery
End-to-end transport over heterogeneous networks and for multiple principals Error control, congestion control, …
How to better support wireless mobile users, insertion of services, vehicular, DTNs, …
Trustworthy network operations Improve “security” broadly defined by leveraging the intrinsic
security properties of XIA
Focus on availability and systematic approaches to trust management
DAG No “ID – Locator separation”
Overhead on packet header
30
SAIL-NetInf
Started in the EU project 4WARD
continued in the follow-on project SAIL Motivatio
31
SAIL-NetInf : Model
Trustable copies of Information Even on untrusted server and connection
32
SAIL-NetInf : Self-Certification
Prevent unauthorized changes, ensure data integrity
Static content Include hash(content) in ID Label field
Verification: compute hash(retrieved data) and compare to hash in ID
Dynamic content Storing hash(dyn.content) in ID would violate ID persistence
Use signature [SK(attributes)] in ID instead
Verification: Verify that signature is correct and corresponds to PKIO
Type A=Hash(PKIO) L={attributes}
Security Metadata
SKIO
33
SAIL-NetInf : Operation
34
SAIL-NetInf : Summary
Based on unique name on information
Based on Receiver-Initiated transmission
Supports heterogeneous networks
flexibility applicability, innovation
35
Paradigm Shift : Evolution of Networks
+82-42-860-1234
Number (Wire) Specify How switching
168.2.10.3
Address (Interface) Specify Where routing
3AEF098D5F4E7C00
ID (Host/Data/Service/Thing)
Specify What locating path selection
36
Paradigm Shift : ID-LOC separation
ID-Locator combined Relation may be encoded in ID itself
Ex: Ordering, Grouping(prefix aggregation, hashing, etc.)
Relation may obtained by external interactions
Ex: Configuration, Learning, Routing Protocols
ID-Locator Separated ID itself has no clue for locating the entity
Locator is independent from the entity
Entity may be bound to locations on multiple spaces
Why should ID be separated from Locator? ID is used as a unique name for the intended entity
Locator is used as a locatable address for entities
ID may be mapped onto multiple locators
Space where the locator is defined determines the mechanism
37
Paradigm Shift : Entity and Environment
Entity-Environment Separation an entity itself is independent from its environment
Entity may exist in multiple heterogeneous environments
Communication services are provided by multiple environments
Connect to the entity Wherever it happens to be
Entities belong to environment Entities separated from environment
Connect to Whatever happens to be
at the location
38
Paradigm Shift : Intent-Mechanism Separation
Intent-Mechanism Combined Network directs instructions
Where you are
How you can do
User selects mechanism
Network performs protocols
Moved network (address) change
Intent-Mechanism Separated User specifies intent
What(Who) I am
What I want to contact
Network selects mechanism
Network finds protocols
Moved just path change
Instructions Intents
39
Polymorphic Enable different cooperation
paradigms in parallel.
Enable easy deployment of new mechanisms.
Without raising routing and addressing to the application
IP Layer
DNS
Media Media Media
ID API
Appl. Contents service
ID Loc Mapping
Polym
orp
hic
Net
Polym
orp
hic
Net
Polym
orp
hic
Net
Paradigm Shift : Polymorphic networks
Holomorphic Based on the IP Protocol
Dependent to addressing and routing
Vulnerable to attack
Hard to evolve
40
Paradigm Shift : Horizontal Layers
Vertical Function Layers Functional decomposition
within an element peer-to-peer protocols System Engineer View
TCP
IP
DL/PHY
Appl.
TCP
IP
DL/PHY
Appl.
IP
DL/PHY
Appl. GW.
GW GW
GW Host
Local Regional global
Logical Domains Logical Domains GW.
GW.
Horizontal Network Layers Spatial decomposition of
space (domain structuring) Sequence of Gateways Network Architect View
Suspension Bridge Model Arch Bridge Model
domains
41
Paradigm Shift : Structured Network Spaces
Traditional Networks No formal definitions on
network structures
Tech. may defines the network structures
Each layer implicitly defines its coverage
Future Networks Abstraction of networks
Recursive Domains
Domain
domain
domain
Abstract network view
Control Interface
Packet
Inte
rface
Recursive network view
domain
42
Paradigm Shift : Views on networks
Host 1 Host 2
Node 1 Node 2
Element (Entity) View Network = A set of
interconnected elements
Functionality of elements (protocol stacks)
Space (Relation) View Network = A space where
comm. entities may exist
Relations on the space
(interactions with environment)
43
Technical Issues
ID Based Communications
Named Data Networks
Mobility First eXpressive
Internet Arch. Nebula SAIL (EU) …
Common Issues
Entry explosion Routing scalability Vulnerable to attack
Reactive Path Setup - Path Setup when being required
Fish Eye Routing - nearer finer - farther coarser
Trust Domain - Certification when ID is registered at a domain - Trust relation of domains
Domain
Forwarding
Cache
GW
Domain Domain Domain
Path Discovery Protocol
44
Technical Issues : Incremental Deployment
Control Plane
(Controller Hierarchy)
Data Plane
(Recursive
Domains)
45
Prospects : Learn from History
Learn from History Internet : starts as an overlay of telephone networks
Successful patches
Urgent Issues : Congestion control of TCP
Local solution : NAT, Firewall, IDS
Isolated upgrade : MPLS, routing Protocols
Overlay solutions : P2P, Social Networks, CCN
Failed Trial
No flag day : IPv6
Too stubborn principles : RSVP
How long shall the current Internet continue? Only by patches and overlays ?
When will the Future Internet come?
46
Prospects : Goals of Future Internet
Propose a new Architecture for Future Internet Redesign the internet from scratch
Rethink the layer model
Rethink the End-to-End Principle
Take account of new requirements Functionalities : Mobility, Security, Autonomicity
New Technologies : sensor, Ad-hoc, PAN
However, tolerant to the existing networks assume less homogeneity
provide minimal rules for interworking among dissimilar networks
allow packet translation in intermediate nodes
Revolutionary Concepts but Evolutionary Deployments
47
Concluding Remarks
New Era of Network Science Craft Science
Two major techniques Abstraction
Recursion
What Future Internet has to do? Build shared infra with richer
capabilities
Show incentives to adaptors of new concepts
Suggest graceful migration plans from the existing Networks Not “backward compatibility” but
“adaptability”
DIANA Domain-Insulated
Autonomous Network
Architecture