[PPT] - Time-varying resilient virtual network mapping for PowerPoint Presentation

SLIDE 1

Time-‑varying ¡resilient ¡ virtual ¡network ¡mapping ¡for ¡ mul6-‑loca6on ¡cloud ¡data ¡centers ¡

Minh ¡Bui1, ¡Ting ¡Wang1, ¡Brigi/e ¡Jaumard1, ¡ Deep ¡Medhi2 ¡and ¡Chris ¡Develder3 ¡ ¡

1: ¡CSE, ¡Concordia ¡University, ¡Montreal, ¡Canada ¡ 2: ¡CSEE, ¡University ¡of ¡Missouri, ¡Kansas ¡City, ¡MO, ¡USA ¡ 3: ¡INTEC ¡– ¡IBCN, ¡Ghent ¡University ¡– ¡iMinds, ¡Ghent, ¡Belgium ¡ ¡

SLIDE 2

Op6cal ¡clouds ¡

OpLcal ¡networks ¡crucial ¡for ¡ increasingly ¡demanding ¡cloud ¡ services, ¡e.g., ¡

§ CompuLng: ¡

High ¡energy ¡physics ¡
Amazon ¡EC2, ¡MicrosoS ¡Azure ¡

§ Online ¡storage: ¡

Dropbox, ¡Google ¡Drive, ¡etc. ¡

§ CollaboraLon ¡tools: ¡

MSOffice ¡365, ¡Google ¡Docs ¡

§ Video ¡streaming: ¡

NeZlix, ¡YouTube ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡
C. ¡Develder, ¡et ¡al., ¡"Op;cal ¡networks ¡for ¡grid ¡and ¡

cloud ¡compu;ng ¡applica;ons", ¡Proc. ¡IEEE, ¡Vol. ¡100, ¡

No. ¡5, ¡May ¡2012, ¡pp. ¡1149-‑1167. ¡

SLIDE 3

Network ¡virtualiza6on ¡

Physical ¡network ¡is ¡logically ¡ parLLoned ¡in ¡isolated ¡virtual ¡ networks ¡ ¡ § Virtual ¡Network ¡Operators ¡ (VNO) ¡operate ¡logically ¡ separate ¡networks ¡ § Physical ¡Infrastructure ¡ Providers ¡(PIP) ¡have ¡full ¡control ¡

ver ¡infrastructure ¡(fibers, ¡

OXCs) ¡

VNO 1 VNO 2 PIP

J.A. ¡García-‑Espín, ¡et ¡al., ¡"Logical ¡Infrastructure ¡ Composi;on ¡Layer: ¡the ¡GEYSERS ¡holis;c ¡approach ¡ for ¡infrastructure ¡virtualisa;on", ¡in ¡Proc. ¡TERENA ¡ Networking ¡Conference ¡(TNC ¡2012), ¡Reykjavík, ¡ Iceland, ¡21-‑24 ¡May ¡2012. ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 4

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 5

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 6

Resiliently ¡provisioning ¡virtual ¡cloud ¡networks ¡

¡ ¡ ¡How ¡to ¡choose ¡the ¡virtual ¡to ¡physical ¡mapping, ¡such ¡that ¡ § Services ¡remain ¡available ¡in ¡case ¡of ¡network ¡failures ¡ § Bandwidth ¡for ¡providing ¡services ¡is ¡minimal ¡

¡

? ¡

Note: ¡ § Anycast: ¡requests ¡coming ¡from ¡ users ¡can ¡be ¡served ¡by ¡any ¡server ¡ § Cloud ¡services ¡offered ¡by ¡VNO ¡ § Cloud ¡services ¡run ¡on ¡top ¡of ¡PIP ¡

¡

Users Grid Resources

?

app ¡

Grid/cloud resources

B. ¡Jaumard, ¡A. ¡Shaikh ¡and ¡C. ¡Develder, ¡"Selec;ng ¡

the ¡best ¡loca;ons ¡for ¡data ¡centers ¡in ¡resilient ¡op;cal ¡ grid/cloud ¡dimensioning ¡(Invited ¡Paper)", ¡in ¡Proc. ¡ 14th ¡Int. ¡Conf. ¡Transparent ¡OpLcal ¡Netw. ¡(ICTON ¡ 2012), ¡Coventry, ¡UK, ¡2-‑5 ¡Jul. ¡2012. ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 7

Two ¡proposed ¡protec6on ¡schemes: ¡

VNO-resilience PIP-resilience PIP PIP VNO VNO pW pB pS pW pB pS vs d1 d2

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

This ¡paper ¡

M. ¡Bui, ¡B. ¡Jaumard, ¡and ¡C. ¡Develder, ¡“Anycast ¡end-‑

to-‑end ¡resilience ¡for ¡cloud ¡services ¡over ¡virtual ¡

p;cal ¡networks” ¡(Invited ¡Paper), ¡in ¡Proc. ¡15th ¡Int. ¡
Conf. ¡Transparent ¡OpLcal ¡Netw. ¡(ICTON ¡2013), ¡

Cartagena, ¡Spain, ¡23-‑27 ¡Jun. ¡2013. ¡

SLIDE 8

Related ¡work: ¡Sta6c ¡traffic ¡scenarios ¡

§ Tradi6onal ¡dimensioning ¡(no ¡virtualisa6on, ¡no ¡resilience): ¡

Develder ¡et ¡al. ¡2009: ¡Anycast, ¡flexibility ¡in ¡choosing ¡data ¡center ¡

§ Resilient ¡dimensioning ¡problem: ¡

Shaikh ¡et ¡al. ¡2011, ¡Develder ¡et ¡al. ¡2013: ¡ ¡scalable ¡method, ¡no ¡synchronizaLon ¡

between ¡working ¡and ¡backup ¡DCs ¡

§ RouLng ¡cloud ¡service ¡requests ¡and ¡mapping ¡a ¡VNet ¡to ¡the ¡physical ¡ infrastructure ¡separately: ¡

Lee ¡et ¡al. ¡ ¡2009, ¡Yu ¡et ¡al. ¡2010: ¡Survivable ¡VNet ¡embedding, ¡but ¡assume ¡VNet ¡is ¡

given ¡ ¡

Jiang ¡et ¡al. ¡2012, ¡Alicherry ¡et ¡al. ¡2012: ¡ ¡OpLmal ¡server ¡selecLon ¡and ¡rouLng ¡of ¡

anycast ¡services ¡in ¡the ¡physical ¡layer ¡for ¡intra-‑ ¡and ¡inter-‑DC ¡networks ¡ ¡but ¡no ¡ resilient ¡network ¡design ¡in ¡the ¡virtual ¡layer ¡

§ VNet ¡planning ¡problem: ¡

Barla ¡et ¡al. ¡2012, ¡Barla ¡et ¡al. ¡2013: ¡using ¡mixed ¡integer ¡linear ¡programming, ¡but ¡no ¡

synchroniza;on ¡between ¡working ¡and ¡backup ¡DCs ¡

Bui ¡et ¡al. ¡2013 ¡(ICTON): ¡first ¡model ¡that ¡incorporates ¡synchronisaLon ¡path, ¡but ¡s;ll ¡

sta;c ¡traffic! ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 9

Problem ¡statement ¡

§ Study ¡6me-‑varying ¡traffic: ¡ Traffic ¡pa/ern ¡changes ¡from ¡one ¡period ¡(t) ¡to ¡the ¡next ¡(t+1) ¡ § Key ¡research ¡quesLon: ¡ Benefit ¡(in ¡network ¡resource ¡usage) ¡of ¡changing ¡routes ¡for ¡legacy ¡ traffic, ¡i.e., ¡that ¡conLnues ¡from ¡t ¡to ¡t+1? ¡

Does ¡it ¡help ¡to ¡only ¡change ¡backup ¡paths? ¡
Or ¡do ¡we ¡need ¡to ¡change ¡working ¡as ¡well? ¡
For ¡all ¡legacy ¡traffic? ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 10

Problem ¡statement ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡
Cloud ¡network ¡topology: ¡G ¡= ¡(V, ¡L), ¡with ¡V ¡= ¡nodes, ¡L ¡= ¡links ¡
LocaLons ¡of ¡the ¡data ¡centers, ¡VD ¡⊆ ¡V ¡ ¡
Set ¡of ¡service ¡requests, ¡K ¡parLLoned ¡into ¡

§ KLEG: ¡requests ¡in ¡period ¡t, ¡that ¡conLnue ¡into ¡the ¡next ¡t+1 ¡ § KADD: ¡requests ¡in ¡subsequent ¡period ¡t+1 ¡ and ¡characterized ¡by ¡ § vk: ¡source ¡of ¡service ¡ § Δk: ¡bandwidth ¡requirement ¡in ¡period ¡t ¡ § Services ¡originaLng ¡from ¡the ¡same ¡source ¡are ¡aggregated ¡

RouLng ¡of ¡the ¡requests ¡in ¡period ¡t: ¡KLEG ¡
Choice ¡of ¡primary ¡and ¡backup ¡DC ¡loca6ons ¡for ¡each ¡service ¡in ¡period ¡t+1 ¡
Primary, ¡backup ¡and ¡synchronizaLon ¡paths ¡in ¡period ¡t+1 ¡
Total ¡network ¡bandwidth ¡u6liza6on ¡is ¡minimized ¡
KLEG ¡are ¡(i) ¡unchanged, ¡(ii) ¡only ¡changed ¡for ¡backup, ¡(iii) ¡freely ¡changed ¡

Given: ¡ Find: ¡ Such ¡that: ¡

SLIDE 11

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 12

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 13

Solu6on: ¡Column ¡genera6on ¡model ¡

§ Column ¡generaLon ¡idea: ¡

Many ¡different ¡“configuraLons” ¡
Start ¡from ¡a ¡restricted ¡subset ¡of ¡such ¡“configuraLons” ¡
IteraLvely ¡find ¡addiLonal ¡configuraLons ¡that ¡reduce ¡the ¡cost: ¡

(1) ¡Restricted ¡Master ¡Problem ¡(RMP) ¡ (2) ¡Pricing ¡Problem ¡(PP) ¡to ¡find ¡new ¡configs ¡

§ A ¡configuraLon ¡= ¡

Working ¡path ¡ ¡
Backup ¡path ¡ ¡
Sync ¡path ¡between ¡the ¡primary ¡& ¡backup ¡DCs ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

VNO-resilience PIP VNO pW pB pS vs d1 d2

SLIDE 14

Column ¡genera6on ¡solu6on ¡algorithm ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

RMP ¡ SelecLon ¡of ¡the ¡best ¡ configuraLons ¡ Solve ¡PPADD ¡(k)/PPLEG ¡(k) ¡ GeneraLon ¡of ¡a ¡new ¡ promising ¡configuraLon ¡

Yes ¡ No: ¡select ¡ another ¡ request ¡k ¡

All ¡k ¡requests ¡ Unsuccessfully ¡ tested ¡ LP ¡is ¡

pLmally ¡

solved ¡ Find ¡an ¡ ¡ε–opLmal ¡ ILP ¡soluLon ¡

Yes ¡ No ¡ RMP ¡Output ¡/ ¡ ¡PP ¡Input: ¡ ¡ No ¡ PP ¡Output ¡/ ¡RMP ¡Input: ¡ ¡A ¡new ¡promising ¡configuraLon ¡ck ¡for ¡request ¡k ¡ Values ¡of ¡the ¡dual ¡ variables ¡ (check ¡ck ¡for ¡all ¡the ¡other ¡configuraLons ¡ In ¡order ¡to ¡avoid ¡duplicaLng ¡configuraLons) ¡

NegaLve ¡ reduced ¡cost? ¡

SLIDE 15

¡ ¡ ¡ ¡ ¡ ¡ ¡ Constraints: ¡

Assure ¡all ¡requests ¡are ¡granted ¡
Count ¡legacy ¡changes ¡xLEG_BS, ¡xLEG_W ¡
Compute ¡W, ¡B, ¡S ¡bandwidths ¡
Check ¡capacity ¡constraints ¡on ¡data ¡centers ¡

Restricted ¡Master ¡Problem ¡(RMP) ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

PIP pW pB pS

Case ¡(ii): ¡ penalty ¡for ¡disrupLng ¡B/S ¡ path ¡of ¡legacy ¡ Case ¡(iii): ¡ penalty ¡for ¡disrupLng ¡W ¡ path ¡of ¡legacy ¡

SLIDE 16

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 17

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 18

Case ¡study ¡

§ Topology: ¡

24 ¡nodes, ¡43 ¡links ¡
Data ¡centers ¡in ¡ ¡ ¡ ¡ ¡: ¡

CA, ¡WY, ¡TX, ¡OH ¡

§ Traffic: ¡

Total ¡of ¡20…80 ¡requests ¡(same ¡for ¡t ¡and ¡t+1) ¡with ¡

Δk ¡in ¡[0,1] ¡units; ¡synchronisaLon ¡fracLon ¡δk ¡= ¡0.1 ¡

Period ¡t: ¡30% ¡region ¡1, ¡50% ¡region ¡2, ¡20% ¡region ¡3 ¡
Period ¡t+1: ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

1 2 6 3 4 7 8 10 14 13 17 18 24 23 22 16 11 15 21 20 19 9 12

1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1100 1100 1150 1200 1200 1200 1200 1300 1300 1400 1900 2600 900 900 900 950 950 800 850 850 1000 800 800 800 800 850 900 250 600 300 700 600 650

Region 1 Region 2 Region 3

15 5 6 13

Scenario ¡ Region ¡1 ¡ Region ¡2 ¡ Region ¡3 ¡ 40% ¡legacy ¡ 20% ¡drop ¡ 20% ¡add ¡ 30% ¡drop ¡ 10% ¡add ¡ 10% ¡drop ¡ 30% ¡add ¡ 60% ¡legacy ¡ 10% ¡drop ¡ 10% ¡add ¡ 20% ¡drop ¡ 10% ¡add ¡ 10% ¡drop ¡ 20% ¡add ¡ 80% ¡legacy ¡ 10% ¡drop ¡ 10% ¡add ¡ 10% ¡drop ¡

‑ ¡
‑ ¡

10% ¡add ¡

SLIDE 19

Results: ¡Net ¡total ¡bandwidth ¡savings? ¡

1. Only ¡changing ¡backup ¡(II, ¡ ¡ ¡ ¡ ¡ ¡) ¡does ¡not ¡save ¡much; ¡changing ¡also ¡

working ¡(III, ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡) ¡does ¡

2. Capacity ¡savings ¡are ¡realized ¡through ¡sharing ¡of ¡backup ¡
3. Savings ¡obviously ¡diminish ¡with ¡decreasing ¡legacy ¡fracLon ¡(LàR) ¡ ¡

Intuitively expected: for low sync bandwidth, VNO-resilience better Benefit diminishes for larger sync bandwidth

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

80% legacy traffic 60% legacy traffic 40% legacy traffic

25000

50000 75000 100000 125000 20 40 60 80 20 40 60 80 20 40 60 80

Number of requests Bandwidth (summed over all links)

Total

Working (W) Backup (B) Synchronisation (S) Scenario I (no changes for legacy) Scenario II (change only B and/or S) Scenario III (change B, S, and/or W)

SLIDE 20

Results: ¡Change ¡all ¡legacy ¡routes? ¡

Of ¡the ¡legacy ¡requests, ¡we ¡typically ¡change ¡>50%, ¡but ¡only ¡about ¡ 20% ¡need ¡to ¡reroute ¡the ¡working ¡path ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 21

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 22

Overview ¡

1. IntroducLon ¡
2. Problem ¡statement ¡
3. Model ¡& ¡soluLon ¡approach ¡
4. Case ¡study ¡
5. Conclusions ¡
M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 23

Conclusions ¡

§ Scalable ¡column-‑generaLon ¡based ¡method ¡for ¡resilient ¡VNet ¡ planning ¡of ¡Lme-‑varying ¡traffic ¡ § Our ¡case ¡study ¡shows ¡that: ¡

Changing ¡legacy ¡traffic ¡from ¡one ¡period ¡to ¡the ¡next ¡only ¡really ¡

saves ¡if ¡we ¡allow ¡changing ¡the ¡working ¡paths ¡

… ¡but ¡we ¡need ¡only ¡to ¡change ¡around ¡20% ¡of ¡them ¡

§ Future ¡work: ¡

OpLmizaLon ¡of ¡choice ¡of ¡DC ¡locaLons ¡(e.g., ¡‘sca/ered’ ¡vs ¡

‘paired’, ¡see ¡ICTON ¡2013) ¡

Extensive ¡studies ¡of ¡different ¡traffic ¡pa/erns, ¡over ¡mulLple ¡

periods ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡

SLIDE 24

? ¡

Thank ¡you ¡… ¡any ¡ques6ons? ¡

Prof. ¡Chris ¡Develder ¡

chris.develder@intec.ugent.be ¡ Ghent ¡University ¡– ¡iMinds ¡ ¡ ¡

M. ¡Bui, ¡et ¡al., ¡"Time-‑varying ¡resilient ¡virtual ¡network ¡mapping ¡

for ¡mul;-‑loca;on ¡cloud ¡data ¡networks", ¡ICTON ¡2014 ¡