Thinking of Architecture for Future Internet - PowerPoint PPT Presentation


PPT – Thinking of Architecture for Future Internet PowerPoint presentation | free to download - id: 7cce0c-OGY2N


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Thinking of Architecture for Future Internet


Thinking of Architecture for Future Internet, Choong Seon Hong, KHU – PowerPoint PPT presentation

Number of Views:61
Avg rating:3.0/5.0
Slides: 48
Provided by: Md82
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Thinking of Architecture for Future Internet

Thinking of Architecture for Future Internet
  •, Choong Seon Hong, KHU

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
  • (4) To allow distribute network management
  • (5) To be cost effective
  • (6) To allow host attachment with a low level of
  • (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
  • Environment
  • Trusted gt Untrusted
  • Users
  • Researchers gt Customers
  • Operators
  • Nonprofits gt Commercial
  • Usages
  • Host-oriented gt Data-centric
  • Connectivity
  • E2E IP gt Intermittent Connection

  • 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 IPs shortcomings
    will not be
  • resolved by conventional incremental and
  • style designs. So, the Future Internet designs
    must be made
  • based on clean-slate approach.

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.

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
  • 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
Source Steve Deering, IPv6 addressing the
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
  • 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
  • There is a question of how network provider and
    ISP continue to make
  • profit.

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

Future Internet
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)

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

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
  • must be protected from the plague of security
  • breaches, spread of worms and spam, and denial
  • service attacks, etc .

Design Goals (2/4)
  • Mobility
  • The FN should support mobility of devices,
  • 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)
  • user and/or application perspectives.

Design Goals (3/4)
  • Heterogeneity
  • The FN should provide much better support for a
  • range of applications/services and enable new
  • applications/services. In addition, it should
  • 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

Design Goals (4/4)
  • Customizability
  • The FN should be customizable along with
  • various user requirements.
  • Context-Aware Numbering and Content-Centric
  • Service-Specific Overlay Control and Service
  • Economic Incentives
  • The FN shall provide economic incentives to the
  • components/participants that contribute to the
  • networking.

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

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
Meta Architecture
  • Network virtualization
  • Realize virtual network with programmable network
  • elements.
  • Multiple architectures architecture or no
  • Federation of different architecture regions
  • Heterogeneous networks with heterogeneous
  • 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
  • De-ossifying the current Internet
  • Multiple virtual networks co-exist on top of a
  • shared substrate.
  • Different virtual networks provide alternate
  • 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
Testbed vs. Infrastructure
  • GENI in Progress
  • Success Story (spiral
  • development)
  • PlanetLab http//
  • VINI (Virtual Network Infrastructure)
  • http//

  • What is PlanetLab?
  • Consortium joint Academic, Government, Industry
  • 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
  • ATT, France Telecom, Polish Telecom, Google,
  • Facility Planetary-scale overlay and
    underlay network
  • 700 Linux-based servers at 300 sites in 30
  • 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

  • PlanetLab Facility Today
  • 784 servers at over 382 sites
  • Co-located throughout the (developed) world _at_
    Uni. Companies
  • Co-located at network crossroads (Internet2, RNP,
    CERNET, )

  • 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

  • Limitations of Traditional Approaches
  • Simulation based on limited models
  • Topologies, administrative policies, workloads,
  • Emulation (and in lab tests) are similarly
  • 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

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

  • The maps below show our current VINI deployments

Internet2 Deployment
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

  • 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/di
    sconnected 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
Future Wireless Networks
Cross-Layer Communications
  • Avoid Layering Concept
  • Exploit the dependency between protocol layers to
  • performance gains
  • Direct communication between protocols at
  • layers or sharing variables between layer
  • Optimization ?? Abstraction
  • E.g., Cross-layer Design for Wireless Mobile
  • 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

Cross-Layer Design Proposals
Source V. Srivastava et al., Cross-layer
design, IEEE Comm. Magazine, 2005
Diverse E2E Communications
  • Original E2E
  • Concerned with end-to-end services and protocols
  • in hosts, such as transport protocols and
  • architecture for high performance.
  • e.g., presentation layer design,
    application-layer framing, high performance host
    interfaces, and efficient protocol implementation
  • 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
  • Network addressing and naming
  • Routing protocols
  • Backbone design
  • Circuit Packet
  • Heterogeneous physical layers
  • Heterogeneous applications
  • Security

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
  • CASCADASComponent-ware for Autonomic
    Situation-aware Communications, and Dynamically
    Adaptable Services
  • Bio-Inspired Network
  • Use biological concept for network
  • Service generation with natural selection/
  • Security with immune system

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

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.

I3 (contd)
  • Multicast
  • Anycast

  • Wireless
  • Cognitive
  • Cooperative
  • Coopcom http//
  • 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

  • Sensor
  • Vehicle/aircraft
  • Emergency
  • Satellite
  • Energy/power

Global Collaboration (1/3)
  • 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)

Global Collaboration (2/3)
  • ITU-T
  • NGN-GSI, SG13
  • New Question Proposal on the Future Network
  • 2007, Geneva
  • New Question Proposal on the Future Network (Jan.
  • 2008, Seoul)
  • SG17
  • New Questions on Future Open System
  • Communications Technology

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

  • Detailed specifications for optimal
  • Implementation and Testbed
  • Other considerations?

  • Myung-ki Shin, Meta Architecture for Future
    Internet, HSN 2008 Presentation Material
  • PlanetLab http//
  • VINI (Virtual Network Infrastructure)
  • http//
  • http//
  • IPv6 Addressing the future http//www.6journal.or
  • DTN,
  • http//
  • http//
  • Haggle, http//

Question and Discussion