Transcript Presentation

Thinking of Architecture
for Future Internet
[email protected], Choong Seon Hong, KHU
Recall of Internet (’74)
2

Design Goals









(0) To connect existing networks
(1) Survivability
(2) To support multiple types of services
(3) To accommodates a variety of physical networks
(4) To allow distribute network management
(5) To be cost effective
(6) To allow host attachment with a low level of effort
(7) To allow resource accountability
Design Principles





Layering (design goal – 0, 3)
Packet Switching (design goal – 5)
A network of collaborating networks (design goal – 1, 4)
Intelligent end-system / end-to-end arguments (design goal – 1, 5)
DHCP (design goal – 6), SNMP (design goal – 7)
Changes of Networking
3

Environment
 Trusted

=> Untrusted
Users
 Researchers

Operators
 Nonprofits

=> Customers
=> Commercial
Usages
 Host-oriented

=> Data-centric
Connectivity
 E2E
IP => Intermittent Connection
Assumptions
4

Incremental Design



Clean-Slate Design



A system is moved from one state to another with incremental patches
How should the Internet look tomorrow ?
 IETF and IPv6 perspective
The system is re-designed from scratch
How should the Internet look in 15 year ?
 Future Internet
It is assumed that the current IP’s shortcomings will not be
resolved by conventional incremental and “backward-compatible”
style designs. So, the Future Internet designs must be made
based on clean-slate approach.
Problem Statement (1/4)
5
1. Basic Problems
1.1. Routing Failures and scalability

The problems have been examined as being caused by mobility,
multi-homing, renumbering, PI routing, IPv6 impact, etc. on the
current Internet architecture.
1.2. Insecurity

As current communication is not trusted, problems are self-evident,
such as the plague of security breaches, spread of worms, and denial
of service attacks.
1.3. Mobility


Current IP technologies was designed for hosts in fixed locations, and
ill-suited to support mobile hosts.
Mobile IP was designed to support host mobility, but Mobile IP has
problems on update latency, signaling overhead, location
privacy, etc.
Problem Statement (2/4)
6
1. Basic Problems
1.4. Quality of Service
 Internet architecture is not enough to support quality of service from
user or application perspective.
 It is still unclear how and where to integrate different levels of quality
of service in the architecture.
1.5. Heterogeneous Physical Layers and Applications
 Recently, IP architecture is known as a “narrow waist or thin waist”.
 Physical Layers and Applications heterogeneity poses tremendous
challenges for network architecture, resource allocation, reliable
transport, context-awareness, re-configurability, and security.
1.6. Network Management
Narrow Waist for
Internet Hourglass
 The original Internet lacks in management plane.
(Common Layer = IP)
Source : Steve Deering,
IPv6 :addressing the future
Problem Statement (3/4)
7
1. Basic Problems
1.7. Congestive Collapse
Current TCP is showing its limits in insufficient dynamic range to handle
high-speed wide-area networks, poor performance over links with
unpredictable characteristics, such as some forms of wireless link, poor
latency characteristics for competing real-time flows, etc.
1.8 Opportunistic and Fast Long-Distance Networks
Original Internet was designed to support always-on connectivity, short
delay, symmetric data rate and low error rate communications, but
many evolving and challenged networks do not confirm to this design
philosophy.
 E.g., Intermittent connectivity, long or variable delay, asymmetric data
rates, high error rates, fast long-distance communications, etc.
 1.9. Economy and Policy
The current Internet lacks explicit economic primitives.
There is a question of how network provider and ISP continue to make
profit.
Problem Statement (4/4)
8
2. Problems with Original Design Principles
2.1. Packet Switching

Packet switching is known to be inappropriate for the core of
networks and high capacity switching techniques (e.g., Terabit).
2.2. Models of the End-to-End Principle


The Models of the end-to-end principle have been progressively
eroded, most notably by the use of NATs, which modify addresses,
and firewalls and other middle boxes
End hosts are often not able to connect even when security policies
would otherwise allow such connections.
2.3. Layering


Layering was one of important characteristics of current IP
technologies, but at this phase, it has inevitable inefficiencies.
One of challenging issues is how to support fast mobility in
heterogeneous layered architecture.
Future Internet
9
Internet: Success Story
10






Packet Switching (1962)
ARPANet (1969)
Internet Concept (1974) : “inter-net”
TCP/IP protocol suite (1978)
1st IETF meeting at San Diego (1986)
World Wide Web (1993)
New Design Goals
11








Scalability
Security
Mobility
Quality of Service
Heterogeneity
Robustness
Customizability
Economic Incentives
Design Goals (1/4)
12

Scalability
 Scalability
issue is emerging as continuous growth of
cultural demands for networking in the future.
 Routing and addressing architecture
 Multi-homing and PI routing

Security
 The
FN should be built on the premise that security
must be protected from the plague of security
breaches, spread of worms and spam, and denial of
service attacks, etc .
Design Goals (2/4)
13


Mobility
The FN should support mobility of devices, services,
users and/or groups of those as seamlessly, as it
supports current wired and wireless
 Supporting New Devices/Networks
 Context-awareness
 Multi-homing and Seamless Switching

Quality of Service
 The
FN should support quality of service (QoS) from
user and/or application perspectives.
Design Goals (3/4)
14

Heterogeneity
 The
FN should provide much better support for a broad
range of applications/services and enable new
applications/services. In addition, it should accommodate
heterogeneous physical environments.
 Application/Service Heterogeneity
 Physical Media Heterogeneity
 Architecture Heterogeneity

Robustness
 The
FN should be robust, fault-tolerant and available as
the wire-line telephone network is today.
 Re-configurability
 Manageability
Design Goals (4/4)
15

Customizability
 The
FN should be customizable along with
various user requirements.
 Context-Aware Numbering and Content-Centric Service
 Service-Specific Overlay Control and Service Discovery

Economic Incentives
 The
FN shall provide economic incentives to the
components/participants that contribute to the
networking.
Building Blocks
16
Meta architecture (diverse architecture)
 Architecture
 Mechanism
 Service/ applications

Internet vs. FI
17
Current Internet :
Architecture – TCP/IP (Narrow Arch.)
Mechanism – SNMP, IPsec …
Application – Web, E-mail …
FI :
Meta Architecture : Multiple Architectures Architecture
Architecture – TCP/IP, Intermittent X, ….
Mechanism – SNMP, IPsec, Cognitive, Cooperative,
Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite
Meta Architecture
18

Network virtualization
Realize virtual network with programmable network
elements.
 Multiple architectures architecture or no architecture


Federation of different architecture regions

Heterogeneous networks with heterogeneous architectures
connected with gateway

New layered architecture



Violate strict layering abstraction
Instead, use other layers’ functionalities (APIs) to do
something efficiently
Diverse models of the end-to-end principle
Network Virtualization
19

De-ossifying the current Internet
 Multiple
virtual networks co-exist on top of a
shared substrate.
 Different virtual networks provide alternate end-to-end
packet delivery systems and may use
different protocols and packet formats.
 Easily programmable
 Can

experiment on any level (optical to apps)
E.g., GENI (Global Environment for Network
Innovations)
GENI : Block Diagram
20
Testbed vs. Infrastructure
21


GENI in Progress
Success Story (spiral
development)
• PlanetLab : http://www.planet-lab.org
• VINI (Virtual Network Infrastructure)
http://www.vini-veritas.net
PlanetLab(1)
22

What is PlanetLab?

Consortium: joint Academic, Government, Industry venture
 Formally formed January 2004
 Hosted by Princeton University, UC Berkeley, and U. of Washington
 United States Government funded (NSF and DARPA)
 Hewlett Packard and Intel as founding Industrial members


AT&T, France Telecom, Polish Telecom, Google, NEC, …
Facility: Planetary-scale “overlay” and “underlay” network
 700+ Linux-based servers at 300+ sites in 30+ countries
 Researchers can get a virtual machine on each server (SLICE)
 In a SLICE across PlanetLab researchers can deploy & evaluate …
 … distributed systems services and applications
“The next Internet will be created as an overlay in the current one”
 … network architectures and protocols
“The new Internet will be created in parallel next to the current one”
PlanetLab(2)
23

PlanetLab Facility Today



784 servers at over 382 sites
Co-located throughout the (developed) world @ Uni. & Companies
Co-located at network crossroads (Internet2, RNP, CERNET, …)
PlanetLab(3)
24

The Importance of Systems Building
 Systems-oriented CS research needs to build and try
out its ideas to be effective
 Paper designs are just idle speculation
 Simulation is only occasionally a substitute
 We need:
 Real implementation
 Real experience
 Real network conditions
 Real users
 To live in the future
PlanetLab(4)
25

Limitations of Traditional Approaches
 Simulation
based on limited models
 Topologies,
 Emulation
 Only
administrative policies, workloads, failures…
(and “in lab” tests) are similarly limited
as good as the models
 Conventional
 Not
testbeds are (too narrowly) targeted
cost-effective to test every good idea
 Often of limited reach; no real users
 Often with limited programmability
VINI (1)
26


VINI is a virtual network infrastructure that allows network
researchers to evaluate their protocols and services in a realistic
environment that also provides a high degree of control over
network conditions. VINI allows researchers to deploy and
evaluate their ideas with real routing software, traffic loads, and
network events. To provide researchers flexibility in designing
their experiments, VINI supports simultaneous experiments with
arbitrary network topologies on a shared physical infrastructure.
VINI currently consists of 37 nodes at 22 sites connected to the
National LambdaRail, Internet2, and CESNET (Czech Republic).
VINI(2)
27

The maps below show our current VINI deployments
Internet2 Deployment
Different Arch. & Gateway
28

Tie together heterogeneous networks
 Gateway
spans multiple architecture regions that
use different protocols
 Applications can communicate across multiple
architecture regions

E.g., DTN Bundle Layer and Gateway
DTNs
29


Delay-Tolerant Networking (DTN) is an approach to computer
network architecture that seeks to address the technical issues in
mobile or extreme environments, such as deep-space, that lack
continuous network connectivity
Goals
 Support interoperability across ‘radically heterogeneous’ networks
 Tolerate delay and disruption
 Acceptable
performance in high loss/delay/error/disconnected
environments
 Decent performance for low loss/delay/errors

Components
 Flexible naming scheme
 Message abstraction and API
 Extensible Store-and-Forward Overlay Routing
 Per-(overlay)-hop reliability and authentication
Internet vs. DTN Routing
30
Future Wireless Networks
31
Cross-Layer Communications
32

Avoid Layering Concept
 Exploit
the dependency between protocol layers to obtain
performance gains
 Direct communication between protocols at nonadjacent
layers or sharing variables between layer
 Optimization

 Abstraction
E.g., Cross-layer Design for Wireless Mobile Network
 Create
new interfaces between layers, redefine the layer
boundaries, design protocol at a layer based on the details
of how another layer is designed, joint tuning of parameters
across layers, or create complete new abstraction
Cross-Layer Design Proposals
33
Source : V. Srivastava et al., Cross-layer design,
IEEE Comm. Magazine, 2005
Diverse E2E Communications
34

Original E2E


Concerned with end-to-end services and protocols implemented
in hosts, such as transport protocols and implementation
architecture for high performance.
 e.g., presentation layer design, application-layer framing, high
performance host interfaces, and efficient protocol implementation
techniques.
EME (End-Middle-End)



While still end-to-end in many ways, connection establishment in the
Internet today involves state and functionality in the middle in the form
of NATs, firewalls, proxies and so on .
The current Internet architecture does not reflect this resulting in a
mismatch between design and practice.
There are some signaling based solutions to connection establishment
Architecture Components
35







Network addressing and naming
Routing protocols
Backbone design
Circuit & Packet
Heterogeneous physical layers
Heterogeneous applications
Security
Architecture (E.g.) (1/2)
36

Data Oriented Network Architecture
 Data dissemination rather than p2p conversation
 DONA : The Data-Oriented Network Architecture

CCN: Content Centric Network
Autonomic Communication
 Manageability
 ANA: Autonomic Network Architectures
 CASCADAS:Component-ware for Autonomic Situation-aware Communications,
and Dynamically Adaptable Services
Bio-Inspired Network
 Use biological concept for network
 Service generation with natural selection/ evolution
 Security with immune system



explores a clean-slate data-centric approach to Internet architecture. The key
observation that motivates this design is that the vast majority of current Internet
usage is data retrieval, where the user cares about content and is oblivious to its
location.
Architecture (E.g.) (2/2)
37

Opportunistic Communication
 Send
packet according to the link condition
 Store & forward
 DTN
 Haggle: A European Union funded project in Situated and
Autonomic Communications

I3
 Mobility
 Internet
indirection infrastructure
I3 (Internet Indirect Infrastructure)
38


Each packet is associated with an id
 this id is used by the receiver to
obtain delivery of the packet.
 host R that inserts a trigger (id, R) in
the i3 infrastructure to receive all
packets with identifier id.
When a host changes its address,
the host needs only to update its
trigger.
 When the host changes its address
from R1 to R2, it updates its trigger
from (id, R1) to (id, R2).
 As a result, all packets with identifiers
id are correctly forwarded to the new
address.
I3 (cont’d)
39


Multicast
Anycast
Mechanisms
40



Wireless
 Cognitive
 Cooperative
 Coopcom: http://www.coopcom.eu.org/home.php
 Viral network
Optical
P2p
 DHT(Distributed Hash Table)




Pastry
Security
 Self-revealing content
 Public key/ ECC
Manageability
 High level Abstraction
Building Block
 Lego like building blocks
Service/Applications
41





Sensor
Vehicle/aircraft
Emergency
Satellite
Energy/power
Global Collaboration (1/3)
42

ISO/IEC JTC1/SC6
 Ad-hoc
Meeting for Future Network (Paris, 4-5
Sept. 2007)
 SC6 Meeting (Geneva, April 2008)
 Trial
 Start
for initiation of NP Ballot within JTC1
New Work from the end of 2008
 It may be almost aligned with possible activities
for the next study period of ITU-T (2009-2012)
Global Collaboration (2/3)
43

ITU-T
 NGN-GSI,
SG13
 New
Question Proposal on the Future Network (Sept.
2007, Geneva
 New Question Proposal on the Future Network (Jan.
2008, Seoul)

SG17
 New
Questions on Future Open System
Communications Technology
Global Collaboration (3/3)
44

IRTF
 The
Chairs of six of the fourteen Research
Groups comprising IRTF have funded FIND
proposals  dtnrg,
 New
eme, end2end, imrg, p2prg, rrg
Works Considered
 Network
virtualization RG
 QoS policy framework RG
 Cross-layer communication in TSV
Conclusions
45



Detailed specifications for optimal architecture?
Implementation and Testbed
Other considerations?
References
46







Myung-ki Shin, Meta Architecture for Future Internet, HSN 2008 Presentation
Material
PlanetLab : http://www.planet-lab.org
VINI (Virtual Network Infrastructure)
http://www.vini-veritas.net
http://i3.cs.berkeley.edu/
IPv6: Addressing the future
http://www.6journal.org/archive/00000012/01/steve_deering.pdf
DTN,
 http://www.cs.berkeley.edu/~demmer/talks/dtn-tutorial-mobihoc-may06.ppt
 http://www.ipnsig.org/reports/DTN_Tutorial11.pdf
Haggle, http://www.haggleproject.org/index.php/Main_Page
Question and Discussion
47