Transcript Mata Architecture for the Future Network

Mata Architecture for
the Future Network
APAN2008
January 23 2008
Myung-Ki SHIN, ETRI
[email protected]
1
Why Future Network ?

The Future Network, which is anticipated to provide
futuristic functionalities beyond the limitation of the
current network including Internet, is getting a global
attention in the field of communication network and
services.

We see a growing demand for following features:


Scalability, security, mobility, Quality of Service (QoS),
robustness, heterogeneity, economic incentives, etc.
Also, the Future Network will be more deeply integrated
and composed with new emerging technologies and
services

E.g., Intermittent network, DTN (Delay-Tolerant Network),
vehicular/airborne network, programmable and cognitive networks
2
Assumption

Incremental Design



A system is moved from one state to another with
incremental patches
How should the Internet look tomorrow ?
Clean-Slate Design
The system is re-designed from scratch
 How should the Internet look in 15 year ?
It is assumed that the current IP’s shortcomings will
not be resolved by conventional incremental and
“backward-compatible” style designs.
So, the Future Network designs must be made based
on clean-slate approach.



3
Design Goals (1/4)

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 .
4
Design Goals (2/4)

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.
5
Design Goals (3/4)

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
6
Design Goals (4/4)

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.
7
Building Blocks




Meta architecture (diverse architecture)
Architecture
Mechanism
Service/ applications
8
Internet vs. FN
Applications
Meta Architecture for the FN
TCP/UDP
IP
Link
Physical
Application #1
Application #2
Transport &
Network #1
Transport &
Network #2
Link &
Physical #1
Link &
Physical #2
Application #N
…..
Transport &
Network #N
Link &
Physical #N
Current Internet :
Architecture – TCP/IP
Mechanism – SNMP, IPsec …
Application – Web, E-mail …
FN :
Meta Architecture : Architectures Architecture
Architecture – TCP/IP, Intermittent X, ….
Mechanism – SNMP, IPsec, Cognitive, Cooperative, …
Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite …
9
Meta Architecture

Network virtualization



Federation of different architecture regions


Heterogeneous networks with heterogeneous architectures
connected with gateway
Cross-layered architecture



Realize virtual network with programmable network
elements.
Multiple architectures architecture or no architecture
Violate strict layering abstraction
Instead, use other layers’ functionalities (APIs) to do
something efficiently
Diverse models of the end-to-end principle
10
Network Virtualization

De-ossifying the current Internet



Multiple virtual networks co-exist on top of a
shared substrate.
Different virtual networks provide alternate end-toend 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)
11
Different Arch. & Gateway

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
12
Cross-layer Communication

Avoid Layered 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 communication 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
13
Diverse Communications

Original E2E Communication


Concerned with e2e services and protocols implemented in hosts,
such as transport protocols and implementation architecture for
high performance.
EME (End-Middle-End) Communication



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
14
Architecture Components







Network addressing and naming
Routing protocols
Backbone design
Circuit & Packet
Heterogeneous physical layers
Heterogeneous applications
Security
15
Mechanisms

Wireless






Optical
P2P


DHT
Security



Cognitive
Cooperative
Coopcom
Viral network
Self-revealing content
Public key/ ECC
Manageability

High level Abstraction
16
Service/Applications





Sensor
Vehicle/aircraft
Emergency
Satellite
Energy/power
17
Next Steps



It’s time to start discussing the FUTURE.
ETRI, KT and Samsung AIT will start the
works.
Success Scenarios




Figure out the design goal and requirements
Clean-slate designs and meta architecture
Prototype, experiment, and testbeds
Spiral development cycle
18