Deliverable 3.3 Service Mapping v1.0 - CORDIS · 2017-04-25 · T-NOVA | Deliverable D3.3 Service mapping © T-NOVA Consortium 6 List of Tables Table 1 T-NOVA requirements relevant

T-NOVA|DeliverableD3.01 Inter. Report on Orchestrator PlatformImplementation

©T-NOVAConsortium 11

DeliverableD3.3

Servicemapping

Editor F.Liberati(CRAT)

Contributors Francesco Liberati, Federico Cimorelli, Francesco Delli Priscoli,Alessandro Giuseppi, Saverio Mascolo, Antonio Pietrabissa,Vincenzo Suraci, Letterio Zuccaro (CRAT), Alberto Ceselli,Alessandro Petrini, Marco Trubian (UniMi), PanagiotisPapadimitriou, David Dietrich, Ahmed Abujoda (LUH), MichaelMcGrath, Vincenzo Riccobene (INTEL), Aurora Ramos (ATOS),Maurizio Arnaboldi, Pietro Paglierani (ITALTEL), José Bonnet(PTIN),JordiFerrerRiera,JosepBatalléOronich,EduardEscalona(i2CAT),ThomasPliakas(CLDST)

Version 3.1-final

Date 12thJanuary,2016

Distribution PUBLIC(PU)

Ref. Ares(2016)2347437 - 20/05/2016

T-NOVA|DeliverableD3.3 Servicemapping

©T-NOVAConsortium

2

ExecutiveSummary

ThisdeliverablepresentstheoutcomesofTask3.3“Servicemapping”,oftheT-NOVAproject.Thetaskisfocusedontheresearchanddesignofalgorithmsfortheoptimalmappingofvirtualnetworkservicesinvirtualizednetworkinfrastructures.

Thisworkstartedbyareviewofusecases,requirementsandarchitecturedesignproposedinWorkPackage(WP)2,andbytheanalysisofthescientificandtechnologicalstateoftheartinservicemappingalgorithms.Furthermore,theinputandoutputinterfacesforthealgorithmhavebeenspecifiedindetail,intermsofneededinputdataandofrequiredoutputdataforaservice instantiation. Based on the above points, three main service mapping algorithmstogetherwithanalgorithmforserviceschedulinghavebeenproposed.Twoservicemappingalgorithmsarebasedonintegerlinearprogrammingwhilethethirdisbasedonastochasticcontrolmethodology.Themathematicalformulationandthepropertiesofthealgorithmsarepresentedanddiscussedindetail.Simulationsresultsinemulatedenvironmentsareproposedanddiscussedtohighlightthecharacteristicsonthealgorithms.Priortothedescriptionofthealgorithms,acommonmathematicalframeworkformodellingtheservicemappingproblemis proposed, based on the ETSI reference documents on virtualization architecture. Themodellingframeworkisbasedongraphtheoryandprovidesawayforconsistentlymodelling:

1. Therequirementsofthenetworkservicestobemapped.2. Thenetworkinfrastructure’stopologyanditscurrentoccupancylevelsothatfeasible

andoptimalmappingsarecomputedbythealgorithm.

Thedevelopedalgorithmsallowtoconsidermultiplemappingobjectives,including:

1. Maximisationofnetworkservicerequests’acceptance.2. Minimizationofmappingcosts(i.e.thecostsforemployingthedifferentnetwork

resources).3. Balancingofnetwork/datacenterloaddistribution.

Asideof thedesignof themappingalgorithms,another fundamentaloutputof this task isgiven by the design of a microservice-based service mapping module, aimed to host theservicemapping algorithm, and of its integration inside TeNOR, the T-NOVAorchestrator.Suchactivityhasbeencarriedout inclosecooperationwiththeactivitiesdedicatedtothedesignoftheinfrastructurerepository(Task3.2)andofthenetworkservicedescriptor(WP6).Asamatteroffact,assaidbefore,networkservices’requirementsandnetworkstatusarethetwokeyinputstotheservicemappingalgorithms.Theservicemappingmoduleoffersthepossibility to integrate and avail of any service mapping algorithm conforming to theinput/outputspecifications,whicharealignedtothethreemappingalgorithmsdeveloped.Inthisway,anyinvestigatedservicemappingalgorithm,orevenacombinationofthemcanbepotentiallyintegratedinTeNOR,andtested.

Finally, the integration of the service mapping module including one of the developedmappingalgorithmshasbeenachievedandpreliminarytested,withdetailsreportedinthisdocument.


©T-NOVAConsortium

3

TableofContents

1.INTRODUCTION..............................................................................................................7

1.1.MOTIVATION,OBJECTIVESANDSCOPE....................................................................................71.2.STRUCTUREOFTHEDOCUMENT............................................................................................7

2.PROBLEMDEFINITION....................................................................................................9

2.1.USECASESANDREQUIREMENTS............................................................................................92.1.1.Usecases.................................................................................................................92.1.2.Requirements........................................................................................................10

2.2.REFERENCESCENARIOANDARCHITECTURE............................................................................132.2.1.ArchitectureandFlows..........................................................................................13

2.3.PROBLEMMODELLING.......................................................................................................162.4.SCIENTIFICANDTECHNOLOGICALSTATEOFTHEART...............................................................20

2.4.1.ScientificStateoftheArt.......................................................................................202.4.2.TechnologicalStateoftheArt...............................................................................22

3.T-NOVASERVICEMAPPINGALGORITHMS.....................................................................25

3.1.ANINTEGERLINEARPROGRAMMINGBASEDAPPROACH..........................................................253.2.REINFORCEMENTLEARNINGBASEDAPPROACH......................................................................27

3.2.1.VNFMappingviaReinforcementLearning............................................................273.2.2.NSMappingAlgorithm..........................................................................................31

3.3.MULTI-STAGENETWORKSERVICEEMBEDDING......................................................................333.3.1.Mainassumptions.................................................................................................333.3.2.IterativeAlgorithm................................................................................................333.3.3.ILPModelforServiceChainPartitioning...............................................................333.3.4.MIPModelforNF-subgraphMapping...................................................................34

3.4.VNFSCHEDULINGOVERANNFVINFRASTRUCTURE................................................................363.5.SUMMARYOFTHEFEATURESOFTHEALGORITHMS.................................................................38

4.SERVICEMAPPINGMODULEIMPLEMENTATIONANDINTEGRATION............................40

4.1.IMPLEMENTATION.............................................................................................................404.2.INTEGRATION...................................................................................................................42

4.2.1.InteractionwiththeInfrastructureRepository......................................................444.2.2.InteractionwiththeT-NOVANSD..........................................................................47

5.SIMULATIONTESTS.......................................................................................................50

5.1.INTEGERLINEARPROGRAMMINGBASEDAPPROACH................................................................505.1.1.Test1:EvaluatingsolversscalabilityastheNIsizeincreases................................515.1.2.Test2:Evaluatingsolversscalabilityastheaveragedatacenterloadincreases...535.1.3.Test3:Finetuningofmodelparameters...............................................................54

5.2.REINFORCEMENTLEARNINGBASEDAPPROACH......................................................................575.2.1.MappingofSingleVNFs.........................................................................................575.2.2.MappingofCompleteNSs.....................................................................................59

5.3.MULTI-STAGENETWORKSERVICEEMBEDDING......................................................................61

6.CONCLUSIONS..............................................................................................................64

7.REFERENCES.................................................................................................................65

8.LISTOFACRONYMS......................................................................................................68


©T-NOVAConsortium

4

9.LISTOFMATHEMATICALSYMBOLS...............................................................................70

10.ANNEXA:DOCUMENTATIONOFTHESERVICEMAPPINGMODULEAPI.......................73

11.ANNEXB:DETAILSONINFRASTRUCTUREREPOSITORYQUERYING..............................77

12.ANNEXC:DETAILSONTHESERVICECATALOGUEQUERYING.......................................81


©T-NOVAConsortium

5

ListofFigures

Figure1T-NOVAOverallUsecasediagram([1]).......................................................................9Figure2TheservicemappingmoduleintheTeNORarchitecture..........................................13Figure3Resourcerepositoryhighlevelarchitecture.............................................................14Figure4Interactionoftheservicemappingmodulewiththeinfrastructurerepositoryandthenetworkservicecatalogue......................................................................................................15Figure5ExampleofafirstlevelSMproblem(a)anditssolution(b).....................................17Figure6ExampleofaVNFcomposedbyfourVNFcs(ontheleft)andtheinternalstructureofaDCmodel(ontheright)........................................................................................................17Figure7ExampleofsecondlevelSMproblem(a)anditssolution(b)...................................18Figure8OpenStackFilterschedulerapproach(pictureelaboratedfrom[28])......................23Figure9Weightinghosts(pictureelaboratedfrom[28]).......................................................24Figure10ReinforcementLearningworkflow..........................................................................30Figure11Networkservice(controlfunctions)schedulingontoNFVI.....................................36Figure12DetailsoftheT-NOVAServiceMappermicroservice..............................................40Figure13InfrastructureRepositorysub-systemarchitecture................................................45Figure14Simpleserverresourcegraph..................................................................................46Figure15Percentageacceptanceasaverageloadincreases..................................................54Figure16CPUtimeasaverageloadincreases........................................................................54Figure17Acceptancerateinfunctionofthearrivalrank.......................................................55Figure18Averagecomputingtimeinfunctionofthearrivalrank(onstresstest)................56Figure19Revenueevolution:greedyandQ-Learningpoliciescompared..............................57Figure20AverageNSacceptancerates..................................................................................58Figure21UtilizationofPoPresources....................................................................................58Figure22NSstopologiesandbandwidthrequirementsfortheNS1(a),theNS2(b)andtheNS(c)............................................................................................................................................59Figure23NItopology(20nodes)andbandwidthavailability(a),linkdelay(b).....................59Figure24.Acceptancerateinfunctionoftheload(samerewardforallNStypes)................60Figure 25: Load balancing level across the DC servers with weight-minimized requestpartitioning..............................................................................................................................61Figure26:Acceptanceratewithweight-minimizedandgreedyrequestpartitioning............62Figure27:Cumulativerevenuewithweight-minimizedandgreedyrequestpartitioning.....62Figure28:Acceptanceratewithdiversearrivalratesofexpiringservicechainrequestswithweight......................................................................................................................................63


©T-NOVAConsortium

6

ListofTables

Table1T-NOVArequirementsrelevanttoservicemapping...................................................11Table2PseudocodefortheVNFmappingbasedonreinforcementlearning.......................30Table3PseudocodefortheNSmappingbasedonreinforcementlearning..........................31Table4Comparedviewofmainalgorithms’features............................................................39Table5APIcallsforspecificinfrastructureinformationretrieval...........................................47Table6NSD:SLA......................................................................................................................48Table7NSD:SLA:assurance_parameters...............................................................................48Table8NSD:SLA:assurance_parameters:violation...............................................................48Table9NSD:SLA:constituentVNFs........................................................................................48Table10VNFD:deploymentflavor.........................................................................................49Table11vnfd:deployment_flavour:constituent_vdu.............................................................49Table12Instancedetails.........................................................................................................50Table13Solversscalabilitytest,60stimelimit.......................................................................51Table14Solversscalabilitytests,overallacceptancerate......................................................53Table15Servicemappingrequestparameters(bodyofthePOSTcall).................................73Table16Sequentialstepsinqueryingtheinfrastructurerepository......................................77Table17Sequentialstepsinqueryingtheservicecatalogue..................................................81


©T-NOVAConsortium

7

1. INTRODUCTION

1.1. Motivation,objectivesandscope

In the T-NOVA system, the servicemappingmodule is the component responsible for thedecisionofwhichresourcesof thevirtualizednetwork infrastructuremustbe leveragedtobestserveanincomingrequestofaNetworkService(NS)instantiation.Asamatteroffact,theavailabilityofmultipleallocationsolutionsand,atthesametime,theheterogeneityofresourcestypes,intermsofrequirements,costs,quality,etc.,makestheintroductionofanintelligentmappinglogicanecessity,oratleastahighlydesirablefeatureforincreasingtheefficiency of the instantiation process. The first aim of this deliverable is therefore thepresentationofageneralandcomprehensivediscussionoftheservicemappingprobleminvirtualizednetworkinfrastructures.Amathematicalmodellingframeworkfortheproblemishereprovided,anditisaswelldiscussedhowtheservicemappingmoduleactsasamoduleofTeNOR–theT-NOVAorchestrator–andhowitcoordinateswiththeothermodulesoftheT-NOVAarchitecturetoperform its functions.Secondly, thework inTask3.3hasaimedatresearchingdifferentservicemappingalgorithms1,designedtotackletherequirementsandthepeculiaritiesofthemappingproblemsaddressed,andtoexplorethestrengthsofferedbythedifferentmathematicaltoolshereused(mainlycomingfromthefieldsofintegerlinearprogrammingandstochasticcontroltheory).AthirdfundamentaloutputofTask3.3 isthedesignoftheservicemappingmodule,incorporatedinamicro-servicesarchitecture,anditsintegrationwithintheTeNORorchestrator.Thisintegration,inparticular,hasbeenachievedbymeansofadetaileddocumentationoftheexternalandinternalinterfacesofthemappingmodule.ThefirstaretheinterfacesbetweenthemappingmoduleandtheothercomponentsofTeNOR,whilethesecondonearetheinterfacesinsidetheservicemappingmodulewiththeactualmappingmathematicalalgorithmutilizedtosolvetheservicemappingproblem.Thislaststepinparticularprovidesaflexiblewaytomakepossibletheintegrationandtestingofdifferentmappingstrategies,thusprovidingasolidbasisforfutureworkimprovements,continuation of future research activities, research cooperation of the topic in futureinitiatives,etc.

1.2. StructureoftheDocument

Theremainderofthedocumentisstructuredasfollows:

• Section 2 presents the basis knowledge needed to frame the work on servicemapping. In particular, this section reviews T-NOVA use cases, requirements andarchitecturedesign,seeninthelightofservicemappingrequirements.Then,basedon the ETSI relevant documents in the field, this section proposes a unifyingmathematicalmodellingframeworkforservicemapping,asacommonbaseandinputtoallthemethodologiesdevised.Finally,asummaryoftheanalysisofthestateoftheartinservicemappingisreported.

• Section 3 presents the detailed discussion of three service mapping algorithmsproposedforT-NOVA,alongwithaschedulingalgorithm.

1 The reader should notice the distinction between the service mapping algorithms, which aremathematicalalgorithmsdesignedtosolvetheservicemappingproblem,asexplainedinSection3,andthe service mapping module, which is the module of the T-NOVA architecture hosting theimplementationofaservicemappingalgorithm(asexplainedinSection4).


©T-NOVAConsortium

8

• Section4dealswiththedesignoftheservicemappingmoduleanditsintegrationinTeNOR, theT-NOVAorchestrator.This sectiondetails the integration logicand thetechnologiesinvolved.

• Section5discussessimulationresultsforthedifferentmapping logicsdevised.Theaimof the simulations is to highlight theproperties of each algorithmand to testperformancesandscalabilityinextendedscenarios.

• InSection6theconclusionsfortheworkofthetaskaregiven.• The lists of references, acronyms and mathematical symbols are reported after

Section6.• The Annexes present a brief documentation of the developed service mapping

ApplicationProgrammingInterface(API)andthespecificationofthedatainterfaceswiththemainothermodulesoftheT-NOVAorchestrator.


©T-NOVAConsortium

9

2. PROBLEMDEFINITION

ThischapterprovidesthebasicinformationontheservicemappingproblemastackledintheT-NOVAproject,toproperlylaythefoundationforthediscussionofthedifferentalgorithmsconceivedintheproject,andtocorrectlyframethediscussiononservicemappingmoduledesignandintegrationintotheT-NOVAorchestrator,TeNOR.

Inthenextsection,theUseCases(UCs)andtherequirementsinvolvingservicemappingarerecalled from deliverable D2.1 “System Use Cases and Requirements” [1], to define theboundariesoftheservicemappingproblemasaddressedinT-NOVA.

2.1. UseCasesandRequirements

InthefollowingwebrieflysummarizetheT-NOVAusecases,describedanddiscussedinthedeliverableD2.1[1],thatarerelatedtotheservicemappingproblem.Therequirementsfortheservicemappingmoduleareidentifiedaswell.

2.1.1. Usecases

ServicemappingisacoretechnologyinTeNOR,enablingusecasesthathaveacentralroleintheaddressedbusinessframework,asdetailedinthenextfigure.

Figure1T-NOVAOverallUsecasediagram([1])


©T-NOVAConsortium

10

UsecasesanalyzedinD2.1[1]andrelatedtotheservicemappingarethefollowing:

1. UC2.1.Mapanddeployservice(seeD2.1[1],Section5.2.2.6).TheVNFsaremappedintoappropriate resources and then provisioned on the Network Functions Virtualization(NFV)infrastructure.Theusecasemaybeexecutedintwodifferentmanners:eitheruponanewservicerequestbythecustomer(UC2),orasaresultofaservicereconfigurationorrescaling(UC3).

2. UC3. Reconfigure/RescaleNFV services (seeD2.1 [1], Section 5.2.2.7).This use case is

focused on the adaptation of the resources allocated to a specific service, optimizingresource usage, and/or modification of configuration parameters. Two variants areconsidered,asdescribedbelow.

a) UC3.1scale-out/scale-inVNFService• Scale-outoftheNFVserviceresultsinadditionalVNFinstancesbeingaddedtoan

existinginstance.ThenewVNFinstancesrequiretheinstantiationofnewVirtualMachines(VMs)withcompute,network,and/orstoragecapacitytohostthenewVNFs.

• Scale-inremovesVNFinstances(andtheirhostVMs)thatarenolongerrequired.Thisactionreleasescompute,networkandstorageresources.

b) UC3.3 Reconfigure VNF Service: the configuration/parameters of the service areadjusted.

3. UC6.TerminateNFVservices(seeD2.1[1],Section5.2.2.11).Thisusecasedefinesthe

proceduresrelatedtotheterminationofaprovisionedNFVservice,eitherbythecustomerortheServiceProvider(SP),andremovalofaVNFfromthecatalogueofavailableandadvertisedservices.

Service mapping is thus envisaged in TeNOR as a key building block in order to supportoptimizeddeployingofnetworkservicesandreconfigurationofthesameincasebreachesoftheservicelevelsaredetectedbythemonitoringfunctionalities.

2.1.2. Requirements

The analysis of the service mapping problem and the design of the proposed solutionsreported in this deliverable have moved from the related key functional requirementsidentified in deliverable D2.1 [1]. Such requirements are summarized in the followingparagraph,takenbythementioneddeliverable:

NFVservicemapping.TheT-NOVAsystemshouldbeabletomapNFVservicerequestsreceivedfromcustomerstothenetwork,suchthatallNFVservicerequirementsaremet. Specifically, this requires the mapping of virtual network topology to thesubstratenetwork,whilesatisfyinganybandwidthand/ordelayrequirements,aswellas the assignment of NFVs to substrate nodes that have sufficient computing andstorage resources for packet processing, forwarding and/or caching. In turn, NFVservice mapping entails requirements such as the substrate network topology,processing,storageandnetworkresourceavailabilityacrossthenetwork,aswellasthecomputational requirementsof theNFVsthatshouldbedeployed. NFVservicemapping should be optimised based on one or multiple objectives, such as theminimisationofthemappingcost,themaximisationoftheprovider’srevenueorthemaximisationofNFVservicerequestacceptancerate.


©T-NOVAConsortium

11

ThetextinItalicmarksparticularlyrelevantaspectstobetakenintoaccountwhendesigninganddevelopingaservicemappingalgorithm.Inparticular:

1. Aflexibleandconsistentmathematicalmodellingoftheservicemappingproblem,tobeable to correctly capture the process ofmapping the network service to the networkinfrastructure resources, taking into account user requirements andservice/infrastructureconstraints.ThisaspectisaddressedindetailsinSection2ofthisreport.

2. Theneedoffeedingthemappingmodulewithinformationonboththecurrentstatusofthenetworkandthedetailedrequirementsoftheservicetobemapped.ThisaspectisaddressedinSection4,whichdetailstheinterfacesoftheservicemappingmodulewiththeinfrastructurerepositoryandtheservicecatalogue,designedandimplementedwiththepurposeofretrievingtheabovedata.

3. The fact that the developed mapping strategies have to take into account multipleobjectives stemming from service users, providers, infrastructure operators, etc. (e.g.maximizationofserviceperformances,minimizationofmappingcosts,maximizationofmappingacceptancerates,etc.).ThisaspectisaddressedindetailsinSection3,wheretheproposedT-NOVAmappingstrategiesarereportedandexplained,andinSection5,wheresimulationresultsarediscussed,highlightinghowthemulti-objectivesareaccountedforandachieved.

TheT-NOVAatomicrequirementsaddressedbytheservicemappingmodulearereportedinthefollowingtable,forthesakeofcompleteness.Foreachrelevantrequirement,itsrelationtotheservicemappingtaskisexplainedinthelastcolumn.ThetableistakenandadaptedfromtheannexofdeliverableD2.1[1].

Table1T-NOVArequirementsrelevanttoservicemapping.

Req.id

UseCase

Req.Nam

e

RequirementDescription JustificationofRequirement RelationtoServicemapping

T_NOVA

_04

UC1

,UC2

,UC3

NSCo

mpo

sition TheT-NOVAsystemSHALLbe

abletocomposeaNSfromatomicVNFinstancesavailableattheNFStoreanddefinethelogicaltopologyamongtheseveralcomponents.

ThecreationofaNSfromthecombinationofatomic/simpleVNFisimportantinordertosimplifytheprocessprovisionofNStothecustomersandavoidcomplexpathcalculations

TheinformationregardingtheNScompositionprocessoutcome(i.e.NStopologyandrequirements)isacquiredbytheservicemappingmoduleeachtimeaNSmappingrequestisdone.ThatisdoneinordertoensuretheservicemappingsolutionmeetsalltheNSprovisioningrequirements.

T_NOVA

_08

UC1

.1,U

C2

ResourceM

apping TheT-NOVAsystemSHALLbe

abletomapanincomingcustomerserviceselection(service+ServiceLevelAgreement-SLA)tospecificcomputational,storage,networkinfrastructureresourcesbasedonspecificoptimisationcriteriaorconstraints.

InfrastructureresourcesusedtohostaspecificVNFserviceandSLArestrictionsneedtobeselectedfromapoolofinfrastructureresources;thisselectionmustcomplywithapplicableoptimizationcriteriaorconstraints

Thisisthekeyrequirementaddressedbyservicemapping.


©T-NOVAConsortium

12

T_NOVA

_20

UC2

,UC3

,UC4

Resource

mon

itorin

g TheT-NOVAsystemSHALLbeabletomonitorandcollectinformationaboutconsumptionandavailabilityofresources(computational,storage,network)onarealtimebasis,includingtheresourcesconsumedbyeachspecificVNFinstance.

MonitoringisessentialtoensurethatthedeploymentofVNF’sontohostinginfrastructureisperformedadequately.Monitoringprovidesessentialmetricsrequiredbyoperationssuchasrescaling,billing,etc.

Monitoringinformationisaninputtoservicemappingmodule,whichprovidesmappingsolutionsalignedandoptimisedaccordingtoresources’availability.

T_NOVA

_21

UC2

VNFcreatio

n TheT-NOVAsystemSHALLbeabletoautomatetheinstantiationofVNFsontheinfrastructurebasedoncustomerrequestsandconstraints.

AutomationofVNFlifecycleisanessentialcharacteristicoftheT-NOVAsystem

Thesystemsfulfillingtheserequirementsaretheactuatorsoftheservicemappingdecisions.

T_NOVA

_26

UC2

Topo

logyof

VNF

compo

nents TheT-NOVAsystemSHALLdefine

thelogicaltopologybetweentheseveralVNFcomponents.

ConnectivitybetweenVNFcomponentsmustbeautomated

ThelogicaltopologybetweentheseveralVNFcomponentsofaNSisaninputtotheservicemappingalgorithm.

T_NOVA

_30

UC3

,UC4

,UC4

.1

SLAmon

itorin

g TheT-NOVAsystemSHALLbeabletocompareservicemetricswithSLArequirementsandindicateSLAstatus(conformance/breach).WhentheT-NOVAsystemdeterminesthatanSLAisinbreachitSHALLinitiatetheapplicableaction,e.g.rescaling.

SLAmanagementandmonitoringisconsideredessentialforthecommercialapplicabilityoftheT-NOVAsystem.TheT-NOVAsystemmustdeterminewhenanSLAisinbreachandtriggercorrectiveactions.

ServicemappingisoneofthepossibletoolsthatTeNORcanusetoreacttoSLAbreaches.

Inaddition to theabove requirements, also theatomic requirementson scaling/migration(T_NOVA_36-T_NOVA_45inD2.1[1])arerelatedtoservicemapping,inthesensethatservicemappingisoneofthetoolsthatTeNORcouldusetodealwithscaling/migration.


©T-NOVAConsortium

13

2.2. ReferenceScenarioandArchitecture

This section presents the service mapping module in the context of the T-NOVA systemarchitecture, explaining which are the relevant modules of the T-NOVA system providinginputstotheservicemappingmodule,andwhicharetheonesresponsibleforenforcingitsdecisions.

TeNORservicemappingmodulecouldbecalledintwodifferentoccasions:

• Whenanewinstanceofanetworkserviceisrequested:thiskindofrequestcomesfrom themarketplace, and it happenswhen a customerwants to buy a networkservice.

• When the SLA enforcement module predicts a SLA breach and notifies the NSmanagementmodule,whichrequestsanewmappingfortheresourcesthattheNSinstanceisconsuming.

For the servicemappingmodule, these two scenarios involve the same kind ofworkflow,whichisthefocusofthisdeliverable.

2.2.1. ArchitectureandFlows

TheplaceoftheservicemappingmodulewithintheTeNORarchitectureisshowninFigure2below.

ServiceMapping

NSManager

ServiceCatalogue

NewNSinstancerequest

NSProvisioning

Scaling/Migrationrequest

SLAEnforcement

1b

1a

2

3a

4 5

InfrastructureRepository

3b

Figure2TheservicemappingmoduleintheTeNORarchitecture

Thefigureshowstheeventsandflowsinvolvedinthecallstotheservicemappingmodule:

1. Asdescribedabove,therearetwokindsofreasonsacalltotheservicemappingcanbemade:becauseanewNSinstance(1a)orbecauseascaling/migrationofanexistinginstanceinordertokeeptheagreedSLA(1b)isneeded.

2. Therequestforanewmappingispassedtotheservicemappingmodule.


©T-NOVAConsortium

14

3. Theservicemappingmodulegrabsfromtheinfrastructurerepositorythemostup-to-datedataabouttheinfrastructure(step3a).Inaddition,theservicemappingmodulegrabs from the service catalogue (T-NOVA Network Service Descriptor (NSD)) therelevantinformationabouttheservicetobemapped(step3b),suchasthresholdsforthetechnicalSLAmetrics,and/ornodeandlinkrequirements,asexplainedinthenextSection2.3.

4. Afterthemappingoptimization,theservicemappingmodulereturnsthelistofPointsofPresence(PoPs)wheretheresourcescanbelocated.

5. Finally, theNSManagerpasses these locations to theNSProvisioning, in order toimplementthedecisionstakenbytheservicemappingmodule.

Theobjectiveofthisdeliverable istospecify indetail theworkflowthathasbeenoutlinedabove.

ThetwokeymodulesoftheT-NOVAsystemsupportingtheservicemappingmodulearetheinfrastructure repository and the service catalogue; they are briefly introduced in thefollowingparagraphs,whilefulldetailsaregiveninSection4.2.

The infrastructure repository subsystem provides the service mapping module with theinfrastructure related information, gathered from the Virtualized Infrastructure Manager(VIM)andNetworkFunctionVirtualizedInfrastructure(NFVI)components,asshowninFigure3.Also,aresourcediscoverymechanismallowsthesubsystemtoaugmenttheinformationprovidedbycloudandSDNenvironments.

Figure3Resourcerepositoryhighlevelarchitecture.

TheinfrastructurerepositorycomponentthatinterfacestheservicemappingmoduleistheAPIMiddlewareLayer.ItisalayerthatprovidesacommonsetofRESTAPIcallsthatcanbeused by the TeNORmodules to request and retrieve information from the infrastructurerepository. It is through the API Middleware layer that the service mapping module canretrieve the infrastructure repository informationandbuild a consistent representationofcurrentstatusoftheinfrastructure,eitherintermofitstopologyorofthecurrentavailabilityofresources.ThatisdoneeachtimeaNSmappingrequestismade,insuchawaythatthesolution computed by the mapping algorithm is aligned with the current status of theinfrastructure,intermsofresources’availability.

The service catalogue, on the other hand, provides the service mapping module with aconsistent representation of the network services requirements and with the main


©T-NOVAConsortium

15

characteristics. In fact, a feasible solution of the service mapping problem must respectnetworkservicenodeand linkrequirements,alongwiththeexpectedserviceperformancedefined in the SLA, as agreed between the service provider and the customer in themarketplaceandincludedinthenetworkservicedescriptor.ESTI’sNSDformat(seee.g.[2])hasbeenextendedbytheT-NOVAprojecttoincludeadditionalfieldstodefinethethresholdsfor service performance metrics, based on the expected performance of the differentdeploymentflavoursoftheVNFsthatarepartoftheservice.ForeachVNFdeploymentflavourtheVNFdeveloper indicatestheVirtualizationDeploymentUnit(VDU)requirementswhichare included in the VNFD. Therefore, by means of the NSD and of the VNFD the servicemappingalgorithmgetstheresourcerequirementsneededtodeploytheserviceinordertomeettheagreedSLA.AdditionaldetailsonthedescriptorparametersrelevanttotheservicemappingproblemarediscussedinSection4.2.2.

Thesequencediagrambelowsummarisestheinteractionoftheservicemappingmodulewiththeservicemanager,theinfrastructurerepositoryandtheservicecatalogue.

Figure4Interactionoftheservicemappingmodulewiththeinfrastructurerepositoryandthe

networkservicecatalogue

Fromthatpictureitcanbealreadyseenthatthemappingmoduleisdividedintotwomainsub-components:

1. Amoduleresponsibleforprovidinginterfacinganddataadaptingfunctionalities;itretrievesandorganises(inthetwoJSONfilesspecifiedinthefigure)thedatafromthemappingcall,theinfrastructurerepositoryandtheservicecatalogue.

2. The actualmodule responsible for themapping problem solving, which receives,fromthetwoJSONfiles,alltheinputsneededtobuildthemappingproblemitself.

MoredetailsontheintegrationofthemappingmoduleintotheT-NOVAarchitecturecanbefoundinSection4.

ThenextsectionpresentsamodellingframeworkfortheservicemappingproblemtackledinT-NOVA.The sectionsarebasedon thepreliminaryoutputsof the taskas reported in theinterimdeliverableD3.01[3].

ServiceManager

Micro-Service

InfrastructureRepository

NS/VNFCatalogues

ServiceMappingMicro-service

CoreSolverCoreSolverSM

Algorithm

MappingReq.(NS_ID)Req.NIdata

Req.NS/VNFdataResp.

Resp.

Build InputFiles toSMalgorithm(NS.jsonNI.json)

CallSMAlgorithm

Execute SMAlgorithmResp.SM

SolutionResp (json, {VNFi-PoPi}i)


©T-NOVAConsortium

16

2.3. ProblemModelling

TheServicemapping(SM)problemaddressedinT-NOVAfocusesontheoptimalassignmentof Network Service (NS) chains to servers hosted in interconnected datacenters (DCs)operatedbythesamenetworkserviceprovider.

Theoptimalityconceptcanbedefinedtowarddifferentobjectives:economicalprofit,QualityofService(QoS),energy-efficiencyandothers.

TheSMisanonlineproblem.Thatis,therequestsforNSsarenotknowninadvance.Instead,requests arrive to the system dynamically and, when accomplished, they can stay in thenetwork for an arbitrary amount of time. Algorithms for the SM problem have to handleservicerequestsastheyarrive.

According toETSI’sNFVArchitectural Framework [4], aNS is representedbya forwardinggraph inwhicheachvertex isaVirtualNetworkFunction(VNF).Hence, inT-NOVA,aNS isdefined as a directed graph 𝐺 𝑁𝑆 = (𝑉, 𝐴) in which each vertex, say ℎ, in the set 𝑉represents a VNF, and each arc, say (ℎ, 𝑘), in A represents a link connecting two VNFs,required for the correct implementation of the service (e.g. a chain in a web server tiercomposedbyfirewall,NATandloadbalancer).

TheNetworkInfrastructure(NI)onwhichwewanttoruntheNScanbedescribedasadirectedgraph𝐺(𝑁𝐼) = (𝑉., 𝐴.)inwhicheachvertex,sayp,inthe𝑉. setrepresentsaDC,andeacharc,say(𝑝, 𝑞),in𝐴. representsthenetworkconnectionestablishedbythenetworkprovideramongtheDCs.

Hence,thefirstproblemariseswhenanewNSinstancerequestarrivestotheorchestratorandtheSMisaskedtoassigneachVNFintherequiredservicetoaDCwithintheavailablenetwork infrastructure (note that it is possible that all the involved VNFs are eventuallyassignedtothesameDC).Moreformally,this“firstlevelproblem”canbestatedasfollows.

Firstlevelproblem:Givena𝑁𝑆anda𝑁𝐼,solvingthefirstlevelSMproblemrequirestoassigneachVNFoftheservice,toaDCinthenetwork(i.e.eachvertexinVtoavertexin𝑉.)andeacharc(h,k)inA,toanorientedpathinG(NI)fromtheDCtowhichthevertexhhasbeenassigned,totheDCtowhichthevertexkhasbeenassigned.

Figure5(a)reportsaNScomposedbytwoVNFs,aNIcomposedbyfourinterconnectedDCsandtheircorrespondinggraphs.

Figure5(b)reportsapossiblesolutionofthefirstlevelprobleminvolvingthegraphsofFigure5(a).VNF1hasbeenassignedtoDC1,VNF2hasbeenassignedtoDC4andthearcconnectingVNF1andVNF2hasbeenassignedtothebluepathfromDC1toDC4,throughDC3.


©T-NOVAConsortium

17

Figure5ExampleofafirstlevelSMproblem(a)anditssolution(b)

Moreover, each VNF can have a complex structure, i.e., it can be made of elementaryinterconnected components, each one executed on a VM. At the same time, each DC iscomposedbyhundreds(orthousands)ofinterconnectedservers.

Hence,onceaVNFhasbeenassignedtoaDC,asecondproblem(referredtoasa“secondlevelproblem”)ariseswiththerequesttoinstantiateeachVMcomposingtheVNFonaserverhostedintheDC.

Moreformally,eachVNFcanbedescribedasadirectedgraph𝐺(𝑉𝑁𝐹) = (𝑉2, 𝐴2)inwhicheachvertex,sayi,inthe𝑉2 setrepresentsaVirtualNetworkFunctionComponent(VNFc)[5],andeacharc,say(i,j),in𝐴2 representsalinkbetweentheVNFcomponents.

Inturn,eachDCcanbedescribedasadirectedgraph𝐺(𝐷𝐶) = (𝑉5, 𝐴5)inwhicheachvertexintheVDsetrepresentsahardwaredevice,eitheraserveroranetworkswitch,andeacharcinADrepresentsthenetworkconnectionestablishedbytheDCownerbetweenthehardwaredevices.

Figure6displays,ontheleftside,aVNFcomposedbyfourinterconnectedcomponents,and,ontherightside,theinternalstructureofaDCmodelwithitsinterconnecteddevices.

Figure6ExampleofaVNFcomposedbyfourVNFcs(ontheleft)andtheinternalstructureofaDCmodel(ontheright)

VNF1 VNF2G(NS)

?

DC2

DC1 DC4

DC3

G(NI)

DC2

DC1 DC4

DC3

G(NI)

VNF1 VNF2

(a) (b)

VNF1 VNF2G(NS)

DC2

DC1 DC4

DC3

G(NI)

VNc1

VNc2

VNc3

VNc4

G(DC)

G(VNF)

switch

server


©T-NOVAConsortium

18

Secondlevelproblem:GivenaVNFandaDC,solvingthesecondlevelSMproblemrequiresto assign each VNFc in the VNF to a server in the DC (i.e. each vertex in𝑉2 to a vertexrepresentingaserverin𝑉5)andeacharc(𝑖, 𝑗),in𝐴2,toanorientedpathinG(DC)fromthehardwaredevicehostingVNFcitothehardwaredevicehostingVNFcj.

Figure7ExampleofsecondlevelSMproblem(a)anditssolution(b)

Figure7(a)showsan instanceofthesecond levelproblem, inwhichtheVNF1componentsmustbeassignedtotheDC1servers.Figure7(b)showsasolutionofthesecondlevelproblem,whereeachcomponenthasbeenassignedtoa(suitable)serverandthelinksconnectingthecomponentshavebeenmappedtothebluepathsinvolvingswitchesandservers.

ThesecondlevelproblemisnotpartoftheservicemappingmoduleanditissolvedbycallingtheappropriateOpenStackfunctions(seediscussioninnextSection2.4.2).

Thecandidatehardwareforamapping,i.e.serversandlinkswithineachDCandlinksbetweencouple of DCs, have to be able to support the performance requirements of the virtualcomponents.ThismeansthatineachG(NS)directedgraphandineachG(NI)directedgraph,resource pools are associated to each vertex and to each arc. These resources must beavailable on servers that will host the involved virtual machines and in the links used toguaranteetheconnectivityrequiredbythenetworkservice(i.e.networklinkswithspecificcapacitiesandQoS).

Inparticular,afeasiblesolutionoftheservicemappingproblemmustrespectthefollowingthreerequirements.

NodeRequirements.Asetofnoderesourcetypes,say𝑁𝑇,isassociatedtothenodesofthe𝐺(𝑁𝑆)and𝐺(𝑁𝐼)graphs.Eachmemberofthe𝑁𝑇setrepresentsaparticularresource(e.g.CPUpowerneed,numberofcores,numberofhardwareandsoftwareaccelerators,numberofGPUs,etc.),whichcanberequiredbyaVNF,sinceitcouldberequiredbysomeofitsVNFc.Inturn,eachmemberofthe𝑁𝑇setcanbepresentinaDC,sinceitcouldbepresentinsome𝑅ℎ𝑡, isassociatedtoeachVNFnodeℎ,with𝑡∈𝑁𝑇. Itrepresentstheamountofaggregateresourceoftype𝑡requiredbytheVNFℎ.Anumericvalue,say𝑅𝐴;< ,isassociatedtoeachNI𝑁𝑇. It represents the amount of aggregate resource of type 𝑡 available in theDC𝑢. The

VNc1

VNc2

VNc3

VNc4

G(DC)

G(VNF1)

?

G(DC)VNc2

VNc1

VNc4VNc3

(a) (b)


©T-NOVAConsortium

19

aggregatevalues ineachnodearecomputedsummingupthevaluesof thecorrespondingresourcequantities,requiredoravailable,inthesinglecomponents,VNFcorservers,inthatnode.

ForeachDCnode𝑢andresourcetype𝑡,thesumoftheaggregatedresourceneedsofallVNFsmappedtoitcannotexceedtheaggregateavailableresource𝑅𝐴;< .

LinkRequirements.Asetoflinkresourcetypes,say𝐿𝑇,isassociatedtothelinksofthe𝐺(𝑁𝑆)and 𝐺(𝑁𝐼) graphs. Each member of the set 𝐿𝑇 represents a particular resource (e.g.bandwidth)whichcanberequiredbyanarc(ℎ, 𝑘)in𝐺(𝑁𝑆).Inturn,eachmemberofthe𝐿𝑇setcanbepresentinalinkoftheNI.Anumericalvalue,say𝑅𝑅?@< ,isassociatedtoeacharc𝐿𝑇.Itrepresentstheamountofresourceoftype𝑡requiredbythearc(ℎ, 𝑘).Anumericvalue,𝐴𝑝𝑞𝑡,isassociatedtoeacharc(𝑝,𝑞)in𝐺(𝑁𝐼),with𝑡∈𝐿𝑇.Itrepresentstheamountofresource𝐿𝑇,thesumofthe𝑅𝑅AB< valuesofNSarcsmappedtopathsincluding(𝑝, 𝑞)cannotexceed𝑅𝐴CD< .

Δπ, isassociated toeachpathπ in𝑃.Anactualdelayδ𝑝𝑞 isassociated toeacharc(𝑝,𝑞) inδ𝑝𝑞ofallthearcs(𝑝,𝑞)∈𝐴𝐼belongingthepathsusedforconnectingallthelinksbelongingtoΔπ.

Sincewe are facing an online problem, the amount of physical resources available at anyinstanceineachtimeisequaltotheamountoftheinfrastructurehardwaredevicesintheDCsminustheoneallocatedtotheVMscurrentlyrunningontheirserversinresponsetosatisfiedNSrequests.Onlywhenaserviceiscompletedtheresources(computationalandbandwidthdemands) allocated to it become newly available, and can be assigned, on the involveddevices,tootherincomingservicerequests.


©T-NOVAConsortium

20

2.4. ScientificandTechnologicalStateoftheArt

After the previous general introduction to the servicemapping problem, the proposed T-NOVA architecture and the modelling framework, this section presents a review of thescientific and technological state of the art in service mapping. Founding knowledge forframingtheservicemappingprobleminthecontextofnetworkfunctionvirtualizationcanbefound in the relevant ETSI documents specifying terminology and concepts, use cases,referencearchitecture,etc.(seee.g.[2],[4],[5],[6]).

2.4.1. ScientificStateoftheArt

NFV has received attention by the research community since a few years.With regard toservice mapping, the focus is on DC networks. Many works present cloud platformimplementations that allowNFs to be arbitrarily integrated into virtualmachineswithoutconsideringthefunctionalitiesofaservicechain.Moreindetails,Oktopus[7],CloudMirror[8]andSecondNet[9]assignvirtualclusterstoDCstakingintoaccountperformanceguarantees.Otherworks,suchasSTRATOS[10],discussesservicecompositionconsideringdifferentNFs.However,thoseworksaremainlybasedonheuristicalgorithmsthatseektominimizeinter-rack traffic within DC networks. In a similar vein, [11] discusses a heuristic second levelmappingalgorithmforassigningVMstoserversinadatacentre.ThepaperaddressesthecaseofNSscomposedbymultipleVNFs,pointingoutthatthetypicalcaseaddressedinliteratureregards instead themappingof singlenetwork functions. Interestingly thepaperdiscusseshowautomatedsecondlevelmappingprocedurescouldbebuiltontopoftheexistingcloudmanagement systems,with particular regard to theOpenStack case (this aspect is brieflyaddressedinthenextsection,whichdetailstheOpenStackmechanismsforassigningVMstothecomputenodes).

Otherearlyworks,suchas[8],aredevotedtodevelopNSmodellingtechniquesforsolvingthe inefficienciesofpreviouslyadoptedmodels,suchashose,VOC(VirtualOversubscribedCluster)andpipemodels[8].Thetechnique,calledTAG(TenantApplicationGraph),allowstoaccurately capture bandwidth requirements for the VMs to be deployed, avoiding theoverprovisioning inefficiencies that the other mentioned models do allow. The TAG isessentiallyagraphbasedmodelinwhichVMs,ortiersofVMs,arerepresentedbynodes,andingressandegressbandwidthrequirementsamongVMsaremodelledbydirectededges,orself-loops,formodellingintra-tierbandwidthrequirements.TheNSmodelsreportedinthisdeliverableareanextensionoftheTAGmodel.Inthesamework,alsoasecondlevelmappingstrategybasedonmin-cutandknapsackalgorithmisoutlined,withsupportingsimulationsshowing the effectiveness of the algorithm in avoiding overprovisioning of resources.Basically,thelogicofthealgorithmistomaximiseco-locationofVMslinkedby"heavy"edges,intermsoflinkbandwidthrequirements.

ThedeploymentofNFsovermultipleDCs,i.e.,themappingofNFservicechainsoverinter-DCnetworksfinallyenablesthewide-areadeploymentofnetworkservices.SuchservicechainmappingisoftencomparedtotheVirtualNetwork(VN)embeddingproblem,whichhasbeenstudied extensively. Fischer et al. [12] provide a survey on VN embedding accordingly.However,therichvarietyofproposedVNembeddingalgorithms(w.r.t.,resourcemapping)cannotbedirectlyappliedtoservicechainsduetothedifferentNFtypes,policiesincurredbythemiddleboxoperators, and the changing traffic rates causedby someNFs. In any case,thoseworkscaninspirefurtherapproachesrelatedtoservicechainembedding.

OtherapproachesexistalsofortheservicechainmappingovermultipleDCsandproviders.Huangetal.[13]proposeadistributedalgorithmfornetworkserviceplacementassumingthe


©T-NOVAConsortium

21

abilitytodeployNFs inthedatapath.MIDAS[14]employsaheuristicalgorithmfororder-preservingNFassignmenttomiddleboxesdeployedalongthedatapath.

The recent contribution by Riggio et al. [15] introduces an algorithm formapping ServiceFunctionChain(SFC)requeststoavirtualisednetworkinfrastructure,focusingonthecaseofWLANs. The paper proposes a general NS (i.e. SFC) and virtualised network modellingframework,stillatanearlystage,relyingonagraphformalismcompliantwiththeETSINFVmodel.Boththesub-problemsofVNFmappingtotheunderlyingnetworknodesandofVNFvirtuallinkmappingtonetworkpathsarehereaddressed.Theproposedmappingstrategyisagreedyone,inthesensethatitsequentiallyvisitstheVNFstobemapped,startingfromtheonewithmaximumconnectivitydegree.EachvisitedVNFismappedtothenetworknodeswhichoptimiseacostmetric.Thecostmetricaccountsfortheresidualcapacitylevelofthenetworknode,andforthecapacitylevelofthepathsconnectingthenetworknodewiththenetworknodeshostingthepreviouslymappedVNFsoftheservice.Thevirtuallinktonetworkpathmappingisdecidedbasedonshortestpathcomputation.Resultsarepresentedrelyingonperformancemetricswidelyusedintherelevantliterature,suchasSFCacceptanceratesandnodes/linksutilizationlevels.

Anotherinterestingandadvancedcontributioncanbefoundin[16],whereauthorsproposea service mapping algorithm based on integer linear programming. The services and theinfrastructurearemodelledasundirectedgraphs,withspecificationoftopologyandnode/linkavailabilities and requirements. One of the interesting features of that paper is theinvestigationofthesocalled“lookahead”property(previouslyintroducedbythereferencesmentioned in [16]),according towhichmorenetworkservicesareembeddedat thesametime. Authors show that the solution efficiency increases as the number of servicessimultaneously mapped increases (i.e. network resources are better exploited and moreservice requests canbeaccommodated, even if it is shown that increasing thenumberofsimultaneouslymappedservicesincreasesthemappingtime).

Authorsof[17],[18]2analyseinsteadthecaseinwhichanetworkservicechainconsistingofseveralnetworkfunctionscanberealizedinmultipleways(theprocessofchoosingtheactualimplementation “shape” for the requested service chain being referred to as “servicedecomposition”).Theauthorsthenproposeamappingalgorithmwhichintegratesaservicedecomposition phase, with the aim of optimally selecting, at runtime, the most suitableserviceconfigurationtoimplement.BothanILPandaheuristicmodelforsolvingtheproblemareproposed.

Reference [19] introduces a context-free language to build a model for formalizing thenetworkfunctionchainingrequests.Also,amixedintegerquadraticprogrammingnodeandlink mapping strategy is presented, with a Pareto evaluation of three different objectivefunctions: (i) maximization of remaining data rate on underlying network links, (ii)minimizationofthenumberofusednodesand(iii)minimizationoflatenciesalongthepaths.

Also soft computing optimization techniques have been proposed for solving the servicemappingproblem.Aninterestingexampleinthissenseisgivenintheearlywork[20],whereamappingapproachrelyingonbinaryPSO(ParticleSwarmOptimization) isproposed.Fivedifferent target functions for governing the mapping behaviour are here proposed(minimizationofnetworknodesused,minimizationofnetworklinkused,minimizationofthecostofusedlinks,andothersnotrelevanttothisdiscussion).Virtuallinkmappingisperformedvia shortest path computation, with the cost given by the free link resources. Other softcomputing,approximate,evolutionaryoptimizationtechniques(suchassimulatedannealing,

2WorkssupportedbytheUNIFYproject,7thFrameworkProgrammeforResearchandTechnologicalDevelopment,GrantAgreementNo.619609,www.fp7-unify.eu.


©T-NOVAConsortium

22

genetic algorithms, etc.) have been applied as well. The interested reader is referred toreferencesin[20].

Amongtherecentworksrelatedtoservicemapping,reference[21]3,proposesamodularNFVarchitecture that permits policy-based management of VNFs, introducing as well aninformationmodeldescribingandabstractingnetworkresourcesandnetworkfunctions.Thispaper is interesting because it investigates the synergies between Network FunctionsVirtualization (NFV) architectures and Software-Defined Networks (SDN). To prove theconcept, a simple virtual link mapping algorithm based on shortest path computation isproposedandthepolicybasedframework fororchestratingVNFs is tested inasmall-scaletestbed. It is shown how the proposed rule-based framework allows to dynamicallyorchestratetheVNFsandtheunderlyinginfrastructure,insuchawayastoensuretheSLAsdefinedforthedifferentclienttiersaresatisfied.

Concluding,researchonservicemappingalgorithmiscontinuouslyevolving,withmanynovelcontributions being proposed. The interested reader may find additional discussion ofconsolidatedstateoftheartinservicemappingin[12],[22],[23].

Finally,theoutputofthecurrenteffortsofT-NOVAconsortiuminthefieldofservicemappingresearchcanbefoundinthefollowingpapers:[14],[24](integerlinearprogrammingservicemapping for multi domain service mapping with limited information disclosure); [25](schedulingproblem);[26](earlyresultsonservicemappingviareinforcementlearning);[27](description of the T-NOVA servicemappingmodule and its integration with the T-NOVAorchestrator).

2.4.2. TechnologicalStateoftheArt

ThissectionpresentsdetailsontheOpenStackfilteringandweightingprocedure,whichisthetechnology aimed to decide on which hosts the VM should be instantiated. This is atechnologicalsolutiontowhathasbeencalledinSection2.3thesecondlevelservicemappingproblem,whichisnamelytheproblemofdecidingwhichmachinesintheDCshouldhostthemappedservices.InSection3.3.4,analgorithmproposedbyT-NOVAforsecondlevelmappingispresented.

2.4.2.1. OpenStackFilteringandWeighting

WhenschedulingaVMinanOpenStackenvironmentthe“compute”serviceusesthenova-schedulertodeterminewheretoinstantiatetheVM.WhenresourcingVMinstances,thenovafilterschedulerfiltersandweightseachhostinthelistofacceptablehosts.Thefirststepistheapplicationoffilterstodeterminewhichhostsareeligibleforconsiderationwhendispatchingaresource,asshowninFigure8.Filtersarebinary:eitherahostisacceptedbythefilter,oritisrejected.

ThecurrentavailablefiltersinOpenStackareasfollows:

• AggregateCoreFilter• AggregateDiskFilter• AggregateImagePropertiesIsolation• AggregateInstanceExtraSpecsFilter• AggregateIoOpsFilter• AggregateMultiTenancyIsolation

• GroupAffinityFilter• GroupAntiAffinityFilter• ImagePropertiesFilter• IsolatedHostsFilter• IoOpsFilter• JsonFilter

3WorksupportedbytheGN3plusproject,7thFrameworkProgrammeforResearchandTechnologicalDevelopment,GrantAgreementNo.605243.


©T-NOVAConsortium

23

• AggregateNumInstancesFilter• AggregateRamFilter• AggregateTypeAffinityFilter• AllHostsFilter• AvailabilityZoneFilter• ComputeCapabilitiesFilter• ComputeFilter• CoreFilter• NUMATopologyFilter• DifferentHostFilter• DiskFilter

• MetricsFilter• NumInstancesFilter• PciPassthroughFilter• RamFilter• RetryFilter• SameHostFilter• ServerGroupAffinityFilter• ServerGroupAntiAffinityFilter• SimpleCIDRAffinityFilter• TrustedFilter• TypeAffinityFilter

Figure8OpenStackFilterschedulerapproach(pictureelaboratedfrom[28])

Hoststhatareacceptedbythefilterarethenprocessedbyaweighingsteptodecidewhichhoststouseforthatrequest,asshowninFigure9.Allweightsarenormalizedbeforebeingsummedup;thehostwiththelargestweightisgiventhehighestpriority.

Host1

Host2

Host3

Host4

Host5

Host6

Host5

Host3

Host1

Host6

Filters

Hostschosenafterfilteringaresortedafterweighting

(herethebestvariantisHost5,theworst– Host6)

Host1

Host2

Host3

Host4

Host5

Host6

Weighting


©T-NOVAConsortium

24

Figure9Weightinghosts(pictureelaboratedfrom[28])

Host1

Host2

Host3

Host4

Host5

Host6

Cost CostCost

CostCost

Cost

Cost CostCost

Cost Cost

Cost CostCost

CostCost

CostCost

Cost

Weight 1=12

Weight 2 =87

Weight 3 =23

Weight 4 =10

Weight 5 =56

Weight 6 =40

Host4

Host1

Host3

Host6

Host5

Host2

Hosts fromthepoolofhosts

Costs ofthehosts capabilitiesrelativetotherequest specifications

Weights –sums ofcosts

Sortedlistofhosts


©T-NOVAConsortium

25

3. T-NOVASERVICEMAPPINGALGORITHMS

This section presents the mathematical details of the four service mapping approachesproposedinT-NOVA.

The first proposed approach is based on Integer Linear Programming (ILP) and aims tooptimizeNS to PoPmappings, having as objective theminimization ofmapping costs andservicedelay in respectof infrastructureandservices’ constraints.This ILPapproach takesdecisionsbasedonthecurrentstateofthenetwork(asprovidedbythenetworkmonitoring)andontheNSrequirementsandspecifications(asgatheredfromtheNScatalogue).

Thesecondproposedapproachisastochasticone(whilethepreviousoneisdeterministic)and is based on the reinforcement learning theory. The approach aims at exploring thepossibility of improvingmappingdecisions basedon iterative learningof the environmentdynamics(VNFtypes,arrivalandterminationrates,resources’capacity,etc.).

ThethirdapproachisalsobasedonILP,andinvestigatesbothafirstlevelmappingstrategyandasecondlevelone.Atfirstlevel,theapproachinvestigatesadifferenttargetfunctionwithrespecttotheone investigatedbythefirstproposedILPapproach,aimedatbalancingtheload across the network. In addition, a second level approach based on Mixed IntegerProgramming(MIP)isproposed,wheretheobjectiveistomaximisetheNSco-location,whileminimizingthetrafficwithintheDC.

Finally,thefourththeoreticalgorithmhereproposedaddressestheproblemofNSscheduling,anissuecomplementarytheofservicemapping(detailsareinSection3.4).

Toeasethereading,a tablereportingthe listandabriefexplanationof themathematicalsymbolscanbefoundinSection9.Also,eachsectionhasaseparatenumberingofequations.

3.1. AnIntegerLinearProgrammingbasedApproach

ThismappingstrategyhasbeenproposedbytheUniversityofMilan(Unimi).ItisbasedonanILPmodelforthefirstlevelproblem.TheaimofthefirstlevelproblemistoidentifyamappingofVNFstoDCsandlinkstopathswhichminimizetheoverallcost,whilesatisfyingconstraintsonresourceusageanddelay(eventuallycomingfromSLAsanddefinedintheNSDoftheNStobe instantiated).Theobjective functionof theoptimizationmodel isaweightedsumofthree components: (i) the cost of assigningVNFs toDCs, (ii) theoverall delay and (iii) theoveralllinkresourceusage,asderivedbyassigningthelinksamongVNFstopathamongDCs.Sincewearefacinganonlineproblem,thisobjectiveimplicitlymodelsthetrueoveralltargetfunction,i.e.themaximizationofthenumberofacceptedNSrequests.

Givena service request andanetwork infrastructure, for eachVNF, sayℎ, composing theservice,andforeachDC,say𝑝,composingthenetworkinfrastructure,weneedtodefineacost, say𝑐C?,which canmodel thecost of assigningℎ to𝑝 in termof themaximizationofacceptedrequests.Thesequantitiescanbeestimatedgatheringdatafromthequalityofthesolutionobtainedwhensolvingthesecond levelproblemthroughtheOpenStackAPIcalls.havebeentunedaccordingtotheresultsofanexperimentalcampaign(seeSection5.1).

InthisILPformulationweusethebinaryvariables𝑦C?toexpresstheassignmentofVNFℎtotheDC𝑝,whereasthebinaryvariables𝑥CD?@ indicatewhetherthelink(ℎ, 𝑘)ingraph𝐺 𝑁𝑆 =(𝑉, 𝐴)hasbeenmappedontoapathamongDCsingraph𝐺 𝑁𝐼 = (𝑉., 𝐴.)whichusesthelink(𝑝, 𝑞).

TheILPapproachforfirstlevelmappingcanbethereforeformalizedasfollows.


©T-NOVAConsortium

26

Problem(ILPbasedServicemapping)

Minimize

𝛼 𝑐C?𝑦C? + 𝛽 𝛿CD𝑥CD?@ + 𝛾 𝑅𝑅?@< 𝑥CD?@(?,@)∈O<∈PQ(C,D)∈OR(?,@)∈SS∈TC∈UR?∈U (1)

Subjectto

𝑦C? = 1∀ℎ ∈ 𝑉C∈UR (2)

𝑥CD?@ − 𝑥DC?@ =C∈URC∈UR 𝑦C? − 𝑦C@∀ ℎ, 𝑘 ∈ 𝐴, ∀𝑝 ∈ 𝑉. (3)

𝛿CD𝑥CD?@C,D ∈OR?,@ ∈S ≤ ∆S∀𝜋 ∈ 𝑃 (4)

𝑅𝑅?@< 𝑥CD?@?,@ ∈O ≤ 𝑅𝐴CD< ∀ 𝑝, 𝑞 ∈ 𝐴., ∀𝑡 ∈ 𝐿𝑇 (5)

𝑅𝑅?< 𝑦C??∈U ≤ 𝑅𝐴C< ∀𝑝 ∈ 𝑁., ∀𝑡 ∈ 𝑁𝑇 (6)

𝑦C? ∈ 0,1 ∀ℎ ∈ 𝑉, ∀𝑝 ∈ 𝑉. (7)

𝑥CD?@ ∈ 0,1 ∀(ℎ, 𝑘) ∈ 𝐴, ∀(𝑝, 𝑞) ∈ 𝐴. (8)

Theobjectivefunction(1)isaweightedsumofthreecomponents:thecostofassigningVNFstoDCs,theoveralldelayandtheoveralllinkresourcesusage.

Constraints(2)ensurethateachVNFℎ ismappedexactlytooneDC.Conditions(3)ensurethatforagivenpairofVNFsℎand𝑘assignedtoDCs𝑝and𝑞,respectively,thereisapathinthenetworkinfrastructuregraph𝐺(𝑁𝐼)connecting𝑝to𝑞towhichtheedge(ℎ, 𝑘)hasbeenmapped.Constraints(4)imposethesatisfiabilityofaSLAbasedonthedelaythresholdsforinthe𝑃set.Constraints(5)imposethelinkresourcelimitoftheinterDCconnectionsforeachlinkresourcetype𝑡 intheresourcetypeset𝐿𝑇.Constraints (6) imposethenoderesourcelimitoftheDCforeachnoderesourcetype𝑡intheresourcetypeset𝑁𝑇.Theconditions(7)and(8)expressthebinarydomainconstraintsforthevariablesused.

TheaboveILPmodelissolvedbyinvokingtheopensourceGLPKILPsolver.ThischoicehasbeentestedagainstthechoiceofthecommercialsolverCPLEX(seeSection5.1).


©T-NOVAConsortium

27

3.2. ReinforcementLearningBasedApproach

ThissectionpresentsaservicemappingstrategybasedonReinforcementLearning(RL)[29].WefirstfocusonastrategytomapsingleVNFsandthenprovideapossibleextensionofthemethodtothegeneralcaseofNSmapping.

ThismappingstrategyhasbeenproposedbytheConsortiumforResearchinAutomationandTelecommunication(CRAT).Earlyresultsoftheworkcanbefoundin[26].

3.2.1. VNFMappingviaReinforcementLearning

ThissectiondescribesareinforcementlearningstrategyaimedatmappingsingleVNFs.Earlyworkonthetopiccanbefoundinthepaper[26],towhichtheinterestedreaderisredirected.

3.2.1.1. ProblemModellingbasedonMarkovDecisionProcess

ReinforcementlearningmethodologyappliestocontrolproblemswhichcanbemodelledasaMarkovDecisionProcess(MDP)[30].

AMDP isadiscrete-timestochasticcontrolprocessdefinedby thequadruple{𝑆, 𝐴𝑐𝑡, 𝑇, 𝑟}where:

-𝑆isadiscreteandfinitestatespaceset.

-𝐴𝑐𝑡isadiscreteandfiniteactionspace.

-𝑇isthetransitionprobabilitymatrix,whichdescribesthesystemdynamics.

- 𝑟:𝑆×𝑆×𝐴𝑐𝑡 → 𝑅cd is the reward function, that describes the reward obtained in thetransitionfrom𝑠to𝑠′whenaction𝑎 ∈ 𝐴𝑐𝑡istaken.

The main MDP definitions rely on the Markovian (or memory-less) property and on thestationary distribution of the stochastic process. Under these assumptions, the transitionprobabilitiesarestationaryanddependonthecurrentstate-actionpair:thegenericelementofthematrix𝑇,denotedwith𝑡(𝑠, 𝑎, 𝑠′),describestheprobabilitythatthesystemtrajectorytransitsfromstate𝑠tostate𝑠′whenaction𝑎 ∈ 𝐴𝑐𝑡istaken.ApolicyΠisamappingofeachstate𝑠toanaction𝑎.Thestatevaluefunction𝑉i(𝑠)isdefinedastheexpectedrewardwhenthesystemisinstate𝑠andthesystemevolvesunderpolicyΠ.Similarly,thestate-actionvaluefunction𝑄i(𝑠, 𝑎)isdefinedastheexpectedrewardwhenthesystemisinstate𝑠,action𝑎ischosenandthesystemevolvesunderpolicyΠ.

Inthefollowing,theactualSMproblemismodelled, inordertoderive informationontheassociatedMDP{𝑆, 𝐴𝑐𝑡, 𝑇, 𝑟}.LetusdenotewithΤthetimehorizonoverwhichtheproblemis defined. Let |An| denote the number of PoPs in the network infrastructure and𝑃𝑜𝑃 ={1,2,3, . . . , |An|}thePoPs’IDs.

Recall that𝑅𝐴denotesthevectorofresourcesavailableatthedifferentPoPs.Thegenericcomponentof𝑅𝐴,called𝑅𝐴C,denotestheamountofthedifferentresourcesavailableatthePoP 𝑝. In turn, the component 𝑡 of 𝑅𝐴C, named𝑅𝐴C< ,denotestheamountofresourcesoftype𝑡 (e.g.memory,computation,storage,etc.)availableinthePoP𝑝(weconsideraunivocallyorderedsetofresourcetypes).

Asamatteroffact,resourcesaredifferentiatedbasedontheirnature:acloudprovidercanoffer,forexample,bothcomputationalandstorageresource,and,regardingstorage,eitheron ssd or on hdd disks; somemachinesmaymount a specific network card, some othermachinesmayhaveahigheruptime,andsoon.


©T-NOVAConsortium

28

On theotherhand,eachVNF is characterisedby the requirement vector𝑅𝑅?< , stating theamountofresourcesoftype𝑡requiredbytheVNFℎtobemapped.

StateSpaceDefinition

Intheearlywork[26]thestatespacehasbeenfirstdefinedas

𝑆 = {𝑠(𝑡) = 𝑠s,C(𝑡), 𝑡 ∈ Τ, 𝑣 ∈ 𝑉𝑁𝐹, 𝑝 ∈ 𝑃𝑜𝑃} (1)

where𝑠s,C(𝑡)denotesthenumberofVNFoftype𝑣deployedatPoP𝑝.ThestatespacethusgivesaviewoftheoccupancylevelofthePoPatthedifferenttimes.Aformulationconsideringsuch definition of the state space presents a scalability problem due to the state spaceexplosionobservedwhenthenumberofVNFtypesandPoPsincreases.Thus,thefollowingaggregatedformulationforthestatespaceisconsideredinthefollowingformula

𝑆 = {𝑠 ∈ 0,1 d, UR } (2)

inwhichthelengthofthegenericstatevectorisequaltothenumberofPoPsinthenetworkinfrastructure( 𝑉. ),andthegenerici-thcomponentofthestatevectorisequaltooneiftheaggregatedoccupancylevelofthei-thPoPisgreaterthanapredefinedthreshold.Byprovidingan aggregated view of the PoPs occupancy level, this state space formulation improvesscalabilitywithrespecttothepreviousone.ThecurrentstateofthesystemsisevaluatedbytheservicemappingmodulethroughtheAPImadeavailablebytheinfrastructurerepository,asdetailedinSection4.2.1.

ActionSet

TheactionsetregardsthedecisionaboutwhereVNFisdeployed,andisdefinedasfollows

𝐴 = {1,2, … , |𝐴5|} (3)

where𝑎 = 𝑖meansthattheVNFinquestionisdeployedonthei-thPoP.

TransitionMatrix

Weassumethattherequestsandtheterminationsofservicesarecharacterizedasfollows:for each service of type 𝑘, the new NS requests are distributed according to a Poissondistributionofmeanarrivalfrequency𝜆@andterminationsaccordingtoaPoissondistributionofmeanarrivalfrequency𝜇@.

In case the state space definition (1) is adopted, a state transition due to a new serviceinstantiationcanbemodelledas𝑠(𝑡 + 1) = 𝑠(𝑡) + 𝛿A,@ where𝛿A,B isavectorallzeroesbutthei*j-thcomponent,whichisequaltoone,meaningthatanewi-thVNFhasbeenallocatedinthej-thPoP.VNFterminationcanbemodeledsimilarly.

The transition probabilities among states can be modelled through a transition matrix𝑇(𝑠, 𝑎, 𝑠′),specifyingtheprobabilitythatperformingaction𝑎instate𝑠willleadtothenewstate𝑠′.Transitionprobabilitiesdependonthearrivalanddeparturerates.Incasethestatespacedefinition in(2) ischosen, it isnotpossibletoeasilyderiveastatetransitionmatrix,sinceanaggregatedstatedescriptionisadopted,sothatthereisnolongeragranularviewonthePoPoccupancylevel.However,thereinforcementlearningsolutionapproachproposedinthefollowingdoesnotrequireacompleteknowledgeoftheMDP,andofthetransitionmatrixinparticular(weadoptamodel-freeapproach).


©T-NOVAConsortium

29

RewardFunction

The reward matrix is chosen to reflect the service mapping goals. A possible choice inparticularisthefollowing

𝑟(𝑠, 𝑎, 𝑠′) = 𝑟, 𝑟 > 0𝑖𝑛𝑐𝑎𝑠𝑒𝑜𝑓𝑠𝑢𝑠𝑠𝑒𝑠𝑠𝑓𝑢𝑙𝑙𝑚𝑎𝑝𝑝𝑖𝑛𝑔0𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

(4)

wheredifferentchoicesfortherewardfactorrarepossible:

• Aconstantreward,leadingtomaximizationofrequests’acceptance.• A reward functiondependingon theVNF tobemappedand thePoP chosen. This

choicecanbeadoptedifminimisationofmappingcostsissought(whenthecostsformapping to the different PoPs are known), or as well maximization of mappingrevenue(whendifferentVNFsyieldstodifferentrevenues).

The following section briefly describes the solution strategy devised to derive an optimalmappingstrategy,thatis,astrategywhichmaximisestherevenuesinthelongterm.

3.2.1.2. MDPSolutionStrategy

TheobjectiveofthissectionistoderiveafeasiblesolutionstrategytoworkouttheoptimalpolicyfortheMDPdefinedinthesectionabove.Anoptimalpolicyistheoneoptimizingtheexpectedrewardinthelongrun.

Severalstrategiesareavailableinliteraturetofindtheoptimalpolicy(areviewofthemainonescanbefoundin[29]).Itisknownthat,incasefullinformationontheMDPareavailable,theoptimalpolicycanbecomputedbysolvingtheBellmanequationofdynamicprogramming[29]. Inour case,however, it isnot realistic toassumeperfectmodelon theMDP,and inparticularonthetransitionmatrix(sincethereisnotperfectknowledgeoftheNSrequestandterminationpatternsandthestatespacehasanaggregatedstructure).For this reason,RLapproaches for the optimal policy calculation are investigated next. RL are model freemethods,whichdonotassumecompleteknowledgeoftheenvironment(oftransitionmatrix𝑇inparticular).DifferentRLmethodsexist,ofwhichQ-learningwillbeinvestigatednext.Bothmethodsaimatestimating thepreviously introduced state-actionvalue function𝑄i(𝑠, 𝑎),definedastheexpectedvalueofthecumulativerewardobtainedwhentakingaction𝑎fromstate𝑠andthenfollowingpolicyΠ.

𝑄i(𝑠, 𝑎) = 𝐸S{ 𝑟�� |𝑠� = 𝑠, 𝑎� = 𝑎} (5)

where𝑟�, 𝑠�𝑎𝑛𝑑𝑎�arethereward,stateandactionattime𝜏.

Q-Learning

Q-Learning [29] iteratively estimates the best state-action value function through thefollowingupdaterule,executedeachtimeanactionistakenandtheeffect(i.e.reward)oftheactionisobserved.

𝑄(𝑠�, 𝑎�) ← 𝑄(𝑠�, 𝑎�) + 𝛼�[𝑟�� + 𝜆𝑚𝑎𝑥�𝑄(𝑠��, 𝑎) − 𝑄(𝑠�, 𝑎�)] (6)

Here𝜏isthetime,α�isthesocalledlearningrateand𝜆 ∈ [0,1]isadiscountfactorweightingcurrentrewardsversusfutureones.


©T-NOVAConsortium

30

BasedonthecurrentestimateofQ(𝑠�, 𝑎�),themappingactiontobetakenisdecidedastheonewhichmaximizesthecurrentstate-actionvaluefunction.

𝜋� 𝑠 = 𝑎𝑟𝑔𝑚𝑎𝑥�Q 𝑠�, 𝑎� (7)

TheabovedefinedupdateruleforQdefinesafeedbackruleinwhichα�isagainfactorand[𝑟�� + 𝜆𝑚𝑎𝑥�𝑄(𝑠��, 𝑎) − Q(𝑠�, 𝑎�)]istheerrorbetweenamixedobservedandestimatedstate action value (𝑟�� + 𝜆𝑚𝑎𝑥�𝑄(𝑠��, 𝑎)) and the previous estimate for Q(𝑠�, 𝑎�). Asimilarpolicythatguaranteesfasterstateexplorationandconvergenceofthealgorithmisthe𝜖 − 𝑔𝑟𝑒𝑒𝑑𝑦Q-Learningpolicy,inwhich,ateachmappingstep,action𝑎𝑟𝑔𝑚𝑎𝑥�Q(𝑠�, 𝑎�)istakenwithprobability1 − 𝜖,whilea randomaction is takenwithprobability𝜖. Theeffectobservedisthatoflettingthealgorithmescapefromlocalminima.𝜖iscommonlyreferredtoasexplorationparameter,sincethegreateritis,thefurtherwearefromthepureQ-Learningpolicy. Inpractice,𝜖canbechosen largeat thebeginningof theoperation, toexplorethepolicyspace,andthendecreasedwhenconvergencetotheoptimalpolicyisassessed.

Basedontheabove,theRLservicemappingproblemcanbethereforestatedasfollows.

Problem(ReinforcementLearningbasedServiceMapping)

Giventhecurrentstateofthesystems�andtheobservedreward𝑟�,actaccordingtotheQ-learning𝜖 − 𝑔𝑟𝑒𝑒𝑑𝑦policy

π� s = argmax�Q s�, a� withprob. 1 − ϵrand a withprob. ϵ (8)

andupdatethestateactionvaluefunctionaccordingto(6).

Theflowoftheproposedstrategyispresentedinthefigurebelow.

Figure10ReinforcementLearningworkflow.

ThepresentedalgorithmformappingVNFsisoutlinedinthefollowingtable,intheformofpseudocode.

Table2PseudocodefortheVNFmappingbasedonreinforcementlearning

Algorithm 1 Virtual Network Function Mapping Based on Reinforcement

Learning

1 Start

2 initialize state action value function Q

ENVIRONMENT

SERVICEMAPPINGMODULE

MAPPINGREWARD

CURRENTQESTIMATE

MAPPINGDECISION(BASEDONQANDCURRENTSTATE)

QUPDATE

STATEUPDATE


©T-NOVAConsortium

31

3 listen for incoming VNF activation/termination requests

4 receive incoming VNFs activation/termination request

5 retrieve VNF requirements

6 if VNF activation event

7 measure current state according to (2)

8 map the VNF based on Q-Learning policy (8)

9 check PoP feasibility

10 if feasible

11 positive reward

12 else

13 failure reward (e.g. zero or negative reward)

14 endif

15 update Q function based on (6)

16 else (i.e. VNF termination event)

17 compute state after VNF resources are released

18 reward=0


20 endif

3.2.2. NSMappingAlgorithm

TheabovesectionswereconcernedwithareinforcementlearningstrategyformappingVNFs.Thissectionproposesanextensionof thestrategytothecase inwhichthemappingofanentireNSissought(i.e.,aNScomposedbymoreVNFs).

TheprocedureformappingtheVNFsiskeptunchanged,butthefollowingtwoadditionalstepsareadded:

1. VNFlink–PoPpathmapping. Inthegeneralcase,aNSiscomposedbymoreVNFsrelated by topological constraints (expressed by the forwarding graph) and linkrequirements.InadditiontotheVNF-PoPmappingaction,itisthereforenecessarytoalsodecidehowlinksamongtheVNFsshouldbemappedonthepathsconnectingthePoPshostingthemappedVNFs.

2. Feasibilitycheckextendedtolinkrequirements.WhentheVNFlinkmappingproblemis considered as well, it is necessary to check that the actions decided by thereinforcement learning mapping engine do not lead to the violation of the linkresourcesrequirements(suchasavailablelinkbandwidth,maximumadmissibledelaybetweenmappedVNFs, etc.). Therefore, inaddition to thePoP capacity feasibilitycheck,thefeasibilitycheckonlinkrequirementsisadded.

TheresultingalgorithmforNSsmappingbasedonreinforcementlearningisoutlinedbelow,inpseudocodeformalism.

Table3PseudocodefortheNSmappingbasedonreinforcementlearning

Algorithm 2 Network Service Mapping Based on Reinforcement Learning

1 Start


©T-NOVAConsortium

32

2 initialize state action value function Q

3 listen for incoming events (NS activation or termination events)

4 receive incoming NS activation or termination event

5 retrieve NS data (number of VNFs, node/link requirements, etc.)

6 if NS activation event

7 measure current state according to (2)

8 for i=1 to number of VNFs composing the NS

9 map the VNF based on Q-Learning policy (8)

10 check PoP feasibility

11 map ingress and egress VNF links

12 check link feasibility

13 if feasible

14 positive reward

15 else

16 failure reward (e.g. zero or negative reward)

17 endif


19 endfor

20 else (i.e. NS termination event)

21 compute state after NS resources are released

22 reward=0


24 endif

TheabovestrategyhasadegreeoffreedominthechoiceoftheVNFlinkmappingstrategy(line 11). Driven by themapping goals of selecting feasible PoP paths leading tominimalmapping costs and balanced link resources’ consumption patterns, a shortest path linkmappingstrategyhasbeenselected,inwhichthecostmatrixoftheshortestpathproblemisgivenbyalinearcombinationofthematrixcarryingtheinformationonthelinkmappingcosts,andthematrixcarryinginformationonthelinkcongestionmetrics.Whilethecostmatrixcanbeassumed fixed, the “link congestionmatrix”has tobeupdated regularly, to reflect thecurrent congestion level of the infrastructure. This link mapping strategy is suited to theproblembecauseitreflectsthemappinggoalsanditisfast(theshortestpathproblemcanberesolvedwithfastalgorithmssuchasDijkstra).Thebalancebetweenthegoalofminimizinglinkmappingcostsandlinkbalancingcanbeadjustedbytuningthecoefficientsgoverningthelinearcombinationof thecostandthebalancingmatrices, similarly towhat isdone in theselection of the related terms in the objective functions of the proposed ILP mappingstrategies.


©T-NOVAConsortium

33

3.3. Multi-stageNetworkServiceEmbedding

This approach has been proposed by the GottfriedWilhelm Leibniz Universität Hannover(LUH).Previousworkcanbefoundin[31],[24].

3.3.1. Mainassumptions

ThisstrategyisbasedontheassumptionthattheNFproviders(DCoperators)advertisePoP-levelgraphwith linkcosts,andtheNFcost, i.e.,CPUcostattheDC,thatareexpressedasweightsinthealgorithmdescription.ThestrategyisbasedonanILPmodelapplicabletoanyDCtopologysuchasthetwo-levelhierarchicalfat-tree.

3.3.2. IterativeAlgorithm

Theproposedmappingalgorithmisbasedonthefollowingsteps.

1. Identifylocation-dependentVNFs(e.g.,proxies;resourcesshouldbeinproximityoftheclient’snetwork).

2. IdentifycandidateDCsforeachVNFintheservicechain.

3. IfthereisnoDCsatisfyingallVNFrequirementsandconstraints,partitiontheservicechainamongDCs:

• ILPmodelasshowninSection3.3.3below.• Different objectives can be considered, depending on the service and NF

providers’preference,likeforexample:o Minimizingtheclient’sexpenditure.o MaximizingloadbalancingacrosstheDCsbyconsidering(i.e.,minimisation

of)weightvaluesthatexpressNFServiceProviders’preferences.

4. Uponpartitioning,assigntheVNFstoserverswithintheselectedDCs(secondlevelmappingproblem):

• Formulationas(Integer)LinearProgramsimilartoexistingMulti-commodity-flowproblemformulations.o Objectives:Minimizeinter-racktrafficandthenumberofusedservers.

• Alternativesolution:Heuristicalgorithmthataimsatassigning theVNFs to thesmallestnumberofracksandservers,whileCPUloadandbandwidtharebalancedacrosstheracksandservers.

5. StitchtogethertheVNFservicechainsegments(mappedtodifferentDCs)withtheassignmentofvirtuallinksconnectingtheDCs:

• Objectives: To find the shortest path between a pair of DCs that offers therequiredamountofbandwidth.

• Multi-commodityflowproblemformulation.

3.3.3. ILPModelforServiceChainPartitioning

Next,wepresentourILPmodelforservicechainpartitioning.WeconsidereachlinkassociatedwithaweightvaluethatexpressestheutilizationoflinksandDCs.TheobjectivefunctionoftheILPaimsatminimizingthesumofusedweights𝑤CD whichessentiallyleadstonetworkloadbalancing,andtherewith,toincreasedresourcesefficiency.


©T-NOVAConsortium

34

IntheILPformulations,weusethebinaryvariable𝑦C?toexpresstheassignmentofVNFℎtoDC𝑝.Similarly,thebinaryvariable𝑥CD?@ indicateswhethertheVNFgraphedge ℎ, 𝑘 ∈ 𝐴hasbeenmappedontothePoP-levelgraphedge 𝑝, 𝑞 ∈ 𝐴. (samenotationisusedasforthefirstILPapproachinSection3.1).

TheservicechainrequestpartitioningILPisthereforedefinedasfollows.

Problem(ServicemappingbasedonServiceChainRequestPartitioning)

Minimize:

𝑤CDC,D ∈OR

𝑅𝑅?@< 𝑥CD?@?,@ ∈O

(1)

subjectto:

𝑦C? = 1∀ℎ ∈ 𝑉(2)C∈UR

𝑥CD?@ − 𝑥DC?@ = 𝑦C? − 𝑦C@ℎ ≠ 𝑘, ∀ ℎ, 𝑘 ∈ 𝐴, ∀𝑝 ∈D∈UR

𝑉. 3

𝑦C? ∈ 0,1 ∀ℎ ∈ 𝑉, ∀𝑝 ∈ 𝑉.(4)

𝑥CD?@ ∈ 0,1 ∀ ℎ, 𝑘 ∈ 𝐴, ∀ 𝑝, 𝑞 ∈ 𝐴.(5)

Hereby,webrieflydiscusstheILPconstraints.

Constraint(2)ensuresthateachVNFℎismappedexactlytooneDC𝑝.Condition(3)preservesthebindingbetweentheVNFandthelinkassignments.Moreprecisely,thisconditionensuresthatforagivenpairofassignednodes𝑖,𝑗 (i.e.,VNFsorend-points), there isapath inthenetwork graphwhere the edge (𝑖, 𝑗) has beenmapped. Finally, the conditions (4) and (5)expressthebinarydomainconstraintsforthevariables𝑦C?and𝑥CD?@ .Inaddition,wefixtheassignmentofeachend-pointℎintherequesttoitsrespectivelocation𝑝bysetting𝑦C? ← 1.

3.3.4. MIPModelforNF-subgraphMapping

TheMIPforVNF-subgraphmappingaimsatmaximizingNFco-locationwhileminimizingthetrafficwithintheDC.Inthisrespect,thebinaryvariable𝑦C?denotestheassignmentofVNFcℎtotheserver𝑝,whilethebinaryvariable𝑧Cindicateswhethertheserver𝑝hasbeenassignedtoanyVNFcs(i.e.,𝑧C = 0whenthereisnoVNFcassignedtoserver𝑝;otherwise𝑧C = 1).

Based on the multi-commodity flow problem formulation, we use the term commodity,definedas𝑚AB = {𝑖, 𝑗, 𝑅𝑅?@< } ,toexpressthebandwidthdemands𝑅𝑅?@< betweenapairofVNFcsℎ, 𝑘.Inthiscontext,theflowvariable𝑓CD?@ denotestheamountofflow(i.e.,bandwidthunits)overtheDClink(𝑝, 𝑞)fortheVNF-graphedge(ℎ, 𝑘).TheVNF-subgraphmappingMIPisthereforeformulatedasfollows.


©T-NOVAConsortium

35

Problem(VNF-subgraphServicemapping)

Minimize:

𝑧CC∈UR

+ 1𝑅𝑅?@<?,@∈O¦

𝑓CD?@

?,@ ∈O¦C,D ∈ORC§D

6

subjectto:

𝑦C? = 1∀ℎ ∈ 𝑉2

C∈UR

7

𝑓CD?@ − 𝑓DC?@ = 𝑅𝑅?@< 𝑦C? − 𝑦C@ ℎ ≠ 𝑘, ∀ ℎ, 𝑘 ∈ 𝐴2, ∀𝑝 ∈D∈URC§D

𝑉. 8

𝑅𝑅?< 𝑦C? ≤ 𝑅𝐴C< 𝑧C?∈U¦

∀𝑝 ∈ 𝑉. 9

𝑓CD?@ ≤ 𝑅𝐴CD< ?,@ ∈O¦

∀𝑝, 𝑞 ∈ 𝑉. 10

𝑦C?, 𝑧C ∈ 0,1 ∀ℎ ∈ 𝑉2, ∀𝑝 ∈ 𝑉. 11

𝑓CD?@ ≥ 0∀ ℎ, 𝑘 ∈ 𝐴2, ∀ 𝑝, 𝑞 ∈ 𝐴. 12

Theobjectivefunction(6)consistsoftwoterms,i.e.,thenumberofassignedserversandtheaccumulatedflowdividedbythetotalbandwidthdemand.Essentially,thesecondtermyields1 if all NF-graph edges ℎ, 𝑘 ∈ 𝐴2 are mapped onto single-hop links 𝑝, 𝑞 ∈ 𝐴.. Thenormalizationofthesecondtermprovidesabalanceagainstthefirsttermintheobjectivefunction.

WefurtherdiscusstheconstraintsoftheMIPmodel.Condition(7)ensuresthateachVNFcℎismappedexactlytooneserver𝑝.Constraint(8)enforcesflowconservation,i.e.,thesumofall inboundandoutboundtraffic inswitchesandserversthatdonothostVNFcsshouldbezero.Constraints(9)and(10)ensurethattheallocatedcomputingandbandwidthresourcesdonotexceedtheresidualcapacitiesofserversandlinks,respectively.

Finally, condition (11)expresses thebinarydomainconstraint for thevariables𝑦C? and 𝑧Cwhileconstraint(12)ensuresthattheflows𝑓[email protected]𝑉2 representsthevirtualgatewaywhichwebindtothephysicalgatewayGWbysetting𝑓«¬

U¦(�) ← 1.


©T-NOVAConsortium

36

3.4. VNFSchedulingoveranNFVInfrastructure

As described in previous sections, ETSI NFV defines NSs as entities composed of virtualnetwork functions, which are the actual components performing the specific operations.Typically,networktrafficassociatedtoagivenNSgoesthroughseveralnetworkfunctions.Asauthors state in the previously citedwork [19], thatmeans a set of network functions isspecified and the flows traverse these functions in a specific order so that the requiredfunctionsareapplied.Thisimpliesprecedencerequirementsbetweenfunctionsinthesameservice,whichisknownastheformalizationofthefunctionchaining.

Themanagement and orchestration layer within the NFV stack, i.e. TeNOR in T-NOVA, isresponsibleforthedeploymentandoperationofthedifferentnetworkservices.Themappingproblem,as ithasbeendescribedintheprevioussections– i.e.wherethevirtualnetworkfunctionswillbeallocatedintheNFVIinfrastructure-becomesthefundamentalchallengetosolve.DifferentserversintheNFVIcouldhavedifferentprocessingcapabilities,ordifferenthardwarecharacteristics,whichwillaffectattheendtheNSperformance.Whilethisistruefor all the virtual network functions that process traffic continuously, e.g., deep packetinspection(DPI),thereareotherspecificcontrolfunctionswhichareonlyexecutedduringacertain period of time, like the virtual path computation element (PCE) [32] or themulti-domainvirtualforwardingfunction,aspresentedin[33].Thesecontrolfunctionscanbealsovirtualizedtogetherwiththeactualtraffic-handlingfunctions,butanewchallengecomesintothearenaforthelastgroupofvirtualnetworkfunctions;itisthescheduling,i.e.,whenisitbettertoexecuteeachfunctioninordertominimizethetotalexecutiontimewithout,atthesame time, degrading the service performance and respecting all the precedencies anddependenciesamongthefunctionscomposingtheservice.

Figure11Networkservice(controlfunctions)schedulingontoNFVI

Discussiononwhetherthesespecificvirtualcontrolfunctionsmustbeconsideredasvirtualnetworkfunctionsisleftoutthescopeofthisdeliverable.TheNFVschedulingproblemhasbeendefinedwithinT-NOVAandpublishedin[34],[25],aswellasithasbeenacceptedasoneoftheproblemstobesolved,amongstothersin[23].ThefollowingNFVschedulingalgorithmhasbeenproposedbythe“FundacioPrivadaI2CAT,InternetIInnovacioDigitalACatalunya”(I2CAT).

ProblemDescription

Inthemodelanumberofsetsareused.𝐹representsvirtualnetworkfunctions,𝑁representsnetworkservices,whicharecomposedofdifferentchainsofvirtualnetworkfunctions,and𝑆representsservers,whicharetheelementsresponsibleforprocessingdifferentfunctionsand


©T-NOVAConsortium

37

services.Eachnetworkfunction𝑓 ∈ 𝐹belongstooneofthenetworkservices𝑛 ∈ 𝑁.Infact,eachnetworkserviceismadeofanumberofnetworkfunctions.Therelationismodelledbysets𝐹 𝑛 ,which,foreachnetworkservice,containsallfunctionsthatconstituteit.Thenotionof network service is also indirectlymodelled by sets𝐹 𝑓 that define relations betweennetwork functions, i.e., for each function we define a set (possibly empty) of networkfunctions that cannot be initiated before the considered network function is successfullyexecuted.Thesetsarelistedbelow:

• 𝐹networkfunctions.• 𝑁networkservices.• 𝐹 𝑛 networkfunctionsbelongingtonetworkservice𝑛.• 𝐹 𝑓 network functions that cannot executed before finishing the execution of

networkfunction𝑓.• 𝑆servers.

Thereisalsoasetofconstantsintheproblem,whicharerelevantforthecalculations:

• 𝑡 𝑓, 𝑠 timeneededbyserver𝑠toexecutefunction𝑓.• 𝐴weightofthefinishtimeofthelastservednetworkfunction.• 𝑀infinity;asufficientlylargeconstantinpractice.

Constant𝑡 𝑓, 𝑠 isresponsibleforaserverclassification.Bysettingdifferentexecutiontimesfordifferentnetworkfunctionsondifferentservers, it ispossibletoeasilycreateclassesofservers. Inaddition,settingappropriateconstants𝑡 𝑓, 𝑠 tosufficiently largenumbers,wecaneasilyblocksomefunctionsfrombeingexecutedonparticularservers.However,suchanoperationcanbedonemoreeasilybyforcingappropriatevaluestobeequaltozero.Anotherconstantis𝐴. Itservesasaweighttoindicatewhichpartoftheobjectivefunctionismoreimportant:thefinishtimeofthelastservednetworkservice,orthesumofthefinishtimesofallnetworkservices.The lastconstant is theso-called“big-M”constant frequentlyused inmixedintegerlinearprogramstoexpressrelationsbetweenbinaryandrealvariables.

Finally,thevariablesconsideredfortheproblemmodelare:

• 𝑧finishtimeofthelastservednetworkservice.• 𝑧®finishtimeofnetworkservice𝑛.• 𝑣¯startingtimeofexecutingnetworkfunction𝑓.• 𝑒 ° binaryvariable;1ifnetworkfunction𝑓isexecutedatserver𝑠;0otherwise.• 𝑎¯¯±binaryvariable;1ifnetworkfunction𝑓isexecutedafter𝑓′;0otherwise.

Theobjectivefunctionisdefinedasfollows

𝑚𝑖𝑛𝐴𝑧 + 𝑧®®∈²

Intheformulation,theobjectivefunctionconsistingoftwocomponentsisminimized.Thefirstcomponentisthetimeneededtoexecuteallnetworkservices,whilethesecondcomponentisthesumofthetimesneededtoexecuteeachnetworkservice.Thefollowingconstraintsaretakenintoaccountintheproblem.

𝑧 ≥ 𝑧®∀𝑛 ∈ 𝑁(1)

𝑣¯ + 𝑡 𝑓, 𝑠³∈´

𝑒 ° ≤ 𝑧®∀𝑛 ∈ 𝑁, ∀𝑓 ∈ 𝐹(𝑛)(2)

𝑣¯ + 𝑡 𝑓, 𝑠³∈´

𝑒 ° ≤ 𝑣¯±∀𝑓 ∈ 𝐹, ∀𝑓′ ∈ 𝐹(𝑓)(3)


©T-NOVAConsortium

38

𝑣¯ + 𝑡 𝑓, 𝑠 ≤ 𝑣¯± + 𝑀 𝑎¯¯± + 2 − 𝑒 ° − 𝑒 ±° ,∀𝑓, 𝑓′ ∈ 𝐹, ∀𝑠 ∈ 𝑆(4)

𝑎¯¯± + 𝑎¯±¯ = 1,∀𝑓, 𝑓′ ∈ 𝐹: 𝑓 ≠ 𝑓′(5)

𝑒 ° = 1,∀𝑓 ∈ 𝐹(6)³∈´

Variablezrepresentsamomentintimewhenallnetworkservicesarealreadyexecuted;thus,itcannotbesmallerthanthefinishtimeofanynetworkservice,whichisexpressedby(1).Ontheotherhand,thefinishtimesofsinglenetworkservicescannotbesmallerthanfinishtimesofnetworkfunctionsformingthem.Therelationismodelledby(2).Noticethatin(2)theterm

𝑡 𝑓, 𝑠³∈´ 𝑒 ° isjustatimeneededtoexecutefunction𝑓onaselectedserverrepresentedby𝑒 °.Weconsidernetworkservicesthatimposevariousconstraintsonnetworkfunctionstheyarebuiltof.Thisfactisrepresentedby(3),inwhichtimeofexecutingnetworkfunction𝑓′thatfollowsanothernetworkfunction𝑓,i.e.𝑓′ ∈ (𝑃(𝑓)),hastobegreaterthanthefinishtime of executing network function𝑓. The next constraint, namely (4), prevents networkservicesfrombeingexecutedinparallelonthesameserver;it isinfactassumedthateachserver canprocessonly a singlenetwork functionat a time. Inotherwords, consider twonetworkfunctions𝑓and𝑓′,assumethat𝑓isexecutedbefore𝑓′(thus𝑎¯¯± = 0)andbothareexecutedonserver𝑠. Ifalltheconditionsaremet,constraint(4)reducesto𝑣¯ + 𝑡 𝑓, 𝑠 ≤𝑣¯±,whichmeansthatthestartingtimeofexecutingnetworkfunction𝑓′hastobeafterthefinishtimeofexecuting𝑓.Ontheotherhand,whenatleastoneofthementionedconditionsisnotsatisfied(𝑎¯¯± = 1or𝑒 ° = 0or𝑒 ±° = 0),constraint(4)reducesto𝑎 ≤ 𝑏 + 𝑐𝑀,where𝑐𝑀 ≫ 𝑎, 𝑏 ≥ 0;henceitisalwayssatisfiedregardlessthevaluesofthevariables.Obviously,constant𝑀has tobesufficiently large; in theconsideredproblem itcouldbe for instanceequal to theminimum timeneeded to execute all functionson the fastest server. Finally,constraint (5)ensures thatnotall the𝑎¯¯ variablescanbeequal to1,whileconstraint (6)ensuresthatallnetworkfunctionswillbeexecuted.

The scheduling problem is still under investigation from the theoretical perspective, andfutureworkwillanalysetherelationshipbetweennetworkfunctionsschedulingandjob/taskschedulingintraditionalcomputerscience(i.e.asprocessororientedresearch),wherehugeworkonschedulinghasbeenperformed.Ontheotherhand,thereisatleastoneadditionalinitiativeintheliterature,whichintegratesbothmappingandschedulingofnetworkfunctionsintoonecomplexoptimizationproblem[35].TeNORprototypedoesnotincludeschedulingofnetworkfunctions.

Inordertosolvetheproblem,differentmethodscouldbeutilized.Forexample,aheuristicasavariationofagreedyapproachthatineachiterationschedulesanetworkfunctionwhichminimizestheoveralltimeassumingthattheremainingnetworkfunctionsarescheduledonthe fastest finishingservers.Suchaschedulingproblemcouldbeutilizedtodeterminetheperformance of different DC distribution, such as edge-computing, withmicro-DCs at theedge, and traditional Cloud computing in order to execute specific virtualized controlfunctions.

3.5. SummaryoftheFeaturesoftheAlgorithms

Table 4 below reports a summary of the main features of the algorithms, for ease ofcomparison.


©T-NOVAConsortium

39

Table4Comparedviewofmainalgorithms’features

ProposedApproach

ILPBasedAlgorithms

ReinforcementLearningbasedapproach

Multi-stageNetworkServiceEmbedding

VNFSchedulingoveranNFVInfrastructure

Objectives

Costminimizationorloadbalancing

Revenuemaximization

Costminimizationorloadbalancing

Costminimization(minimalmakespan)

Firstlevelorsecondlevel4,exactorapproximate

Firstlevel.

1stlevel:exactorheuristic

Firstlevel.

1ststage:approximate

Firstlevelandsecondlevel.

1stlevel:exact

2ndlevel:exactorheuristic

Secondlevel.ExactorHeuristic

Online/Offline

Online Online(also,thealgorithmcouldbetrainedoffline)

Online Online

Resourceconstraints

SLA,noderesources,linkresources

Noderesources,linkresources

CPU,bandwidth,location

Infrastructureresourcesavailable

Node/linkmapping

Coordinated Uncoordinated5 Coordinated6 -

Dependencies Optimizer,e.g.GLPK7orCPLEX

- Optimizer,e.g.CPLEX8

-

4First levelmapping:theproblemofassigningVNFstoPoPs.Secondlevelmapping:theproblemofassigningVNFcstoserversinDCs.5Thesingleiterationofthealgorithmisuncoordinated.Inthelongrun,learningissuchthatthenodeandlinkmappingareactuallycoordinateddecisions.6Nodemappingandlinkmappingtakesplacesimultaneously,i.e.,wecanrethinknodemappingiftheoverall cost is lower. In contrast, uncoordinatedmeans the nodemapping is fixed beforewe startmappingthelinks,evenattheriskofrejection.7 GLPK is an open source tool for solving linear mathematical optimization problems (seehttps://www.gnu.org/software/glpk/).8 CPLEX, developed by IBM, is one of the most efficient commercial tools available for solvingmathematical optimization problems (seehttp://www.ibm.com/software/commerce/optimization/cplex-optimizer/).


©T-NOVAConsortium

40

4. SERVICEMAPPINGMODULEIMPLEMENTATIONANDINTEGRATION

ThissectiongivedetailsonhowtheT-NOVAservicemappingmodulehasbeenimplementedandintegratedintoTeNOR,theT-NOVAorchestrator.

ThedocumentationoftheservicemappingmoduleAPI,andofthedatamodelandtheformatusedtoexchange informationbetweentheservicemappingmoduleandtheotherTeNORmodulesisreportedintheannexes.

4.1. Implementation

Similar to the other main orchestrator components, the service mapper has beenimplementedasamicroserviceapplication,whichiscomposedby:

• ARESTservice(writteninRuby[36]).• Acompiledapplication(writteninC++).

Thetwomoduleshaveeachaspecifictask:inanutshell,thecompiledapplicationimplementstheactualsolveroftheservicemappingmathematicalproblem,whiletheRESTserviceactsas an interfacebetween theothermicroservices in theorchestrator and the solver (i.e. itgatherstheinputsneededtobuildthemathematicalmappingproblem,passesthemtothesolverandreturnsthesolutiontotheorchestrator).DetailsoftheRESTserviceareprovidedinthenextsectionofthisdocument,devotedtotheintegrationwork.AschemaofthewholemicroservicearchitectureisgiveninFigure12below.

Figure12DetailsoftheT-NOVAServiceMappermicroservice.

Asrepresentedinthefigure,whentheservicemappingmoduleiscalledbytheorchestrator,theoperationsaredividedintothreemainflows:

1. Queryingofthenetworkservicecatalogue(leftbranchinthefigure).


©T-NOVAConsortium

41

2. Queryingoftheinfrastructurerepository(rightbranchinthefigure).3. Collection of constraints (central branch of the figure) varyingwith eachmapping

instance/request, such as: solver parameters – which can be chosen to tune thebehaviourofthesolver–,geographicalconstraintsonthemapping,etc.

Details onnetwork infrastructure and service cataloguequerying are reported in thenextsection,discussingtheintegrationoftheservicemappingmodule.Afterthequeryingphase,alltherelevantdatainputtotheservicemappingmathematicalproblemarestoredintwodistinctJSONfiles:

1. NI.json,afilestoringallthedatafromtheinfrastructurerepositorywhichentertheservicemappingproblemmathematicalformulation.

2. NS.json,afilestoringallthedatarelatedtothenetworkservicetobemappedandrelevantforservicemapping(also,NS.jsonfileisenrichedwiththeabovementionedruntimeinformationonalgorithmparameters,additionaluserconstraints,etc.).

After the above inputs are gathered, they are passed to the actual solver of the servicemappingproblem.Here the focus is on the implementationprovidedbyUniMiof the ILPmapping approachproposed in Section 3.1. Other mapping approaches could be similarly integrated in thefuture, by adding to themappermicroservice a routing logic which enables themappingalgorithmtobecalled.Intheabovefigure,thecall tothesolver isrepresentedbytheblock“call to ./glpksolver”,sinceanopen-sourcesolver,theGNULinearProgrammingKit(GLPK),hasbeendeployedtosolvetheILPservicemappingproblem.GLPKneedstwobasicstructuresforcorrectlyinstantiatingtheoptimizationproblem:

1. A.modfile,containingtheMathematicalProgrammingLanguage(MPL)programthatimplementstheabstractmathematicalmodeldescribedintheprevioussectionsonalgorithms’description.

2. Atleastone.datfilecontainingtheinputstothemappingproblem,collectedbytheREST service (i.e. the inputs from the infrastructure repository and the servicecatalogue,etc.).

The developed C++ application – which spans, in the above figure, from the “call to./glpksolver” block up to the “Output:result.json” block – acts as awrapper for the GLPKsolver; this application is invoked and executed by the REST service once all the networkinfrastructureandnetworkservicedatarequiredbythesolverhavebeencollectedandlocallysavedtodiskintothetwoinputfilesNI.jsonandNS.json.The application is composed by two distinct binary executables, which are sequentiallyinvokedbytheRESTservice:

1. jsonConverter,whichparsesandfurtherprocessesbothfiles inordertocreatethe.dat files required by GLPK; data extracted from the NI.json and NS.json files areroughlydividedintothree.datfiles:

a) NI_generated.datfile,containingthesnapshotofthenetworkinfrastructure,i.e. the list of PoPs and their connection topology, as well as additionalinformationregardingeachPoPandeachlinkbetweenthem(i.e.computingpowerandcapabilities,bandwidthanddelayofnetworkconnections,etc.).

b) NS_generated.datfile,whichcontainsthedescriptionofthenetworkserviceanditsrequirement,i.e.,thelistofVNFsandtheirconnectiongraphs,aswellasminimalhardwareandbandwidthrequirements,etc.

c) pref_generated.datfile,whichcontainsalistofvariablesthatarenotstrictlyrelatedtoNIorNS,butareusedbythesolvertoadaptthesolutiontoany


©T-NOVAConsortium

42

needspecifiedbythecustomer(i.e.lockingaVNFtoaspecificPoP)orbythenetworkstatus/flavour/servicecharacteristicsbysteeringthesolutioninordertomeetthoserequirements(i.e.preferringdelayminimizationinsteadofPoPspreading);thesevariablesareNIandNSindependentandmayvaryateachallocationrequest.

2. solver,whichactsasawrapperfortheGLPKsolver:oncethe.datfilesaresuccessfully

imported,thisapplicationallocatesanMPLproblem,fillsitsworkspacewithboththemodelandthedatafiles,andinvokestheactualGLPKsolver.

ThelasttaskofthesolverbuildsandreturnsthesolutiontotheRESTservice,injsonformat.Aresponseisprovidedeveniftheproblemhasnofeasiblesolution,whileerrormessagesaregeneratedifsomethinggoeswrongwhencreatingandinstantiatingtheMPLproblemortheGLPKworkspace.Thereturnedfeasiblesolution(ifsuccessfully found)statesthetargetPoPofallocationforeachVNFandthepathofallocationforeachlinkbetweenVNFs.DatatransfersbetweentheRESTserviceandtheC++applicationpackageisachievedbylocallystoring files in json format.SinceANSIC++hasnobuilt-in support forparsing json filesorstreams, the Daniel Parkers's "jsoncons" open-source (under Boost license) library9 forprocessingdatainthisformathasbeenused.It isworthnotingthatbydividingthejson-to-MPLconversionphasefromtheactualsolvermayreducethefutureamountofworkneededfortheimplementationofdifferentsolversthanGLPK.

4.2. Integration

TheRESTservicementionedintheprevioussectiontakescareoftheintegrationoftheservicemapperwiththeOrchestratorcomponentsthatplayaroleinservicemapping,suchassourcesofinformationneededtobuildthemathematicalmappingproblemorasentitiesresponsibleforenforcingthemappingdecisions.Bylogicallyseparatingtheinterfacewiththeorchestrator(bymeansoftheRESTservice)fromtheactualservicemappingsolutionphase(theC++applications),astrategyforprovidingacommonplatformfordatacollectionandaggregationhasbeendevised.Sodifferentsolvingalgorithmscanbepotentiallyintegratedintotheplatformeitherbychangingthecore.modfile that reports the formulationof theoptimizationproblemtobesolved (if themappingalgorithm is still in the family of linear programming), or by changing the solver and theneeded parts of the C++ apps (in case of a mapping algorithm not based on linearoptimization). Moreover, such integration scheme provides a common testbed so thatevaluation of different algorithms may be performed on the same set of data, even inoperationalenvironment.Briefly,themaininteractionsoftheRESTservicewiththeotherinvolvedTeNORmodulesare:

• Receiveandvalidateinstantiationrequestsfromtheorchestrator.

9 https://github.com/danielaparker/jsoncons/wiki/json


©T-NOVAConsortium

43

• Collect data needed by the mapping algorithms, by querying the infrastructurerepository, the network service catalogue and virtual network function catalogueAPIs.

• SavethecollecteddataintotheNI.jsonandNS.jsoninputfiles.• Invokethemappingsolver(theUnimiC++application).• Returnthesolutiontotheorchestratorandtothevisualizationservice.

The service mapper REST service responds to explicit POST commands coming from theorchestrator,withthebodypayloadcontaining,inparticular,theIDofthenetworkservicetobeinstantiated,sothatitispossibletoproperlyquerytheservicecataloguetoretrievetheneededparametersofthenetworkservice.Oncetherequesthasbeenchecked,theoperationflowproceedsaccordingtothefollowingsteps(thereadermayreferforconveniencetoFigure12):

1. TheRESTservicequeriesthenetworkservicecatalogAPItogetadescriptorofthenetworkservice;oncesuccessfullyreceived,thisNSDisparsedandtherelevantdataare extracted (composing the virtual network functions IDs and their forwardinggraphs,aswellasanyotherfirstlevelrequirements).

2. ForeachvirtualnetworkfunctionIDcollectedinthepreviousstep,thevirtualnetworkfunctiondescriptorisrequestedfromthevirtualnetworkfunctioncatalogand,oncesuccessfullyreceived,therelevantdataareextractedfromthedescriptors:eachVNFdisparsed,lookingfortherequestedflavour(orthedefaultone).SinceeveryVNFmaybe composed by different VDUs10, we chose to collect the total aggregatedrequirementsofeachVNF(e.g.,forthememoryrequirement,theaggregatedvirtualmemoryrequirementofaVNFisthesumofthe"virtual_memory_resource_element"fieldofeachVDUcomposingtheVNF).Currently,collectedaggregatedataregardthenumberofvirtualCPUs,theamountofvirtualmemoryandtherequiredbandwidth;alsoinaddition,themaximumalloweddelaybetweenVNFsiscollectedtoo.Alsothevirtualforwardinggraph(aswellasthedescriptorsofthevirtuallinkinvolved)whichinterconnectstheVNFsiscollected.

3. AllthedatacollectedbyparsingtheNSdandtheVNFdsaresavedintoaNS.jsonfileondisk;thisfilemaycontainadditionalparametersthatareNS/VNFindependentandvaryonallocationbasis(atrun-time),i.e.geographicallocationrequirements,solvingstrategy,additionalparameterstobepassedtothesolver,etc.

4. Once NS collection finishes, the REST service begins querying the infrastructurerepositoryAPIs,inordertobuildasnapshotofthenetworkinfrastructurestatus.Datacollectedinclude,butarenotlimitedto,PoPIDs,PoPdescriptionandstatus,PoPlinksIDs,PoPlinksdescriptionsandstatuses,etc.;then,foreachPoP,everyhypervisorisqueriedinordertoextractthetotalaggregatedresourceavailableforthatPoP.

5. AggregatedresourceofeachPoPiscalculatedbysummingtheavailableresources:data regarding the total amount of available CPUs, RAM, HD and bandwidth iscollected in this sameway. EnhancedPlatformAwareness (EPA) requirements aretreated in a similar way: the current implementation counts the total number ofDPDK-enabledNICsandthetotalamountofGPUacceleratorforeachPoP,butotherEPAfeaturescanbeaddedaswell.AllnetworkinfrastructurecollecteddataaresavedtodiskintheNI.jsonfile.

6. OncebothNS.jsonandNI.jsonaresaved,thesolverisinvokedwithasystemcall.Fortheservicemappingalgorithmimplemented,theoneproposedbyUnimi,itconsists

10RecallthataVirtualisationDeploymentUnit(VDU)[5]isaconstructtodescribethedeploymentandoperationalbehaviourofaVNFc.


©T-NOVAConsortium

44

inasequenceofsystemcallstotheC++applicationsdetailedintheabovesection.The solver response is saved to disk in the "MapperResponse.json" file and datarelated tomapping visualization are built and added to the json; finally, this jsonresponseisreturnedtotheOrchestrator.

Asmentionedabove,thetwokeyT-NOVAsubsystemsqueriedbythemappingmicroservicearetheinfrastructurerepositoryandtheservicecatalogue.

Essentialinformationonthetwosubsystemsisprovidedinthefollowingtwosections.

Details on the service mapping module API and on the format and content of the dataexchangedbetweenthemappingmoduleandtheorchestratorarereportedintheannexes.

4.2.1. InteractionwiththeInfrastructureRepository

Thissectionreportsthekeyfeaturesoftheinfrastructurerepositoryinstrumentaltoservicemapping. Full details on the infrastructure repository design can be found in D3.2InfrastructureResourceRepository[37].

The infrastructure repository is the subsystem of the T-NOVA Orchestration layer whichprovides,totheresourcemappingmodule,infrastructurerelatedinformationcollectedfromthe Virtualized Infrastructure Manager (VIM) and from the NFVI components of theInfrastructure Virtualisation and Management (IVM) layer. The design of the repositorysubsystemaddressesthechallengesofassimilating infrastructurerelated informationfromsources within the IVM, namely the cloud infrastructure and data centre networkenvironments.Thissubsystemcomprisesanumberofkeyelementsincludingadatamodel,resource information repositories and accessmechanisms to the information repositories.The subsystem also augments the information provided by cloud and SDN environmentsthrougharesourcediscoverymechanism.

OpenStackuntilrecentversionsexposedalimitedsetofinfrastructurerelatedinformation,andthatwasproblematicfortheresourcemappingmodule.ForexampleintheJunoreleaseof OpenStack the NOVA service database contained almost no infrastructure informationbeyond limitedCPUdetails suchasmanufacturer, speedandCPUstatus flags.SubsequentreleasesofOpenStackhaveimprovedthelevelofinfrastructureinformationstored.HoweverinclusionoffinegrainedinfrastructureinformationremainsaworkinprogressandwillnotbefullyaddressedinthelifetimeoftheT-NOVAproject.

Generation of a comprehensive view of the network infrastructure has been anotherchallenge for the infrastructure repository. While OpenStack Neutron service databasemaintainsinformationregardingtheVMrelatednetworkconnectionsthereisnoviewofthephysicalnetworktopologyi.e.whatcomputenodeNICisconnectedtoanSDNenableswitch.InordertoaddressthislimitationitisnecessarytocollecttheseinformationfromtheDCSDNcontroller i.e. OpenDaylight. ODL provides a REST API which can be used to retrieveinformationregardingthetopologyoftheSDNswitchesandofthecomputenodesattachedtotheswitchports.Fromaresourcemappingmoduleperspectiveusingaseparateinterfacetoretrievenetworktopologyinformationcreatesunwantedcomplications.Thereforefromadesignandimplementationperspectivetherepository implementsasingle interfacewhichabstractstheretrievalofinfrastructureinformationfromallsourceswithintheIVMlayer.

Addressing these shortcomingswas the key goal for the repository subsystemdesign andimplementation.ThekeycomponentsoftheinfrastructurerepositoryasshowninFigure15arethefollowing:


©T-NOVAConsortium

45

• EnhancedPlatformAwareness(EPA)Agents–PythonbasedsoftwareagentrunningonthecomputenodesoftheNFVI-PoP.AcentralEPAcontrollerserviceprovidesaggregationofdatafromeachagentandpersiststhedatatoacentraldatabase.

• Infrastructure Repository Database – Collected infrastructure data is stored in agraphdatabasewhereresourcesarerepresentedasnodeswithassociatedproperties.Edgesbetweenthenodesstoreinformationontheirrelationship.

• ListenerServices-Twoseparatelistenerservicesarespecifiedwithinthearchitecture.TheOpenStackNotification listenerservice isdesignedto interceptmessages fromtheOpenStacknotification.infoqueueandtoprovidenotificationstothecontroller.The EPA agent listener service intercepts EPA agent messages and notifies thecontrollerofthemessagesinordertotriggerprocessingofreceiveddatafilesandtousethedatatocarryoutanupdatedatabaseaction.

• EPAController–Thecontrollerisresponsibleforupdatingtheinfrastructuredatabasebasedon informationreceivedfromthe listenerservicesanddatafilessentbytheEPAagents.OneinstanceofthecontrollerrunsineachNVFI-PoP.TheservicerunsonacomputenodewithintheNFVI.

• APIMiddlewareLayer–ProvidesacommonsetofAPIcallsthatcanbeusedbyallthe functional entities of the T-NOVA Orchestration layer including the resourcemappingmodule.

Figure13InfrastructureRepositorysub-systemarchitecture

4.2.1.1. InfrastructureRepositoryDatabase

Regarding the implementationof the infrastructure repositorydatabase itwas considereduseful and important to encode the relationship between the resources and associatedparameters.Inordertoachievethisgoalagraphdatabaseapproachwasadopted(seetheT-

VirtualInfrastructureManagement(VIM)

NetworkFunctionVirtualisationLayer

T-NOVAOrchestrator

ML2Plugin

EPAAgent

EPAControllerService

APIMiddlewareLayer(REST)

Nova Neutron

OpenStackMessageQueue

EPAAgent EPAAgent

ServiceandVNFManagers

Visualisation

Region:GeoLocation1NFVI-PoP1

Region:GeoLocation2NFVI-PoP2

Cloud3

Cloud1Cloud2

EPADB

OpenStackListenerService

PoP IngressandEgressEndpoints

PoPDB

PoP TopologyVisualisation

InfrastructureData

NetworkTopologyData

VirtualMachine

VirtualMachine

VirtualMachine

Virtua lMachine

VirtualMachine

VirtualMachine

Virtua lMachine

VirtualMachine

VirtualMachine

GatekeeperSecurityAuthentication

ServiceandVNFManager

ResourceMapping

EPAAgentListenerService


©T-NOVAConsortium

46

NOVA deliverable 3.2 [37] for more details). Graph databases are NoSQL (Not only SQL)database systems which commonly use a Directed Acyclic Graph (DAG) to store datarelationships.Agraphdatabasestoresinformationusingvertices/nodesandedges/relations.

Theuseofgraphsmapsconvenientlytothehierarchicalstructureofcompute,storageandnetworkelementswithintheNFVI.TheNFVIcanbedecomposedintoeitherphysicalorvirtualresourcesthatcanbemappeddirectlytoanodestructure.Therelationshipsofvirtual-virtual,physical-physicalandvirtual-physicalarecapturedintherelevantconnectionsbetweentheresources.Virtualresourceshaveanimplicitdependencyonphysicalresources,i.e.avirtualresourcecannotexistwithoutaphysicalhost.Thereforeinagraphconstruct,virtualresourcesmustatsomepointofthegraphbeconnectedtoaphysicalresource

Figure14showsasimplegraphforaserver,whereithastwosockets,eachsockethasoneCPUandeachCPUhasmultiplecores.

Figure14Simpleserverresourcegraph

MiddlewareAPI

To achieve a unified view of the infrastructure information among multiples PoPs, theinfrastructure repository implements amiddleware layer. Themain responsibilities of themiddlewarelayerare:

• Defining a common view for all information sources (OpenStack, EPA Agents andOpenDaylightSDNcontroller);

• DispatchinguserrequeststotherequiredPoP.

Themiddleware layerexposestheAPIcalls tomanagethePoPs(Create,Retrieve,Update,Delete).Whenarequestissenttothemiddlewarelayer,theIDofthePoPthattheuserwantstoaccessmustbespecified.InthiswaythemiddlewarelayercanretrievetheURLsandquerytheappropriatePoPlevelinformationsources.Fromtheperspectiveofacomponentusingthe interface the locationof thedata and theunderlying complexity in forming thequeryresponseisabstracted.TobecompliantwiththeotherOrchestratorinterfacesaRESTtypeapproachwasadopted to implement the interfaces (seedeliverableD3.2Section4.5.1 formoredetails).SomesamplecallstoretrievespecificinfrastructureinformationavailabletotheresourcemappingmoduleareshowninTable5.

Server

Socket Socket

CPU CPU

Core Core Core Core

Hasresource

Hasresource

Hasresource


©T-NOVAConsortium

47

Table5APIcallsforspecificinfrastructureinformationretrieval

Kind Endpointurl Description Actions

Net /pop/{pop_id}/net/ Neutronnetwork GET

Port /pop/{pop_id}/port/ Neutronport GET

Hypervisor /pop/{pop_id}/hypervisor/ HypervisorusedbyNovaCompute GET

Machine /pop/{pop_id}/machine/ Physicalmachine GET

NUMANode /pop/{pop_id}/numanode/ NUMAnode GET

NUMA nodelink /pop/{pop_id}/numanode/link/

Link between NUMAnode and Bridge orSocket

GET

PCIBridge /pop/{pop_id}/bridge/ PCIBridge GET

Bridgelink /pop/{pop_id}/bridge/link/Link between PCI bridgeand PCI devicesconnectedtoit

GET

PCIDevice /pop/{pop_id}/pcidev/ PCIDevice GET

PCI Devicelink /pop/{pop_id}/pcidev/link/ Link betweenPCIDevice

andrespectiveOSdevice GET

OSDevice /pop/{pop_id}/osdev/OSDevice(allowedtype:Compute, Network,Storage)

GET

Socket /pop/{pop_id}/socket/ Socket GET

Cache /pop/{pop_id}/cache/ Cache GET

Core /pop/{pop_id}/core/ PhysicalCore GET

Corelink /pop/{pop_id}/core/link/ Link to Process Unitsnode GET

PU /pop/{pop_id}/pu/ Processingunit GET

Switch /pop/{pop_id}/switch/ PhysicalSDNswitch GET

SwitchInterface /pop/{pop_id}/switch-interface/

Switch interfacecontrolled by ODLcontroller

GET

TechnicaldetailsonthesequenceofactionsperformedtoquerytheinfrastructurerepositoryandanexampleoftheresultingNI.jsonfilearereportedinAnnex11.

4.2.2. InteractionwiththeT-NOVANSD

TheSLAspecificationinT-NOVAisdoneinthemarketplacebytheServiceProvider(SP)[38]andwill be available toTeNORbymeansof theT-NOVANSD that is stored in the servicecatalogue[39].TheSPwilldefineinthemarketplaceexpectedvaluesforthedifferentservice


©T-NOVAConsortium

48

performance metrics, considering the performance metrics of VNFs that are part of theservice.Alsoothermetrics canbedefined for theend-to-endserviceconsidering the linksbetweenVNFs,forinstancethedelayaddedbythelinks.

Therefore,eachSLAspecificationisassociatedbymeansoftheNSDtotheVNFDsoftheVNFsthat constitute the service. These VNFDs describe the VDU requirements defined by theFunctionProviders(FPs)forthecorrespondingVNFflavorineachcase.

The marketplace will also define, as part of the SLA specification, the rewarding for thecustomer,likebillingdiscounts,incasetheSLAagreedbetweentheSPandcustomerisnotmet.ThisisrelevantforthecommercialactivityintheT-NOVAmarketplaceandnotforTeNORitself,butitrepresentstherelevancefortheservicemappingtoachievetheSLAspecifiedfortheservice.

TheNSDandVNFDfieldsrelevantfortheservicemappingarereportedinthefollowingtables.

Table6NSD:SLA

Identifier Description

SLA_Id IDoftheserviceSLAassurance_parameters

Assurance parameter or a combination of multiple assurance parameters with a logicalrelationship between them and values against which this SLA is being described. TheparametersshouldbepresentasaNSD:monitoring_parameter,andtheycanbe:

- genericmetricscommontoall thenetworkservicesthatwillbemonitored(e.g.networkthroughputmetrics).Thebasicmetricswillhaveanassociatedthresholdforactioninitiation.

- Flavour_keyparametersflavour_key Parameter or a combination ofmultiple assurance parameterswith a logical relationship

betweenthemagainstwhichthisflavourisbeingdescribed.constituent_vnf

Representsthecharacteristicsofaconstituentflavorelement.

Table7NSD:SLA:assurance_parameters


name Nameofthemetricvalue RangeofvaluesthemetricshouldtaketomeettheSLA:LT(50)àlowerthan50unit Unitofthevalues:%,Mb,Gb,etcformula FormulathataggregatesthemetricsoftheVNFsinordertocalculatethevalueabove.violations DefinitionofSLAviolations

Table8NSD:SLA:assurance_parameters:violation


breaches_count

Amountoftimesthethresholdsarebreached

interval Timeinterval

Table9NSD:SLA:constituentVNFs


vnf_reference ReferencetoaVNFDdeclaredasVNFDinthenetworkserviceviavnf:id.


©T-NOVAConsortium

49

vnf-flavour_id_reference

ReferencesaVNFflavor(vnfd:deployment_flavour:id)tobeusedforthisserviceSLA.

redundancy_model

Representstheredundancyofinstances,forexample,“active”or“standby”

affinity Specifiestheplacementpolicybetweenthisinstanceandotherinstances,ifany.number_of_instances

NumberofVNFinstancessatisfyingthisserviceassurance.

Table10VNFD:deploymentflavor

Identifier Descriptionid IDoftheVNFflavourassuranceparameters

Asetofelementsrelatedtoaparticularmonitoringparameter.

constraint Constraintthatthisdeploymentflavourcanonlymeettherequirementsoncertainhardwareconstituent_vdu Representsthecharacteristicsofaconstituentflavourelement

ExamplesincludeControl-planeVDU&Data-planeVDU&LoadBalancerVDUEachneedsaVDUelementtosupportthedeploymentflavourof10kcalls-per-secofvPGW,Control-planeVDUmayspecify3VMseachwith4GBvRAM,2vCPU,32GBvirtualstorageetc.Data-planeVDUmayspecify2VMseachwith8GBvRAM,4vCPU,64GBvirtualstorageetc.

Table11vnfd:deployment_flavour:constituent_vdu

Identifier Descriptionvdu_reference ReferencesaVDUwhichshouldbeusedforthisdeploymentflavourbyvnfd:vdu:idnumber_of_instances

NumberofVDUinstancesrequired

constituent_vnfc

ReferencesVNFCswhichshouldbeusedforthisdeploymentflavourbyvnfd:vdu:vnfc:id

TechnicaldetailsonthesequenceofactionsperformedtoquerytheservicecatalogueandanexampleoftheresultingNS.jsonfilearereportedinAnnex12.


©T-NOVAConsortium

50

5. SIMULATIONTESTS

Theaimof thissection is topresentanddiscusssimulationtests foreachservicemappingalgorithmproposed in T-NOVA,with theobjectiveof highlighting thepeculiarities of eachapproach,itsstrengthsandthepossibledrawbacksandareasforfutureworks.

5.1. IntegerLinearProgrammingbasedapproach

Weperformeda computationalevaluationof themethodboth tounderstand the relativeimpactofparameterschoiceinourmodelsandtoassessthescalabilityofthesolvers,therebyvalidating the practical applicability of our framework. For this task we built a syntheticsimulator,workingasfollows.

First, we populated the simulator with the Network Infrastructures (NI) and the NetworkServices (NS) included in the dataset [40] described in [41], a popular reference in theliteratureofmappingalgorithms.Inparticular,suchadatasetconsistsof210baseinstances,partitioned in 7 classes of increasing size networks, each one including 30 instances. AnyinstancecontainsagraphdescribingtheNIandanumberofsmallergraphsdescribingtheNSs.NSgraphsbelongtoalimitednumberoftopologies,representingdifferentservicetypes.NI (respectively, NS) graph nodes are annotated with one integer, indicating the CPUavailability(respectively,consumption)onthatnode.NIgraphnodesareannotatedalsowithanadditionalinteger,indicatingtheallocationcostonthatnode,whichisindependentontheNSnodetobeallocated.Similarly,NI (respectively,NS)grapharcsareannotatedwithtwointegers,oneindicatingtheamountofavailable(respectively,consumed)bandwidth,andtheotherindicatingtheexpected(respectively,required)delayonthatarc.Furthermore,foreachNSnodeavectorofcompatibilitiestoNInodesisgiven,indicatingwhichmappingsarefeasibleduetospecificresourcesneededbytheNSVNFonthehost.WeconsideredeacharcintheNSgraph(andonlythem)ascriticalpaths,whosedelayconstraintshavetoberespected.

InTable12thefeaturesofthisdatasetarereported:foreachclass,wedetailedthenumberof nodes in the NI, the average number of nodes in the corresponding NSs, the averagenumberofNStypes,theaveragefractionofNI-NSnodemappingswhicharefeasible,andtheaverage ratio between the overall amount of available CPU at NI nodes and the overallrequiredCPUofNSnodes.

Table12Instancedetails

Size Average VNF nodes

VNF types

Average compatibility

ratio Available CPU / required CPU

20 5,52 4 18,98% 3,38 30 6,91 4 16,56% 3,88 50 9,87 4 13,81% 4,29

100 17,43 4 10,03% 5,1 Total

Result 9,93 4 14,84% 4,16

Thesebaseinstancesrepresentstaticmappingproblems,whilethoseinTNOVAaredynamic.Thatis,eachNSallocationrequestarrivesatacertainpointintimeandhasacertainduration:NIresourcesareallocated,ifpossible,wheneachrequestisissued,andreleasedwhentherequestisover.


©T-NOVAConsortium

51

Therefore,wecompletedoursyntheticsimulatorconsideringtworunningmodes:simulationandstresstest.

In simulationmode,wemodel the arrival ofNS allocation requests as a Poisson process,whoseaverageinterarrivaltimeisdenotedasλ.WealsoassumethedurationofNSallocationrequests to be random, following a normal distributionwhosemean is denoted as μ andwhosestandarddeviationisdenotedasσ.Asimulationrunconsistsofselectingaparticularbase instance (that is, a NI and the corresponding pool of possible NSs), and then to (a)iterativelychooseoneNSatrandom,selectingitwithuniformprobabilityfromtheNSpool,(b) randomly draw an interarrival time and a duration for the corresponding allocationrequest, (c) possibly release theNI resources assigned to allocations requests terminatingwithinthedrawninterarrivaltime,(d)askthemappingalgorithmtofindasuitableallocationof the drawn NS to the NI, (e) either reject the allocation request or accept it, andsubsequentlymarkNIresourcesasused,accordingtothemappingprovidedbythealgorithm.Thesimulationendsassoonasthesumofinterarrivaltimesexceedsagiventimehorizonτ,thatrepresentsthetimelengthofthesimulation.Valuesλ,μ,σ,andτ,andthebaseinstancetobeused,areparametersofthesimulator.

Instresstestmode,instead,weconsiderforagivenbaseinstanceallNSallocationrequeststoarrivefollowingtheorderinwhichtheyappearintheinstancefile,withanegligiblefixedinterarrival time, and a duration equal to τ. That is, in stress test mode all NS allocationrequestsarriveoneafteranother,theyareeitherrejectedorallocated,andinthesecondcasetheassignedresourcesareneverreleased.

Forthesakeofinterpretability,wealwayssetthesimulationlengthτ=168hours(thatis,oneweek),theaverageallocationrequestdurationμ=24hours,andthecorrespondingstandarddeviationσ=2hours.

5.1.1. Test1:EvaluatingsolversscalabilityastheNIsizeincreases

First,weverifiedthattheapproachiscomputationallyeffectiveenoughtobeembeddedinTeNOR.Wethereforeconsideredtwooptions:touseeithertheopensourcesolverGNUGLPKorthecommercialone IBMCPLEXtoperformservicemapping. Inbothcases,thesolver isinvokedtooptimizetheservicemappingmodeldescribedinSection3.2.

Atimelimitof60swasgiventoeachsolverrun.Thesimulationswererestrictedtoinstanceswithupto100NInodes.Theparametersα,βandγofthemodelwereallsetto1.

Thesyntheticsimulatorwassetinsimulationmode.Weanalysedtwoscenarios:mildandhighaverageNIload,settingintheformercaseλ=μ/(0.50*(L/l)),andinthelattercaseλ=μ/(0.75*(L/l)),whereListheoverallavailableCPUresourcesintheNI,andlistheaverageamountofCPUresourcerequiredbyeachNSinthecorrespondingpool.Thatis,ifCPUweretheonlyscarceresource,andNSnodefragmentationwerepossible,inthemild(respectively,high)averageNI load scenariowewouldexpect tohaveabout50% (respectively, 75%)ofoverallCPUresourcesalwaysallocated.

We considered two performance measures: the percentage of accepted NS allocationrequests,andtheaveragecomputingtimeperallocationrequest.

Table13Solversscalabilitytest,60stimelimit

Solver GLPK


©T-NOVAConsortium

52

Ave

rage

lo

ad

Size Acceptance rate

CPU time

(accept)

Percentage Timeout (accept)

CPU time

(reject)

Percentage Timeout (reject)

0,5 20 80,55% 0,02 0,00% 0,03 0,00% 30 75,31% 0,21 0,19% 0,43 0,57% 50 71,43% 0,49 0,20% 0,48 0,34% 100 58,91% 2,69 0,78% 1,95 0,63%

0,75 20 67,52% 0,02 0,00% 0,02 0,00% 30 62,12% 0,21 0,12% 0,25 0,25% 50 57,26% 0,51 0,19% 0,32 0,08% 100 47,57% 2,57 0,74% 1,87 0,54%

Avg. 65,08% 0,84 0,28% 0,67 0,30% Solver CPLEX

Ave

rage

lo

ad

Size Acceptance rate

CPU time

(accept)

Percentage Timeout (accept)

CPU time

(reject)

Percentage Timeout (reject)

0,5 20 80,57% 0,02 0,00% 0,01 0,00% 30 75,42% 0,04 0,00% 0,02 0,00% 50 71,07% 0,09 0,00% 0,04 0,00% 100 59,52% 0,31 0,00% 0,16 0,00% 0,75 20 67,73% 0,02 0,00% 0,01 0,00% 30 62,70% 0,04 0,00% 0,02 0,00% 50 58,75% 0,08 0,00% 0,04 0,00% 100 47,07% 0,29 0,00% 0,15 0,00% Avg. 65,35% 0,11 0,00% 0,06 0,00%

Table13contains twohorizontalblocks,oneforeachNI loadscenario (columnavg. load).Eachblockcontainsonerowforanyinstanceclass,reportingaveragevaluesoverinstancesofthatclass.InstanceclassesaresortedbyincreasingNIsize(columnsize).Theactualresultsarereportedinthesubsequenttwoverticalblocks,oneforeachsolveroption(asindicatedinthe leading row). Each of them is composed by two sub-blocks, restricting to results onallocation requests that were accepted (respectively, rejected). In each sub-block wereported, in turn, the average percentage of accepted (respectively, rejected) allocationrequests, the average CPU time spent inmapping for those requests that were accepted(respectively,rejected),thepercentageofthoserunsthatexceededthetimelimit.

Wefirstobservethatcomputingtimeisnotacriticalissue:thecommercialsolverCPLEXneverexceedsthetimelimit,andtheaverageresponsetimesisaslowas0.3sevenforlargeNIs.TheopensourcesolverGLPKyieldscomputingtimesthatareoneorderofmagnitudelargerthanthoseofCPLEX;thiswasexpected,givingthebenchmarkingresultsfromtheliterature.Still, the average query time is always less than 3s. Allocation rejection is almost alwaysproducedastheresultofthesolverdetectinginfeasibility(timeoutisobservedonaveragein0.3% of the runs, and only for GLPK); rejections are on average faster to report thanallocations.


©T-NOVAConsortium

53

Summarizing,bothsolversscalewellintermsofcomputingtime:embeddingeitherCPLEXorGLPKwould likelyyield systemswhosebottleneck isnot the servicemappingoptimizationalgorithm.EmbeddingCPLEXyieldsalmostreal-timeperformances.

Second,weobservedthatthepercentageofacceptedrequestsdecreasesasthesizeoftheNIincreases.Thismighthighlightapossiblepointofimprovementforthemappingmodel.Atthesametime,GLPKandCPLEXprovidealmostidenticalresults,evenifGLPKincursmoreoften(0.3%oftheruns)intimeouts.

To further check the behaviour of the solvers when very fast response is required, werepeatedtheexperimentbysettingatimelimitof3sinsteadof60s.OurresultsarereportedinTable14;forsimplicityonlytheNSallocationrequestsacceptancerateisreportedforbothsolvers; as a reference,we include also the acceptance rate obtainedduring the previousexperiment.Onaverage,noworseningisobserved.

Table14Solversscalabilitytests,overallacceptancerate.

Timeout 3 seconds 60 seconds

Average load Size GLPK CPLEX GLPK CPLEX

0,5 20 80,48% 80,25% 80,55% 80,57% 30 74,92% 76,15% 75,31% 75,42% 50 70,97% 71,30% 71,43% 71,07% 100 60,16% 60,12% 58,91% 59,52%

0,75 20 67,81% 67,82% 67,52% 67,73% 30 62,60% 62,52% 62,12% 62,70% 50 57,41% 57,59% 57,26% 58,75% 100 47,94% 47,76% 47,57% 47,07%

Avg. 65,29% 65,44% 65,08% 65,35%

Therefore, also in terms of acceptance rate, embedding either CPLEX or GLPK, even byimposingtighttimelimits,hasnostrongimpactontheperformancesoftheoverallsystem.

5.1.2. Test2:Evaluatingsolversscalabilityastheaveragedatacenterloadincreases

Second,we analysed the performances of ourmapping algorithm as the averageDC loadchanges.Inparticular,werestrictedourteststoinstanceswhoseNIscontain20nodes,andconsideredsimulationsinwhichtheaverageCPUloadofNInodes,denotedas𝛿,rangesfrom0.1 to 1.2, considering each step of 0.1 points, and setting for each of them 𝜆 = 𝜇/(𝛿 ∗(𝐿/𝑙)).

Figure15belowdepictstheaverageacceptancerateobtainedusingCPLEXastheaverageCPUloadchanges.


©T-NOVAConsortium

54

Figure15Percentageacceptanceasaverageloadincreases.

Figure 16 has a similar structure and reports the average computing time per allocationrequestthatwassubsequentlyaccepted(blueline)orrejected(orangeline).

Figure16CPUtimeasaverageloadincreases

Asexpected,theacceptanceratedropsastheaverageloadincreases,butthesystemdoesnotcollapseevenunderheavystress(rightmostpartofthecharts).Averageloadseemstohaveverylittleeffectonsolvercomputingtime.

No substantial difference was observed by using GLPK, and therefore the correspondingresultsareomitted.

5.1.3. Test3:Finetuningofmodelparameters

Finally,wetriedtoassessthebehaviouroftheservicemappingalgorithmastheparametersofthecorrespondingmodelchange.Tothispurpose,wesetthesyntheticsimulatorinstresstestmode, and we considered only instances whose NIs contain 20 nodes. These always

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1,0 1,1 1,2

% A

ccep

tanc

e

Avgerage Load

0

0,005

0,01

0,015

0,02

0,025

0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1,0 1,1 1,2

CPU

tim

e (s

)

Load

Avg. CPU time (accept)Avg. CPU time (reject)


©T-NOVAConsortium

55

include40NSs.Weconsideredeightconfigurations,oneforeachpossiblechoiceofeithervalue1.0orvalue0.0 foreachof themodelparametersα,βandγ. Figure17depicts theacceptancerate(verticalaxis)withrespecttotheNSallocationrequestarrivalrank(horizontalaxis)obtainedusingCPLEX.Onelineisincludedforeachconfiguration:thicklinesencodethechoiceα=1.0(whilethinonesencodeα=0.0),blacklinesencodeβ=1.0(whilegreyonesencodeβ=0.0),continuouslinesencodeγ=1.0(dashedonesencodeγ=0.0).Beforerank20theacceptanceratewasalways100%,andthereforethecorrespondingportionoftheChartisomitted.

Figure17Acceptancerateinfunctionofthearrivalrank

Wenotethatmovingfromβ=0.0(greylines)toβ=1.0(blacklines)substantiallyimprovestheacceptancerate;thesameappliesmovingfromγ=0.0(dashedlines)toγ=1.0(continuouslines).Moving fromα=0.0 (thin lines) toα=1.0 (thick lines)has still some impact,whencombinedwithsettingsβ=1.0andγ=1.0.Thismatchesourmodellingaim,inwhichobjectivetermsrelatedtoβandγdirectlyaffectallocationfeasibility,whilethatrelatedtoαisusefulonlyfordiversification,andthereforeinterPoPbalancing.Overall,settingallparametersto1.0givesthebestresults.

Figure 18 depicts the average computing time per allocation request (vertical axis) withrespecttotheNSallocationrequestarrivalrank(horizontalaxis).Onelineisincludedforeachconfiguration,respectingtheencodingdescribedabove.Whileuptorequest20theallocationsubproblemsturnouttobetrivialforthesolver,asevenasimplegreedysolutionmaybeoptimal,fromrequest21onwardssolvingthesubproblembecomesnottrivialandrequiresanadditionaleffort,evenifthesolverresponsetimeremainslow.

0123456789

10

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Num

ber o

f acc

epte

d N

Ss

Arrival Rank


©T-NOVAConsortium

56

Figure18Averagecomputingtimeinfunctionofthearrivalrank(onstresstest)

No configuration yields substantial changes in the average solver computing time. NosubstantialdifferencewasobservedbyusingGLPK,andthereforethecorrespondingresultsareomitted.

0,00

0,01

0,01

0,02

0,02

0,03

0,03

0,04

0,04

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

CPU

tim

e (s

)

Arrival Rank


©T-NOVAConsortium

57

5.2. ReinforcementLearningBasedApproach

InthefollowingsubsectionsimulationtestsforthetwoRLmappingalgorithmsproposedareprovided(i.e.fortheVNFmappingstrategyinSection3.2.1andthecompleteNSmappingStrategy in Section 3.2.2). The approach has been implemented in Matlab, with artificialinfrastructureandservicerepositoriescreatedtobuildthesimulationscenarios.

5.2.1. MappingofSingleVNFs

Thefollowingsimulationscenario isproposedtohighlightthepeculiaritiesoftheapproach.Three types of NSs are considered: “light”, “medium” and “heavy”, in terms of resourcerequirements.NSsarecharacterizedbythesamearrival (𝜆� = 0,02)andtermination (𝜆< =0,0001)Poissonianrates.NSsarecomposedeachbyasingleVNF.VNFscanrequireuptofivedifferent typesof resources.Anetworkwith10PoPs is considered. InfrastructureandNSs’resourcespecificationshavebeenchosenbasedon[41](PoPresourcesintheorderof10¹ −10ºandNScumulativeresourcesof400,500and600respectivelyforthethreeNStypes).TherewardsformappingthefirsttwoNSsaresetto1,therewardformappingthe“heavy”NSsisset to 10. The remaining simulation parameters are 𝜂 = 0.9, 𝛾 = 0.7, 𝛼� = 1/(1.01 +𝜏/1000 ). This simple simulation setting is aimed at showing how RL manages to learnenvironmentdynamicsandmaximizetheallocationreward,inrespectofinfrastructureandNSconstraints.Figure26showsthetotalrewardachievedintime(3×10ºsimulationsteps)bytwodifferentpolicies:agreedypolicyandtheproposedQ-Learningstrategy.

Figure19Revenueevolution:greedyandQ-Learningpoliciescompared

ThegreedypolicyisatypicalpolicyusedforbenchmarkpurposesinRLapplications.Accordingto the greedy policy, at each time 𝜏, the action is chosen which maximizes the currentachievablereward𝑟�,compatiblywiththePoPs’levelofoccupancy.ThefigureshowsthattheadoptedQ-Learningpolicylargelyovercomesintimethegreedyone.TheQ-Learningstrategyensureshigherperformancesbylearningsystem’sdynamics(e.g.arrivalandterminationrates,PoP resources availabilities and NS requirements). Also, it acts having as objective theperformanceofthesystemoveratimehorizon,ratherthanbylookingonlyattheimmediatereward(thusimplicitlyimplementingthe“lookahead”property[16]).Inthissense,allocationofNSs ismanagedbythecontroller insuchawayastogivesomeprecedencetothemostrewardingservices,asitcanbeseeninthenextFigure27.Thefigureshowstheperformanceof the two policies in terms of average acceptance rate. For both policies, as natural, theacceptanceratedecreasesastheNSsizeincreases.

0 0.5 1 1.5 2 2.5 3 3.5x 104

0

0.5

1

1.5

2

2.5

3

3.5x 104

Mapping Request Number

Tota

l Rew

ard

Q-LearningGreedy Policy


©T-NOVAConsortium

58

Figure20AverageNSacceptancerates

However,itcanbenoticedthat,undertheQ-Learningpolicy,theacceptancerateofthe“large”NS (the one associatedwith the greatest reward) significantly increases (+56%), while theacceptance rate of the “small-size”NS decreases.Notice that this is done not by explicitlyrejectingthelessrewardingservices(eventhoughexplicitrejectioncouldbemodelledaswell),but rather bymapping them to sub-optimal PoPs, in order to keep available space for therewardingNSs. As a result, also the overall acceptance rate increases (+4%), resulting intohigherutilizationofPoPresources11(Figure28).

Figure21UtilizationofPoPresources

Thesimulationscenarioabovecorrespondstoachallengingloadfactor12of1.05.Furthermore,the fact that the different NSs have different resource requirements poses significant

11UtilizationisdefinedhereastheratiooftheaverageusedPoPresourcesoverthetotalavailablePoPresources.12Recallthatloadfactorisdefinedhereastheratiooftheaveragerequestedresourcestotheavailableones.

1 2 30

0.2

0.4

0.6

0.8

1

NS Type

Acce

ptanc

e Rate

Greedy PolicyQ-Learning

0 0.5 1 1.5 2 2.5 3 3.5x 104

0

0.1

0.2

0.3

0.4

0.5

0.6

Mapping Request Number

Utiliz

ation

Q-LearningGreedy Policy


©T-NOVAConsortium

59

constrainttothemappingprocess(making impossible inpracticetoachievehighutilizationfactors).

Concluding,thefollowingstrengthscanbementionedregardingtheproposedRLapproach:(i)the behavior of the algorithm can be tuned in accordance with the control objectives bychoosingtherightrewardfunction,(ii)themappingalgorithmworksbysimplyupdatingtheequations(9)and(10),thushavingnegligibleexecutiontimes,(iii)thelearningpropertyoftheRL algorithm makes possible to maximize not just the immediate reward, but rather theexpectedrewardinthelongrun,whichisimportantwhenactinginanuncertainenvironment(e.g.stochasticservicerequesttimesandtypes).Inparticular,points(ii)and(iii)aredistinctivefeatureswithrespecttotheproposedILPapproaches.

5.2.2. MappingofCompleteNSs

WefinallyprovideasimplesimulationtestoftheRLalgorithmdesignedtomapNSscomposedbymore thanoneVNF (i.e. themostgeneral case– refer toSection3.2.2). To thisend,ascenarioisconsideredinwhichrequestsrandomlyarriveaccordingtoaPoissondistribution.Ateachrequesttime,aNSisrandomlypickedfromapoolofthreepossibleones.Topologyandnode/linkresourcerequirementsofthethreeNSsarereportedinthenextfigure.

(a)

(b)

(c)

Figure22NSstopologiesandbandwidthrequirementsfortheNS1(a),theNS2(b)andtheNS(c)

Thealgorithmistestedonthe20nodeNIfrom[41],thesameusedpreviouslyinSection5.1.2.Thenetworkgraphisreportedinthenextfigure.

(a)

(b)

Figure23NItopology(20nodes)andbandwidthavailability(a),linkdelay(b)

18 8 14 14

Node 1

Node 2 Node 3 Node 4 Node 5

24 45 27

18 27

Node 1

Node 2 Node 3

Node 4 Node 5

Node 6

72 112 96 80

Node 1

Node 2 Node 3 Node 4 Node 5

356 619

207

2369

507 1198 535 168

1894

1055

2919

1250 527

1052

2325

3498

2459

1240

2123 3381

806

1074

1243

2808

1471 956

1012

532

388 1108

197

4565

502

146 2415

1319

547

1177

579

131

1178

220

4606

1048

Node 1

Node 2

Node 3

Node 4

Node 5

Node 6

Node 7

Node 8

Node 9

Node 10

Node 11 Node 12

Node 13

Node 14

Node 15

Node 16

Node 17

Node 18

Node 19

Node 20

34 27

34

26

29 15 27 5

21

32

16

37 32

16

39

15

13

5

27 28

28

14

39

19

28 16

29

27

38 15

34

33

36

33 22

28

17

13

38

24

11

12

25

19

Node 1

Node 2

Node 3

Node 4

Node 5

Node 6

Node 7

Node 8

Node 9

Node 10

Node 11 Node 12

Node 13

Node 14

Node 15

Node 16

Node 17

Node 18

Node 19

Node 20


©T-NOVAConsortium

60

Thefigurebelowreportstheresultingacceptancerateasafunctionoftheloadofrequests,definedastheratiobetweentheaveragecumulativeresourcesaskedtothetotalavailableresources.WerefertothePoPload.Tocomputetheaveragecumulativeresourcesasked,werefer to the Little law [42], according to which the average number of NSs outstandingrequestsisequaltotheaveragearrivalratetimestheaveragedwellingtime(whichisinturngivenbytheratioofthearrivalratetothedeparturerate,forPoissondistributions).Thefigurereports the acceptance rate for the three NSs. The reward function in this test is set tomaximiseNSs acceptance.As for thepreviousVNF case, the rates aredecreasing and theheaviestNSisassociatedwiththelowestacceptancerate.

Figure24.Acceptancerateinfunctionoftheload(samerewardforallNStypes)

Concluding,theabovesimulationshaveshowntheapplicabilityofthereinforcementlearningconcepttotheservicemappingproblem,withencouragingresultswhichshowthatlearningsystems’dynamicsallowstoeffectivelyimplementaformoflookaheadproperty13differentfrom the one previously discussed in literature [16],which consisted “simply” inmappingtogethermorethanonerequest.

Futureresearchworkwillregardinparticular:

• Investigationofnewdefinitionsforthestatespace,inorderto:(i)improvescalabilitythroughimprovedstateaggregation,(ii)improvethedetailsontheactualstateoftheinfrastructureconveyedbythestatedefinition.

• Investigatenewdefinitionsfortherewardfunction,inlinewiththegoalsoftheactorsinvolved.

• Investigate possible combinations with the ILP approaches proposed in thisdeliverable.

13Thatis,theabilityofamappingalgorithmtomapmorethanonerequestatthesametime.

0 0.2 0.4 0.6 0.8 1 1.2

20

40

60

80

100

Load Factor

Acce

ptan

ce ra

te [%

]

NS1NS2NS3


©T-NOVAConsortium

61

5.3. Multi-stageNetworkServiceEmbedding

Inthissection,weevaluatetheefficiencyoftheproposedtwo-stageservicechainembeddingapproach.We particularly focus on the ILP-basedweight-minimized service chain requestpartitioningforwhichweemploytheIBMILOGCPLEXoptimizer.Inaddition,weuseagreedyalgorithmasbaseline.ThisalgorithmbindseachNFwithoneoftheend-points,dependingonthe NF location constraint or the order in the service chain (for NFs without locationdependencies),andassignseachNFtotheDCwhichismostproximatetothecorrespondingend-point.Werunsimulationswith50homogeneousDCs,eachcontaining200servers.Wegeneratedservicechainswitheach10to20NFsandasourcetrafficrateof10to100Mbps.Figure 25 depicts the evolution of load balancing level across the DCs. Since the greedyselectionofDCsclosetotheend-pointsdoesnotleadtoloadbalancing14,wefocusontheload balancing level of the ILP variant. According to Figure 25, weight-minimized requestpartitioningconvergestonear-optimalloadbalancingafter100Krequests,exploitingtheDCutilizationlevelsdisclosedviathelinkweights.Morespecifically,after250Krequeststhehighestserverloadis5.3%abovetheaverageDCutilizationforweight-minimizedrequestpartitioning.

Figure25:LoadbalancinglevelacrosstheDCserverswithweight-minimizedrequestpartitioning

Figure26showstherequestacceptanceratesfortheweight-minimizedandforthegreedyrequestpartitioningmethods.OptimizingDCselectionbasedonthedisclosedweightsinhibitsthe assignment of NF-subgraphs to highly utilized DCs, which usually leads to requestrejections.Assuch,weight-minimizedrequestpartitioningyieldsahigherrequestacceptancerate while the greedy algorithm suffers from a large number of rejections, due to therestrictionsinDCselection.

14TheDCloadbalancingfactorisdefinedbythemaximumovertheaverageserverutilization.

0K 50K 100K 150K 200K 250K1

1.2

1.4

1.6

1.8

2

2.2

2.4

2.6

2.8

3

3.2

3.4

# service chain request

DC

load

bal

anci

ng fa

ctor

Min-W


©T-NOVAConsortium

62

Figure26:Acceptanceratewithweight-minimizedandgreedyrequestpartitioning

Figure26andFigure27showastrongcorrelationbetweentheacceptancerateandgeneratedrevenue.The ILPvariantgenerates substantiallyhigher revenue fromCPUandbandwidth,comparedtothegreedyalgorithm.Thehighacceptanceratewithweight-minimizedrequestpartitioning translates to higher revenuewhich is up to three times higher thanwith thegreedy variant. This essentially designates weight-minimized request partitioning as thepreferredmethod.

Figure27:Cumulativerevenuewithweight-minimizedandgreedyrequestpartitioning

Finally,wemeasuretheacceptancerateofweight-minimizedrequestpartitioningwith250Kexpiring requests and diverse arrival rates. Figure 28 shows that acceptance rates alwaysconverge toa steady state.This further indicates theefficiencyof theproposed ILP-basedmethodsforservicechainembeddingacrossmultipleDCs.

0K 50K 100K 150K 200K 250K0

102030405060708090

100


acce

ptan

ce ra

te (%

)

Min-WGreedy

0K 50K 100K 150K 200K 250K0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

5.5

6 x 105

cum

ulat

ive

reve

nue

gene

rate

d fro

m C

PU (G

Hz)


0K 50K 100K 150K 200K 250K0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

5.5

6x 107

... a

nd fr

om b

andw

idth

(Mbp

s)Min-W CPUGreedy CPUMin-W BWGreedy BW


©T-NOVAConsortium

63

Figure28:Acceptanceratewithdiversearrivalratesofexpiringservicechainrequestswithweight

0K 50K 100K 150K 200K 250K80

82

84

86

88

90

92

94

96

98

100


acce

ptan

ce ra

te (%

)

AR 15/minAR 20/minAR 25/min


©T-NOVAConsortium

64

6. CONCLUSIONS

ThisdeliverablehasreportedtheoutcomesoftheTask3.3“ServiceMapping”oftheT-NOVAproject.

TheservicemappingproblemhasbeenputintothecontextofthearchitecturedevelopedinT-NOVAforvirtualizednetworkfunctionorchestration,andacommonmodellingframeworkforthefirstlevelmappingproblem(i.e.mappingofvirtualnetworkfunctionstodatacentres)and the second level mapping problem (i.e. assignment of virtual machines to hardwaredevices inside the data centre) has been proposed, based on graph theory. Differentmathematicalmethodologiesforservicemappinghavebeenexplored,mainlyborrowingfrompure mathematical optimization theory (integer linear optimization) and from stochasticcontroltheory(reinforcementlearning).Thepropertiesofsuchproposedmappingalgorithmshavebeendiscussedbymeansofsimulationscarriedoutinemulatedenvironment.

A second key outcomeof the Task 3.3, reported in this deliverable, is the design and theintegrationoftheservicemappingmodule(themoduleactuallyhostingtheservicemappingalgorithm)intheT-NOVAsystem.Akeyoutcomeoftheintegrationdesignisthatthemappingmodulecanpotentiallyintegratedifferentmappingalgorithms,providedthattheycomplytothedocumentedinterfacesspecifications.Suchinterfacesmainlyregardtheinteractionofthemodulewiththeinfrastructurerepositoryandwiththeservicecatalogue,whicharethetwokeysubsystemsproviding inputs to themappingproblem.The integer linearprogrammingapproachproposedbyUnimihasbeenintegratedinTeNOR,theT-NOVAorchestrator.Theintegration has been first tested on a mock-up system, built based on the interfacesspecification,andthenintegratedintotheactualT-NOVAsystem.

The integration and implementation style adopted and the results of algorithms researchopenthewayforfurtherpromisingworks.Asmentioned,thesobuiltplatformallowstoeasilyintegrate advancements in the mapping algorithms, which are possible especially in thedirection of integrating the theoretical approaches presented (exact optimization versusstochasticcontrol)towardsanenhancedalgorithm.Suchenhancedalgorithmcouldcapturethestrengthsofboththetheoreticalapproaches,thatis,(i)theabilityofexactmethodstoaccurately tackle the service and infrastructure requirements, thanks to the inclusion ofrelated constraints, and, (ii) the ability of the stochastic methods to learn environmentdynamicsinordertocameupwithmappingdecisionsthataccountforthebehaviourofthesysteminthelongrun.


©T-NOVAConsortium

65

7. REFERENCES

[1] T-NOVAConsortium,“DeliverableD2.1SystemUseCasesandRequirements.”pp.1–62,2014.

[2] EuropeanTelecommunicationsStandardsInstitute(ETSI),“GSNFV-MAN001-V1.1.1-NetworkFunctionsVirtualisation(NFV);ManagementandOrchestration,”vol.1,pp.1–184,2014.

[3] T-NOVA Consortium, “Deliverable D3.01 Interim Report on Orchestrator PlatformImplementation.”pp.1–92,2014.

[4] European Telecommunications Standards Institute (ETSI), “Network FunctionsVirtualisation(NFV);ArchitecturalFramework,”vol.1,pp.1–21,2013.

[5] European Telecommunications Standards Institute (ETSI), “Network FunctionsVirtualisation(NFV);TerminologyforMainConcepts inNFV,”vol.1,no.ETSIGSNFV003V1.2.1,pp.1–13,2014.

[6] European Telecommunications Standards Institute (ETSI), “Network FunctionsVirtualisation(NFV);UseCases,”ETSIGSNFV001V1.1.1,pp.1–50,2013.

[7] H.Ballani,P.Costa,T.Karagiannis,andA.Rowstron,“Towardspredictabledatacenternetworks,”ACMSIGCOMMComput.Commun.Rev.,vol.41,no.4,p.242,2011.

[8] J.Lee,M.Lee,L.Popa,Y.Turner,S.Banerjee,P.Sharma,B.Stephenson,J.C.Mogul,J.Mudigonda, J. R. Santos, H. P. Labs, and P. Alto, “CloudMirror : Application-AwareBandwidthReservationsintheCloud,”inProceedingsofthe5thUSENIXWorkshoponHotTopicsinCloudComputing,2013,pp.1–6.

[9] C. Guo, G. Lu, H. J. H. J. Wang, S. Yang, C. Kong, P. Sun, W. Wu, and Y. Zhang,“SecondNet: a data center network virtualization architecture with bandwidthguarantees,” inProceedingsof the6th InternationalConference, 2010,no.Vdc,pp.15:1–15:12.

[10] A. Gember, R. Grandl, and A. Anand, “Stratos: Virtual middleboxes as first-classentities,”ONSsummit,2013.

[11] S.OechsnerandA.Ripke,“FlexibleSupportofVNFPlacementFunctionsinOpenStack,”inProceedingsofthe20151stIEEEConferenceonNetworkSoftwarization(NetSoft),2015,pp.1–6.

[12] A.Fischer,J.F.Botero,M.T.Beck,H.DeMeer,andX.Hesselbach,“Virtualnetworkembedding:Asurvey,” IEEECommun.Surv.Tutorials,vol.15,no.4,pp.1888–1906,2013.

[13] H.Xin,S.Ganapathy,andT.Wolf,“Ascalabledistributedroutingprotocolfornetworkswith data-path services,” in Proceedings - International Conference on NetworkProtocols,ICNP,2008,pp.318–327.

[14] A.AbujodaandP.Papadimitriou,“MIDAS:Middleboxdiscoveryandselectionforon-path flow processing,” in 2015 7th International Conference on CommunicationSystemsandNetworks(COMSNETS),2015,pp.1–8.

[15] R.Riggio,T.Rasheed,andR.Narayanan,“VirtualNetworkFunctionsOrchestrationinEnterprise WLANs,” in Integrated Network Management (IM), 2015 IFIP/IEEEInternationalSymposiumon,2015,pp.1220–1225.


©T-NOVAConsortium

66

[16] R. Guerzoni, R. Trivisonno, I. Vaishnavi, Z. Despotovic, A. Hecker, S. Beker, and D.Soldani,“AnovelapproachtovirtualnetworksembeddingforSDNmanagementandorchestration,” in Proceedings of the Network Operations and ManagementSymposium(NOMS),2014,pp.1–7.

[17] S. Sahhaf,W. Tavernier, D. Colle, andM. Pickavet, “Network service chainingwithefficientnetworkfunctionmappingbasedonservicedecompositions,”inProceedingsofthe20151stIEEEConferenceonNetworkSoftwarization(NetSoft),2015.

[18] S. Sahhaf,W. Tavernier, D. Colle, andM. Pickavet, “Network service chainingwithefficient network function mapping based on service decompositions,” Comput.Networks,vol.93,pp.492–505,2015.

[19] S. Mehraghdam, M. Keller, and H. Karl, “Specifying and Placing Chains of VirtualNetworkFunctions,”arXivPrepr.arXiv1406.1058,vol.22,no.5,pp.20–25,2014.

[20] V.Abedifar,M.Eshghi,S.Mirjalili,andS.M.Mirjalili,“AnoptimizedvirtualnetworkmappingusingPSOincloudcomputing,”in201321stIranianConferenceonElectricalEngineering(ICEE),2013,pp.1–6.

[21] K. Giotis, Y. Kryftis, and V.Maglaris, “Policy-based orchestration ofNFV services inSoftware-Defined Networks,” in Proceedings of the 2015 1st IEEE Conference onNetworkSoftwarization(NetSoft),2015,pp.1–5.

[22] T-NOVAConsortium,“T-NOVADocumentofWork.”pp.1–164,2013.

[23] R.Mijumbi,J.Serrat,J.L.Gorricho,N.Bouten,F.DeTurck,andR.Boutaba,“NetworkFunction Virtualization: State-of-the-art and Research Challenges,” IEEE Commun.Surv.Tutorials,no.c,pp.1–28,2015.

[24] D.Dietrich,A.Rizk,andP.Papadimitriou,“Multi-domainvirtualnetworkembeddingwithlimitedinformationdisclosure,”IEEETrans.Netw.Serv.Manag.,vol.12,no.2,pp.188–201,2015.

[25] J.F.Riera,X.Hesselbach,E.Escalona,J.A.García-espín,andE.Grasa,“OntheComplexSchedulingFormulationofVirtualNetworkFunctionsoverOpticalNetworks,”in16thInternationalConferenceonTransparentOpticalNetworks(ICTON’14),2014,pp.1–5.

[26] S.Battilotti,F.Facchinei,A.Giuseppi,G.Oddi,A.Pietrabissa,andV.Suraci,“ResourceManagement in Multi-Cloud Scenarios via Reinforcement,” in Control Conference(CCC),201534thChinese,2015,pp.9084–9089.

[27] J.Riera,J.Batallé,J.Bonnet,M.Días,M.J.McGrath,G.Petralia,F.Liberati,A.Giuseppi,A.Pietrabissa,A.Ceselli,A.Petrini,M.Trubian,P.Papadimitrou,D.Dietrich,A.Ramos,M.Javier,G.Xilouris,A.Kourtis,T.Kourtis,andM.Evangelos,“TeNOR-AResourceandServiceMappingApproachtoOrchestratingVNFDeployments,” inSubmittedtotheProceedings of the 2016 2nd IEEE Conference onNetwork Softwarization (NetSoft),2016.

[28] Openstack, “Scheduling,” 2015. [Online]. Available:http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html.

[29] R.S.SuttonandA.G.Barto,ReinforcementLearning:An Introduction, vol.3,no.9.CambridgeMA:TheMITPress,2012.

[30] M.L.Puterman,Markovdecisionprocesses:discretestochasticdynamicprogramming.JohnWiley&Sons,2014.


©T-NOVAConsortium

67

[31] D.Dietrich,A.Abujoda, andP.Papadimitriou, “EmbeddingNetworkServicesacrossMultipleProviderswithNestor,”inProc.IFIPNetworking,2015.

[32] A.FarrelandJ.P.Vasseur,“RFC4655,”Netw.Work.Gr.,no.1,pp.1–5,2006.

[33] J.Batallé,J.Ferrer-Riera,E.Escalona,andJ.A.García-Espín,“OntheimplementationofNFVoveranOpenFlowinfrastructure :RoutingFunctionVirtualization,” inFutureNetworksandServices(SDN4FNS),2013IEEESDN,2013,pp.1–6.

[34] J. F. Riera, E. Escalona, J. Batalle, E. Grasa, and J. A.Garcia-Espin, “Virtual networkfunction scheduling: Concept and challenges,” in 2014 International Conference onSmartCommunicationsinNetworkTechnologies(SaCoNeT),2014,pp.1–5.

[35] R.Mijumbi, J. Serrat, J.Gorricho,N.Bouten, F.DeTurck, and S.Davy, “DesignandEvaluationofAlgorithmsforMappingandSchedulingofVirtualNetworkFunctions,”inProceedings of the 2015 1st IEEE Conference on Network Softwarization (NetSoft),2015.

[36] “Ruby Programming Language,” 2015. [Online]. Available: https://www.ruby-lang.org/.[Accessed:15-Dec-2015].

[37] T-NOVAConsortium,“Deliverable3.2InfrastructureResourceRepository.”pp.1–105,2015.

[38] T-NOVAConsortium,“Deliverable6.4SLAsandBilling.”2015.

[39] T-NOVAConsortium,“DeliverableD6.1ServiceDescriptionFramework.”2015.

[40] Algorithms and complexity group, “Virtual Network Mapping Problem Instances,”2015.[Online].Available:https://www.ac.tuwien.ac.at/research/problem-instances/.[Accessed:15-Dec-2015].

[41] J. Zhu, “Benchmarking Virtual Network Mapping Algorithms,” University ofMassachusetts-Amherst,2014.

[42] J.D.C.LittleandS.C.Graves,“Chapter5Little’sLaw,”Oper.Manag.,vol.115,pp.81–100,2008.


©T-NOVAConsortium

68

8. LISTOFACRONYMS

Acronym Explanation

API ApplicationProgrammingInterface

CIMI CloudInfrastructureManagementInterface

DAG DirectedAcyclicGraph

DC Datacenter

DMI DesktopManagementInterface

DMTF DistributedManagementTaskForce

DPDK DataPlaneDevelopmentKit

EPA EnhancedPlatformAwareness

ETSI EuropeanTelecommunicationsStandardsInstitute

GPU GraphicsProcessingUnit

GW Gateway

HDFS HighlyDistributedFileSystem

HTTP Hyper-TextTransferProtocol

ILP IntegerLinearProgramming

IPMI IntelligentPlatformManagementInterface

IVM InfrastructureVirtualisationandManagement

JSON JavaScriptObjectNotation

MANO (ETSINFV)ManagementandOrchestration

MDP MarkovDecisionProblem

MIF ManagementInformationFormat

MIP MixedIntegerProgramming

ML ModularLayer

MPL MathematicalProgrammingLanguage

NAT NetworkAddressTranslator

NF NetworkFunction

NFS,NFStore

NetworkFunctionStore

NFV NetworkFunctionsVirtualization

NI NetworkInfrastructure

NIC NetworkInterfaceController

NS NetworkService

NSD NetworkServiceDescriptor


©T-NOVAConsortium

69

Or-Vi InterfacebetweentheOrchestratorandtheVIM

PoP PointofPresence

QoS QualityofService

RCSP ResourceConstrainedProjectSchedulingProblem

REST RepresentationalStateTransfer

SLA ServiceLevelAgreement

SM Servicemapping

SMM ServicemappingModule

SP ServiceProvider

SR-IOV SingleRootI/OVirtualization

T-Ac-Or InterfacebetweenT-NOVAAccounting (Marketplacemodule)and theOrchestrator

T-Br-Or Interface between T-NOVA Brokerage (Marketplace module) and theOrchestrator

T-Da-Or Interface between T-NOVADashboard (Marketplacemodule) and theOrchestrator

T-Sla-Or Interface between T-NOVA Servile Level Agreement (Marketplacemodule)andtheOrchestrator

UC UseCase

VCPU VirtualCPU

VDU VirtualisationDeploymentUnit

VIM VirtualInfrastructureManager

VM VirtualMachine

VN VirtualNetwork

VNE VirtualNetworkEmbedding

VNF VirtualNetworkFunction

VNFc VirtualNetworkFunctioncomponent

VNFD VirtualNetworkFunctionDescriptor

VNFM VirtualNetworkFunctionManager

Vnfm-Vnf InterfacebetweentheVNFManagerandVNFs

vNIC virtualNetworkInterfaceController


©T-NOVAConsortium

70

9. LISTOFMATHEMATICALSYMBOLS

Symbol Definition/Explanation

𝐴 Setof linksofthegraph𝐺 𝑁𝑆 ,modellingthesetof linksamongtheVNFscomposingtheNS.

𝐴5 Setoflinksofthegraph𝐺 𝐷𝐶 ,modellingtheconnectionsamongthePoPapparatuses.

𝐴2 Setoflinksofthegraph𝐺 𝑉𝑁𝐹 ,modellingthesetoflinksamongtheVNFccomposingtheVNF.

𝐴. Setoflinksofthegraph𝐺 𝑁𝐼 ,modellingthesetoflinksamongthePoPscomposingtheNI.

𝛼 Weighting parameter of the target function of the proposed ILPmappingapproach.

𝐴𝑐𝑡 Space of the possible mapping actions (reinforcement learningapproach)

𝛽 Weighting parameter of the target function of the proposed ILPmappingapproach.

𝑐C? CostofassigningtheVNFℎtothePoP𝑝

𝛿CD Delayassociatedwitheacharch(𝑝, 𝑞)in𝐺 𝑁𝐼 .

ΔS Maximumalloweddelayassociatedtoeachpathπ∈P.

𝑓CD?@ Amountofflowoverthelink(p,q)fortheNF-graphedge(h,k).

𝛾 Weighting parameter of the target function of the proposed ILPmappingapproach.

𝐺(𝐷𝐶) = (𝑉5, 𝐴5)

GraphmodellingeachPoPinfrastructure.

𝐺 𝑁𝐼 = (𝑉., 𝐴.) GraphmodellingtheNetworkInfrastructure.

𝐺 𝑁𝑆 = (𝑉, 𝐴) GraphmodellingtheNetworkService.

𝐺(𝑉𝑁𝐹)=(𝑉2, 𝐴2) GraphmodellingtheVirtualNetworkFunction.

𝜆 LearningrateoftheQ-Learningupdaterule.

𝑁𝑇 SetofresourcetypesavailableatNetworkInfrastructurenodes.

𝑃 ThesetofpathsconnectingpairsofVNFsinaNS.

π∈P Genericpathin𝑃(i.e.sequenceofarcsinthegraph𝐺 𝑁𝑆 ).

Π Policy function providing a mapping of states to actions (i.e.Π(s,a) denotes the probability that action 𝑎 is taken when thesystemisinstate𝑠.

𝑄S(𝑠, 𝑎) State-actionvaluefunction.Estimateofthevalueassociatedtothestate-action couple (𝑠, 𝑎) (i.e. expected future reward achievedwhenstartingfromstate𝑠,takingaction𝑎andfollowingpolicyΠ).


©T-NOVAConsortium

71

𝑟 Reward function associated with the Markov decision processdefinedfortheSMapproachbasedonreinforcementlearning.

𝑅𝐴C< Amountofresourcesoftype𝑡 ∈ 𝑁𝑇availableatPoPnode𝑝 ∈ 𝑉..

𝑅𝐴CD< Amount of resources of type 𝑡 ∈ 𝑁𝑇 available at NetworkInfrastructurelink(𝑝, 𝑞) ∈ 𝐴..

𝑅𝑅?< Amountofresourcesoftype𝑡 ∈ 𝑁𝑇requiredbyVNFnodeℎ ∈ 𝑉.

𝑅𝑅?@< Amountofresourcesoftype𝑡 ∈ 𝑁𝑇requiredbyVNFlink(ℎ, 𝑘) ∈𝐴.

𝑆 State space of the Markov decision process defined for the SMapproachbasedonreinforcementlearning.

𝑇 StatetransitionmatrixcharacterizingtheMarkovdecisionprocessdefinedfortheSMapproachbasedonreinforcementlearning.

Τ Time horizon over which the reinforcement learning problem isdefined.

𝑡 𝑠, 𝑎, 𝑠± ∈ 𝑇 Probability to go to state 𝑠’ when starting from state 𝑠 andperformingaction𝑎

𝑉 Set of vertices of the graph 𝐺 𝑁𝑆 , modelling the set of VNFscomposingtheNS.

𝑉5 Set of vertices of the graph 𝐺 𝐷𝐶 , modelling the connectionsamongtheapparatusesofthePoP.

𝑉2 Set of vertices of the graph𝐺 𝑉𝑁𝐹 , modelling the set of VNFccomposingtheVNF.

𝑉. Setofverticesofthegraph𝐺 𝑁𝐼 ,modellingthesetofPoPsintheNetworkInfrastructure.

𝑉i(𝑠) Value function. Estimate of the value associated to state 𝑠 (i.e.expected future rewardachievedwhen starting from state𝑠 andfollowingpolicyΠ)

𝑤CD Weightvalueassociatedwithlink(p,q).

𝑥CD?@ Binarydecisionvariable.𝑥CD?@ = 1ifthelink(ℎ, 𝑘)ingraph𝐺(𝑁𝑆)ismappedonapath inthe infrastructurewhichpassesthroughthelink(𝑝, 𝑞)ofgraph𝐺(𝑁𝐼).

𝑦C? Binarydecisionvariable.𝑦C? = 1ifVNFℎisassignedtoPoP𝑝.

𝑧C Binarydecisionvariable.𝑧C = 1ifserverpisused.


©T-NOVAConsortium

72

Annexes


©T-NOVAConsortium

73

10. ANNEXA:DOCUMENTATIONOFTHESERVICEMAPPINGMODULEAPI

This annex reports a documentation of the REST API of the developed service mappingmodule. TheAPIprovides to theorchestrator theaccess to the servicemappingmodule’sservices.

Theinformationprovidedmaybesubjecttofuturechangesastheintegration,deploymentandtestingworkisrefinedduringthecourseoftheproject.

SupportedHTTPMethod

POST

CurrentAcceptedRequestParameters

Theacceptedparametersarereportedinthetablebelow.

Table15Servicemappingrequestparameters(bodyofthePOSTcall)

Name Description Example

NS_id Id of the Network Service to be instantiated "NS_id" = "demo1"

NS_sla Flavour of the Network Service to be instantiated "NS_sla" = "gold"

tenor_api Address of the Tenor API "tenor_api" = "http://1.2.3.4:5544"

infr_repo_api Address of the Infrastructure Repository "infr_repo_api" = "http://1.2.3.4:5544"

ir_simulation If true, dummy IR data is used for testing purpose "ir_simulation" = "false"

ns_simulation If true, dummy NS data is used for testing purpose "ns_simulation" = "false"


©T-NOVAConsortium

74

alpha Optional parameter to be passed to the solutor: weight of alpha parameter in objective function (see notes)

"Alpha" = "0.6"

beta Optional parameter to be passed to the solutor: weight of beta parameter in objective function (see notes)

"Beta" = "0.25"

gamma Optional parameter to be passed to the solutor: weight of gamma parameter in objective function (see notes)

"Gamma" = "0.15"

fixVnf01 Optional parameter that forces the allocation of the first VNF of the NS to the PoP specified by the "toPoP01" parameter (for testing purpose)

"fixVnf01" = "vnf_id_a012fe31"

toPoP01 Optional parameter that states in which PoP should be allocated the VNF specified by the "fixVnf01" parameters (for testing purpose)

"toPoP01" = "126594f3a2a1"

solver Chooses the solver application "solver" = "unimi"

NotesonAlpha,BetaandGammaparameters:theseoptionalkey/valuepairsarepassedbytheOrchestratortotheUniMisolverandtheyareusedasweightsforthethreecomponentsof the objective function. By altering the default values, the solver tries to optimize theallocationoftheVNFsothatcostisminimized(alpha>gamma+beta),theaggregatedelayisminimized(beta>alpha+gamma)orthenumberofinfrastructurelinksfortheallocationofeachNSpathisminimized(gamma>alpha+beta).

RequestPayloadExample

{ "NS_id":"demo1", "NS_sla":"gold", "tenor_api":"http://10.20.30.40:5454", "infr_repo_api":"http://1.2.3.4:5544", "ir_simulation":"true", "ns_simulation":"false", "solver":"unimi", "Alpha":"0.5", "Beta":"0.3", "Gamma":"0.2", "fixVnf01":"",

"toPoP01":""


©T-NOVAConsortium

75

}

ReturnValueExample(successfulmapping)

{ "status": 0, "created_at":"Thu Nov 5 10:13:25 2015", "links_mapping": [ { "vld_id":"vld0", "maps_to_link":"/pop/link/85b0bc31-dff0-4399-8435-4fb2ed65790a", }, { "vld_id":"vld1", "maps_to_link":"/pop/link/85b0bc32-dff0-4399-8435-4fb2ed65790a", }, { "vld_id":"vld0", "maps_to_link":"/pop/link/85b0bc33-dff0-4399-8435-4fb2ed65790a", }, { "vld_id":"vld1", "maps_to_link":"/pop/link/85b0bc34-dff0-4399-8435-4fb2ed65790a", } ], "vnf_mapping": [ { "maps_to_PoP":"/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f7", "vnf":"vnf_demo1_0" }, { "maps_to_PoP":"/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f7", "vnf":"vnf_demo1_1" }, { "maps_to_PoP":"/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f6", "vnf":"vnf_demo1_2" } ]

}

ReturnValueExample(mappingfailure)


©T-NOVAConsortium

76

{ "status": 1, "error":"Error in MIP problem", "info":"MIP solution is undefined", "created_at":"Thu Nov 5 10:11:37 2015"

}

ReturnValueCodes

Allreturnmessagesareinjsonformatand,withtheonlyexceptionforreturncode0,eachmessagehasthekeys"status"(anumericalvalue)andanassociated"error"(astring).Thecompletelistofstatusesanderrorsisthefollowing:

Status Error Description

0 - All ok / valid mapping found

1 "No feasible solution found" The solver was unable to find a feasible solution

-1 "No matching NSd in NS catalog" -

-2 "No matching SLA in NSd" -

-3 "No matching VNFd in VNF catalog" -

-4 "No matching flavour in vnf.deployment_flavour"

-

-60 "No matching NSd in dummy NS catalog" -

-61 "No matching VNFd in dummy VNF catalog"

-

-120 "NS.json not found / not generated" -

-121 "NI.json not found / not generated" -

-122 "Invalid json request: no ns_id found" -


©T-NOVAConsortium

77

11. ANNEXB:DETAILSONINFRASTRUCTUREREPOSITORYQUERYING

Detailsonthesequenceofactionsperformedforqueryingtheinfrastructurerepositoryarereportedinthetablebelow.

AnexampleoftheresultingJSONfilestoringthequeriedparametersisreported(i.e.NI.jsonfile).

Table16Sequentialstepsinqueryingtheinfrastructurerepository

Task Description

ir_simulation == true? § Check if ir_simulation is true

§ set ir_simulation_requested accordingly

request PoP list § GET to /pop/ to retrieve list of PoP;

§ store list to pop_id_array

request PoP detail

§ for each pop, GET to /pop/<pop-id> to retrieve the deatil of PoP

§ clear unused PoP information

§ store PoP status in pop_detail_array

request link list § GET to /pop/link to retrieve list of links between PoPs

§ store list to pop_link_id_array

request link detail

§ for each link, GET to /pop/link/<link-id> to retrieve the detail of link

§ store link status in pop_link_detail_array

§ convert both bw_Gps and bw_util_Gps into Mbps (modyfing the key

accordingly)

§ note that available bw will be calculate as the difference between

occi.epa.pop.bw_Mbps and occi.epa.pop.bw_util_Mbps

§ also, link delay will be extracted from

occi.epa.pop.roundtrip_time_sec

request list of hypervisors

§ for each PoP, GET to /pop/<pop-id>/hypervisor to retrieve the list of

the hypervisors

§ store everything in the hash of arrays hypervisors_list_hash

collect data from each hypervisor and build the aggregate resource of each PoP

§ for each PoP, for each hypervisor in this pop, GET to /pop/<pop-

id>/hypervisor/<hypervisor_id> to retrieve the hypervisor detail

§ from this hypervisor detail extract the data:

§ cpus = attributes -> occi.epa.attributes -> vcpus


©T-NOVAConsortium

78

§ vcpu_used = attributes -> occi.epa.attributes -> vcpu_used

§ ram = attributes -> occi.epa.attributes -> memory_mb

§ ram_used = attributes -> occi.epa.attributes ->

memory_mb_used

§ hdd = attributes -> occi.epa.attributes -> local_gb

§ hdd_used = attributes -> occi.epa.attributes -> local_gb_used

§ calculate the amount of free resource as algebraic difference and

accumulate on PoP basis

§ count the how many cpu have the AES-NI acceleration from

attributes -> occi.epa.attributes -> cpu_info -> features

§ save free resources of each PoP into hypervisors_detail_hash

collect GPU / DPDK data

§ for each PoP_id: GET to /pop/<pop-id>/pcidev/?dpdk=true to get list

of DPDK-enabled NIcs

§ store number of DPDK-enabled NICs in PoP_aggregate_resources -

> dpdk_nic_count

§ for each PoP_id: GET to /pop/<pop-id>/osdev/?category=compute to

get list of GPUs (actually, compute devices?)

§ store number of GPUs in PoP_aggregate_resources -> gpu_count

create final hash and save to disk

§ create a new hash containing pop_id_array, pop_detail_array,

pop_link_id_array, pop_link_detail_array, hypervisors_detail_hash

§ save to disk the hash in json format. create NI.json

An example of the resulting JSON file storing the queried parameters is reported in thefollowing(i.e.NI.jsonfile).

{ "PoP_id": [ "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f4", "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f5" ], "PoP_detail": [ { "attributes": { "occi.epa.pop.graph_db_url": "http://neo4j:[email protected]:7474/db/data/", "occi.epa.pop.lat": "53.3720513", "occi.epa.pop.lon": "-6.5130686999999625", "occi.epa.pop.name": "Intel Ireland's Leixlip Campus, Kildare, Ireland", "occi.epa.pop.odl_name": "admin",

"occi.epa.pop.odl_password": "admin",


©T-NOVAConsortium

79

"occi.epa.pop.odl_url": "http://134.191.243.7:9001/restconf/operational/", "occi.epa.timestamp": 1434538341.071382 }, "identifier": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f4", "links": [ ] }, { "attributes": { "occi.epa.pop.graph_db_url": "http://neo4j:[email protected]:7474/db/data/", "occi.epa.pop.lat": "23.3727512", "occi.epa.pop.lon": "18.5199025", "occi.epa.pop.name": "Googre Corporation, datacenter 00f3a", "occi.epa.pop.odl_name": "admin", "occi.epa.pop.odl_password": "admin", "occi.epa.pop.odl_url": "http://134.191.243.7:9001/restconf/operational/", "occi.epa.timestamp": 1434449042.2 }, "identifier": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f5", "links": [ ] } ], "PoP_link_id": [ "/pop/link/85b0bc27-dff0-4399-8435-4fb2ed65790a", "/pop/link/85b0bc28-dff0-4399-8435-4fb2ed65790a" ], "PoP_link_detail": [ { "attributes": { "occi.epa.label": "is_connected_to", "occi.epa.pop.bw_Mbps": 102400, "occi.epa.pop.bw_util_Mbps": 19420, "occi.epa.pop.destination": "200.202.200.5", "occi.epa.pop.interface": "Interface0", "occi.epa.pop.ip_address": "200.202.200.4", "occi.epa.pop.netmask": "255.255.255.0", "occi.epa.pop.protocol": "MPLS", "occi.epa.pop.roundtrip_time_sec": "0.021", "occi.epa.pop.source": "Ethernet", "occi.epa.pop.type": "Egress", "occi.epa.timestamp": 1434701892.961004 }, "identifier": "/pop/link/85b0bc27-dff0-4399-8435-4fb2ed65790a", "source": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f4",

"target": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f5"


©T-NOVAConsortium

80

}, { "attributes": { "occi.epa.label": "is_connected_to", "occi.epa.pop.bw_Mbps": 102400, "occi.epa.pop.bw_util_Mbps": 15380, "occi.epa.pop.destination": "200.202.200.4", "occi.epa.pop.interface": "Interface0", "occi.epa.pop.ip_address": "200.202.200.5", "occi.epa.pop.netmask": "255.255.255.0", "occi.epa.pop.protocol": "MPLS", "occi.epa.pop.roundtrip_time_sec": "0.023", "occi.epa.pop.source": "Ethernet", "occi.epa.pop.type": "Egress", "occi.epa.timestamp": 1434701892.961004 }, "identifier": "/pop/link/85b0bc28-dff0-4399-8435-4fb2ed65790a", "source": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f5", "target": "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f4" } ], "PoP_aggregate_resources": { "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f4": { "aggregate_cpus": 8, "aggregate_ram": 4096.0, "aggregate_hdd": 160, "aggregate_cpu_accel_aes-ni": 3, "dpdk_nic_count": 2, "gpu_count": 5 }, "/pop/55ef7cce-1e9b-4b8f-9839-d40ceeb670f5": { "aggregate_cpus": 0, "aggregate_ram": 0.0, "aggregate_hdd": -2160, "aggregate_cpu_accel_aes-ni": 3, "dpdk_nic_count": 4, "gpu_count": 2 } }

}


©T-NOVAConsortium

81

12. ANNEXC:DETAILSONTHESERVICECATALOGUEQUERYING

Detailsonthesequenceofactionsperformedforqueryingtheservicecataloguearereportedinthetablebelow.

AnexampleoftheresultingJSONfilestoringthequeriedparametersisreported(i.e.NS.jsonfile).

Table17Sequentialstepsinqueryingtheservicecatalogue

Task Description

set IR and NS/VNF catalog addresses

§ set IR default address

§ set NS base address accordingly to ns_simulation parameter

parse of body request and preliminary check

§ Parse of the request body

§ Check if NS_id is present, return if not

§ Check if NS_sla is present; set ns_sla to "gold" as default

query NS catalog § GET to NS catalog for retrieving the NSd

§ Check if NSd is avaliable in the NS catalog, return if not

store VNF ids associated with selected NS flavour

§ scan nsd -> sla array looking for an id match

§ when found, store for each constituent vnf the

§ nsd -> sla -> constituent_vnf -> vnf_reference

§ nsd -> sla -> constituent_vnf -> vnf_flavour_id_reference

§ nsd -> sla -> constituent_vnf -> number_of_instances

query VNF catalog § -- Loop over constituen_vnfd_array

§ for each vnf_id in constituent_vnf_array: GET to VNF catalog

flavour management

§ scan the vnf -> deployment_flavours array for a match with the

constituent_vnf -> flavour_id

§ once found, store the associated:

§ vdu_name from vnf -> deployment_flavours -> constituent_vdu -

> vdu_reference

§ num_of_vdu_instances from vnf -> deployment_flavours ->

constituent_vdu -> number_of_instances

§ return if no match


©T-NOVAConsortium

82

§ vdu_name is used to reference the correct vdu descriptor associated

to the selected VNF flavor

collect aggregate reqs for each VNF

§ scan vnf -> vdu array for a match with vdu_name from the previous

step

§ once found, collect and aggregate the data

§ tot_cpu with vnf -> vdu -> resource_requirements -> vcpus

§ tot_ram with vnf -> vdu -> resource_requirements -> memory

§ tot_hdd with vnf -> vdu -> resource_requirements -> storage ->

size

§ tot_peak_bw with vnf -> vdu -> networking_resources -> peak

§ tot_aver_bw with vnf -> vdu -> networking_resources -> average

§ max_bw with vnf -> vdu -> resource_requirements ->

network_interface_bandwidth (NOT an aggregate, just max

value)

§ tot_cpu_aesni with vnf -> vdu -> resource_requirements ->

cpu_support_accelerator

§ tot_dpdk with vnf -> vdu -> resource_requirements ->

data_processing_acceleration_library

§ multiply each aggregate data by the number_of_vdus_instance

§ save the aggregate requirements into vnf_requirements array

-- End of loop over constituen_vnfd_array

special requirements management

§ scan and save the special/additional requirements of each VNF, i.e.

GPUs or DPDK-enabled NICs

Forwarding graph management

§ Scan and save into virtual_links_array array the list of virtual links

from nsd -> vld, and extract:

§ virtual_link_id

§ root_requirements (converted in MBps)

§ source

§ destination

§ Scan and save into network_forwarding_paths array the list of

Network Forwarding Paths from nsd -> vnffgds -> vnffgs -> 0 ->

network forwarding path and save:

§ nfp_id

§ nfp_graph (list)

§ connection_points (list)


©T-NOVAConsortium

83

create the ns_out array and fill with data

§ store ns_id in ns_out array

§ store ns_sla in ns_out array

§ store vnf_id array in ns_out array

§ store vnf_req array in ns_out array

§ store virtual_links array in ns_out array

§ store network_forwarding_paths array in ns_out array

collect dynamic parameters passed by the Orchestrator

§ check for "alpha", "beta", "gamma" and all the rest in the request

body

§ store them additional parameter in ns_out array

save data to disk § create NS.json, store ns_out in it and save to disk

AnexampleoftheresultingJSONfilestoringthequeriedparametersisreported(i.e.NS.jsonfile).

{ "ns_id": "demo4", "ns_sla": "gold", "vnf_id": [ "/vnf_demo4_0", "/vnf_demo4_1" ], "vnf_req": [ { "vnf_id": "/vnf_demo4_0", "req_vcpus": 4, "req_ram": 4096.0, "req_hdd": 160.0, "req_nic_bw": 10000, "req_peak_bw": 10, "req_aver_bw": 7, "req_cpu_accel_aes-ni": 1, "req_data_accel_lib_dpdk": 1, "vnf_flavour": "vnfflavourid1", "vnf_num_of_inst": "1" }, { "vnf_id": "/vnf_demo4_1", "req_vcpus": 8, "req_ram": 4096.0, "req_hdd": 160.0, "req_nic_bw": 10000, "req_peak_bw": 10, "req_aver_bw": 7, "req_cpu_accel_aes-ni": 1, "req_data_accel_lib_dpdk": 1,

"vnf_flavour": "vnfflavourid1",


©T-NOVAConsortium

84

"vnf_num_of_inst": "1" } ], "virtual_links": [ { "virtual_link_id": "vld0", "root_requirements": 10000, "source": "data0", "destination": "vnf_demo4_0:data0" }, { "virtual_link_id": "vld1", "root_requirements": 10000, "source": "vnf_demo4_0:data1", "destination": "vnf_demo4_1:data0" }, { "virtual_link_id": "vld2", "root_requirements": 10000, "source": "vnf_demo4_1:data1", "destination": "data1" } ], "network_forwarding_paths": [ { "nfp_id": "nfp0", "nfp_graph": [ "vld0", "vld1", "vld2" ], "connection_points": [ "data0", "data1" ] } ]

}

Documents

Deliverable 3.3 Service Mapping v1.0 - CORDIS · 2017-04-25 · T-NOVA | Deliverable D3.3 Service mapping © T-NOVA Consortium 6 List of Tables Table 1 T-NOVA requirements relevant