Vytautas Valancius, Nick Feamster, Akihiro Nakao, and Jennifer - - PowerPoint PPT Presentation

vytautas valancius nick feamster akihiro nakao and
SMART_READER_LITE
LIVE PREVIEW

Vytautas Valancius, Nick Feamster, Akihiro Nakao, and Jennifer - - PowerPoint PPT Presentation

Vytautas Valancius, Nick Feamster, Akihiro Nakao, and Jennifer Rexford Cloud computing is on the rise Provides computing resources and storage in cloud data centers Hosting on the steroids for Internet services 2 ISP1 Hosted


slide-1
SLIDE 1

Vytautas Valancius, Nick Feamster, Akihiro Nakao, and Jennifer Rexford

slide-2
SLIDE 2

Cloud computing is on

the rise

Provides computing

resources and storage in cloud data centers

Hosting on the steroids

for Internet services

2

slide-3
SLIDE 3

3

Cloud Data Center

Data Center Router Interactive Service Bulk transfer

Internet

Routing updates Packets ISP1 ISP2

Hosted

services have different requirements

Too slow for

interactive service, or

Too costly for

bulk transfer!

slide-4
SLIDE 4

Multiple upstream ISPs

Amazon EC2 has at least 58 routing peers in Virginia

data center

Data center router picks one route to a

destination for all hosted services

Packets from all hosted applications use the

same path

4

slide-5
SLIDE 5

Obtain connectivity to upstream ISPs Physical connectivity Contracts and routing sessions Obtain the Internet numbered resources

from authorities

Expensive and time‐consuming!

5

slide-6
SLIDE 6

6

Cloud Data Center

Interactive Service Bulk transfer

Internet

ISP1 ISP2 Virtual Router B Virtual Router A Transit Portal Routes Packets

Full Internet route control to hosted cloud services!

slide-7
SLIDE 7

Motivation and Overview Connecting to the Transit Portal Advanced Transit Portal Applications Scaling the Transit Portal Future Work & Summary

7

slide-8
SLIDE 8

Separate Internet router for each service Virtual or physical routers Links between service router and TP Each link emulates connection to upstream ISP Routing sessions to upstream ISPs TP exposes standard BGP route control interface

8

slide-9
SLIDE 9

Transit Portal Virtual BGP Router

9

Cloud client with two

upstream ISPs

ISP 1 is preferred ISP 1 exhibits excessive

jitter

Cloud client reroutes

through ISP 2

ISP 1 ISP 2 Interactive Cloud Service BGP Sessions Traffic

slide-10
SLIDE 10

Server with custom routing software 4GB RAM, 2x2.66GHz Xeon cores Three active sites with upstream ISPs Atlanta, Madison, and Princeton A number of active experiments BGP poisoning (University of Washington) IP Anycast (Princeton University) Advanced Networking class (Georgia Tech)

10

slide-11
SLIDE 11

Internet services require fast name resolution IP anycast for name resolution

DNS servers with the same IP address IP address announced to ISPs in multiple locations Internet routing converges to the closest server

Available only to large organizations

11

slide-12
SLIDE 12

ISP1 ISP2 ISP3 ISP4 Transit Portal Transit Portal

Asia North America

Anycast Routes

12

Name Service Name Service

TP allows hosted applications use IP anycast

slide-13
SLIDE 13

Internet services in geographically diverse

data centers

Operators migrate Internet user’s

connections

Two conventional methods: DNS name re‐mapping

▪ Slow

Virtual machine migration with local re‐routing

▪ Requires globally routed network

13

slide-14
SLIDE 14

ISP1 ISP2 ISP3 ISP4 Transit Portal Transit Portal

Asia North America

Tunneled Sessions

14

Active Game Service Internet

slide-15
SLIDE 15

Scale to dozens of sessions to ISPs and

hundreds of sessions to hosted services

At the same time: Present each client with sessions that have an

appearance of direct connectivity to an ISP

Prevented clients from abusing Internet routing

protocols

15

slide-16
SLIDE 16

Conventional BGP router:

Receives routing updates from

peers

Propagates routing update

about one path only

Selects one path to forward

packets

Scalable but not

transparent or flexible

16

ISP1 ISP2 BGP Router Updates Client BGP Router Client BGP Router Packets

slide-17
SLIDE 17

Bulk Transfer Routing Process

Store and propagate all

BGP routes from ISPs

Separate routing tables Reduce memory

consumption

Single routing process ‐

shared data structures

Reduce memory use from

90MB/ISP to 60MB/ISP

17

ISP1 ISP2 Virtual Router Virtual Router Routing Table 1 Routing Table 2 Interactive Service

slide-18
SLIDE 18

Bulk Transfer Routing Process

Hundreds of routing

sessions to clients

High CPU load

Schedule and send routing

updates in bundles

Reduces CPU from 18% to 6% for

500 client sessions

18

ISP1 ISP2 Virtual Router Virtual Router Routing Table 1 Routing Table 2 Interactive Service

slide-19
SLIDE 19

Forwarding Table

Connecting clients Tunneling and VLANs Curbing memory usage Separate virtual routing

tables with default to upstream

50MB/ISP ‐> ~0.1MB/ISP

memory use in forwarding table

19

ISP1 ISP2 Virtual BGP Router Virtual BGP Router Forwarding Table 1 Forwardng Table 2 Bulk Transfer Interactive Service

slide-20
SLIDE 20

Future work: More deployment sites Making TP accessible for network research

test‐beds (e.g., GENI, CoreLab)

Faster forwarding (NetFPGA, OpenFlow) Lightweight interface to route control

20

slide-21
SLIDE 21

Limited routing control for hosted services Transit Portal gives wide‐area route control Advanced applications with many TPs Open source implementation Scales to hundreds of client sessions The deployment is real Can be used today for research and education More information http://valas.gtnoise.net/tp

21

Questions?