Mata Architecture for the Future Network

1. Mata Architecture for the Future Network APAN2008 January 23 2008 Myung-Ki SHIN, ETRI mkshin@etri.re.kr

2. 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

3. 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.

4. 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 .

5. 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.

6. 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

7. 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.

8. Building Blocks • Meta architecture (diverse architecture) • Architecture • Mechanism • Service/ applications

9. Internet vs. FN Applications Meta Architecture for the FN TCP/UDP Application #1 Application #2 Application #N IP Transport & Network #1 Transport & Network #2 Transport & Network #N ….. Link Link & Physical #1 Link & Physical #2 Link & Physical #N Physical 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 …

10. Meta Architecture • 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 • Cross-layered architecture • Violate strict layering abstraction • Instead, use other layers’ functionalities (APIs) to do something efficiently • Diverse models of the end-to-end principle

11. Network Virtualization • 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)

12. 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

13. 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

14. 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

15. Architecture Components • Network addressing and naming • Routing protocols • Backbone design • Circuit & Packet • Heterogeneous physical layers • Heterogeneous applications • Security

16. Mechanisms • Wireless • Cognitive • Cooperative • Coopcom • Viral network • Optical • P2P • DHT • Security • Self-revealing content • Public key/ ECC • Manageability • High level Abstraction

17. Service/Applications • Sensor • Vehicle/aircraft • Emergency • Satellite • Energy/power

18. 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