Thinking of Architecture for Future Internet

1. Thinking of Architecture for Future Internet cshong@khu.ac.kr, Choong Seon Hong, KHU

2. Recall of Internet (’74) • 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)

3. Changes of Networking • Environment • Trusted => Untrusted • Users • Researchers => Customers • Operators • Nonprofits => Commercial • Usages • Host-oriented => Data-centric • Connectivity • E2E IP => Intermittent Connection

4. Assumptions • Incremental Design • A system is moved from one state to another with incremental patches • How should the Internet look tomorrow ? • IETF and IPv6 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 “backward-compatible” style designs. So, the Future Internet designs must be made based on clean-slate approach.

5. Problem Statement (1/4) 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.

6. Problem Statement (2/4) 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 • The original Internet lacks in management plane. Narrow Waist for Internet Hourglass (Common Layer = IP) Source : Steve Deering, IPv6 :addressing the future

7. Problem Statement (3/4) 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.

8. Problem Statement (4/4) 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.

9. Future Internet

10. Internet: Success Story • 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)

11. New Design Goals • Scalability • Security • Mobility • Quality of Service • Heterogeneity • Robustness • Customizability • Economic Incentives

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

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

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

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

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

17. Internet vs. FI FI : Meta Architecture : Multiple Architectures Architecture Architecture – TCP/IP, Intermittent X, …. Mechanism – SNMP, IPsec, Cognitive, Cooperative, Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite Current Internet : Architecture – TCP/IP (Narrow Arch.) Mechanism – SNMP, IPsec … Application – Web, E-mail …

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

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

20. GENI : Block Diagram

21. Testbed vs. Infrastructure • GENI in Progress • Success Story (spiral development) • PlanetLab : http://www.planet-lab.org • VINI (Virtual Network Infrastructure) http://www.vini-veritas.net

22. PlanetLab(1) • 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”

23. PlanetLab(2) • 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, …)

24. PlanetLab(3) • 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

25. PlanetLab(4) • Limitations of Traditional Approaches • Simulation based on limited models • Topologies, administrative policies, workloads, failures… • Emulation (and “in lab” tests) are similarly limited • Only as good as the models • Conventional testbeds are (too narrowly) targeted • Not cost-effective to test every good idea • Often of limited reach; no real users • Often with limited programmability

26. VINI (1) • 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).

27. VINI(2) • The maps below show our current VINI deployments Internet2 Deployment

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

29. DTNs • 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

30. Internet vs. DTN Routing

31. Future Wireless Networks

32. Cross-Layer Communications • 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

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

34. Diverse E2E Communications • 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

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

36. Architecture (E.g.) (1/2) • Data Oriented Network Architecture • Data dissemination rather than p2p 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

37. Architecture (E.g.) (2/2) • 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

38. I3 (Internet Indirect Infrastructure) • 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.

39. I3 (cont’d) • Multicast • Anycast

40. Mechanisms • 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

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

42. Global Collaboration (1/3) • ISO/IEC JTC1/SC6 • Ad-hoc Meeting for Future Network (Paris, 4-5 Sept. 2007) • SC6 Meeting (Geneva, April 2008) • Trial for initiation of NP Ballot within JTC1 • Start 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)

43. Global Collaboration (2/3) • 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

44. Global Collaboration (3/3) • IRTF • The Chairs of six of the fourteen Research Groups comprising IRTF have funded FIND proposals - • dtnrg, eme, end2end, imrg, p2prg, rrg • New Works Considered • Network virtualization RG • QoS policy framework RG • Cross-layer communication in TSV

45. Conclusions • Detailed specifications for optimal architecture? • Implementation and Testbed • Other considerations?

46. References • 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

47. Question and Discussion