KRNET 2014 ⓒ Woojik Chun

Review and Prospect on

Future Internet Architectures

2

Contents

What is the Future Internet ? 1

3

4

5

Future Internet – Paradigm Shift

Future Internet – Technical Issues

6 Concluding Remarks

Future Internet - Prospects

2 Future Internet – Architecture Review

3

What is the Internet ?

The Internet joining many government, university and private computers

together

providing an infrastructure for the use of E-mail, bulletin boards, file archives, hypertext documents, databases and other computational services

A single huge space w.r.t IP address for delivering of data and messages From anywhere in a host to anywhere

in the world.

Space of the Internet Routing? Metric space (IGP) Topological space (BGP)

4

What is the Future Internet ?

Narrow Sense Solutions on Limitations of

the current TCP/IP based Internet

Broad Sense Future Networked Services

and Applications

Common Sense Shared Information Infra

Union of heterogeneous networks

A set of rules for interworking among autonomous systems

Service Infra

Network Infra

Services, Applications

Heterogeneous Networks

5

Future Internet : Two Different Views

Network Centric View Service Centric View

Limitation of

current Internet

New Core Tech.

(Content, virtualization)

Emerging New networked

applications

Clean slate

Internet Research

Outputs:

Novel network/protocol concepts

Future Internet architecture ideas

Influence on current IP standards

Approaches to fixed-mobile convergence

Possible clean-slate deployments

New classes of applications

Inte

rnet

by a

nd fo

r People

Inte

rnet o

f Conte

nts

and K

now

ledge

Inte

rnet

of T

hin

gs

In

tern

et

of S

erv

ices

Network Infra

(Internet of networks)

Future Networked Society

6

Future Internet : Major Researches

Named Data Networking (Lixia Zhang, UCLA) moves the communication paradigm from today's focus on

"where", i.e., addresses, servers, and hosts, to "what", i.e., the content that users and applications care about

NEBULA(Jonathan Smith, U Penn) addresses the technical challenges in creating a cloud-computing-

centric architecture

MobilityFirst (D. Raychaudhuri, Rutgers University) dealing with mobility as a first class entity allows functionalities

like context and location-aware services to fit naturally into the network

eXpressive Internet Architecture (P. Steenkiste, CMU) exploring the technical challenges in creating a single network

that offers inherent support for communication between current communicating principals--including hosts, content, and services--while accommodating unknown future entities

SAIL-NetInf (EU FP-7) focuses on the information itself, not on the location of the

information.

7

NDN (Named Data Networking)

Principal Investigator Lixia Zhang, UCLA

Collaborating Institutions Colorado State University,

PARC,

University of Arizona,

University of Illinois/Urbana-Champaign,

UC Irvine,

University of Memphis,

UC San Diego,

Washington University,

Yale University

http://www.named-data.net/

8

NDN: Motivation

9

NDN: Internet Today

src

dst

X

Path determined by global routing, not local choice

Structural asymmetry precludes market mechanisms and

encourages monopoly formation

10

Producer

Consumer

a/b

NDN: approach

Packets say ‘what’ not ‘where’ (no src or dst)

Forwarding decision is local

Upstream performance is measurable

11

Producer

Consumer

a/b/c/d

Data

a/b/c/d

Each Router may Cache the Contents at the Content Store

Structural asymmetry precludes market mechanisms and

encourages monopoly formation

NDN: approach

12

NDN : Operation

A

Pending Interest Table Forwarding Information Base

Face 2

：

Face 2

Face 1

Face 1

Face 1

Face 3

Content Store

6 hour

2 hour

：

movie.red.*

movie.blue.*

movie.green.*

movie.violet.*

movie.blue.*

movie.yellow

NDN Operation Example Ref: SNU MMLab

13

NDN : Summary

Send / Receive Publish / Subscribe (Interest)

Sender-driven Receiver-driven

Host Names Data Names

Host Reachability Information Scoping

Channel Security Self-Certifying Metadata

Unicacst Multicast

14

Nebula

Principal Investigator: Jonathan Smith, University of Pennsylvania

Collaborating Institutions: Cornell University,

Massachusetts Institute of Technology,

Princeton University,

Purdue University,

Stanford University,

Stevens Institute of Technology,

University of California/Berkley,

University of Delaware,

University of Illinois/Urbana-Champaign,

University of Texas,

University of Washington

15

Nebula : Motivation

NEBULA is an architecture for the Cloud-based Future Internet More secure and reliable

Deployable and evolvable

Truly clean-slate

Technology, Economics and Policy continue to evolve NEBULA co-design with Economist and Lawyer on team

Motivation for a new architecture: Availability: Risk of network outages

Security: Poor endpoint authentication

Consistency: Communications end point focused, not data focused

16

Nebula: Architecture and Principles

Architecture: Services provided by cloud data centers

Multiple cloud providers, that each use replication

Agreements for "roaming" allow user to connect to nearest center

Variety of access mechanisms (wired & wireless)

Transit networks to connect access to data centers

Principles Ultra reliable, high-speed core interconnecting data centers

Parallel paths between data center and core router

Secure access and transit

Policy-based path selection

Authentication during connection establishment

17

Nebula: Building Blocks

NDP – NEBULA Data Plane Distributed path establishment with guarantees

NVENT – NEBULA Virtual and Extensible Networking Techniques Extensible + Policy control plane

NCore - NEBULA Core Redundantly connected high availability routers

18

Nebula : summary

Architecture specific to the cloud service Access network

Transit network

Core network

Research Issues NDP run on multiple paths?

Realm ( ~ AS)

Mapping to intra-domain / inter-domain

Public-Key infrastructure

Control enforcement

19

MobilityFirst

Principal Investigator Dipankar Raychaudhuri,

Rutgers University/New Brunswick

Collaborating Institutions Duke University,

Massachusetts Institute of Technology,

University of Massachusetts/Amherst,

University of Massachusetts/Lowell,

University of Michigan,

University of Nebraska/Lincoln,

University of North Carolina/Chapel Hill

20

MobilityFirst: Motivations

Naming and addressing DNS binds a host name to an IP address.

DNS is designed to be queried frequently but updated slowly.

Caching enables scalability at the cost of update-propagation delay.

Routing Aggregation of IP addresses into prefixes is central to routing scalability.

Host mobility is assumed to be infrequent enough

an indirect routing approach inefficient

Network mobility (e.g., mobile networks of vehicles, planes, or VMs) scales poorly with the Internet's inter-domain routing protocol.

Disruption-tolerance TCP/IP stack assumes that hosts and routers are stationary long enough

the routing protocol can compute a contemporaneous end-to-end path

the transport protocol can respond to end-to-end loss and congestion signals.

TCP/IP stack falls short in emerging wireless scenarios (vehicular, sensor).

21

MobilityFirst: Principles

Mobility as the norm

Seamless host and network mobility at scale;

Multi-provider mobile network access

Heterogeneous wireless technologies.

Robustness

with respect to intrinsic properties of wireless medium

(disconnection, varying bandwidth, high error rates, scarce spectrum).

Trustworthiness

Enhanced security for mobile networks and wired infrastructure

Usability

Architectural support for context-aware pervasive mobile services

evolvable core network services

network manageability

economic viability, regulability and universal access.

22

MobilityFirst: Name and Address Separation

Separation of names (ID) from network addresses (NA)

Globally Unique Name(GUID) User Name, Device ID,

Context, AS name …

Multiple domain-specific naming service

Global Name Resolution Service GUID -> NA mapping

Hybrid GUID/NA approach Both name/address in PDU

“fast Path” when NA is available

Late binding option

23

MobilityFirst: Summary

Network = collection of independent access networks

Mapping from Host GUID to network addresses (NA) GNRS based on DHT

No recursion on networks

24

XIA (eXpressive Internet Architecture)

Principal Investigator Peter Steenkiste, Carnegie Mellon University

Collaborating Institutions Boston University,

University of Wisconsin/Madison

25

XIA: Visions

Users & appl. must be able to express their intent Principals express their intent

Multi-Principals supports communication between diverse entities (eg., hosts,

services, contents, …)

Support an evolvable set principals for comm.

allows “late binding'' to a particular host or set of hosts

Intrinsic Security extend AIP(Accountable Internet Protocol)

Communicating entities are named by their public keys

Narrow waist For trust management

Defines the API between principals and network protocol mechanisms

26

XIA: Multiple Principal Types

27

XIA : DAG with Fallbacks

A node can have multiple outgoing edges

Outgoing edges have priority among them Forwarding to HIDS is attempted if forwarding to CIDA is not

possible – Realization of fallbacks

CIDA

HIDS

Fallback edge (low priority edge)

27

Primary edges

Intermediate node

28

XIA : Path Selection in SCION

28

Source Destination

PCB PCB PCB PCB

Source/destination can choose among up/down hill paths Path control shared between ISPs,

receivers, senders

Desirable security properties: High availability, even in

presence of malicious parties

Explicit trust for operations

Minimal TCB: limit number of entities that must be trusted

No single root of trust

Simplicity, efficiency, flexibility, and scalability

29

XIA : Summery

End-to-end transport over heterogeneous networks and for multiple principals Error control, congestion control, …

How to better support wireless mobile users, insertion of services, vehicular, DTNs, …

Trustworthy network operations Improve “security” broadly defined by leveraging the intrinsic

security properties of XIA

Focus on availability and systematic approaches to trust management

DAG No “ID – Locator separation”

Overhead on packet header

30

SAIL-NetInf

Started in the EU project 4WARD

continued in the follow-on project SAIL Motivatio

31

SAIL-NetInf : Model

Trustable copies of Information Even on untrusted server and connection

32

SAIL-NetInf : Self-Certification

Prevent unauthorized changes, ensure data integrity

Static content Include hash(content) in ID Label field

Verification: compute hash(retrieved data) and compare to hash in ID

Dynamic content Storing hash(dyn.content) in ID would violate ID persistence

Use signature [SK(attributes)] in ID instead

Verification: Verify that signature is correct and corresponds to PKIO

Type A=Hash(PKIO) L={attributes}

Security Metadata

SKIO

33

SAIL-NetInf : Operation

34

SAIL-NetInf : Summary

Based on unique name on information

Based on Receiver-Initiated transmission

Supports heterogeneous networks

flexibility applicability, innovation

35

Paradigm Shift : Evolution of Networks

+82-42-860-1234

Number (Wire) Specify How switching

168.2.10.3

Address (Interface) Specify Where routing

3AEF098D5F4E7C00

ID (Host/Data/Service/Thing)

Specify What locating path selection

36

Paradigm Shift : ID-LOC separation

ID-Locator combined Relation may be encoded in ID itself

Ex: Ordering, Grouping(prefix aggregation, hashing, etc.)

Relation may obtained by external interactions

Ex: Configuration, Learning, Routing Protocols

ID-Locator Separated ID itself has no clue for locating the entity

Locator is independent from the entity

Entity may be bound to locations on multiple spaces

Why should ID be separated from Locator? ID is used as a unique name for the intended entity

Locator is used as a locatable address for entities

ID may be mapped onto multiple locators

Space where the locator is defined determines the mechanism

37

Paradigm Shift : Entity and Environment

Entity-Environment Separation an entity itself is independent from its environment

Entity may exist in multiple heterogeneous environments

Communication services are provided by multiple environments

Connect to the entity Wherever it happens to be

Entities belong to environment Entities separated from environment

Connect to Whatever happens to be

at the location

38

Paradigm Shift : Intent-Mechanism Separation

Intent-Mechanism Combined Network directs instructions

Where you are

How you can do

User selects mechanism

Network performs protocols

Moved network (address) change

Intent-Mechanism Separated User specifies intent

What(Who) I am

What I want to contact

Network selects mechanism

Network finds protocols

Moved just path change

Instructions Intents

39

Polymorphic Enable different cooperation

paradigms in parallel.

Enable easy deployment of new mechanisms.

Without raising routing and addressing to the application

IP Layer

DNS

Media Media Media

ID API

Appl. Contents service

ID Loc Mapping

Polym

orp

hic

Net

Polym

orp

hic

Net

Polym

orp

hic

Net

Paradigm Shift : Polymorphic networks

Holomorphic Based on the IP Protocol

Dependent to addressing and routing

Vulnerable to attack

Hard to evolve

40

Paradigm Shift : Horizontal Layers

Vertical Function Layers Functional decomposition

within an element peer-to-peer protocols System Engineer View

TCP

IP

DL/PHY

Appl.

TCP

IP

DL/PHY

Appl.

IP

DL/PHY

Appl. GW.

GW GW

GW Host

Local Regional global

Logical Domains Logical Domains GW.

GW.

Horizontal Network Layers Spatial decomposition of

space (domain structuring) Sequence of Gateways Network Architect View

Suspension Bridge Model Arch Bridge Model

domains

41

Paradigm Shift : Structured Network Spaces

Traditional Networks No formal definitions on

network structures

Tech. may defines the network structures

Each layer implicitly defines its coverage

Future Networks Abstraction of networks

Recursive Domains

Domain

domain

domain

Abstract network view

Control Interface

Packet

Inte

rface

Recursive network view

domain

42

Paradigm Shift : Views on networks

Host 1 Host 2

Node 1 Node 2

Element (Entity) View Network = A set of

interconnected elements

Functionality of elements (protocol stacks)

Space (Relation) View Network = A space where

comm. entities may exist

Relations on the space

(interactions with environment)

43

Technical Issues

ID Based Communications

Named Data Networks

Mobility First eXpressive

Internet Arch. Nebula SAIL (EU) …

Common Issues

Entry explosion Routing scalability Vulnerable to attack

Reactive Path Setup - Path Setup when being required

Fish Eye Routing - nearer finer - farther coarser

Trust Domain - Certification when ID is registered at a domain - Trust relation of domains

Domain

Forwarding

Cache

GW

Domain Domain Domain

Path Discovery Protocol

44

Technical Issues : Incremental Deployment

Control Plane

(Controller Hierarchy)

Data Plane

(Recursive

Domains)

45

Prospects : Learn from History

Learn from History Internet : starts as an overlay of telephone networks

Successful patches

Urgent Issues : Congestion control of TCP

Local solution : NAT, Firewall, IDS

Isolated upgrade : MPLS, routing Protocols

Overlay solutions : P2P, Social Networks, CCN

Failed Trial

No flag day : IPv6

Too stubborn principles : RSVP

How long shall the current Internet continue? Only by patches and overlays ?

When will the Future Internet come?

46

Prospects : Goals of Future Internet

Propose a new Architecture for Future Internet Redesign the internet from scratch

Rethink the layer model

Rethink the End-to-End Principle

Take account of new requirements Functionalities : Mobility, Security, Autonomicity

New Technologies : sensor, Ad-hoc, PAN

However, tolerant to the existing networks assume less homogeneity

provide minimal rules for interworking among dissimilar networks

allow packet translation in intermediate nodes

Revolutionary Concepts but Evolutionary Deployments

47

Concluding Remarks

New Era of Network Science Craft Science

Two major techniques Abstraction

Recursion

What Future Internet has to do? Build shared infra with richer

capabilities

Show incentives to adaptors of new concepts

Suggest graceful migration plans from the existing Networks Not “backward compatibility” but

“adaptability”

DIANA Domain-Insulated

Autonomous Network

Architecture