An Operator’s Perspective On NFV Standardization Progress

An operator’s perspective on NFVstandardization progressBruno CHATRAS, Orange, ETSI NFV ISG Vice-Chairman1

NFV is now a 4-year old concept!The seminal white paper on Network FunctionsVirtualisation (NFV) signed by 13 network operatorswas published at the ONS conference in Darmstadtin October 2012.The first meeting of the ETSI Industry SpecificationGroup (ISG) on NFV was held in January 2013. Today, the ISG membership has grown over 290companies.2

Network Functions Virtualisation in a NutshellRelocating network functions from dedicated appliances to pools of generic industry servers,leveraging:-Cloud Computing Technology-Virtualisation Technologies-Advances in general purpose processors performanceVirtualisedNetwork FunctionAutomated installation& lifecycle managementPhysicalNetwork Function3-Software imagesMetadatadistributed pools of commodity server

Transforming NFV promises into realityis conditional on industry progress on Interoperability Emergence of Cloud-Native Network Functions Tackling Operational ChallengesHow can Standards help the industrymake progress on these items?4

ETSI NFV Specification Releases2016-20182015-2017Release 22013-2014Release 3OperationalizingNFVLooking forinteroperabilityRelease 1Setting theconceptsPoCs5TrialsLarge-scale deployments

How can Standards help? Interoperability Emergence of Cloud-Native Network Functions Tackling Operational Challenges6

Primary interoperability goalVirtualised Network Functions (VNFs) must beApplicationManagementInteroperable with independently developedmanagement systems.VNFsVNFsVNFsRequirements1/ Standard Interfaces2/ Standard VNF PackagingNFVInfrastructureNFVManagement and OrchestrationIndependent from the underlying infrastructurethereby permitting independent hardware andsoftware upgrades, and portability.VNF Virtualised Network Function7

Another interoperability goalNFV Management and Orchestrationfunctions must be interoperable withindependently developedNFV infrastructures and applicationmanagement systems.It must be possible to create an NFVManagement and Orchestration systemfrom independently NFsNFVInfrastructure8NFVO: NFV OrchestratorVNFM: VNF ManagerVIM: Virtualised Infrastructure ManagerNFVOVNFMVIM

NFV Management and Orchestration standardizationThe 2nd Release of ETSI NFV specifications so far includes:A set of protocol-independent specifications of the interfaces exposed on the referencepoints of the NFV Management & Orchestration framework (NFV-MANO).Language-independent specifications of NFV descriptors (a.k.a. deployment templates).Also known as“Stage 2” specificationsIFA0XY ETSI GS NFV-IFA 0XY9

AttributeDual-form “Stage 2” specificationsTabular form & UML .NNot specifieddefaultLocalizationLanguageM0.1Not mputeDescDescriptionIdentifier of this VNFD informationelement. This attribute shall beglobally unique. The format will bedefined in the data model specificationphase. See note 1.Provider of the VNF and of the VNFD.Name to identify the VNF Product.Invariant for the VNF Product lifetime.Software version of the VNF. This ischanged when there is any change tothe software that is included in theVNF Package.Identifies the version of the VNFD.Human readable name for the VNFProduct. Can change during the VNFProduct lifetime.Human readable description of theVNF Product. Can change during theVNF Product lifetime.Identifies VNFM(s) compatible with theVNF described in this version of theVNFD.Information about localizationlanguages of the VNF (includes e.g.strings in the VNFD). See note 4.Default localization language that isinstantiated if no information aboutselected localization language isavailable.Shall be present if“localizationLanguage” is present andshall be absent otherwise.Virtualisation Deployment Unit. Seeclause 7.1.6.Defines descriptors of virtual computeresources to be used by the VNF. Seeclause 7.1.9.2.2.

The road to interoperabilityApproval of the ETSI GS NFV-IFAspecifications was a major step towardsenabling interoperability betweenManagement & Orchestration functionsVNFs and Management & Orchestrationfunctions and VNFsBut further steps are required11InteroperabilityHoly Grail

The role of standards on the road to interoperability“Stage 2” specifications are not sufficient to enable a truly open ecosystem.Multiple incompatible solutions can be derived while being functionally compatible, e.g.Interfaces: REST vs. Non-REST solutions, REST variants (e.g. TMF vs OMA-style)Descriptors: TOSCA vs. YANG representation of the VNF Descriptor, and multiple variants are possible ineach case Open Source communities cannot solve the problem alone unless there is only one community!According to a survey carried out by the ETSI NFV NetworkOperators Council (NOC) over the summer of 2016, the 2ndreason why ETSI NFV should engage in “Stage 3 work is thatOpen Source is not considered sufficient to guaranteeinteroperability .12

Activities of the ETSI NFV Solutions (SOL) Working GroupOngoing workoSpecification of a set of REST APIsapplicable to the VNFM – NFVOreference point): SOL003oSpecification of a set of REST APIsapplicable to the VNFM – VNF/EMreference points: SOL002oSpecification of a TOSCA profile forthe VNFD and NSD: SOL001Next to come13oSpecification of a set of REST APIsapplicable to the OSS-NFVO referencepoint.oSpecification of a VNF PackagingFormat.

Milestones for publicationREST Protocols/APIsTOSCA-basedNFV descriptors14A VNFD-only versionmight be available before

Interoperability between VNFs and NFV infrastructure: The portabilitychallengeMany VNFs need to be “accelerated” to deliver high performance will running on COTS servers.Hardware acceleration is a widespread solution,which today creates dependencies betweenthe VNF and the underlying hardwareExampleThe VNF is a Diameter Routing AgentIPSec processing is off-loaded to anenhanced Network Interface Card (NIC)The VNF software communicates with the NICusing a proprietary API, specific to the card model.15PortabilityPerformance

The Pass-through modelDependencies have to be specified in the VNF Descriptor,by the VNF provider.Restricted ability to move the VNF from one server toanother.16

Towards a solutionUnder standardization in ETSI GS NFV-IFA 002Open source implementations in OPNFV DPACC17

How can Standards help? Interoperability Emergence of Cloud-Native Network Functions Tackling Operational Challenges18

Cloud-native / Cloud-ready VNFsToday, these are “marketing” terms referring to a VNFwhose software has been (re-)designed to get the mostfrom the Cloud-based nature of the NFV technology, asopposed to just porting existing network applications toCOTS servers.Sometimes also advocates a Microservice design style,entering aspects not directly related to virtualisation, e.g.Focus on a single capability (i.e. “do a single thing well”motto)A set of guidelines developed and agreed by the NFVcommunity would be welcomed.19

Cloud-native / Cloud-ready VNFsExample guidelinesDesign small VNFs or VNF Components to enable fastinstantiation and increase resource utilizationInclude a “load balancing” VNF Component to facilitate scalingand resilienceMinimize the number of stateful VNFCs within a VNF, to facilitateresilience.Minimize coupling between VNF Components to facilitate partialupgradesDesign for failure (internal redundancy, synchronizationmiddleware between stateful VNF Components, etc.)ChallengesNo one-size-fits-all solutionShould not hinder vendor differentiation20

How can Standards help? Interoperability Emergence of Cloud-Native Network Functions Tackling Operational Challenges21

Operationalizing NFVAddressing considerations related to licensing, accounting andchargingConsistent operational integration with connectivity servicesManaging Management & Orchestration systemsConsolidating security mechanismsAddressing E2E automationSupporting multi-domain (incl. multi domain orchestration) andmulti-tenancy scenariosMaintaining service availability and continuity whenupdating/upgrading softwareAddressing troubleshooting solutionsSpecifying hardware requirementsIntegrating policy management in NFV Management &Orchestration22

Hardware requirementsSpecification of requirements to enableinteroperability of equipment in thetelecommunications environment to supportNFV deployment. The focus includes thefollowing areas: Operations Environmental Mechanical Cabling Maintenance.Specification of requirements for the supportof lawful intercept and/or critical nationalinfrastructures.23ETSI GS NFV-EVE 007: Specification on NFVI NodePhysical Architecture - Multi-Vendor InteroperabilityRequirements.To be approved: 2017Q1

Software UpgradeService providers are looking for Software Update/Upgrade solutions such that service availabilityand continuity is maintained.Software update in conventional networks typically implies reduced redundancy during upgradeprocess and/or upgrade can only take place during off-peak periods No failover possibility whileswitching over.NFV provides an opportunity for a better approach.Guidance and Best Practices available in GS NFV-REL 002 & GS NFV-REL 003 (published)A new work item has been launched to specify requirements on software update.The scope covers all types of software related to NFV: VNFs, MANO and NFVI.24ETSI GR NFV-REL 006:Specification for maintaining service availability and continuitywhen updating/upgrading softwareTo be published: June 2017

VNF Software Upgrade principleSoftware upgrade should be done in a gradual and revertible waye.g. upgrade a fraction of the whole capacity, a certain service type or a certain user group, with theconstraint of preserving the service availability and service onOldversionTrafficTypically requires an SDN controller to direct an increasing% of the traffic to the new version.25

License ManagementToday: Vendor specific licensesmanagement and lack of processautomation for service provisioning andlicence renewal/updates.Flexible deployment requires flexiblelicense management (e.g. in case of autoscaling).A new study has been launched in ETSI toidentify the features needed to supportlicense management for NFV and theirimpact on Management and Orchestrationfunctions.26ETSI GR NFV-EVE 010:Report on License Management for NFVTo be approved: June 2017

Management & Orchestration functionsneed to be managed and reliable as well NFVOManagementAutomated deployment of new instances, including automatic discovery of new peersConfiguration of Management & Orchestration functions according to operator’s policiesFault Management and Performance Management of Management & Orchestration functionsIn-service software updateReliabilityAutomated failover/recoveryRedundancy models to avoid single points of failure and/or distribute the loadStand-alone mode of operation for the VIM and VNFM in case of NFVO failure27ETSI GR NFV-IFA 021:Report on Management of MANO functions To be approved: January 2017

Addressing E2E automation: The missing linkFor a VNF to become fully operational, theembedded network application needs to beconfigured and managed.OtherOperationsSupportSystemsEMWhen a new VNF is being deployed,an Element Manager (EM) needs to be deployedas well in an automated way.VNFNFVManagement &Orchestrationfunctionsorthe VNF needs to be manageable throughgeneric EM functionality embedded in the OSSNFVInfrastructureQuite a challenge!28ETSI GR NFV-IFA 021:Report on management of NFV-MANO and automateddeployment of EM and other OSS functions To be approved:January 2017

Typical solutions for automated EM deploymentDeploy EMs as special components of these VNFs or as additional VNFs.VNFVNFCANSVNFC« EM »VNFCBVNFCCVNF« EM »VNFAVNFBVNFCFull deployment automation also requires that standard interfaces to the OSS beavailable.Interface configuration templates can be embedded in the VNF Package to allow forsome degree of per-VNF customization.29

How can Standards help? Interoperability Emergence of Cloud-Native Network Functions Tackling Operational Challenges30