THINKING OF ARCHITECTURE FOR FUTURE INTERNET cshongkhu ac

THINKING OF ARCHITECTURE FOR FUTURE INTERNET cshong@khu. ac. kr, 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 � E 2 E IP => Intermittent Connection

Assumptions 4 Incremental Design A system is moved from one state to another with incremental patches � How should the Internet look tomorrow ? IETF and IPv 6 perspective � Clean-Slate Design 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 “backwardcompatible” style designs. So, the Future Internet designs must be made

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, IPv 6 impact, etc. on the current Internet architecture. 1. 2. Insecurity � As current communication is not trusted, problems are selfevident, 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 �

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 Narrow Waist for Internet Hourglass challenges for network architecture, resource allocation, reliable (Common Layer = IP) transport, context-awareness, re-configurability, and security. 1. 6. Network Management Source : Steve Deering, IPv 6 : addressing the future � The original Internet lacks in management plane.

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.

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 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) 1 st 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 (Qo. S) 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

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 – 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) • Planet. Lab : http: //www. planet-lab. org • VINI (Virtual Network Infrastructure) http: //www. vini-veritas. net

Planet. Lab(1) 22 What is Planet. Lab? � 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 Planet. Lab researchers can deploy & evaluate … … distributed systems services and applications “The next Internet will be created as an overlay in the current one”

Planet. Lab(2) 23 Planet. Lab Facility Today 784 servers at over 382 sites � Co-located throughout the (developed) world @ Uni. & Companies � Co-located at network crossroads (Internet 2, RNP, CERNET, …) �

Planet. Lab(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

Planet. Lab(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 Lambda. Rail, Internet 2, and CESNET (Czech Republic).

VINI(2) 27 The maps below show our current VINI deployments Internet 2 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

Cross-Layer Design Proposals 33 Source : V. Srivastava et al. , Cross-layer design, IEEE Comm. Magazine, 2005

Diverse E 2 E Communications 34 Original E 2 E � 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 p 2 p conversation � DONA : The Data-Oriented Network Architecture � 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. 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

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 I 3 � Mobility � Internet indirection infrastructure

I 3 (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 i 3 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 R 1 to R 2, it updates its trigger from (id, R 1) to (id, R 2). � As a result, all packets with identifiers id are correctly forwarded to the new address.

I 3 (cont’d) 39 Multicast Anycast

Mechanisms 40 Wireless � Cognitive � Cooperative � Coopcom: http: //www. coopcom. eu. org/home. php � Viral network Optical P 2 p � 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 JTC 1/SC 6 � Ad-hoc Meeting for Future Network (Paris, 4 -5 Sept. 2007) � SC 6 Meeting (Geneva, April 2008) Trial � Start for initiation of NP Ballot within JTC 1 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, SG 13 New Question Proposal on the Future Network (Sept. 2007, Geneva New Question Proposal on the Future Network (Jan. 2008, Seoul) SG 17 � 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, end 2 end, imrg, p 2 prg, rrg Works Considered Network virtualization RG Qo. S 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 Planet. Lab : http: //www. planet-lab. org VINI (Virtual Network Infrastructure) http: //www. vini-veritas. net http: //i 3. cs. berkeley. edu/ IPv 6: Addressing the future http: //www. 6 journal. org/archive/00000012/01/steve_deering. pdf DTN, � http: //www. cs. berkeley. edu/~demmer/talks/dtn-tutorial-mobihocmay 06. ppt � http: //www. ipnsig. org/reports/DTN_Tutorial 11. pdf Haggle, http: //www. haggleproject. org/index. php/Main_Page

Question and Discussion 47