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



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



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.



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



5.1 CONSTRAINTSONTHEEXPERIMENTERSUSE..........................................................................465.2 ADDITIONALSUPPORT......................................................................................................47

6 REFERENCES...................................................................................................................48

7 LISTOFACRONYMSANDABBREVIATIONS.....................................................................49



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



ListofTables

Table1:EricssonHardwareStructureoftheTestBed................................................................15

Table2.FokusOpenStackHardware..........................................................................................20

Table3:NetworkEquipment......................................................................................................21

Table4:NetworkServicesProvidedbytheUoSTestbed...........................................................30



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.



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].



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.



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.



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”



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.



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;



• 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.



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



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.



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:



• 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.



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.



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.



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).



Figure7.Experimenterinteraction

2.3.1. NFVFeatures

TheexperimenterwillbedealingwithNFVResourcesineveryexperimentsinceNFVisthecoretechnology exploited in the SoftFIREMiddleware. The Experimenter can reserve and deploy



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



• 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/



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.



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



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/



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.



• 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



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.



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.



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/



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



• 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:



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



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



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



• 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.



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.



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



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).



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]



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



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.



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.



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

Date post:	14-Oct-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Guidelines, rules and mechanisms governing the usage of ... · OC3: Guidelines, rules and...

Documents