Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • There will be problem with scalability. For example Devices will outnumber humans by several orders of magnitude, Mobile IP is not effective, overhead Security: how to embed it, how to cope with heterogeneous networks
  • presentation

    1. 1. Thinking of Architecture for Future Internet [email_address] , Choong Seon Hong, KHU
    2. 2. Recall of Internet (’74) <ul><li>Design Goals </li></ul><ul><ul><li>(0) To connect existing networks </li></ul></ul><ul><ul><li>(1) Survivability </li></ul></ul><ul><ul><li>(2) To support multiple types of services </li></ul></ul><ul><ul><li>(3) To accommodates a variety of physical networks </li></ul></ul><ul><ul><li>(4) To allow distribute network management </li></ul></ul><ul><ul><li>(5) To be cost effective </li></ul></ul><ul><ul><li>(6) To allow host attachment with a low level of effort </li></ul></ul><ul><ul><li>(7) To allow resource accountability </li></ul></ul><ul><li>Design Principles </li></ul><ul><ul><li>Layering (design goal – 0, 3) </li></ul></ul><ul><ul><li>Packet Switching (design goal – 5) </li></ul></ul><ul><ul><li>A network of collaborating networks (design goal – 1, 4) </li></ul></ul><ul><ul><li>Intelligent end-system / end-to-end arguments (design goal – 1, 5) </li></ul></ul><ul><ul><li>DHCP (design goal – 6), SNMP (design goal – 7) </li></ul></ul>
    3. 3. Changes of Networking <ul><li>Environment </li></ul><ul><ul><li>Trusted => Untrusted </li></ul></ul><ul><li>Users </li></ul><ul><ul><li>Researchers => Customers </li></ul></ul><ul><li>Operators </li></ul><ul><ul><li>Nonprofits => Commercial </li></ul></ul><ul><li>Usages </li></ul><ul><ul><li>Host-oriented => Data-centric </li></ul></ul><ul><li>Connectivity </li></ul><ul><ul><li>E2E IP => Intermittent Connection </li></ul></ul>
    4. 4. Assumptions <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><ul><ul><li>IETF and IPv6 perspective </li></ul></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><ul><ul><li>Future Internet </li></ul></ul></ul><ul><li>It is assumed that the current IP’s shortcomings will not be </li></ul><ul><li>resolved by conventional incremental and “backward-compatible” </li></ul><ul><li>style designs. So, the Future Internet designs must be made </li></ul><ul><li>based on clean-slate approach. </li></ul>
    5. 5. Problem Statement (1/4) <ul><li>1. Basic Problems </li></ul><ul><li>1.1. Routing Failures and scalability </li></ul><ul><ul><li>The problems have been examined as being caused by mobility, </li></ul></ul><ul><ul><li>multi-homing, renumbering, PI routing, IPv6 impact, etc. on the </li></ul></ul><ul><ul><li>current Internet architecture. </li></ul></ul><ul><li>1.2. Insecurity </li></ul><ul><ul><li>As current communication is not trusted, problems are self-evident, </li></ul></ul><ul><ul><li>such as the plague of security breaches, spread of worms, and denial </li></ul></ul><ul><ul><li>of service attacks. </li></ul></ul><ul><li>1.3. Mobility </li></ul><ul><ul><li>Current IP technologies was designed for hosts in fixed locations, and </li></ul></ul><ul><ul><li>ill-suited to support mobile hosts. </li></ul></ul><ul><ul><li>Mobile IP was designed to support host mobility, but Mobile IP has </li></ul></ul><ul><li>problems on update latency, signaling overhead, location </li></ul><ul><li>privacy, etc. </li></ul>
    6. 6. Problem Statement (2/4) <ul><li>1. Basic Problems </li></ul><ul><li>1.4. Quality of Service </li></ul><ul><ul><li>Internet architecture is not enough to support quality of service from </li></ul></ul><ul><ul><li>user or application perspective. </li></ul></ul><ul><ul><li>It is still unclear how and where to integrate different levels of quality </li></ul></ul><ul><ul><li>of service in the architecture. </li></ul></ul><ul><li>1.5. Heterogeneous Physical Layers and Applications </li></ul><ul><ul><li>Recently, IP architecture is known as a “ narrow waist or thin waist ”. </li></ul></ul><ul><ul><li>Physical Layers and Applications heterogeneity poses tremendous </li></ul></ul><ul><ul><li>challenges for network architecture, resource allocation, reliable </li></ul></ul><ul><ul><li>transport, context-awareness, re-configurability, and security. </li></ul></ul><ul><li>1.6. Network Management </li></ul><ul><ul><li>The original Internet lacks in management plane. </li></ul></ul>Source : Steve Deering, IPv6 :addressing the future Narrow Waist for Internet Hourglass (Common Layer = IP)
    7. 7. Problem Statement (3/4) <ul><li>1. Basic Problems </li></ul><ul><li>1.7. Congestive Collapse </li></ul><ul><ul><li>Current TCP is showing its limits in insufficient dynamic range to handle </li></ul></ul><ul><ul><li>high-speed wide-area networks, poor performance over links with </li></ul></ul><ul><ul><li>unpredictable characteristics, such as some forms of wireless link, poor </li></ul></ul><ul><ul><li>latency characteristics for competing real-time flows, etc. </li></ul></ul><ul><li>1.8 Opportunistic and Fast Long-Distance Networks </li></ul><ul><ul><li>Original Internet was designed to support always-on connectivity, short </li></ul></ul><ul><ul><li>delay, symmetric data rate and low error rate communications, but </li></ul></ul><ul><ul><li>many evolving and challenged networks do not confirm to this design </li></ul></ul><ul><ul><li>philosophy. </li></ul></ul><ul><ul><li>E.g., Intermittent connectivity, long or variable delay, asymmetric data </li></ul></ul><ul><li>rates, high error rates, fast long-distance communications, etc. </li></ul><ul><li>1.9. Economy and Policy </li></ul><ul><ul><li>The current Internet lacks explicit economic primitives. </li></ul></ul><ul><ul><li>There is a question of how network provider and ISP continue to make </li></ul></ul><ul><ul><li>profit. </li></ul></ul>
    8. 8. Problem Statement (4/4) <ul><li>2. Problems with Original Design Principles </li></ul><ul><li>2.1. Packet Switching </li></ul><ul><ul><li>Packet switching is known to be inappropriate for the core of </li></ul></ul><ul><ul><li>networks and high capacity switching techniques (e.g., Terabit). </li></ul></ul><ul><li>2.2. Models of the End-to-End Principle </li></ul><ul><ul><li>The Models of the end-to-end principle have been progressively </li></ul></ul><ul><ul><li>eroded, most notably by the use of NATs, which modify addresses, </li></ul></ul><ul><ul><li>and firewalls and other middle boxes </li></ul></ul><ul><ul><li>End hosts are often not able to connect even when security policies </li></ul></ul><ul><ul><li>would otherwise allow such connections. </li></ul></ul><ul><ul><li>2.3. Layering </li></ul></ul><ul><ul><li>Layering was one of important characteristics of current IP </li></ul></ul><ul><ul><li>technologies, but at this phase, it has inevitable inefficiencies. </li></ul></ul><ul><ul><li>One of challenging issues is how to support fast mobility in </li></ul></ul><ul><ul><li>heterogeneous layered architecture. </li></ul></ul>
    9. 9. Future Internet
    10. 10. Internet: Success Story <ul><li>Packet Switching (1962) </li></ul><ul><li>ARPANet (1969) </li></ul><ul><li>Internet Concept (1974) : “ inter-net ” </li></ul><ul><li>TCP/IP protocol suite (1978) </li></ul><ul><li>1st IETF meeting at San Diego (1986) </li></ul><ul><li>World Wide Web (1993) </li></ul>
    11. 11. New Design Goals <ul><li>Scalability </li></ul><ul><li>Security </li></ul><ul><li>Mobility </li></ul><ul><li>Quality of Service </li></ul><ul><li>Heterogeneity </li></ul><ul><li>Robustness </li></ul><ul><li>Customizability </li></ul><ul><li>Economic Incentives </li></ul>
    12. 12. Design Goals (1/4) <ul><li>Scalability </li></ul><ul><ul><li>Scalability issue is emerging as continuous growth of </li></ul></ul><ul><ul><li>cultural demands for networking in the future. </li></ul></ul><ul><ul><li>Routing and addressing architecture </li></ul></ul><ul><ul><li>Multi-homing and PI routing </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>The FN should be built on the premise that security </li></ul></ul><ul><ul><li>must be protected from the plague of security </li></ul></ul><ul><ul><li>breaches, spread of worms and spam, and denial of </li></ul></ul><ul><ul><li>service attacks, etc . </li></ul></ul>
    13. 13. Design Goals (2/4) <ul><li>Mobility </li></ul><ul><li>The FN should support mobility of devices, services, </li></ul><ul><ul><li>users and/or groups of those as seamlessly, as it </li></ul></ul><ul><ul><li>supports current wired and wireless </li></ul></ul><ul><ul><li>Supporting New Devices/Networks </li></ul></ul><ul><ul><li>Context-awareness </li></ul></ul><ul><ul><li>Multi-homing and Seamless Switching </li></ul></ul><ul><li>Quality of Service </li></ul><ul><ul><li>The FN should support quality of service (QoS) from </li></ul></ul><ul><ul><ul><li>user and/or application perspectives. </li></ul></ul></ul>
    14. 14. Design Goals (3/4) <ul><li>Heterogeneity </li></ul><ul><ul><li>The FN should provide much better support for a broad </li></ul></ul><ul><ul><ul><li>range of applications/services and enable new </li></ul></ul></ul><ul><ul><ul><li>applications/services. In addition, it should accommodate </li></ul></ul></ul><ul><ul><ul><li>heterogeneous physical environments. </li></ul></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 </li></ul></ul><ul><ul><li>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>
    15. 15. Design Goals (4/4) <ul><li>Customizability </li></ul><ul><ul><li>The FN should be customizable along with </li></ul></ul><ul><ul><li>various user requirements. </li></ul></ul><ul><ul><li>Context-Aware Numbering and Content-Centric Service </li></ul></ul><ul><ul><li>Service-Specific Overlay Control and Service Discovery </li></ul></ul><ul><li>Economic Incentives </li></ul><ul><ul><li>The FN shall provide economic incentives to the </li></ul></ul><ul><ul><li>components/participants that contribute to the </li></ul></ul><ul><ul><li>networking. </li></ul></ul>
    16. 16. 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>
    17. 17. Internet vs. FI Current Internet : Architecture – TCP/IP (Narrow Arch.) Mechanism – SNMP, IPsec … Application – Web, E-mail … FI : Meta Architecture : Multiple Architectures Architecture Architecture – TCP/IP, Intermittent X, …. Mechanism – SNMP, IPsec, Cognitive, Cooperative, Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite
    18. 18. Meta Architecture <ul><li>Network virtualization </li></ul><ul><ul><li>Realize virtual network with programmable network </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>connected with gateway </li></ul><ul><li>New 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 </li></ul></ul><ul><ul><li>something efficiently </li></ul></ul><ul><li>Diverse models of the end-to-end principle </li></ul>
    19. 19. Network Virtualization <ul><li>De-ossifying the current Internet </li></ul><ul><ul><li>Multiple virtual networks co-exist on top of a </li></ul></ul><ul><ul><li>shared substrate . </li></ul></ul><ul><ul><li>Different virtual networks provide alternate end-to-end </li></ul></ul><ul><ul><ul><li>packet delivery systems and may use </li></ul></ul></ul><ul><ul><ul><li>different protocols and packet formats. </li></ul></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 </li></ul><ul><ul><li>Innovations) </li></ul></ul>
    20. 20. GENI : Block Diagram
    21. 21. Testbed vs. Infrastructure <ul><li>GENI in Progress </li></ul><ul><li>Success Story ( spiral </li></ul><ul><li>development ) </li></ul><ul><ul><li>• PlanetLab : </li></ul></ul><ul><ul><li>• VINI (Virtual Network Infrastructure) </li></ul></ul><ul><ul><li> </li></ul></ul>
    22. 22. PlanetLab(1) <ul><li>What is PlanetLab? </li></ul><ul><ul><li>Consortium: joint Academic, Government, Industry venture </li></ul></ul><ul><ul><ul><li>Formally formed January 2004 </li></ul></ul></ul><ul><ul><ul><li>Hosted by Princeton University, UC Berkeley, and U. of Washington </li></ul></ul></ul><ul><ul><ul><li>United States Government funded (NSF and DARPA) </li></ul></ul></ul><ul><ul><ul><li>Hewlett Packard and Intel as founding Industrial members </li></ul></ul></ul><ul><ul><ul><ul><li>AT&T, France Telecom, Polish Telecom, Google, NEC, … </li></ul></ul></ul></ul><ul><ul><li>Facility: Planetary-scale “overlay” and “underlay” network </li></ul></ul><ul><ul><ul><li>700+ Linux-based servers at 300+ sites in 30+ countries </li></ul></ul></ul><ul><ul><ul><li>Researchers can get a virtual machine on each server ( SLICE ) </li></ul></ul></ul><ul><ul><ul><li>In a SLICE across PlanetLab researchers can deploy & evaluate … </li></ul></ul></ul><ul><ul><ul><li>… distributed systems services and applications </li></ul></ul></ul><ul><ul><ul><li>“ The next Internet will be created as an overlay in the current one” </li></ul></ul></ul><ul><ul><ul><li>… network architectures and protocols </li></ul></ul></ul><ul><ul><ul><li>“ The new Internet will be created in parallel next to the current one” </li></ul></ul></ul>
    23. 23. PlanetLab(2) <ul><li>PlanetLab Facility Today </li></ul><ul><ul><li>784 servers at over 382 sites </li></ul></ul><ul><ul><li>Co-located throughout the (developed) world @ Uni. & Companies </li></ul></ul><ul><ul><li>Co-located at network crossroads (Internet2, RNP, CERNET, …) </li></ul></ul>
    24. 24. PlanetLab(3) <ul><li>The Importance of Systems Building </li></ul><ul><ul><li>Systems-oriented CS research needs to build and try out its ideas to be effective </li></ul></ul><ul><ul><ul><li>Paper designs are just idle speculation </li></ul></ul></ul><ul><ul><ul><li>Simulation is only occasionally a substitute </li></ul></ul></ul><ul><ul><li>We need: </li></ul></ul><ul><ul><ul><li>Real implementation </li></ul></ul></ul><ul><ul><ul><li>Real experience </li></ul></ul></ul><ul><ul><ul><li>Real network conditions </li></ul></ul></ul><ul><ul><ul><li>Real users </li></ul></ul></ul><ul><ul><ul><li>To live in the future </li></ul></ul></ul>
    25. 25. PlanetLab(4) <ul><li>Limitations of Traditional Approaches </li></ul><ul><ul><li>Simulation based on limited models </li></ul></ul><ul><ul><ul><li>Topologies, administrative policies, workloads, failures… </li></ul></ul></ul><ul><ul><li>Emulation (and “in lab” tests) are similarly limited </li></ul></ul><ul><ul><ul><li>Only as good as the models </li></ul></ul></ul><ul><ul><li>Conventional testbeds are (too narrowly) targeted </li></ul></ul><ul><ul><ul><li>Not cost-effective to test every good idea </li></ul></ul></ul><ul><ul><ul><li>Often of limited reach; no real users </li></ul></ul></ul><ul><ul><ul><li>Often with limited programmability </li></ul></ul></ul>
    26. 26. VINI (1) <ul><li>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. </li></ul><ul><li>VINI currently consists of 37 nodes at 22 sites connected to the National LambdaRail , Internet2 , and CESNET (Czech Republic). </li></ul>
    27. 27. VINI(2) <ul><li>The maps below show our current VINI deployments </li></ul>Internet2 Deployment
    28. 28. Different Arch. & Gateway <ul><li>Tie together heterogeneous networks </li></ul><ul><ul><li>Gateway spans multiple architecture regions that </li></ul></ul><ul><ul><li>use different protocols </li></ul></ul><ul><ul><li>Applications can communicate across multiple </li></ul></ul><ul><ul><li>architecture regions </li></ul></ul><ul><li>E.g., DTN Bundle Layer and Gateway </li></ul>
    29. 29. DTNs <ul><li>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 </li></ul><ul><li>Goals </li></ul><ul><ul><li>Support interoperability across ‘radically heterogeneous’ networks </li></ul></ul><ul><ul><li>Tolerate delay and disruption </li></ul></ul><ul><ul><ul><li>Acceptable performance in high loss/delay/error/disconnected environments </li></ul></ul></ul><ul><ul><ul><li>Decent performance for low loss/delay/errors </li></ul></ul></ul><ul><li>Components </li></ul><ul><ul><li>Flexible naming scheme </li></ul></ul><ul><ul><li>Message abstraction and API </li></ul></ul><ul><ul><li>Extensible Store-and-Forward Overlay Routing </li></ul></ul><ul><ul><li>Per-(overlay)-hop reliability and authentication </li></ul></ul>
    30. 30. Internet vs. DTN Routing
    31. 31. Future Wireless Networks
    32. 32. Cross-Layer Communications <ul><li>Avoid Layering Concept </li></ul><ul><ul><li>Exploit the dependency between protocol layers to obtain </li></ul></ul><ul><ul><li>performance gains </li></ul></ul><ul><ul><li>Direct communication between protocols at nonadjacent </li></ul></ul><ul><ul><li>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 Design for Wireless Mobile Network </li></ul><ul><ul><li>Create new interfaces between layers, redefine the layer </li></ul></ul><ul><ul><li>boundaries, design protocol at a layer based on the details </li></ul></ul><ul><ul><li>of how another layer is designed, joint tuning of parameters </li></ul></ul><ul><ul><li>across layers, or create complete new abstraction </li></ul></ul>
    33. 33. Cross-Layer Design Proposals Source : V. Srivastava et al., Cross-layer design, IEEE Comm. Magazine, 2005
    34. 34. Diverse E2E Communications <ul><li>Original E2E </li></ul><ul><ul><li>Concerned with end-to-end services and protocols implemented </li></ul></ul><ul><ul><li>in hosts, such as transport protocols and implementation </li></ul></ul><ul><ul><li>architecture for high performance. </li></ul></ul><ul><ul><ul><li>e.g., presentation layer design, application-layer framing, high performance host interfaces, and efficient protocol implementation techniques. </li></ul></ul></ul><ul><li>EME (End-Middle-End) </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>
    35. 35. 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>
    36. 36. Architecture (E.g.) (1/2) <ul><li>Data Oriented Network Architecture </li></ul><ul><ul><li>Data dissemination rather than p2p conversation </li></ul></ul><ul><ul><li>DONA : The Data-Oriented Network Architecture </li></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul><ul><ul><li>CCN: Content Centric Network </li></ul></ul><ul><li>Autonomic Communication </li></ul><ul><ul><li>Manageability </li></ul></ul><ul><ul><li>ANA: Autonomic Network Architectures </li></ul></ul><ul><ul><li>CASCADAS: Component-ware for Autonomic Situation-aware Communications, and Dynamically Adaptable Services </li></ul></ul><ul><li>Bio-Inspired Network </li></ul><ul><ul><li>Use biological concept for network </li></ul></ul><ul><ul><li>Service generation with natural selection/ evolution </li></ul></ul><ul><ul><li>Security with immune system </li></ul></ul>
    37. 37. Architecture (E.g.) (2/2) <ul><li>Opportunistic Communication </li></ul><ul><ul><li>Send packet according to the link condition </li></ul></ul><ul><ul><li>Store & forward </li></ul></ul><ul><ul><li>DTN </li></ul></ul><ul><ul><li>Haggle: A European Union funded project in Situated and Autonomic Communications </li></ul></ul><ul><li>I3 </li></ul><ul><ul><li>Mobility </li></ul></ul><ul><ul><li>Internet indirection infrastructure </li></ul></ul>
    38. 38. I3 (Internet Indirect Infrastructure) <ul><li>Each packet is associated with an id </li></ul><ul><ul><li>this id is used by the receiver to </li></ul></ul><ul><ul><li>obtain delivery of the packet. </li></ul></ul><ul><ul><li>host R that inserts a trigger (id, R) in </li></ul></ul><ul><ul><li>the i3 infrastructure to receive all </li></ul></ul><ul><ul><li>packets with identifier id . </li></ul></ul><ul><li>When a host changes its address, </li></ul><ul><li>the host needs only to update its </li></ul><ul><li>trigger. </li></ul><ul><ul><li>When the host changes its address </li></ul></ul><ul><li>from R1 to R2 , it updates its trigger </li></ul><ul><li>from (id, R1) to (id, R2) . </li></ul><ul><ul><li>As a result, all packets with identifiers </li></ul></ul><ul><li>id are correctly forwarded to the new </li></ul><ul><li>address. </li></ul>
    39. 39. I3 (cont’d) <ul><li>Multicast </li></ul><ul><li>Anycast </li></ul>
    40. 40. 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( Distributed Hash Table) </li></ul></ul><ul><ul><ul><li>Pastry </li></ul></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><ul><li>Building Block </li></ul><ul><ul><li>Lego like building blocks </li></ul></ul>
    41. 41. 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>
    42. 42. Global Collaboration (1/3) <ul><li>ISO/IEC JTC1/SC6 </li></ul><ul><ul><li>Ad-hoc Meeting for Future Network (Paris, 4-5 </li></ul></ul><ul><ul><li>Sept. 2007) </li></ul></ul><ul><ul><li>SC6 Meeting (Geneva, April 2008) </li></ul></ul><ul><ul><ul><li>Trial for initiation of NP Ballot within JTC1 </li></ul></ul></ul><ul><ul><li>Start New Work from the end of 2008 </li></ul></ul><ul><ul><li>It may be almost aligned with possible activities </li></ul></ul><ul><ul><li>for the next study period of ITU-T (2009-2012) </li></ul></ul>
    43. 43. Global Collaboration (2/3) <ul><li>ITU-T </li></ul><ul><ul><li>NGN-GSI, SG13 </li></ul></ul><ul><ul><ul><li>New Question Proposal on the Future Network (Sept. </li></ul></ul></ul><ul><ul><ul><li>2007, Geneva </li></ul></ul></ul><ul><ul><ul><li>New Question Proposal on the Future Network (Jan. </li></ul></ul></ul><ul><ul><ul><li>2008, Seoul) </li></ul></ul></ul><ul><li>SG17 </li></ul><ul><ul><li>New Questions on Future Open System </li></ul></ul><ul><ul><li>Communications Technology </li></ul></ul>
    44. 44. Global Collaboration (3/3) <ul><li>IRTF </li></ul><ul><ul><li>The Chairs of six of the fourteen Research </li></ul></ul><ul><ul><li>Groups comprising IRTF have funded FIND </li></ul></ul><ul><ul><li>proposals - </li></ul></ul><ul><ul><ul><li>dtnrg, eme, end2end, imrg, p2prg, rrg </li></ul></ul></ul><ul><ul><li>New Works Considered </li></ul></ul><ul><ul><ul><li>Network virtualization RG </li></ul></ul></ul><ul><ul><ul><li>QoS policy framework RG </li></ul></ul></ul><ul><ul><ul><li>Cross-layer communication in TSV </li></ul></ul></ul>
    45. 45. Conclusions <ul><li>Detailed specifications for optimal architecture? </li></ul><ul><li>Implementation and Testbed </li></ul><ul><li>Other considerations? </li></ul>
    46. 46. References <ul><li>Myung-ki Shin, Meta Architecture for Future Internet, HSN 2008 Presentation Material </li></ul><ul><li>PlanetLab : </li></ul><ul><li>VINI (Virtual Network Infrastructure) </li></ul><ul><ul><li> </li></ul></ul><ul><li> </li></ul><ul><li>IPv6: Addressing the future </li></ul><ul><li>DTN, </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Haggle, </li></ul>
    47. 47. Question and Discussion
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.