Mata Architecture for the Future Network APAN2008 January 23 2008 Myung-Ki SHIN, ETRI  [email_address]
Why Future Network ? <ul><li>The Future Network, which is anticipated to provide futuristic functionalities beyond the lim...
Assumption <ul><li>Incremental Design </li></ul><ul><ul><li>A system is moved from one state to another with incremental p...
Design Goals (1/4) <ul><li>Scalability </li></ul><ul><ul><li>Scalability issue is emerging as continuous growth of cultura...
Design Goals (2/4)   <ul><li>Mobility  </li></ul><ul><ul><li>The FN should support mobility of devices, services, users an...
Design Goals (3/4)   <ul><li>Heterogeneity  </li></ul><ul><ul><li>The FN should provide much better support for a broad ra...
Design Goals (4/4)   <ul><li>Customizability  </li></ul><ul><ul><li>The FN should be customizable along with various user ...
Building Blocks <ul><li>Meta architecture (diverse architecture) </li></ul><ul><li>Architecture </li></ul><ul><li>Mechanis...
Internet vs. FN   Applications TCP/UDP Physical Link IP Current Internet : Architecture – TCP/IP Mechanism – SNMP, IPsec …...
Meta Architecture <ul><li>Network virtualization </li></ul><ul><ul><li>Realize virtual network with programmable network e...
Network Virtualization <ul><li>De-ossifying the current Internet   </li></ul><ul><ul><li>Multiple  virtual networks  co-ex...
Different Arch. & Gateway <ul><li>Tie together heterogeneous networks  </li></ul><ul><ul><li>Gateway spans multiple archit...
Cross-layer Communication <ul><li>Avoid Layered Concept </li></ul><ul><ul><li>Exploit the dependency between protocol laye...
Diverse Communications <ul><li>Original E2E Communication </li></ul><ul><ul><li>Concerned with e2e services and protocols ...
Architecture Components  <ul><li>Network addressing and naming  </li></ul><ul><li>Routing protocols  </li></ul><ul><li>Bac...
Mechanisms <ul><li>Wireless </li></ul><ul><ul><li>Cognitive </li></ul></ul><ul><ul><li>Cooperative  </li></ul></ul><ul><ul...
Service/Applications <ul><li>Sensor </li></ul><ul><li>Vehicle/aircraft </li></ul><ul><li>Emergency </li></ul><ul><li>Satel...
Next Steps <ul><li>It’s time to start discussing the FUTURE. </li></ul><ul><li>ETRI, KT and Samsung AIT will start the wor...
Upcoming SlideShare
Loading in …5
×

download

217
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
217
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

download

  1. 1. Mata Architecture for the Future Network APAN2008 January 23 2008 Myung-Ki SHIN, ETRI [email_address]
  2. 2. Why Future Network ? <ul><li>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. </li></ul><ul><li>We see a growing demand for following features: </li></ul><ul><ul><li>Scalability, security, mobility, Quality of Service (QoS), robustness, heterogeneity, economic incentives, etc. </li></ul></ul><ul><li>Also, the Future Network will be more deeply integrated and composed with new emerging technologies and services </li></ul><ul><ul><li>E.g., Intermittent network, DTN (Delay-Tolerant Network), vehicular/airborne network, programmable and cognitive networks </li></ul></ul>
  3. 3. Assumption <ul><li>Incremental Design </li></ul><ul><ul><li>A system is moved from one state to another with incremental patches </li></ul></ul><ul><ul><li>How should the Internet look tomorrow ? </li></ul></ul><ul><li>Clean-Slate Design </li></ul><ul><ul><li>The system is re-designed from scratch </li></ul></ul><ul><ul><li>How should the Internet look in 15 year ? </li></ul></ul><ul><li>It is assumed that the current IP’s shortcomings will not be resolved by conventional incremental and “backward-compatible” style designs. </li></ul><ul><li>So, the Future Network designs must be made based on clean-slate approach. </li></ul>
  4. 4. Design Goals (1/4) <ul><li>Scalability </li></ul><ul><ul><li>Scalability issue is emerging as continuous growth of cultural demands for networking in the future. </li></ul></ul><ul><ul><ul><li>Routing and addressing architecture </li></ul></ul></ul><ul><ul><ul><li>Multi-homing and PI routing </li></ul></ul></ul><ul><li>Security </li></ul><ul><ul><li>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 . </li></ul></ul>
  5. 5. Design Goals (2/4) <ul><li>Mobility </li></ul><ul><ul><li>The FN should support mobility of devices, services, users and/or groups of those as seamlessly, as it supports current wired and wireless </li></ul></ul><ul><ul><ul><li>Supporting New Devices/Networks </li></ul></ul></ul><ul><ul><ul><li>Context-awareness </li></ul></ul></ul><ul><ul><ul><li>Multi-homing and Seamless Switching </li></ul></ul></ul><ul><li>Quality of Service </li></ul><ul><ul><li>The FN should support quality of service (QoS) from user and/or application perspectives. </li></ul></ul>
  6. 6. Design Goals (3/4) <ul><li>Heterogeneity </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><ul><li>Application/Service Heterogeneity </li></ul></ul></ul><ul><ul><ul><li>Physical Media Heterogeneity </li></ul></ul></ul><ul><ul><ul><li>Architecture Heterogeneity </li></ul></ul></ul><ul><li>Robustness </li></ul><ul><ul><li>The FN should be robust, fault-tolerant and available as the wire-line telephone network is today. </li></ul></ul><ul><ul><ul><li>Re-configurability </li></ul></ul></ul><ul><ul><ul><li>Manageability </li></ul></ul></ul>
  7. 7. Design Goals (4/4) <ul><li>Customizability </li></ul><ul><ul><li>The FN should be customizable along with various user requirements. </li></ul></ul><ul><ul><ul><li>Context-Aware Numbering and Content-Centric Service </li></ul></ul></ul><ul><ul><ul><li>Service-Specific Overlay Control and Service Discovery </li></ul></ul></ul><ul><li>Economic Incentives </li></ul><ul><ul><li>The FN shall provide economic incentives to the components/participants that contribute to the networking. </li></ul></ul>
  8. 8. Building Blocks <ul><li>Meta architecture (diverse architecture) </li></ul><ul><li>Architecture </li></ul><ul><li>Mechanism </li></ul><ul><li>Service/ applications </li></ul>
  9. 9. Internet vs. FN Applications TCP/UDP Physical Link IP Current Internet : Architecture – TCP/IP Mechanism – SNMP, IPsec … Application – Web, E-mail … Meta Architecture for the FN Application #1 Transport & Network #1 Link & Physical #1 Application #2 Transport & Network #2 Link & Physical #2 Application #N Transport & Network #N Link & Physical #N … .. FN : Meta Architecture : Architectures Architecture Architecture – TCP/IP, Intermittent X, …. Mechanism – SNMP, IPsec, Cognitive, Cooperative, … Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite …
  10. 10. Meta Architecture <ul><li>Network virtualization </li></ul><ul><ul><li>Realize virtual network with programmable network elements. </li></ul></ul><ul><ul><li>Multiple architectures architecture or no architecture </li></ul></ul><ul><li>Federation of different architecture regions   </li></ul><ul><ul><li>Heterogeneous networks with heterogeneous architectures connected with gateway </li></ul></ul><ul><li>Cross-layered architecture </li></ul><ul><ul><li>Violate strict layering abstraction </li></ul></ul><ul><ul><li>Instead, use other layers’ functionalities (APIs) to do something efficiently </li></ul></ul><ul><li>Diverse models of the end-to-end principle </li></ul>
  11. 11. Network Virtualization <ul><li>De-ossifying the current Internet </li></ul><ul><ul><li>Multiple virtual networks co-exist on top of a shared substrate . </li></ul></ul><ul><ul><li>Different virtual networks provide alternate end-to-end packet delivery systems and may use different protocols and packet formats. </li></ul></ul><ul><ul><li>Easily programmable </li></ul></ul><ul><ul><ul><li>Can experiment on any level (optical to apps) </li></ul></ul></ul><ul><li>E.g., GENI (Global Environment for Network Innovations) </li></ul>
  12. 12. Different Arch. & Gateway <ul><li>Tie together heterogeneous networks </li></ul><ul><ul><li>Gateway spans multiple architecture regions that use different protocols </li></ul></ul><ul><ul><li>Applications can communicate across multiple architecture regions </li></ul></ul><ul><li>E.g., DTN Bundle Layer and Gateway </li></ul>
  13. 13. Cross-layer Communication <ul><li>Avoid Layered Concept </li></ul><ul><ul><li>Exploit the dependency between protocol layers to obtain performance gains </li></ul></ul><ul><ul><li>Direct communication between protocols at nonadjacent layers or sharing variables between layer </li></ul></ul><ul><ul><ul><li>Optimization  Abstraction </li></ul></ul></ul><ul><li>E.g., Cross-layer communication for wireless mobile network </li></ul><ul><ul><li>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 </li></ul></ul>
  14. 14. Diverse Communications <ul><li>Original E2E Communication </li></ul><ul><ul><li>Concerned with e2e services and protocols implemented in hosts, such as transport protocols and implementation architecture for high performance. </li></ul></ul><ul><li>EME (End-Middle-End) Communication </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>The current Internet architecture does not reflect this resulting in a mismatch between design and practice. </li></ul></ul><ul><ul><li>There are some signaling based solutions to connection establishment </li></ul></ul>
  15. 15. Architecture Components <ul><li>Network addressing and naming </li></ul><ul><li>Routing protocols </li></ul><ul><li>Backbone design </li></ul><ul><li>Circuit & Packet </li></ul><ul><li>Heterogeneous physical layers </li></ul><ul><li>Heterogeneous applications </li></ul><ul><li>Security </li></ul>
  16. 16. Mechanisms <ul><li>Wireless </li></ul><ul><ul><li>Cognitive </li></ul></ul><ul><ul><li>Cooperative </li></ul></ul><ul><ul><li>Coopcom </li></ul></ul><ul><ul><li>Viral network </li></ul></ul><ul><li>Optical </li></ul><ul><li>P2P </li></ul><ul><ul><li>DHT </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>Self-revealing content </li></ul></ul><ul><ul><li>Public key/ ECC </li></ul></ul><ul><li>Manageability </li></ul><ul><ul><li>High level Abstraction </li></ul></ul>
  17. 17. Service/Applications <ul><li>Sensor </li></ul><ul><li>Vehicle/aircraft </li></ul><ul><li>Emergency </li></ul><ul><li>Satellite </li></ul><ul><li>Energy/power </li></ul>
  18. 18. Next Steps <ul><li>It’s time to start discussing the FUTURE. </li></ul><ul><li>ETRI, KT and Samsung AIT will start the works. </li></ul><ul><li>Success Scenarios </li></ul><ul><ul><li>Figure out the design goal and requirements </li></ul></ul><ul><ul><li>Clean-slate designs and meta architecture </li></ul></ul><ul><ul><li>Prototype, experiment, and testbeds </li></ul></ul><ul><ul><li>Spiral development cycle </li></ul></ul>

×