D2.42 Specification of the Network Function …...agnostic manner for later implementation of the...

T-NOVA|DeliverableD2.41 SpecificationoftheNetworkFunctionFrameworkandMarketplace

©T-NOVAConsortium

1

NETWORKFUNCTIONSAS-A-SERVICEOVERVIRTUALISEDINFRASTRUCTURES

GRANTAGREEMENTNO.:619520

DeliverableD2.42

SpecificationoftheNetworkFunctionFrameworkandT-NOVAMarketplace

Editor PaoloComi(Italtel)

Contributors AuroraRamos,JavierMelián(ATOS),ThomasPliakas(CLDST),SimonHohberg,YacineRebahi(Fraunhofer),MarcoDiGirolamo(HP),EnzoFigini,FaustoAndreotti(Italtel),AhmedAbujoda,PanagiotisPapadimitriou(LUH),EmmanuilKafetzakis,GeorgeXilouris(NCSRD),JoséBonnet(PTIN),DoraChristofi,GeorgiosDimosthenous(PTL),AthinaBourdena,EvangelosMarkakis,EvangelosPallis(TEIC)NicolasHerbaut,MamadouSidibe(VIO)

Version 1.0

Date September30th,2015

Distribution PUBLIC(PU)

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


©T-NOVAConsortium

2

ExecutiveSummary

This document reports the results of the activities carried out in T-NOVA EU-FP7 Project“Functions as-a-Service over Virtualised Infrastructures” by Tasks 2.5 ”Specification ofNetwork Function Framework” and Task 2.6 “Specification of T-NOVA Marketplace”. Itdescribes the requirements, featuresdescription andarchitectural details in a technology-agnosticmanner for later implementationof theNetworkFunctionFrameworkand theT-NOVAMarketplace. This report is the second and final version of the specification workreported in D2.41 thatwas delivered in September14. The current version includes slightrefinementsconsideringfeedbackfromoneyearofimplementationwork.

TheNetworkFunctionFrameworkistheconceptualelementoftheT-NOVAsystemdevotedtothedefinitionofthestructureandbehaviouroftheVirtualNetworkFunctions(VNFs). Itcomprises a Network Function Store, where the VNFs are kept andmade available to T-NOVA as building blocks for creating network services. Virtual Network Functions andnetwork Services in T-NOVA are described, traded, and offered to the final users by aninnovativeMarketplace thatopens theNFVmarket tosoftwaredevelopersand traditionalserviceprovidersforthebenefitoflargeadoptionofNFVsolutions.

A VNF is characterised by two attributes: the operational functionalities and themanagementbehavior.Theoperationalpartexplicitlydefinesthenetworkfunctionsthataresupported,whilethemanagementpartisresponsiblefortheVNFlifecycle.Therefore,aVNFin T-NOVA shall support the APIs for interacting with the T-NOVA orchestration and thevirtualizedinfrastructure,andshallimplementtheVNFlifecycledescribedinthisreport.TheVNFmetadataisafundamentalpartofeachVNF.ItprovidestheinformationfordescribinghowtheVNFiscomposed,whichfunctionalitiesitprovides,andhowtomanageit.Currentlythere are many approaches for implementing this concept which are focused on thetechnicalrequirementsformakingavirtualapplicationrunning.InT-NOVAthisinformationis extendedwith business aspects that allow the registration and trading of a VNF in themarketplace.

ThemarketplaceconcepthasbeenintroducedbyT-NOVAasanoveltyintheNFVschemeinorder to facilitate the interactionbetween thedifferent stakeholders thatare identified intheNFVbusinessscenarios.OnonehandtheVNFscanbeimplementedbyawiderangeofdevelopers providing software implementation, and on the other hand, network serviceprovidersmaywant toacquireVNFs to composenetwork services tobeprovided to theirown customers. The T-NOVA Marketplace has been designed as a distributed platformplaced on top of the overall architecturewhich, besides of including the users front-end,comprisesOSS/BSScomponentsasbillingandaccounting,andinnovativemodulesastheT-NOVABrokeragetoallowtradingfunctionality.

ThevirtualizationofnetworkfunctionsisbeingaddressedbynotablestandardizationbodiessuchasETSIandIETF.InparticularETSIhasdevelopedaNFVreferencearchitectureandhasprovidedacommonlanguageinthisarea.Therefore,thisreportlooksatETSItobuildonit.TheT-NOVAMarketplacespecificationreliesalsoonongoingstandardizationactivitiessuchas business best practices provided byTMForum, as it is for instance the integration of abusinessservicecatalogueandSLAManagementissuesinvirtualization.


©T-NOVAConsortium

3

TableofContents

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

1.1.MOTIVATIONANDSCOPE.....................................................................................................71.2.RELATIONTOT-NOVAOVERALLARCHITECTURE.......................................................................71.3.DOCUMENTSTRUCTURE.......................................................................................................9

2.SPECIFICATIONOFTHET-NOVAMARKETPLACE............................................................10

2.1.OBJECTIVE.......................................................................................................................102.2.STATEOFTHEART.............................................................................................................10

2.2.1.Standardizationactivities......................................................................................112.2.1.1.ETSIISGNFV..................................................................................................................................112.2.1.2.TMForum......................................................................................................................................122.2.1.3.ApplicabilityofTMForumstandardstoETSINFV.........................................................................132.2.1.4.UpdateonTMForumNFVrelatedworkJanuary’15-July2015....................................................14

2.2.2.Otherprojects........................................................................................................162.2.3.Commercialproducts.............................................................................................162.2.4.Conclusions............................................................................................................17

2.3.T-NOVASTAKEHOLDERSINTERACTINGWITHTHEMARKETPLACE..............................................172.3.1.Subscriptionmanagement.....................................................................................182.3.2.Tradingmechanisms..............................................................................................19

2.4.T-NOVAMARKETPLACEUSECASES-LIFECYCLE......................................................................202.5.REQUIREMENTSFORT-NOVAMARKETPLACE........................................................................222.6.SPECIFICATIONOFTHET-NOVAMARKETPLACEARCHITECTURE:COMPONENTSANDINTERFACES....23

2.6.1.ExternalInterfacestotheT-NOVAMarketplace...................................................242.6.1.1.Orchestrator.................................................................................................................................242.6.1.2.NetworkFunctionStore(NFstore)...............................................................................................25

2.6.2.Marketplacemodulesspecification.......................................................................252.6.2.1.Dashboard.....................................................................................................................................252.6.2.2.Accesscontrol(AA).......................................................................................................................292.6.2.3.Brokeragemodule........................................................................................................................312.6.2.4.BusinessServiceCatalogue...........................................................................................................342.6.2.5.ServiceSelectionmodule..............................................................................................................342.6.2.6.SLAmanagementmodule.............................................................................................................352.6.2.7.Accountingmodule.......................................................................................................................382.6.2.8.Billingmodule...............................................................................................................................39

3.NETWORKFUNCTIONFRAMEWORK.............................................................................42

3.1.HIGHLEVELDESCRIPTION....................................................................................................423.2.NFCOMMONCOMPONENTS..............................................................................................44

3.2.1.NFstructureandproperties...................................................................................443.2.1.1.VNFcomposition...........................................................................................................................45

3.2.2.MetadatainT-NOVA.............................................................................................473.2.3.T-NOVANFFrameworkandETSINFVcomparison................................................48

3.3.NFLIFECYCLE...................................................................................................................543.3.1.Development.........................................................................................................563.3.2.Validation..............................................................................................................563.3.3.Publication.............................................................................................................563.3.4.BrokerageandSelection........................................................................................583.3.5.Deployment...........................................................................................................583.3.6.Management.........................................................................................................58

3.3.6.1.Set-up............................................................................................................................................593.3.6.2.Start..............................................................................................................................................60


©T-NOVAConsortium

4

3.3.6.3.Stop...............................................................................................................................................603.3.6.4.Scaling...........................................................................................................................................603.3.6.5.Monitoring....................................................................................................................................62

3.3.7.Termination...........................................................................................................633.3.8.T-NOVAvsETSINFVlifecycle.................................................................................64

3.4.NETWORKFUNCTIONFRAMEWORKAPIS..............................................................................683.4.1.APIshighlevellogicaldescription..........................................................................683.4.2.NetworkFunctionStoreAPIs.................................................................................683.4.3.VNFAPI..................................................................................................................69

3.5.NETWORKFUNCTIONSTOREDESIGN....................................................................................69

4.INTERACTIONBETWEENNETWORKFUNCTIONFRAMEWORKANDTHEMARKETPLACE71

4.1.PURCHASEOFVNFS..........................................................................................................714.2.MARKETPLACE–FUNCTIONSTOREINTERFACES......................................................................71

5.CONCLUSIONS..............................................................................................................73

5.1.SUMMARY.......................................................................................................................735.2.CONTRIBUTIONSTOSTANDARDS..........................................................................................735.3.FUTUREWORK.................................................................................................................74

6.ANNEXES......................................................................................................................76

6.1.ANNEXA-REQUIREMENTSSPECIFICATION............................................................................766.1.1.Detailedmarketplacecomponentsrequirementsspecification............................786.1.2.DetailedNetworkFunctionStorerequirementsspecification...............................91

6.2.ANNEXB.DASHBOARDMOCK-UP.......................................................................................93

7.REFERENCES...............................................................................................................103

8.LISTOFACRONYMS....................................................................................................105

IndexofFigures

Figure1-1RelevancetoT-NOVAOverallArchitecture..............................................................8Figure2-1ETSINFVarchitecture.............................................................................................12Figure2-2.StakeholdersinteractinginT-NOVAMarketplace................................................18Figure2-3Marketplacelifecyclefromthecustomer’sperspective........................................20Figure2-4Marketplacearchitecture.......................................................................................23


©T-NOVAConsortium

5

Figure2-5Dashboardviews....................................................................................................26Figure2-6.RBAChighlevelarchitecture.................................................................................30Figure2-7Tradingprocess......................................................................................................32Figure2-8Brokeragemoduleinternalarchitecture................................................................33Figure2-9BusinessServiceCatalogue....................................................................................34Figure2-10ServiceSelectionOverallArchitecture.................................................................35Figure2-11SLAlifecycle..........................................................................................................37Figure12:Cyclopsmicro-serviceArchitecturerepresentation...............................................40Figure3-1.VNFframeworkhighlevelarchitecture................................................................43Figure3-2.VNFframeworkdetailedarchitecture...................................................................44Figure3-3.VNFhigh-levelstructure........................................................................................45Figure3-4.VNFinternalcomponents.....................................................................................45Figure3-5.VNFcomposition...................................................................................................46Figure3-6.VNFinternalcomponentsinmultiVNFCsVNF.....................................................46Figure3-7.VNFServiceGraph.................................................................................................47Figure3-8.VirtualisationofnetworkfunctionsinETSI...........................................................48Figure3-9.ManagementandorchestrationofNFVsinETSI..................................................49Figure3-10.NFVarchitecturalframeworkandinterfacesinETSI...........................................50Figure3-11.T-NOVANFVstructuremappingtoETSIframework...........................................51Figure3-12.VNFlifecycle........................................................................................................55Figure3-13.ExtendedVNFlifecycle........................................................................................55Figure3-14.VNFpublicationintheNFStore..........................................................................57Figure3-15.VNFwithdrawalfromtheNFStore.....................................................................58Figure3-16.VNFset-up...........................................................................................................59Figure3-17.VNFstart.............................................................................................................60Figure3-18.VNFstop..............................................................................................................60Figure3-19.Scaling-outexample............................................................................................61Figure3-20.Scaling-out...........................................................................................................62Figure3-21.Scaling-in.............................................................................................................62Figure3-22.VNFmonitoring...................................................................................................63Figure3-23.VNFterminationorclean-up...............................................................................64Figure3-24.VNFinstancestatetransitions............................................................................65Figure3-25.NFStorearchitecture..........................................................................................70Figure6-1DashboardLoginScreen.........................................................................................93Figure6-2NewUserProfile....................................................................................................94Figure6-3ServiceProviderProfileScreen..............................................................................95Figure6-4ServiceProviderNewService1/2..........................................................................96Figure6-5ServiceProviderNewService2/2..........................................................................97Figure6-6CustomerScreen....................................................................................................98Figure6-7CustumerNewService...........................................................................................99Figure6-8CustomerExistingServices...................................................................................101Figure6-9ServiceProvider-RunningServices1/2................................................................101Figure6-10ServiceProvider-RunningServices1/2..............................................................102

IndexofTables

Table2-1MainT-NOVAMarketplacecomponentsdefinitions..............................................10Table2-2OverviewofTradingmechanisms...........................................................................20Table2-3Marketplaceexternalinterfaces.............................................................................24


©T-NOVAConsortium

6

Table2-4Marketplaceinternalinterfaces..............................................................................24Table2-5SPdashboardview..................................................................................................26Table2-6FPdashboardview..................................................................................................27Table2-7Customerdahsboardview.......................................................................................27Table2-8SLAperservice........................................................................................................36Table2-9SLAmanagementmoduleinformation...................................................................38Table2-10Accountingmoduleinformation...........................................................................39Table3-1T-NOVAsupportofETSIVNFfeatures.....................................................................53Table3-2ComparisonofT-NOVAwithETSINFVlifecycleoperations....................................67


©T-NOVAConsortium

7

1. INTRODUCTION

1.1. Motivationandscope

Network Functions Virtualization (NFV) constitutes a topic of immense interest to thenetworkingcommunityinthetheresearch/academicdomainbutalsoinindustrysinceit iscandidate approach for short-term exploitation. Via the concept of infrastructure“softwarisation”, NFV has the potential to entirely transform the networking market andopen it tonewentrants. In this context, T-NOVA introduces a completeopen solution forNFVdeployment, focusingon theVirtualNetwork Function (VNF) as a serviceperspectivewithastrongbusinessorientation.

Inorder toprovide thisbusinessorientation to theNFVschemeT-NOVAdevelopsanovelmarketplacethatwillfacilitateT-NOVAcustomerstoselectvirtualappliancesbymeansofafriendly front-end, “plug” them into their existing connectivity services, configure/adaptthemaccordingtotheirneedsand,inthecaseofnetworkserviceproviders,alsoallowthemtoofferNetworkServices(NSs)composedbyseveralVNFstotheirowncustomers[1].

Theservicerequestwillbecarriedoutviaatailoredcustomerfront-end/brokerageplatformthat ispartof theT-NOVAMarketplace.Thismarketplacewill alsoprovideall theT-NOVAstakeholdersSLAandbillingfunctionalities.

On the other hand, T-NOVA introduces an innovative Network Function Store (NF store)followingtheparadigmofalreadysuccessfulOS-specific“AppStores”.ThisNFstorecontainsVNFs by third-party developers, published as independent entities and accompaniedwiththenecessarymetadataforbothtechnicalandbusinessdescriptionoftheVNF.

SoftwaredeveloperswillingtoselltheirVNFsthroughtheT-NOVAmarketplaceshallextendtheir implementation of network functions supporting the APIs for interacting with thevirtualizedinfrastructureandtheT-NOVAorchestrationfortheservicecomposition[2],andtheVNFlifecycledescribedinthisdeliverable.

In this way, thanks to the NF store and themarketplace, it is expected that T-NOVAwillcontribute to expandmarket opportunities by attracting new entrants to the networkingmarket. This capability will be particularly important for SMEs and academic institutionswhichcanleveragetheT-NOVAarchitecturebydevelopinginnovativecutting-edgeNetworkFunctions (NFs) as software modules that can be included in the NF store. This also willenabletherapidintroductionofVNFsintothemarket.

1.2. RelationtoT-NOVAoverallarchitecture

T-NOVA overall architecture is described in previous deliverables [3]. The scope of thecurrentdocumentwithrespecttotheT-NOVAarchitectureisthedefinitionandspecificationof the (i) marketplace; (ii) network function store (NF store); (iii) VNFs and (iv) assortedinterfacesasgraphicallyillustratedinFigure1-1.


©T-NOVAConsortium

8

Figure1-1RelevancetoT-NOVAOverallArchitecture

Insummary,theT-NOVAMarketplaceisadistributedplatformplacedontopoftheoverallarchitecture which, besides of including the users front-end, it comprises OSS/BSScomponents as billing and accounting, and innovativemodules as the T-NOVA Brokerage,beinginchargeofmanagingallbusinessrelationshipsamongtheT-NOVAstakeholders(seesection2.3).

TheNFstoreismainlyarepositoryfortheVNFimagesandtheiraccompanyingmetadata.ItplaysanimportantroleintheVNFlifecyclemanagementasit isthecomponentwheretheVNFsarepublishedbydifferentNFdevelopers.

VNF lifecycle is also part of the scope for this deliverable. More specifically, informationrelated to VNF deployment, management and termination have interdependencies withvarious components of the overall architecture. Other stages of the lifecycle refer tointeractionbetweenthemarketplaceandtheNFstore.

Finally,theinterfacesasdefinedin[3]arealsospecifiedinthecurrentdocument.


©T-NOVAConsortium

9

1.3. Documentstructure

Thisdocumentisstructuredasfollows:

Firstly, Section2 focuseson the specificationof theT-NOVAMarketplace.Afteranoveralldescriptionoftheobjectiveinsection2.1,section2.2containsthestateoftheartanalysisoverwhich the specificationof the T-NOVAMarketplacehas beenperformed. Section2.3givesanoverviewonhoweachT-NOVAstakeholderwilliteractwiththesystemandSection2.4 summarizes the T-NOVAMarketplace lifecycle in order to provide the reader awholepicture of the marketplace functioning. The requirements gathering procedure isexplanained in section 2.5, while section 2.6 contains the proper specification of eachcomponentinthemarketplaceaccordingtotherequirementsspecificationslistedinAnnexA.

Section 3 is devoted to the specification of Virtual Network Function (VNF) structure andbehaviourandthedesignoftheNetworkFunctionStore(NFstore).Section3.1explainsthescopeofthesectionprovidinghighleveldescriptionofthesubsetoftheaddressedT-NOVAarchitecture.ThedescriptionoftheVNFstructureisthetopicofsection3.2.Itdescribesalsothe informationmodel of the VNFmetadata descriptor. A first comparative analysis withETSINFV isprovided.Section3.3completes theVNFdescriptionwith thedefinitionof thenetworkfunctionlifecycle.ThedescriptionofVNFstructureandbehaviouriscompletedbysection3.4providingthehighlevelspecificationoftheAPIssupportedbyboththeVNFandtheNFstore.Finally,chapter3.5outlinesthehighleveldesignoftheNFstore.

The objective of section 4 is to make clearer and remark the relation between themarketplaceandNFstore,bothfromafunctionalandarchitecturalpointofview.

Section5containstheconclusionsgatheredfromthecontentsofthisdocument.

Finally, Annex A provides the list of all the requirements gathered for the differentmarketplace components andNF store,whileAnnexB contains the initialmock-upof thedashboarddone inthespecificationwork;nextversionsandfinaldesignwillbe included infuturedeliverablesintheproject[4][5].


©T-NOVAConsortium

10

2. SPECIFICATIONOFTHET-NOVAMARKETPLACE

2.1. Objective

Themarketplace intheNFVscheme isan innovativeconceptthatT-NOVA introduceswiththeaimofpromotingtheVNFserviceofferingsandfacilitatingthecommercialactivityandfluent interaction among the different business stakeholders identified in [1]. Besides ofproviding the Graphical User Interface (GUI) for all of the stakeholders, the T-NOVAMarketplacewill facilitateall thenecessaryfeaturesrelatedtothemarketactivity,suchastrading,SLA(ServiceLevelAgreement)negotiationsandbilling.

ThecomponentsidentifiedinthepreviousworkinT-NOVA[3]thatarepartoftheT-NOVAMarketplaceandrepresentedinFigure1-1andhighleveldescribedinTable2-1:

Name DescriptionSLAManagementModule

Themarketplace functional entitywhich establishes and stores the SLAsamongalltheinvolvedpartiesandcheckingiftheSLAshavebeenfulfilledornotwill inform theaccounting system for thepertinentbillable items(penaltiesorrewarding).

AccountingModule

Themarketplacefunctionalentitywhichstoresalltheinformationneededfor later billing for each user: usage resources for the different services,SLAsevaluations,etc.

BillingModule The markeplace functional entity that produces the bills based on theinformationstoredintheaccountingmodule.

AccessControlModule

Themarketplace functional entitywhich administers security in amulti-userenvironment,managingandenablingaccessauthorization/controlforthe different T-NOVA stakeholders considering their roles andpermissions.

Dashboard The marketplace functional entity which provides the user front-end,exposinginagraphicalmannerallcustomer-facingservices.

BrokerageModule

The marketplace functional entity which enables the interaction amongactorsforserviceadvertisement,requestandbrokerage/trading.

Table2-1MainT-NOVAMarketplacecomponentsdefinitions

2.2. StateoftheArt

InordertodesignandlaterimplementthemarketplacecontextinT-NOVA,wehavefirstlylookedatthemostrelevantongoingstandardizationworkswhenapplyingnetworkservicesprovisionbusinessprocessestoNetworkFunctionVirtualization(NFV).InSep’14TMForumprovidedsomefirstinputsmappingtheirstandardizationdocumentaboutbusinessprocesstotheETSINFVMANOarchitecture[6].FurtherETSIandTMForuminsightsaresummarizedin2.2.1.

In section 2.2.2 recent research projects implementing amarketplace to provide networkservicesandotherprojectsfocusedinNFVandsoftwarenetworksaresurveyed. Insection2.2.3wesummarizeseveralcurrentcommercialsolutionsthatmaybealignedwithT-NOVAMarketplaceapproach.


©T-NOVAConsortium

11

Finally, in section 2.2.4 we extract some conclusions gathered from this state of art inrelationtoT-NOVAMarketplace.

2.2.1. Standardizationactivities

2.2.1.1. ETSIISGNFV

Anetworkoperator-led IndustrySpecificationGroup (ISG)was setup in the lastquarterof2012undertheumbrellaofETSI(EuropeanTelecommunicationStandardInstitute)toworkthroughthetechnicalchallengesofNFV.ETSIISGNFVinitsdocumentonglobalarchitecture[6] illustrates the high-level NFV framework, where three main working domains can beidentified:

- VNF, as the software implementation of a network function which is capable ofrunningovertheNFVI.

- NFVInfrastructure(NFVI),whichincludesthediversityofphysicalresourcesandhowthesecanbevirtualised.NFVIsupportstheexecutionoftheVNFs.

- NFVManagementandOrchestration (NFVMANO),which covers theorchestrationand lifecyclemanagement of physical and/or software resources that support theinfrastructure virtualisation, and the lifecycle management of VNFs. NFV MANOfocuses on all virtualisation-specific management tasks necessary in the NFVframework.

RelationtoT-NOVAMarketplace

As it has been described in the previous work to define overall T-NOVA architecturedescribedin[3],andaccordingtothediagramin

Figure 2-1, the marketplace is completely novel in regards to ETSI view [7]. T-NOVAintroduces the marketplace concept aiming at opening the NFV market to third partydevelopersfortheprovisionofVNFs,aconceptthatcurrentlyfallsoutsidethetechnicalviewofETSINFV.

Ontheotherhandandalsointroducedin[3],whereETSIMANOhasbeendeeplyexplained,ETSINFVdoesnotprovideyetanymoreinsightontheOSS/BSS(OperatingSupportSystem/Business Support System) of the operator besides the definition of an interface (Os-Ma).ThoughOSS/BSS systems are notwithin the scope of T-NOVA, the proposedmarketplacecontains partially some OSS/BSS functionalities (i.e. billing, accounting, SLA monitoring,Authentication,Authorisation,andAccounting(AAA)),whichwillbeimplemented/adapted.


©T-NOVAConsortium

12

Figure2-1 ETSINFVarchitecture

2.2.1.2. TMForum

ThegeneralobjectiveofTeleManagementForum[8],asaglobaltradeassociationofserviceprovidersandsuppliers, istheimprovementonbusinessagilityandthegrowthofbusinessthrough knowledge, tools, standard, training and best practices. The specific TM Forum’sAgileBusinessandITProgramaimsatoptimizeserviceproviders’operationsreducingcosts,risks, and time to market by providing a set of integrated offerings that collects theexperienceandbestpracticesgleanedfromthemajorplayerswithintheindustry.TheTMF’sstandards are collectively known as Frameworx, which is composed of four underlyingcomponents,eachaimedatstandardizinginformationmodels,interfaces,andlexicon:

- Business Process Framework(eTOM, Telecom Operations Map): the industry'scommon process architecture for both business and functional processes. Thisframeworkismeanttoaidinthecreationofacomprehensive,multi-layeredviewofall of the business processes necessary for a carrier’s operation. It provides bothguidelines and process flows, and aligns with standards from ITIL (InformationTechnologyInfrastructureLibrary)andotherexternalbodies.

- InformationFramework(SID,Shared Information/Datamodel):providesacommonreference model for enterprise information that service providers, softwareproviders and integrators use to describe management information. It is used todevelop databases and provide a glossary of terms for business processes. Theframework is intended to reduce integration costs and to reduce projectmanagement time and cost by minimizing the number of necessary changes tounderlyingarchitectureduringthelaunchofanewproductorserviceoffering.

- Application Framework(TAM, Telecom Application Map): it provides a commonlanguage between service providers and their suppliers to describe systems andtheirfunctions,aswellasacommonwayofgroupingthem.Itattemptstogrouptheinformation and processes defined by the eTOM and the SID into recognizableapplications.

- IntegrationFramework(TIP,TMForumIntegrationProgram(TIP):itshowshowthebusinessprocess,informationandapplicationframeworksinteractto:

T-NOVAMarketplace


©T-NOVAConsortium

13

o Create a catalog of business services that define functional and non-functionalaspectsofaservicebasedonserviceorientedprinciples;

o Develop a platformor domain-based enterprise architecture that providesthebusinessagilityrequiredtocompeteintoday'smarket;

o Definecriticalstandardinterfacesthatspeedintegration.

2.2.1.3. ApplicabilityofTMForumstandardstoETSINFV

TMForumZOOM[9] is the initiative launchedbyTMForum focused inNFV,whose TR227TM Forum Specifications document [10] contains a description of the set of TM Forumdocuments that are relevant for ETSINFVMANOwork. It identifies areaswhere each TMForumdocumentmaycontributetostandarizetheinformationpresentedandinterfacesofthe MANO reference points. Those that may be applicable to the specification of themarketplacearethefollowing:

eTOM:

- EnablesMANOtodesigninterfacesandAPIsthatbetterreflecthowanorganizationperformsconfiguration,monitoring,andotherprocesses.

- Enables MANO to achieve a better alignment between business processes of anorganizationandtheprocessflowsthataredefinedbyMANO.

- EnablesMANO toensure that the referencepoints that itdesignsareappropriateforthebusinessprocessesofanorganization.

SID:

- Provides detailed models in an object-oriented form that can be used to furtherdefineMANOserviceandresourceconcepts.

- Provides a detailed model of how services and resources are managed, includingdefinitionofmetricstorepresentkeycharacteristicsandbehaviourofservicesandresourcesaswellasSLAs.

- Provides a framework to design interfaces and APIs for various business andoperationalprocesses.

TIP:

- Createsacommonsharedintegrationenvironment.- Provides detailed interactions in the form of a set of messages exchanged as a

protocol.- Linksbusinessprocessestoinformationelements(e.g.,theSIDmodelelements).- Definesstandardizedtemplatesforthedevelopmentofnewinterfaces.- Increases interface reusability through addressing a broad set of business process

scenarios.


AnalysingthedocumentTR228TMForumGapAnalysisrelatedtoMANOWork[11]wecangather that one of the topics that TM Forumpoints out asmissing fromNFVMANO, is adetailed implementation model on how to manage operational and business supportsystems in a hybrid legacy and virtualized environment, something that ETSI is notaddressingsofar.

Thoughbeingoutof theT-NOVAscopethe interfacebetweentheMANOarchitectureandthe existing OSS/BSS system of operators, T-NOVA aims to provide a first step on the


©T-NOVAConsortium

14

directionof this research linebymeansof the implementationof themarketplace,whichwillimplementsomeofthefunctionalitiesofaBSSsystemofanexternaloperator,andwhatcouldbeafirstinputforlateststudiesintheinteroperabilitywithOSS/BSSexistingsystems,thatTMForumZOOMintendstoaddressinthefuture[8].

2.2.1.4. UpdateonTMForumNFVrelatedworkJanuary’15-July2015

AsstatedinthepreviousSOTAsurveyonSeptember2014[12]TMForumdidnotprovideatthat date specifications on NFV business management but generic business practices forbusinessagility,whichweconsideredtomakeT-NOVAMarketplacecompliancewith,suchtheSIDmodelandtheinclusionofabusinessservicecatalogue.

Also in December 2014 TMForum activity was surveyed within T-NOVA [4] specifically inrelation to service description, billing and SLAmanagement, when good practices or firstinsights towardsNFVwere still a set of objectivesof TMForumZOOMproject [9] thatweconsideredtobuildT-NOVAmarketplaceframework.

InFebruary2015,TMForumlaunches its firstresearchreportonNFV:Virtualization:WhenwillNFVcrossthechasm?[13].Morethantechnicalguidelinesthisreportsurveysmembersand other experts to explore when NFV will ‘cross the chasm’ to widespread availability,including:

- DefinitionofNFVbasedonETSINFVarchitecture.- Role of SDNin end-to-end provisioning and management of services over NFV

infrastructure.- BarriersforNFVtogetintothemarket.- ResultsofasurveyofserviceprovidersandindustryexpertsonthedriversforNFV,

thebusinessandtechnologicalinhibitors,planstoadoptaDevOps.

TMForumCatalystprojects

TMForumCatalystprojects[14]areintheformofWhitepapers,CaseStudies,BestPractices,lessons learned as input to provide to other teams through to Interface Specifications,Models, Frameworks&ReferenceCode. Inpreviouswork in T-NOVAmarketplace [12]weidentifiedoneofthemparticularlyinlinewithT-NOVAmarketplaceapproach:

- ServiceBundlinginaB2B2XMarketplace[15].ThisTMForumcatalystprojectaimsto show how a buyer can bundle a collection of services sourced from differentsuppliers and deliver them seamlessly to a customer. These components couldinclude traditional network access products, as well as NFV and IaaS products.Concretebusinessrolesandprocesstouchpointsenableawell-definedrelationshipamongplayersinthevaluechaintoensureseamlessdelivery.

More recent current TMForum catalysts projects that can be relevant to T-NOVAmarketplaceare:

- Maximizing Profitability with NFV Orchestration [16]: this catalyst aims todemonstrate how to instantiate,monitor and scale Virtualized Network Functions(VNF)basedontechnicalparameters (SLA,QoS,etc.)andbusinessmetrics (costofpower,etc.).

- NFV Management Ecosystem [17]: an implementation of management andorchestration(MANO)asdefinedbytheETSINFVISGistheplatformforthiscatalystto try to demonstrate real-time, dynamic management of capacity, performance,


©T-NOVAConsortium

15

qualityofservice(QoS)andservicelevelagreements(SLA)aswellasenablingreal-timebillingandcompensation.

TMForumreports

Recent TMForum reports that we have identified potentially relevant to T-NOVAMarketplacearethefollowing:

- IG1123NFVReadiness:PackagingVirtualizedNetworkServicesforProcurementandOperation[18].ThisguidereviewsthecurrentETSINFVtermswhichmightbeusedtodefineNFVpackagingconceptsusedbyServiceProviders (SP) forprocurement,packagingusedby suppliers sellingNFVcapabilities,packagingused todefineNFVsoftwaremodules,andpackagingfordeploymentofsoftwareimages.

- TR244TMForumInformationFrameworkEnhancementstoSupportZOOM[19].Thisdocument describes a portion of the ZOOM information model, which has beenintegratedintotheInformationFramework.Itdefinesfourconceptsfundamentaltomodeling NFV-based systems (VirtualResource, NetworkFunction, NetworkService,andGraph),aswellastwogeneral-purposeconcepts(CatalogandEvent)thathavebeen used by existing Catalysts, and are also critical for realizing SDN and NFVsystems. This report is further explained in T-NOVA servicedescription framework[20],whereitwillbedescribehowT-NOVAisapplyingSIDTMForummodeltoETSINFVapproach.

Focusing in SLA management in NFV, T-NOVA SLA specification work has been ahead ofTMForum,butinlinewithit,sinceithasbeenbuiltfollowingitsapproachasexplainedin[4]comingfromSLAmanagementincloudservices.InthelastyearTMForumhasreleasedthenexttworeports:

- IG1120 Virtualization Impact on SLA Management [21]: this exploratory reportprovides initial thoughts on the impact of end-to-end SLAmanagement in a fullysoftware-defined and virtualized environment, i.e., Cloud-SDN-NFV. Its objective istoleverageknowledgeandexperiencefromtheTMForumSLAMwork,andapplyittovirtualizedenvironments.

- IG1127 End-to-end Virtualization Management: Impact on E2E Service AssuranceandSLAManagementforHybridNetworks[22]:ThisApplicationNotebringsoutthechallengesandimpactsonend-to-endServiceAssuranceandSLAmanagementinahybrid physical/virtualized environment. This change introduces a host of actors,each responsible for part of the overall solution, and creates new SLA/OLAconstructs. Italsonecessitatesnewmeansofoperations–havingSLA-linkedPolicyOrchestration, new RCA rules for Fault Correlation, and automated closed loopcontrols,thusreapingthebenefitsofvirtualizationasdesignprinciples.

TheselastreportswillbedetailedinthefuturedeliverabledevotedtoSLAandbilling inT-NOVA[23].


Fromtheserviceproviderpointofview,themarketplacehasbeenincludedintotheT-NOVAsystem taking into account the approach proposedby TMForum, as it is for instance theprovisionofbusiness interactionagility for all the stakeholders, the creationof abusinessservicecataloguetoprovidetheserviceofferingseasierforthecustomer,ortheadoptionacommon language for service description that it will be detailed in future T-NOVAdeliverables[20].TMForumSIDmodelwillbeappliedtoNFVwithinT-NOVA.AlsoT-NOVA


©T-NOVAConsortium

16

SLA management framework has been built considering the references from TMForum.However, ithasnotbeenfoundanyreferencefortheaccountingandbillingframeworkofNFVservicesthatT-NOVAisbuilding.

2.2.2. Otherprojects

In this subsectionwe reference researchprojects implementingmarketplaces for networkservicesprovision:

- XIFI [24]. This is a project of the European Public-Private-Partnership on FutureInternet(FI-PPP)programmewiththeobjectiveoffacilitatetheuptake,deploymentandfederationofseveral instancesofacommonmarketplatformtopavethewayfor a unified European marketplace that is crucial for enabling commercialexploitationofFIresources.Inputsfromthisprojectinrelationtoservicedescriptionlanguages and catalogues have been surveyed when building T-NOVA serviceframework.

- OtherrecentresearchprojectsthatmayberelevanttoT-NOVAasitwasidentifiedin previous work [3] are: MCN [25], Unify [26] and NETIDE [27]. None of theseincludesamarketplaceas it is inT-NOVA inwhich several functiondevelopers co-exists with full support for their commertial activity. In order to re-use existingsolutions, T-NOVAhas considered theMCNchargingplatform tobe adapted to T-NOVAecosystem.Thisisfurtherexplainedinsection2.6.2.8.

2.2.3. Commercialproducts

WehaveidentifiedsomecommercialproductsthatmayberelatedpartiallytotheT-NOVAMarketplace:

- CENX Ethernet Lifecycle Manager (ELM) [28] is a software-based solution thatautomates lifecyclemanagementspecific tocarrierEthernetand IPservicesacrossdata network infrastructures and evolving the concept of SDN/NFV. It provides avisualrepresentationofall inter-carrierEthernetservices, inordertoallowServiceProviders, Access Providers and Cloud Exchange Providers to deliver qualityconnectivity services. Some features are ordering automation, big data analytics,service orchestration and delivery across multiple operator networks andvisualisationoftransportservicesend-to-end.

- Equinix Platform - Marketplace [29] is a platform where users can buy and sellconnectivity among other services. Provides service-offering capabilities for sellersandbuyershaveaccesstowideareaofservicesacrossmultipleoperators.

HPhassomeexemplarycasesofmarketplacesbuiltuparoundecosystemswhichcoalescetherelevantstakeholders.Suchcasesare:

- HP OpenNFV Partner Ecosystem [30]: around its OpenNFV technical platform, HPcreated an ecosystem of partners, classified as Technology, Application or Servicepartners.Partof thisecosystemare theOpenNFVLabs,whereHPand itspartnerscan test and validate applications to make sure they run as expected on theOpenNFV reference architecture. Based on the outcomes of testing, each VNF islabelledaseithersilver,gold,orplatinumlevel.

- SDN App Store [31]. In 2014, HP launched its SDN App Store, meant to act as amarketacceleratortoolforitsecosystemspartners,complementedbyaportfolioofconsulting services addressed to the end customers. The SDN App Store makes


©T-NOVAConsortium

17

available to thedeveloper community a centralizedplatform, able to interconnectwithcustomerpremises.

- Cloud28+: The Cloud28+ [32] initiative created a European ecosystem of cloudservice providers, builders and developers, leading to the creation of a larger andunified service catalogue. Cloud28+ is not actually amarketplace, since it doesn’ttakeanycompensation in returnof its serviceofmatchingcustomerdemandwithserviceoffering. It isa federatedservicecatalogue,definingtheservices throughacommon specification, describing their performance, and connecting them to thedemandside(->customers).


When lookingat somecommercial solutionswehave identified theHPsolutionsaboveasones of closest ones to T-NOVA Marketplace approach but with differences. Moreconcretely,theOpenNFVPartnerEcosystemisatestingplatformfordevelopersmorethanamarketplace,howeverthisopenviewofa testingenvironment itcanbeavery interestingapproachtopotentiallyextendT-NOVAMarketplacewithopenaccessfollowingasandboxconcept, includingfreetrainingdocumentationandpossibilityoffreetrials.ThiswillmakeT-NOVA exploitation roadmap [33] shorter. SDN app Store is alignedwith approach of T-NOVA Function Store, while Cloud 28+ can be considered a marketplace but fully cloudoriented,notnetworkservicesareconsidered.

2.2.4. Conclusions

Analysing the state of art, we have found some solutions fromwhichwe can build on inordertodeveloptheT-NOVAMarketplace;howeveratthisstageitdoesnotexistapropermarketplacetodeliverVNFasaService.

TheT-NOVAMarketplaceisdesignedconsideringtheabovesolutions,thecurrentNFVETSIarchitecture, the on-going TMForum Best Practices for business services delivery and SLAmanagement.

2.3. T-NOVAstakeholdersinteractingwiththeMarketplace

Starting from the business roles analysis performed inDeliverableD2.1 [1],we concludedthat all of the T–NOVA roles identified can be grouped to be played by three differentstakeholders which we have called the basic stakeholders in the T-NOVA landscape. Forsimplicity it has been decided from the implementation point of view that only the basicstakeholders will be considered when specifying the T-NOVA system. Nevertheless,interesting future work for T-NOVA system in general, and for T-NOVA Marketplace inparticular,willbeitsextensionformultiplenon-basicT-NOVAstakeholders.

Therefore, three different stakeholders will exploit the T-NOVA Marketplace: Customer,ServiceProvider(SP),andFunctionProviders(FPs).ThissituationisreflectedinFigure2-2.


©T-NOVAConsortium

18

Figure2-2.StakeholdersinteractinginT-NOVAMarketplace

The T-NOVA Marketplace will facilitate the following functionalities for the T-NOVAstakeholders:

- Customers will be able to browse and select network service offerings that bestmatchtheirneeds,aswellasnegotiateSLAsandexchangetheirbillinginformationwiththeSP,keepingtrackofalltheservicespurchased.

- AServiceProviderwill beable toacquireVNFs, interactingwithdifferentnetworkfunction developers through a brokerage/trading procedure not only for its ownneeds but also to offer composed Network Services (NSs) to its own customers.Therefore,alsoSLAandbillinginformationbetweenSPandFPswillbemanaged.

- Several Function Providers (network function developers) will be able to publishtheirVNFstotradethembymeansofT-NOVAMarketplace.

Besidesthesethreebasicstakeholders,T-NOVAwillhaveitsownT-NOVAoperatorthatwillbeinchargeofthesystem,andtheaccesscontrolfortherestofthestakeholders.

2.3.1. Subscriptionmanagement

AstheT-NOVAMarketplacewillbeaccessedbythreepreviousmaincategoriesofusersorstakeholders, and each of these categories has a specific task, it is crucial that themarketplaceimplementsaRoleBasedAccessControl(RBAC)frameworkthat:

- restrictsaccountaccessonlytoauthorizedusers,- linksausertoanaccountandassignstheusertosomespecificroles,- linkseachroletospecificpermissionsorprofile.Forinstance,aFPwillbeallowedto

upload VNFs in the function store or to upgrade them. If this provider wants topurchasea service, itwill alsobeassigned the roleofa customer. Inotherwords,thisframeworkwillallowuserstoperformactionsaccordingtotheassignedroles.

As a first step, the stakeholders need to register on the T-NOVA system. Here typicalinformationsuchasprovidername,username,address,wishedrole,emailaddress,etc.,willberequestedinordertocreateanaccountonT-NOVAforthisuser.Ifthisuserwishestouseanexistingaccount(onGoogle,Yahoo,etc)forauthenticatinghimself,anaccountontheT-NOVAsystemwillbeautomaticallycreatedforhimin(seedetailsinsection2.6.2.2.).


©T-NOVAConsortium

19

2.3.2. Tradingmechanisms

OneoftheaddedvaluesoftheT-NOVAmarketplace isthepossibilityofauctioningamongseveral FPs. In this way, the SP, and T-NOVA customers in general, will benefit from thisfeature by receiving the best price option, based on their requirements of servicedescriptionandSLAlevel.

The principal objective of the T-NOVA auction is to trade the VNFs between the SP andseveralFPstoachievebestpriceoptionforT-NOVAcustomeronacompetitivebasis,whilemaximisingtherevenuethattheauctioneerraisesandefficientlyexploitingtheVNFs.Giventhoseobjectives, thedesignofT-NOVAauctionsystemmustalsoaddresssomechallengesan auctioneer faces. Briefly, these challenges includewinner’s curse (this situation occurswhen one ormore users pay toomuch for the auctioned item(s)), collusion (most of thetimescausedinsmallsizemarkets)andsignaling(lesssignalingsimplifytheauctionprocessandattractbidders).

Consideringtradingmodels,twomainapproachesexist,thereservepriceestimation(orfix-price) and the auctions. The former case refers to the lowest price the seller iswilling toacceptforagivenitem(i.e.service),withoutperformingbids.Thelattercaseperformsbidsbasedonsingle,multiunitorcombinatorialauctions.Thereareplentyofauctionprotocols,including the sealed first-price auction, the sealed second-price auction (called Vickereyauction),theopenascending-price(English)auctionandtheopendescending-price(Dutch)auction.ThemainonesarecollectedinTable2-2.Moreinformationregardingtheauctiontheoryandthetypesofauctionscanbefoundin[34].

In T-NOVA marketplace, the auctioning will be performed by means of the brokeragemodule(seesection2.6.2.3.).

TradingMechanisms UsageFix-price IncasesthattheofferofNFsislowertothedemand

Auctions IncasesthattheofferofNFsishighertothedemand

Vickerey/Sealedbidauction • Optimizesocialwelfare(thepriceatwhichchargedthe winner depends on the bids of competitorsandnoneoftheindividualoffer)

• Avoidsignaling• Truethfullincaseofsecondprice

Englishauction • Quite profitable type of auction for the seller/Reachtolargeamounts

• Winner's curse is not possible to be prevented(biddersoverestimatethevalueoftheitem)

• Requiressignaling • Nottruethfull

Dutchauction • Very profitable type of auction for the seller. Thepurchasepricewasnotallowedtodroptoomuch,due to the fear that another bidder will firstacquiretheitem

• Requiressignalling• Nottruethfull

CombinationofEnglish/DutchandVickery

• Decreasethecollusion


©T-NOVAConsortium

20

auctions

Combinatorialauction-Vickerey-Clark-Grooves

• Sellpackageofitems–winnerclaimallornothing• Truethfull• VeryComplex

Table2-2OverviewofTradingmechanisms

2.4. T-NOVAmarketplaceusecases-lifecycle

Based on the T-NOVA use cases in collected in [1], we describe in this section thewholemarketplace lifecyle fora customeraccessing the systemtopurchaseVNFaaS,orNetworkServices(NSs)basedonVNFs.ThisgeneralprocedureisrepresentedinFigure2-3.

Figure2-3Marketplacelifecyclefromthecustomer’sperspective

Background:

- The Function Providers (FPs) thatwant to sell their VNFs through T-NOVA systementer the systemproviding their VNFs required information (according to sections3.3.2and3.4.2).

- The Service Provider (SP) that wants to purchase VNFs in order to later sell NSsbasedonVNFsthroughT-NOVAlogintothesystem.

- AbusinessservicecatalogueisfilledofflineinthemarketplacewhenanewservicecompositionhastakenplacetriggeredbytheSP.Thisbusinessservicecataloguewillcontainalltheinformationofthecommercialofferingsavailable(moreinformationin2.6.2.4.BusinessServiceCatalogue).

1. The T-NOVA customer enters T-NOVA system through the dashboard identifying (orregisteringifitisitsfirsttime).

2.TheT-NOVAcustomerindicatestheservice(VNF,severalVNFsorNetworkService)he/shewouldliketopurchase(performsearch).


©T-NOVAConsortium

21

3.Themostsuitableofferingsavailableinthemarketplacebusinessservicecataloguewillbeshowntothecustomerinorderforhimtoselectone,includingpriceandSLAoptions.Intheevent that there is not any available service offering in the business service cataloguematching thecustomer request, anewservice composition shouldhave to takeplaceandtrading mechanisms will be performed among FPs if several FPs offer similar VNFsdynamically.

4. The customer selects one of the offered services, together with the configuration ofspecific technical configuration parameters needed for the service provision, and the SLAagreementprocedurewillbeinitiated.

5. All the related information is stored in the different marketplace modules (customerprofile,SLA,accounting,etc.).

6.Serviceprovisioningstarts.

7.Servicemonitoringinformation,SLAfulfilmentinformationandbillinginformationwillbemade available through the dashboard each time it is required by the customer whenaccessingtheT-NOVAmarketplace.

8.Billingwill takeplacewhenfinishingtheservices inpay-as-you-goservices,oreachtimetheassignedbill cycle finishes for the restof services (betweencustomerandSP,butalsobetweenSPandFPs).


©T-NOVAConsortium

22

2.5. RequirementsforT-NOVAMarketplace

TherequirementscaptureprocesshasfocusedonidentifyingthedesiredbehaviourfortheT-NOVAmarketplaceanditscomponents,whichweremostofthemidentifiedbasedonthepreviousrequirementsanalysisperformedatT-NOVAsystemlevel[1].

None of themarketplace components requirements in this deliverable specifies how theywillbeimplemented;implementationdetailswillbespecifiedinthefutureworkintechnicalT-NOVA WorkPackages (WPs) as the implementation-specific descriptions are notconsidered to be requirements. The goal of these requirements is to develop anunderstandingofwhatthemarketplacecomponentsneed,howtheyinteractbetweeneachother, and their relationship to the overall T-NOVA architecture [3]. Additionally, the T-NOVA use cases [1] were also considered and cross-referenced with marketplacecomponentsrequirements.

Requirements were primarily anchored to the existing T-NOVA use cases and theinteractionswiththewholesystembothintermsoftheactionsandrequeststhatwouldbeexpected. Additionally the high-level data/information that is be required by themarketplace to successfully deploy its functionalities was also identified. Identifiedrequirements were primarily functional since they are related to the behaviour that isexpectedfromthemarketplace.

Usingasystems’engineeringapproachthehigh levelarchitectureforthemarketplacewasdescribed in Deliverable 2.22 [3], each component of the overall systemwas specified interms of high-level functional blocks. This approach identified the following functionalblocks:

- Dashboard- AccessControl- Brokeragemodule- SLAmanagementmodule- Accountingmodule- Billingmodule

Also a Business Service Catalogue has been identified to be part of the MarketplacematchingTMForumproposalforbusinessagility.

The requirements of T-NOVA Marketplace components can be found in Annex A -Requirements Specification as well as the requirements describing how they shouldinterfaceonewithoneanother.Theserequirementswereusedasafoundationalinputintothe specification of the overall marketplace architecture and its constituent components,which are presented in section 2.6. The coverage of these requirements by the T-NOVAsystemwillbeexplanainedafterimplementationwork.


©T-NOVAConsortium

23

2.6. Specification of the T-NOVA Marketplace architecture:componentsandinterfaces

Based on the requirements performed at system level [1], the initial approach for themarketplace architecture included in Deliverable 2.22 [3], the requirements gathered foreach component in the marketplace, and refinements done in the WP devoted tomarketplace implementation[4] isdepicted inFigure2-4, includingtheoveralldiagramfortheT-NOVAmarketplacearchitecturewithboththeexternalandinternalinterfaces:

Figure2-4Marketplacearchitecture

Table 2-3 and Table 2-4 collect a brief description of the purpose of each external andinternalinterfacedespictedinFigure2-4.Extendedinformationofexternalinterfacesofthemarketplace is explained Section 2.6.2. The specification of each module’s functionality,internalarchitectureandtheirinterfacesareaddressedinsections2.6.3to2.6.8.

MarketplaceExternalInterface

Description

T-Da-Or ItisusedtogetmonitoringinformationoftheservicebythecustomerandSP.

T-Ss-Or ItisusedtonotifytheorchestratoraboutanewNSinstantiationincludingtheserviceconfiguration.

T-Sl-Or SLAmodule requests currently running NS metrics from the monitoringsystemintheorchestrator.

T-Ac-Or The accounting is notified about any status change of each NetworkService(NS)orVNFinstances.

T-Bsc-Or The BSC uses this interface to push the NSD relevant fields to theorchestratorwhenanewserviceofferinghasbeencreated.Alsooncetheorchestratorvalidatesit,theavailabilityofaserviceisnotifiedtotheBSCtobeofferedtothecustomer.

T-Br-Nfs Thebrokeragemodulewilluseittoretrievesinformationaboutthe


©T-NOVAConsortium

24

availableVNFs. T-Da-Nfs ItisusedtouploadVNFandmetadatabytheFPstotheFunctionStore

Table2-3Marketplaceexternalinterfaces

Marketplaceinternalinterfaces

Description

T-Ac-AA Itisusedbytheaccountingmoduletoaccessthe“userprofiles”.

T-Ac-Bi Alltheinformationneededforbillingisstoredintheaccountingmodule.

T-Sl-Ac SLAmoduleisaccessedbytheaccountingmoduletoextractinformationaboutSLAviolationsforpenaltiestobeapplied.

T-Br-Ss This interface is used by the Service Selection module to check anypotential change in the price as a result of the trading process beforecreatinganentryintheaccounting.

T-Da-Sl It is used to introduce SLA templates in the SLA module when a newservice of VNF is created and also to provide the dashboard with SLAfulfilmentrelatedinformation.

T-Da-AA It is used to provide and collect all the information necessary toauthenticatetheT-NOVAusers.

T-Da-Ss Once a Customer selects a service in the BSC from the dashboard, it ismanagedbytheserviceselectionmodule inordertoprovidethecustomserviceconfiguration.

T-Ss-Ac It is used to create the entries in the accountingmodule to track everyserviceorVNFinstancecreatedintheorchestratorforbillingpurposes.

T-Da-Bi Thethreestakeholdersuseittovisualizebillinginformation.

T-Da-Br ItisusedtorequestVNFsinordertofacilitateauctioningamongFPs.

T-Da-BSC It is used to publish offerings by the SP, and to browse offerings by thecustomer.

Table2-4Marketplaceinternalinterfaces

2.6.1. ExternalInterfacestotheT-NOVAMarketplace

The marketplace modules will communicate with other two T-NOVA components: theorchestrator,andthefunctionstore.

2.6.1.1. Orchestrator

The T-NOVAOrchestrator, which specification can be found in Deliverable 2.31 [2], dealswiththeoptimaldeploymentofnetworkservicesinstances,asrequestedbythecustomerortheServiceProvider (SP)onthemarketplace,accordingtoayet tobedesignedalgorithm,therequiredSLAandthecurrentstatusoftheavailableinfrastructure.

Whileall network services instanceshavebeen instantiatedandare running, it is also theorchestrator’sresponsibilitytofollowtheavailablemetrics,bothfromtheinfrastructureandfromtheservicemetrics.InordertomeettheagreedSLAs,theorchestratormayscaleoutor up the supporting insfrastructure, communicating such changes to themarketplace, sothatachangeinaccountingisregisteredandlaterbilledtothecustomer.Later,ifthescaled


©T-NOVAConsortium

25

(outorup)infrastructureisperceivedasbeingmorethanenoughtofulfilltheSLA,itcanbescaledinordown.Throughtallthisprocess,theorchestratormustprovidethemarketplacewithmeaningfullmetricsshowinghowNetworkService(NS) instancesareworking.Detailsof the interfacesbetween theorchestratorandmarketplacemodulesareexplained in thefollowing sections: Dashboard, Business Service Catalogue. Accounting module ServiceSelectionmodueleandSLAmanagementmodule.

2.6.1.2. NetworkFunctionStore(NFstore)

Asitwillbeexplanainedinsection3.5,thisT-NOVAcomponentwillstoretheVNFsimagesand metadata that the marketplace, more concretely the brokerage module, will use toperformtradingmechanismsamongFunctionProviders(FPs),tolaterincludethoseVNFsintheservicecompositionprocessperformedbytheorchestrator.

ForaVNFtobepartofaservicecompositionprocess, it isnecessarythattheorchestratormakeitavailable,accordingtoT-NOVAOrchestrationspecificationinD2.31[2].WheneveraVNF is uploaded, updated or removed from theNF Store, the orchestrator is informed inordertoupdateits internalregisters.ThisprocessmakestheVNFavailable intheFunctionStoretoberetrievedbythebrokeragemodule.

2.6.2. Marketplacemodulesspecification

2.6.2.1. Dashboard

WiththeaimofcreatingasingleentrytotheT-NOVAsystemthatprovidessimplicityforthedifferent T-NOVA users or stakeholders, a unified T-NOVA Dashboard will be designed,takingintoaccountthedifferentrolesoftheT-NOVAMarketplace.Thiscommondashboardfor thewhole T-NOVAenvironmentwill host three views for the three basic stakeholdersthatwill access the T-NOVAMarketplace: the Service Provider (SP), the Function Provider(FP)andtheCustomer.

StartingfromthedashboardrequirementsinAnnexA,inthissectionweincludethegeneraldescriptionoftheinformationthatthedashboardwillhavetoshow,firstideasforitsdesignand the general information that will have to be collected by the different APIs of thedashboard coming from the rest of the T-NOVA components. The complete designinformationand later implementationofT-NOVAuserdashboardwillbedone inT6.3,anditsoutcomeswillbegatheredintheDeliverablesD6.01andD6.3.

Functionality

ThemainfeaturesofthedashboardarepresentedinFigure2-5.EachviewisallocatedwithspecificfunctionalitiesstemmingfromtherequirementsgatheredfromAnnex6.1.1.


©T-NOVAConsortium

26

AA

ServiceComposition

ServiceMonitoring

BillingInformation

SLAInformation

AAVNFUpload

VNFPublicationVNFModificationVNFWithdrawVNFsmonitoringBillinginformationSLAinformation

AA

Servicerequest

Serviceselection

Serviceconfiguration

Servicemonitoring

Billinginformation

SLAinformation

Figure2-5Dashboardviews

TheSPviewofthedashboardwillallowtheSPtoperformthefunctionalitiesshowninTable2-5.

Functionality ShortExplanation

AA AuthorizationandAuthenticationoftherespectiveroleintotheT-NOVADashboard.

Servicecomposition Graphical wizard that will help the SP to compose a newNetwork Service (NS) starting from the brokerage amongtheFPsowingtheavailableVNFs.

Servicemonitoring Graphical representation of all monitoring data for aselectedor"consumed"Service.

Billinginformation Graphicalrepresentationofthebillingoutcomesofselectedor "consumed" service. There will be two types of billinginformationfortheSP:

- ChargesfortheSP’scustomers(BSSfunctionality).- Invoicesonbehalfofitsownsuppliers,theFPs.

SLAinformation Detailsoftheselectedor"consumed"servicebasedonhowthey respect the agreed SLA. The SPwill have accessed totwo different kinds of SLA contract and SLA monitoringinformation:

- SLAbetweenSPanditscustomers(BSS)- SLAagreedwithhisitssuppliers,theFPs

Table2-5SPdashboardview

The FP view of the dashboard will allow the FPs to perform the functionalities shown inTable2-6.


AA AuthorizationandAuthenticationoftherespectiveroleintotheT-NOVAdashboard.

VNFUpload GraphicalwizardthatwillhelptheFPtouploadhisVNFwith


©T-NOVAConsortium

27

thenecessaryparameters.

VNFPublication GraphicalrepresentationfortheFPtoprovidethelastcheckinordertopublishtheuploadedVNF

VNFModification SmallgraphicalwizardthatprovidestheabilitytotheFPtomodifytheuploadedVNF.

VNFWithdraw Graphical representation that gives to the FP theability toremoveanalreadypublishedoruploadedVNF

VNFsmonitoring Graphical representation of all monitoring data for aselectedor“consumed”NF.

Billinginformation Graphical representation of the Billing outcomes for aselectedor“consumed”NF.

SLAinformation Information of the selected or "consumed" NFs based ontheagreedSLAanditsfulfilment.

Table2-6FPdashboardview

ThecustomerviewofthedashboardwillallowthecustomertoperformthefunctionalitiesshowninTable2-7.


AA AuthorizationandAuthenticationoftherespectiveroleintotheT-NOVADashboard.

Servicerequest GraphicalrepresentationoftheServices/FunctionsreturnedbytheT-NOVAbusinessservicecatalogue.

ServiceSelection Graphical representationassistedbya checkboxprovidingthe ability to the customer to select a service forconsumption.

Serviceconfiguration Small Graphical wizard providing to the customerpredefinedparametersfordefiningtheselectedservice.

Servicemonitoring Graphical representation of the data gathered from themonitoringmodules.

Billinginformation Graphicalrepresentationofthebillingoutcomesofselectedor"consumed"service.

SLAinformation Detailsoftheselectedor"consumed"ServicebasedonhowtheyrespecttheagreedSLA.

Table2-7Customerdahsboardview

Design

ThedashboardconstitutestheT-NOVAsystemfront-end,asofferedtotheCustomer,theSPandtheFPsforserviceconsumption,discovery,interaction,publication,etc.Inorderforthedashboard to be as up-to-date as possible and terminal-agnostic, aweb-based design hasbeenselected.

Furthermore,thedashboardshallbeabletomeetand,ifnecessary,toadapttothespecificstakeholder’s needs/requirements asmuch as possible providing the best experience to aspecific stakeholder. This implies that the implementation shall achieve a flexible service


©T-NOVAConsortium

28

presentationbymeansofanappropriatechoiceoftechnologiesandtools.T-NOVAwillalloweveryroletopersonalisesomesettingssuchasinterface,appearanceandcontentaccordingtoitsprofile.

Morespecifically, intheauthenticationstage,allstakeholdersshareacommonlayoutthatdisplays the generic graphical interface composed by the basic controls that enablestakeholder specific authentication.Once authenticated, every stakeholderwill be able tocustomizetheoverallexperienceaccordingtoasetofpreferencesandhisprofile.

Themaindesigndecisiongatheredfromtherequirementsin[1]hasbeentohaveacommondashboardwith different customized views based on different roles. Furthermore and bygathering all the requeriments we have designed a first version of a mock-up for thedashboardthatwillbeusedasaPilotfortheupcomingwork inTask6.1–UserDasboard.Themock-upisavailableinAnnexB6.2.

Interfaces

The informationthatwillbecollected fromtherestofT-NOVAcomponents tobeusedbydashboardwillbeprovidedthroughthefollowingAPIs:

AA: theAuthenticationandAuthorizationaccess control systemwillprovideanAPI to thedashboardtoprovideandcollectalltheinformationnecessarytoauthenticatetheT-NOVAusersorstakeholders.

SLAmanagement:thegoalofthisAPIistoshowtheusersthefollowinginformationcomingfromtheSLAmanagementmodule:

- SLAtemplatespecificationtobefilledbytheSPandFPs.- SLAofferingtothecustomerandassociatedtoeachservice.- SLAfulfilmentsbyallthestakeholders.

Note:theSLAselectionperformedbythecustomertomanagetheSLAnegotiationprocessandtheSLAcontract informationwill comefromthebrokeragemodule thatperformsthetrading.

TheSLA front-end tool thatwillbe integrated in thedashboardwillbealso responsible tomakethecorrectrequesttotheSLAAPIandthengatherandshowtheresults.

Brokerage

This interface isexploited for trading issues,amongtheT-NOVAusers (i.e.SP,FP)andthebrokeragemodule.TheinformationthatwillgothroughthisAPIwillberelatedto:

- VNFrequestandselection:bymeansofthisAPItheSPrequestsandselectionswillbesenttothebrokeragemodule.

- AdvertiseVNF:thisfunctionalityisexploitedforthecommunicationbetweenFPandthebrokeragemodule,asthelatterperformtheintermediatecommunication,thisistrading.

Orchestrator

The interfacebetweenthedashboardandtheorchestratorwillbeusedtomanageserviceusagedata: through this interface theSPandcustomerwill beable toget themonitoringinformationoftheservice.

Billing

The billingAPI for the dashboardwill have tomanage the following information betweendashboardandbillingmodule:


©T-NOVAConsortium

29

- Billschargedperuserandperservice(SPandcustomer).- ChargesdonetoSP’scustomers(BSSfunctionalitytotheSP).- ChargesdonetoFP’scustomers,whichistheSP.

BusinessServiceCatalogue

TheBusinessServiceCatalogueAPIforthedashboardwillbeusedto:

- Publishandon-boardserviceofferingsbytheSPtoT-NOVA.- Browseavailableserviceofferingsbythecustomer.

ServiceSelectionmodule

This API will have to manage the information needed to configure each service to becustomizedforthecustomerwhenselectingeachservice,forinstanceprovidingcustomer’snetworkdetails for latertheorchestratorproperlydeploytheservice.AlsousedtoupdateonconfigurationorneedtoremovearunningNS.

NetworkFunctionStore

This interface allows the FPs to publish and manage their VNFs into the NF Store. Thepublicationconsists inuploadingtheVNF image,registeringtheVNFand itsmetadata intothe function store. The VNFs are versioned allowing the FPs to provide further upgrades.Finally, the FPs can remove their VNFs. In summary, the information managed with thisinterfaceis:

- VNFimageandVNFmetadatadescriptor.- VNFversion.- Upload,upgradeanddeletetheVNFpackage.

2.6.2.2. Accesscontrol(AA)

In T-NOVA, different stakeholders are foreseen. Each of these stakeholders will have aspecific roleandaccordingly someassociatedpermissions (seebelow in this sectionPolicyEnforcementService).Forinstance,aFunctionProvider(FP)willbeabletouploadaVNFandupgradeitifneeded.TheSPwillbeabletoselecttheVNFsthatheiswillingtodeployanduse,andshouldnotbeallowedtoupload/removeagivenVNFfromtheNFStore.Oneofthemain challenges inT-NOVA is how toadminister security inamulti-userenvironment. Toaddressthisissue,T-NOVAwillspecifyanddevelopalightweightRoleBasedAccessControl(RBAC)systemwheredecisionsarebasedonthefunctionsagivenstakeholderisallowedtoperformwithinT-NOVA.

TherequirementsgatheredforthismodulearecollectedinAnnexA.Themainconclusionsaresummarizedinthefollowingbullets:

- ThedifferentstakeholdersshouldbeauthenticatedbeforeanyoperationontheT-NOVAsystem.

- Thedifferentstakeholdersshouldbeauthorizedtoperformtasksthatareassociatedtotheirrolesandpermissions.

- Roles are created according to their functions in T-NOVA, and stakeholders areassignedrolesbasedontheirresponsibilitiesandqualifications.

- Rolescanbereassignedorgrantednewpermissionsifneeded.- Rolesandpermissionsshouldbeupdatableandrevocable.

Functionality

TheRBACsystemwillbeofferingtwomainfunctionalities:


©T-NOVAConsortium

30

- Authentication:authentication istheprocessbywhichthesystemwillverifythatauserofT-NOVAisexactlywhoheisclaimingtobe.

- Authorization: authorization is theprocessbywhich auser is allowed toperformthetaskshewantsto.

Architecture

ThegeneraldiagramoftheaccesscontrolsystemisdepictedbyFigure2-6.

Figure2-6.RBAChighlevelarchitecture

AuthenticationManager

To enable the T-NOVA system to provide different functionalities to the stakeholders, amechanismforauthenticatingastakeholderisrequired.InT-NOVA,thisisperformedbytheAuthenticationManager,allowingausertoregisterandloginwithusernameandpassword.In the registration case, the user has to provide the information required (username,password, email etc) by filling out a registration form. Finally thought the authenticationprocesstheAuthenticationManagerreturnsaJWTauthenticationtokenreflectingthattheuserisloggedin.

PolicyEnforcementService

ThePolicyEnforcementserviceimplementsaRoleBasedAccessControl(RBAC)mechanismthatallowsassigningusersdifferentrolesresultingindifferentrights.SuchanaccesscontrolmechanismallowstheT-NOVAsystemto implementfunctionalitysuchasuploadingaVNForpurchaseaservice.Whenanewuserregistersauserprofilewillbecreatedcontainingthenameandemail addressof theuser. Furthermore theprofilewill also contain thecurrentroleoftheuser.

Therolesforeseenatthisstageoftheprojectare:


©T-NOVAConsortium

31

- T-NOVAoperator:inchargeoftheT-NOVAsystem- Service Provider: it purchases several VNFs to compose a service to be sold to its

finalcustomers.- FunctionProviders:theentitiesthatareallowedtouploadandupgradeagivenVNF

ontheT-NOVAsystem.- Customer:theentityinterestedinpurchasingaT-NOVAservice.

Interfaces

Several interfaces are foreseen to ease the communicationwith the other parts of the T-NOVAsystem.Thisincludes:

§ Interfacetothedashboard:theT-NOVAAccessControlmodulewillprovideanAPItothedashboardallowingittoauthenticatetheT-NOVAusers.

§ Interface with all the other compoments in the marketplace: the T-NOVA AccessControl Systemwill provide an API to access the “User profiles” and features areneededtohandleinformation,suchasuserpermissions,personalinformationetc.

2.6.2.3. Brokeragemodule

Towards facilitating trading between diverse actors in the NFV scene the T-NOVAmarketplace includes an innovative brokeragemodule, inwhichVNFs by several FunctionProviders(FPs)canbebrokered/traded.

Functionality

Via the brokerage module API in the dashboard, the SP place their requests andrequirements for the corresponding VNFs, receive offerings and make the appropriateselections,takingintoaccountthepriceandtheofferedSLAs.Tradingpoliciessuchaslong-termlease,scheduledlease,short-termleaseorspotmarkets(theseleasingtypesreferetothe duration of VNFs exploitation) can be based either on fixed-price or action-basedstrategies(seesection2.3.2Tradingmechanisms).

In T-NOVA there are several objectives in order to select an auction mechanism, whichshouldbe taken intoaccount.The firstobjective is toavoid toomuchsignallingoverhead.Thisobjectivemaybesatisfiedwiththesealed-bidauction. Inthisauctionscheme,bidderssimultaneouslysubmitsealedbidssothatnobidderknowsthebidofanyotherparticipant.Hence,bidderscannot change theirbidsafter theannouncementof theotherbids. In thecaseofsealed-bidauctionthefirstpriceauctionmodelshouldbeimplemented.Sealed-bidauctionmaynotbetruthful(truthfulnesspreventsmarketmanipulation,sincethebiddingisperformed considering the true value of the item), however the VNFs auctions are oftenorganizedtomaximizethepayoff,andnottobetruthful.

Tobeprecise,the implementationofthesecondpriceauctionmodel isalsopossiblesincethereisnoprobleminswitchingthepaymentmethodinanauctionengine(thismaybeanoptionalfeatureimplementedintheT-NOVABrokerageModule),thus,makingthisauctiontruthful.TheT-NOVABrokerageModulemaychangethepricingruleinaflexiblemanner.Itisamatterofimplementinganextrapolicyinthebrokeragemoduleoperationmechanism.Additionally, the call pricemaybe used to provide rational item valuation. Thebrokeragemodulewilldeterminethepropercallprice foreachVNFbasedonmarketing factors. It isalsopossiblethatthebiddersusetheirownvaluationtoolsalongwithboththebrokerage


©T-NOVAConsortium

32

module,sothattheformer(i.e.bidders)tobeabletolearntheoptimumcallprice.FutureworkforauctioningimplementationwillbedoneinTask6.3–Brokeragemodule.

Insummary,thebrokeragemodulewillprovidethefollowingfunctionalities:

§ VNFdiscovery: this process is required in order thebrokeragemodule to seek fortherequestedVNF.

§ Trading: this process enable the brokerage module to trade the VNFs, especiallythroughauctions, incasethatoneVNFisofferedbymorethanoneFP. Figure2-7depictsthesequencediagramofgeneralauctiontrading.

Figure2-7Tradingprocess

1. TheSPprovidestothebrokeragemoduletheVNFrequestandtheinitialprice.2. ThebrokeragemodulesendsanACKthatinitiateauctions.3. ThebrokeragemoduleinformstheFPsregardingtherequestandtheinitialprice4. FPsendstheirbidsforthefunctions(Price+SLAspecification)5. Thebrokeragemodulesolvesanauctiontomaximizeitsrevenue.6. Thebrokeragemoduleinformsthebidresults.7. Dependingonthetypeofauction,aniteration(3-6)continuesuntilthebidwinneris

found.8. Thebrokeragemoduleannouncesthefinalresults.9. Thewinneracknowledgestheresults.10. The brokeragemodule indicates the the VNF’s price,which is provided by the FP

thatwonthebidding,totheSP.11. TheSPacceptsthepriceandSLA.12. TheSPreceivestheVNF.13. (Price will be stored in the accounting module, and SLA agreement in the SLA

managementmodule).


©T-NOVAConsortium

33

Architecture

TheoverallarchitectureofthebrokeragemoduleanditsinterfacesisdepictedinFigure2-8.

Figure2-8Brokeragemoduleinternalarchitecture

Incasethecustomerwouldliketoaskforaservicethatisnotalreadyinthecatalogue,hewill have the option to perform a request for a new service composition taking place.ThereforetheServiceProviderwillusethebrokeragemoduletoqueryforspecificVNFs.TheprocessoftradingbetweenSPandFPsistheninitiatedaccordingtothesequencediagramdepictedinFigure2-7.

Interfaces

The required interfaces of the brokeragemodule for the proper communicationwith theotherpartsoftheT-NOVAsystemare:

§ Interface to the dashboard: this interface is required in order for the users of T-NOVAsystem(i.e.SP,FPs) tobeallowedto trade.For thispurpose, functionalitiessuchasservicecomposition/VNFrequestbytheSPandadvertiseVNF/tradingbytheFPsareexploited.

§ Interface to the service selectionmodule: with this interface the service selectionmodulewillcheck iftherecouldhavebeenachangeinthepricefortheVNFsasaresultofthetradingprocess.HeretheSSmoduleisanintermediatecomponenttofinallyprovidethatinformationtotheaccountingforbillingpurposes.

§ InterfacetotheSLAmanagementmodule:thisinterfaceisexploitedinorderforthebrokeragemoduletoprovideinformationtotheSLAmanagementmoduleregardingthe SLA agreed between SP and FPs as a result of the trading process. (The SLAmanagementmodulerequiressuchinformationinordertocreateandstoretheSLAcontractandforSLAmonitoringissues).

§ InterfacetotheFunctionStore:this interfaceisrequiredinorderforthebrokeragemoduletoretrieveinformationabouttheavailableVNFsforaservicecomposition.


©T-NOVAConsortium

34

2.6.2.4. BusinessServiceCatalogue

AccordingtothesystemrequirementsgatheredinDeliverableD2.1[1],inordertoaT-NOVAuser(typicallythecustomer)tobeabletoeasilyknowtheservicesalreadyavailableintheT-NOVA system, and access the description of those services, the T-NOVAMarketplacewillstoreallthisinformationinwhatwehavecalledthe“businessservicecatalogue”,matchingalso with the approach suggested by TM Forum in its “integration framework”, in whichfunctionalandnon-functionalaspectsofa servicebasedonserviceorientedprinciplesaredefined.ThisworkwillbecontinuedinT-NOVAunderTask6.1–servicedescription.

StartingfromtherequirementsinAnnexA-RequirementsSpecificationforthiscomponent,whicharemainlyrelatedtotheneedofthecataloguetobebrowsable,includingtheservicedescription, SLAs offered by the Service Providers and price for each services&SLA, weexplainnextitsfunctionalityandthewaytheinformationwillbestored.

Functionality

The business service cataloguewill be used by the Service Provider (SP), to store/create,services and update, delete the services. All stored services will be browsable based oncriteriasuchasprice,SLAandotherservicedescriptioncharacteristics,byServiceProviderandCustomer,whicharedefinedinmarketplacesearchview,throughDashboardmodule.

Thebusinessservicecataloguewillbefilledwiththeserviceoffering informationmanuallyandofflineafteraservicecompositionhastakenplacebytheSPthroughtheorchestrator.

Design

Thebusinessservicecataloguecontainsserviceofferingentries,eachofthemiscomposedby:servicedescription+SLAoffer+price,accordingwhat

Figure2-9shows.

Figure2-9BusinessServiceCatalogue

Interfaces

- Dashboard-thebusinessservicecataloguewillbeaccesseddirectlyandonlybythe dashboardmodule in both read andwritemode (by the customer and SPrespectively).

- Orchestrator– thebusinessservicecataloguewillpushtheNSDrelevant fieldsto the orchestrator when a new service offering has been created. Once theorchestratorvalidatesit,theavailabilityofaservicesisnotifiedtotheBSCtobeofferedtothecustomer.

2.6.2.5. ServiceSelectionmodule

Based on the requirements gathered for the Marketplace and the initial implementationsteps in order to improve in modularity it has been decided to include an intermediatecomponent between dashboard, business service catalogue and orchestrator that will beresponsibletoactivateintheorchestratortheselectednetworkservicebythecustomer:theServiceSelectionmodule.

Offering1(Service1,SLA11,price11)

Offering1(Service1,SLA12,price12)

Offering1(Service2,SLA21,price21)…


©T-NOVAConsortium

35

Functionality

The Service Selection module will provide the T-NOVA customer the ability to activate anetwork service thatmatches his search criteria. Itwill communicatewith orchestrator inordertoactivatetheservice,anddependingonOrchestratorresourcestheselectednetworkservicewillbeprovisioned,oritwillbediscarded.Incaseofsuccessfulactivation,thatwouldbenotifiedbytheOrchestrator,theServiceSelectionmodulewillpassthenetworkserviceinformationtotheaccountingmoduleinordertobeforwardedlatertothebillingmodule.Itwillnottaketheactionovertheaccountingincasetheserviceisnotprovisioned.

Before introducing the information in the accounting module it will make sure theinformationisupdatedandconsultthebrokeragemoduleincasetherehasbeenanychangeduringthetradingprocess.

Design

Figure2-10depictstheoverallarchitectureoftheservice-selectionmodule.

Figure2-10ServiceSelectionOverallArchitecture

TheRouting/LogicFunctionisresponsibletoforwardtherequesttoorchestratorand

dependingontheanswer,toforwardittoaccountingmodule.

Theservicemodule isbasedonmodulararchitecture, inorder toenhancethe logicof themodule,andtosupportadditionalinterfaceswithothermodulesifneeded.

Interfaces

- Dashboard - Interface between the Customer and the service selectionwherethecurrentserviceselectedisbeingconfigured.

- Orchestrator-ItisusedtonotifytheorchestratoraboutanewNSinstantiationandpassthecustomserviceconfiguration.

- Accountingmodule–Itisusedtocreatetheentriesintheaccountingmoduletotrack every service or VNF instance created in the orchestrator for billingpurposes

- Brokeragemodule - This interface is used by the Service selectionmodule toconsult any change in the information regarding the price as a result of thetradingprocessinthebrokeragemodulebeforecreatingtheaccountingentry

2.6.2.6. SLAmanagementmodule

Service Level Agreements (SLAs) represent a contractual relationship between a serviceconsumer and a service provider in order to provide a mechanism to increase trust in


©T-NOVAConsortium

36

providers by encoding dependability commitments and ensuring the level of Quality ofServiceismaintainedtoanacceptablelevel.

InT-NOVAtherewillbeaSLAagreedbetweenFunctionProvider(FP)andServiceProvider(SP) and between the Service Provider and its customers, and per each service, since thesameservicecouldhavedifferentSLAlevelsassociated.OneVNFcanbeofferedbyaFPwithdifferent flavours.Depedingon the technical characteristicsof thevirtual infrastructure inwhichtheVNFswillbedeployed,theperformanceachievedforthenetworkservicewillbedifferent.TheperformancegaranteesthataFPcanofferedforeachVNFwillbepartofthenegotiation through the tradingmechanisms implemented by the brokeragemodule (seesection 2.6.2.3. ). Therefore one Network Service (NS) can be offered with different SLAlevelsanddifferentprices,beingpartofdifferentofferingsasitisrepresentedinTable2-8:

SLAperserviceservice1,SLA11,price11

service1,SLA12,price12



Table2-8SLAperservice

SLAsdescribe theservice that isdelivered, itspropertiesandtheobligationsofeachpartyinvolved.Moreover,SLAsestablishthatincasetheguaranteeisfulfilledorviolated,rewardsor penalties, monetary or not, can be applied, respectively. T-NOVA SLA managementmodule will provide information for later accounting, depending on the terms andconditionsgatheredintheSLAandonwhetherthisSLAhasbeenmetbyallpartiesornot.

The requirements for theT-NOVASLAmanagementmodule, listed inAnnexA,aremainlyrelated to the need to provide mechanisms to get an agreement presented and agreed,storealltheSLAagreements,toinformtheorchestrator,andtoknowalltheSLAfulfilmenttoinformthebillingsystemforpossiblepenalties.

Functionality

The SLAmanagementmodule is in charge of providingmechanisms to get an agreementpresented and agreed, informing the involvedparties (Customer, SP, and FPs) and storingtheSLAs,itwilllaterreceiveandwillprocessallmeasurementsrelatedtotheSLAfromthemonitoringsystem(intheorchestrator)and,checkingiftheSLAshavebeenfulfilledornot,willinformtheaccountingsystemforthepertinentbillableitems(penaltiesorrewardings).

ASLAbasicallyconsistsoftwomainsteps:

1. Paper-signedcontract,inthiscase,betweenthecustomerandtheSP,andbetween

theSPandFPs, includingthedescriptionofthequalityofserviceandthepenalties

tobeapplied(couldalsobeonawebsitebyagreeingtermsandconditions).

2. eContract: It is automatically negotiated between parties for each customer,

depending on the demand. Always based on a paper-signed framework contract

(step1).

The SLA management module needs to be able to provide the following functionalities:publication, discovery and negotiation of SLAs requirements, in order tomanage the SLAlifecyclethatcanbesplitinthefollowingphases:


©T-NOVAConsortium

37

1. SLA Template Specification: for the SP (and FPs), a clear step-by-step proceduredescribinghowtowriteanSLAtemplatetoprovideacorrectservicedescription.

2. PublicationandDiscovery:publishtheproviderofferandpossibilityforthecustomertobrowse/compareoffers.

3. Negotiation: agreement on SLA conditions between the customer and the SP andbetween the SP and the FPs. This could be a bargain-like transaction or simply acombo list selection of predefined choices when the customer selects a specificoffering.

4. ResourceSelection:dependingonthechosenSLAforeveryservice,theSPbymeansof the orchestrator will map that specification to the resources that need to beassignedtotheserviceinordertomeetthisSLA.

5. Monitoring and Evaluation of the SLA: comparing all the terms of the signed SLAwith the metrics provided by the monitoring system (from the orchestrator), inordertointernallypreventupcomingviolations.

6. Accounting: invoking the charging/billing system according to the result to informaboutbillableitemsaspenaltiesorrewards.

Figure2-11SLAlifecycle

Design

TheinformationthatshallbestoredintheSLAmanagementmoduleishighleveldescribedinTable2-9.

Item SLA templatespecification

SLAcontract

Partiesinvolved

Parameters

Penalties

SLAfulfilment

Billableitems

InputfromtheSP Input from the Input from the Output of the SLA


©T-NOVAConsortium

38

and FP fromthedashboard

dashboardas theoutputoftheSLAnegotiation

the monitoringsystem in theorchestrator

managementmodule (to be sentto the accountingmodule)

VNFID

ServiceID

Table2-9SLAmanagementmoduleinformation

Interfaces

Sofar,severalinterfacesareforeseentoeasethecommunicationwiththeotherpartsoftheT-NOVAsystem.Theseare:

§ Interfacetothedashboard:theSLAmanagementmodulewillprovideanAPItothedashboard to show the pertinent SLA information (template specification,agreement,SLAfulfilment,etc.)andtointroducetheSLAtemplates.

§ Interfacetotheaccountingsystem: theSLAmanagementmodulewillbeconsultedbytheaccountingmoduleaboutbillableitemsaspenaltiesorrewardswhentheSLAhasnotbeenachieved.Also,theAccountingModulewillbeinchargeofintroducingthe final agreements once a purchase has occurred and to start/stop the SLAenforcementonceaservicehasbeenprovisionedorstopped.

§ Interface to the orchestrator: TheOrchestratorwill get the information about thetermsagreedontheSLAandgeneratethemonitoring information foreachmetricwich will be consulted periodically by the SLA module to determine the level offulfilmentoftheSLAforeachserviceandfunction.

2.6.2.7. Accountingmodule

Functionality

The accounting module in T-NOVA will be in charge of registering all the businessrelationshipsandevents(subscriptions,SLAevaluationsandusage)thatwillbeneededforbilling. The accountingmodulewill be the intermmediate component between the billingmoduleandtherestofthesystem.

Design

Thehigh-levelinformationthatshallbeusedbytheaccountingmoduleisdescribedinTable2-10.

Type ItcouldbeaServiceorastandaloneVNF.

InstanceID IDoftheinstanceoftheservice(orfunction)inthesystemonceit’sbeeninstantiated.It’susedforinteractionswiththeOrchestrator.

Client PurchaseroftheService(Customer),orFunction(SP).

Provider SelleroftheService(SP),orFunction(FP).

SLA Id of the SLA agreement of the transaction (in order to get possiblepenaltiestobeapplied)


©T-NOVAConsortium

39

Status Currentstatusortheservice(orfunction):Runningorstopped,

Billing InformationonhowtobilltheService(orfunction)totheclient.

Dates Datewhentheservice(orfunction)wasinstantiated.

Table2-10Accountingmoduleinformation

Interfaces

§ Interfaces to the SLA management module: the SLA management module will beconsultedfromtheaccountingmoduleaboutbillableitemsaspenaltiesorrewardswhentheSLAhasnotbeenachieved.

§ Interface to the service selection module: the Service Selection module will be inchargeofcreatingtheentries in theAccountingmodule.While theOrchestrator isinstantiatingaservice,theServiceSelectionstoresintheAccountingmodulealltheinformationnecessarytotrackthenewlycreatedinstancesandlinkthemtotheSLAagreementandthepricingdataforamoreaccuratelaterbilling.

§ Interfacetotheorchestrator:themonitoringsystemintheorchestratorwillusethisinterfacetoupdateintheaccountingsystemthestatusofthedifferentservicesandfunctions.

§ Interfacetothebillingmodule:bymeansofthisinterfacethebillingmodulewillgetalltheinformationitwillneedtoissueabill.

2.6.2.8. Billingmodule

The billing module in T-NOVA is in charge of generate the bills for users and providersandrevenue sharing reports between the ServiceProvider (SP) and the FunctionProviders(FP)attheendofabillingcycle.Inordertoreusedexistingsolutions,thebillingmoduleinT-NOVA will be an adapted version of the opensource rating-charging-billing frameworkCyclops[35].

Functionality

Cyclopsallowsdatacollection,normalizationandpersistenceofresourceconsumptiondatafor services consumed by the customers. The framework does not implement meteringitself; it assumes that the resources that are being consumed are being measured. Itprovides a rich set of APIs for (non-natively supported) applications to report theconsumptiondatatoCyclops.Nativelyitextractstheusagevalues(ofresources)fromafewsupportedIaaSandPaaScloudplatforms.

Cyclopsallowscustomsetofmeterstobedefinedandfurtherallowsproviderstocustomizethe rating and billing rules associated with such meters. Natively, it supports all built inmetersforOpenStackandsupportforCloudStackisunderdevelopment.

The framework generates usage data reports periodically, which has been extended tosupporteventsbasedusagereportsgenerationfortheT-NOVAbillingscenarios.Chargedatarecords are generatedperiodically also. This in T-NOVA is governedby the billingmodels,whichareassociatedwithserviceorVNFsinstancesbelongingtocustomers.

CyclopsprovidesRESTAPIs forbill generationby specifyinganydesiredperiod,hence theuserofCyclopsmustdeterminetheendofbillingcycleeventandusethebillgenerationAPIfromCyclops.


©T-NOVAConsortium

40

AllthedatastoredwithintheCyclopsframeworkhaveassociatedtimestamps,thusjustifyingthedatastorageintotime-seriesdatastore.ItnaturallysupportsvariousdataanalyticsandhasrichAPIsfordatavisualization.

The framework has been extended to allow revenue share computation and reportgeneration formonetary settlements between the SP and the FP taking into account theexistingrevenuesharingagreementbetweenthem.

Design

Cyclopsframeworkisinspiredbymicro-servicesdesignapproachfordistributedapplicationdevelopment.Thekeymicro-servicesinCyclopsare:

a) UsageDataRecord(UDR)mService,b) ChargeDataRecord(CDR)mService,c) BillingmService

The external applications send relevant data into Cyclops asynchronously over highlyavailable message bus. The framework is integrated with Gatekeeper authentication andauthorizationservice.Thehighlevelarchitectureisshownbelow:

Figure12:Cyclopsmicro-serviceArchitecturerepresentation

Interfaces

In T-NOVA, Cyclops has interfaces with the Accounting module, and the marketplacedashboard. The lists of various interfaces and the functionality that are (or could be)achievedovertheseinterfacesaredescribedbelow:

• Cyclops-UDR-Accounting-supportseventbasedusagereportsgenerationforactiveserviceinstances

• Cyclops-CDR-Accounting – supports event based charge reports generation foractiveserviceinstances,billingmodeldetails,


©T-NOVAConsortium

41

• Cyclops-billing-Accounting – information flow allowing generation of revenuesharingreportbetweenSPandFP.

• Cyclops-billing-SLA–SLAviolationsdataqueryfrombillingmicro-serviceforagivenperiod

• Cyclops-billing-dashboard–billgenerationforanydesiredperiod.• Cyclops-UDR-dashboard – data extraction API could be used to provide rich

visualizationtocustomers• Cyclops-messaging-Accounting – allows sendingonbilling relevant service lifecycle

eventstobesenttoCyclops

Atamuchhigherlevel,theseinterfacescanbeaggregatedintothese3listedbelow:

1. Cyclops-Accounting2. Cyclops-Dashboard


©T-NOVAConsortium

42

3. NETWORKFUNCTIONFRAMEWORK

This section is devoted to the definition and specification of the Network FunctionFrameworkthatistheT-NOVAarchitecturalelementrelatedtothestructureandbehaviourof theVirtualNetworkFunctions (VNFs). This sectiondescribesalso theNetworkFunctionStore (NFS) thatcontains theVNFs’ (VirtualNetworkFunctions) software imagesand theirmetadata description. This section provides also the high level description of VNF design.Finally,itdescribesthelifecycleofaVNF.

Insummarythecontentofthissectionis:

- DesignofVNFcommoncomponents.- StudyofNetworkFunctionLifecycle.- SpecificationofNFAPIs.- DesignofNetworkFunctionStore.

WerecogniseETSINFVasanotablebodyworkingonVNFspecification.InthisdocumentwewillmakeseveralreferencestoETSIwork.WewillalsocompareT-NOVAwithETSINFVwiththeaimofidentifyingsynergiesandgaps.

3.1. Highleveldescription

TheNetworkFunctionStore(NFStore)containsalltheinformationoftheVNFsprovidedbydifferentsoftwaredevelopersorFunctionProviders (FPs) thatwant tooffer themthroughtheT-NOVAmarketplace.TheNFStoreismaintainedbytheT-NOVAOperator.

TheNFStorecontainsVNFs:

- providedbyseveral(third-party)developers,- publishedasindependententities,- accompaniedwiththenecessarymetadata.

The diagram in figure 3-1 provides a very high level architectural description of therelationshipsofNFStoreandVNFswiththeotherelementsofT-NOVAarchitecture.


©T-NOVAConsortium

43

Figure3-1.VNFframeworkhighlevelarchitecture

TheVNFs images reside in theNF store.Theyare selectedvia themarketplacedashboardandtheninstantiatedanddeployedovertheexecutionplatform(NFVInfrastructure).TheT-NOVAorchestrator, specifically theNFVManager, controls theexecutionofVNFsover theNFVInfrastructure.

The NF Store is mainly a repository for the VNFs and their metadata. A VNF can beversioned. Whenever a new VNF is added to the repository, the NF Store informs theorchestrator. Then, the orchestrator retrieves the VNF image andmetadata from the NFStore.ThesameprocedureappliesforVNFremoval,orforanyothermodificationtoaVNFintheNFStore.

According to this approach, the T-NOVAOrchestrator can be considered a single point ofknowledge,meaningthattheinformationshallalwaysbeeasilyandeffectivelyaccessibletotheorchestrator.

TheVNFManagercontrolsVNFsthroughtheT-Ve-Vnfminterface.Theoperationsoverthisinterface are related to the VNF lifecycle, which must be supported by each VNF to becompliantwith T-NOVA system.During the active phase of a VNF, themonitoring systemprovidesinformationtotheVNFManageraboutthestatusofthevirtualizedinfrastructureresources (e.g. remainingcores intheVNF Infrastructure),somegenericmetricsaboutthesate of each VirtualMachine running each VNF (e.g.% CPU, used RAM) and finally someapplication-specific indicatorsdirectlyprovidedbytheVNFs(e.g.concurrentsessions).ThisinformationallowstheOrchestratortotakedecisionsaboutresourceallocationandinitiatescalingproceduresifneeded.Thisdetailedarchitectureisrepresentedinfigure3-2diagram.


©T-NOVAConsortium

44

Figure3-2.VNFframeworkdetailedarchitecture

3.2. NFCommonComponents

ThisintroductorychapterdescribesthecomponentsandbehavioursofT-NOVAVNFs.Allthetopicswillbedeeplyanalysedindedicatedsections.Thespecificdetailsforimplementationwillbedescribedinotherdeliverablesoftechnicalworkpackages(fromWP3toWP6).

3.2.1. NFstructureandproperties

Generally speaking, a Virtual Network Function (VNF) is an executable software programthatimplementsthewholeorpartofsomenetworkfunctionsandishostedinavirtualisedplatform. VNFs can be deployed in a network solution between computer machines(virtualisedornot)andphysicalnetworkingdevices.

Giventhequickconvergenceofcomputing,storageandnetworksandtheveryhighvolumeof standard servers that are shipped, the idea is to exploit the flexibility and agility ofsoftwareimplementationsincomparisonwithhardwareproprietaryboxes.Inthisway,thelaunchof new telecom services in short time is relatively easy.Most of customhardwareappliances (e.g., network processors, digital signal processors, firewalls, etc.) can beimplementedasVNFsandmovedwhereandwhenneeded.

In the scopeofT-NOVAproject, aVNF isa virtualmachineoragroupof virtualmachinesthat implementsNetworkFunctions in software.TheVNFhigh levelarchitecturalmodel isrepresented in figure 3-3. A VNF is characterised by two attributes: the operationalfunctionalities and the management behavior. The operational part explicitly defines thenetworkfunctionsthataresupported,whilethemanagementpartisresponsiblefortheVNFlifecycle(i.e.start,stop,pause,scaling,etc.).

Startingfromtheoperationalpart,aVNFapplicationmaysupportoneormoreapplicationnetwork interfaces for communicating with other VNFs at the application layer level.Incomingandoutcomingdatatraffic(afterbeingprocessedbytheVNF)arepassedthroughVirtualNetworkInterfaces(VNIs).

Ontheotherhand,twospecificinterfacesexistformanagementpurposes.Ontheonehand,aVNFmanagementsocketinteractswithVirtualisedInfrastructureManager(s)-VIM(s)-and


©T-NOVAConsortium

45

on the other hand, a management interface is used to communicate with the T-NOVAorchestratorframework(seeT-NOVAdeliverableD2.21[3]formoredetails).

Figure3-3.VNFhigh-levelstructure

Even if internals of a VNF are left to the VNFDeveloper,we suggest adopting a commonstructureforVNFcomponentsdepictedinfigure3-4.

The“VNFController”istheinternalcomponentdevotedtothesupportoftheVNFlifecycle.The “Init Configuration” component is responsible for the initialization of the VNF thathappensatthebeginningoftheVNFexecution.TheMonitoringAgentcomponenttransmitsapplication-levelmonitoringdatatowardstheMonitoringSystem.

Figure3-4.VNFinternalcomponents

AlloftheabovementionedVNFinternalcomponentsareoptional,excepttheVNFControllerwhichmustbepresentineachVNF.Tobemoreprecise,theVNFControllerwillinterfacetheVNFmanagertosupportthelifecyclemanagementoperationswithintheVNF.Moredetailsabout the allocation of the VNF internal componets require to introduce the concept ofNetworkFunctionComponentasexplainedinthefollowingsection.

3.2.1.1. VNFcomposition

MorethatoneVirtualMachinecanbenecessary torealizeasingleVNF. In thiscase,eachVMiscalledaVirtualNetworkFunctionComponent(VNFC).


©T-NOVAConsortium

46

Thediagraminfigure3-5representsaVNFcomposedbytwoVNFCs,oneofthemexposingonenetworkinterface,whiletheotherbeinginternaltotheVNF.

Figure3-5.VNFcomposition

BothOperational (specific toeachVNF)andManagementbehaviours (ie. Lifecycleevents)aredescribedinVNFDescriptorsandVNFCDescriptorsfiles.Forexample,aVNFDescriptorimposestheminimalVNF infrastructureresourcerequirementsthataVNF instanceneeds.Moreover,VNFDescriptorsprovidedetailsabouttheinstanceinternaltopologyandlifecycleoperations.

Inaddition,theVNFprovidesthedescriptionofthegroupofVNFCthatcomposesit.

The only component of the VNF directly interacting with the Orchestrator is the VNFControllerthroughtheV-Ve-Vnfminterface.

The VNF and VNFC properties, contained in corresponding descriptors, will be exposedthroughtheVNFManagementsocket.

In thecaseofa composedVNF, the internalVNFcomponents requiredbyT-NOVAcanbeallocated in many different ways. The minimal mandatory requirement is that each VNFmust have only one VNF controller. The other components, i.e. Init Configuration andMonitoring Agent, can be optionally allocated in the different VNFCs. In figure 3-6 weprovide an example of a VNF composed by twoVNFCs. In this case the Init ConfigurationcomponentisallocatedinalltheVNFCs,whilethereisonlyoneMonitoringAgent.OfcourseotherconfigurationsarepossibledependingontheparticularitiesoftheVNF.

Figure3-6.VNFinternalcomponentsinmultiVNFCsVNF


©T-NOVAConsortium

47

InT-NOVA,allrelevantinformationisexpressedusingametadatalanguage.SincemetadatapermitstheautonomousoperationofeachVNFandVNFC,directinteractionbetweentheT-NOVAOrchestratorandVNFCslocatedinsideofVNFshasbeenconsidered.Theinteractionwiththemarketplaceisindirectthroughmetadatadescriptors.

Servicegraphorforwardinggraph

ServiceChainingcanbeused tobuildEnd-To-Endservice.Theycanbebuiltbycomposingseveral VNF, thanks to themetadata used in the descriptors. The VNF Forwarding Graphdepictsthis interconnectionofVNFsandthetrafficflowsbetweenthem.Morespecifically,severalVNFscanbeconnectedtoprovideaservice,andtheseconnectionscanbevisualisedthrough a graph. The T-NOVA Orchestrator can use the VNF descriptors for creating thisServiceGraph(orforwardinggraph)byinteractingwiththeVNICsoftheVNFsaspresentedinfigure3-7.

Figure3-7.VNFServiceGraph

3.2.2. MetadatainT-NOVA

TheVNFmetadatadescriptor(VNFD)providestheinformationfordescribingwhattheVNFfunctionalities are andhow tomanage them.Many approaches are currently availableonhowtoimplementthistemplate,namely:

- AmazonAWSCloudFormation[36]- OpenStackHeatOrchestrationTemplate(HOT)[37]- ETSIVNFDescriptorTemplate[7]

Theyprovidethetechnical informationforconfiguring,runningandoperatingtheVNF, i.e.the virtual machines with the software application images providing services in a cloudenvironment.

In T-NOVA, wewill extend this information with business-relevant aspects that allow theregistrationandtradingofaVNFinthemarketplace.

TheVNFDescriptorsinT-NOVAwillinclude:

- theVNFnameandtheversion;- thevendoroftheVNF;- theVNFbehaviour(i.e.,thedescriptionofwhattheVNFdoes);- anSLAdescriptionoffer;- apriceoffer;- thereferencetothesoftwareimageassociatedwiththeVNF;


©T-NOVAConsortium

48

- theminimumrequiredhardwareresources(e.g.CPUunitnumbers,virtualmemorysize,virtualdisksize);

- thenetworkinterfaces(i.e.,theconnectionpointswiththenetwork);- selectedperformancemetrics(i.e.howVNFshallperformintypicalconfigurations);- thedefaultdeploymentparameters;- the definition of some statistics (i.e. monitoring data generated during the active

stateoftheVNF);- informationabouthowtoproperlyscaletheVNF(i.e.,scalinginprocedures);- possiblefunctionalornetworkconstraints;

FromthemomentthatallmetadataofaVNFwillbeavailabletotheT-NOVAplatform,themarketplace can use operational and business information for selecting themost suitableVNF according to customer’s needs and willingness to pay. At the same time, theOrchestratorwillexploitthemetadataformanagingtheVNFaccordingtotheVNFlifecycle.

Besides this high level approach, an in-depth analysis about metadata structure andtemplate creation have been made in the technical workpackages WP3, WP4, WP5, andWP6. We decided to publish the in-depth analysis directly in T-NOVA public web site(http://www.t-nova.eu). A practical reason is that the architectural definition and thespecifications in this document remain vaildwhile the research and definition of the VNFdecriptor will continue after the final issue of this document, therefore we would haveriskedtopublishincompleteorinconsistentinformation.MostimportantistheambitiontoencouragetheadoptionofT-NOVAframeworkbyalargenumberofVNFdevelopersandthisinformationisfundamentalforthemfordevelopingtheirVNFs.

3.2.3. T-NOVANFFrameworkandETSINFVcomparison

ThisparagraphmakesacomparisonbetweentheVirtualNetworkFunction(VNF)frameworkthatwillbeusedinT-NOVAandtheonespecifiedbyETSI.

In ETSI NFV specifications, the objective of NFV is to separate software that defines thenetwork function (the VNF) from hardware and software used to create generic hostingfunctionsinfrastructurewhichexecutestheVNF(theNFVI:NetworkFunctionVirtualizationInfrastructure).Therefore,therequirementisthatVNFandNFVIareseparated,asdepictedinFigure3-8.

Figure3-8.VirtualisationofnetworkfunctionsinETSI

Asaresult:

- theNetworkFunctionfunctionalblockissplitintoahostfunctionplusaVirtualized

NetworkFunction(VNF);

- acontainerinterfacebetweentheVNFandthehostiscreated;


©T-NOVAConsortium

49

- theNFInterfaceissplitintovirtualizedandinfrastructureinterfaces;

- the interfaces between non-virtualized and virtualized network functions are

homogenous.

An important concept must be taken into account: the VNF cannot be considered afunctionalblockindependentofitshostfunction.TheVNFcannotexistautonomously,sinceitisanabstractviewofthehostfunctionwhenconfiguredbyVNF.

The NFV architecture is thus not defined by functional blocks but using the followingentities:

- HostFunctionsandtheirassociatedcontainerandinfrastructureinterfaces;

- VNFswiththeirassociatedcontainerandvirtualizedinterfaces.

Regardingmanagementandorchestration,theETSIframeworkissplitintomanagementandorchestration of infrastructure (NFVI) and network functions (VNFs), as depicted in figure3-9.AsimilarapproachformanagementandorchestrationhasbeenadoptedinT-NOVA,asdescribedin[3]and[2].

Figure3-9.ManagementandorchestrationofNFVsinETSI

WithparticularregardtothestructureoftheVNF,whichisthefocusofthissectionofthedocument, ETSI specifies a number of interfaces,which are relevant to the VNF softwarearchitecture,asdepictedinfigure3-10.


©T-NOVAConsortium

50

Figure3-10.NFVarchitecturalframeworkandinterfacesinETSI

Inthefollowinglist,abriefexplanationoftheseinterfacesisprovided.

- SWA-1:thisisawell-definedinterfaceusedtoconnectvariousnetworkfunctionsin

aforwardinggraph.

- SWA-2:itreferstoVNFinternalinterfaces,i.e.forVNFCtoVNFCcommunication.In

fact,aVNFcanbedecomposedandmadeupfromsub-partsorcomponents(VNFCs)

whicharethemselvesVNFsinterconnectedbytheinfrastructure.

- SWA-3: it interfaces the VNF with the NFV management and orchestration,

specificallywiththeVNFM.

- SWA-4:itisusedbytheEMStocommunicatewithaVNF.

- SWA-5:itcorrespondstoVNF-NFVIcontainerinterfaces.

InT-NOVA,theVNFstructurehasbeencompletelydescribedinparagraph3.2.1.Figure3-11shows the T-NOVA VNF high level structure and the mapping with the VNF’s interfacesspecifiedbyETSI.

Other reference pointsMain NFV reference pointsNFVI Host Container

OSS/BSS

NFVI

Os-Ma

Vn-NfNf-Vi Or-Vi

NFV Orchestrator (NFVO)

EMS

Or-Vnfm

Vi-Vnfm

VNFManager (VNFM)

VeNf-Vnfm

VNFC

SWA-5

SWA-2

SWA-4

SWA-1

Vn-Nf

VNFC

SWA-5

Separate Instances,Separate Containers,

Both SWA-5 Instances

Virtualized Infrastructure

Manager(VIM)

VNF

VNF

VeEn-Vnfm

SWA-3


©T-NOVAConsortium

51

Figure3-11.T-NOVANFVstructuremappingtoETSIframework

ItisworthnotingthatETSIinterfacesSWA-1andSWA-2correspondtointerfacesusedinT-NOVAforcommunicationbetweenVNFsandVNFCs, respectively.Regardingmanagement,theT-NOVAframeworkisalignedwithETSISWA-3andSWA-5aswell,byadoptingacoupleof interfaces for the control of VNFs from the T-NOVA Orchestrator and the control ofinfrastructure by the T-NOVA VIM. The interface SWA-4 with the Element ManagementSystem (EMS) is not further specified by ETSI because it is considered already present incurrentnetworkarchitectures.ForthesamereasoninT-NOVAweconsiderthisinterfaceasavailable.

Besides the comparison of the ETSI and T-NOVA VNF frameworks, a brief explanation ofcommon patterns in VNF design and operations defined by ETSI and the correspondingsupportofrelevantfeaturesinT-NOVAisprovidedinTable3-1.

ETSIVNFfeature Description T-NOVAsupport

VNF designpatterns

VNF InternalStructure

VNF(C) composition ispossible

Supported.

VNFInstantiation Each VNFC of a VNF iseither parallelizable ornon-parallelizable.

Supported.

VNFCStates EachVNFCof a VNFmayneed to handle stateinformation.

Supported.

VNF Load BalancingModels

There are different typesof load balancing,typically 4 models areidentified (internal,external, e2e andinfrastructure).

Readytosupportit.

Not studied in thedeliverable.

VNFScalingModels Auto, on-demand andmanagement basedscaling.

Driven by T-NOVAOrchestrator.

VNFComponentRe- Different models have Component re-use


©T-NOVAConsortium

52


Use been studied regardingcomponent re-use butonly one case has beenagreed as relevant forETSINFV.

is possible andencouraged. Notstudied in detailsbecause out-ofscopeforT-NOVA.

VNF Update andUpgrade

VNF Update andUpgradeOverview

ThekeydifferenceisthatVNF upgrades mayrequire planning onnetwork service level,whileVNFupdatescanbedeployed withoutcoordination with otherVNFs participating in thesameVNFFG.

Update andupgrade requirecreating newservice instanceusingupdatedVNFsversions availablein the FunctionStore.

VNF Update &UpgradeRequirements forVNFProvider

The VNF package shallprovide an automaticprocedure forupgrade/update of theVNF instance. Theprocedure shall supportcontroloftheprogressofthisprocess,includingtheallocation of virtualresources from the NFVmanagement andorchestration. Roll-backwillbesupportedaswell.

Sameasabove.

VNF'sProperties HardwareIndependence

HW dependent, partlyCOTS,COTS.

Only COTSconsidered untilnow.

Virtualization andContainerAwareness

Hypervisor (agnostic,dependent), OScontainers, HL containertech, no virtualized & nocontainer, partlyvirtualized.

Hypervisoragnostic.

Elasticity No, any, in/out only,up/downonly

Onlyin/out.

ScalingAutomation No, VNF-triggered,triggered by the NFVmanagement andorchestrationfunctions.

Triggered byT-NOVAOrchestrator.

VNF PolicyManagement

Full policy, not policybased. This feature isrelated to theabilityofaVNF to support rule-

Full policy issupported in T-NOVAmetadata.


©T-NOVAConsortium

53


based provisioningneeded for automatedtasks (e.g. scale-in, scale-out, or migration basedonthresholdcrossing).

Migrationoperations

No live, Live, Partial,other.

Notaddressedyet.

VNFState Stateful,stateless. Supported.

VNF InternalStructure

Simple,structured. Supported.

Reliability Dependent on faultdetection and faultreportingmechanism.

Reliability is up toeach VNF. It isprovided atapplicationlevel.

LocationAwareness Dependencies onposition.

Locationindependent.

ApplicationManagement

No, proprietary,standard,multipleserviceproviders.

Supported.

Diversity andEvolution of VNFProperties

In a VNF with multipleVNFCs, each VNFC mayhavedifferentproperties.

Supported.

Attributesdescribing VNF'sRequirements

VNF TopologicalCharacteristics

The deploymentconfiguration andoperational behaviour ofa VNF shall be describedaccording to a templatecalled

Virtualized NetworkFunction Description(VNFD).

T-NOVAmetadata.

Table3-1T-NOVAsupportofETSIVNFfeatures

Finally,thedatamodelusedtodescribeVNFsinT-NOVAisconsidered.

In ETSI, the Virtualized Network Function Description (VNFD) is a specification templateprovided by the VNF Provider for describing virtual resource requirements of a VNF. It isusedbytheNFVmanagementandorchestrationfunctionstodeterminehowtoexecuteVNFlifecycleoperations(e.g.instantiation,etc.).VFNDisfullydescribedin[7].

ThetemplatecapturesthegeneralcharacteristicsofeachVNFandisusedtoon-boardtheVNF,inordertosupporton-demandinstantiationsoftheVNFinanoperator'snetwork.

The deployment configuration and operational behaviour of a VNF shall be describedaccordingtothesameVFNDtemplate.Thedeploymentconfigurationdefinesthestateandenvironment for a VNF to be deployed, whereas the operational behaviour defines theneededfunctionsforaVNFtobeoperatedandmanagedproperly[6].


©T-NOVAConsortium

54

TheVNFDiscomposedofthefollowingmaininformationelementsgroupings:

•VNFidentificationdata,including:

- DatatouniquelyidentifytheVNFvendor/provider.- TypeanddescriptionoftheVNF,whichhelptoidentifytheNetworkFunctionthatis

implementedasaVirtualNF,andenable interoperabilityofVNFsmanufacturedbydifferentVNFProviders.

- Version.

•VNFspecificdata,including:

- SpecificVNFconfigurationdata.- Connectivityrequirementsandinter-dependenciesofVNFCs.- VNFlifecycleworkflowscripts.- Deploymentflavours,specifyinghowmanyinstancesofeachVNFCtypeandversion

tobeinstantiatedbasedonserviceKPIs.- Deploymentconstraints.

•VNFCdata,including:

- Typeandidentification,uniquelyidentifyingtheVNFCtype.- SpecificVNFCconfigurationdataandscripts.- Deploymentconstraints.- Virtualcontainerfiles/imagesreferences,includingthepossibilitytodefinepackages

of: VNFC binaries plus operating system, empty operating system, and/or emptyvirtualcontainer(i.e.,unloadedoperatingsystem).

•Virtualizedresourcerequirements,including:

- Compute resources, e.g. virtual CPU and virtual RAM assigned to the virtualcontainer.

- Storageresources,e.g.sizeofthevirtualdiskassignedtothevirtualcontainer.- Network resources, e.g. number and type of virtual NICs that are assigned to the

virtualcontainer,includingalsorequirementsfornetworkbandwidth.

Besides all this information, the metadata used in T-NOVA (section 3.2.2) includes someadditional information for the marketplace, which is used to build and maintain anecosystemforaneasyandefficientbrokeringofVNFsamongdifferentstakeholders inthemarket(FPs,SPsandCustomers).

3.3. NFLifecycle

TheVNFlifecycleencompassesthedifferentstagesthataVNFneedstopassthrough.IntheT-NOVAproject,wehavedefinedthefollowingstages:

• Development:o Software implementation of Network Functions (NFs) is performed by

Function Providers. NFs are published and aggregated in the T-NOVAFunctionStore.

• Validation:o Thevalidationprocedureaimsatprovidingacertificationthatthedeveloped

NFswillworkasexpected.• Publication:


©T-NOVAConsortium

55

o NFpublicationisperformedattheNFStore,whoserepositorywillhostboththe function image (as stand-alone application or integrated VM) and theassociateddescription/metadata

• Brokerage:o Brokerage isundertakenby thebrokeragemodule in themarketplace that

will match users’ service requirements with the technical capabilitiesprovided by the NFs, thus ensuring that the resources required for NFsdeploymentareavailable.

• Selection:o Finally the customer selects themost suitableNFs according to his or her

needs.• Deployment:

o TheVMimageanditsmetadataaretransferredfromtheNFStore• Management:

o This is the runningphaseof theNF.AnApplicationProgramming Interface(API)willbeexposed to theochestrator for setupand real-timecontrolormanagement. The running phase can be preceded by a networkre-configurationprocedure.

• Termination:o InvolvestheremovaloftheNFinstancefromthevirtualisedinfrastructure,

includingnetworkre-configuration,ifneeded.

TheVNFlifecycleisrepresentedinfigure3-12.

Figure3-12.VNFlifecycle

Actual interaction between T-NOVA Orchestrator and VNF happens in management andtermination states of the VNF lifecycle, as highlighted in figure 3-12. This considerationbringstothedefinitionoftheextendedVNFlifecyclepresentedinfigure3-14. Ithighlightsthestatusdiagraminternallytothemanagementstatus.

Figure3-13.ExtendedVNFlifecycle

The VNF lifecycle is implemented by events generated by the VNFM towards the VNFControllerFunctionineachVNF(see:figure3-2).


©T-NOVAConsortium

56

TheremainingofthischapterisdevotedtothedetaileddescritionofthisVNFlifecycle.

3.3.1. Development

ThedevelopmentcoverstheimplementationphaseoftheVNF.

TheVNFshallbeuploadedontheFunctionStoreusingtheMarketplacedashboard.TheNFapplication will run in the execution environment under the coordination of T-NOVAOrchestrator.

TheVNFdevelopershallalsoprovidethemetadatadescriptionoftheVNF.Thedescriptionincludes both functional and non-functional information that will be used by differentelementsofT-NOVAframework.

T-NOVAdoesnotintendtouseaspecificprogramminglanguagenortoimposeagivenSDK.TheresultoftheVNFdevelopmentprocessconsistsofoneormorevirtualmachineimagesandtherelatedmetadatafiles.Theinformationmodelisdescribedinasection3.2.2ofthisdocumentandpublishedintheT-NOVApublicwebsite(http://www.t-nova.eu).Asfortheimplementation details, they will be addressed in the WPs dedicated to VNFimplementation.

3.3.2. Validation

ThevalidationprocessensuresthattheVNF:

- supportsT-NOVAT-Ve-VnfmAPI,- operatesasexpected,- performsasexpected.

InT-NOVAitisrequiredthatonlyvalidatedVNFscanbeuploadedtotheNFStore.

VNFvalidation isperformedoff-lineandprior toanyupload.Thisprocesswill inparticulargeneratesomeinformationthatwillbereflectedintheVNFmetadata.

ImplementingautomatedtoolsforVNFvalidationisout-of-scopeofT-NOVA.Nevertheless,T-NOVA will provide guidelines and describe validation best practices based on theexperienceacquiredfromtheeffectiveimplementationofVNFsintheT-NOVAframework.

The validation process shall include executing a number of test suites. The minimalrequirementistoverifythattheVNFsupportstheT-NOVAAPIforthewholeVNFlifecycle.Thisgoalcanbeeffectivelyreachedbyusingthe"TDDkitforVNFdevelopers".ThisisaTestDriven Development environment a VNF develper can download from the T-NOVA publicwebsite.TheycanuseitforvalidatingtheirVNFwithrespecttotheVNFlifecyle.TheTDDkitconsistsofaVMcomposedbyatestgenerationengineandtestsuites.ThesetestsuitesarerunagainsttheVNFunderdevelopmentthatactuallyisanotherVM.

3.3.3. Publication

ThepublicationprocessconsistsofregisteringtheVNFanditsmetadata intotheNFStore.Only validated VNFs can be uploaded to the NF Store. The interactionwith the NF StoreoccursthroughauserinterfacesupportedbytheT-NOVAFPdashboard.


©T-NOVAConsortium

57

ThisstageoftheVNFlifecycleneedstobefurtherdetailedtoaddresstheupdatingofaVNForalsoitswithdrawalfromtheNFStore.

ThepublicationstageintheVNFlifecycleisthereforecomposedby:

- Publication,- Modification,- Withdrawal.

ofaVNFimageanditsmetadata.

In all the cases, the NF Store informs the T-NOVA Orchestrator about any modificationaffecting a VNF in the NF Store. In case of publication or modification of the VNF, theorchestrator gets the updated VNF image and metadata from the NF Store. In case ofwithdrawaltheorchestratorsimplyremovestheVNFfromitsinternaldatabase.

Thediagraminfigure3-14describesthepublicationprocedure.ThesameworkflowappliestothemodificationoftheVNFbyadaptingthefunctioncallsaccordingly.

Figure3-14.VNFpublicationintheNFStore

The workflow for withdrawing the VNF from the NF Store is slightly different. It isrepresentedinfigure3-15.


©T-NOVAConsortium

58

Figure3-15.VNFwithdrawalfromtheNFStore

3.3.4. BrokerageandSelection

Theseoperationsareperformedbythemarketplace.ThemetadataoftheVNFsisaccessedbythebrokeragemodule inthemarketplacetoperformtradingamongFunctionProvidersofferingVNFwithsimilarfunctionality.ThefinalgoalistofindthebestpricefortheServiceProvider,consideringtheVNFsdescriptionandofferedSLA(seesection2.6.2.3.).

3.3.5. Deployment

DeployingaVNFmeansinstallingandinitializingtheVNFintheNFVinfrastructure.ThentheVNFisreadytobeactivated.

ThedeploymentofaVNFconsistsoftransferringtheVNFVMimage(s)containingtheVNFfromtheNFStoretotheNFVinfrastructure.

ThedeploymentphaserequiresinteractionbetweenT-NOVAOrchestratorandtheVIM.

The workflow is fully described in Deliverable D2.31 related to Orchestration and VirtualInfrastructurespecification[2].

3.3.6. Management

Themanagementstageisdedicatedtoreal-timemanagementoftherunningVNF.

Thisiscomposedbyasetofsub-stagessuchas:

- set-up- start- stop- scaling- monitoring


©T-NOVAConsortium

59

ThemanagementphaseiscontrolledbytheT-NOVAOrchestratorthatdirectlyinteractswiththeVNFandtheVIM.ThereisalsoanindirectinteractionbetweentheVNFandtheVirtualInfrastructure because of the execution of the virtual machines composing the VNF. ThisinteractioniscommontoalltheVMsinacloudenvironment.

The VNF lifecycles events are described in a specific metadata file, the VNF Descriptor(VNFD), and are implemented as a set of operations or scripts the VNFM activates forconfiguringandcontrollingtheVNF.

During the VNF's provisioning stage the VNFM interacts with the Init ConfigurationcomponentthatcanbeallocatedineachVNFCcomposingtheVNF,whiletheVNFlifecyclerequiresVNFMinteractingwiththeVNFControllerthat ispresent inonlyoneVNFCoftheVNF.

3.3.6.1. Set-up

TheVNFset-upconsistsoftheinitializationphaseoftheVNF.TheorchestratoraskstheVIMtostarttheVNF.Thenitcandirectly interactwiththeInitConfigurationcomponentoftheVNF, for instance to configure the interfaces (e.g.NICs). This interactionhappens throughtheT-NOVAAPIsupportedbytheVNF.Thebootstrap initializationresults froman indirectinteractionwiththeNFVI.TheNICconfigurationisadirectinteractionwiththeorchestrator.The latter uses the VNF metadata information for learning about the VNF IP interfaces.Moreover, it needs to know the service description for configuring the service graph orforwarding graph in the right way. If needed, the ochestrator can also run networkconfiguration tasks. In this case the T-NOVAOrchestrator asks theVIM to reconfigure thenetwork.

Theset-upphaseinfigure3-16representsacaseofaVNFcomposedbyasingleVM.

Figure3-16.VNFset-up

IncasetheVNFiscomposedbyseveralVNFComponentstheorchestratorshallrepeattheprocedure for all theVMs. In this case theNIC configuration could requiremore complexinteractionswiththeVNF.


©T-NOVAConsortium

60

3.3.6.2. Start

ThestartcommandinstructstheVNFtostartprovidingitsservices.

Thestartphaseinfigure3-17representsacaseofaVNFcomposedbyasingleVM.

Figure3-17.VNFstart

3.3.6.3. Stop

ThestopcommandinstructstheVNFtostopproviding itsservices.Afterastopcommand,the VNF can receive a new start command. Otherwise, the lifecycle evolves to theterminationstage.

Wecandistinguishbetweengracefulandimmediatestop.GracefulstopisarequesttotheVNF to stop accepting new service session request. However, active service sessionscontinuetobesupporteduntiltheirnaturaltermination.Immediatestoprequestforcestheterminationofallactiveservicesession.

Thestopphaseinfigure3-18representsacaseofaVNFcomposedbyasingleVM.

Figure3-18.VNFstop

3.3.6.4. Scaling

Scalingexploits theelasticitypropertyofaservicebasedonacloudenvironment. Inotherwords, it is theability todynamically increaseor reducetheamountof resourcesusedforprovidingtheservice.AccordingtoETSINFV,scaling is theabilitytodynamicallyextendorreduceresourcesgrantedtoaVNF[38].

Scaling policies are known as scaling out/in, and scaling up/down. Scaling out/in meansallocating or releasing resource instances, i.e. creating new VMs or terminating VMs.Scaling-out adds, while scaling-in removes resource instances. Scaling up/down meansincreasingordecreasingtheresourcesallocatedtoaninstance,i.e.increasingordecreasingmemoryorcomputationpowertoaVM.Scaling-upincreases,whilescaling-downdecreasesresources.


©T-NOVAConsortium

61

Scaling out/inmust be supported by theVNF. It consists of accomodate or release a VNFcomponent instance inside of the VNF. Whenever the orchestrator decides for scalingout/in, it triggers theVNFMthat in turnsask theVNFtoaddor removeaVNF-C instance.Moreover the orchestrator is resposible to ask the VIM to allocate or remove the VMresourcesfortheVNF-Cinvolvedinscaling.

Implementing scaling up/down needs additional features not widely available in presentoperating systems and hypervisors. This scaling policy consists inmodifying the hardwareconfigurationofamachinewhileitisrunning.Boththehypervisorandtheoperatingsystemof thevirtualmachineshall support liveadaptationofcomputation,memory,storage,andnetwork resources. Moreover, these operations shall be coordinated between thehypervisorandtheoperatingsystem.Alsoforthisscalingpolicyit isuptotheorchestratorto initiate and manage the process. In this case it shall require dedicated VIM capabilitywhile it seemsthat theVNFapplication isnotparticularly involved in theprocess.T-NOVAdoesnotsupportscaleup/down.

Independently from the chosen policy, scaling can be the strategy adopted by a ServiceProvider (SP) to match customer’s expectation of an optimally performing system. Moretechnically,scalingmightbeafollow-upofmonitoringactivityonSLAfulfillment.Monitoringdataarecollectedfromthesystemmonitoringplatform(intheorchestrator)andalsofromtheVNFitself.MonitoringdatawillbecomparedagainstSLAthresholdprovidedbytheSLAmanagement module in the marketplace. Whenever, some threshold is overcome, theorchestrator shall perform the most appropriate scaling procedure according with thedescription contained in the VNF metadata. In case the SLA is not fulfilled by scalingprocedures, thiswouldbetaken intoaccountbytheSLAmanagementmoduletotaketheappropriateactionsthawillimpactinbilling(section2.6.2.6.).

The diagram in figure 3-19 gives an example of scaling-out procedure. As soon as thedemand for resources increases a new VNF-C instance is activated and configured forcollaboratinginefficientlyprovidingtheservice.

Figure3-19.Scaling-outexample

The VNF developer shall include in themetadata descriptor VNFD a section dedicated onscaling out/in. This information will be used by the orchestrator for activating theappropriateprocedurewhentheneedofscalingisdetected.

Moredetaileddescriptionof scaling-out isprovided in figure3-20.When theorchestratordetects the needof scaling, it interactswith theVIM for allocating newVMandwith theVNFM for activating the scaling procedure towards theVNF. TheVNF receives the scalingcommand and the references of the new VNF-C and activates the most appropriate


©T-NOVAConsortium

62

procedureforaccomodatingthenewVNF-C.Ingeneralitconsistsinthereconfigurationofaload balancing or scheduling funcion. For shake of clarity the detailed internal interactionbetweentheorchestratorandtheVNFMisnotdescribedhere.Detailsarein[39].

Figure3-20.Scaling-out

Theprocedureforscaling-inissimilartakingattentionthatnowtheVNF-Cinstanceshallbeterminatedandreleased.Scaling-outisdescribedinfigure3-21.

Figure3-21.Scaling-in

WerecongizethatformanyVNFsaninternalfront-end,scheduler,orloadbalancerfunctionis needed in order to support scaling. However, it is not wise to generalize this practiceimposingitinthedesignofanyVNF.

3.3.6.5. Monitoring

TheprovisionofaneffectivemonitoringforcheckingtheavailabilityandthehealthstatusoftheVNFs ismandatory. Thiswillhelp inbetterunderstandinghowtheVNFsareusingtheresources, and whether the resources are correctly used. In T-NOVA, the monitoringmechanismwillcollectanddisplaydifferenttypesofdataincludingmemory,virtualstorageandvirtualnetworkresourceusage.Tobemorespecific,themonitoringmechanismispartof theorchestratorandwillbe inchargeofmonitoringontheonehandthe infrastructurethrough the VIM and on the other hand the VNFs that are part of the service. Here, theFunctionProvider (FP)needstoprovidewhat tomonitorat theVNF level,andtheServiceProvider(SP)needstoperformthesametaskatthecomposednetworkservice.


©T-NOVAConsortium

63

Figure3-22.VNFmonitoring

In Figure 3-22 the KPIs defined by the Function and Service providers as well as theircorrespondingvaluesthataregeneratedduringtherunningphaseof theVNFsaresenttothemonitoringserverthatinturnsdeliversmonitoredinformationtotheorchestrator.Thelatterwillmatchthereceived informationagainst the“rules”thataredefinedthroughtheVNFmetadataorthroughtheSLAs.Basedonthiscomparison,anactionsuchasactivatingascalingproceduremightbetaken.TheKPIsthatcanbeusedforthemonitoringmechanismincludenetwork relateddata (packet loss,bandwidth, Jitter,CPUthreshold,etc.)anddatarelatedtotheserviceprovidedbytheVNF(incaseofSBCcouldbenumberaSIPmessagesinagiventimeslot,numberofconcurrentactivesessions,etc.).

3.3.7. Termination

This isthefinalphaseoftheVNFlifecyclethatoccursattheendoftheprovisioningoftheserviceimplementedbytheVNF.

Termination phase consists in the removal of VNF instance from the virtualizedinfrastructure.Itcanalsorequireanetworkre-configuration.

Theterminationphaseinfigure3-23depictsacaseofaVNFcomposedbyasingleVM.


©T-NOVAConsortium

64

Figure3-23.VNFterminationorclean-up

IncasetheVNFiscomposedbymoreVMsoralsomoreVNFCstheorchestratorshallrepeattheprocedureforalltheVMs.InthiscasetheNICconfigurationcouldrequiremorecomplexinteractionswiththeVNF.

3.3.8. T-NOVAvsETSINFVlifecycle

In thisparagraph,a comparisonof the lifecycledefined inT-NOVAprojectwith respect tothe lifecycle defined in ETSI NFV will be carried out. The focus will be on the lifecyclemanagement functions that are required to manage the instantiation, maintenance andterminationofaVNF(orNS).

InETSINFV,thestatetransitiondiagramforaVNFisdepictedin Figure3-24.


©T-NOVAConsortium

65

Figure3-24.VNFinstancestatetransitions

Accordingtothediagram,aVNFcanbefoundinthefollowingstates:

- Null:VNFInstancedoesnotexistandisabouttobecreated.- Instantiated Not Configured: VNF Instance does exist but is not configured for

service.- InstantiatedConfigured–Inactive:VNFInstanceisconfiguredforservice.- InstantiatedConfigured–Active:VNFInstancethatparticipatesinservice.- Terminated:VNFInstancehasceasedtoexist.

MakingacomparisonbetweenT-NOVAandETSIVNFlifecycle isnotatrivialtasksincetheETSI specification documents are still in draft status. The ETSI reference documents usedtakecarryoutthisanalysisare:

- NetworkFunctionsVirtualisation(NFV)-VirtualNetworkFunctionsArchitecture[6]thatdescribesthesoftwarearchitectureoftheNFVframework;

- NetworkFunctionsVirtualisationManagementandOrchestration[7]thatdescribesthefunctionscollectivelyprovidedbyNFVO,VNFM,andVIM.

The VNF lifecycle is controlled by a set of operations necessary for a VNF to provide itsexpected functionality. Theprerequisite for all lifecycleoperations is theVNFon-boarding(process of registering the VNF with the NFVO and uploading the VNF data (VNFD, SWimagesetc).

InTable3-2,anoverviewisgivenofT-NOVAlifecycleoperationsandhowtheymapto(ordifferfrom)theircorrespondingETSIlifecycleoperations.


©T-NOVAConsortium

66

LifecycleoperationETSIReference

T-NOVA ETSINFV

Development

In T-NOVA, development isthe process to build an NFapplication compatible withtheT-NOVAenvironment.

-

Development is not explicitly describedintheETSIframework.

-

Validation

In T-NOVA, validation is anoff-line process that has tobe made prior to any VNFuploadintheNFStore.

Validation

In ETSI, a validation step is requiredduringon-boardingbytheNFVO.

[7].5.4.1

Publication

In T-NOVA, a method isexposed by the T-NOVAOrchestrator fornotificationchange(s) in the NF Store.After notification, the T-NOVAOrchestratorrequeststhenewdata.

On-boarding

VNF on-boarding refers to the processofsubmittingaVNFPackagetotheNFVOrchestrator to be included in thecatalogue.

In ETSI, the sender will submit directlythe VNF Package data to theOrchestrator.

VNF Packagemanagement

[7].7.2.1

[7].B2.1

Modification Update

Withdrawal Delete

-

-

-

Managed by T-NOVAOrchestrator.

Disable

Enable

Query

VNF Packagemanagement

[7].7.2.1

Brokerage

Operation performed in theMarketplace.

-

NotinETSIscope.

-

Selection

Operation performed in theMarketplace.

-

NotinETSIscope.

-

Deployment Instantiate

Instantiate will include configuration ifspecified by the VNF deploymenttemplate. In ETSI, a feasibility check is(optionally) performed beforeinstantiation.

[7].5.4.2

VNF lifecyclemanagement

[7].7.2.4

[7].B.3.1.2

Management::Set-up Configure VNFconfiguration


©T-NOVAConsortium

67

LifecycleoperationETSIReference

T-NOVA ETSINFV

In T-NOVA, Get, Create andSet operations will besupported.

Get

In ETSI, the Configure interface willinclude the following operations: Get,Create,Set,DeleteandNotify.

[7].7.2.6

Management::Start Start [6].6

Management::Stop Stop [6].6

Management::Scaling

In T-NOVA, only in/outscaling will be supported.Sources of scaling will beeither the VNF or themonitoring platform itselfand the operation will beperformed by the T-NOVAOrchestrator.

Scale

In ETSI, scaling options are: in/out,up/down. Several sources of scalinghave been considered (MANO.B4) thatcan be reduced to two categories: (a)automated scaling, where decision isdone by or forwarded to the VNFManager and (b) scaling based onmanagementrequest,wherethescalingrequest is coming from some sender(OSS/BSS or operator) and received bytheNFVOrchestrator.


[7].7.2.4

[6].6

NotsupportedinT-Nova. In ETSI, the VNF lifecycle managementinterface will include the followingoprations:

Query

Check

Heal

Update

Modify

Upgrade

Reset


[7].7.2.4

[6].6

Management::Monitoring

In T-NOVA, a VNFmonitoring method isexposed by the T-NOVAOrchestrator.

In ETSI, monitoring is related to VNFperformance and VNF faultmanagement. VNF informationexchange is based on a notify/getmechanism.

VNF performancemanagement

[7].7.2.7

VNF faultmanagement

[7].7.2.8

Termination Terminate


[7].7.2.4

[7].B.6

Table3-2ComparisonofT-NOVAwithETSINFVlifecycleoperations


©T-NOVAConsortium

68

Inconclusion,thelifecyclemanagementofVNFsandrelatedpackagesadoptedinT-NOVAismostlyalignedwiththeoneadoptedinETSI.However,somedifferencesexistinpublicationand brokerage, which are T-NOVA specific. In fact, T-NOVA target is an open marketenvironment,whileETSIfocusislimitedtotraditionaltelcooperations.

Duetothefactthatneitherthespecifications inETSInortheworks inT-NOVAprojectareconsolidatedyet,somemoreinvestigationonthissubjectcouldberequiredinthefuture.

3.4. NetworkFunctionFrameworkAPIs

TheVNFframeworkdescribedinthissectioninteractswiththeT-NOVAsystemthroughtheinterfaces represented in figure 3-1. The interfaces are exposed by theNF Store and alsodirectlybytheVNFs.

TheNFStoreexposesinterfacesforinteractingwiththedatabaseoftheVNFmadeavailabletothesystem.

InterfaceT-Da-NfsisusedbythedashboardforinteractingwiththeNFStoreforpublishing,modifying,andwithdrawingaVNFanditsrelatedmetadata.

Interface T-Or-Nfs connects the NF Store with the orchestrator for providing informationabouttheVNFmetadatadescriptionand itsexecutable imagemakingtheVNFavailabletotheT-NOVAsystem.

Interface T-Br-Nfs is used by the Marketplace brokerage module to retrieve informationabouttheVNFsavailableintheNFStore.

InterfaceT-Ve-VnfmisexposedbyeachVNFtotheorchestrator.DuringtheactivephaseofaVNF,theinterfaceT-Ve-VnfmallowstheorchestratortodirectlyinteractwiththeVNF.Thisinteractiontakesplaceinthe“Management”and“Termination”statesoftheVNFlifecycle.In particular, the whole active phase of a VNF (set-up, start/stop, scaling, monitoring) iscontrolled by means of direct communication between orchestrator and VNF. SuchcommunicationisperformedthroughcallstotheexposedfunctionsoftheVNFsAPI.

3.4.1. APIshighlevellogicaldescription

ForeachinterfaceexposedbytheNetworkFunctionFrameworkweprovidethedescriptionof the high level logical primitives or API functions. In-depth analysis and detailedspecificationoftheAPIwillbedevelopedinworkpackageWP3andWP5.

3.4.2. NetworkFunctionStoreAPIs

TheseAPIsallows interactingwith theNFStore formanaging theuploading,downloading,anddeletionoftheVNFimageandtherelatedmetadatadescriptor.

InterfaceT-Da-Nfscontainsthefollowingoperations:

• publish_VNF,publish_VNF_metadatao UploadintheNFStoretheVNFimageandtheVNFmetadatadescriptor.

• withdraw_VNF,withdraw_VNF_metadatao DeletefromtheNFStoretheVNFimageandtheVNFmetadatadescriptor.


©T-NOVAConsortium

69

InterfaceT-Or-Nfscontainsthefollowingoperations:

• get_VNF_metadata,get_VNF_imageo ReadfromtheNFStoretheVNFimageandtheVNFmetadatadescriptor.

InterfaceT-Br-Nfscontainsthefollowingoperations:

• get_VNF_metadatao ReadfromtheNFStoretheVNFmetadatadescriptor.

The complete definition of the operations over T-Da-Nfs, T-OR-Nfs is described in thetechnicalspecifications[40],[41].

3.4.3. VNFAPI

TheAPIdescribed in this chapterallows theVNF tobemanagedby theorchestrator inT-NOVAsystem.AnyVNFmustimplementthisAPItobepartofT-NOVA.

InterfaceT-Ve_Vnfmcontainsthefollowingoperations:

• initial_configurationo Provides the initial configurationparameters toeachVNF-Ccomposing the

VNF. Typical usage is assigning the IP address of the VNF’s networkinterfaces.

• starto AskstheVNFtostartprovidingitsservices.

• stopo AskstheVNFtostopprovidingitsservices.Twotypesofstoparesupported:

hardandsoft.AsoftstopensuresagracefulceaseoftheVNF.Inparticular,asks to complete any in-progress operation before stopping the VNF. ThehardstopaskstoimmediatelyceasealltheoperationsoftheVNF.TheVNFremainsactiveafterthestopoperation iscompleted, i.e.theMVisupandrunning;onlytheserviceprovisioningisinterrupted.

• terminateo AskstheVNFtoterminateitsexecution.Thisoperationshuts-downtheVMs

composingtheVNF.• scale_out,scale_in

o Ask the VNF to perform scaling out/in procedures by reconfiguring theinternalresourcescomposingtheVNF.

3.5. NetworkFunctionStoredesign

TheNFStoreismainlyarepositoryfortheVNFsandtheirmetadata.HighlevelbreakupofNFStoreincludes:

- NFrepositoryo Archive of VNF images and related metadata. This data is versioned so that

differentversionsofthesameVNFcanbepresentintheNFStore.- NFSmanager

o ProvidesinterfacesforinteractingwiththeNFrepository.


©T-NOVAConsortium

70

TheNFrepositoryisresponsibleforconcurrentoperationsthatareperformedonthestore(CRUDoperations)onimagesandmetadata.

The NFS Manager block implements the interfaces to the repositories. In addition, itdelegates sometraitsof its responsability (likeauthenticationandauthorizationaccess) toanexternalAAmodule.Securitymechanismscanbeadoptedfordataexchangeovertheseinterfaces.

The NF Store provides interfaces to the orchestrator (T-Or-Nfs) and marketplace'sDashboard (T-Da-Nfs) and Brokerage (T-Br-Nfs) as described in Figure 1-1. An additionalinterface(notshowninthepicture)forconsolemanagementisforeseen.

Figure3-25.NFStorearchitecture

The requirements capture process for the Network Function Store has been performedaccordingtotheprocedureexplainedinsection2.5forthemarketplacecomponents.TheyarelistedinAnnex6.1.2.


©T-NOVAConsortium

71

4. INTERACTIONBETWEENNETWORKFUNCTIONFRAMEWORKANDTHEMARKETPLACE

InthissectionweaimtosummarizeandtomakeclearertherelationbetweentheNetworkFunctionFrameworkandtheT-NOVAMarketplaceaccordingtowhathavebeendescribedintheprevioussections.

Firstly, the way of purchasing VNFs it is summarized in section 4.1, and the interfacesbetweentheNFStoreandthemarketplaceareexplainedinsection4.2.

4.1. PurchaseofVNFs

Thepurchaseof aVNF through the T-NOVAmarketplace should go through the followingsteps:

VNFstorage

TheT-NOVAMarketplacewilladvertiseonlyvalidatedNetworkFunctions(NFs).Afterbeingtestedandvalidated,theNFswillbeuploadedintotheNFStore.TopreventmisuseoftheNFStore,theFunctionProvider(FP)needstoauthenticateitselfandbeauthorizedtouploadtheVNF.ThesameauthenticationprocedureenablestheFPtouploadandupgradedversionofitsVNF.InadditiontotheVNF,thecorrespondingmetadatainformationhastobemadeavailable.

VNFadvertisement

ThemarketplacewilladvertisetheVNFsstoredintheNFStorebasedonthemetadatathataccompaniesthemandtheiravailabilityprovidedbytheorchestrator.IncaseanewversionoftheNFunderconsiderationisuploaded,theNFStorewill informtheorchestratoraboutthisandconsequently,theVNFadvertisementonthemarketplacewillbeupdated.

VNFpurchase

AcustomerwillingtopurchaseaservicefromT-NOVAwillneedlookforavailableservicesbyselecting availableVNFsorNetwork Services (NSs), and setting the start andendday andtimeof theservice.Thecustomermightalsoneedto insert the informationrelatedtotheingressandegress routers thatwill form theendpointsof thepath thatwill carryon theservicetraffic.ThecustomerwillalsoneedtospecifytheSLArequirementsheisinterestedin.

Once the customer selects a service, it will need afterwards to configure the relatedparameters.ThiswillvaryfromoneVNFtoanother.Theparametersmightinclude(contenttype,protocolstobeused,traffictobeallowedordenied,prioritizationrulesifneeded).

Aftertheconfiguration,theserviceisreadytorun,however,thecustomerneedsfirstofalltoselectthemeansbywhichitwillbecharged.

4.2. Marketplace–FunctionStoreinterfaces

TherearetwointerfacesbetweenthemarketplaceandtheFunctionStore:


©T-NOVAConsortium

72

1. T-Da-Nfs:TheinterfacebetweenthedashboardandtheNFStoredespictedinFigure2-4hasthesinglefunctionalityofprovidingtheAPIfortheFunctionProviderstoinserttheirVNFsofferingsandassociatedmetadataintheFunctionStore.

OncetheVNFsmetadataarestoredintheNFStore,theavailableVNFstocomposeaservicewillbereadyforthebrokeragemodulebymeansoftheorchestrator,whichwillupdatetheavailabilityintheFunctionStore.Thisisrequiredtoavoidthatthemarketplacecouldallowthe SP to create a service starting fromVNFs that although there are available atmarketlevel,theycouldbestillnottechnicallyreadytobepartofaserviceyet.

2. T-Br-Nfs: The brokerage module will use it to retrieve information about theavailableVNFs.


©T-NOVAConsortium

73

5. CONCLUSIONS

5.1. Summary

This document provides the specification and high level design of the Network FunctionFramework and T-NOVAMarketplace for later implementation. Analysing the state of theart, including main standardization activities, previous research projects and commercialsolutions ithasbeengatheredthatatthisstageapropermarketplacetodeliverVNFsasaServicetogetherwiththeFunctionStoreasT-NOVAproposesdoesnotexist.

The T-NOVA Marketplace has been designed to be used by three kinds of stakeholdersaccording to the use cases analysis performed in T-NOVA [1], therefore a three viewsdashboardwillbe implementedaswell asandaccess controlmodule thatwillprovideAAfunctionalities to control their different permissions. The T-NOVA Marketplace will allowVirtual Network Functions (VNFs) provided by a variety of software developers (FunctionProviders)tobepublishedandtradedbymeansofabrokeragemodulethatwillimplementpricing mechanisms e.g. auctioning, when a new Network Service (NS) is going to becomposedbyaServiceProvider (SP).T-NOVACustomerswillbeabletobrowseandselectamong the available network service offerings in themarketplacebymeans of a businessservice catalogue aswell as negotiate the associated SLA and price. The billing procedurecontemplatesnotonlyfinalcustomersofT-NOVAnetworkservices,butalsothecommercialrelationshipbetweentheServiceProviderandFunctionProviders.

In relation to the specification of the Network Function Framework twomain tasks havebeen performed: the description and specification of the VNFs and the design of the NFStore.ThefirstoneincludestheAPIsallowingtheVNFtobemanagedbytheT-NOVAsystemaswellastheinformationelementsthatshallbepresentintheVNFmetadata.AkeypieceofdataoftheNetworkFunctionFrameworkisthemetadatadescriptorassociatedwiththeactual software implementation of theVNF. Besides the structural definition of a VNF, itsbehaviourhasbeenstudieddefininga lifecyclethat iscommontoall theVNFs inT-NOVA.This lifecycle can be split in an inactive and active part. In relation to the active one, thelifecycle states describe the VNF when it is up and running over a virtualised executionplatform. On the other hand, the inactive lifecycle states span from the softwaredevelopmentoftheVNFtoitsuploadingintotheNFStorethatcanbethoughtastheplacewheretheVNFsarestored.TheNFStoreAPIsprovideinterfacesbymeansofthedashboardwithFunctionProvidersforuploading,updating,andwithdrawingtheVNFsoftwareimagesandmetadatadescription,andinterfaceswiththerestoftheT-NOVAsystemformakingthisinformationavailableforserviceorchestration.

5.2. Contributionstostandards

T-NOVA Marketplace will be built considering the current NFV ETSI architecture andconsidering the on-going TMForum Best Practices for business services delivery under itsframeworx(businessprocess,information,application,andintegrationframeworks)butnotrestrictedtoit.Forinstanceithasbeendecidedtoincludeabusinesscataloguetoprovidethe marketplace offerings being aligned with TMForum proposes in its integrationframework.


©T-NOVAConsortium

74

From the state of the art analysis performed,we gathered that the T-NOVAMarketplaceconcept is completely novel with regard to ETSI view [7]. T-NOVA introduces themarketplaceaimingatopeningtheNFVmarkettothirdpartydevelopersfortheprovisionofVNFs,aconceptthatcurrentlyfallsoutsidethetechnicalviewofETSINFV.

Ontheotherhand,supportedbytheTR228TMForumGapAnalysisrelatedtoMANOWork[11]ithasbeengatheredthatETSIdoesnotprovidesofaranymoreinsightontheOSS/BSS(Operating Support System / Business Support System) of the operator apart from thedefinitionofaninterface;adetailedimplementationmodelonhowtomanageoperationalandbusiness support systems inahybrid legacyandvirtualizedenvironment is somethingthatETSIisnotaddressingsofar.

Thoughbeingoutof theT-NOVAscopethe interfacebetweentheMANOarchitectureandthe existing OSS/BSS system of operators, T-NOVA aims to provide a first step on thedirectionof this research linebymeansof the implementationof themarketplace,whichwillimplementsomeofthefunctionalitiesofaBSSsystemofanexternaloperator,andwhatcouldbeafirstinputforlateststudiesintheinteroperabilitywithOSS/BSSexistingsystems,which also TM Forum ZOOM intends to address in the future [8]. Other future work ofTMForumthatT-NOVAMarketplace isaligned to is the impactof theSLAManagement invirtualization.

InrelationtotheNFVframework,weconcludethatthelifecyclemanagementofVNFsandrelated packages adopted in T-NOVA is mostly aligned with the one adopted in ETSI.However,somedifferencesexistinpublicationandbrokerage,whichareT-NOVAspecific.Infact,T-NOVAtargetisanopenmarketenvironment,whileETSIfocusislimitedtotraditionaltelcooperations.

ConsideringtheevolutionofETSIstandardforNFVandparticularlytheNFVPhase2theT-NOVAprojectwillbeactivelyparticipating to the ISG (IndustryStudyGroup)activitiesandmeetings providing different contributions. While ETSI NFV Phase 1 had the objective toprovide informative requirements the focus of Phase 2 is on interoperability and alsonormative requirementswithdifferent levelofdetailwillbeprovided.T-NOVA isactive intheEVEWG(EvolutionandEcosystem)andinIFAWG(InterfacesandArchitectures).

However, due to the fact that neither the specifications in ETSI nor theworks in T-NOVAprojectareconsolidatedyet,somemorecollaborationwithstandardscouldbeforeseeninthefuture.

Themarketplace is a concept that doesn't require a full standardization because it is notnecessary to implement the solution using components provided by different partners. Inany case it is important that themarketplace, according to the VNFaaS and NFVIaaS usecases described in the ETSI GS NFV 001 (NFV Use cases) document, can be implementedusingastandardManagementandOrchestrationframework.Therefore,weareworking inorder to identify thegaps that canhinder the implementationof this conceptandwewillprovidecontributionstothestandardsinordertoovercometheselimitations.

5.3. FutureWork

ThespecificationprovidedinthisdocumenthasbeenbuiltbasedontherequirementsatT-NOVAsystemleveldescribedinpreviousdeliverablestogetherwithsomerelevantpartsof


©T-NOVAConsortium

75

the ETSI NFV work and TMForum best practices. The information assembled with thisprocesshasbeenthecriticalinputintoatwostageprocess:Stage1consistedonaresearchand design phase, where a system engineering approach was adopted to define the keyfunctional components [3]. Stage 2 presented in this document has defined both thereference architecture and its functional entities and interfaces in a technology-agnosticmannertodecouplethespecificsoftheimplementationsdetails.Anadditionalthirdstage,whichconstitutestheactivitieswithinWP5andW6,willaddressthedetailsofthesuitabletechnologiesandtheiroperation.

Thisreportisthesecondandfinalversionofthespecificationworkreportedin[12]thatwasdelivered in September 2014. The current version includes slight refinements consideringfeedback from one year of analysis and implementation work in the abovementionedtechnicalWPs.

Implementation work is still planned until end of December 2015 when the T-NOVAMarketplace and Function Store will be completely implemented. Year 2016 in T-NOVAprojectwillbedevotedtothesystemintegrationandtestingofallitscompoments,e.g.withthe T-NOVA orchestrator and Virtualized Infrastructure Management. We do expect thatsystemintegrationmaydetectsomegapsorneedoffinetuningtheinterfacedescriptions.Moreover, testing the system can identify some non-functional aspect that could suggestrefiningsomepartofthisspecification.Forinstance,itisdifficulttofigure-outperformanceand component interaction issues with the limited experience we have with actual NFVimplementationinfield.

BeyondT-NOVA,wehave identified some5G researchand innovationprojects towardsT-NOVAMarketplaceandNetworkFunctionframeworkcanbeaverygoodreferencetobuildon.Theseareamongothers,

- 5GEx [42], that aims to build a sandbox to extend software networks in a multi-domain/operator environment. Although 5GEx is not expected to implement a fullmarketplacelayer,itshouldspecifyanorthboundAPIforenduserstoaccessthemulti-domainservicecatalogue.T-NOVAmarketplacecanbeagoodreferencetolookat,forderivingfunctionalandnon-functionalrequirementsonBusinesstoCustomerinterface.

- SONATA [43], that focuses on the implementation of an enhanced modularorchestration platform and an SDK to facilitate service composition by servicedevelopers. T-NOVA GUI for Service Providers and its interface with T-NOVAorchestrator and T-NOVA Function Store can be seen as a relevant starting point forSONATAtobuildtheSDKforservicecomposition.


©T-NOVAConsortium

76

6. ANNEXES

6.1. AnnexA-RequirementsSpecification

Tospecifyrequirements,thefollowingtemplatehasbeenused,withthefollowingfields:

Field MeaningReq.id Requirement ID, of the form YYY_xx, in which YYY identifies

thecomponentandxxisnumberedsequentially,startingfrom01poreachdifferentcomponent.

• Dashboard–D.x• AccessControl–AA.x• SLAmanagementmodule–SLA.x• BrokerageModule–B.x• Accountingmodule–A.x• BusinessServicecataloguestore–BSC.x• Billingmodule–Bil.x• Interfacesmarketplace-orchestrator–IMO.x• NetworkFunctionStore–FS.x

UseCase Usecase(s)inDeliverableD2.1[1]fromwhichtherequirementisoriginated.

Domain Technicaldomaintowhichtherequirementbelongs,selectedoutofthelist:

• Managementandorchestration• Security• Servicecontinuity• Operations• Market/Commercialoperability

RequirementName Shortrequirementname

RequirementDescription Full requirement description. It usually corresponds to asentence including the word “shall” (for mandatoryrequirements),ou“should”(foroptionalrequirements).

JustificationofRequirement

Rationalebehindtherequirement

Every requirement has an implicit severity level, which is indicated by the verb used toexpressit,inaccordancetoIETFRFC2119[1]:

• SHALLcorrespondstoanabsoluterequirement,somethingthatmustbesupportedbytheimplementation.

• SHOULDcorrespondstoarecommended,butoptional,requirement–paraphrasingRFC2119,thismeansthat“theremayexistvalidreasonsinparticularcircumstancesto ignore a particular item, but the full implications must be understood andcarefullyweighedbeforechoosingadifferentcourse”.


©T-NOVAConsortium

77

Generally speaking, the criterion for assessing the severity level of each T-NOVArequirementwasbasicallywhetherornotthatspecificrequirementisindispensableforthesystemtodeliveritsbasicfunction.


6.1.1. Detailedmarketplacecomponentsrequirementsspecification

Dashboardrequirementsforthethreeviews:Req.id

UseCase

Domain RequirementName RequirementDescription JustificationofRequirement

D.1 UC1,UC2

Security-AA Authenticationandaccesscontrol

ThedashboardSHALLprovidea“loginin“pageforthedifferentstakeholderstobeauthenticated

StakeholdersinteractingwiththeT-NOVAsystemshouldbeauthenticatedandauthorisedinordertobeabletobrowsetheBusinessServiceCatalogue,issueSLArequests,oruploadNFVs

D.2 UC1,UC2


The“login”pageinthedashboardSHOULDoffertothedifferentstakeholdersmeanstouse(username,password,OpenID,GoogleAPI)forauthentication

StakeholdersinteractingwiththeT-NOVAsystemshouldbeabletousedifferentauthenticationtechniquestoaccessT-NOVA

D.3 UC1,UC2


The“login”pageinthedashboardSHOULDoffertothedifferentstakeholdersmeanstoremembercredentialswhenloginon

StakeholdersinteractingwiththeT-NOVAsystemshouldnotbeobligedtoinsertcredentialswhenaccessingagainthesystem

D.4 UC1,UC2

Management&Orchestration

Webaccess TheDashboardSHALLbeaccessibletoauthorizedusersviatheInternet

TheDashboardwillprovidethenecessaryinterfaceinordertobeviewedovertheInternet

D.5 UC1UC2


ParallelAccess TheDashboardSHOULDprovidemultipleusersloginandnolessthan10

TheParallelaccesswillprovidethenecessarytoolsforeveryusertobeabletoprovidehiscontent

D.6 UC1,UC2


Availability TheDashboardSHOULDbeavailable24/7365daysperyear

TheDashboardmustbealwaysoninordertocontroleverypartoftheT-NOVAinfrastructure.


©T-NOVAConsortium 79

DashboardrequirementsfortheCustomerview:Req.id

UseCase


D.7 UC2.2

Servicecontinuity+Market/commercialoperability-brokerage

Serviceofferingsselection ThedashboardSHALLbeabletoallowacustomertosearchandwatchofferings,selectingoneorseveralofthem

Service,SLAandpriceinformationneedtobevisualizedbythecustomertoallowshimtoperformaselection

D.8 UC2.2

Servicecontinuity+Market/commercialoperability–SLAmanagement

SLAselection ThedashboardSHALLbeabletoallowacustomertoselect/negotiateamongdifferentSLAlevelsforaspecificservice

Service,SLAandpriceinformationneedtobevisualizedbythecustomertoallowshimtoperformaselection

D.9 Servicelocation ThedashboardSHALLenablethecustomertoconfigurecertainparametersoftheservice,atleastthelocation

D.10 UC5.1

Servicecontinuity-SLAmanagement

SLAvisualizationbycustomer

ThedashboardSHALLbeabletoallowacustomertovisualizedSLAfulfilmentinformationwhenheasksforit

CustomerhastobeabletovisualizeSLAfulfilmentinformationwhenheasksforit

D.11 UC6 Market/commercialoperability-billing

Billsvisualizationbycustomer

ThedashboardSHALLbeabletoallowacustomertovisualizehisbillinginformationwhenheasksforit

Customerhastobeabletovisualizehisbillswhenheasksforit

D.12 UC2 ServiceContinuity-orchestrator

Serviceterminationbythecustomer

ThedashboardSHALLallowthecustomertorequestservicetermination

ThedurationoftheNSwillbespecifiedintheSLA,whentheNSisnolongerneededthesystemshouldde-composetheNSandcanceltheSLA.AlternativelytheSLAcanbeterminatedbythecustomeron-demand.

D.13 UC3 Management&Orchestration–orchestrator(serviceconfiguration)

Customerserviceportal ThedashboardSHALLallowthecustomertoprovidethemeanstoconfiguretheVNFsofaspecificNS.

AnyparametersrequiredtoconfiguretheVNF(e.g.IPprefixes,trafficclasses,etc.)mustbeaccessiblebythecustomerthroughtheserviceportal.

D.14 UC3,UC4

Management&Orchestration–orchestrator(servicemonitoring)

Customernotification-VNFstarts/failstostart

IftheVNFstartscorrectly,theT-NOVAsystemSHALLbeabletonotifythecustomeraboutthisevent.Thecustomerserviceportalshallprovidethisinformationtothecustomer.Iftheservicefailstostartcorrectly,theT-NOVASHALLbeabletonotifythecustomeraboutthisevent.

Thecustomermustgetfeedbackaboutsuccessorfailureofhis/herservicerequest

D.15 UC4 Management&Orchestration,Elasticity

Customerserviceportal-ScaleIn/Out

ThedashboardSHOULDprovideameansforacustomertorequesteithera“scaleout”or“scalein”ofadeployedVNFService.WhenthecustomerrequestsaVNF“scaleout”or“scalein”thecustomerwillhavetheoptiontoreusea



Req.id

UseCase


previousconfigurationortospecifyanewconfiguration.

D.16 UC4.2 Management&Orchestration,Elasticity

Customer/SPScaleDownVNFservice

TheDashboardSHOULDbeabletoallowthecustomertoscaledownanexistingVNFservice

ScaledownisnecessarytoensuretheT-NOVAsystemcanmeetthechangingneedsofthecustomer

D.17 UC5_1–UC7_4

Management&Orchestration-Brokerage

Servicecatalogue ThedashboardSHALLbeabletoprovideallservicesthatareactivefortheauthorisedcustomers.

Servicecatalogueisessential,becauseitprovidestotheauthorizedcustomersthepossibilitytoidentifytheservicethatneedstobeterminated

D.18 Dashboard,ServiceConfiguration

CollectNSparameters ThedashboardSHALLcollecttheservice’spre-definedparameterswhenacustomerselectsaspecificNS

See[1].NotethattheCustomercanonlychoosefromalistofauthorizedNS.

D.19 Dashboard,ServiceConfiguration

DisplayNSparameters FortheNSchosenbythecustomer,theDashboardSHALLdisplaytheparametersforaselectedNSbythecustomer,takingintoaccounttheirproperties(defaultvalues,enumeratedvalues,read-only,inter-relationship,etc.)

Displayshouldtakeintoaccountrelated/inter-dependentparameters(see[1])

D.20 Dashboard,ServiceMonitorisation

Collectanddisplaymetrics ThedashboardSHALLdisplaytheservice’spre-definedmetrics

See[3].


Manageconfigurationofserviceparameters(Customer)

ThedashboardSHALLallowthecustomertoconfiguresomeserviceparameters

Includesnotonlythegraphicalconfiguration(e.g.,pie-graphvs.bar-graph,graphtitle,etc.)


Displayconfiguredmetrics TheDashboardSHALLdisplaytheconfiguredmetrics

DashboardrequirementsfortheFunctionProviderview:



Req.id

UseCase


D.23 UC2.2 Servicecontinuity+Market/commercialoperability–FunctionStore

VNFsandSLAsdescriptionbytheFPs

ThedashboardSHALLbeabletoallowFunctionProviderstodescribetheirVNFsandmetadata(conditions,SLA,price).

VNFsandSLAsdescriptionneedtobestoredinthesystemtoallowthecustomertobrowsethroughthisinformation

D.24 UC1 Security-AA FPauthentication,certification

ThedashboardSHALLallowtheFPstobeauthorisedbythesysteminordertoadvertise,uploadandmodifyanyVNF.TheacceptanceofaFPwillbesubjectofbilateraldiscussionsbetweenthedeveloperandtheT-NOVAoperator.

ThisisessentialinordertocontroltheaccesstotheBrokerageandtheFunctionStoreandincreasesecurity.

D.25 UC1 Operational-FS VNFAdvertisement ThedashboardSHALLallowFPstobeabletoadvertisetheVNFcapabilitiesinthesystem.

TheFPforeachVNFthatisuploadedormodifiedneedstonotifytheOrchestratorinorderthattheServicecatalogueisupdated.ThisactioniscalledadvertisementoftheVNF.TheadvertisementrequestshouldcontaintheVNFmetadata,includingname,id,pricinginformation,requirementsandVNFcapabilities.

D.26 UC1 Operational-FS VNFwithdrawal ThedashboardSHALLallowFPstobeabletoremovedoneoftisVNFsfromthesystem.

TheFPforeachVNFthatiswithdrawnneedstonotifytheOrchestratorinorderthattheServicecatalogueisupdated.

D.27 UC1 Operational-FS VNFUpload ThedashboardSHALLallowFPstobeabletouploadthepackagedVNFtotheFunctionsStore.

ThesystemshouldofferamethodtotheFPforuploadingandstoringthepackagedVNFtotheFunctionStore.BothVNFimageanditsmetadataareuploaded.WhenaparticularVNFisrequestedtheOrchestratorwillinstantiatethisVNFtotheappropriateNFVI-PoP.



Req.id

UseCase


D.28 UC1 Security/Operational-FS VNFvalidation VNFvalidationSHOULDbechecked. TheVNFshallbevalidatedbeforebeingincludedintotheFunctionStore.Validationisanoff-lineprocess.Itisout-ofscopeofT-NOVA.

D.29 UC1 Operational-FS FPVNFstatusmonitoring AlltheVNFsofthesamedeveloperSHALLbebrowsableinthedeveloperdashboard,fromwherethedeveloperisabletomonitorthestatusandotherstatisticaldata(popularity,rating,commentsetc.).

ThisrequirementcoverstheneedforsupportingthemonitoringofeachVNFbytheFPintermsofavailability,popularity,malfunctionsandalerting.

DashboardrequirementsfortheServiceProviderview:Req.id

UseCase


D.30 UC2.2 Servicecontinuity+Market/commercialoperability–servicecatalogue

ServicesandSLAsdescriptionbytheSP

ThedashboardSHALLbeabletoallowServiceProviderstodescribetheirservicesandconditionsdescription(service(+servicedescription),SLA,price)

ServicesandSLAsdescriptionneedtobestoredinthesystemtolaterallowthecustomertobrowsethroughthisinformation

D.31 UC3.1 Servicecontinuity-SLAmanagement

SLAvisualizationbytheSP ThedashboardSHALLbeabletoallowacustomertovisualizeSLAfulfilmentinformationondemand

CustomerhastobeabletovisualizedSLAfulfilmentinformationwhenheasksforit



Req.id

UseCase


D.32 UC6,UC2

Market/commercialoperability-billing

Billcycleagreement ThedashboardSHALLallowtheSPtobeassignedabill/billingmodecyclewiththeFPs

Billingprocedureneedstoknowwhenabillcyclefinishes(fornonpay-as-you-goservices).

D.33 UC6 Market/commercialoperability-billing

BillsvisualizationbySP ThedashboardSHALLbeabletoallowaSPtovisualizehisbillinginformationondemand

Customerhastobeabletovisualizedhisbillswhenheasksforit

D.34 UC2,UC3,UC4

Operational,ServiceContinuity,Management&Orchestration-orchestrator

NSCompositionbytheSP ThedashboardSHALLallowtheSPtocomposeaNSfromatomicVNFinstancesavailableattheNFStoreanddefinethelogicaltopologyamongtheseveralcomponents(see[2])

ThecreationofaNSfromthecombinationofatomic/simpleVNFisimportantinordertosimplifytheprocessprovisionofNStothecustomersandavoidcomplexpathcalculations

D.35 UC3,UC4,UC5

Management&Orchestration-Orchestrator

Resourcemonitoring ThedashboardSHALLallowtheSPtomonitorandcollectinformationaboutconsumptionandavailabilityofresources(computational,storage,network)onarealtimebasis,includingtheresourcesconsumedbyeachspecificVNFinstance.

MonitoringisessentialtoensurethatthedeploymentofVNF’sontohostinginfrastructureisperformedadequately.Monitoringisalsorprovidesessentialmetricsrequiredbyoperationssuchasrescaling,billing,etc.

D.36 UC4 Management&Orchestration,Elasticity-orchestrator

SPserviceportal-ScaleUp/Down

ThedashboardSHALLprovidethemeansforaSPtorequesteithertoupordownscaletheresourcesallocatedtoadeployedVNFServicebasedontheSLAevaluation.

TheT-NOVAsystemmustprovidetheabilityforcustomerstorequestadditionalresourcesortheremovalofresourcesfromadeployedVNFservice.

D.37 UC4 Management&Orchestration,Elasticity-orchestrator

SPnotification-VNFisremoved

AnotificationSHALLbeshowntotheSPiftheVNFanditshostVMsaresuccessfullyremovedfromtheT-NOVAsystem.

Thecustomermustgetfeedbackaboutthesuccessorfailureoftheirservicerequest

D.38 UC4 Management&Orchestration;Elasticity-orchestrator

SPnotification-VNFrescale

ThedashboardSHALLnotifytheSPwhentheirrequesttorescaleaVNFhasbeensuccessfullycompleted.

Thecustomermustgetfeedbackaboutthesuccessorfailureoftheirservicerequest

D.39 UC4.2 Management&Orchestration,Elasticity-orchestrator

SPScaleOutVNF ThedashboardSHALLallowtheSPtochoosetoscalein/outanexistingVNF.

CustomerswillrequestincreasesinVNFservicestomeetbusinessneeds

D.40 Dashboard,ServiceComposition

BrowseavailableVNFs TheDashboardSHALLallowtheServiceProvidertobrowsetheavailable(andauthorized)VNFs

ThelistofavailableVNFsisacombinationofthelistprovidedbytheOrchestratorandthelistofauthorizedservicesfortheServiceProvider(inamulti-ServiceProvider



Req.id

UseCase


scenario).


SelectandconfigureoneormoreVNFs

ThedashboardSHALLallowtheSPtocomposeaNetworkServicefromasetofavailableVNFs[2].

NotethatmorethanoneinstanceofthesameVNFcanbeusedinthecompositionofaNS.ThisconfigurationincludesthedefinitionoftheselectedVNFs’connectiongraph.Thisconnectiongraphis,inthesimplestcase,theconnectionoftheoutputofaVNFinstancetotheinputofanotherVNFinstance.Inmorecomplexcasestheremightbesomeformofprocessingtheoutput(e.g.,max/min/average,step,etc.)beforedeliveringtotheinput.


Definecomposedserviceparameters

Foragivencomposedservice,theDahsboardSHALLallowtheSPtodefineitsparametersandmapthosetotheparametersoftheVNFsusedinthecomposition.

Includesthedefinitionofrelated/inter-dependentparameters(fordisplayingpurposes,see[2])andmappingVNF’sparameterstothecomposedserviceparameters,aswellastheindicationofdefaultvalues,mandatoryorread-onlyproperties,etc.


Definecomposedserviceindicators

Foragivencomposedservice,thedashboardSHALLallowtheSPtodefineitsmetrics,mappingfromthoseavailablefromeachoftheVNFusedinthecomposition

Includesthedefinitionofrelated/inter-dependentindicators(fordisplayingpurposes,see[2])andmappingVNF’smetricstothecomposedservicemetrics.


Managelife-cycleofcomposedservices

TheDashboardSHALLallowtheSPtomanagethelife-cycleofthecomposedservices.

Notethatifacomposedserviceisbeingused,itcannotberemovedentirelybitcanbedroppedfromthelistofavailableservicesintheMarketplace


SP-FPtrading TheDashboardSHOULDallowtheSPtointeractwiththeFPsinordertotradevariousVNFs

Auction/TradeinsidetheServiceComposition



Req.id

UseCase



Collectanddisplaymetrics TheDashboardSHALLdisplaytheservice’spre-definedmetrics

See[3].


Manageconfigurationofmetrics(SP)

TheDashboardSHALLallowtheconfigurationofserviceparametersbytheSP.

Includesnotonlythevisibilityofthemetricandanyothergraphicalconfiguration(e.g.,pie-graphvs.bar-graph,graphtitle,etc.)butalsoeventuallysomeformofcombiningtwoormoremetrics.AsubsetofthesemetricswilllikelyberelatedtotheagreedSLA.


Displayconfiguredmetrics TheDashboardSHALLdisplaytheconfiguredmetrics

AccessControlReq.id

UseCase


AA.1

UC2 Security Authenticationandaccesscontrol

AAmoduleSHALLsupportmechanismsforauthenticationandauthorisationforthedifferentstakeholders.Theauthorizationisbasedontheassociatedrolesandpermissions

StakeholdersinteractingwiththeT-NOVAsystemshouldbeauthenticatedandauthorisedinordertoperformtaskssuchasuploadingaNForpurchaseaVNF

AA.2

UC2 Security Securecommunication AAframeworkSHOULDprovideencryption. Encryptionshouldbeused,inordertopreventeavesdropping.

AA.3

UC1 Security FPauthentication,authorization

AASHALLauthenticateandauthorisetheFPsinordertoadvertise,uploadandmodifyVNFs

EachFPthatinteractswiththeBrokerageandtheFunctionStoreneedstobeauthenticatedandauthorisedbythesystem.ThisisessentialinordertocontroltheaccesstotheBrokerandtheFunctionStoreandincreasesecurity.



AA.4

Security StakeholdersAuthorization

Profiles are created according to T-NOVA roles andstakeholders are assigned roles based on theirresponsibilitiesandqualifications

Basedonthedifferentstakeholdersresponsibilitiesandqualificationsandthetasksthattheywillundertake,roleswillbecreated

AA.5

Security StakeholdersAuthorization

Roles can be reassigned or granted new permissions ifneeded. Which means they SHALL be updatable andrevocable

Asresponsibilitiesmightchangeorextended/reducedovertime,rolesSHALLbeflexibleenoughtobereassigned,extendedwithnewfeatures,orrevoked

Brokerage:

Req.

id

Use

Case


B.1 UC2.1 Operational Trading/Bidding TheBrokerageSHALLbeabletoperformauctionsamongServiceproviderandFunctionproviders

TheBrokeragemustbeabletoinitiateauctionswheneveritisrequired.

B.2 UC2.1 Operational Trading/Bidding TheBrokerageSHOULDtakeintoaccounttheSLAparameters

TheBrokeragemustbeabletoinitiateauctionsbyusingtheSLAparametersasaprerequisite

B.3 UC2.1 Operational Trading/Bidding TheBrokerageSHOULDreturnthebestpossibleFunctiontotheSP

ThebrokeragemustbeabletoauctionandreturnthebestpossibleresultstotheSP

B.4 UC2.1 Operational Trading/Bidding TheBrokerageSHOULDbeabletoaccommodatemultipleFPtoaSP

ThebrokeragemustbeabletoauctionamongtheavailableFPs

B.5 UC2.1 Operational Trading/Bidding TheBrokerageSHOULDbeabletotakeintoconsiderationpredefinedAtomicTradingUnits

ThebrokeragemustbeabletoauctionamongtheavailableFunctionswithpredefinedParameters

BusinessServiceCatalogue



Req.id

UseCase


SC.1 UC2.2 Servicecontinuity+Market/commercialoperability

ServicesandSLAsdescription

TheservicecatalogueSHALLbeabletostorealltheavailableNSsintheT-NOVAmarketplace,specifyingSLAlevelandprice.

ServicesandSLAsdescriptionneedtobestoredinthesystemtoallowthecustomertobrowsethroughthisinformation



TheservicecatalogueSHALLbebrowsablebytheSP Theservicecataloguemustsupportadvancesearchingcapabilities,tosupportsearchwithdifferentcriteria,suchasprice,SLA,etc.



TheservicecatalogueSHALLsupportoperationsofcreating/updating/deletingNSs.

Theservicecatalogueneedstosupportupdatinganddeletingoperations,regardingtheNSs.

SLAmanagementmoduleReq.id

Use

Case


SLA.1 UC2.2 Servicecontinuity SLAinformationcustomer-SPstorage

TheSLAmanagementmoduleSHALLstorealltheSLAagreementsbetweenacustomerandtheSPforeachservice.

SLAagreementsmustbestoredinorderforservicemonitoringtodetermineiftheSLAhasbeenfulfilledornot

SLA.2 UC2.2 Servicecontinuity SLAinformationSP-FPsstorage

TheSLAmanagementmoduleSHALLstorealltheSLAagreementsbetweentheSPandtheFPsforeachVNF.

SLAagreementsmustbestoredinorderforaVNFmonitoringtodetermineiftheSLAhasbeenfulfilledornot

SLA.3 UC4,UC5,UC5.1

Management&Orchestration,Operations,ServiceContinuity

SLA–orchestratorinterface

TheSLAmanagementmoduleSHALLbeconnectedtotheorchestratortoletitknowabouttheagreedSLAforeachservice.(WhentheSLAisnotfulfilledtheorchestratorwillhavetoinitiatetheapplicableaction,e.g.rescaling)

SLAmanagementandmonitoringisconsideredessentialforthecommercialapplicabilityoftheT-NOVAsystem.TheT-NOVAsystemmustdeterminewhenanSLAisinbreachandtriggercorrectiveactions.



SLA.4 UC5.1,UC6

Market/commercialoperability

SLAfulfilmentinformationstorage(fromtheorchestrator)

TheSLAmanagementmoduleSHALLstorealltheinformationaboutSLAfulfilmentforeventualcompensationsorpenaltiesforlaterbilling.

InordertocompensatethecustomereconomicallyfornotachievingtheSLAagreed,thebillingsystemmusthavethisinformation

SLA.5 UC5.1,UC6


SLA–accounting/billinginterface

TheSLAmanagementmoduleSHALLbeconnectedtheaccounting/billingsystemtoletitknowabouteventualcompensationsorpenaltieswhentheSLAhasnotbeenfulfilledforaspecificservice.


SLA.6 UC5.1 Servicecontinuity SLAvisualisationbycustomerandSP

TheSLAmanagementmoduleSHALLbeconnectedtotheDashboardtoallowacustomerandSPtovisualizeSLAfulfilmentinformationwhenrequested.

CustomersandSPshastobeabletovisualizeSLAfulfilmentinformationsincethisistherealserviceleveltheyaregettingandpayingfor.

SLA.7 UC2.2 ServiceContinuity SLAproceduremechanisms

TheSLAmanagementmoduleSHALLprovidemechanismstogetanagreementpresentedandagreedbetweentheparties

TheinvolvedpartiesneedtobeinformedabouttheSLAofferfromtheotherpartyandbeabletoagreeordisagree

AccountingmoduleReq.id

UseCase


Ac.1 UC3 Management&Orchestration

Accountingnotification-VNFstarts

TheaccountingsystemSHALLknowifaVNFornetworkservicestartscorrectly.

Forbillingpurposes,theaccountingsystemhastobenotifiedaboutthestartoftheVNFserviceinstance

Ac.2 UC5 Market/commercialoperability

Resourcesusageforbilling TheaccountingsystemSHALLstorealltheinformationaboutresourcesusagebyeachserviceforlaterbillingpurposes.

Billingprocedureneedstoknowtheservicesthathavetakenplaceandwhentheystartandend.

Ac.3 UC6 Market/commercialoperability

Priceinformationforbilling

TheaccountingsystemSHALLstoretheinformationaboutpricesagreedbyeachcustomerforlaterbillingpurposes.

Billingprocedureneedstoknowthepricetobeappliedforservice

Ac.4 UC5.1,UC6


SLAbillableitems TheaccountingsystemSHALLbeawareoftheinformationaboutSLAfulfilmentforbillingcompensationsorpenalties.


Ac.5 UC6,UC2


Billcycle TheaccountingmoduleSHALLbeabletoprovidethebillingrelatedinformationforanygivenperiodforeachcustomer,andSP.

Billingprocedureneedstogeneratethebillsforcustomisedperiodsoftime.



Componentsrelationships TheaccountingsystemSHALLstorethenecessaryinformationoftheserviceandfunctioninstances,,agreements,providersandcustomers.

Alltheelementsinvolvedintheissueofabillmustbelinkedandrelated.

BillingmoduleReq.id

UseCase


Bil.1 UC6 Market/commercialoperability

Priceinformationforcustomerbilling

ThebillingmoduleSHALLreceivetheinformationaboutpricesagreedbyeachcustomerforeachservice.



PriceinformationforSPbilling

ThebillingmoduleSHALLreceivetheinformationaboutpricesagreedbyeachSPforeachVNF.



Billissuing ThebillingmoduleSHALLissuebillswhenthecustomer'sbillcyclefinishesorservicepay-as-you-gofinishesandstoresthemwithinthecustomerprofile.

Billingprocedureneedstoknowwhenapay-as-you-goservicestartsandfinishes.

Bil.4 UC6 Billing-accountinginterface

ThebillingSHOULDreceivealltheinformationneededforbillingfromtheaccountingmodule.

Bil.5 UC6 Billing-Usermanagementinterface

ThebillingmoduleSHALLgetthespecificuserrelatedinformationalongwiththeinformationreceivedfromtheaccountingsystemforbillingpurposes.

Bil.6 UC6 Billing-Dashboardinterface

ThebillingmoduleSHOULDprovideinformation(statisticsandgraphs)tothedashboard.

It’sdesirablebythecustomertohavestatisticsthatrepresentwhattheyarepayingforinaneasy-to-understandway.

Marketplace–orchestratorinterfaceReq.

id




IMO.1

Orchestrator,Marketplace Provisionanewnetworkservice

TheMarketplaceSHALLusethisinterfacetoinformtheOrchestratortoprovisionthenetworkservice,aftertheCustomerhasselectedandconfiguredthenetworkservice.TheOrchestratorSHALLreadtheSLAandthedate/timetostartthenewnetworkservice.EachNScanbecomposedofoneormoreVNFs.

Thedate/timeofstart/endtheservicearepartoftheSLA.

IMO.2

Orchestrator,Marketplace Changeconfigurationofadeployednetworkservice

TheMarketplaceSHALLusethisinterfacetochangetheconfigurationofanalreadyprovisionednetworkserviceontheOrchestrator.

IMO.3

Orchestrator,Marketplace Providenetworkservicestatetransitions

TheMarketplaceSHALLusethisinterfacetoknowaboutthestatetransitionsofagivennetworkservice,e.g.toallowstartandstopbillingfortheservice.

ItisassumedthateachNShasapre-definedstate-diagram,like‘Readytorun’,‘Running’,‘Stopped’,etc.,thatisalsoknowntotheMarketplace.

IMO.4

Orchestrator,Marketplace Providenetworkservicemonitoringdata

TheMarketplaceSHALLusethisinterfacetoshowtheCustomerhowthesubscribednetworkserviceisbehaving,howitcomparestotheagreedSLAandbilltheserviceusage.

Thisinterfacewillverylikelyhavetosupportveryhighvolumetraffic.

IMO.5

Orchestrator,Marketplace TerminateaprovisionedNS

TheMarketplaceSHALLusethisinterfacetorequesttheOrchestratortoterminateprovisionedNSs

Itisassumedthattheimpactonthedependentmoduleslikebilling,aretakencarebytheMarketplace(seeNFVO.04).SLAManagementispartoftheMarketplace.Eitherafteracustomer’srequestorbythepre-definedendingdatehadbeenattained,theSLAManagementnotifiestheOrchestratoroftheendoftheSLA.

IMO.6

Orchestrator,Marketplace Securecommunication InterfacesbetweentheMarketplaceandtheOrchestratorshouldbesecured.

Encryptionshouldbeused,inordertoensuresecurityagainsteavesdropping.EvenbetweentheMarketplaceandtheOrchestrator,sincetheMarketplaceisreallyasetofdistributedapps.

Marketplace–FunctionStore



IFM.1

FunctionStoreMarketplace ProvideavailableVNFs TheMarketplaceSHALLusethisinterfacewiththeOrchestratortoprovidetheServiceProviderwithalistoftheVNFs,sothatitcanselectandparameterisethem,orusetheminthecompositionofanewnetworkservice.

ItisassumedthatthisVNFmetadataincludesaURL/repositorynamefromwhichtofetchtheactualVNFsoftwareandinstallitonthepreviouslyallocatedinfrastructure(seeNFVO.10below).Notethat,althoughthisinformationwillmostcertainlyhavetobecachedontheOrchestrator’ssideforperformancereasons,theavailableVNFswillbedynamic,soupdatestothiscachedinformationwillberatherfrequent.

IFM.2

FunctionStoreMarketplace ProvideavailableVNFs TheMarketplaceSHALLusethisinterfacetoallowtheFPstouploadVNFstotheFunctionStore

6.1.2. DetailedNetworkFunctionStorerequirementsspecification

Req.id UseCase


FS.1 UC1 Operational VNFUpload(orPublish) TheFunctionStoreSHALLbeabletostoreallthepackagedVNFsandtheirassociatedmetadata.

ThesystemshallofferamethodtotheFPforuploadingandstoringthepackagedVNFtotheFunctionStore.WhenaparticularVNFisrequestedtheOrchestratorwillinstantiatethisVNFtotheappropriateNFVI-PoP.

FS.2 UC1 Security/Operational

VNFvalidation VNFvalidationSHOULDbechecked. ThesubmittedVNFisvalidatedbytheT-NOVAFunctionStoreinordertoincreasesecurityandintegrityoftheVNFpackage.ThisisoutofthescopeofT-NOVA

FS.3 UC1 Security/Operational

VNFIdentification TheFunctionStoreSHALLprovideauniqueidentificationIDtoeachcertified,advertisedVNF.

TheVNFIDwillbethereferencenameusedbythesystemformonitoringpurposes.

FS.4 UC1 Operational VNFModification/Withdrawal

TheFunctionStoreSHALLallowmodification/withdrawalofthepackagedVNFsandtheirassociatedmetadata.

The system will offer a method to the FP formodificationand/orwithdrawalofthepackagedVNFintheFunctionStore.

FS.5 Operational VNFDownload TheFunctionStoreSHALLallowdownloadingofthepackagedVNFsandtheirassociatedmetadata.

Thesystemwillofferamethodfordownloadinginformation associated to VNFs from therepository.



FS.6 Operational VNFDirectory TheFunctionStoreSHALLallowlistingofpackagedVNFsandtheirassociatedmetadata.

The system will offer a method to list thecontentofthedatastoredintherepository.

FS.7 Operational VNFNotification TheFunctionStoreSHALLbeabletonotifychangesinitsstatus.

The systemwill provide amechanism to notifyan update or change in the content of therepository. This is basically used to make theOrchestrator databases in sync with theFunctionStore.

FS.8 Security/Operational

VNFAuthentication The Function Store SHALL allow access only toauthenticatedusers.

The system (AA module) will grant operationand control of the Function Store uponauthenticationofFPs.

FS.9 Operational/Management

VNFUserPrivilege The Function Store SHALL provide different levels ofprivilegestousers(e.g.userandrootlevels).

FP will have user access to the repository. Inaddition,theFunctionStorewillofferapowerfulmanagementinterfacetoadministrators.

FS.10 Operational/Performance

VNFUserConcurrency TheFunctionStoreSHOULDprovidemulti-usercapability. Concurrent requestsshouldbemanagedby theFunctionStorerepository.

FS.11 Operational/Security VNFDataProtection The Function Store SHOULD guarantee securitymechanismsfortransmissionofdata.

The data should be protected (e.g. encrypted)when transferred to/from the Function Storerepository.

FS.12 Operational/Security VNFDataOblivion TheFunctionStoreSHOULDguaranteethatcancelleddatawillbecompletelydisregarded.

The FP should be able to delete his/her datafromtherepositoryinadefinitemanner.

FS.13 Operational/Performance

VNFServiceContinuity The Function Store SHOULD be available withoutinterruptionregardlessoftimeorday(24/7/365).

TheFunctionStoreserviceshouldbeofferedasanonstopservice.



6.2. AnnexB.DashboardMock-up

Figure6-1DashboardLoginScreen



Figure6-2NewUserProfile



Figure6-3ServiceProviderProfileScreen



Figure6-4ServiceProviderNewService1/2



Figure6-5ServiceProviderNewService2/2



Figure6-6CustomerScreen



Figure6-7CustumerNewService



Figure6-8CustomerExistingServices

Figure6-9ServiceProvider-RunningServices1/2



Figure6-10ServiceProvider-RunningServices1/2


7. REFERENCES

[1] DeliverableD2.1–SystemUseCasesandRequirements.T-NOVAproject.

[2] DeliverableD2.31 -Specificationof the InfrastructureVirtualisation,ManagementandOrchestration-T-NOVAproject.

[3] DeliverableD2.22-OverallSystemArchitectureandInterfaces-Final-T-NOVAproject.

[4] Deliverable D6.01 - Interim Report on T-NOVAMarketplace implementation, T-NOVAproject(Dec'2014).

[5] DeliverableD6.3-Usersdashboard.T-NOVAproject.

[6] ETSI GS NFV-SWA 001” Network Functions Virtualisation (NFV)- Virtual NetworkFunctionsArchitecture.

[7] ETSINFVISG,“NFV-MAN001NFVManagementandOrchestration,”July2014.[Online].Available: http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-MAN001v061%20management%20and%20orchestration.pdf.

[8] TMForum,“TMForumWebSite,”http://www.tmforum.org.

[9] TMF ZOOM, «TMF ZOOM,» [En línea]. Available:http://www.tmforum.org/ZOOM/16042/home.html.[Últimoacceso:2014].

[10]TMF“TR227TMForumSpecificationsrelevantforMANOWorkV1.0.1”,2014.

[11]TMF,TR228TMForumGapAnalysisrelatedtoMANOWorkV1.0.1,2014.

[12]DeliverableD2.41-InterimReportonSpecificationofNetworkFunctionFrameworkandT-NOVAMarketplace.T-NOVAproject(Sep'2014).

[13]TMForum:Virtualization:WhenwillNFVcrossthechasm?February2015.

[14]TMForumCatalyst-https://www.tmforum.org/collaboration/catalyst-program/current-catalysts/.

[15]TMF Catalyst Project: Service Bundling in a B2B2XMarketplace. Available: [Accessed2014]http://www.tmforumlive.org/service-bundling-in-a-b2b2x/.

[16]TMForumCatalystproject:HowtomaximizeprofitabilitywithNFVorchestration-June2015.

[17]TMForum NFV Management Ecosystem - http://tmflive2014bak.wpengine.com/nfv-management-ecosystem/.

[18]TMForum G1123 NFV Readiness: Packaging Virtualized Network Services forProcurermentandOperationsR14.5.1-September2014.

[19]TM Forum Information Framework Enhancements to Support ZOOM R15.0.0 - May2015.

[20]DeliverableD6.1ServiceDescriptionFramework-T-NOVAproject.


©T-NOVAConsortium104

[21]TMForumIG1120VirtualizationImpactonSLAManagement-April2015.

[22]TMForum IG1127 End-to-end Virtualization Management: Impact on E2E ServiceAssuranceandSLAManagementforHybridNetworksR15.0.0-May2015.

[23]DeliverableD6.4-SLAsandBilling-T-NOVAproject.

[24]Project XIFI (FI-PPP), “Official Web Site,” [Online]. Available: [Accessed2014].https://www.fi-xifi.eu/home.html.

[25]MCNprojectMobileCloudNetworking-http://www.mobile-cloud-networking.eu/site/.

[26]Unifyproject-Unifyingcloudandcarriernetworks-https://www.fp7-unify.eu/.

[27]NETIDEproject-Anintegrateddevelopmentenvironment-www.netide.eu.

[28]CENX Ethernet Lifecycle Manager (ELM) Available: [Accessed 2014]http://www.cenx.com/.

[29]EquinixPlatform–Marketplace.Available:[Accessed2014]http://www.equinix.com/.

[30]HP OpenNFV Partner Ecosystem - http://www8.hp.com/us/en/cloud/nfv-partners-labs.html.

[31]SDN App Store - http://blogs.hp.com/marketwatch/2014/09/27/hp-launches-industry%e2%80%99s-first-sdn-app-store-unleashing-new-wave-of-networking-innovations/.

[32]Cloud28+-http://www.cloud28plus.eu/.

[33]DeliverableD8.1-MarketAssesment.T-NOVAproject.

[34]V.Krishna,AuctionTheory,2010.

[35]Cyclops-https://icclab.github.io/cyclops/.

[36]Amazon AWS CloudFormation. Available online. [Accessed 2014].http://aws.amazon.com/es/cloudformation/.

[37]OpenStackHot. Available [Accessed 2014]http://docs.openstack.org/developer/heat/template_guide/hot_spec.html..

[38]ETSI GS NFV 003 "Network Functions Virtualisation (NFV); Terminology for MainConceptsinNFV".

[39]DeliverableD2.32 -Specificationof the InfrastructureVirtualisation,ManagementandOrchestration-FInal-T-NOVAproject.

[40]DeliverableD5.1-FunctionStore-T-NOVAproject.

[41]DeliverableD3.1-OrchestratorInterfaces-T-NOVAproject.

[42]5GExproject-5GExchange-https://5g-ppp.eu/5gex/.

[43]SONATA project - Service Programing and Orchestration for Virtualized SoftwareNetworks-https://5g-ppp.eu/sonata/.



8. LISTOFACRONYMS

Acronym Explanation

AA AuthenticationandAuthorisation

AAA Authentication,Authorisation,andAccounting

API ApplicationProgrammingInterface

BSS BusinessSupportSystem

CRUD CreateReadUpdateandDelete

CPU CentralProcessingUnit

DoW DescriptionofWork

eTOM TelecomOperationsMap

GUI GraphicalUserInterface

EMS ElementManagementSystem

ETSI EuropeanTelecommunicationStandardInstitute

EU EndUser

FI FutureInternet

FP FunctionProvider

ISG IndustrySpecificationGroup

ISP InternetServiceProvider

IT InformationTechnology

KPI KeyPerformanceIndicator

MANO ManagementandOrchestration

NFaaS NetworkFunctions-as-a-Service

NF NetworkFunction

NFC NetworkFunctionComponent

NFV NetworkFunctionsVirtualisation

NFVI NetworkFunctionVirtualizationInfrastructure

NFVO NetworkFunctionVirtualizationOrchestrator

NS NetworkService

OSS OperationalSupportSystem

QoS QualityofService

RBCA RoleBasedAccessControl

RTT Roundtriptime

SaaS Software-as-a-Service



SBC SessionBorderController

SDK SoftwareDevelopmentKit

SDN Software-DefinedNetworking

SDO StandardsDevelopmentOrganisation

SI ServiceIntegrator

SID SharedInformation/Datamodel

SIP SessionInitiationProtocol

SLA ServiceLevelAgreement

SP ServiceProvider

TAM TelecomApplicationMap

TIP TMForumIntegrationProgram

UC UseCase

VIM VirtualInfrastructureManager

VM VirtualMachine

VNF VirtualNetworkFunction

VNFaaS VirtualNetworkFunctionasaService

VNFD VirtualNetworkFunctionDescriptor

VNFM VirtualNetworkFunctionManager

VNI VirtualNetworkInterface

VNPaaS VirtualNetworkPlatformasaService

WP WorkPackage

D2.42 Specification of the Network Function …...agnostic manner for later implementation of the...

Documents

Transcript of D2.42 Specification of the Network Function …...agnostic manner for later implementation of the...