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)
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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©T-NOVAConsortium
4
9.LISTOFMATHEMATICALSYMBOLS...............................................................................70
10.ANNEXA:DOCUMENTATIONOFTHESERVICEMAPPINGMODULEAPI.......................73
11.ANNEXB:DETAILSONINFRASTRUCTUREREPOSITORYQUERYING..............................77
12.ANNEXC:DETAILSONTHESERVICECATALOGUEQUERYING.......................................81
T-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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
19 update Q function based on (6)
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-NOVA|DeliverableD3.3 Servicemapping
©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
18 update Q function based on (6)
19 endfor
20 else (i.e. NS termination event)
21 compute state after NS resources are released
22 reward=0
23 update Q function based on (6)
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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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
Identifier Description
name Nameofthemetricvalue RangeofvaluesthemetricshouldtaketomeettheSLA:LT(50)àlowerthan50unit Unitofthevalues:%,Mb,Gb,etcformula FormulathataggregatesthemetricsoftheVNFsinordertocalculatethevalueabove.violations DefinitionofSLAviolations
Table8NSD:SLA:assurance_parameters:violation
Identifier Description
breaches_count
Amountoftimesthethresholdsarebreached
interval Timeinterval
Table9NSD:SLA:constituentVNFs
Identifier Description
vnf_reference ReferencetoaVNFDdeclaredasVNFDinthenetworkserviceviavnf:id.
T-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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
# service chain request
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)
# service chain request
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-NOVA|DeliverableD3.3 Servicemapping
©T-NOVAConsortium
63
Figure28:Acceptanceratewithdiversearrivalratesofexpiringservicechainrequestswithweight
0K 50K 100K 150K 200K 250K80
82
84
86
88
90
92
94
96
98
100
# service chain request
acce
ptan
ce ra
te (%
)
AR 15/minAR 20/minAR 25/min
T-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©T-NOVAConsortium
72
Annexes
T-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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-NOVA|DeliverableD3.3 Servicemapping
©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" ] } ]
}