Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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
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
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
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
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
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
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
Performance/Path Characteristics
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
Performance/Path Characteristics
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
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
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
Source: Arbor Networks 2009
à New core of interconnected content and consumer networks
46
The new Internet
Source: Arbor Networks 2009
à New core of interconnectedcontent and consumer networks
Google, Google, AkamaiAkamai, ,
RapidShareRapidShare, , ……
47
The new Internet
Source: Arbor Networks 2009
à New core of interconnectedcontent and consumer networks
Moving Target I :
Popular Applications
48
The new Internet
Source: Arbor Networks 2009
à New core of interconnectedcontent and consumer networks
Moving Target I :
Popular Applications
Moving Target II :
Bottlenecks
49
The new Internet
Source: Arbor Networks 2009
à New core of interconnected content and consumer networks
Moving Target II :Bottlenecks
à ISPs lost control of their traffic
Moving Target I :
Popular Applications
50
The new Internet
Source: Arbor Networks 2009
à New core of interconnected content and consumer networks
Moving Target II :Bottlenecks
à ISPs lose control of their network
Moving Target I :
Popular Applications
“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
Field TestISP-Application Collaboration
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
Internet Service ProviderInternet Service Provider(ISP)(ISP)
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
Field TestISP-Application Collaboration
62
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
3
4
6PaDISPaDIS
5
Provider-aided Distance Information System
PaDIS
63
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
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
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
3
4
6PaDISPaDIS
5
Full View Full View of the ISP of the ISP NetworkNetwork
Content can be downloaded from any eligible host!
PaDIS
65
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
3
4
6PaDISPaDIS
5
Full View Full View of the ISP of the ISP NetworkNetwork
Host1
Host2
Host3
Host4
PaDIS
66
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
3
4
6PaDISPaDIS
5
Full View Full View of the ISP of the ISP NetworkNetwork
Host1
Host2
Host3
Host4 Host2
Host4
Host3
Host1
PaDIS
67
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
3
4
6PaDISPaDIS
5
7
7
Full View Full View of the ISP of the ISP NetworkNetwork
PaDIS
68Client
Host A
Host B
Host C
Network load balancing
69
Network load balancing
Client
Host A
Host B
Host C
70
Network load balancing
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
Field TestISP-Application Collaboration
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
Internet Service ProviderInternet Service Provider(ISP)(ISP)
Host
1
2
5
3
6PaDISPaDIS
4
7
7
ISP applications collaboration
77
Client
External DNS
Provider DNS
Internet Service ProviderInternet Service Provider(ISP)(ISP)
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
Internet Service ProviderInternet Service Provider(ISP)(ISP)
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
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
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
r Key ideasm Separation of locator/identifier function of IP address
=> separation of routing and location mapping
mHierarchy for routing and location mapping
87
Approach
r Key ideasm Separation of locator/identifier function of IP address
=> separation of routing and location mapping
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
Stub ASAccess Provider
Core
EnterpriseNetwork
ISP1
ISP2ISP3
TransitAS 1
TransitAS 2
92
r AS corem ~5000 ASs
r AS edgem ~30000 AS
Stub ASAccess Provider
Core
EnterpriseNetwork
ISP1
ISP2ISP3
TransitAS 1
TransitAS 2
Potential large
separator
Potential small
separator
93
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
m Intermediate• Stub ASs, e.g., metropolitan area networks• Enterprise networks• Content distribution networks
m Edge• Local area networks
94
Hierarchical routing: Internet
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
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
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
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
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