npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...

1

Future Internet

Revisiting the Internet architecture?

Prof. Anja Feldmann, Ph.D.Deutsche Telekom Laboratories

TU Berlin

2

The “Internet”

3

The “Internet”: What is itr Visualization (2002)

~ 535,000 Nodes > 600,000 Links

r Social phenomenam Cyperspacem Changing/redefining

communication • Human to human,

human to computer, ….

4

The “Future Internet”?r Information and Media

Societym Everyone generates contentm Sensors and cameras

everywherem New distribution channels

r Challengesm Verificationm Fusion/filtering of

informationm Situation adaptationm Incentives, trust, privacy

5

What makes the Internet so sexy

r Applications can be deployed by anybody that is connected to the Internet(Fundamentally different to the Telephone world)

rMulti-service network: Everything over the Internet

6

TCP/IP protocol structure

Transport(Hosts)

Network

Link

Application(Processes)

IP

TCP UDP

Telnet FTP

DNSHTTP SMTP

FDDI ATM

Tokenring Ethernet

7

What makes the Internet so sexy

r Applications can be deployed by anybody that is connected to the Internet(Fundamentally different to the Telephone world)

rMulti-service network: Everything over the Internet

m Every application protocol over IPm IP over any network technology

8

Internet design goals

(in decreasing order of importance)mConnect existing networks mSurvivabilitymSupport multiple types of servicesmMust accommodate a variety of networksmAllow distributed managementmAllow host attachment with a low level of

effortmBe cost effectivemAllow resource accountability

9

Today’s Internet – out of shape!!!

rRedesign needed?

Data plane Control plane

Picture due to Rui Aguilar

10

Today’s Internet: Architectural limitsr Trust assumptions

m Internet assumes cooperation

r Competitionm Original Internet assumed no commercial considerations

r Edge diversitym Original Internet is host-centricm Ignores mobility, sensors, ...

r Network servicesm Original Internet exposes limited informationm Limits new servicesm Limits network managementm Almost no changes in the network core

r Designed to be a open, cooperating systemr Focus on data plane

11

Today’s Internet: Challenges

r Heterogeneity any which way you lookm Users, applications, hardware, traffic

r An immense moving targetr Highly interacting systemsm Temporal: between users, hosts and networks

m Spatial: among different components

m Vertical: across different networking layers

12

Why rethink the Internet architecture

r Reliability and availabilitym E-Commerce increasingly depends on fragile Internetm Debuggability

r Securitym Known vulnerabilities lurking in the Internetm Addressing security has a significant cost

r Scale & Diversitym Cyberspace (everything is networked)

r Support for new applications/servicesm Mobility / Quality of servicem High speed connections to the home

r Economicsm Cost-effectivelym Business models

FAll are control plane issues!

13

Rethinking the Internet architecturer Explore alternative architecturesr Approachm Incremental

• Apply point-solutions to the current architecture

m Clean slate design (CSD)• Start from scratch

r Advantage CSDm No limitations: enables rethinking of the network and

service architecturem Architecture not intrinsicm Experiments and failures are possible

14

How to get there?r How to determine that one has a good new architecture?m Paperware? Nom Built, evaluated, used? Yes

r Approach:m Experimental facilitym Research into new architectures

r Benefit:m Intellectual challenge:

uncover otherwise ignored system aspectsm Research how to build/operate an experimental facility

FGo beyond point solutions

15

Clean slate design: DriversrTechnicalm Virtualization techniquesm Cloud computing / networkingm Significant computational resources in the networkm Fast packet forwarding hardware, e.g., OpenFlow

rStarting pointsm PlanetLab / OneLabm Geant2/Internet2m Emulabm Vinim…

16

Future Internet: Sample initiatives and projects

EU IST FP7 Future Internet projects http://www.future-internet.eu/activities/fp7-projects.html

EU IST FP7 Future Internet projects http://www.future-internet.eu/activities/fp7-projects.html

Future Internet network design –FIND http://find.isi.edu/ Future Internet network design –FIND http://find.isi.edu/

Clean Slate Program (Stanford University) Clean Slate Program (Stanford University)

AKARI Project (Japan) AKARI Project (Japan)

Groupe de Reflexion Internet du Futur (France)Groupe de Reflexion Internet du Futur (France)

ANR (France) ANR (France) it839/u-it839 (Korea) it839/u-it839 (Korea)

NICTA (Australia) NICTA (Australia)

G-LAB funded by BMBF (Germany) G-LAB funded by BMBF (Germany)

Super Janet funded by EPSRC (UK) Super Janet funded by EPSRC (UK)

Internet del Futuro (SP)Internet del Futuro (SP)

CNGI Project (China) CNGI Project (China)

17

Revisiting traffic characteristics: Why?

r Constantly changingr Basis of most architectural changes

r Residential broadband access popular/widespreadrDiffers from well-studied campus and enterprise

trafficm Not subject to acceptable-use policies

Motivation

18

Usage changes: „Killer application?“

rWWW and the Internetm 1993: ... Hardly any WWW traffic on the Internetm 1994: ... About 10% of total Internet traffic is WWWm 95/96: ... Up to 60-70% of overall Internet traffic is

WWWm…??????...

19

Application mix?

20

However: MWN traffic by port(24 hours of traffic to/from MWN clients in 2006)

0.00%0.00%1.66%10421.71%1.05%1.85%Mail 251.71%1.75%2.12%SSH 221.29%2.08%2.34%Web 443

0.00%0.00%1.06%1433

0.00%0.01%3.53%445

72.59%68.13%70.82%Web 80

20.95%4.08%16.32%> 102479.05%73.73%83.68%< 10240.00%0.00%1.04%135

% Payload% Success% ConnsPort

21

Application mix – today?

22

Outline

r Revisiting traffic characteristicsm Data setsm Dominant characteristics

• Application usage• HTTP usage• NNTP usage• Performance/path characteristics

r Revisiting ISP – application relationship r Revisiting Routingr Revisiting Network structurer Revisiting Splitting control and forwarding

Outline

23

Outline




Outline

24

Data sets (1)

r Large European ISP (>10M customers in total)r Anonymized packet level tracesm Covering >20,000 DSL customersm One urban area

rOverview of packet level tracesm 14 x 90min; twice per day over 1 week in Aug 2008m 24hr in Sep 2008 (>4TB)m 24hr in Apr 2009 (>4TB)

r Bro Intrusion Detection System for analysis

Data sets

25

Data sets (2)

r Anonymized DSL session tracesm DSL connect / disconnect timesm Anonymized line-card IDm Access bandwidthm Augments packet data

rOverview of session tracesm One for each packet tracem 10 day in Feb 2009

Data sets

26

Outline




Outline

27

Methodology

r Using Bro's Dynamic Protocol Detection (DPD)m Protocol semantics and/orm Signatures

r 85% of bytes classifiedr Another 3.6% on well-known portsr No dominant day-of-week effectsr VerificationmWith NetFlow data (port based)mWith commercial Deep Packet Inspection (DPI)

system at different location

Application Usage

28

Application usage per hour

Application Usage

unclassified

well-known

other DPD

NNTP

eDonkey

BitTorrent

HTTP

29

Application usage per b/w

unclassified

well-known

other DPD

NNTP

eDonkey

BitTorrent

HTTP

30

Key results

rHTTP dominates? : 57% of bytesr P2P less than 14%r Unclassified: 11%rOther significant protocolsm NNTP 2–5%m Streaming (non-HTTP) 5%m Voice-over-IP 1.3%

r Port based classification works well for non-P2P protocols

Application Usage

? Erman et al. found very similar results in cotemporaneous work presented at WWW'09

31

Outline




Outline

32

Motivation & methodology

rWhy is HTTP so popular (again)?m HTTP offers popular high-volume content?m HTTP as transport protocol for other applications?

r Anonymized HTTP headers extracted via BrorDetermine content-typem Content-type headerm Libmagic

r Second level domain (from Host header)r User-Agent header

HTTP Usage

33

Key resultsr Popular content-types by volume

rDomain popularity:m One-click-hoster is top domain: 15% of HTTP bytesm Video portals (using flash-video) follow

r No significant hiding / tunneling via HTTPØHTTP dominance due to popular high-volume

content

HTTP Usage

flash-video25.2%

RAR14.7%

image11.5%

video7.6%

other23.4%

unclass. 17.6%

0 20 40 60 80 100

Flash-Video clearly dominates

34

Outline




Outline

35

Usenet – NNTPr Exchange of news/messages

m Subsumed by forums, wikis and blogs

m Said to be outdated and only used by “geeks”

m Most servers do not allow binary content and have short retention times.

r What has changed?m Fee-based NNTP server

operators, e.g., UseNeXT or GigaNews

m 99 % NNTP volume is binarym Competes with One-Click-

Hosters as client/server based alternative for file-sharing

Application Usage

36

Outline




Outline

37

TCP options / performance

rWindow scalingm Approx. 50% of host advertise scaling; most non-zeromMaximal advertised window often 64KB

r Loss/reordering in 10% of connectionsr Bandwidth-delay product > max. rcv. windowm Affects 44% of connections with >50KB volume

(downstream)

rMost lines only use small fraction of bandwidth

Performance/Path Characteristics

38

Round-trip-times (RTT)r Assessed during TCP handshake


m Local component dominates (DSL interleaving)

m Median: 74msm 99th perc: 1328msm Wireless equipment

can cause significant delays

39

Achieved flow throughputApplication Usage

40

Achieved throughput

rMost lines only use small fraction of bandwidthr Throughput by application and flowm HTTP, NNTP have order of magnitude higher

throughput than P2P

rMean number of parallel flowsm P2P has 5 times as many as HTTPm P2P and NNTP similar


41

Summary – Residential traffic study

r High IP address churn (4% assigned > 10 times)r HTTP dominates traffic: >57%

m P2P only 14%m NNTP noticeable

r Flash-video (video portals) most popular in HTTP: >25% m RAR-archives (One-click-hosters): >14%

r Performancem DSL bandwidth in general not fully utilizedm Window advertisements might limit performancem Local RTT component dominates (DSL interleaving)

Summary

42

Outline




Outline

43

Internet and traffic engineering

Source: Arbor Networks 2009

44

Internet and traffic engineering

Source: Arbor Networks 2009à Offline Process

Adjust routing or peering, dimension the network

Traffic Engineering:

45

The new Internet


à New core of interconnected content and consumer networks

46

The new Internet


à New core of interconnectedcontent and consumer networks

Google, Google, AkamaiAkamai, ,

RapidShareRapidShare, , ……

47

The new Internet



Moving Target I :

Popular Applications

48

The new Internet



Moving Target I :


Moving Target II :

Bottlenecks

49

The new Internet



Moving Target II :Bottlenecks

à ISPs lost control of their traffic

Moving Target I :


50

The new Internet



Moving Target II :Bottlenecks

à ISPs lose control of their network

Moving Target I :


“Telekom’s chief executive, said Google and others shouldpay telecoms groups for carrying content on their networks”

51

Challenge

Content-aware Traffic Engineering

ISPs re-gain control of their traffic by biasing host selection

52

Grand challenge

àOnlineàNo routing re-configurationàNo additional investmentsà Possible reduction of operational costà Potential negotiation tool

Content-aware Traffic Engineering

ISPs re-gain control of their traffic by biasing host selection

53

Roadmap

Measurements

System

Design & Deployment

Field TestISP-Application Collaboration

54

Measurements

System

Design & Deployment

Field Test

System

Design & Deployment

Field Test

System

Design & Deployment


55

Residential traffic

Source: Maier et al, IMC’09

àRecall: HTTP is responsible for around 60% of total traffic

à This trend should continue (flash video, cloud applications, datacenters)

56

Client

External DNS

Provider DNS

Internet Service ProviderInternet Service Provider(ISP)(ISP)

Host

1

2

3

4

5

Content Distribution and DNS

57

Client

External DNS

Provider DNS


Host

1

2

3

4

5

DNS Reply Aggregator

Content Distribution and DNS

58

$ dig photos-h.ak.fbcdn.net<<>> DiG 9.7.0-P1 <<>> photos-h.ak.fbcdn.net;; QUESTION SECTION:photos-h.ak.fbcdn.net. IN A;; ANSWER SECTION:photos-h.ak.fbcdn.net. 6099 IN CNAME photos-

d.ak.facebook.com.edgesuite.net.photos-d.ak.facebook.com.edgesuite.net. 20492 IN

CNAME a998.mm1.akamai.net.a998.mm1.akamai.net. 7 IN A 62.41.85.74a998.mm1.akamai.net. 7 IN A 62.41.85.90...

Reply anatomyàRequesting a photo from Facebook

2nd Level Domain à Application

Redirection à Content Provider

59

Consolidation of content

àTop-10 applications or content providers are responsible for around 50% the HTTP traffic.

60

Diversity of paths

àMore than 60% of the HTTP traffic can be download from at least 3 different locations

61

Measurements

System

Design & Deployment


62

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5

Provider-aided Distance Information System

PaDIS

63

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5

Full View Full View of the ISP of the ISP NetworkNetwork

PaDIS

64

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5


Content can be downloaded from any eligible host!

PaDIS

65

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5


Host1

Host2

Host3

Host4

PaDIS

66

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5


Host1

Host2

Host3

Host4 Host2

Host4

Host3

Host1

PaDIS

67

Client

External DNS

Provider DNS


Host

1

2

3

4

6PaDISPaDIS

5

7

7


PaDIS

68Client

Host A

Host B

Host C

Network load balancing

69


Client

Host A

Host B

Host C

70


Client

Host A

Host B

Host C

71

Path diversity

0.5% 5% 50%

à Top-10 content providers and applications

àReduction up to 30%on congested link

à 5-10% reduction in total traffic

àNo increase in path length

à Improve locality of HTTP traffic from 25% à 50%

Link Utilization

Rebalance of traffic to less congested links

72

Measurements

System

Design & Deployment


Roadmap

73

Improving content access timeCase study: CDN

74

Improving content access time Case study: One-Click Hosters

75

Measurements

System

Design & Deployment

Field Test

ISP-Application Collaboration

Roadmap

76

Client

External DNS

Provider DNS


Host

1

2

5

3

6PaDISPaDIS

4

7

7

ISP applications collaboration

77

Client

External DNS

Provider DNS


Host

1

2

5

3

6PaDISPaDIS

4

7

7

Host1

Host2

Host3

Host4

Host2

Host4

Host3

Host1

ISP-applications collaboration

78

ISP-applications collaboration

Client

External DNS

Provider DNS


Host

1

2

5

3

6PaDISPaDIS

4

7

7

Host1

Host2

Host3

Host4

Host2

Host4

Host3

Host1

Host2Host2

Host3Host3

Host1Host1

Host4Host4

79

Summaryr Alternative traffic engineering

m Do not change the routingm Change the traffic matrix!

r Benefitsm ISPs: Regain control of network trafficm User: Performance improvements

à Win-win situation for ISPs and end-users à ISPs can share benefits with content and application providers

r PADIS m Simple and easy to implementm Prototype running

80

Outline




Outline

81

Exploring Alternative Architectures

HAIR: Hierarchical Architecturefor Internet Routing

82

Routing scalability: Problems

r IP addresses usagem Locator within the Internetm Identifier for applications

r Routing table size growthm Multi-homingm Traffic engineeringm Prefix disaggregation

83

Routing scalability: Problems

r Churn: High update ratesm Due to mobilitym Due to global visibilitym Due to „overuse“ of policym ...

84

Routing scalability: Current workarounds

staticlarge RTlarge RT

high upd ratehigh

upd rate

dynamic

Scalability issues

expensive TCAMexpensive TCAM

high workloadto maintain RThigh workloadto maintain RT

control plane

data plane

Consequences limited TE

limited TE

limitedmobilitylimitedmobility

Problems

massivefilteringmassivefiltering

dampeningdampening

Workarounds

static

dynamic

85

Approach

r Key ideasm Separation of locator/identifier function of IP address

=> separation of routing and location mapping

130.149.220.23TU-Berlin

86

Approach



mHierarchy for routing and location mapping

87

Approach



mHierarchy for routing and location mapping

r Two componentsm Routing system based on locatormMapping system to map an identifier to a locator

88

Hierarchical routing

r Network is organized in multiple levelsr Levels are separated by separatorsr Routers only know the details about their level

Separator

89

Hierarchical routing: Internet

rWhere do we have small separators?r Internet structurem Core

• Set of interconnected autonomous systems (ASs)• Tier-1, tier-2 ASs, …• Transit ASs

90

Stub ASAccess Provider

EnterpriseNetwork

TransitAS 1

TransitAS 2

ISP1

ISP2ISP3

91

r AS corem ~5000 ASs

r AS edgem ~30000 AS


Core

EnterpriseNetwork

ISP1

ISP2ISP3

TransitAS 1

TransitAS 2

92

r AS corem ~5000 ASs

r AS edgem ~30000 AS


Core

EnterpriseNetwork

ISP1

ISP2ISP3

TransitAS 1

TransitAS 2

Potential large

separator

Potential small

separator

93


rWhere do we have small separators?r Internet structurem Core

• Set of interconnected autonomous systems (ASs)• Tier-1, tier-2 ASs, …• Transit ASs

m Intermediate• Stub ASs, e.g., metropolitan area networks• Enterprise networks• Content distribution networks

m Edge• Local area networks

94


r Separator sizem Core -> Intermediate

• Stub ASs, e.g., metropolitan area networks: < 10 links• Enterprise networks: < 10 links• Content distribution networks: < 1000 links

m Intermediate -> Edge• Local area networks: < 10 links

r Terminologym Core /WANm Intermediate / MANm Edge / LANm Separator / Attachment point (AP)

95

Hierarchical network

r Example: Three levels of hierarchym Routing via intermediate points – the separators

=> specify attachment pointsmWAN APs: WAP

• Provider access links

mMAN APs: MAP• Firewalls

96

Sending a packet

r Routing via intermediate access pointsmMapping service: resolve identifier to locatorm 3 locator parts: WAP|MAP|ID

97

Routing scalabilityr Core

m Routing based on WAPsm Stable business relationshipsm Almost no churnm Aggregatable addresses m Common routing protocol (e.g., BGP)

r Intermediate (smaller ISPs/enterprises)m Routing based on MAPsm Separate addresses and routingm Local changes à local impact

r Edge (e.g., Ethernet LAN)m Standard L2 switching

98

Mapping system

rDesign requirementsm Scales with number of hostsm Fast response timesm Easy to update

r Approachm Clients are responsiblem Hierarchical design

• Global DHT or DNS like system– For each identifier: pointer to MMS– WANs contribute resources

• MAN mapping service (MMS) – Stores locators for attached nodes – Provided by MAN(s)

99

Mapping identifiers to locators

r Stepsm Client queries

• Global DHT• MMS

r To avoid lookupsm Use cachingm Include source

locators in packetm …

r Global DHT/MMSm Can store multiple

alternatives

r Failure recoverym Via multiple

alternatives

100

Discussion (1)

r Scalabilitym Hierarchical routing AND mapping systemm Updates are localized => low update ratesm No manual configuration

rMobility: local visibility of changesm Intra-MAN mobility: frequent

• Updates restricted to MMS

m Inter-MAN mobility: less frequent• Update global DHT (fast)• Move locators to new MMS

101

Discussion (2)

rMultihomingm Inherent support: APs exposed to routing system

rMultipathm Use multiple locators in parallel

r Inbound traffic engineering m Per-host basismMANs/MMS have control

rMigration pathm To support legacy hosts

102

Migration via NATs/Firewalls: Sending

r Firewalls/NAT act as MAPsr Legacy packet arrives from LANm Treat dst address as dst IDm Resolves locator for IDm Add source locator

to packet headerm Encapsulate original packet

and sends it

103

B

Migration: Receiving

rWAP strips encapsulationrMAP/NAT strips the second layermMay get the mapping for the source locator

r Packet is routed onward

To: WAP

To: MAP

Loc(A)

From: ATo: B

To: MAP

Loc(A)

From: ATo: B

A => Loc(A)

From: ATo: B

104

What’s different here

r Routing hierarchy based on structure of the Internetm Smaller table sizesm Lower update rates

rMapping service is hierarchicalmWith local control and responsibility

rHosts are responsible for obtaining mappingr Incremental deployment possible

105

Lessons learned

rMain goalsm Scalabilitym Support for multi-homing, TE, mobility, etc.m Smooth migration, support for legacy hosts

r Key ideasm Separation of locator/identifier function of IP addressm Hierarchical routing and location mapping scheme

r Two componentsm Routing system based on locatormMapping system to map an identifier to a locater

106

Outline




Outline

107

Enabling Alternative Architectures

Network Virtualization Architecture: Proposal and Initial Prototype

108

Network virtualization scenarios

r Virtual networkm Resource isolationm Different architecture/protocol per virtual network

• Does not have to be IP protocol• Some with some QoS and security

m Expose network components to applications and services• Overcome Internet impassé

m Dynamic • New ones will come and old ones will go• Migration / Expansion / Contraction

m Multiple networks in parallel == diversity

r Simplify network management and service offeringsr Virtual networks != VPN – VPN is just a service!

Virtual networks != P2P network – P2P is just an overlay

109

Virtualization: Vision

Virtualization Management

Provisioning of Virtual Networks(on-demand instantiation of virtual networks)

Infrastructure

VirtualizedSubstrate

VirtualNetworkVirtual

Network

Virtualization of Resources(partitioning of physical infrastructure into “slices”)

Virtualization Management

Provisioning of Virtual Networks(on-demand instantiation of virtual networks)

Infrastructure

VirtualizedSubstrate

VirtualNetworkVirtual

Network

Virtualization of Resources(partitioning of physical infrastructure into “slices”)

110

Benefits of virtualization

rOvercome ossification of network core m Isolation as enabler for new technologies

• Traditional: IPv6, multi-cast, …• CSD: novel network architectures

m Deployment of innovative productsm Network diagnosis

r Efficient utilization of resourcesmMigration of devices (such as routers)

– similar to server virtualizationm Traffic load balancing (“migration” of links)

r New business opportunities m Sharing of physical resources

(e.g., T-Mobile UK and 3 UK)

111

Virtual network – terminology

Virtual linksInfrastructure provider link

Virtual nodes

Physical node

Legacy nodesInfrastructure provider A

Infrastructure provider B

Substrate nodes

112

Virtual node – terminology

…

Physical Resources

InfrastructureProvider

?????

?????

VNet User

Substrate node control

per VNetcontrol

VNet

A

VNet

B

VNet

Z

PhysicalLink

113

Roles in the Internet

r Traditional roles: m Service providers (SP)

• Google, World of Warcroft, …

m Internet Service Providers (ISPs)• Deutsche Telekom, AT&T, …

r Recently: m Physical infrastructure provider (PIPs)m Bit-pipe providers m Service providers (SP)

114

Roles with network virtualization

VNet Operator

VNet Provider

Infrastructure provider Infrastructure provider…..

Service Provider

115

Tasks: Birdseye view

r Physical Infrastructure Provider (PIP)m Provides Virtual Resources + Resource Control

Interface

r VNET Provider (VNP)m Assembles virtual networksm Intuitively: provides layer of indirection

r VNET Operator (VNO)m Operates, controls, manages virtual networks

(e.g., comparable to NOC)

r Service provider (SP)m Offers the service

116

Physical Infrastructure Provider

r Services:mProvides Virtual ResourcemResource Control Interface

r Input: Requests for virtualized resources from VNP

r Task: m Creation of topology (constituents)m Pointers to virtual resourcesm Resource Control Interface

• Virtual Node Bootstrapping• Interconnection

117

VNET Provider (VNP)

r Service: m Instantiated virtual networks

(interconnected virtual nodes with bootstrapping environment)

m Handles contracts with PIP and VNO.

r Input: Abstract request for VNetr Task: m Identify appropriate PIPsm Negotiate contractsm Partition network topology and acquire partial VNETs

and Control Interfaces m Assemble virtual networks and control interfaces from

partial VNETs provided by PIPs

118

VNET Operator (VNO)

r Service: m Bootstraps, operates, controls, manages fully

instantiated virtual networkm Operates on virtual resources, identified by Identifiers

(not Locators)

r Input: Interconnected virtual networkr Task: operating, managing of virtual network

119

Control interfaces

120

VNET Provider

PIP

Management PIP1

Management VNP

Management PIP2

Management entity Console proxy

VNET signaling and control

121

VNET Operator

VNET Provider

PIP

Management PIP1

Management VNP

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.

Management PIP2

1 2

122

VNET Operator

VNET Provider

PIP

Management PIP1

Management VNP

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.

Management PIP2

1 2(1) (2) ID

123

IP

Management PIP1

Management VNP

Management PIP2

NYC

London NYC

London

124

IP

Management PIP1

Management VNP

Management PIP2

NYC

London NYC

London

ID.1

(3)

ID’

125

IP

Management PIP1

Management VNP

Management PIP2

NYC

London NYC

London

ID.1 ID.2

(3)

ID’ ID’’(4)

126

VNET Provider

PIP

Management PIP1

Management VNP

Management PIP2

C

VM

[ID’.ID.1, console1](5)

console1

127

VNET operator

VNET Provider

IP

Management IP1

Management VP

Management IP2

C

VM

console1

C

VM

console1

console1 console2

[[ID.1,console1];[ID.2, console2]](6)

128

VNET operator

VNET Provider

IP

Management IP1

Management VP

Management IP2

C

VM

console1

C

VM

console1

console1 console2

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.1 2

129

Lessons learned

r Isolate tasks => business opportunitiesm E.g.: Magnitude of the investment cost

• AT&T plans to invest 17–18 Bn $ in 2009 compared to a revenue of 124 Bn $ in 2008

• Deutsche Telekom plans to invest 8.7 Bn Euro compared to revenues of 62 Bn Euro in 2008

1% is substantial!

rDon’t forget control interfacesr Interprovider issues are trickyr Indirection and resource isolation are great tools

130

Case study: Locating performance problems

aided by network virtualization

131

Network debugging: Motivation

rHow do you test an update to the configuration or software of your system?

simulation

?scalable?cheap? accuracy?

testbed

?may be more accurate? but user behavior?? expensive to run? on large scale?? longtime?

132

Network diagnosis/debugging

r Problem: Implementation/configuration issue surface in large-scale, long-term deployments with real user traffic

r Goal:m Do not change network under testm Avoid probe effect

rDiagnosis methods:m Instrumentationm Regression tests

133

Instrumentation

Moni

Moni Moni

SubstrateVhost

Vhost Vhost

VNET 1Monitoring

r Pair production VNet with monitoring VNetr Copy all/selected packets to monitoring VNetr Processing is accounted to monitoring VNet

Regression testing – Shadow Vnet

V1.1

V1.1 V1.1

Substrate

V1.0

V1.0 V1.0

VNet running V1.0

VNet running V1.1

Ctrl

Ctrl Ctrl

Ext 1Ext 2

Control Vnet

Input dist'ed to Vnet 1.0and Vnet 1.1

Output of Vnet 1.0 dist'edto ext entities

135

Regression testing – Shadow Vnet

r Run VNet1.0, VNet1.1 monitoring VNetr Distribute external input to both VNet1.0 and VNet1.1r Ctrl compares output behavior of VNet1.0 and VNet1.1

for semantic equalityr Only output of VNet1.0 is distributed to external entities

V1.1

V1.1 V1.1

Substrate

V1.0

V1.0 V1.0

VNet running V1.0VNet running V1.1

Ctrl

Ctrl Ctrl

Ext 1Ext 2

Control Vnet

Input dist'ed to Vnet 1.0and Vnet 1.1

Output of Vnet 1.0 dist'edto ext entities

136

Example: VoIP with background load

r Phase 1: Minimal background trafficr Phase 2: Background traffic increasesr Phase 3: Start ShadowVNet: VNET Br Phase 4: Enable QoS in VNET Br Phase 5: VNET B becomes operational

137

Example: VoIP with background load

r User perceived quality is restored when the ShadowVNet is activated

Lessons learned

r New network debugging featuresm Instrumentationm Regression testsm Distributed debugger

r Goalsm To not change network under testm Avoid probe effect

r Solution: Network virtualizationm Isolationm Accounting of resources

139

Outline




Outline

140

Case Study: OpenFlow

An exciting new technology for separating hardware and software

141

OpenFlow – An enabler for open control of the network

rOpenFlow moves control path in each switch/router (middlebox) to an external controller, which makes policy decisions at the flow level (flow is defined by Layer 2, Layer 3 and/or Layer 4 header fields).

rWith OpenFlow, each switch speaks a separate control protocol with an external controller over SSL

Forwarding Table Calculation

Packet Forwarding Engine Traditional

Switch

headerLocal forwarding decision per packet a flow of today consists of 100th of packets

OpenFlow Switch

SecureChannelSecure

Channel SSLsw

OpenFlowSwitch

FlowTableFlowTable

hw

Network Control

Network Control Generic concept

of per flowswitching

Network Control

Network Control

142

r Interface between the OpenFlow network and the client enables, e.g., on demandm Constraints on routem Temporary upgrade in service/QoS.

Example service using OpenFlowPer-flow policy and QoS on demand

Controller

OpenFlow devices

QoS/privacy contraints: §Delay < 10ms§Bandwidth > 1Mbps§Not through region X

QoS/privacy contraints: §Delay < 10ms§Bandwidth > 1Mbps§Not through region X

QoS boost: Increase bandwidth for this specific flow.

QoS boost: Increase bandwidth for this specific flow.

143

Controller

PC

OpenFlow usage – Simple virtualization. Dedicated OpenFlow network.

OpenFlow Switch

OpenFlow Switch

Peter’s codePeter’s code

Decision?OpenFlowProtocol

OpenFlow Switch

Peter’s RulePeter’s Rule

Peter’s RulePeter’s Rule Peter’s RulePeter’s Rule

144

OpenFlow is already supported on routers/switches.

Cisco Catalyst 6k

NEC IP8800

HP Procurve 5400

Juniper MX-series WiMax (NEC)

PC Engines

Quanta LB4G

145

An OpenFlow based Router

Taking advantage of + OpenSource Routing Software+ Inexpensive Switch Hardware

146

OpenFlow based router: FIBIUM.Evaluation of open-source routers.

§ ISPs spend significant annual CAPEX for routers etc.§ Currently a quasi-monopoly

vendor market for backbone routers and routers in huge data centers.§ Modularization/standardization of

router components/open-source software may open the market § Similar to Linux§ Industry standards for blade

servers

§ ISPs spend significant annual CAPEX for routers etc.§ Currently a quasi-monopoly

vendor market for backbone routers and routers in huge data centers.§ Modularization/standardization of

router components/open-source software may open the market § Similar to Linux§ Industry standards for blade

servers

Levers and current situation

§ Understand if low cost switches with open-source software can be suitable replacement for high-cost routers.§ Build and evaluate prototype

router using low-cost components and open-source software.

§ Understand if low cost switches with open-source software can be suitable replacement for high-cost routers.§ Build and evaluate prototype

router using low-cost components and open-source software.

Our Approach

The OpenFlow might be a low cost, flexible alternative

The OpenFlow might be a low cost, flexible alternative

147

OpenFlow based router: FIBIUM.Today’s inflexible routers.

§ Proprietary software§ Limited features customization§ No access to datapath§ Optimized but not programmable

hardware

§ Proprietary software§ Limited features customization§ No access to datapath§ Optimized but not programmable

hardware

Current IP routers§ Carrier-grade open-source based

routers, e.g., Vyatta, IPInfusion, Quagga§ High-performance and inexpensive

Ethernet layer-3 switches with OpenFlowsupport, e.g. HP, NEC, Cisco

§ Carrier-grade open-source based routers, e.g., Vyatta, IPInfusion, Quagga§ High-performance and inexpensive

Ethernet layer-3 switches with OpenFlowsupport, e.g. HP, NEC, Cisco

Observations

148

OpenFlow based router: FIBIUM.Divide and conquer.

§ Decouple routing and datapath§ Combine inexpensive OpenFlow-

enabled switch with open-source routing software on commodity hardware

§ Decouple routing and datapath§ Combine inexpensive OpenFlow-

enabled switch with open-source routing software on commodity hardware

Principles§ Current switches have sufficient

datapath performance§ Switch control logic is limited§ Current commodity hardware better than

route controllers on routers

§ Current switches have sufficient datapath performance§ Switch control logic is limited§ Current commodity hardware better than

route controllers on routers

Observations

149

OpenFlow based router: FIBIUM.From concept to reality.

§ Leverages OpenFlow interface of switch:§ RouteVisor programs the switch§ Route cache management ensures

good fast path performance despite limited switch control logic

§ Slow path handled by PC

§ Leverages OpenFlow interface of switch:§ RouteVisor programs the switch§ Route cache management ensures

good fast path performance despite limited switch control logic

§ Slow path handled by PC

FIBIUM§ Ensures that switch and PC combination

appears as a router to the outside world§ Interface between route control

logic on PC and switch§ Collects traffic statistics from switch

and updates data path on switch

§ Ensures that switch and PC combination appears as a router to the outside world§ Interface between route control

logic on PC and switch§ Collects traffic statistics from switch

and updates data path on switch

RouteVisor

150

OpenFlow based router: FIBIUM.Prototype.

§ Test: 2 HP switches, commercial routers (Cisco and Juniper) and Linux routers§ RouteVisor tasks:

§ Switch configuration§ Handle OSPF and BGP messages§ Route Cache management

§ Test: 2 HP switches, commercial routers (Cisco and Juniper) and Linux routers§ RouteVisor tasks:

§ Switch configuration§ Handle OSPF and BGP messages§ Route Cache management

Test lab

§ Control plane: 100K BGP updates per minute§ Communication channel between PC and

switch: § Traffic statistics: 100K per second§ Switch data path updates: 1000

modifications per second

§ Control plane: 100K BGP updates per minute§ Communication channel between PC and

switch: § Traffic statistics: 100K per second§ Switch data path updates: 1000

modifications per second

Prelim. performance evaluation

Lessons learned

rOpen interface == new opportunitiesr Flexibility of software wins over closed systemsr Example: FIBIUMm Control: Open source routing softwaremData path: Hardware

152

Rethinking the Internet architecturer Explore alternative architecturesr Approachm Incremental

• Apply point-solutions to the current architecture

m Clean slate design (CSD)• Start from scratch

r Advantage CSDm No limitations: enables rethinking of the network and

service architecturem Architecture not intrinsicm Experiments and failures are possible

153

CSD: Reshaping the Internetr Impact on users:

m Ease of access to relevant informationm New control plane with new capabilitiesm Easy to introduce new applications with new features

• Security, mobility, quality of service

r Impact of new economic models:m New interfaces between providers (network/service)m New value-chain and new roles for providersm Open interfaces may enable new ecosystems of business alliances

r Impact on society:m Information society

r Impact on operators: m Easier network management

npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...

Documents

Transcript of npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...