Guidelines, rules and mechanisms governing the usage of ... · OC3: Guidelines, rules and...
Transcript of Guidelines, rules and mechanisms governing the usage of ... · OC3: Guidelines, rules and...
SoftwareDefinedNetworksandNetworkFunctionVirtualizationTestbedwithinFIRE+
GrantAgreementNº687860
Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbedfortheThirdOpenCall
ExperimentManagementVersion:DueDate:DeliveryDate:Type:DisseminationLevel:Leadpartner:Authors:Internalreviewers:
3.0July21st2017July21st2017Report®PU–PublicAllPartners(Seelistbelow)PMC
Disclaimer
Thisdocumentcontainsmaterial,whichisthecopyrightofcertainSoftFIREconsortiumparties,andmaynotbereproducedorcopiedwithoutpermission.
Thecommercialuseofanyinformationcontainedinthisdocumentmayrequirealicensefromtheproprietorofthatinformation.
Neither the SoftFIRE consortium as a whole, nor a certain part of the SoftFIRE consortium,warrantthattheinformationcontainedinthisdocumentiscapableofuse,northatuseoftheinformationisfreefromrisk,acceptingnoliabilityfor lossordamagesufferedbyanypersonusingthisinformation.
SoftFIRE has received funding from the European Union’sHorizon 2020 research and innovation programme under GrantAgreementno.687860.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page3of49
VersionControl:
Version Date Author Author’sOrganization Changes
0.0 Tuesday, 11April2017
RobertoMinerva EITDigital Modification to D3.3Handbook forexperimenters aboutthe ProgrammingLifeCycle
1.0 21stApril2017 RobertoMinerva EITDigital Added newerdescriptionoftestbeds.Added a table of fullcapabilities
1.1 11May2017 LorenzoTomasini TUB Improvement ofExperiment lifecycledocumentation
1.2 11May2017 BjoernRiemer FOKUS Definition of SDNResources andimprovement ofTestbeddescriptions
1.3 12May2017 LorenzoTomasini TUB Integration of Partnerscontributions
1.4 15May2017 LorenzoTomasini TUB Final version forinternalreview
2.0 15May2017 RobertoMinerva EITDigital FinalEditing
2.1 21stJuly2017 LorenzoTomasini TUB Updateofcontent
2.2 21stJuly2017 MassimilianoRomano
AssemblyDataSystem Testbed List – SDNresources
3.0 21stJuly2017 RobertoMinerva EITDigital Revision andconsolidation
Annexes:
Nº FileName Title
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page4of49
Contributors:
Contributor Partner
GiuseppeCarella TUB
DanieleCarmignani SecurityReply
MariusCorici FOKUS
PeterFeil DeutscheTelekomAG
SusanneKuehrer EITDigital
MarcoMiglione Ericsson
RobertoMinerva TelecomItalia
FabioPaglianti SecurityReply
BjörnRiemer FOKUS
MassimilianoRomano AssemblyDataSystem
UmbertoStravato Ericsson
LorenzoTomasini TUB
SerdarVural UniversityofSurrey
DeliverableTitle: Guidelines, rules and mechanisms governing the usage of theSoftFIRETestbed
DeliverableTopic HandbookforThirdOpenCall
Keywords: NFV,SDN,5G
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page5of49
ExecutiveSummary:SoftFIRE is an experimental federated Testbed aiming at nurturing an ecosystem of organizationswillingtoextend,consolidateandpossibly industrializesolutions intherealmofNFV/SDNsolutionswithaspecificreferencetotheiradoptionin5Garchitectures.
InordertotakeadvantageofSoftFIRE,twokindsoforganizationscouldusetheplatform:
• ThoseselectedbymeansoftheOpenCallsmechanisms• ThoseinterestedinusingtheSoftFIREinfrastructureindependentlyfromtheOpenCallsand
onthebasisofprecisepurposesoftheorganization.
Fromaprogrammingperspective,thetwokindsofrequestswillnotdiffertoomuchandtheywillgothroughsubstantiallythesameguidelinesandmechanisms.Whatwillbedifferentarethetimeframeoftheexperimentationandadifferentlevelofprojectsupport.
ThisdocumentisbasedonDeliverableD3.3(Guidelines,rulesandmechanismsgoverningtheusageof the SoftFIRE Testbed) and it has been update to reflect the current status of the SoftFIREmiddleware. It presents an updated description of the SoftFIRE lifecycle for experimenters withspecific focus on the SoftFIRE Software Portal and the OpenVPN experimenter access. It provideshintsonthelevelofsupportthatSoftFIREwillgenerallyallocatetoorganizationsparticipatingtotheopencalls.Italsodescribeslimitationsandconstraintsforthegeneraluseoftheplatform.
The focus of the document is in providing to programmers and users of the platform a view onmechanismsandpossibilitiesofferedbytheFederatedtestbedandguidethemthroughtheexpectedlifecycleofatypicalexperiment.
InSection2ageneraldescriptionoftheSoftFIREFederatedinfrastructureisgiven.Inparticular,2.2provides a description of the different components testbeds that form the SoftFIRE Federatedplatform. Section 2.3 provides a view of the new tools that allow the SoftFIRE testbed to beaccessible,manageableandintegratedwiththeFIREinfrastructure.Section3describestheintendedlifecycle of an experiment: the design and the programming of the services and applications; thedeploymentof software componentson theplatform; theexecutionof theapplicationswithin theSoftFIREFramework; thesecurityandmonitoringof theexperimentexecution;andtheclosingandwithdraw of the experiment. Section 4 presents some tools and mechanisms that can help theprogrammersduringtheexperimentationphaseand,finallysection5describessomeconstraintsandlimitationintheusageoftheSoftFIREFederatedtestbed.
ThisdocumentisanessentialsourceofinformationforpeoplethatwantoactuallyusetheSoftFIREFederatedTestbed.Theplatformisunderconstructionanditsusageandsetoftoolsandmechanismswillchangeinthecourseoftheprojectlife.Thisdocumentistobeintendedasalivingdocumentthattheprojectwillkeepupdatedwheneversubstantialnoveltieswillbeadded.Inaddition,theprojectiskeentoreceivecommentsandsuggestionsfrompractitionersandexperimentersthathaveactuallyusedtheplatformfordevelopingtheirownsolutions.ThesesuggestionswillbeparticularlyusefultoextendandconsolidatetheaccessandusageofSoftFIREframework.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page6of49
Contents
LISTOFFIGURES....................................................................................................................8
LISTOFTABLES......................................................................................................................9
1 INTRODUCTION.............................................................................................................10
2 ARCHITECTUREOFTHEFEDERATEDTESTBED................................................................12
2.1 THEFEDERATIONOFTESTBEDS...........................................................................................122.2 THECOMPONENTTESTBEDS...............................................................................................142.2.1. ERICSSONLAB....................................................................................................................142.2.2. TECHNICALUNIVERSITYBERLINSUPPORTRESOURCES...............................................................172.2.3. FRAUNHOFERFOKUSTESTBED............................................................................................182.2.4. UNIVERSITYOFSURREY(UOS)..............................................................................................202.2.5. DEUTSCHETELEKOM(DT)...................................................................................................212.2.6. ASSEMBLYDATASYSTEM(ADS)...........................................................................................222.2.7. OTHERTESTBEDS...............................................................................................................222.3 SOFTFIREMIDDLEWAREARCHITECTUREANDSUPPORTINGSERVICES.........................................232.3.1. NFVFEATURES..................................................................................................................252.3.2. SDNFEATURES..................................................................................................................262.3.3. MONITORINGFEATURES......................................................................................................272.3.4. SECURITYFEATURES............................................................................................................282.4 ADDITIONALRESOURCESAVAILABLETOTHEEXPERIMENTERS....................................................292.4.1. VIRTUALRESOURCES...........................................................................................................292.4.2. PHYSICALRESOURCES..........................................................................................................32
3 HOWTOUSESOFTFIRE..................................................................................................34
3.1 GETTINGACCESSTOTHEPLATFORM....................................................................................353.1.1. GETOPENVPNCERTIFICATE.................................................................................................353.1.2. OPENVPNSETUP...............................................................................................................353.1.3. REGISTERTOEXPERIMENTMANAGER....................................................................................353.2 RUNNINGTHEEXPERIMENT...............................................................................................363.2.1. DESIGNPHASE...................................................................................................................363.2.2. PROVISIONPHASE...............................................................................................................413.2.3. RUNTIMEPHASE.................................................................................................................413.2.4. CLOSINGPHASE..................................................................................................................42
4 SOFTFIRESUPPORTTOEXPERIMENTERS........................................................................43
4.1 SUBSCRIPTION................................................................................................................434.2 CASESUBMISSIONANDFOLLOWUP.....................................................................................434.3 WORKFLOW...................................................................................................................444.4 SERVICESTANDARDS........................................................................................................454.5 SUPPORTCONTACTS........................................................................................................45
5 SOFTFIREGENERALUSE.................................................................................................46
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page7of49
5.1 CONSTRAINTSONTHEEXPERIMENTERSUSE..........................................................................465.2 ADDITIONALSUPPORT......................................................................................................47
6 REFERENCES...................................................................................................................48
7 LISTOFACRONYMSANDABBREVIATIONS.....................................................................49
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page8of49
ListofFigures
Figure1:TheSoftFIREstructureforprogrammers.....................................................................13
Figure2:EricssonComputingView.............................................................................................16
Figure3:EricssonOpenStackComponentsOrganization...........................................................16
Figure4:EricssonTestbedNetworkingLayout..........................................................................17
Figure5:TU-Berlinresourcesoverview......................................................................................18
Figure6:FOKUSTestbedoverview.............................................................................................19
Figure7.Experimenterinteraction.............................................................................................25
Figure8:ExperimentLifecycle....................................................................................................34
Figure9.SEMExperimenterpage...............................................................................................36
Figure10:RedminehomeforSoftFIRE.......................................................................................43
Figure11:Issuestracking............................................................................................................43
Figure12:DescribingaNewIssue..............................................................................................44
Figure13:Processfortrackingissues.........................................................................................45
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page9of49
ListofTables
Table1:EricssonHardwareStructureoftheTestBed................................................................15
Table2.FokusOpenStackHardware..........................................................................................20
Table3:NetworkEquipment......................................................................................................21
Table4:NetworkServicesProvidedbytheUoSTestbed...........................................................30
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page10of49
1 Introduction
SoftFIRE is building a federated experimental platform aimed at the construction andexperimentationofservicesandfunctionalitiesbuiltontopofNFVandSDNtechnologies.Theplatform is a loose federation of already existing testbed owned and operated by distinctorganizationsforpurposesofresearchanddevelopment.
SoftFIREintendstooffertheopportunitytousethefederatedenvironmentinordertoallowtothelargerecosystempossiblethecreationofservicesaswellasthefunctionalextensionoftheplatformitself.
SoftFIREhas threemainobjectives: supporting interoperability,programmingandsecurityofthefederatedtestbed.Securityandprogrammabilityoftheplatformarethenmajorgoalsandtheyare the focusof theSoftFIRE’sThirdOpenCall.However theexperimentersare free toproposeandworkonanytechnically relevanttopicrelatedtoNFV/SDN inthecontextof5Gevolutions.
Theobjectiveofthisdocumentistoillustratetheusageofthetestbedtothirdpartiesandtodescribetheprocessesthatareinplacetomonitorandgoverntheaccesstoresourcesduringtheprogrammingphaseandtheexecutionphase.
In this document, rules and mechanisms that ease the access to functionalities of thefederated testbed are presented and exposed to programmers in order to facilitate theprogrammingandtheusageofSoftFIRE.
Theapproachusedbytheprojectistoworkwithdifferenttestbedsinordertofigureoutasetof commonavailable functionalities todescribeandofferexternallybymeansof a commonmiddlewarelayer.Thesefunctionsallowauniformaccessandusageofthefederatedtestbed.TheprojectalsotriedtoimplementafirstsetofFIRErequirementstobefulfilledinordertoallowa smoothandcontrolledaccess to theplatform.The toolsused in theFirstOpenCall,FITeagle [1] and jFED ( [2]), have been substituted with the SoftFIRE Experiment Manager(SEM) middleware in order to grant access to Open Baton [3] and to extend to otherfunctionalities(suchasSDNproxying).TheSoftFIREprojectdecidedtodeprecatetheusageofFITeagleandjFEDandtomovetoanewandmoreindustrialarchitecturebasedonTOSCA[4].Thework for creating a full architecture is still goingon,but someuseful functionalities areprovidedstartingfromtheSecondOpenCall.
TheprogrammersandexperimentersshoulddevotesometimetofamiliarizewiththeSoftFIRESoftwareArchitecture. Inaddition, thedocumentpresents the initialdesignandfunctionsoftheSoftFIRESoftwarePortalandtheusageoftheOpenVPNinordertoaccesstothesystemandinteractwithitsfunctionsandimages.
The different component testbeds do offer distinctive capabilities. Along the projectdevelopmentperiodtheywillbeprogressivelyextended(introducingnewcapabilities)andwillbemade available to programmers. In such away, the platformwill be enriched andmademore suitable for complex developments related to NFV/SDN technologies and with aperspectiveto5G.
Thisdocumentalsodescribes the individual testbeds. Insuchaway,Experimenterscouldbeacquaintedwiththeunderlyinginfrastructureandunderstandhowtotakeadvantageofit.Inperspective,thiscouldalsobeusedinordertoplantheinterworkingwithotherplatforms.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page11of49
The document sketches also the approach used to support the life cycle of theexperimentations on the federated testbed. This is clearly the most useful part of thedocumentforprogrammersandcodersanditisconstantlyupgradedandimproved.
The last parts of this document are devoted to the support provided by SoftFIRE to theexperimentersandthelimitationandconstraintsthatdoexistinordertouseSoftFIRE.
Thisdocumentisintendedtobealivingdocumentanditwillbeextendedandimprovedalongthetimewhiletheproject improvesthefederatedtestbedandacquiresmoreknowledgeontheexperimenters’andprogrammers’needs.Updatestothisdocumentcanbefoundin[5].
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page12of49
2 ArchitectureoftheFederatedtestbed
2.1 TheFederationoftestbedsSoftFIRE federates different European testbeds owned by the partners of the project.CurrentlythefederatedTestbedare:
• RMEDCloudLabfromEricsson,locatedinRome;• FUSECOPlaygroundfromFOKUSFraunhofer,locatedinBerlin;• 5GICfromUniversityofSurrey,locatedinGuildford,Surrey;• ADSNFVLabfromAssemblyDataSystem,locatedinRome
NewtestbedsarenowintheintegrationphaseandmaysoonjointheFederation,e.g.,
• DeutscheTelekom;
InthepastotherTestbedwereintegrate(andcurrentlynotavailable):
• JoLNetfromTIM,spreadoverseveralItaliancities;
Inorder toguaranteeasecurecommunicationover thepublic Internet, secured links (IPsec)areused inorder to interconnect the testbedsdataand controlplane. SecureexperimenteraccessisprovidedviaacentralOpenVPNservice.
Experimenters can access the available resources through a single access-point, i.e., theSoftFIREExperimentManager,Figure1:TheSoftFIREstructureforprogrammers.Thistoolwillbe under development during the entire lifecycle of the project in order to progressivelymanageandorchestratetheallocationofseveralresources(Virtualization,SDN,5GResources,Security,andMonitoring).TheExperimentManagerprovidesprimitivestoauthenticateusersandtodiscover,reserve,acquire,monitorandfinallyreleaseasetofarbitraryresourcesoftheinfrastructure. Once a user has been given the authorization to access the system, he canperform experiments on top of the architecture for a certain amount of time. The SoftFIREExperiment Manager (SEM) will ensure interoperability with other technologies byimplementingthestandardTOSCAinterface.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page13of49
Figure1:TheSoftFIREstructureforprogrammers
SEMinteractswiththeNFVManager thatmanageNFVcomputingandnetworkingresourcesof the testbeds,which is an abstraction layer on top of an instance ofOpen Baton. In fact,OpenBatonisaNetworkFunctionVirtualizationOrchestrator(NFVO)thatfollowstheETSINFVManagementandOrchestration (MANO)specificationandallowsusers todefineand launchvirtualizedinstancesandtoconnectthemthroughasetofvirtualizednetworks[3].Inaddition,itprovidesautoscalingandfaultmanagementbasedonmonitoringinformationcomingfromthemonitoringsystemavailableattheNFVIlevel.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page14of49
Moreover, theproject isworking for integrating theSEMwithanSDNManager inchargeofallocatingSDNrelatedresourcestoeachindividualexperimenter.MechanismsforallowingtheallocationofSDNresourcesarecurrentlyunderimplementationandwillbeavailableinordertoexposeresourcesandAPIsofOpenDayLightcontrollerand/orclosedsourceSDNcontroller.
Eachtestbedprovisionsvirtual resourcesbymeansofanOpenStack [6]cloudcontroller (theadopted release is at least Newton) that controls the physical compute, storage, andnetworkingresourcesdedicatedtotheproject.ThisOpenStackcontrollerisconnectedtothecentral Open Baton orchestrator, which coordinates the instantiation of virtual machines(VMs)overthetestbeds.ExploitingthemultiplepointofpresencessupportedoutoftheboxbyOpenBaton,experimenterscanchoosespecificlocationsmeaningofthetestbedinwhichtheywanttoinstantiateVMsandsothearchitecturecansimulatepeculiarscenariosincludingthe interaction of different domains inside one operator’s network or among differentoperators.Thoughsometestbedsownresourcesthatcouldnotbehandledbymeansof theETSI NFV framework (e.g., physical switches, wireless access points or other 5G relatedresources),SEMwillbeprogressivelyextendedinordertomanagethoseresources,whicharethenexportedtowardstheexperimenters.IncaseofresourcesnotfullyintegratedtotheSEMmechanisms,experimenterswillbeable toaccess themeitherviadirectaccessbymeansofSEMordirectAPIs.
2.2 ThecomponenttestbedsTheFederated testbed consistsofmultiple testbed sites,with the following total amountofvirtualisationresourcesforexperimenters.Pleasenotethenumbersnotedinthetablebelowindicate the total amount available for all experimenter VMs combined (not for eachexperimenter).
Testbedname CPU(number) RAM(inGbytes) Disk Storage (inGbytes)
Fokusosdnc 32 125 12
Fokusdev 56 256 274
Ericsson 80 256 1600
DT 10 20 50
UniversityofSurrey 12 48 240
AssemblyDataSystem 32 96 1800
TOTAL 190 705 2176
2.2.1. EricssonlabEricssonSoftFIRE testbed ispartof theEricssonRMEDCloudLab.Located inRome, theLab’sscope is toprovideHandsonandCompetenceBuild-up, showspecificandconcrete“proof”
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page15of49
points related to the cloud benefits, CustomerDemo on specific products and demonstratehowissuesandconcernscanbemanagedmitigatingtherisks.
Mainactivitiesperformedare:
• StandardCustomerDemo• DeepDiveonCustomerspecificrequest• PoConCustomerpremises• FullyCustomizedPoConCustomerpremises• ValidationandCertificationonCustomerspecificstack/solution
The Ericsson Cloud Lab is a flexible environment where it is possible to combine differenthardwareconfigurationstosupportdifferentdeliverypolicies.TheLabisanywayadaptabletoguaranteetheEricssonPlatformrequirementsandcommercialproducts.
EricssonTestbedArchitectureforSoftFIRE
Ericsson is sharing an experimental infrastructure (Ericsson SoftFIRE testbed) to beinterconnectedwithintheSoftFIREproject.
ThescopeofEricssontestbedinSoftFIREprojectistoprovideanOpenStackLibertyinordertodeliveryaninfrastructureasaservice(IaaS)forcreatingandmanaginglargegroupsofvirtualprivateserversinadatacenter.
ThearchitectureisbasedonDellHardware,asshowninthetablebelow:
Table1:EricssonHardwareStructureoftheTestBed
Description(singlenodeconfiguration) Qty
DellPowerEdgeR620 1
Intel Xeon E5-2660v2 2.2GHz, 25M Cache, 8.0GT/s QPI, Turbo, HT,10C,95W,MaxMem1866MHz
2
16GBRDIMM,1866MT/s 8
400GB,SSDSASValueSLC6Gbps 2
IntelX520DP10GbDA/SFP+ServerAdapter 2
IntelEtherneti350QP1GbNetworkDaughterCard 1
The number of servers reserved for the project are three: one controller and two computenodesFigure2:EricssonComputingView.
Fromstoragepointofview,all serversareequippedwith2x400GBdisk inmirroring forOSand2additionaldisksby2TBeachone,alsoinmirroring.
Inthecontroller1TBisusedforCinderand1TBisusedforGlance;ineachcomputenode2TBarereservedforNova.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page16of49
Figure2:EricssonComputingView
The installed OpenStack has a classical modular architecture where main components are (Figure3):
• Nova-providesvirtualmachines(VMs)upondemand. • Cinder - provides persistent block storage to guest VMs. • Glance-providesacatalogueandrepositoryforvirtualdiskimages. • Keystone-providesauthenticationandauthorizationforalltheOpenStackservices. • Horizon - provides a modular web-based user interface (UI) for OpenStack services. • Neutron - provides network connectivity-as-a-service between interface devices
managed by OpenStack services.
Figure3:EricssonOpenStackComponentsOrganization
Thefollowingvariantshavebeenputinplace:
• InsteadofMySQLDBhasbeenusedPostGres;
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page17of49
• L3agentisnotinstalledcauseofthepresenceoftheexternalSDNcontroller;• OntheComputeNode,noDHCPandmetadataareactivatedandOVSisloadedviathe
networking-odlpseudoagent
ToextendOpenStackcloudscapabilitieswithSDNfunctionality,OpenDaylightSDNcontroller(ODLBoronSR-2)underOpenStackNeutronhasbeenintegratedintotheNeutroncomponentofOpenstackviathetheOVSDB2.7.0south-boundplug-in.
OpenDaylightalsoprovidestheuserwithaccessibleAPItocontrolandrefinetheconfigurationoftheattachedOVSswitchesofferinginthiswaybasicSDNcapabilities.
NetworkDesign
The network design of the proposed architecture is composed by six networks (Figure 4:EricssonTestbedNetworkingLayout):
• IDRACnetwork:istheconsolenetwork;• MGMT:Administrationforoperationandmaintenance• NB_API:OpenstackNortboundAPI;• SB_API:OpenstacksouthboundinterfaceAPI(Openstackinternalservices)• Tunnelnetwork:computeinterconnectionforVMstraffic;• Floatingnetwork:externalnetwork(flat)providingfloatingIPstotheVMs
Figure4:EricssonTestbedNetworkingLayout
2.2.2. TechnicalUniversityBerlinSupportResourcesTheTU-BerlinnodeisthecenteroftheSoftFIRE’sVPNnetwork.Itisrealizedasapurevirtualnetwork that is feedasVLAN into the twoVirtualizationenvironmentsatTUB (seeFigure5:TU-Berlin resources overview). The VPN encryption is handled by a virtual instance of anOpenBSDbasedFirewallrunningonaVMwarebasedvirtualizationcluster.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page18of49
TUBalsoutilizesaprivateOpenStackclusterthatisusedtohostgenericSupportServiceslikethedevelopmentversionsoftheOrchestrationtoolsusedbySoftFIRE.ThisenvironmentalsohoststheExperimentmanagerplugincomponentthatisusedtostoreVMimagesbecausethebandwidthprovidedatTUBismuchfasterthanontheothertestbeds.TheOpenStackclusterisnotprovidedtotheSoftFIREexperimenterstoexecuteexperiments.
Figure5:TU-Berlinresourcesoverview
VPNHub
InterconnectionbetweenFOKUSandtheotherSoftFIRETestbeds isprovidedbyavirtualizedIPsec VPN server. AnOpenBSD based firewallwas chosen because of the great flexibility insupportedVPNand firewall settings that are needed to interconnect thedifferent testbeds.Thenetworks are completely isolated from the internalnetworkof theUniversity. Incomingand outgoing network traffic is filtered based on whitelists that allow previously agreedprotocols.TheVPNHubiscapableofforwardingtrafficbetweendifferentSoftFIREnetworksatdifferent Partners. The VPN Server also provides OpenVPN services to registeredExperimentersandIPSecinterconnectiontootherTestbeds.AccesstotheOpenVPNserverisprotectedbythesameCertificatesthatareusedtoaccessthejFedclient.Thecertificatesareautomatically generated by the SoftFIRE portal. This VPN server provides network access toregisteredexperimenterssotheycandirectlyinteractwiththeirownNVFs.
2.2.3. FraunhoferFOKUSTestbedTheSoftFIRETestbednodelocatedatFraunhoferFOKUSinBerlinisrealizedastwoseparatedOpenStack instances: One pure OpenStack installation and the other part as an integratedinstallationwithOpenSDNcore to provide SDN features. Figure 6: FOKUS Testbed overview.The connectivity to the distributed parts of the SoftFIRE Testbeds is realized by an IPsecsecuredVPNlinktotheTUB.
DFN/Internet
OScompute OScompute OScompute
OScontroller
Tenant
SoftFIREServiceTenant
TenantOtherTenant
SoftFIREnetwork
FITeagle
OpenBatondev
VMWareESX
VPNRouter(OpenVPN,
IPsec)
SoftFIREnetworkVLAN
Exp.Managerplugin
IPsec
IPsec
IPsec
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page19of49
Figure6:FOKUSTestbedoverview
OpenStackCluster
ThecomputeresourcesareprovidedbytwoOpenStackNewtoncluster installationsthatarededicated to the SoftFIRE Project. A dedicated deployment was chosen to minimize theinterference from other active projects on to the Experiments. The setup is based on onecombinedcontroller,computeandnetworkinghostandoneadditionalcomputenodeforthe“pure”OpenStackinstallation.FortheSDNfeaturedversionofOpenStacktheControlleralsohouses the OpenSDNcore controller that acts as a master controller for each of theOpenSDNcore vSwitches that are deployed in each compute host. The used servers aremanufacturedbyDellandare intheBladeformfactor.Table2.FOKUSOpenStackHardwareliststhedetailsoftheusedserverhardware.StorageCapacityisprovidedbyacentralStorageArray Network (SAN)manufactured by NetApp accessed via GBit Ethernet. The Servers areconnectedtoseveralredundantnetworksthatareusedformanagementandstorageaccess.DirectaccesstothesenetworksisnotpossiblefromwithintheVMinstances.Connectivityforthe SoftFIRE VPN in realized as an external provider network that is connected via theOpenSDNcore vSwitches (or the Networking host of the OpenStack) and dedicated to theSoftFIREproject.
OScompute OScompute OScompute
OScontroller
SoftFIRETenant(s)SoftFIRETenant(s)
VM VM VM
SDNSwitch
SDNSwitch
SDNSwitch
OpenSDNcore controller
VMWareESX
SoftFIREnetwork
VPNRouter
VLAN
IPsec
OpenBatonproduction
Exp.Managerprod.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page20of49
Table2.FOKUSOpenStackHardware
Type RAM CPU Storage
Controller &Compute1
DellPowerEdgeM620
128GB 2x Intel(R) Xeon(R)CPU E5-2640 v2 @2.00GHz(32vcores)
360GBSSD
1TBHDD
NAS:500GB
Compute2 DellPowerEdgeM620
128GB 2x Intel(R) Xeon(R)CPU E5-2640 0 @2.50GHz(24vcores)
150GBSAS
NAS:500GB
Controller &Compute &OpenSDNCore
DellPowerEdgeM620
128GB 2x Intel(R) Xeon(R)CPU E5-2640 v2 @2.00GHz(32vcores)
150GBSAS
NAS:500GB
OrchestrationandManagementServices
The resources of the Federated SoftFIRE testbed are managed via SoftFIRE ExperimentManager (SEM) andOpen Baton toolkits. These services are the single contact point to theexperimenters.ToensuregoodconnectivitytoallSoftFIREtestbedstheseservicesareinstalledatFraunhoferFOKUSondedicatedservers.Forsecurityreasons,theseservicesareinstalledonadedicatedhardwarethatcannotbeaccidentallymodifiedbytheSoftFIREcomponents.TheVPN router thatmanages the Interconnection to theVPNhubatTUB is realizedasa virtualinstance in a different virtualization environment. This second virtualization environment isrealizedbyaVMwareESXcluster.AZabbix[7]proxyserviceisprovidedonthesameinstancetosupportthecollectionofKPIvalues.
2.2.4. UniversityofSurrey(UoS)TheUoSSoftFIREtestbedsegmentispartoftheoverallUoS5GICtestbed.LocatedintheUK,the scope of the testbed is to provide hands-on access to a 3GPP based campus RANwithindoor and outdoor coverage that is able to be interconnectedwith a variety of virtualizedcore slices, inorder todevelopCoreNetwork5Gevolutionsanddemonstrate5GUseCasesrunningovertheresultantend-to-end(ETE)cellularnetwork.Inthismanner,thetestbedcanbeusedtobuildindustrycorecompetencein5G.
The networkwas initially built as a fixed ETE cellular system, but has now been evolved toprovideasetofvirtualizednetworkcapabilitiesthatcanbeconfiguredtoconnectwithIPstubstowardstheRANtoenablevariousnetworkslicestobeconnectedincircuitunderthecontrolofthefederatedSoftFIREcore.
It is envisaged that experimenters using the facilities of the UoSSoftFIREtestbedwillbeabletoshowspecificandconcrete“proof”pointsrelatedtothe5GRANandCoreevolutionsanddemonstrateapplicationsrunningoverthisinfrastructure.Theseusecaseproofpointscanbeusedtosupportmanytypesofusecases tohighlight theirbenefits,explain tocustomersandindustrypartnershowtheyworkanddemonstratehow5Gtargetsmaybemet,andwhattheprosandconsareforeachdemonstration.
Themainactivitiesperformedare:
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page21of49
• StandardexperimenterDemo• DeepDiveonexperimenterspecificrequest• Proof-of-Concept(PoC)whilstconnectedtoexperimenters’equipmentorremotesite• ValidationandCertificationonCustomerspecificsolution
UoSTestbedArchitectureforSoftFIRE
The5GICUoStestbedissharingasegmentofthetestbedwiththeSoftFIREFederatedTestbed(UoSSoftFIREtestbedsegment),whichisinterconnectedwithintheSoftFIREproject.
ThescopeofUoSSoftFIREtestbedsegmentintheSoftFIREprojectistoprovidethefollowingcomponentparts:
1. OpenStack (Newton version) system access to infrastructure that can be used toinstantiatecoreslicesforexperimentationwiththelocalRANcomponents.
2. Accesstothe5GICin-buildingLTE-ARAN3. Accesstothe5GICin-buildingWi-Fisystemformulti-access5Gusecases
Inordertodelivertheinfrastructureasaservice(IaaS)capabilitiesforcreatingandmanagingasadata-centre,thefollowingnetworkhardwareisprovidedforexperimenteruse,asshowninTable3.
Table3:NetworkEquipment
Description(singlenodeconfiguration) QtyDell PowerEdge R920 (deployed as SoftFIRE OpenStackControllerandComputeserver)Total12CPUsavailableforexperimenterVMs
1
Indoor,Wi-FiAccessPointsWi-Fi802.11acAccessPointsfromAruba
6
Indoor,LTE-A,FDD,Femto-cells,Band20 1
ResourcesavailableperExperimenteratUoSTestbed
Description(singlenodeconfiguration) Qty
CPUs 4
Diskstorage <=80GB
RAM 16GB
PleasenotethatinOpenStackenvironment,thiscansupport2“m1.medium”flavours(2CPUs,40GBdiskspace,and8GBRAM).
2.2.5. DeutscheTelekom(DT)
TheSoftFIREprojecthasalsoworkedtowardstheextensionoftheFederatedtestbed.Startingfrom the Second Open Call some infrastructure resources from a testbed of DT have beenintegratedandmadeavailablefortheexperiments.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page22of49
The testbedcontributionofDT ispartofa largerOpenStackcluster located inacommercialdata center in Berlin, which is used for a number of innovation projects. Currently theOpenStack release “Mitaka” is installed but the migration to the “Newton” release will beavailablebeforethestartoftheThirdOpenCall.SoftFIREwillhaveaccesstoaportionoftheoverallresourcesasdescribedinthetableatthebeginningofchapter2.2.Dependingonthedemandfromtheexperimentersthere issomeroomto increasethevirtualresourcesduringtheOpenCallifneeded.
2.2.6. AssemblyDataSystem(ADS)
ADS SoftFIRE testbed is located in Rome. The aimof this environment is to set up a Lab todevelopNFVskillsinsideADSSoftwareFactoryandprovideaplatformforcustomerdemoandPoC. The Labwill be also an optimalworking environment for the development and test ofown-brandVNFandbenchmarkingcloudvirtualnetworkperformance.
ADS, has based its NFV infrastructure on Red Hat Openstack 10 (Newton) released onDecember2016. It’s the firstLongTermReleasethatwillhaveasupport lifecycleupto fiveyears. This release is suggested for real production infrastructures for TelcoOperators,whoneedstableandsupportedenvironments.CurrentlytheADSNFVplatformconsistsof5nodeswiththefollowingroles:
Qty Role HardwareDescription
1 Director DELLPowerEdge-2xQuadXeonwith16GBRam
1 Controller DELLPowerEdge-2xQuadXeonwith16GBRam
2 Compute DELLPowerEdge-2xQuadXeonwith48GBRam(Tot96GB)
1 Storage(CEPH) DELLPowerEdge-2xQuadXeonwith16GBRam
1 Monitoring andManagementTools
SUNServerX4-2-2xQuadXeonwith32GBRam
The Private Cloud will be interconnected within the SoftFIRE project in order to makeexperimentsonageographicallydistributedNFVplatform.
The storagebackedof the infrastructure is basedonCeph SoftwareDefined Storage,whichprovidesaHighAvailabilityandHighScalabilityObjectandBlockStorageongeneral-purposehardware.
TheintegrationwithOpenDayLightwillenablemoreadvancedSDNfunctionalitiesthanthoseprovidedbydefaultOpenStackNeutronmodule.
Furthermore, compute nodes leverage on Real Time KVM Hypervisor to virtualize VNFrequiringRealTimefunctionalities.
2.2.7. OtherTestbeds
For interestedcompanies, there is thepossibility to integrateothertestbeds inorderextendthe functionalities and capabilities offered by the Federation. In case there is this need,werecommendgettingintouchwiththeSoftFIREcontacts.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page23of49
TheSoftFIREproject is also involved in international activities. Thereare joint activitieswithotherpossiblepartnertocreateawiderfederationofTestbeds.Afirststeptowardsitwastheintegration in the federated testbedof the EITDigital SiliconValley testbed. It could be theentrypointforfurthercollaborationswithorganizationsintheUSA.
2.3 SoftFIREMiddlewareArchitectureandsupportingservicesThe SoftFIRE middleware architecture has gone through a deep restructuring andconsolidationinordertoprovidebetterservicestoexperimenters.
With reference to Figure 1, several “managers” have been designed, implemented andprovidedtoexperimentersinordertosupporttheexperimentlifecycle.
The identifiedmanagers areNFVManager, for virtualized resources, SDNManager for theallocationof theSoftFIREprovidedSDN functionalities, aSecurityManager thatwill supportthe allocation of security functions made available by SoftFIRE and usable by theexperimenters,theMonitoringManagerforsomerelatedmonitoringfunctionalities.TheNFVManagerandtheSDNManagerareunderdevelopmentandwillbeprovided in time for thesecondwave.TheothermanagerswillbeprogressivelyintroducedinordertobeusedinthefollowingwaveofexperimentationsorHackathons/Challenge.
ItisimportanttoclarifythataccesstotheindividualOpenStackinstanceswillbegrantedonlyviatheSoftFIREExperimentManager(i.e.,theSoftFIREMiddleware),andinmostofthecasesOpenStackAPIswon’tbeavailabletobedirectlyconsumedbyexperimenters.
Nevertheless,thetestbedwillbealignedwithindustry-orientedstandardisationefforts:TOSCAis exposed to experimenters for deploying and provisioning resources on the federatedinfrastructure.ThismeansthatSoftFIREgenericresourcesaredescribedasTOSCAnodesandthe SoftFIRE Experimenter Manager will support the “translation” and allocation of therequestedresourceontotheSoftFIREavailableresources.ExperimenterscouldalreadystarttogetfamiliarwiththeTOSCAAPIsandfunctionalitiesofferedbytheOpenBatonframework[3].Although the final ones,whichwill be exposed by the SoftFIREmiddleware,may be slightlydifferent, the SoftFIRE consortiumwill try tomaintain compatibility with the functionalitiesprovidedbytheOpenBatonAPIs.SoftFIREwillmakeuseoftheOpenBaton4threleasewhichhasbeenlaunchedbytheendofApril2017.TheOpenBatoninstallationinSoftFIREprovidesthe following components: NFVO, Generic VNFM, Auto-scaling Engine, Zabbix Plugin, andOpenStack driver. Experimenters could also consider extending the set of componentsprovidedbytheOpenBatonframework.ForthistheycouldmakeuseoftheOpenBatonSDKandbuildeitheranewVIMdriver,Monitoringdriver,VNFManager,orexternal component(using the event mechanism, please refer to the documentation). In this case, theexperimenter should host the additional developed components on their ownpremises andinterconnectthemtotheOpenBatonframeworkviatheRabbitMQmessagebus.
Monitoring functionalitieswillbe implementedbytheZabbixmonitoringsystem,andwillbeprovidedasaservicetoexperimenters.
AdditionalSecurity featureswillbeadded inorderto furtherenrichthepotentialnumberofusecasestobedevelopedonthefederatedtestbeds.Complexopensourcesecurity-orientedVNFswillbemadeavailable to theexperimenters,offeringalsoNetwork IntrusionDetectionSystemwithDeepPacketInspectioncapabilities(SuricataNIDS).Virtualfirewallingcapabilitieswillbealsoenhancedgivingthepossibilitytomanageandrecreaterealcasescenarios.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page24of49
Figure7showsthegenericprocessbywhichtheprogrammerscanusethefederatedtestbed.Thepicture indicateshowthe federatedtestbedwillgrantaccessandwillprovideallocationand usage of resources. A registration phase is needed and when an experiment has beenauthorizedandwillbedoneautomatically, theExperimenterwillgetacertificatetobeusedfortheexperimentteaminordertoaccesstotheSoftFIREresources(theSoftFIREwebportalwill be used in order to distribute the certificates.When the access to the infrastructure isgranted,theexperimenterswillbeabletorequestresources.Iftheyareavailabletheywillbeallocatedandanacknowledgmentwillbereturnedtotheusers)andinstantiated(essentiallyavirtual instanceof themwillbecreatedandexclusively instantiated for theexperiment)andhence usable for the specific goals of the experiment. The SoftFIRE Experiment Managersegmentstheexperimentsinsuchawaytoavoidinterferencebetweendifferentusagesoftheplatform(e.g.,otherexperiments).
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page25of49
Figure7.Experimenterinteraction
2.3.1. NFVFeatures
TheexperimenterwillbedealingwithNFVResourcesineveryexperimentsinceNFVisthecoretechnology exploited in the SoftFIREMiddleware. The Experimenter can reserve and deploy
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page26of49
Network Servicesondemandor canalsodefinehis ownNetwork Service tobedeployed inoneormoretestbedoftheSoftFIREinfrastructure.
ThepreconfiguredNetwork Services available are defined in the Section2.4.1where all theVirtualResourcesaredescribed.PleasenotethatduetocopyrightconstraintssomeNetworkServicesareconstrainedtobedeployedinaspecifictestbedandtheexperimenterwillnotbeabletoaccessthedeployedVMs.
In particular, the SoftFIRE middleware NFV features are provided by the ETSI NFV MANOcompliantorchestratorOpenBaton[3].Forthatreason,inordertodefineadifferentNetworkService,youmayfindofhelptheOpenBatondocumentationandtutorialonCSARdefinition[9],howevermoredetailswillbeprovidedinthesection3.2.1.
2.3.2. SDNFeatures
From the second wave of experiments, the SoftFIRE middleware provides SDNprogrammability features to the experimenters. This enables them to create innovativeexperimentsandusecasesthatmakeuseofadvancednetworkingfeaturesthatareprovidedbytheSDNmiddlewarecomponentsintheSoftFIREplatform.CurrentlytheprojectisworkingtowardsthepossibilitytointroduceServiceFunctionChaining.Incasethesefunctionswillbemadeavailable,theprojectwillinformandadvertiseitthroughwww.softfire.euportal.
Inaddition to thechangeson theSoftFIREMiddleware, theSoftFIREconsortium isprovidingSDN technologies either as virtualised or physical entities available in some of the testbedsprovided. Currently, some of the individual testbeds already integrated OpenDaylightcontroller (ODLBoronSR-2)underOpenStackNeutron tomanage thenetwork flowson thecomputenodesviatheOVSDB2.7.0south-boundplug-in.NetworkprogrammabilitywouldberealisedviaasetofOpenDaylightRESTCONFAPIsexposedbytheODLcontroller.
FraunhoferFOKUSoffersaccessrecentdeveloped integrationofOpenSDNcoreSDNplatformintotheOpenStackneutronnetworking.TheOpenSDNcoreControllerincollaborationwiththeOpenSDNcorevSwitchintegratedintothecomputeserversprovidefullcontrolofthenetworkusedbyallNFVsdeployedon thisparticularOpenStack.Theexperimenterscanmakeuseofthe JSON-RPC basedAPI of the Controller to implement advanced SDN features like ServiceFunctionChaining(SFC),Trafficredirectionandloadbalancing.
However,theaccesstotheindividualcontrollerAPIwillbesubjecttomechanismstolowertheriskof interferingamongvirtualobjectuserdataconfiguration.Therefore,accesstotheSDNtechnologiesmaybegranted in suchaway thateachexperiment couldwork independentlywithoutinterferencesfromotherrunningexperiments.
DuetothefactthateachTestbedusesdifferentcontrollersandvSwitchimplementationstheSoftFIREplatformcan’tofferSDNWANfeaturesduringthethirdopencallphase.
Please note that these specifications may change according to the progress and theenrichmentoftheTestbeds.
2.3.2.1. FraunhoferFOKUSOpenSDNCore
TheOpenSDNCoredevelopedbyFraunhoferFOKUSprovidesadvancedSDNfeaturesthataretightlyintegratedintotheOpenStackplatform.ThisplatformcanbeusedtodevelopnewkindofSDNapplications,orutilize thecurrent features to implementcustomusecasesbasedonFlowrules.ThePlatformprovidesthefollowingfeatures:
• DedicatedflowtablesforeachExperiment
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page27of49
• Accessislimitedtothisflowtablesandtorulesthatdirectlymatchonportsandmac-addressesusedbytheExperiment
• TheOpenStackintegrationusespredefinedsetofflowtablestorealizebasicfeatureslike,ARP,Floating-IPs,Internet-Access,Tenantnetworkseparation.
• Traffic will traverse tables 0 for classification and 6 for firewalling and is thenforwardedtoapplicationspecifictablesbeforeitleavestheswitchviaanoutputport.
• Tenant specific flow-tables are inserted just after the firewall before applicationspecifictables
TheSDNcontrollerexposesaJSON-RPCAPIthat isusedtocontrol the innerworkingsoftheControllerandallconnectedvSwitches.TheextensivedocumentationofthisAPIcanbefoundontheSoftFIRESDNdocumentationwebsite.1
2.3.2.2. OpenDayLightNetVirt
OpenDaylight OPENFLOW PLUGIN RESTCONF APIs are exposed by the Boron SR-2 ODLcontroller for Network programmability. The user can take advantage of NetworkVirtualization by using OpenDaylight SDN functionalities whilst utilizing OpenvSwitch. Thestack includes a Neutron Northbound, a Neutron Virtualization Layer and an OVSDBsouthboundpluginandanOpenFlowsouthboundplugin.
To allow experimenters to operate their own network programmability schemas preventivemeasureshavebeenadoptedsuchaslimitingtheaccesstoexperimentdedicatedflowtablesalongwithinvolvingOVSportandMACaddressusedbytheexperiment.
2.3.3. MonitoringFeatures
ExperimenterMonitoring functionality ismade available as a service to experimenters whoneedstogetmonitoringdataabouttheirownVM.
ThemonitoringsolutionofferedbySoftFIREisbasedontheopensourcemonitoringsoftwareZabbix.Themonitoringservicecomprisestwomajorsoftwarecomponents:ZabbixserverandZabbixagent.
TheMonitoringResource (ZabbixServer) request isperformedviaToscaAPIexposedby theExperimentManagerandmustbedefinedinresourcerequestdefinitionTemplatealongwithinformationonwhichtestbedtodeploy.
Theserverisdeployedinaseparateanddedicatedresourceintotheindicatedtestbed.AttheRequestResourcecompletion,theexperimenterisinformedabouttheZabbixServerfloatingIPalongwithusercredentialpreconfiguredtoaccess.TheZabbixagentwillbeinstalledinalltheVMstheexperimenterdescribesintotheNFVnode_typesdescription.ManymetricsarebeingmonitoredinVMlevelandareprovidedasstandardmetricsandcanbeactivatedordeactivatedonrequest.Someofthese,butnotlimitedto,perVMare:totalmemory,usedmemory,freememory,totalswapmemory,usedswapmemory,freeswap1http://docs.softfire.eu/opensdncore/
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page28of49
memory,totalstorage,usedstorage,freestorage,CPUload,CPUutilization(%),CPUcount,networkmetrics(e.g.incomingandoutgoingtrafficininterfaces,OS-relatedmetrics,processes-relatedmetrics(e.g.numberofrunningprocesses),services-relatedmetrics(e.g.FTP-/Email-/SSH-serverisrunning),etc.SoftFIREdoesnotprovideapplicationmonitoringmetricsaddressinginformationaboutthestateoftherunningapplication,itsperformanceandotherapplicationspecificinformation.ThesemetricsarenotprovidedbydefaultbyZabbix,theexperimentsneedtoexplicitlyconfigurethemattheagentandtheserverlevels.
2.3.4. SecurityFeatures
TheSecurityManager insidetheSoftFIREMiddlewaremakesavailabletotheExperimenteraseriesof security related functionalities that shemightdecide to includeandusewithinheractivitiesontheSoftFIREplatform.
Hereisthelistoftheavailablefeatures.
1. TheExperimentercandeployaSecurityResource2. The Experimenter can statically configure her Security Resource by means of its
descriptora. TheExperimentercanenablelogscollectionfromherResourceb. TheExperimentercanstaticallyconfiguresomerulesonherResource
3. TheExperimentercandynamicallyconfigureherResourceonceithasbeendeployed4. TheExperimentercanseeherResourceslogsinawebdashboard5. TheExperimentercanperformsearchesamongherResourceslogsinawebdashboard6. TheExperimentercanseestatisticsrelatedtoherResourceslogsinawebdashboard
2.3.4.1. SecurityResources
ASecurityResource isacommonlyusedsecurityagent that theExperimentercan include inherexperiment.Shecanaccessandconfigureitthroughastaticinitialconfiguration,includedin the TOSCAdescription of theResource, or, once deployed, through a REST interface thatexposesitsmainservices.
TheExperimentercanalsoasktheSecurityResourcetosenditslogmessagestoaremotelogcollector,whichmakesthemavailableinasimplewebpagereservedtoher.TheExperimentercould easily access it through its web browser and check the behaviour of her all securityagents,andtoseesomestatistics.
TheExperimentercangettheSecurityResourceintwodifferentformats:
• As an agent directly installed in the VM that shewants tomonitor. The systemwillprovide her a script that the Experimenter has just to run inside the VM. It will bealreadyconfiguredasrequiredintheTOSCAdescriptionoftheresource.TheoutputofthescriptwillprovidetotheExperimenterinformationonhowtoaccessthedeployedresource(URLs,etc.)
• As a standalone VM the Security Resourcewill be deployed directly by the SecurityManager in the testbedchosenby theExperimenter.TheSecurityManagerwill takecareoftheinitialconfigurationoftheresource.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page29of49
The Experimenter has to set up on her own the redirection of the network traffic that shewants to control through the Security Resource VM (by means of tunnelling or SDNcapabilities).
TodatetheonlySecurityResourceavailableontheSoftFIREenvironmentisthefirewall.
2.3.4.2. Firewall
Afirewallisanetworksecuritysystemthatmonitorsandcontrolstheincomingandoutgoingnetworktrafficbasedonpredeterminedrules.
TheavailablefirewallresourceisbuiltuponUbuntuUFW(UncomplicatedFireWall),towhichacontrolsystem,basedonaReSTinterface,hasbeenadded.
ThefirewallagentisavailableforUbuntuOSonly.
The rules that can be defined on this type of firewall are stateless (they do not maintaininformationaboutthecontext).Itworksasapacketfilter,whichlooksatnetworkaddresses,portsandprotocols.
ServicesspecificallyavailableforthefirewallResourceare:
1. TheExperimentercanstaticallydefinealistofallowedIPaddresses(orCIDRmasks)2. TheExperimentercanstaticallydefinealistofdeniedIPaddresses(orCIDRmasks)3. TheExperimentercanstaticallydefinethedefaultbehaviourofthefirewall4. TheExperimentercangetthestatusofthefirewall5. TheExperimentercangettherulesinstalledonthefirewall6. TheExperimentercandynamicallyaddaruletothefirewall7. TheExperimentercandynamicallyupdatearuleonthefirewall8. TheExperimentercandynamicallyremovearulefromthefirewall
2.4 AdditionalresourcesavailabletotheexperimentersCurrently the project and its partners are developing additional functionalities and relatedvirtualmachines.Providedthatanacceptablelevelofstabilityandrobustnessisreached,thefederated testbed will be complemented with such sets of well formed and ready to usenetwork functions. Theprogrammerswill thenbe able touse themand create services andapplications,takingadvantageofmoreprogrammablebuildingblocks.
The topics addressed are existing network architectures (like IMS and its evolution) and aspecialattention isgivento initialbuildingblocks for5G.Thiswillallowtheprogrammers toexploitthesefunctionalitiesandstartdesignapplicationsforthe5Genvironments.
Inordertosupporttheprogrammers,incaseofareleaseofnetworkfunctions,thisdocumentwillbeextendedandwillpresentadescriptionofthebasicfunctionalities,theAPIsandaguidetousethem.
2.4.1. VirtualResources
2.4.1.1. Widelydeployable
• OpenIMSCore(Fokus):The Open IMS Core is an Open Source implementation of IMS Call Session ControlFunctions (CSCFs) and a lightweight Home Subscriber Server (HSS), which together
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page30of49
formthecoreelementsofall IMS/NGNarchitecturesasspecifiedtodaywithin3GPP,3GPP2,ETSITISPANandthePacketCableinitiative.ThefourcomponentsareallbaseduponOpen Source software (e.g. the SIP Express Router (SER) orMySQL). FormoredetailspleasevisittheOpenIMSwebsite2
2.4.1.2. FOKUS
• Open5GCore(Fokus):Open5GCore is a prototype implementation of the pre-standard 5G network. Thesoftware is available from November 2014 and its main features are described onwww.open5gcore.net. Open5GCore represents the continuation of the OpenEPCprojecttowardsR&Dtestbeddeployments.IthasbeenusedovertheyearsinmultipleprojectsasareferencevEPCimplementation.ThefollowinglimitationsapplywhenthisVNFisusedbyExperimenters:
o This VNF can only be used inside the Fraunhofer FOKUS testbed due tolicensingconstrains.
o It will provide a complete virtualized 5G-core network with virtualized UEcomponentsandbenchmarkingfeatures.
o Interconnection of physical RAN equipment is also supported; however, theexperimenter thenneeds tobepresent into the labof Fraunhofer FOKUS inBerlin
2.4.1.3. UniversityofSurrey
TheUoStestbedprovidesLTE-Acorenetworksliceswithadded5Gfeatures.UoSrunsVMsforaUserPlane(UP)slicewhereadedicatedUPnode(UPN)runsforanexperimenter,aswellasasingle VMwhere a Control Plane (CP) node (CPN) runs. Table 4 briefly describes the virtualcorenetworkcomponents.
Table4:NetworkServicesProvidedbytheUoSTestbed
NetworkService
Max # ofinstances
VNFs Description
CPN 1 HSS,MME,integrated(SGWc,PGWc)
ThisNetworkService(NS)sliceisinstantiatedassoonasanyEPCisrequiredtobeinstantiatedonthe UoS testbed for Control Plane connectivityviatheUoSLTE-ARAN.
ThereisonlyeveroneinstanceoftheCPNNSforthe whole UoS SoftFIRE network Segment. Allexperimenters instantiated on the UoS testbedsharethissliceforLTE-AEMMconnectivity.
ThePLMN-idusedis23591whichisaVodafoneUKtestidwithlabel“5GSF”
UPN(CC) 3 CC, This Network Service is instantiated perexperimenter for LTE User Plane service and
2http://www.openimscore.org/
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page31of49
Integrated(SGWu,PGWu)
extended5GContextAwarenessAssociationtoagroupofcellsknownasa“Cluster”viathenewlyproposed 5G node called a Cluster Controller(CC).
ThissliceprovidesbestperformanceforInternetaccess.
EachauthorizedexperimenterisprovidedwithasingleinstanceofthisVMontheUoStestbed.
UPN(CM) 3 CM,integrated(SGWu,PGWu)=a.k.a.PacketProcessingEntity(PPE)
This Network Service is instantiated perexperimenter for LTE User Plane service andextended5GContextAwarenessAssociationtoaClusterMemberwithina“Cluster”viathenewlyproposed5GnodecalledaClusterMember(CC).
ThissliceprovidesbestperformanceforIntranetaccessviaoneoftheClusterMembers.
CM has the interface to an experimenter-provided server application (that would run onanexperimenterVM)
EachauthorizedexperimenterisprovidedwithasingleinstanceofthisVMontheUoStestbed.
FortheThirdOpenCall,theseserviceswillbeofferedbyUoS:
• ACUPSevolvedEPCasUPNandCPNoperatingwithanalreadydeployedCPN.AsingleUPNwillbeinstantiatedforeachapprovedexperimenterontheUoStestbed,whereastheCPNissharedamongexperimenters.
• The Experiments must be related with and designed to work with LTE EPC. TheExperimenterVNFDmustbeavirtualisedserverapplicationtobedeployedonaVMonUoSOpenStack.ThisVNF isto interactwithEPConthestandardSGi interface(toLTEPGW). TheExperimentermustdevelopanAndroidapp thatwould interactwiththisserverapplication.UoSwillprovideanAndroid libraryaswellas theAPI topassand receivemessages to/from the server application that the Experimenters are todevelop.
• TheExperimentersaretosubmittheirappasanAPKtoUoSatthefollowingcontact:Dr.SerdarVural([email protected]).
• AdditionalfunctionalityforreservationofmobilephonesremotelyisavailableviathePhysical ResourceManager of the SoftFIRE ExperimentManager. This also providestheexperimenterwithsomeremotecontrolcapabilitiesofthemobilephone.
• The UoS RAN or core network infrastructure cannot be modified to fit specificpurposes of an experiment. Exceptions can be made for exceptionally interestingexperimentsthataddadditionalcapabilitytotheinfrastructure.
• TheCPNVM(sharedbyallexperimenters)andtheUPNVMs(CCandCM)assignedtoanexperimenterareassignedspecific IPaddressesbyUoS.TheexperimenterVMs, iftheyneedmobiledataconnectivity,cantalktothemobilecoreontheseIPaddresses.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page32of49
• ExperimenterAndroidappsmustbecompatiblewithstock(Google)Android>=7.1.1.UoScanprovideonemobileforeachexperimenter,ormultiplemobilesdependingonthenumberofsimultaneousexperimentersusingtheUoSequipment.
MobileDeviceRequirements
TheUoSrequirestheuseofmobilesforlivetestingthatsupportthefollowingbasicfeatures:
Aspect Specification Comment
OS Stock Android >=7.1.1required!
Easier todevelop research codewithmoreparametersexposedthaniOS
LTEBands
B20 These bands operate on Femto cell RAN equipmentconnectedtoSoftFIRE’ssoftcore.
Wi-Fi 802.11ac TheUoShas802.11acandmostpreviousgenerationsofWi-Fisupport
Category 5,6 A minimum of category 5 is essential to support theCarrier Aggregated LTE-A RAN in order to get the bestspeedsfromthedeployedRAN.
2.4.2. PhysicalResources
2.4.2.1. FOKUS
TheFraunhoferFOKUStestbedprovidesaccesstoaphysicalLTEeNodeBfemtocellandPCorAndroidbasedUEthatcanbeusedbyexperimentersiftheyvisittheTestbedlocatedinBerlin.Experimenters can also bring their own LTE equipment to be used with the experiment.However incaseofowneNodeBdevicespleasebase inmindthatFOKUSTestbedhasaveryrestrictivelicenseinregardtofrequencybandandtransmissionpower.
Device Vendor LTEBands Qty Notes
Phone GoogleNexus5 * 1 Android6
Phone SamsungS4 * 2 Android6
PC-Dongle HuaweiE3372 13,7,* 2
LTEeNodeB Ip-access 13,7 1 LTERelease10
WiFiAP Various 802.11ac OnRequest
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page33of49
2.4.2.2. UniversityofSurrey
UniversityofSurreyprovidesanindoorLTEfemtocelland6WiFiaccesspointsovertwofloorsof the 5GIC building. The following table summarises the available physical resources.Experimentersshouldnotethat5GIChaslicenseforLTEFDDBand20.
Device Vendor LTEBands Quantity Notes
Phone GooglePixel 20 3 Android7.1
LTEFDDFemtocell
ip.access 20 1
WiFiAP Aruba 802.11ac 6 SeparateWiFiSSIDforSoftFIREexperimenters
TousethephysicalresourcesoftheUoStestbed,theexperimentersaretoprovideanAndroidapp.UoSstaffwillplacethethreemobilephones ina fixed location–theuseof themobilephones are tobe sharedbymultiple experimenters.However, dependingon thenumberofexperimentersrequiringmobilephones,therecanbedifferentscenariosregardingtheuseofthemobilephones:onephoneperexperimenter,orsharedmobilesamongexperimenters.
TheUoS testbedprovides a set of 5G capabilities;mainly control anduser plane separation(CUPS),aswellasan improveduserplaneslice.Theapptobedesignedbyanexperimenterneeds to include a library APK provided by UoS, and two special simple identifiers tosend/receiveapplicationmessagesto/fromthenetwork.
5GIC provides a separate virtual user plane (UP) for each experimenter on its OpenStackenvironment, with amaximum of 3 UP slices, i.e. 3 experimenters at a timewhen all suchexperimentersrequiretheuseofavirtualmobilecorenetwork.
The experiment scenario that uses the 5GIC testbed (radio access network, the virtual coreVM, and theUP slice) is a client-server application, inwhich auser app runningonAndroidmobilephone(s) communicateswitha serverapplication runningonavirtualmachine (VM).Sincethisisawell-testedscenario,UoSrequiresexperimenterstofollowthisscenario,shouldtheywishtousethephysicalresourcesinUoS.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page34of49
3 HowtouseSoftFIRE
TheSoftFIREMiddlewareprovidestotheexperimenterdifferentAPIs.TheusageoftheseAPIsisdescribed inthefollowingsections.Thispartof thedocumentwillguidetheexperimenterthrough the process of designing, provisioning and terminating the experiment. TheexperimentoverviewstepsaredescribedinFigure8anditdefinesthestepsoftheexperimentlifecycleandtheusualexecutionorder.
Figure8:ExperimentLifecycle
However,atthetimeofwritingthistutorial,newdevelopmenthasbeendoneontheSoftFIREmiddleware.Forthatreason,wesuggesttofollowthemoreuptodateSoftFIREExperimenterguidelinesandusagemanual,alwaysavailablehereatourdocumentationwebsite[5].
ThelifecycleofanexperimentisdepictedinFigure8:
• Designphaseo Listresources:listingalltheavailableresources.o Define the experiment: based on the previous step, decidewhat to reserve
anddefinetheexperimentinordertofulfilyourrequirement.• Provisionphase
o Resource reservation and provisioning: first reserve a timeslot to access theresources(inthecaseofLTEandotherradioresourcesanexclusiveaccess isofimportancetoavoidinterferences).Thendeploytheexperimentdefinedinthepreviousstep.
• Runtimephaseo Resourcemonitoring:oncedeployed,ifthemonitoringoftheresourceswere
selected in the previous steps, it will be possible to monitor the deployedresourcesusingamonitoringserverdedicatedtotheexperimenter
o Resourcecontrolatruntime:Itisalsopossibletoaccessremotelysomeofthevirtual resources when deployed correctly and additionally some externalservices,suchasautoscalingwillbeavailable.
• Closingphaseo Resource termination: when the experiment is finished, either because the
timehasexpiredorbecausetheexperimenterhasfinished,theresourceswillbereleased.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page35of49
3.1 GettingAccesstotheplatform3.1.1. GetOpenVPNcertificate
OpenVPN is used to provide access to the SoftFIRE network based on certificates. EachacceptedexperimentwillreceiveacertificatethatcanbeusedtoaccesstheOpenVPNservicefor the duration of the open call period. The certificate will be generated by the SoftFIREPortal,pleasefollowthefollowingstepstoretrieveyourpersonalcertificate.
1. RegistertotheSoftFIREportal2. Getacceptedbytheconsortium3. DownloadtheOpenVPNconfigurationfilefromtheSoftFIREportal
IftheautomaticgenerationofOpenVPNconfigurationfilefailsorifyourclientsoftwareneedsadifferentformatofconfigurationfile,additionaldocumentationisavailableontheSoftFIRESoftwaredocumentationwebsite3.
3.1.2. OpenVPNsetup1. InstallanOpenVPNclientmatchingyouroperationsystem
o Linux:openvpnpackagesavailablefromthedistributionsrepositoryo MacOS:variousversionsavailable,wehavetested“tunnelblick”o Windows: OpenVPN-GUI was tested by us but the usage of windows is not
recommended2. ImportthedownloadedconfigurationfileintoyourchosenOpenVPNclientapplication3. ConnecttotheVPNserverusingtheclientapplication
3.1.3. RegistertoExperimentManager
TheregistrationofanExperimentertotheExperimentManagerwillbedoneautomaticallysothereisnotanyrelevantinformationregardingthismatterthatconcernstheExperimenter.Innext releases of this document wewill provide details for platform extension developmentpurposes.However,alwaysbeuptodatebyusingthisdocumentationavailableonline[5].
3http://docs.softfire.eu/openvpnconfig/
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page36of49
3.2 RunningtheexperimentFigure 7 defines the interactions between the Experimenter and the SEM. These steps aredescribedinthefollowingsubsections.ThereferencepageistheExperimenterPageshowninFigure9.
Figure9.SEMExperimenterpage
Inthefollowingsections,wewillrefertothetestbeds.EachtestbedasastringidthatwillbeusedintheTOSCApropertiesofsomenodes.
• ericsson:RMEDCloudLabfromEricsson,locatedinRome• fokus:FUSECOPlaygroundfromFOKUSFraunhofer,locatedinBerlin• surrey:5GICfromUniversityofSurrey,locatedinGuildford,Surrey• ads:AssemblyDataSystemTestbed,locatedinRome• dt:DeutscheTelekomTestbed,locatedinBerlin
3.2.1. Designphase
Duringthisphase,theExperimenterisrequiredtodefinehisexperiment.ThisrequiresthattheExperimenterisawareoftheavailableresources.
3.2.1.1. Resourcediscovery
First step is to list which resources are available to be requested. In Figure 9 the availableresources are listed in the left of the orange and grey table. This list has three importantcolumns:
• Name:Thisisanidoftheresourceandmustbeusedlaterwhendefiningtheexperiment
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page37of49
• Description:Thisisadetaileddescriptionoftheresource.Pleasereaditcarefullybeforedeployingtheresource,sinceitmaynotfityourrequirements
• NodeType:thisfiledistheTOSCAnodetypeassociatedtothatresource.
3.2.1.2. Experimentdefinition
Once you are aware of the available resources, you can start defining the experiment. Theexperiment is definedusing Topology andOrchestration Specification for CloudApplications(TOSCA)[4].Inparticular,theExperimenterhastocreateaCSAR[10]zipfilecontainingallthenecessaryfilesanddefinitionsforlettingtheExperimentManagerinstantiateeverything.ThestructureoftheCSARisdefinedasfollowing:
├──Definitions|└──experiment.yaml├──Files|└──nsd.csar└──TOSCA-Metadata├──Metadata.yaml└──TOSCA.meta
Therearethreetwomandatoryfoldersplusoneoptional.DefinitionsandTOSCA-Metadataaremandatoryfoldercontainingthemetadatafilesandtheexperimentdefinition,asdescribedinthe following sections. The Files folder contains some additional files needed in case someresourcesspecifyextrarequirements.
3.2.1.2.1. TOSCA-Metadata
The TOSCA-Metadata folder contains the TOSCA.meta file and the Metadata.yaml file. TheTOSCA.meta file must contain the reference to the template in this case Entry-Definitions:Definitions/experiment.yaml.
Forexample:
TOSCA-Meta-File-Version:1.0CSAR-Version:1.1Created-By:MyCompanyEntry-Definitions:Definitions/experiment.yaml
TheMetadata.yamlcontainsexperimentMetainformation:
• thename• thestartdate• theenddate
Asfollows:
name:ExperimentNamestart-data:"9/5/17"end-data:"10/5/17"
3.2.1.2.2. Definitions
The experiment.yaml must follow a specific structure. An example is show in the followinglines:
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page38of49
tosca_definitions_version:tosca_simple_yaml_1_0description:TemplateforSoftFIREyamlresourcerequestdefinitionimports:-softfire_node_types:http://docs.softfire.eu/etc/softfire_node_types.yamltopology_template:node_templates:zabbix_server:type:MonitoringNodeproperties:resource_id:monitoringtestbed:ericssonsdn_ericsson:type:SDNResourceproperties:resource_id:sdn_ericssontestbed:ericssoniperf:type:NFVResourceproperties:resource_id:iperfnsd_name:TheIperfNSDtestbeds:{ALL:ericsson}
Asshownintheexample,theSoftFIREexperimentyamlfilemustcontaintheTOSCAdefinitionversion as tosca_definitions_version: tosca_simple_yaml_1_0. This line isfollowedbyadescriptionoftheexperiment.
The imports section must be specified as in the example because the EM will only acceptspecificnodetypesdefinedin[11]
Eachnodetypespecifiesaresource_id thatmustbechosenfromtheavailableresources.Thenodenameisarbitrary.Eachnodetypecanhavesomeadditionalpropertiesandtheycanbedifferent fromeachother’s. Check thenode type specification [11] tounderstandall thenodetypes.
3.2.1.2.2.1 NFVResource
TheNfvResourcenodetypeisdefinedasfollows:
NfvResource:derived_from:eu.softfire.BaseResourcedescription: "Defines a NFV resource request in the SoftFIREMiddleware"properties:testbeds:type:mapentry_schema:description:"mappingbetweenvnftypesandtestbed.Or'ANY':<testbed_name>forallinone"type:stringnsd_name:type:string
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page39of49
description:"NameoftheNStodeploy"file_name:type:stringdescription: "relative path to the Open Baton CSAR. It isalwaysstartingwithFiles/..."required:falsessh_pub_key:type:stringrequired:falsedescription:"thepublicsshkeythatwillbeinjectedintheVMinordertogiveaccesstotheexperimenter"
Thisnodetypehasdifferentproperties:
• resource_id:Theresourceidthatcanbefoundfromthelistresourcetable.• testbeds:amapwhereyoucandefinethetestbedwhereeachVNFwillbedeployed.It
isdefinedasvnftypeandtestbedname• nsd_name:thenameoftheNS• file_name:incasethepreconfiguredNSarenotsufficientforyourexperimentyoucan
uploadyourownNSinCSARformatandplaceitintheFilesfolder.Thisfieldcontainsthenameofthefile
3.2.1.2.2.2 SDNResource
TheSDNResourcetypeisdefinedasfollows:
Copydefinitionhere
SDNResource:derived_from:eu.softfire.BaseResourcedescription: Defines a SDN resource request in the SoftFIREMiddleware
TheSDNResourcetypedoesnotprovideanyadditionalpropertiesbesidestheoneinheritfromtheBaseResourcetype:
• resource_id:Theresourceidthatcanbefoundfromthelistresourcetable.DependingonthisidthetestbedthatisusedtoprovidetheSDNresourceimplicitischosen.
3.2.1.2.2.3 MonitoringResource
TheMonitoringResourcenodetypeisdefinedasfollows:
MonitoringResource:derived_from:eu.softfire.BaseResourcedescription:DefinestheZabbixmonitoringresourcerequestedproperties:testbed:type:stringrequired:falsedescription: Location where to deploy the monitoringserver
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page40of49
Thisnodetypehasthefollowingproperties:
• resource_id:Theresourceidthatcanbefoundfromthelistresourcetable• testbed:thetestbedwhereyouwanttheZabbixservertobedeployed.
3.2.1.2.2.4 SecurityResource
TheSecurityResourcenodetypeisdefinedasfollows:
SecurityResource:derived_from:eu.softfire.BaseResourcedescription:DefinesaSecurityagenttobedeployed.Moredetailson*docu_URL*properties:resource_id:type:stringrequired:truedefault:firewalltestbed:type:stringrequired:falsewant_agent:type:booleanrequired:truedefault:truelogging:type:booleanrequired:truedefault:trueallowed_ips:type:listentry_schema:type:stringrequired:falsedenied_ips:type:listentry_schema:type:stringrequired:falsedefault_rule:type:stringrequired:true
Thisnodetypehasdifferentproperties:
• resource_id:DefinesthetypeoftheSecurityResource.Todateonlyfirewallisaccepted
• testbed:DefineswheretodeploytheSecurityResourceselected.Itisignoredifwant_agentisTrue
• want_agent:DefinesiftheExperimenterwantsthesecurityresourcetobeanagentdirectlyinstalledontheVMthatshewantstomonitor
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page41of49
• logging:DefinesiftheExperimenterwantsthesecurityresourcetosenditslogmessagestoacollectorandshewantstoseethemonadashboard
• allowed_ips:ListofIPs(orCIDRmasks)allowedbythefirewall.[allowfromIP]• denied_ips:ListofIPs(orCIDRmasks)deniedbythefirewall[denyfromIP]• default_rule:Defaultruleappliedbythefirewall(allow/deny)
3.2.1.2.3. Files
ThisfoldercontainsaninnerCSARofaNS.ThisisonlyusedincasetheNFVResourceyouwantto deploy is not one of the preconfigured one. In this case, the how to build this CSAR isexplainedin[9].AndtheNfvResourcefile_namefieldmustpointtothisfile.
Moreover,thereissomeadditionalinformationthatcanbeconfiguredandthatarespecificoftheSoftFIREplatform.ThevimInstanceName fieldcancontainzeroormoreofthefollowingoptions:
• vim-instance-fokus,inordertodeployinFokustestbed• vim-instance-er,inordertodeployinEricssontestbed• vim-instance-uos,inordertodeployinSurreytestbed• vim-instance-ads,inordertodeployinADStestbed• vim-instance-dt,inordertodeployinDeutscheTelekomtestbed
Ofcourse,thesetestbedsarelimitedbytheavailability.TherulesofchoicewillfollowtherulesdefinedintheOpenBatondocumentation[3].
Therearenospecificconstraintsforwhatconcernsthenetworks.
3.2.2. Provisionphase
3.2.2.1. Resourcereservationandprovisioning
Once theexperimentCSAR isuploaded, the resource reservation is done.Under theorangeandgreytable,therewillbeanothertableshowingtheuploadedexperimentwithabuttontodeployit.Byclickingit,theexperimentpreviouslydefinedwillbedeployedandshortlyyouwillbeabletoaccessit.ThestatuswillthenbecomeACTIVE.
3.2.3. Runtimephase
3.2.3.1. Resourcemonitoring
In case you have asked for amonitoring resource, youwill receive an Ip of a Zabbix serverwherealltheVMsareregistered.InthisZabbixserveryouwillhavefulladminrightsandyouwillbeabletomonitoryourresources.
3.2.3.2. Resourcecontrolatruntime
Itwill be given thepossibility to the experimenter to access his ownVMs through SSH. Theaccesswillbecontrolledby theusageof certificatesand isonlypossiblewithin theSoftFIREVPN.ByusingtheVPN,theexperimentergainsdirectaccesstohisvirtualnetworkfunctions.
IncaseofanyissuesrelatedtotheSoftFIREinfrastructure,pleaseseeSection4andSection5.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page42of49
3.2.4. Closingphase
3.2.4.1. Resourcetermination
For releasing theresources,youhavetoput theexperiment id in thereleaseresource inputfield on the right side of the Experimenter page, and click on the button. If the enddate isreachedbeforeyoureleasetheresources,theresourceswillbeautomaticallyreleased.
ThecollectionofmonitoringinformationisaresponsibilityoftheExperimenter.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page43of49
4 SoftFIREsupporttoexperimenters
TheexperimentercanrequiresupportrelatedtotheusageofthefederatedtestbedsbymeansofaFirstLevelSupportsystems(e.g.TroubleTicketSystem),implementedwithREDMINEToolaccessibleatthefollowingaddresshttps://redmine.softfire.eu/
Beforeopeninganewcase,itisrecommendedtoverifyinREDMINEifsimilarcaseshavebeenrecentlyissued(https://redmine.softfire.eu/projects/softfire/issues).
4.1 SubscriptionThe selected experimenter is configured in Redmine tool portal with proper credentials inordertoruncasesubmissions.TheRedmineportalwillprovideexperimenterwithcredentialviamailnotificationatthestartoftheopencall.Thesubscriptionwilllasttill15daysaftertheclosureofopencall.
4.2 CasesubmissionandfollowupOnce entered in Redmine (Figure 10: Redmine home for SoftFIRE) with the assignedLogin/PasswordjumptotheSoftFIREProject:
Figure10:RedminehomeforSoftFIRE
Hereyoucancheckthecurrentissuesoropenanewone(Figure11:Issuestracking)bymeansofthefollowingTabs:
Figure11:Issuestracking
Toopenanewcase,from“NewIssue”tab(Figure12:DescribingaNewIssue)youaccesstothepageinthepicturebelowwhereyouhaveto:
1. Selectamongtwooptions:BugorFeatureSupport2. AssignashortandsignificantsloganintheSubjectfield
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page44of49
3. Writeanaccuratedescription,indicating:a. STR:StepstoReproduceb. BD:BugDescriptionc. ER:ExpectedResult
4. ChoosetherightCategory,consideringwhereyouneedassistance5. SetaprioritybasedonitsUrgency(Normalasdefault),thatwillbethenrevisedbythe
receiver6. Ifanyfilecanbettersupportthecase,attachitintheFilesfield,clickingon“Browse…”.
Ifyouwanttoaddasnapshotinthetextdescriptionyouhaveto:a. attachtherelated.JPGfilebyclickingon“Browse…”clickonthe“Image”Icon
and“!...!”willbeaddedinthedescriptionb. Copythe“FileName.JPG”ofthepicturebetween“!...!”
Figure12:DescribingaNewIssue
Check ifeverything is filled incorrectlybyclickingon“Preview”and finalize itbyclickingon“Create”.
Ifyouneedtoupdateyourownissue,gounderIssueTabclickontheItemandthenon
4.3 WorkflowThe just opened Cases will be immediately notified to a reference person for eachInfrastructure: they will analyse it and, based on its description, will assign it to the mostsuitable responsible for follow up (stepping the item in “In Progress” status, asking forFeedback if something unclear or moving to resolved if a solution has been identifiedmeanwhile).
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page45of49
TheCasewillfollowtheworkflowdescribedinFigure13:Processfortrackingissues(onlytheInfrastructureOwnerscandirectlyRejectorClosetheissue):
Figure13:Processfortrackingissues
4.4 ServiceStandardsThePlatformwillbeoperationalduringthesetimeframes:
Workinghours:10:00a.m.to5:00p.m.CEST
MondaytoFridayGMT
Outsidethistimeframe:issues/requestswillbeemailedandmanagedatbesteffort
Pleasecheckyourlocaltimecorrespondence(http://www.worldtimebuddy.com/)
4.5 SupportContacts
Partner ContactSurreySystem [email protected]
SurreyIT/Enterprise [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page46of49
5 SoftFIREGeneralUse
SoftFIRE can be used by experimenters that have applied to Open Calls as well as fromorganizationsorentitiesthatwanttoexperimentontheplatformoutsideoftheprocessoftheOpen Calls. For the use of the testbed there are general rules that are described in thefollowingsectionsandgenerallyapply.
5.1 ConstraintsontheExperimentersUseThe SoftFIRE infrastructure is composed by loosely integrated platform under differentadministrativedomains.Inaddition,thedifferentplatformsareranforexperimentalpurposesandtheyarenotyetconsideredamassproductiontool.Thismeansthatbugsandissuesintheplatformbehaviourcanoccurandwilloccur.Actually,thescopeoftheexperimentsisalsotosupportthetuneupandtheassessmentoftheplatformasawhole.
ThePlatformisstillunderdevelopmentandithasabasicsetoffunctionalitiesthathavetobetunedupanditismissinganumberoffeaturesthatwillbeprogressivelyaddedinthefuture.SoftFIRE is by nomeans to be considered a product and so the usual support for softwaredevelopmentcannotbegranted.
Even if SoftFIRE aims at programmers, not all the features to allow for a fast programmingapproachareprovided.This isduetodifferences in thecomponent testbedsandtosecuritycontrols imposedbydifferentadministrativedomains.Theprogrammingphasescould resultcumbersomeandnotparticularlyattractive;howevertheymayimprovealongthelifetimeoftheproject.
Servicelevelagreements(SLA)donotapplyduringtheexperimentationphases.Becausethisisa period to test and explore SoftFIRE, the experimenters should not run productionapplicationsontheinfrastructurePlatformduringthetrial.
TheSoftFIREprojectreservestherighttodiscontinueatanytimetheserviceiftheuseisnotconsistentwiththepurposeofSDN/NFVand/orviolateanyaspectsof infrastructuresecurityorshallconflictsanyongoingexperimentation.
Duringtherunningperiodoftheexperiments,theSoftFIREprojectwillputinplaceateamthatwill support the experiments in theirwork on the platform. As said this is not offered as aprofessionalserviceanditsworkingwillbeonthebaseofbesteffort.Theentireinfrastructureshould be considered more a sort of α-test platform. Possible downs could occur withoutnoticeorduetooverloadcausedbyparallelexperiments.
SoftFIRE will offer expertise available by email (with possible follow-up by phone) and twohours per day during the experimentation phase in order to collect issues and provideresponses.We’ll try to providemost of the answers by 24 hours (typically nextmorning orafternoon).Someissuescouldbenotsolvableduetotheshorttimeoftheexperimentperiodor due to the need to intervene on the platform. The supporting time will work withexperimentersforcircumventanyproblem.
Theprojectwillalsoissuelimitsandconstraintsontheallocationofavailableresources.Thisisdue to theneed tosupportandallowparallelexperimentations. This limitationdependsonthe total capabilitiesof the federatedplatformaswell as thenumberof experimenters andtheirrequestsintermsofresources.TypicallimitationcouldberelatedtothemaxnumberofVMstobeinstanced,thenumberofphysicalresourcesusableorthemaxmemoryusableper
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page47of49
experimenters. Other limitations could apply, or be notified during the course of theexperimentations.
Paid support: If you have extensive support needs during the experimentation, you maypurchasepaid support for theSoftFIREPlatform.Thepaid supportpackageoffers increasinglevelsofhands-onsupportandresponsetime.
A few aids for the experimenters could be added in due time in the SoftFIRE portal athttp://www.softfire.eu
• An“on line” tutorialonhowtoaccessanduse theplatformwillbepreparedbeforetheexperimentationphase
• Apresentationwithausecase• Othereducationalmaterial
5.2 Additionalsupport
Formorepersonalizedservicesexperimentersarereferredtothe[5]aswellastothecontactpersonsontheSoftFIREwebsite.
Updated references will be posted in the Contact section of the SoftFIRE web sitehttps://www.softfire.eu/contact-support/.
The feedback from experiments will be of great use in order to assess thematurity of thesolutionsandtheirapplicabilityandpotentialtosupportbusinessrelatedimplementations,sothe project invites all the experimenters and users in being very proactive in providing thistypeofinformation.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page48of49
6 References
[1] FITEagle,“ASemanticResourceManagementFramework,”[Online].
[2] A.j.-b.f.f.t.f.jFED,“jFed,”[Online].
[3] Open Baton, “An open source Network Function Virtualisation Orchestrator (NFVO),”[Online].
[4] OASIS,“TOSCASimpleProfileinYAMLVersion1.0,”OASIS,2016.
[5] SoftFIRE, “SoftFIRE Experimenter Usage Manual Documentation,” [Online]. Available:http://docs.softfire.eu/.
[6] OpenStack,“Opensourcesoftwareforcreatingprivateandpublicclouds,”[Online].
[7] Zabbix,“TheUltimateEnterprise-classMonitoringPlatform,”[Online].
[8] ON.Lab,“BringingopennessandinnovationtotheInternetandCloud,”[Online].
[9] Open Baton, “TOSCA CSAR on-boarding,” [Online]. Available:https://openbaton.github.io/documentation/tosca-CSAR-onboarding/.
[10]OASIS, “TOSCA Cloud Serivice Archive,” [Online]. Available: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csd03/TOSCA-Simple-Profile-YAML-v1.0-csd03.html#_Toc419746172.
[11]SoftFIRE, “Node Type definition,” [Online]. Available:http://docs.softfire.eu/etc/softfire_node_types.yaml.
[12]OpendayLight,“OpenSourceSDNPlatform,”[Online].
[13]ONOS,“OpenNetworkOperatingSystem,”[Online].
[14]FIRE,“FutureInternetResearchandExperimentation,”[Online].
[15]FED4Fire,“FederationforFutureInternetResearchandExperimentation,”[Online].
[16]OMF,“OpenManagementFramework,”[Online].
[17]ETSI,“NetworkFunctionsVirtualisation(NFV);,”ETSI,2014.
OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed
Date:2017-07-21 OC3:Guidelines,rulesandmechanismsgoverningtheusageoftheSoftFIRETestbed Page49of49
7 ListofAcronymsandAbbreviations
Acronym Meaning
CA LTE-ACarrierAggregation
CC UoS5GClusterMember
CM UoS5GClusterController
EMM EPSMobilityManagement
EPC EvolvedPacketCore(LTE-A)
GUI GraphicalUserInterface
HSS HomeSubscriberServer
IaaS InfrastructureasaService
LTE-A AdvancedLongTermEvolution
MME MobilityManagementEntity
NF NetworkFunction
NS NetworkService
PDN PacketDataNetwork
PGW PDNGateway
PoC PointofContact
PPE UoECUPSevolved combinedPacket Processing Entity including SGWuandPGWuNFentities
RAN RadioAccessNetwork
SFA Slice-basedFederationArchitecture
SGW ServingGateway
UoS UniversityofSurrey
VNF VirtualNetworkFunction