An Operator’s Perspective On NFV Standardization Progress

3y ago
1.31 MB
33 Pages
Last View : 1d ago
Last Download : 5m ago
Upload by : Wade Mabry

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

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

By way of conclusion: What about the relation to 5G?Network SlicingNFV network services can be regarded as means to implement network slices (e.g. one networkslice supported by one or more concatenated or nested network services, possibly deployed indifferent administrative domains).MobilityThe ability to move virtualisation containers – and thus VNFs - across locations opens the door tonew thinking around mobility management, e.g. services can follow their users to optimizeperformance and latency.Cloud NativeCloud-readyness and the Microservices design style should be a source of inspiration for the designof both the 5G functional architecture and the software architecture of 5G network functions 31

Further detailsETSI NFV Technology Web (Drafts n32

Thank you33

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. ETSI GR NFV-REL 006:

Related Documents:

1. Teaching with a Multiple-Perspective Approach 8 . 2. Description of Perspectives and Classroom Applications 9 . 2.1 Scientific Perspective 9 . 2.2 Historical Perspective 10 . 2.3 Geographic Perspective 11 . 2.4 Human Rights Perspective 12 . 2.5 Gender Equality Perspective 13 . 2.6 Values Perspective 15 . 2.7 Cultural Diversity Perspective 16

One Point Perspective: City Drawing A Tutorial Engineering 1 Tatum. When completing this tutorial, you must use the following items: * White, unlined paper * A ruler or other straight-edge * A pencil. Begin by setting up your paper for a one-point perspective drawing. Draw a horizon line and a vanishing point. Draw two orthogonals (diagonal .File Size: 727KBPage Count: 41Explore furtherOne point perspective city: The step by step guide .pencildrawingschool.comHow to Draw One Point Perspective City Printable Drawing .www.drawingtutorials101.comOne Point Perspective Drawing Worksheets - Learny Kidslearnykids.comPerspective Drawing - An Easy Lesson in 1 Point .www.drawinghowtodraw.comThe Helpful Art Teacher: Draw a one point perspective city .thehelpfulartteacher.blogspot.comRecommended to you b

Independent Personal Pronouns Personal Pronouns in Hebrew Person, Gender, Number Singular Person, Gender, Number Plural 3ms (he, it) א ִוה 3mp (they) Sֵה ,הַָּ֫ ֵה 3fs (she, it) א O ה 3fp (they) Uֵה , הַָּ֫ ֵה 2ms (you) הָּ תַא2mp (you all) Sֶּ תַא 2fs (you) ְ תַא 2fp (you

One-Point Perspective Cityscape. One-Point Perspective Room. One-Point Perspective Room. One-Point Perspective Hallway. Atmospheric Perspective is the technique of creating an illusion of depth by depicting distant objects as p

CCS Debug perspective is used for execution and debugging of code on the customer EVM. To switch to the CCS Debug perspective, click on Window Perspective Open Perspective CCS Debug (See Figure 2). Figure 1.3.1: Changing the CCS Perspective The current perspective can be seen in the upper right corner of the CCS window, as shown in

Asphalt Plant Engineer Batch Plant Operator Bit Sharpener Concrete Joint Machine Operator (canal and similar type) Concrete Placer Operator Concrete Planer Operator Dandy Digger Deck Engine Operator Deck Engineer Derrickman (oilfield type) Drilling Machine Operator, Bucket or Auger types (Calweld 100 bucket or similar types - Watson 1000

PERSPECTIVE : Perspective is used by artists to create the illusion of depth and distance in a painting or drawing. Creating 3D effects on a 2D surface like paper, wood, wall space or canvas is made possible with the use of perspective. Urban artists make strong use of perspective in their lettering and illustrations.

point perspective. (This objective supports SM Task 113-579-1026, Draw Subjects in Perspective.) Lesson 2: DRAW OBJECTS IN TWO-POINT PERSPECTIVE TASK: Describe the components of two-point perspective. CONDITIONS: Given information and examples about