Embed Size (px)
Citation preview
ETSI SR 003 382 V2.0.0 (2015-11)
Cloud Computing Standards and Open Source
Optimizing the relationship between standards and Open Source in Cloud Computing
Analysis, conclusions and recommendations from Cloud Standards Coordination Phase 2
CAUTION: This document is provided for information and is for approval within the ETSI Technical Committee NTECH only.
ETSI and its Members accept no liability for any further use/implementation of this Special Report.
Approved and published specifications and reports shall be obtained exclusively via the ETSI Documentation Service at
http://pda.etsi.org/pda/queryform.asp
<
SPECIAL REPORT
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 2
ReferenceDSR/NTECH-00031
KeywordsCloud, Cloud Computing, Open Source Software,
Open Source Communities, Standards, Standards Setting Organizations
ETSI
650 Route des Lucioles F-06921 Sophia Antipolis Cedex – FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 – NAF 742 C
Association à but non lucratif enregistrée à la Sous-préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from: http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2015.
All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 3
Contents
IntellectualPropertyRights.........................................................................................................5
Foreword....................................................................................................................................5
Introduction................................................................................................................................5
1 Scope....................................................................................................................................6
2 References............................................................................................................................62.1 Normativereferences..............................................................................................................................62.2 Informativereferences............................................................................................................................6
3 Definitions,symbolsandabbreviations.................................................................................73.1 Definitions...............................................................................................................................................73.2 Abbreviations...........................................................................................................................................7
4 StandardsandOpenSource...................................................................................................94.1 Context....................................................................................................................................................94.2 Objectives................................................................................................................................................94.3 Approach...............................................................................................................................................104.4 Contentofthereport............................................................................................................................10
5 StandardsandOpenSource:definitions,objectivesandinteractionchallenges...................115.1 Definitionsandobjectives.....................................................................................................................115.1.1 Standards........................................................................................................................................115.1.2 OpenSource....................................................................................................................................12
5.2 Differentobjectives,differentapproaches............................................................................................125.3 Mainchallengestoanefficientinteraction...........................................................................................135.3.1 Technicalchallenges........................................................................................................................135.3.2 Organizationalchallenges...............................................................................................................145.3.3 Intellectualpropertychallenges......................................................................................................15
6 StandardsandOpenSource:Interactionscenarios..............................................................166.1 Anoverallview......................................................................................................................................166.2 Thescenarios.........................................................................................................................................166.2.1 AnOpenSourcecommunityimplementsstandards.......................................................................166.2.2 AnSSOdevelopsanOpenSourcereferenceimplementation.........................................................176.2.3 AnSSOdevelopsstandardsbasedontheresultsofanOpenSourcecommunity...........................176.2.4 Acollaboration(“jointproject”)isestablishedbetweenaStandardOrganizationandanOpenSourcecommunity.......................................................................................................................................18
6.3 Currentandfuturesituation..................................................................................................................18
7 BetteraligningthestandardsandOSScommunities............................................................187.1 Alignment:ifandwhenneeded............................................................................................................187.2 Strategies...............................................................................................................................................197.3 Solutions................................................................................................................................................19
8 ConclusionsandRecommendations.....................................................................................19
9 Areasforfurtherstudy........................................................................................................20
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 4
AnnexA: StandardsRelatedOrganizationsApproaches.........................................................22
AnnexB: OpenSourceCommunitiesApproaches..................................................................25B.1 OpenSourceCloudmiddlewareprojects..............................................................................................25B.2 Standardsusagesummarytable...........................................................................................................27
AnnexC: InteractionscenariosinpracticeinCloudComputing..............................................28C.1 Sharingspecifications:NFVandOPNFV................................................................................................28C.1.1 Theactors........................................................................................................................................28C.1.2 Workingtogether:opportunities,issues.........................................................................................29
C.2 OpenSourceandStandards:OpenStack..............................................................................................29C.2.1 Theactors........................................................................................................................................30C.2.2 Supportofstandards.......................................................................................................................31
C.3 DistributedManagementTaskForce(DMTF).......................................................................................31C.3.1 DMTFStandards..............................................................................................................................31C.3.2 DMTFstandardsandOpenStack.....................................................................................................31
AnnexD: ChangeHistory.......................................................................................................32History.............................................................................................................................................................32
Tables TABLE1:OPENSTACKSERVICESINSUPPORTOFOPENSTACKARCHITECTURE.................................................ERREUR!SIGNETNONDÉFINI.TABLE2:STRATEGIESOFSSOSTOWARDSOPENSOURCECOMMUNITIES....................................................ERREUR!SIGNETNONDÉFINI.TABLE3:STRATEGIESOFOPENSOURCEORGANIZATIONSTOWARDSSSOS........................................................................................25TABLE4:OPENSOURCEPRODUCTSADHERENCETOSTANDARDS......................................................................................................27TABLE5:AWS-RELATEDSPECIFICATIONS..............................................................................................ERREUR!SIGNETNONDÉFINI.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 5
Intellectual Property Rights IPRsessentialorpotentiallyessentialtothepresentdocumentmayhavebeendeclaredtoETSI.TheinformationpertainingtotheseessentialIPRs,ifany,ispubliclyavailableforETSImembersandnon-members,andcanbefoundinETSISR000314:"IntellectualPropertyRights(IPRs);Essential,orpotentiallyEssential,IPRsnotifiedtoETSIinrespectofETSIstandards",whichisavailablefromtheETSISecretariat.LatestupdatesareavailableontheETSIWebserver(http://ipr.etsi.org).PursuanttotheETSIIPRPolicy,noinvestigation,includingIPRsearches,hasbeencarriedoutbyETSI.NoguaranteecanbegivenastotheexistenceofotherIPRsnotreferencedinETSISR000314(ortheupdatesontheETSIWebserver)whichare,ormaybe,ormaybecome,essentialtothepresentdocument.
Foreword ThisSpecialReport(SR)hasbeenproducedbyETSISpecialistTaskForce486"CloudStandardsCoordinationPhase2"astheresultofWorkItemNTECH(15)000007"STF486WIonCloudComputingstandardsandOpenSource".ThepresentreportisoneoffourspecialreportsthatformtheoutputofSTF486:
WP1: ETSISR003381:"CloudComputingUsersNeeds";WP2: ETSISR003382:"CloudComputingStandardsandOpenSource";WP3: ETSISR003391:"InteroperabilityandSecurityinCloudComputing";WP4 ETSISR003392:"CloudComputingStandardsMaturityAssessment".
InthispresentRelease,itisproposedtotheNTECHTechnicalCommitteeforapprovalandtopublicationontheCloudStandardsCoordinationwebsite(http://csc.etsi.org).
Introduction CloudComputingisincreasinglyusedastheplatformforICTinfrastructureprovisioning,application/systemsdevelopmentandendusersupportofawiderangeofcoreservicesandapplicationsforbusinessesandorganizations.CloudComputingisdrasticallychangingthewayICTisdeliveredandused.However,manychallengesremaintobetackled.Concernssuchassecurity,vendorlock-in,interoperabilityandaccessibility,servicelevelagreementsmoreorientedtowardsusersareexamplesofissuesthatneedtobeaddressed.InFebruary2015,theCloudStandardsCoordinationPhase2(CSC-2)waslaunchedbyETSItoaddressissuesleftopenaftertheinitialCloudStandardsCoordinationPhase1(CSC-1)workwascompletedattheendof2013,withaparticularfocusonthepointofviewoftheCloudComputingusers(e.g.,SMEs,Administrations).ThepresentreportinvestigatestherelationshipandtheinteractionsbetweenstandardizationandOpenSourcebasedsoftwareandsolutionsinCloudComputing.ThisquestionwasnotaddressedinCloudStandardsCoordinationPhase1(see[i.1]).Inthemeantime,CloudComputinghasemergedasoneofthedomainsofInformationandCommunicationTechnologywhereOpenSourcedevelopmentplaysaveryimportantroleandchangessignificantlythestatusquoand,amongstother,thetraditionalapproachtostandardization.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 6
1 Scope InFebruary2015,theCloudStandardsCoordinationPhase2(CSC-2)waslaunchedbyETSItoaddressissuesleftopenaftertheCloudStandardsCoordinationPhase1(CSC-1)workwascompletedattheendof2013.CloudStandardsCoordinationPhase2isinvestigatingsomespecificaspectsoftheCloudComputingstandardizationlandscape,inparticularfromthepointofviewoftheCloudComputingusers(e.g.,SMEs,Administrations).ItwillalsogenerateanewsnapshotregardingthestateofstandardsandinvestigatetheinteractionandrelationbetweenstandardizationandOpenSourcebasedsoftwareandsolutions.ThepresentreportpresentstheresultsofCloudStandardsCoordinationPhase2regardingtheanalysisoftherelationshipbetweenStandardsandOpenSourceinthecontextofCloudComputing.
2 References 2.1 Normative references Thefollowingreferenceddocumentsarenecessaryfortheapplicationofthepresentdocument.Notapplicable.
2.2 Informative references Referencesareeitherspecific(identifiedbydateofpublicationand/oreditionnumberorversionnumber)ornon-specific.Forspecificreferences,onlythecitedversionapplies.Fornon-specificreferences,thelatestversionofthereferenceddocument(includinganyamendments)applies.
NOTE: Whileanyhyperlinksincludedinthisclausewerevalidatthetimeofpublication,ETSIcannotguaranteetheirlongtermvalidity.
Thefollowingreferenceddocumentsarenotnecessaryfortheapplicationofthepresentdocumentbuttheyassisttheuserwithregardtoaparticularsubjectarea.
[i.1] CloudStandardsCoordination,FinalReport,November2013.http://csc.etsi.org/resources/CSC-Deliverable-008-Final_Report-V1_0.pdf
[i.2] Regulation(EU)No1025/2012oftheEuropeanParliamentandoftheCouncil,onEuropeanstandardization,25October2012.http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32012R1025
[i.3] ImplementingFRANDstandardsinOpenSource:Businessasusualormissionimpossible?,EuropeanCommission,November2012http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/report-from-frand-os-conference-22nov12_en.pdf
[i.4] Openrequirementsforstandards,OpenSourceInitiativehttp://opensource.org/osr
[i.5] ETSISR002960v1.0.1"WorkinginETSIwithinanOSScontext",12/2012[i.6] Comparisonoffreeandopen-sourcesoftwarelicenses,Wikipedia
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses[i.7] Top20OpenSourcelicenses,BlackDuck
https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses[i.8] ThearchitectureofOpenSourceApplications,A.Brown&G.Brown,TheAOSAeditors[i.9] TheOPNFVRelease1'Arno':
https://www.opnfv.org/sites/opnfv/files/opnfv_arno_overview_diagram.jpg[i.10] ISO/IECGuide2:2004"Standardizationandrelatedactivities–Generalvocabulary"[i.11] OpenStackApplicationProgrammingInterface(API),http://developer.openstack.org/api-ref.html[i.12] UKGovernmentOpenStandardsPrinciples
https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 7
[i.13] "CompatibilityOfTheLicensingOfEmbeddedPatentsWithOpenSourceLicensingTerms",IainG.MitchellQC,StephenMason,http://www.ifosslr.org/ifosslr/article/view/57
[i.14] ISO/IECDraft19941"CloudComputing–InteroperabilityandPortability"[i.15] “OpenStandardsandOpenSource:EnablingInteroperability”,F.Almeida,J.Oliveira,J.Crux
http://airccse.org/journal/ijsea/papers/0111ijsea01.pdf
3 Definitions, symbols and abbreviations 3.1 Definitions Forthepurposesofthepresentdocument,thefollowingdefinitionswillapply:
opensourcelicense:CopyrightlicenseforOpenSourcesoftware
opensourcesoftware(OSS):ComputersoftwarethatisavailableinsourcecodeformNote:Thesourcecodeandcertainotherrightsnormallyreservedforcopyrightholdersareprovidedunderanopen-sourcelicensethatpermitsuserstostudy,change,improveandattimesalsotodistributethesoftware
sourcecode:Anycollectionofcomputerinstructionswrittenusingsomehuman-readablecomputerlanguage,usuallyastext
standardssettingorganization(SSO):Anyentitywhoseprimaryactivitiesaredeveloping,coordinating,promulgating,revising,amending,reissuing,interpreting,orotherwisemaintainingstandardsthataddresstheinterestsofawidebaseofusersoutsidethestandardsdevelopmentorganization
standard:AStandardisanoutputfromanSSONote:forthesakeofsimplicity,themeaningsof"standard"and"specification"arenotdifferentiatedinthepresentreport,unlikeintheotherCSC-2reports
3.2 Abbreviations Forthepurposesofthepresentdocument,the[following]abbreviations[givenin...andthefollowing]apply:
3GPP ThirdGenerationPartnershipProjectAPI ApplicationProgrammingInterfaceCC CloudComputingCCSL CloudCertificationSchemesListCSA CloudSecurityAlliance CSC-1 CloudStandardsCoordinationPhase1CSC-2 CloudStandardsCoordinationPhase2CSMIC CloudServicesMeasurementInitiativeConsortiumDMTF DistributedManagementTaskForceEC EuropeanCommission ENISA EuropeanUnionAgencyforNetworkandInformationSecurityEPO EuropeanPatentOffice IaaS InfrastructureasaService ICT InformationandCommunicationsTechnologyIEC InternationalElectrotechnicalCommissionIETF InternetEngineeringTaskForce ISG IndustrySpecificationGroup(anETSIstructureforopenmembershipprojects)ISO InternationalOrganizationforStandardization IT InformationTechnology ITU InternationalTelecommunicationUnion
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 8
ITU-T ITUTelecommunicationStandardizationSector NFV NetworkFunctionVirtualizationNIST NationalInstituteofScienceandTechnologyOASIS AdvancingOpenStandardsfortheInformationSociety OCF OpenCertificationFrameworkODCA OpenDataCenterAllianceOGF OpenGridForumOMA OpenMobileAllianceOPNFV OpenPlatformforNFVOSS OpenSourceSoftware PaaS PlatformasaService SaaS SoftwareasaService SDO StandardsDevelopmentOrganizationSLA ServiceLevelAgreementSME SmallorMediumEnterpriseSNIA StorageNetworkingIndustryAssociationSSO StandardsSettingOrganizationSTF SpecialistTaskForce(anETSIstructureforinternalprojects)TMF TeleManagementForumW3C WorldWideWebConsortium
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 9
4 Standards and Open Source 4.1 Context TheCloudStandardsCoordinationproject(CSC)Cloud Standards Coordination Phase 1 (CSC-1) took place in 2013 as a community effort supported by ETSI andprimarilyaddressedtheCloudComputingstandardsroadmap.InDecember2013theresultswerepubliclypresentedinaworkshoporganizedbytheEuropeanCommission(EC).The CSC-1 Final Report [i.1] provides a snapshot on the Cloud Computing standardization landscape at the end of2013.Itisavailableat:
http://csc.etsi.org/resources/CSC-Deliverable-008-Final_Report-V1_0.pdfCloudStandardsCoordinationPhase2GiventhedynamicsoftheCloudComputingmarketandstandardization,CloudStandardsCoordinationPhase2(CSC-2) was launched in February 2015 with, in particular, the main objective of producing an updated version of thesnapshotof theCloudComputing standardization landscape.CSC-2aimsatbetter taking intoaccount theneedsofCloudComputingcustomersontheirCloudrelatedrequirementsandpriorities.ThiswillhelpCSC-2tofurtherassessthematurityofCloudComputingstandardsandevaluatehowstandardscansupporttheCloudComputingcustomers’priorities.AnalyzingtherelationshipofStandardsandOpenSourceThequestionofOpenSourcehasbeenalludedto intheCloudStandardsCoordinationPhase1report [i.1],butnotdirectlyaddressed:
"AnotheraspectofthecloudcomputingenvironmentthatisworthyofconsiderationistheroleofthevariousOpenSourceprojectswhichareaddressingmanyofthetopicsdiscussedinthisreport.Whilenotformalstandards,theOpenSourceprojectsarecreatingtried-and-testedAPIs,protocolsandenvironmentswhichaddressaspectsofinteroperability,portabilityandsecurityrelatingtocloudcomputing.ItispossiblethatfuturespecificationsandstandardsmayderivefromoneormoreoftheOpenSourceprojects.SomeexamplesofpositiveinteractionhavealreadybeenseenbetweenstandardsbodiesandOpenSourceprojectsthatshouldbeencouraged.TheroleofOpenSourceprojectswasnotaddressedinthisreport."(see[i.1]section6.1)
Thepresentreportaddressessomeofthepointsmentionedabove,inparticularregardingthepositiveinteractionofStandardsSettingOrganizations(SSO)andOpenSourcecommunities.
4.2 Objectives ThepresentreportwillelaborateonthedifferencesandoverlapsbetweenOpenSourceandstandardizationwiththepurposeofoutliningareaswhere,despitethesedifferences,OpenSourcecommunitiesandStandardsSettingOrganizationsmightcometogethertofurtheraddvaluetotheCloudComputingspace.Themainobjectivesareto:
• UnderstandtherelationshipbetweenOpenSourceandstandardsandvice-versaviatheidentificationofanumberofinteractionscenariosinvolvingStandardSettingOrganizationsandOpenSourcecommunities.ThesescenariosarenotspecifictoCloudComputing.Someofthemarealreadyvisibleandsomeonlyemerging.
• ClarifyhowthesescenariosapplytoCloudComputing.• CollectinformationupontheperceivedstrategiesandvisibleactionsoftheSSOsregardingOpenSource,and
howtheymatchtheabovescenarios;• CollectinformationupontheperceivedstrategiesandinteractionsoftheOpenSourceprojectstowards
standardization,especiallywhentheinteractionscenarioinvolvesoneormoreoftheSSOsrelevantinCloudComputing;
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 10
• Proposerecommendationstofosterpositiveinteraction,tosuggestareasforcollaborationbetweenbothcommunitiesonwaystosupportthisinteraction(e.g.technicalframeworks,interoperability,intellectualproperty).
4.3 Approach Asitwillbeoutlinedanumberoftimesintheremainderofthepresentreport,standardizationandOpenSourceareservingratherdifferentpurposesandhavedevelopeddifferentwaystoachievetheirowngoals.Therefore,thefollowingisnotgoingtobeadebateontherespectivemerits(orlackof)ofeachapproach.ThereportismostlyfocusedontherelationshipbetweenstandardizationandOpenSourceinCloudComputing.Theunderstandingofthisrelationshipmayrequirethatsomeconsiderationwillbemadeoftopicsoutsidethisprecisescope.However,thishasbeenlimitedtothemaximumandthereportisnotaddressingthefollowingquestions:
• Thedebateonthedifferentmeaningsof"open".Differentapproachesto"openness"arecoexisting,inparticularregarding"openstandards".ThepresentreportwillrefertotheEUregulation(see[i.2]),aswasalsothecaseforCloudStandardsCoordinationPhase1.
• Thedebateonthemanyoptionsforintellectualpropertylicensing.DifferentapproachesarecoexistinginOpenSourcecommunitiesaswellasinstandardization.Despiteitsimportance,thisquestionhasbeenconsideredasoutsideofthescopeofthepresentreport.
• ThedebateontherespectivemeritsofOpenSourcelicenses.Thesameremarkasaboveapplies.• ThecontributionsoforganizationsthatarenotdirectlyinvolvedinstandardsmakingorOpenSourceprojects
inCloudComputingthatareoutsidethescopeofthework.,eveniftheyareaddressingimportantquestionssuchaspromotion,marketing,etc.
4.4 Content of the report Section5ofthisreportisageneralanalysisofthemaindifferencesbetweenstandards-makingandOpenSource(Software)andtherelatedchallenges.ThoughthisanalysisisnotaddressingCloudComputingspecifically,theremarksmadeapplyalsointhiscontext.Section6ispresentingaframeworkfortheanalysisoftheinteractionsbetweenstandards(andinparticularStandardsSettingOrganizations)andOpenSource(andinparticularOpenSourceorganizationsorprojects).ThisframeworkisnotspecifictoCloudComputingbutmaybeusedinthiscontext.Itisusedinthefollowingsections.Section7outlinessometrendsandopenquestionsregardingtheevolutionofSSOs’andOpenSourcecommunities'expectations,strategiesandperceivedevolutions.Section8highlightsconclusionsandrecommendationsfromtheanalysisdoneinthepresentreport.Section9suggestssomeareasforfurtherwork.AnnexAisacompilationofinformationrelatedtotheundertakingsofmajorSSOsinCloudComputingrelatedtoOpenSource.AnnexBisacompilationofinformationrelatedtotheundertakingsofmajorOpenSourcecommunitiesandprojectsinCloudComputingrelatedtostandardization.AnnexCintroducesseveralexamplesofthescenariosoutlinedinSection6inthecontextofCloudComputing.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 11
5 Standards and Open Source: definitions, objectives and interaction challenges
ThissectionpresentssomegenericcharacteristicsofstandardsandOpenSource(i.e.nonspecifictoCloudComputing)andhowstandardsandOpenSourcesolutionstogethercanhelpdrivethedevelopmentanduptakeofCloudComputing.
5.1 Definitions and objectives 5.1.1 Standards DefinitionAstandardisdefinedas“adocument,establishedbyconsensusandapprovedbyarecognizedbody,thatprovides,forcommonandrepeateduse,rules,guidelinesorcharacteristicsforactivitiesortheirresults,aimedattheachievementoftheoptimumdegreeoforderinagivencontext”(see[i.10]).ThisdefinitionisinfactamplifiedbyETSI’srulesfordraftingstandards(availableviatheETSIPortal).Standardsaretypicallymanifestedasspecificationsthatcanbeusedasisoraselementsoflargerproducts,solutionsorotherstandards.Astandardcanbecomparedtoorsaidtoconstituteareferencebasedonwhichonecanbuildproductsorservicesthatallsharethesamespecifications,andthusare“compatible”atsomelevel.Standardsareofvariousnatures,mayapplytodifferentcontextsandarenotalwaysdirectlyrelatedtoanimplementation. Astandardmaybeuniversalinnature,andisoftenusedinternationallyand/orindependentofaparticularindustryorverticaldomain.Standardscanalsobedevelopedtosupportaparticulardomain,verticalorindustrysector. Standardstendtobestableovertime.Anotherfrequentlymentionedcharacteristicisthatastandardshouldbetechnicallyagnostic/neutral,unlessdevelopedinsupportforaparticulartechnologyplatform.Thisallowsinnovationtotakeplaceinimplementations. StandardsSettingOrganizationsAStandardsSettingOrganization(SSO)referstoanyorganizationthatdevelopsandmaintainsstandards.SomeessentialelementsoftheoperationofanSSO(see[i.2],[i.4]or[i.12])are:
• Transparentandpubliclyaccessibledecision-makingprocesses;• Collaborativeconsensusbuilding,extensiveconsultation&reviewefforts;• Formalproceduresandmatureprocesses;• Fairaccesstostandardsatzeroornominalcost;• Deliberateselectionoffuturestandardsthroughprestudies,studygroupsorsimilarprecedinganydecision
todevelopastandard;• Marketsupportandusage.
BenefitsWhilstsuccessandadoptionofindividualstandardsmayvary,ingeneraltheknownbenefitsthatcomefromrelyingonstandardsare:
• Stability.ThemorestandardsareincorporatedandusedinICTsolutions,themorelikelyitisthatthesolutionbasedonthemwillbestableovertime.
• Focusonthecorefunctionality.Asaconsequenceofusingstandards,thedevelopersofICTsolutionscanspendthemostoftheireffortsoncreatingsupportforthecorefunctionalitythatisrequestedbytheusers.
• WidespreaduseandInteroperability.Usingstandardsincreasestheprobabilityofinteroperabilitybetweensolutions;standardsforexchangeofinformationforexamplearecommonlybasedonspecificationsthatarebuiltforanytechnologyplatformandwithsupportfordifferentunderlyingtechnologiesinmind.
• Technology/implementationneutrality.Inparticular,thisisasignificantfactortosupportavoidanceoflock-inbyallowingmultipleimplementationsfromdifferentproviders.
• Regulatory/GovernmentalPolicies/Legalaspects.Standardsareoftenusedasupportforregulation.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 12
5.1.2 Open Source DefinitionOpenSourcereferstoawaytodevelopsolutionscollaboratively.OpenSourcesolutionsrelyona“community”thatisresponsibleforthedevelopment,provisioningandmaintenanceoftheOpenSourcesolution.MostOSSsolutionshavebeendevelopedwithindependencefromtheunderlyingenvironmentasamainobjective.Initially,OpenSourcesolutionswereparticularlyavailableonfreelyavailabletechnologies(suchasLinux,Apache,Javadistributions,etc.)butaretodayavailablealsoonmostcommerciallyavailabletechnologyplatforms. Appliedtothedevelopmentofsolutions,OpenSourceischaracterizedbythefollowing:
• Decentralizedproductionofsourcecode;• Collaborationacrossgeographiesandorganizations;• Variants,knownas“forks”,thatsometimesarebroughtbackintotheoriginatedversionofthesourcecode
productorinothercasesspunoffintoanotherproduct;• UsageofOpenSourcelicenses(see[i.6]and[i.7]).
OpenSourcecommunitiesTherearemanyOpenSourcecommunitiesinCloudComputing.SomeofthemarelistedandanalyzedinAnnexBofthepresentreport.BenefitsWhilstsuccessandadoptionofindividualopensourceprojectmayvary,ingeneraltheknownbenefitsthatcomewithOpenSourceare:
• Sharedco-developmentresourcesenablingcollaborationandreducingdevelopmentcosttoeachparticipant;• Availabilityofmanyresourcesduetothecollaborativeandcommunity-basednatureofOpenSource;• Adevelopmentmodelbasedonrecurringandincrementalreleasesandimprovementthatfitswellwith
conceptssuchas“continuousdelivery”,“teambaseddevelopment”and“agiledevelopment”;• Modularandclearlydefinedproductsandserviceswithimprovedflexibilityforcustomization;• Supporttomultipleunderlyingenvironmentsasakeyfactortoavoidanceoflock-in.
5.2 Different objectives, different approaches TheOpenSourceapproachisusefulto,atleast,twocategoriesofstakeholders:
• Developersarebenefittingfromacarefullyelaboratedandfine-tunedinnovationframework:tools,methods,governance,recognition,etc.Thisframeworkisfullysupportivetomajorrequirementsfromthiscommunity:systematicusageofsourcecodeatthecenterofthedevelopment,supportofagilemethodologies,extremelyshortcycletimes,tonameafew.
• Someorganizations(e.g.enterprises,industryassociations,serviceproviders,etc.)havequicklyendorsedtheinnovationpowerofOpenSourceandincorporateditintotheirstrategies.Theyallsharetheobjectiveofcreatingecosystemsaroundinnovationstorapidlytesttheirvalueandshortentheirtime-to-market.The'openinnovation'basedmodelprevalentasaresultofOpenSourceenablesthecreationofvalue-addedservicesontopofthesourcecode.
TheleadingforceinOpenSourceisthe(source)code:"thecodeistheproof"(thattheideaissound,thatitisimplementable,thatitsworks,etc.).Inconsequence,OpenSourcehassomespecificcharacteristicsthatmakeitdifferentfromstandardization:
• ThefocusoftheOpenSourceworkisthedevelopmentofanindependentsetofsourcecodethatcanpossiblybeforkedintoanotherindependentsetofsourcecodethatwillprovideadifferentsolution.Thisapproachtomultipleimplementationsisdifferentthantheoneinstandardization(whichisinmostcaseabasicassumptionforthedevelopmentofstandards).Butinanycase,itmustbeclearthatOpenSourcecommunitiesaswellasSSOsconsidermultipleimplementationsasakeyaspectoftheirworkandareorganizedtosupportthem(e.g.viaawideuseofplugfests);
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 13
• OpenSourcedevelopmentdoesnotnecessarilyrelyonprior(ex-ante)specifications.Insomeextremecases,awrittenspecificationandevendocumentationarehardtofind;
• OSSisconcernedwithinteroperabilityifandwhenitisusefulandneeded,forinstancetoenforcemulti-vendorssupport.
Ontheotherhand,theleadingforceinstandardsisthespecification:
• TheworkinSSOsassumeanex-antepluralityofimplementersandtriestoavoidthechoiceofagiventechnologyagainstotherpossiblecandidateones;
• SSOsensureneutralityvis-à-visimplementationsviastableandwell-controlledspecifications.Themajorobjectiveistoguaranteeinteroperabilityandinmostofthecasestoprovidethemeanstoverifyit(viatestspecifications,validationtools,interoperabilitytesting,etc.);
• SSOsareguaranteeingtheneutralityvis-à-vistechnologiesthroughtheirinternalprocesses,andapermanentsearchforconsensus(witharesulttoreducetheconcernsrelatedtoantitrust).
5.3 Main challenges to an efficient interaction ThissectionidentifieschallengesthatneedtobeaddressedandresolvedtoallowamoreefficientinteractionbetweenOpenSourceandStandards.
5.3.1 Technical challenges ArchitectureWiththedevelopmentofmoreandmorecomplexsystems,standardsnolongerrelyonlyonthedefinitionofprotocoltosupportinteroperability.Theyarealsomoreandmorerelyingonreferencearchitectures,functionaldecompositionsandreferencepointsthatareslowlyevolvingovertime.ForOpenSourceproducts,thesituationiscomparable:todistributetheworkloadbetweenvariouscontributingprogrammersorcodeproducingcommunities,aproperarchitecturalandfunctionaldecompositionofthesoftwareunderdevelopmentismandatoryforOSSdevelopment(see[i.8]).IncrementalreleasesversusupdatesOpenSourceproductsarelargelyevolvingincrementally:newfeaturesareprototyped,testedandadaptedveryrapidly.Thestabilityofthecodeisamajorissueopensourceprojectshavetoaddressbyimplementingpropermeasuresforreleasemanagementandversioning.Standardsontheotherhandaredevelopedonce,andthenupdated(moreorless)regularly,untiltheybecomeobsolete.StandarddocumentandsourcecodeStandardsSettingOrganizationsandOpenSourcecommunitiesproduceanddistributeartifactsthataredifferentinnature:
• StandardsSettingOrganizationsproducestandardsthatarecommonlymanifestedindocumentsthatspecifyrequirements,architectureandprotocols/APIsofasystemorapartofasystem.Theevolutionofastandardisbasedonchangerequeststhatareexaminedduringperiodicreviewsandpossiblyimplementedviaachangerequestinthestandard.Thecoherentdevelopmentofthestandardissupportedbytoolenvironmentsthatareessentiallymanagingdocumentversionsassociatedtoalistofrevisions.NotethatsomeStandardsSettingOrganizationsguidelinesincludetheneedofhavingsourcecodeimplementationsofthestandard(e.g.W3C,OGF).
• OpenSourcecommunitiesproducesourcecode,acollectionofcomputerinstructionswrittenusingsomehuman-readableprogramminglanguage,usuallyastext.Thissourcecodeevolutionisguidedbyapermanentflowofchangerequeststhatareconstantlyexaminedbyreviewersandimplementedon-the-flyifdeemedaccurate.WhilesourcecodeisthemainoutputofOpenSourceProjects,asolidproductdocumentationincludingcodedocumentations,architectureandfunctionalspecificationsbasedonrequirementscollectionsorstandards,anduserandinstallationguides,iscrucialforasuccessfulOSSdevelopment.OpenSourcecommunitiesalsooftenproducedocumentationassociatedwiththeopensourcecode(e.g.architecture,APItextualdescription).
Interoperability
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 14
InteroperabilityisanimportanttopictoconsiderforstandardsandOpenSource,thoughforsomewhatdifferentreasons.Inthedevelopmentofstandards,achievingthehighestdegreeofinteroperabilityforanygivenstandardisnormallyoneofthemainobjectives(see[i.14]fortheworkdoneinISO/IECJTC1SC38oninteroperabilityandportability).ForOpenSourceprojects,achievinginteroperabilityisalsoimportant,buttypicallyonlywithinthetechnologycontextoftheOpenSourceprojectinquestion. ForCloudComputingeffortstobesuccessfulwhenusingstandardsandOpenSource,itissubsequentlyimportanttounderstand,keeptrackofandaddressallaspectsofinteroperabilitythatapplyintheCloudComputingcontextinquestion.Thisreportwillnotgoin-depthintosuggestingconcreteactionstoaddressinteroperabilityaspectsrelatedtostandardsandOpenSource,butsomehighlevelrecommendationsspecifictostandardsandOpenSourcecanbemade:
• StandardsandOpenSourcearenotmutuallyexclusive,butcomplementary.Asaconsequence,implementingCloudComputingsolutionsbasedonstandardsusingOpenSourceasthewaytodevelopandprovisionthesolutionsispossible.Keepingfocusontheparticularcharacteristics,advantagesandweaknessesofstandardsandOpenSourceinordertomitigateanyproblemswillprobablybeimportant;
• UsingOpenSourcetoimplementstandardsasCloudComputingsolutionsisnotenough.OpenSourceandstandardsbythemselvesdonotsolveandaddressallneedsandrequirementsofCloudComputing.Additionally,oneneedstounderstandtheuser-specificneedsandrequirements,processestobesupported,informationanddatatobeprocessed,securitypoliciesinplace,longtermgoals,resourceavailabilityandlimitationandmuchmore.Thecomplexityofcreatingopen,transparent,secureandagilebusinesssupportingICTsolutionsshouldnotbetakenlightly.However,standardsandOpenSourcecantogetherassistinacceleratingtheprovisioningofCloudComputing.
ToolsandframeworksThedifferencesbetweenstandardsandOpenSourceoutlinedintheaboveparagraphhavetheircounterpartinthetoolsandframeworkscurrentlyusedbytheirrespective"developers":
• Thetoolsthatsupportstandardsdevelopmentanddistributionaretypicallywordprocessors(withtheinternalabilitytotrackchanges)aswellasdocumentrepositories(tree-basedrepositories,sharepoints,portals,etc.).Ontheotherhand,thereisthepotentialforaspectsofcertainstandards–e.g.programminginterfaces,datamodelsorontologies,tobedescribedinamachine-readablefashionthatcanbeautomaticallyprocessed(e.g.intoaspecificlibrarywritteninaspecificprogramminglanguage).
• AnOpenSourceproductisessentiallydevelopedaroundsourcecodeversionmanagementtoolsembeddedinlargerframeworksofferingpeerreview,collaboration,etc.(suchasGitandGitHub).Thesetoolsareoptimizedforthemanagementofsourcecode,lessforhandlingpaper(whichisnotperceivedingeneralasadrawbackbytheusers).Therefore,opensourceprojectsrelyinadditionondocumentmanagementsystemsforproductandprojectdocumentations.Moreover,toolsforqualityassurance(e.g.,overnighttesting),automatedlicensecompatibilitychecking,projectmaturityvalidation,softwaremetrics,etc.,areusedbymanyopensourceprojects.
SomeSSOshavedevelopedveryeffectivetools,frameworksandprocessesforthestandardstheymaintain.Forinstance,theproofofinteroperabilityrequiresalotofproceduralandtechnicalsolutions(e.g.testmethods,descriptionlanguages,testenvironments,etc.)thatSSOscanpotentiallyoffertootherorganizations.OSScommunitiesmaybenefitfromusingthetestorQualityAssuranceservicesofSSOs,providedthattheseserviceshavebeenadaptedtotherequirementsofOpenSource,e.g.byOpenSourcerepositories,OpenSource-basedtestdevelopmentorconformancetesting.
5.3.2 Organizational challenges (Long-term)MaintenanceMaintenance(evenlong-term)ispartofthebasicoperationsoftheSSOs,especiallytheSDOsthatareinchargeofensuringthatcriticalstandardsremainavailableoverlongperiodoftimeandcanbeadaptedtothechangesintheiroperatingenvironment.WhenitcomestoOSS,thisobjectiveisnotalwaystakenintoaccountwhentheprojectsarelaunched,thoughsomeOpenSourcecommunitiesintheICTdomainarewillingandabletodomaintenanceoveralongperiodoftime.However,insomecases,thismaintenanceisnotpossible,forinstancebecause:
• SomeOSSprojectshavetobediscontinued,e.g.forlackofresourcesorlossofbasicexperts;
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 15
• Inlong-livedsystems,suchastheonesthataredeployedintelecommunications,some"de-facto"productsmaybedeployedonthefieldfordurationsthatexceedthecapabilitiesoftheoriginatingOpenSourcecommunities.
Inthiscase,thelong-termmaintenancemayhavetobetakenoverbyadifferentorganization.ThiscanpotentiallybedonebySSOs,providedthattheyareorganizedtoprovidethecorrespondingservicetoOpenSourcecommunities.GovernanceInallorganizations,acleargovernancemodel,withexplicitandwell-documentedrulesfordecision-making,isapre-conditionforwell-motivatedandefficientparticipationoftheactors.Therearemanygovernanceschemesthatfitthispurpose,andnoneisparticularlybetterthantheotherones.Inanycase,clarityisamust.Ingeneral,thegovernanceofSSOshasbeenorganizedaroundtheneedtocreateandmanageconsensusasthebasisformakingwidelyacceptedandrelevantstandards.Thetechnicaldecisionsare,inmostcases,delegatedto"TechnicalGroups"(orcommittees,etc.)whereastheglobalandstrategicdecisionsareundertheresponsibilityofaBoard(orsimilargroup),ingeneralcomposedofelectedmembers.InOpenSourcecommunities,twomodelsarewellestablished(withalotofvariantsthatsharesomeelementsofboth):theso-called"benevolentdictatorship"wherecontrolisunderasingleentity(personorgroup),andthedistributedcontrolwherepartsofthegovernanceisallocatedtoindividualsthathavebeenrecognizedascapableofthetask.AnotherdifferencebetweenSSOsandOpenSourcecommunitiesregardinggovernanceisitsfocus:whileSSOsgovernanceisdirectedtowardsachievingconsensusontechnicalissuesandaddressesarelativelyclosedsetofstakeholders,thegovernanceofOpenSourcecommunitiesmayaddressalargercollectionofstakeholders.Therefore,additionalrequirementsonthetransparencyofdecision-makingprocessesaddressingacommunitywithfluidborders(bothintermsofcontributingpersonsandofrelevantopinions)havetobetakenintoaccount.WhenaddressingtheinteractionbetweenOpenSourcecommunitiesandSSOs,thequestionofgovernancemustnotbeunderestimated.Adiscussionbetweenbothpartiesforthedefinitionofsolutions,workprograms,etc.willrequireaclearandtransparentdecisionpointonbothsides,basedonwelldefinedprocesseswithactorsinwelldefinedroles.
5.3.3 Intellectual property challenges DifferentissuesareatstakewhenitcomestoIntellectualPropertyRights(IPR).Thisisafieldofveryactiveandsometimeshighlycontroversialdebates.SomeaspectsareverysignificantfortheSSOs,inparticularthosewithanIPRpolicythatraisepatentlicensingquestionsorissues.SomeaspectsareverysignificanttoOpenSourcecommunitiesthatwanttoensurethattheuseoftheirOSSproductisnotimpactedbypatentclaimsholdersinparticulartheabsenceofalicenseorunreasonablelicensingtermsandconditions.ThequestionsofOpenSourcelicensesandofSSOs'IPRpoliciesareamongstthosethatrequireclarificationinordertoensureanefficientinteractionbetweenSSOsandOpenSourcecommunities.OpenSourceLicensesThelicensesapplicabletoanOpenSourceproductorcommunityareextremelyvaried(see[i.6]).Evenifavastmajorityofthembelongtoalimitedset(the6mostusedlicensesrepresent81%ofOpenSourceprojects,see[i.7]),thequestionofthelicenseapplicabletoanOpenSourceproductorwithinanOpenSourcecommunitycannotbeignoredifproposedforinclusioninaStandardorasanimplementationofaStandard.PatentandcopyrightpoliciesFirst,anSSOwillhavetoensurethattheOpenSourcematerialthattheywanttoincludeintheirstandardsshouldnotbeassociatedwithusagerestrictionsattachedtoanOpenSourcelicense,e.g.restrictionsuponthedistributionofcommercialproductsandservicesthatcomeinconflictwiththeSSOIntellectualPropertyRightspolicy(see[i.5]).
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 16
Second,thequestionofwhetherornottheIntellectualPropertyRights(IPR)policiesoftheSSOsarecompatiblewiththeimplementationoftheirstandardsbyOpenSourcecommunitiesishighlydebated.Inparticular,itisoftenperceived(thoughnoconsensusofthispointhasbeenreached)thatimplementationofstandardsavailableunderaFRANDlicenseinOpenSourcemaybedifficult(see[i.3],[i.13]or[i.15]).Severalexamplesofdifferentapproachescanbenoticed:
• TheETSISpecialReporton"WorkinginETSIwithinanOSScontext"[i.5]addressesthequestionofFRAND,providessomerecommendationsandlistssomeactualimplementationsofStandardsbyOpenSourceprojectsthatcomplywiththeETSIIPRpolicy;
• TheOpenStandardsRequirement(see[i.4]bytheOpenSourceInitiative)definescriteriatoensurethatan"openstandard"willnotprohibitimplementationsinOSSconformingtothestandard;
• SomeSSOspoliciesonlysupporttheuseof"royalty-free"policyforimplementationoftheirstandards.
6 Standards and Open Source: Interaction scenarios 6.1 An overall view TheinteractionbetweenStandardsSettingOrganizationsandOpenSourcecommunitieshasitsorigininareciprocalneedtobenefitfromeachother'sproducts(e.g.standardsfromanSSO,orsoftwarefromanOpenSourcecommunity)andservices(e.g.QualityInsuranceorInteroperabilityTesting).Afewexemplaryscenariosareusedbelowtodifferentiateandclassifysometypicalinteractions.Thesescenariosarebasedinmostcasesonactualexamples,sometimeswithalongpastexperiencethatallowsforrelevantassessment.Ontheotherhand,somearerelatedtoinitialundertakingsorperceivedintentionsoftheactorsbutmaynotbeyetentirelyvalidated.Itisexpectedthat,incaseOpenSourcecommunitiesandSSOswanttoengageacollaboration,theywillhavetodiscussalongthelinesofoneormoreofthesescenariosandaddresstheissuesthathavebeendefinedintheprevioussection.
6.2 The scenarios 6.2.1 An Open Source community implements standards Thisinteractionscenario(Scenario1)includestwovariantsdependingonwhetherthestandardsarealreadyexistingpublishedstandards(Scenario1a)orareemergingstandards(Scenario1b).
6.2.1.1 An Open Source community implements existing standards from a Standards Setting Organization
Inthisscenario(Scenario1a):• AnSSOTechnicalGrouphasdevelopedandpublishedasetofstandards–thatwillbemaintainedandmaybe
furtherevolved.Thissetincludesdetailedprotocol/APIstandardsthatcanbeusedforimplementationpurposes;
• AnOpenSourcecommunityoutsidetheSSOwantstomakeareferenceimplementationofthesestandards–thatwillbefurtherdistributed(bytheOpenSourcecommunityitselforbyspecializeddistributors)andintegratedintocommercialproductsunderconditionsdefinedbyanOpenSourceLicense;
• TheOSSimplementationissettobefully"compliant"withthesestandardsorcanleadtoevolutionsofthestandardspublishedandmaintainedbytheSSO.
ExamplesofsuchimplementationscanbefoundintheETSI2012report[i.5].ForCloudComputing,anexampleofthisscenarioincludestheOpenStackimplementationofDMTFCADFspecification(seeAnnexCforfurtherinformation).
6.2.1.2 An Open Source community implements emerging standards from an SSO
Inthisscenario(Scenario1b):
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 17
• AnSSOTechnicalGroupisdevelopingasetofstandardsthatisnotyetstableandpublished.Thissetincludesstandardsatvariousstagesofthestandardsdevelopmentchain(e.g.standardsonrequirements,architecture,protocols/APIs);
• AnOpenSourcecommunityoutsidetheSSOwantstoundertakeanimplementationofthissetofstandards;• TheOSSimplementationmaybeonly"inspiredby"theon-goingworkoftheSSOandcan:
• SignificantlydivergefromitiftheprogressoftheOpenSourceimplementationisnotfedbacktotheSSO.Insomecase,theresultoftheOpenSourcecommunityworkisaproductimplementingasubsetofthestandardsunderpreparationintheSSO.
• ProvideearlyfeedbackonthestandardsunderelaborationintheSSOspecificationbyrapidlyprototypingsomeaspectsofit,inordertocomemorerapidlytoastableversionoftherelevantstandards.
Scenario1bisavariantofScenario1a,withpotentiallysignificantimpactsontheemergingstandardsunderpreparationintheSSO.AnexampleofScenario1bistheinteractionbetweentheIndustrySpecificationGroup"NetworkFunctionVirtualization"inETSI(ISGNFV)andtheOpenPlatformforNFV(OPNFV)(seemoredetailsinAnnexC).
6.2.2 An SSO develops an Open Source reference implementation Inthisscenario(Scenario2):
• AnSSOTechnicalGrouphasdevelopedandpublishedasetofstandards–thatwillbemaintainedandmaybefurtherevolved;
• Tospeed-upthemarketadoption,theTechnicalGroupdecidestodevelopareferenceimplementationofthesestandardsorofasubsetofthem,usinganOpenSourcemethodologyandenvironment(includingfortestingpurpose).
TheresultoftheSSOworkisabundleoftheStandardsandthereferenceimplementationsourcecode.Thereferenceimplementation:
• Isoneofmanyimplementationsinlinewiththepublishedset(orsubset)ofstandards.• CanbeusedbyanOpenSourcecommunityforinclusioninitsproductanddistributionordirectlyincludedin
commercialproducts(e.g.somevendors/integrators)underconditionsdefinedbyanOpenSourceLicense.Tomakethishappens,theSSOmusthaveimplementedinternallyanOpenSourcehostingframework.ExamplesofthisscenarioincludetheOpenSourceimplementationbyOMAoftheRCSspecification,whichisintegratedintocommerciallyavailableproducts.SimilarinitiativesarestartinginoneM2Mand3GPPpartnershipprojects.,ForCloudComputing,oneexampleistheDMTFStandardsSettingOrganization,whichisdevelopinganOpenStackimplementationoftheCIMIspecification.(SeeAnnexCforfurtherinformation).
6.2.3 An SSO develops standards based on the results of an Open Source community
Inthisscenario(Scenario3):• AnOpenSourcecommunityisdesigninganddevelopingasoftwareimplementationthatfulfillstheneedsof
anSSO,e.g.providinganimplementationcoveringthefunctionalandarchitecturalrequirementsexpressedinstandardspublishedorunderdevelopmentbythatStandardsOrganization;
• TheStandardOrganizationdecidestoendorsetheresultsoftheOpenSourcecommunityanddevelopsstandardsbasedonthedocumentedAPIsdevelopedbytheOpenSourcecommunity;
• TheOpenSourcecommunityhasoptedforanOpenSourcelicense.Theresultingstandardisasetof"triedandtested"APIsactingasareferenceinitsindustrysegment.AnexampleinCloudComputingistheDMTFspecificationofanOpenStackprofileforCADF(SeeAnnexCforfurtherinformation).
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 18
6.2.4 A collaboration (“joint project”) is established between a Standard Organization and an Open Source community
Inthisscenario(Scenario4):• Ajointcollaboration(“jointproject”)betweenaStandardsOrganizationTechnicalGroupandanOpenSource
communityisestablishedwiththeobjectivesofdevelopingtogetherasetofstandardsandanOpenSourceimplementationofthesestandards.
• Thesetofstandardsincludesstandardsatvariousstagesofthestandardsdevelopmentchain(e.g.standardsonrequirements,architecture,protocols/APIs)whiletheOpenSourceimplementationprovidesareferenceimplementationofthesestandards.
• ThiscollaborationincludestheestablishmentofajointsteeringTechnicalCommitteewhosetasksistocoordinatethedevelopmentofstandardsbytheStandardOrganizationandthedevelopmentoftheOpenSourceimplementation.ThisTechnicalCommitteewilldrivetheroadmapintermsofusecases,requirementsandarchitecturethatshouldbesupportedbytheOpenSourceimplementation.
Scenario4canbeviewedasacombinationofScenario1bandScenario3withtheadditionofaformal“jointproject”betweenaStandardOrganizationandanOpenSourcecommunitytohelpfosteringandcoordinatingeffortsinacoherentandagilemanner.IthastobenotedthoughthatanequivalentscenarioexistinthefieldofstandardizationwherecollaborationbetweenStandardOrganizationsarepossible,e.g.partnershipprojectsbetweenregionalStandardOrganizationssuchas3GPPorOneM2MorcollaborativeteamsbetweenISO/IECJTC1sub-committeesandITU-Tstudygroups.
6.3 Current and future situation Someoftheabovescenariosarewellestablishedwhereassomearemoreintheirearlydiscussionphasewithintheconcernedorganizations(OpenSourcecommunitiesaswellasSSOs).WiththeexpectedclarificationoftheinteractionsbetweenSSOsandOpenSourcecommunities,moreexamplesoftheabovescenariosaswellasnewscenariosarelikelytoemergeinthecomingyears.
7 Better aligning the standards and OSS communities 7.1 Alignment: if and when needed Regardingalignment,itisnotintendedheretofindawaytocomeupwithsimilarwaysofworkingandexpectedoutcome(whichwouldbeimpossibleconsideringthemajordifferencesinpurposeidentifiedinsection5).Actually,thereisadifferencebetweentheexpectationsofSSOsandOpenSourcecommunitiesfromthisstandpoint:SSOsarerealizingthat,inordertorespondbettertotheneedsofthestandardizationstakeholders,theyneedtofindwaystoincorporateOpenSourceintheirverygenes.ThisisnotthecaseforOpenSourceorganizationsthatdonotfeelthesamepressingneedforcooperation.ThisasymmetrybetweentheviewofSSOsandOSSisinparticularvisibleinthescenariosidentifiedinsection6,whereamajoritystemsfromtheneedsofSSOsratherthantheopposite.AlignmentwillcomefromtherealizationbybothSSOsandOpenSourcecommunitiesthattheyhavegoodopportunitiestoimprovetheeffectivenessoftheirrespectiveresults(morespeed,betterquality,moretesting,improvedmaintainability,etc.),ThisisespeciallytrueintheCloudComputingindustrysegment.Theprogresswillcomewiththeidentificationofmutuallysatisfactorysolutionstospecificproblems.ItisnotexpectedthateachSSOwillsetupacompleteOpenSourcestrategyimplementingallthescenariosofsection6(thoughsomemaywanttodoit).
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 19
7.2 Strategies Asaresultofthedifferentexpectationspointedoutabove,thematurityofstrategiestoaddressStandardsandOpenSourceinteractionisdifferentforSSOsandOpenSourceorganizations.TheSSOsstrategiesareregardingOpenSourcearecurrentlyatdifferentstages:
• Manyarejuststartingtodiscusstheissueandidentifytheirobjectives;• Somehavealreadyapreviousexperienceandhaveclearlyoutlinedobjectives;• Afewhavestartedtoanalyzehowtheirassetsmaybeimpactedbythisnewapproach(e.g.technical
organization,membershippolicy,IntellectualPropertypolicy);• Onlyafewhaveaverycompleteanddetailedapproach.
TheOpenSourceorganizationsstrategiesregardingstandardsarelargelyconditionedbytheanswertoafirstquestion:howcantheybenefitfromcollaboratingwiththeSSOs?AnnexAofthisreportisoutliningtheroleofsomeSSOsinvolvedinCloudComputingstandardization(e.g.thosewhohavebeenidentifiedduringCloudStandardsCoordinationPhase1)andthestatusoftheirOpenSourcestrategies.AnnexBhasasimilarobjectiveforsomeOpenSourceorganizationsinvolvedinCloudComputing.
7.3 Solutions Somepossiblesolutionshavebeenhighlightedintheprevioussectionsbutafirstanalysisshowsthattherearenotsomanyinplaceatthisstage.However,thefollowingapproachescanbehighlighted.1/ChangethesettingofSSOstoaccommodateOpenSourceprojectswithintheexistingorganization.Thiscantakeseveralforms,possiblycomplementary:
• DefinitionofspecifictechnicalorganizationswithintheSSO,differentfromtheirregulartechnicalcommittees.Forinstance,thecreationofTechnicalCommitteeswithspecialruleswithintheSSO(e.g.specificmembershiprules,differentIPRpolicies).
• DefinitionofspecificmembershipconditionsmeanttoattractregularparticipantofOpenSourceprojectswithinanSSOcontext(e.g.specialconditionstoacademics,tomicro-enterprise,etc.)
• Investigationofthebenefits,risksandrequiredchangesassociatedtotheadaptationoftheIPRpolicieswhenitbecomesnecessarytoaccommodatesomeoftheexpectedlicensingschemesintheOpenSourcecommunity(providedthereisareal–inparticularbusiness–advantage).
2/DefineOSS-orientedservicesinSSOsToofferattractiveservices,someelementsmustbedefined:
• ListofservicesinsupportofOpenSourcecommunities:o HostingofOSSproject,includingtheavailabilityofanOSSplatform;o Testingsupport,nparticularinteroperabilitytesting,plugfests,etc.o QualityAssurance;o Maintenance;o …
• Conditionsforuse:legalframework,ServiceLevelAgreement,etc.
8 ConclusionsandRecommendationsThegoalsofstandardsaredifferentfromthoseofOpenSourceSoftware(OSS).Standardizationaimsatproducingspecificationsthatcanbeimplementedinanyappropriatetechnology.Thisisessentialtoavoidvendorlock-insituationsaswellasforpromotinginnovativeimplementations.OpenSourceprojectsaimtofavortherapiddevelopmentofhighqualitysoftwareorreferenceimplementationsallowingforthediscoveryandvalidationofconceptsorprovidingsolutionsthatrespondtogivenusecasesandderivedfunctionalandarchitecturalrequirements.OpenSourceisalsopotentiallyanimportantvectorofgrowthandinnovationintheCloudComputingspace.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 20
StandardsandOpensourceapproacheshaveanimportantroletoplayincomplementingeachother,andinfact,tosomeextent,moreandmoreICTprojectsdocombinethetwoapproaches.However,onlystandardsprovidethestabilityandtechnologyneutrality,inparticularrequiredforpublicpoliciesthatseektoimproveinteroperabilitywhilereducinglock-intoanyparticulartechnologysolution.InitsroleofsupportingStandards,OpenSourcecan:
• HelpovercomelimitationsinthedevelopmentandimplementationofStandards;• SpeedthedevelopmentandimprovethequalityofStandards;• Facilitatetheunderstandingofstandardsforimplementers;• ImprovetheStandardinteroperabilitybyusingOpenSourcereferencetest-bedimplementationandtesting
software.ThereforeinorderforstandardsandOpenSourcetoadequatelysupporteachother,thefollowingrecommendationsareproposed.Collaboration
• EncouragecollaborationbetweenOSScommunitiesandSSOsworkingonsimilarorcloselyrelatedtopics,e.g.NFVandOPNFV,possiblythroughjointeventslikeworkshops,plugtests;
• Encouragethecreationof“jointprojects”betweentheSSOswherethestandardsaredevelopedandOpen
Sourcecommunitiesinordertopushforcloserelationship,interaction,exchangeandcooperation;Roadmaps
• MakesurethatcollaborationbetweenSSOsandOpenSourcecommunitiesaddresstheknownCloudComputing(standards)gaps,e.g.inServiceLevelAgreement,Security,PrivacyandIntegrity;
• EncourageOpenSourceinitiativestostandardizetheirspecificationsthatareimportantforinteroperability
(e.g.APIs:DataModel,Protocol,Format).Organization
• FacilitatetheimplementationofOpenSourcesolutionsbasedonStandards(developedorunderdevelopmentinaSSO),inparticularbynarrowingthegapbetweendifferentapproachesofPatentandCopyrightpolicies;
• Ensurethatpre-standardizationactivities(e.g.thoseemanatingfromresearchprojects)canbesustained
overalongerperiodinordertoallowforasmoothtransitionofresultswithinCloudComputingstandardization.
Education,dissemination,promotion
• EncourageSSOsforearlyandincreasedeffortinthedisseminationofplansfor/workonnewCloudrelatedspecificationstowardstheOpenSourcecommunitiesintheCloudarea;
• EngageindustrialusersofCloudComputingOpenSourcecommunities;
9 Areas for further study Someareasforfurtherstudyhavebeenoutlinedintheprevioussectionsofthisreport:
• ClarificationoftheStandardsandOpenSourceinteractionscenarios:o Content,o Completeness,o Operationalworkingprocedures,o Methodsandtools.
• ClarificationoftheimpactonSSOorganizationsofgreatercompatibilityofFRANDandOpenSourcelicenses.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 21
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 22
Annex A: Standards Related Organizations Approaches ThisannexispresentingsomeinitiativesofSSOsandafewrelatedorganizationsinthefieldofCloudComputingthatrelatetotheirinteractionswithOpenSourcecommunities.
Table1:StrategiesofSSOstowardsOpenSourcecommunities
Organization Type ScopeinCC Strategy,position,initiativeswithOpenSource
3GPP SDO Transparentfilesharingovermobilenetworks
ThereareanumberofOpenSourceimplementationsof3GPPspecification
ATIS SDO ATIShasdevelopedanumberofCloudComputingrelatedstandards;somehavebeenretainedinthelistofStandardsofCSC(phase1).
ATIShasdevelopedacompleteframework,inparticularlegal,toallowforstandarddevelopersandOpenSourcedeveloperstoworktogether,takingintoaccountdifferentmodelsforbusiness,licensingorIPprotection
CSMIC SSO TheCSMICaimstocontributetothesolutionofthecloud-basedservicemeasurementproblem.IncludingdevelopmentofaServiceMeasurementIndex(SMI)andaframeworkfororganizingandclassifyingservicemeasures.Thegoalisastandardwayofdescribinganddocumentingservicemeasures.
DMTF SSO DMTFdevelopedtheOpenVirtualizationFormat(OVF)thatisbroadlyusedtodescribevirtualmachineimagesinaportableway.DMTFalsospecifiedtheCloudInfrastructureManagementInterface(CIMI)whichisaself-serviceIaaSmanagementinterfaceandtheCloudAuditDataFederation(CADF)specificationdefinesanormativeeventdatamodelalongwithacompatiblesetofinterfacesforfederatingevents,logsandreportsbetweencloudprovidersandcloudcustomers.
DMTFhasalonghistorysupportingOpenSourceimplementationsofitsstandards.DMTFDSP2038definesaCADFrepresentationforusewiththeOpenStackCloudManagementPlatform
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 23
Organization Type ScopeinCC Strategy,position,initiativeswithOpenSource
ENISA EuropeanAgency
ENISAaspartoftheactivitiesundertheEUcloudstrategydevelopedalistofdifferentcertificationschemesthatcouldberelevantforpotentialCloudComputingcustomers.ThecreationofthislistisexplicitlymentionedasakeyactionintheEuropeanCloudStrategy.ThislistwasdevelopedbyENISAintightcollaborationwiththeEuropeanCommissionandtheprivatesector.
Thecertificationschemeslistcanbefoundat:https://resilience.enisa.europa.eu/cloud-computing-certification(WereferinterestedreaderstoapaperENISApublishedlastyearthatgivesanoverviewofarangeofinformationsecuritycertificationschemes,usedindifferentsectors.)
ETSI SDO ETSIisthehomeoftheNetworkFunctionVirtualization(NFV)IndustrySpecificationGroup(ISG)
TheETSIBoardhasdevelopedafirstframeworkforStandardsandOpensourcein2012.Theyarecurrentlyintheprocessofexpandingittotakeintoaccountmorescenarios.
IEEE SSO P2301isaworkinggroupforcreatingaGuideforCloudPortabilityandInteroperabilityProfiles.P2302–StandardforIntercloudInteroperabilityandFederation(SIIF)isthefirstCloudstandardizationactivityofIEEE
IEEEexpectstheseneweststandardswillnotonlyfollowtheconsensus-basedprocesschampionedbyIEEE,butwillalsoleveragethelatestintechnologydevelopmentbestpractices,suchasliveglobaltestbedsandOpenSourcereferences.
IETF SSO TheactualtechnicalworkoftheIETFisdoneinitsworkinggroups(WGs),whichareorganizedbytopicintoseveralareas(e.g.,routing,transport,security,etc.).IETFisspecifyingprotocolsanddatamodelsfor:
-SDN(NETCONF/Yangdatamodels,PCEP,ServiceFunctionChaining,…),
-RTCWeb,-HTTP
IETFhasstartedtodiscussaframeworktosupportOpenSource.Duringitsmeetings,IETFisholdingaHackathontoencouragedeveloperstodiscuss,collaborateanddeveloputilities,ideas,samplecodeandsolutionsthatshowpracticalimplementationsofIETFstandards.IETFindividualsstartusingGitHubforeditingIETFdrafts,prototyping,testsuites(e.g.https://github.com/http2)
OASIS SSO TopologyandOrchestrationSpecificationforCloudApplications(TOSCA)
LeadingOpenSourceorganizationshavealsoembracedTOSCAwithnumerousprojectsalreadyactive,e.g.integrationwithOpenStackHEAT,OpenNebula.
ODCA SSO
OGF SSO OGFhasdevelopedtheOpenCloudComputingInterface(OCCI)specificationandotherspecificationsthatareusefulinCloudenvironmentsthoughnotspecificallydevelopedforClouds,e.g.,WS-AgreementforCloudServiceLevelAgreements
ThereareanumberofOpenSourceimplementationsofOGFspecifications.IngeneralOGFencouragestheuseofOpenSourceimplementationsforevaluatingspecificationsandfortestinginteroperability.OpenSourceimplementationsmaybeusedtodevelopextensionstospecifications.OGFregularlyorganizesplugfeststosupportthis
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 24
Organization Type ScopeinCC Strategy,position,initiativeswithOpenSource
OMA SSO TheOpenMobileAlliance(OMA)deliveredthetechnicalspecificationforUnifiedCloudDisk(UCD)EnablerV1.0.TheUCDEnablerprovidesunifiedcloudstoragesysteminmobilecloudcomputingenvironments
OMAhasbeenaddressingthequestiononhowSSOscanadapt/evolvesuchthattheybetterenabletheapplicationdevelopertotakeadvantageofthestandardspecificationstheyproduce.SomeOMAeffortsintheareaofOpenSourceareongoingsuchastheadoptionofspecifictoolsforspecifications,theusageofGithubrepository,etc.
SNIA SSO TheSNIACloudDataManagementInterface(CDMI)isanISO/IECstandardthatenablescloudsolutionvendorstomeetthegrowingneedofinteroperabilityfordatastoredinthecloud.TheCDMIstandardisapplicabletoalltypesofclouds–private,publicandhybrid.
SNIA’sCloudStorageInitiative(CSI)promotescloudstorageadoptionwithopenstandardsthatprovidevendorsandenduserswithchoice,interoperability,andportability.CSIleadsasanindustryneutralauthorityoncloudstorageenvironmentsandiscommittedtoeducatingvendorandendusercommunitiesoncloudstorage&industrystandardizationbenefits.SNIAalsosupportsOpenSourceprojectsinstorage
TMF SSO TheprimaryobjectiveofTMForum’sCloudServicesInitiativeistohelptheindustryovercometoday’sbarriersaroundCloudservicesandassistinthegrowthofacommercialmarketplaceforcloudbasedservices.Thecenterpieceofthisinitiativeisanecosystemofmajorbuyersandsellerswhowillcollaboratetodefinearangeofcommonapproaches,processes,metricsandotherkeyserviceenablers.
AspartofitsZOOM(Zero-touchOrchestration,OperationsandManagement)project,TMFhasproducedaZOOMpositiononOpensource(seeTMFIG1119,Release14.5)
W3C SSO W3CitselfhasnotyetdevelopedaspecificstandardforCloudcomputing.However,asmost(ifnotall)oftheWS-*specificationsaretargetingweb-based
W3CconsidersOpensourcesneedOpenstandardsandCloudservicesneedOpenStandards.W3Cishappytocontributeandcollaborate•OpenPlatformCapabilities•DataandSemanticSupport•AdvancedServiceManagement
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 25
Annex B: Open Source Communities Approaches B.1 Open Source Cloud middleware projects InthissectionweanalyzethemajorOpenSourceCloudmiddlewareprojectsregardingtheirsupportforCloudstandards,theirrelationtoStandardsDevelopmentOrganizationsandtheirpossibleinvolvementinthedevelopmentofCloudstandards.
Table2:StrategiesofOpenSourceorganizationstowardsSSOs
Organization WhattheydoinCC Strategy,position,initiativeswithSSOs
Ceph Opensourcesoftwarestorageplatformdesignedtodeliverobject,block,andfilestoragefromasingledistributedunifiedsystem
CloudStack CloudStackisdevelopingCloudcomputingsoftwareforcreating,managing,anddeployinginfrastructurecloudservices.
CloudStacksupportstheOCCICloudComputingstandard.CloudStackasacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheCloudstackcommunitymaybeactiveinSSOs,inparticularVerizoneTerremarkclaimstobe,maybeactiveinthedevelopmentofopenstandards
CompatibleOneBroker
CompatibleOneisacloudbrokerbasedonopenstandards
CompatibleOnesupportstheOCCIandWS-Agreementstandards.CompatibleOneasacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheCompatibleOnecommunitymaybeactiveinSSOs
Contrail TheCONTRAILprojectdeliveredisanOpenSourcesysteminwhichresourcesthatbelongtodifferentoperatorsareintegratedintoasinglehomogeneousFederatedCloud.Afollow-upactivityisOpenContrail
ContrailsupportsanumberofCloudComputingstandards:OCCI,OVF,CDMIandWS-Agreement.MembersoftheContrailprojectparticipatedinthedevelopmentofOCCIduringthelifetimeoftheproject.
Eucalyptus EucalyptusisasoftwareforbuildingAmazonWebServices(AWS)-compatibleprivateandhybridCloudComputingenvironments
EucalyptussupportstheOCCICloudComputingstandard.Eucalyptusasacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheEucalyptuscommunity,especiallyHP,maybeactiveinSSOs.
KVM OpensourcesoftwarevirtualizationsolutionforLinuxonx86hardwarecontainingvirtualizationextensions.
Nimbus TheNimbusPlatformisanintegratedsetoftoolsthatdeliverIaaSCloudstoscientificusers;theNimbusInfrastructureisanOpenSourceEC2/S3-compatibleInfrastructure-as-a-Serviceimplementationalsowithafocusonscientificusers.
NimbussupportstheOCCIandstandard.Nimbusasacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheNimbuscommunitymaybeactiveinSSOs
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 26
Organization WhattheydoinCC Strategy,position,initiativeswithSSOs
OpenDaylight OpensourceSDNcontrollerplatformfornetworkprogrammabilitytoenableSDNandcreateasolidfoundationforNFVfornetworksatanysizeandscale.
TheSDNcontrollersupportsmultiplesouth-boundinterfacesandprotocolsdevelopedintheIETF(OVSDB,Netconf/Yang,PCEP,LISP,BGP,Opflex,CoAP…),ONF(OpenFlow).
OpenNebula OpenNebulaisacloudcomputingplatformformanagingheterogeneousdistributeddatacenterinfrastructures
OpenNebulasupportsanumberofCloudComputingstandards:OVF,CDMIandOCCI.OpenNebulaasacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheOpenNebulacommunitymaybeactiveinSSOs.
OpenStack OpenStackisdevelopingacloud-computingsoftwareplatform.MostoftenusedforIaaS
OpenStacksupportsanumberofCloudComputingstandards:OVF,CDMI,OCCI.OpenStackasanorganization(representedbytheOpenStackFoundation)isnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheOpenStackcommunity,especiallyindustrialmembers,maybeactiveinSSOs.
OpenvSwitch(OvS) OpenSourceSoftwareswitchdesignedtobeusedasavswitchinvirtualizedserverenvironments.OpenvSwitchhasalsobeenintegratedintovariouscloudcomputingsoftwareplatformsandvirtualizationmanagementsystems,includingOpenStack,OpenNebula…
OpenvSwitchsupportsstandardmanagementinterfaces(e.g.sFlow,NetFlow,IPFIX…),andisopentoprogrammaticextensionandcontrolusingOpenFlowandtheOVSDBmanagementprotocol.
OPNFV OpensourceprojectfocusedonacceleratingNFV'sevolutionthroughanintegrated,openplatform.
ThescopeofOPNFV’sinitialreleaseisfocusedonbuildingNFVInfrastructure(NFVI)andVirtualizedInfrastructureManagement(VIM)oftheETSINFVarchitecturalframework(ETSIGSNFV002)
OPTIMIS AtoolkitformanagingIaaSCloudsespeciallysupportinghybridClouds,CloudfederationandCloudbursting
OPTIMISsupportstwoCloudComputingstandards:OVFandWS-Agreement.MembersoftheOPTIMISprojectparticipatedinthedevelopmentofWS-AgreementNegotiationduringthelifetimeoftheproject.
OW2 TheOW2communityisengagedinseveralcloudcomputingprojectssuchasCompatibleOnecloudbroker,OpenCloudwaremulti-IaaSPaaS,XLCloudHPCcloudplatform,andOCCIware,aformalframeworkforthemanagementofanydigitalresourceinthecloud.
OW2facilitatesthedevelopmentofOpenSourceSoftwarewithastrongfocusoninfrastructuresoftwareandcloudcomputing.OW2isnotastandardorganizationbutencouragesitsmemberstotakepartinstandardworkgroups.OW2encouragesitsprojectstosupportopenstandardsandisstartingtohavesomeexperiencewithOCCI.
WSO2 HasdevelopedsoftwareforCloudenvironments,e.g.,theCloudGatewayforpublishingservicesanddatatotheCloudfrominsidetheenterprise.HasacommercialofferingforaCloudenvironment
WSO2supportstheOCCIandWS-Agreementstandards.WSO2asacommunityisnotparticipatinginthedevelopmentofstandards.However,individualmembersoftheWSO2communitymaybeactiveinSSOs
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 27
B.2 Standards usage summary table ThefollowingtableliststhesupporttostandardsfortheaboveselectedOpenSourceprojects.
Table3:Opensourceproductsadherencetostandards
Organization OVF CIMI CDMI OCCI WS-Agreement
CompatibleOneBroker
N/A No N/A Yes Yes
CloudStack N/A Yes N/A Yes NoEucalyptus N/A No N/A Yes NoNimbus N/A No N/A Yes No
OpenContrail Yes No (Yes) Yes YesOpenNebula Yes No Yes Yes NoOpenStack Yes (Yes)1 (Yes)2 (Yes)3 NoOPTIMIS Yes No No No YesWSO2 N/A No N/A (Yes) Yes
1(Yes)indicatesthatthereisnofullimplementationbutarudimentaryinterfaceonly.2OpenStacksupportsanumberofCloudComputingstandardsincludingOVF,CDMI,OCCI,butthissupportismostlyviaindependentopen-sourceadd-onprojects.ThecoreOpenStackcommunityhasclarifiedthatiftherewassufficientcommunitydesire,furtherstandardssupportcouldbeincorporatedintothecoreOpenStackprojects.Givenlimiteddevelopmentresources,itisessentiallyamatterofcommunitypriority.(seehttps://github.com/osaddon).
3Seehttps://wiki.openstack.org/wiki/Occiandhttps://github.com/stackforge/occi-os
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 28
Annex C: Interaction scenarios in practice in Cloud Computing
Thedescriptionofthescenariosintheprevioussectionhasraisedsomequestionsthatthissectionwishestoaddress.Todothis,wehaveselectedafewcasestudiesthatserveasamoreconcreteillustrationoftheopportunitiesandissuesraisedbythecollaborationofOpenSourcecommunitiesandSSOs.
C.1 Sharing specifications: NFV and OPNFV SomeofthescenariosabovearerelatedtotheimplementationbyanOpenSourcecommunityofoneormorespecifications(alreadyexistingorunderdevelopment)comingfromanSSO.ThequestionoftheadoptionofanemergingstandardbyanOpenSourcecommunityaddressedinscenario2canbeillustratedbytherelationshipbetweenNFV(anIndustrySpecificationGroupwithinETSI)andOPNFV(anOpenSourceOrganization).
C.1.1 Theactors
NFV(NetworkFunctionVirtualization)TheNFVISG(IndustrySpecificationGroup)wascreatedendof2012undertheauspicesoftheEuropeanTelecommunicationsStandardsInstitute(ETSI),inresponsetoacallforactionfromagroupofmajoroperators[1].NetworkFunctionsVirtualizationaimstotransformthewaythatnetworkoperatorsarchitectnetworksbyevolvingstandardITvirtualizationtechnologytoconsolidatemanynetworkequipmenttypesontoindustrystandardhighvolumeservers,switchesandstorage,whichcouldbelocatedinDatacenters,NetworkNodesandintheenduserpremises.ThefirstNFVISGoutputswerepublishedinOctober2013,includingausecasespecification[ETSINFVGS001],andanNFVArchitecturalFrameworkspecification[ETSINFVGS002]thatidentifiesNFVsystemcomponentsandtheinterfacesbetweenthem.ThenthesefirstoutputswerecomplementedwithnewdeliverablespublishedbyETSIinJanuary2015[2].Altogetherthisfirstspecificationphase(knownasNFVPhase1)setsthefoundationalconceptsandcreatesacommonvocabularyandarchitecturalframeworkwidelysharedintheindustry.TheETSINFVarchitecturalframeworkenablesVirtualizedNetworkFunctions(VNF)tobedeployedandexecutedonadistributedcarrier-gradecloudinfrastructureknownastheNFVInfrastructure(NFVI),whichconsistsofpoolsofcommodityhardwareresources(computing,storageandnetwork)wrappedwithasoftwarelayerthatabstractsandlogicallypartitionsthem.Inhypervisor-baseddeployments,aVNFistypicallymappedtooneVirtualMachine(VM)intheNFVIbutmayalsobesplitintomultipleVNFcomponents(VNFC)loadedonseparatevirtualmachines(e.g.withdifferentscalingrequirements).Thedeployment,executionandoperationofVNFsonanNFVIaresteeredbyaManagement&Orchestration(M&O)system,whosebehaviorisdrivenbyasetofmetadata(a.k.a.NFVdescriptors)describingthecharacteristicsofthenetworkservicesandtheirconstituentVNFs.TheM&OsystemincludesanNFVOrchestrator(NFVO)inchargeofthelifecycleofnetworkservices,asetofVNFmanagersinchargeofthelifecycleoftheVNFs(includingVNFscalingout/in)andaVirtualizedInfrastructureManager(VIM),whichcanbeviewedasanextendedCloudManagementSystemresponsibleforcontrollingandmanagingNFVIresources.AmajorchallengeremainstoachieveinteroperabilityforthekeyinterfacesidentifiedintheNFVarchitecturalframework.TheNFVPhase1specificationsarenotsufficienttomeetthisobjectiveastheyonlyprovideafunctionaldescriptionoftheseinterfaces,whileinteroperabilityusuallyrequiresthespecificationofaprotocoland/oranAPIandoftenadatamodel.OneofthemostimportantgoalsoftheNFVPhase2workprogramistoclosetheaforementionedinteroperabilitygapbyprovidingtherightlevelofspecificationsforthekeyinterfaces.Apre-requisitetoanyprotocolorAPIspecificationworkistocompletethefunctionaldescriptionoftheseinterfacesidentifiedduringNFVPhase1.Oncethisstepisdone,afollow-upspecificationphaseshouldleadtoaprotocolspecification,presumablyintheformofaprofileof–oranextensionto–anexistingbasestandard.Onekeytaskwillbetoselectthemostappropriatebasestandardperinterface.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 29
CloselyrelatedtointeroperabilityaretheVNFportabilityandVNFmigrationtopics.PortabilityreferstotheabilitytodeployaVNFondifferenttypesofservers,whenlivemigrationreferstotheabilitytomoveanactiveVNFinstancefromoneservertoanotherwhileensuringservicecontinuity.OneoftheworkitemsforNFVPhase2willbethespecificationofasetofinterfacesenablingtheVNFCcodetoaccessaccelerationservicesprovidedbytheinfrastructure,inanimplementation-independentmanner.AnotherprospectiveworkitemforNFVPhase2isareportthatstudiestheinternalarchitecturalstructure/physicalcomponentsofanNFVINodeandprovideasetofguidelinestosupportanNFVenvironment.Thegoalistofacilitatetheavailabilityofthesecomponentsinamulti-vendorenvironment.Besides,thepublicationofareportontheroleofsoftware-definednetworking(SDN)intheNFVarchitecturalframeworkisexpected. OPNFV(OpenPlatformforNFV)TheOpenSourceOpenPlatformforNFV(OPNFV)initiative,ledbytheLinuxFoundation,waslaunchedonthe30thSeptember2014withtheparticipationofseveralITandtelecomvendorsandtelecommunicationsserviceproviders[3].TheobjectiveofOPNFVistoprovideareferenceinfrastructureplatformforNetworkFunctionsVirtualization(NFV).Therefore,largepartsoftheOPNFVarchitecturearedirectlyrelatedtothearchitectureoutlinedinthedocumentsprovidedbyETSIISGNFV.Tostartwith,OPNFVaddressesanintegratedsolutionforNFVIandVIMcomponentsoftheETSINFVarchitecturethattogetherbuildtheinfrastructurelayeroftheNFVframework.Toachievethisgoal,OPNFVwillworkinclosecollaborationwithanumberof“upstream”OpenSourceinitiatives(e.g.OpenStack,OpenDayLight,KVM,OVS…).Inadditiontocodedevelopment,OPNFVincludesanumberofrequirementsprojectsbutalsointegrationandtestingprojects.OPNFVwillexecuteonareleasecadenceofareleaseapproximatelyeverysixmonths.OPNFVRelease1‘ARNO’wasdeliveredinJune2015.ThisfirstOPNFVreleaseincludesthefollowingexistingOpenSourcecomponents(see[i.9]):
• OpenStackReleaseJuno;• OpenDaylightReleaseHeliumforNetworkcontrol;• CephobjectstorageorchestratedbyCinder;• OVSforvirtualswitch;• KVMhypervisorforVirtualMachine.
C.1.2 Workingtogether:opportunities,issues
Attheformallevel,thecurrenttypeofpartnershipengagementiscalled“LetterofIntent"(LoI)allowingthecooperationbetweenETSIandOPNFV[6].ThisestablishesaformalcontactbetweenETSIwithOPNFVandservestoexchangeoperational/promotionalinformationandtoidentifycommonroadmaps.Theintentionistoco-operateinthestandardizationeffortsintheareaofNFVandtoworktogetherforpromotingandencouragingfurtherengagementbetweentherespectivecommunities.Forthispurpose,thepartiesmayseektoencourageanddevelopcollaborativeactivitiesinvariousways,includingtheexchangeofideasandexpertise. Inpractice,itisclearthatkeepingeachorganizationabreastofdevelopmentsofjointinterestischallenging,giventhequitedifferentgovernanceprocessesofETSINFVISGandOPNFV.Asamatteroffact,thedevelopmentofmanyrequirementsprojectsinOPNFVoverlapswithETSINFV.OneoftheimportantgoalsoftheETSINFVphase2workprogramistoprovidefunctionalspecificationsforthekeyinterfacesoftheNFVarchitecturalframework.OPNFVcouldbeconsideredasprovidingde-facto‘specifications’fortheNFVInfrastructureanditsmanager(VIM)whilemoreconventionalstandardsarelikelytobedevelopedbyETSINFVand/orotherSDOsforotherNFVmanagementandorchestrationinterfaces.However,itislikelythatOPNFVwilldevelopthe“de-facto”‘specifications’fortheNFVInfrastructureanditsmanagerfromthedeliverablesofitsownrequirementsprojectsratherthanfromETSINFVspecifications.Moreover,somerecentlyagreedOPNFVrequirementsprojectsareaddressingothermanagementandorchestrationinterfacesaswell,therebyincreasingtheriskofseeingafragmentationoftherequirementsspecificationsintheindustry.
C.2 OpenSourceandStandards:OpenStackOpenSourceOrganizationsdeveloptheirprojectswiththeirowndynamics.TheirrelationshipwithStandardsSettingOrganizationsmayormaynotexist(dependingonthescenario).ThefollowingsectioninvestigatesthecaseofOpenStackasanexampleofScenario5("AnOSSorganizationimplementsReferenceAPIs").
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 30
C.2.1 The actors OpenStackOpenStack(http://www.openstack.org)isanOpenSourceCloudComputingsoftwarethatprovidesinfrastructureasaservice(IaaS)ClouddeploymentforpublicandprivateClouds.OpenStackwasfirstintroducedinJune2010,bornwithitsinitialcodefromNASA’sNebulaplatformandRackspace’sCloudFilesplatform.Today,theOpenStackprojectismanagedbytheOpenStackFoundationestablishedinSeptember2012.TheOpenStackFoundationisanindependentbodyprovidingsharedresourcestohelpachieveOpenStackmissionbyempowering,protectingandpromotingOpenStacksoftwareandthecommunityarounditincludingusers,developersandtheentireecosystem.OpenStackcommunitywithmorethan500supportingcompaniesishavingaroundsix-monthreleasecycleandtillnowOpenStackhasreleasedelevenmajorOpenStackreleasesfromAustininOctober2010toKiloinApril2015.OpenStackisorganizedaroundthreemainmodulesi.e.compute,storageandnetworking.Alongwiththesethree,dashboardisanotherimportantcomponentprovidinginterfacetoadministratorsandusersforprovisioningandreleaseofresources.Thesecomponentsinteractwithuser’sapplicationandunderlyinghardwareoverwhichotherOpenStackservicesrun.OpenStackCompute(Nova)hasanabstractionlayerforcomputedrivers.Thisiswhatallowschoosingwhichhypervisor(s)touseforanyOpenStackcomputedeployment.OpenStackprovidesanIaaSsolutionthroughasetofinterrelatedservices.EachserviceoffersanApplicationProgrammingInterface(API)(see[i.11])thatfacilitatesthisintegration.TheseRESTfulAPIsandOpenStackcurrentlyconsistofseveraldifferentservicecodeprojectstomakeitmodular,eachhavingitsdifferentcodenamefortheproject.ThiscodenamedescribesthedifferentmodulesofOpenStackandtheirconfigurationfilesrespectively.EachOpenStackprojectalsoprovidesacommand-lineclient,whichenablesaccessingtheprojectAPIthrougheasy-to-usecommands(seehttp://docs.openstack.org/cli-reference/content/).ThefollowingtabledescribestheOpenStackservicesthatprovidetheOpenStackarchitecture.
Table4:OpenStackservicesinsupportofOpenStackarchitecture
Service Codenameofproject
Description
Dashboard Horizon Providesaweb-basedself-serviceportaltointeractwithunderlyingOpenStackservices.
Compute Nova Managesthelifecycleofcomputeinstances.
Networking Neutron EnablesNetwork-Connectivity-as-a-Service.
ObjectStorage Swift StoresandretrievesarbitraryunstructureddataobjectsviaaRESTful,HTTPbasedAPI.
BlockStorage Cinder Providespersistentblockstoragetorunninginstances.
Sharedservices
Identityservice Keystone ProvidesanauthenticationandauthorizationserviceforotherOpenStackservices.
Imageservice Glance Storesandretrievesvirtualmachinediskimages.
Telemetry Ceilometer MonitorsandmeterstheOpenStackcloudforbilling,benchmarking,scalability,andstatisticalpurposes.
Higher-levelservices
Orchestration Heat Orchestratesmultiplecompositecloudapplicationsbyusingtemplates.
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 31
Databaseservice Trove ProvidesscalableandreliableCloudDatabase-as-a-Servicefunctionalityforbothrelationalandnon-relationaldatabaseengines.
Dataprocessingservice
Sahara ProvidescapabilitiestoprovisionandscaleHadoopclustersinOpenStack.
DistributionsTherearemanywaystoinstallanddeployOpenStackthroughsoftwaredistributions.TheOpenStackMarketplaceincludesalistofcommercialsoftwaredistributionspoweredbyOpenStack.Inadditiontocommercialofferings,OpenStackisalsoincludedwithseveralnon-commercialLinuxdistributions.
C.2.2 Support of standards ThedevelopmentoftheOpenStacksoftwarethroughitsthighreleasecyclesisakeyelementoftheoutputoftheOpenStackcommunity.Amongstthedecisionsthathavetobetakenfortheproduct,thechoiceofwhichCloudComputingstandardwillbesupportedisimportant.MoreinformationregardingthesupportofCloudComputingstandardsbyOpenStackandotherimportantCloudComputingOpenSourceprojectscanbefoundinAnnexB.
C.3 Distributed Management Task Force (DMTF) C.3.1 DMTF Standards
DMTF(www.dmtf.org)developsstandardsthatenablethemanagementofdiversetraditionalandemergingtechnologiesincludingCloudComputing,virtualization,networkandinfrastructure.RegardingCloudComputing,DMTFhasproducedseveralspecificationsincluding:
• DSP0243,OpenVirtualizationformat(OVF).OVFisacommonpackagingformattopackageandsecurelydistributevirtualappliances.Thisenablesportabilityofvirtualappliancesacrossmultiplevirtualizationplatformsandproducts.OVFisapackagingstandardandnotaruntimestandard.AnOVFpackagecontainsoneormoreimagefiles,an.ovfXMLmetadatafilethatcontainsinformationaboutthevirtualmachine,andpossiblyotherfilesaswell.OVFdoesnotdictateanyparticulardiskformat(e.g.VHD,VMDK,VDI,QCOW2...)tobeused.AnOVFpackagecanbedistributedindifferentmanners.Forexample,itcanbedistributedasasetofdiscretefiles,orasatararchivefilewithan.ova(openvirtualappliance/application)extension.
• DSP0263,CloudInfrastructureManagementInterface(CIMI).CIMIisaself-serviceIaaSmanagementinterface,allowingCloudcustomerstodynamicallyprovision,configureandadministertheirCloudusageusingahighlevelinterfacethatabstractsawaymuchofthecomplexityofsystemsmanagement.TheinterfaceusestheHyperTextTransferProtocol(HTTP)tosendandreceivemessagesthatareformattedusingeitherJavaScriptObjectNotation(JSON)ortheeXtensibleMarkupLanguage(XML).
• DSP0262,CloudAuditDataFederation(CADF).TheCloudAuditDataFederationspecificationdefinesanormativeeventdatamodelalongwithacompatiblesetofinterfacesforfederatingevents,logsandreportsbetweenCloudprovidersandCloudcustomers.Morethanaformat,theCADFstandarddefinesafulleventmodelanyonecanusetofillintheessentialdataneededtocertify,self-manageandself-auditapplicationsecurityinCloudenvironments.
OVFandCIMIareadoptedasInternationalStandards,respectivelyISO/IEC17203andISO/IEC19831.
C.3.2 DMTF standards and OpenStack TheobjectiveofthisclauseistolookathowtheOVF,CIMIandCADFstandardsdevelopedbyDMTFhavebeenadoptedinmajorOpenSourceprojects,i.e.OpenStackandCloudStack.NotethatDMTFhasrecentlyenteredintoanAlliancePartnerrelationshipwiththeOpenStackFoundation(http://www.dmtf.org/sites/default/files/OpenStack-DMTF-WR-1_1.pdf).BothDMTFandOpenStackarecommittedtocross-bodycollaboration,integratingexisting
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 32
standardstoenhanceinteroperabilityforthegoodoftheindustry.ThisrelationshipinitiallyfocusesonstandardscriticaltoCloudsecurity,improvingcloudauditabilitytoaccelerateenterpriseadoption.OVF:TheOpenStackImageServiceprovidesdiscovery,registrationanddeliveryservicesfordiskandserverimages.WhenaddinganimagetoOpenStackGlance,thevirtualmachineimage’sdiskformatandcontainerformatmustbespecified.Thediskformatofavirtualmachineimageistheformatoftheunderlyingdiskimage.Thecontainerformatreferstowhetherthevirtualmachineimageisinafileformatthatalsocontainsmetadataabouttheactualvirtualmachine.BothOVFandOVAcanbespecifiedasvaluesforthecontainerformat.
CIMI:OpenStackdoesnotsupporttheDMTFCIMIspecification.CIMIonOpenStackNovaprojectinGithub(https://github.com/osaddon/cimi)wasstartedwiththegoalofaddingthesupportofCIMItoOpenStack.Howeverthishasseennoactivitysince2012andwouldneedtobeupdatedtothelatestversionofOpenStack.ApartfromOpenStack,CIMIhashadseveralopensourceprojectsimplementingpartsofitsuchasDeltaCloudandOW2SiroccoprojectsprovidingaproxysystemwithCIMIasthetopAPIandsupportformultiplebackend-clouds.
CADF:CADFiscurrentlyimplementedinpyCADF(https://github.com/openstack/pycadf):APython-basedCADFLibrary,usedbyOpenStack.DMTFDSP2038definesaCADFrepresentationforusewiththeOpenStackCloudManagementPlatform.
References• DMTFDSP0243:OpenVirtualizationFormatSpecification• DMTFDSP0262:CloudAuditingDataFederation(CADF)–DataFormatandInterfaceDefinitionsSpecification• DMTFDSP0263:CloudInfrastructureManagementInterface(CIMI)ModelandRESTfulHTTP-basedProtocol• DMTFDSP2038:CloudAuditDataFederation–OpenStackProfile(CADF-OpenStack)
Annex D: Change History
Date Version Information about changes July2015 1.0.0 FirstpublicationoftheSRforcomments
October2015 2.0.0
Finalpublicationbasedonthechangesprovidedby:-CommentsfromtheNTECHTechnicalCommitteereview-Commentsfromthepublicreviewgatheredonhttp://csc.etsi.org-Additionalchangesproposedduringthefinalreviewworkshop
History Documenthistory
V0.9.0 30/06/2015 DraftforSTFreview.IncorporatesallthecontentalreadydevelopedwithintheSTFintotheappropriatetemplate.
V0.9.1 2/07/2015 Statusofdocumentafterthereviewmeetingon2/07/2015
V0.9.2 23/7/2015 Statusofdocumentafterthereviewmeetingon24/07/2015
V0.9.3 24/07/2015 Statusofdocumentimmediatelyafterthereviewmeetingon24/07/2015
V0.9.99 27/07/2015 Documentforfinal"sanitycheck"beforepublicationon27/07/2015Incorporatesthechangesdecidedduringthereviewmeetingon24/07/2015
V1.9.0 12/10/2015 IncorporatesthechangesdecidedduringtheReviewWorkshopinBrusselson02/10/2015forreviewbytheSTFteam.
V1.9.1 13/10/2015 IncorporatesthechangesagreedduringtheSTFteammeeting
V1.9.2 14/10/2015 AdditionalchangesandalignmentwithotherSTFreports
ETSI
ETSI SR 003 382 V2.0.0 (2015-11) 33
V1.9.8 16/10/2015 For"sanitycheck"(nofurthercommentsallowed)bythereviewersandtheSTFteam
