presentation

Thinking of Architecture for Future Internet

[email protected], 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.

Source : Steve Deering,IPv6 :addressing the future

Narrow Waist forInternet Hourglass

(Common Layer = IP)

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 withunpredictable characteristics, such as some forms of wireless link,

poorlatency characteristics for competing real-time flows, etc.

1.8 Opportunistic and Fast Long-Distance NetworksOriginal Internet was designed to support always-on connectivity,

shortdelay, symmetric data rate and low error rate communications, butmany evolving and challenged networks do not confirm to this designphilosophy. 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 makeprofit.

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

fromuser and/or application perspectives.

14

Design Goals (3/4) Heterogeneity

The FN should provide much better support for a broadrange of applications/services and enable newapplications/services. In addition, it should accommodateheterogeneous 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

Current Internet :Architecture – TCP/IP (Narrow Arch.)Mechanism – SNMP, IPsec …Application – Web, E-mail …

FI :Meta Architecture : Multiple Architectures ArchitectureArchitecture – TCP/IP, Intermittent X, ….Mechanism – SNMP, IPsec, Cognitive, Cooperative,Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite

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-endpacket delivery systems and may usedifferent protocols and packet formats.

Easily programmable Can experiment on any level (optical to apps)

E.g., GENI (Global Environment for NetworkInnovations)

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 effectivePaper designs are just idle speculationSimulation is only occasionally a substitute

We need:Real implementationReal experienceReal network conditionsReal usersTo 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 to deploy and evaluate their ideas with real routing software, evaluate their ideas with real routing software, traffic loads, and network eventstraffic 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