Network Functions Virtualisation

Transcription

1 Network Functions Virtualisation State-of-the-art and outlook CLOUD DAYS September 2017 Bruno CHATRAS, Orange, ETSI NFV ISG Vice-Chairman 1

2 Agenda State Of the Art Technical challenges and path forward? Gartner Hype Cycle 2

3 NFV is nearly a 5-year old concept now! The seminal white paper on Network Functions Virtualisation (NFV) signed by 13 network operators was published at the Open Networking Summit (ONS) in Darmstadt in October The first meeting of the ETSI Industry Specification Group (ISG) on NFV was held in January Today, the ISG membership has grown over 300 companies. 3

4 Network Functions Virtualisation in a Nutshell Relocating network functions from dedicated appliances to pools of generic industry servers, leveraging: - Cloud Computing Technology - Virtualisation Technologies - Advances in general purpose processors performance Physical Network Function Automated installation & lifecycle management Virtualised Network Function - Software images - Metadata 4 distributed pools of commodity server

5 ETSI GS NFV 002 The ETSI NFV architectural framework Management of the service provided by the VNF NFVI EM 1 VNF 1 (other) OSS/BSS functions Vn-Nf EM 2 EM 3 VNF 2 VNF 3 Os-Ma Ve-Vnfm NFV Orchestrator (NFVO) Or-Vnfm VNF Manager(s) (VNFM) Vi-Vnfm Lifecycle management of Network NFV Management Services & Orchestration (MANO) Network Service Descriptors (NSD) and VNF Descriptors (VNFD) Lifecycle management of VNF instances Hypervisors, Network/SDN 5 controllers Virtual Computing Computing Hardware Virtual Storage Virtualisation Layer Vl-Ha Storage Hardware Virtual Network Network Hardware Nf-Vi Virtualised Infrastructure Manager(s) (VIM) Or-Vi Allocation and management of the NFVI resources

6 Where is the Industry today? NFV is still at an early stage of adoption, with 2016 marking the transition from proof of concepts (PoCs) to production-ready solutions. Telecommunication service providers are busy dealing with the challenges faced with their first commercial deployments These challenges are causing a market collective pause in the exponential growth originally foreseen. 3 main areas of concern 1. Lack of interoperability between the components of an NFV system 2. Commercial tools for full automation of service lifecycle management not available 3. Very few cloud-ready VNFs (i.e. many VNFs not designed to take the full benefits of a cloud-based deployment) 6

7 The reality of NFV Use Cases vcpe emerges as Top NFV deployment use cases, especially on the enterprise market Perceived as a quick-win by many enterprise and operators, decreasing capex and increasing operational efficiency through automation. Most VNFs are replacements of already fielded network functions e.g. virtual mobile packet core network or virtual VoIP equipment Brand new VNFs will appear with 5G deployments and will bring additional requirements 5G networks are anticipated to take advantage of Cloud-native principles for the design of some of their network functions (e.g. to facilitate scaling and healing) 7

8 NFV: A good fit for 5G networks! Network Slicing: NFV network services provides the technical means to implement network slices. Mobility: The ability to move virtualisation containers and thus VNFs - across locations opens the door to new thinking around mobility management, e.g. services can follow their users to optimize performance and latency. Cloud Native: Cloud-ready VNFs is the key to provide the agility, performance and reliability levels expected from 5G systems. 8

9 Network Slicing vs. NFV technology Selected requirements from 3GPP TS Service requirements for next generation new services and markets. Requirements The 3GPP system shall allow the operator to create, modify, and delete network slices. The 3GPP system shall allow the operator to define the set of services supported in a network slice. The 3GPP system shall support the dynamic adaptation of capacity, i.e. elasticity of a network slice. The 3GPP system shall ensure that elasticity of one slice has no impact on services delivered by other slices. Supporting NFV feature Network Service Lifecycle Management Supported by an OSS-embedded slice control functionality acting as an NFV Orchestrator service consumer. Network Service scaling Isolation mechanisms inherent to virtualisation technologies, virtualised resource quota management and permitted allowance. 9

10 Architectural work ongoing in 3GPP and ETSI ETSI GR NFV-EVE 012: Report on Network Slicing Support with ETSI NFV Architecture Framework. 3GPP TR : "Study on management and orchestration of network slicing for next generation network". 10

11 Transforming NFV promises into reality is conditional on progress in NFV standardization and open source development. Consumer Standardization bodies NFV Framework NFVRG Research ISG NFV Requirements Supporting Standardization bodies Open Source communities 11

12 ETSI NFV Specification Releases Release 2 Looking for interoperability Release 3 Operationalizing NFV Release 1 Setting the concepts 12 PoCs Trials Large-scale deployments

13 A closer look at the Open Source landscape for NFV OSS NFVO VNFM NFVI VIM 13

14 Agenda State Of the Art Technical challenges and path forward Interoperability Cloudreadiness Full automation 14

15 Primary interoperability goal Virtualised Network Functions (VNFs) must be Independent from the underlying infrastructure thereby permitting independent hardware and software upgrades, and portability. Interoperable with independently developed management systems. Requirements 1/ Standard Interfaces 2/ Standard VNF Packaging Application Management VNFs VNFs VNFs NFV Infrastructure NFV Management and Orchestration 15 VNF = Virtualised Network Function

16 Another interoperability goal NFV Management and Orchestration functions must be interoperable with independently developed NFV infrastructures and application management systems. It must be possible to create an NFV Management and Orchestration system from independently developed components. Application Management VNFs VNFs VNFs NFVO VNFM NFV Infrastructure VIM 16 NFVO: NFV Orchestrator VNFM: VNF Manager VIM: Virtualised Infrastructure Manager

17 VNF Packaging A VNF Package is a Cloud Service ARchive (CSAR) A CSAR file is a ZIP file with a well-defined structure. The structure and format of a VNF package shall conform to the TOSCA Simple Profile YAML v1.1 Specification of the CSAR format. The VNFD (VNF descriptor) is the main TOSCA definitions YAML file inside the archive. References: ETSI GS NFV-SOL

18 CSAR file example This is the VNFD (contains the infrastructure requirements)!------tosca-metadata!------tosca.meta!------definitions!----- MRF.yaml!----- Other Templates!------Files!----- ChangeLog.txt!----- MRF.cert!----- image(s)!----- other artifacts!------tests 18 Manifest file (contain digests of individual files)!----- file(s)!------licenses!----- file(s)!------scripts!----- install.sh!----- MRF.mf

19 Compute Storage Internal CPD SW image Descr The VNF Descriptor (VNFD) The VNFD provides all information needed for deploying the VNF: Amount of resources needed (Virtual Compute, Storage, Networking) Internal topology and external connectivity Affinity / anti-affinity rules between VNF components Software metadata Lifecycle management behaviour (e.g. automatic scaling) Other constraints (e.g. acceleration capabilities) VNFD VDU Internal VLD Major open issue for interoperability The list of VNFD parameters is specified in ETSI GS NFV-IFA 011. The actual encoding will be based on TOSCA / YAML but the details are still under discussion between ETSI and OASIS TOSCA See: 19 External CPD Deployment Flavour

20 APIs for Management and Orchestration Completed work in ETSI o Specification of a set of RESTful APIs applicable to the VNFM NFVO, and VNFM VNF/EM reference points. The ETSI architectural framework identifies a number of reference points, on which several interfaces are produced. 1 interface = 1 API Ongoing work in ETSI o o Specification of a set of RESTful APIs applicable to the OSS-NFVO reference point. Analysis of the gap between functional requirements applicable to the VIM northbound interfaces and Open Stack APIs 20

21 REST (Representational State Transfer) design applied to ETSI NFV HTTP-based incarnation of REST JSON used as the format for resource representations Manipulation of resources (e.g. vnf instances) using CRUD(*) operations POST create resource GET read resource / query resources PATCH update resource DELETE delete resource Special resources for notification management (notification endpoint) complex procedures (task resources). Error handling OpenAPI (a.k.a. Swagger) descriptions will be available soon! 21 (*) CRUD = Create, Read, Update, Delete

22 TASK resources for ETSI NFV APIs Some procedures (e.g. VNF lifecycle management) are not a good fit to be modelled using CRUD operations. TASK resources provide a workaround, an RPC-like solution within a REST framework. A TASK resource is a child of a resource which represents the task/operation to be executed. E.g. vnf_instances/{vnfinstanceid}/scale_vnf The client POSTs a set of parameters to the TASK resource to execute the associated operation. The operation affects the state of the parent resource. 22

23 Resource URI structure of the VNF Lifecycle Management Interface {apiroot}/vnflcm/v1 /vnf_instances /{vnfinstanceid} /instantiate /scale /scale_to_level /change_flavour /terminate /heal /change_ext_conn /operate 23 /vnf_lcm_op_occs /{vnflcmopoccid} /retry /rollback /fail /cancel /subscriptions /{subscriptionid} VNF Instances (POST GET) Individual VNF Instance (GET PATCH DELETE) Task Resources for VNF lifecycle management (POST) VNF LCM operation occurrences (GET) Individual VNF LCM operation occurrence (GET) Task Resources for LCM operation error handling (POST) Subscriptions for VNF lifecycle notifications (POST GET) Individual subscription (GET DELETE)

24 Flow of VNF LCM operations Operations: Instantiate VNF Scale VNF Scale VNF to Level Change VNF Flavour Operate VNF Heal VNF Change External VNF Connectivity Terminate VNF 24

25 Interoperability between VNFs and NFV infrastructure: The acceleration challenge Many VNFs need to be accelerated to deliver high performance will running on COTS servers. Hardware acceleration is a widespread solution, which today creates dependencies between the VNF and the underlying hardware Portability Performance Example The VNF is a Diameter Routing Agent IPSec processing is off-loaded to an enhanced Network Interface Card (NIC) The VNF software communicates with the NIC using a proprietary API, specific to the card model. 25

26 Accelerating VNFs Accelerated VNF Processing partly offloaded to the infrastructure (e.g. on a vswitch or hardware accelerator) and/or Improved IP stack (e.g. DPDK-based IP stack) Virtualisation layer Hardware vswitch VNFC Instance Hardware Accelerator e.g. Smart Network Interface Card (NIC) with offload capabilities 26 The vswitch can be software-accelerated as well DPDK = Data Plane Development Kit

27 The Pass-through model Dependencies have to be specified in the VNF Descriptor, by the VNF provider. Restricted ability to move the VNF from one server to another. 27

28 Towards a solution Under standardization in ETSI GS NFV-IFA 002 Open source implementations under development 28

29 APIs for VNF acceleration ETSI provides functional specifications of acceleration-related interfaces. Application Management NFVO The industry relies on Open Source communities to develop the actual APIs and underlying software modules. OpenStack, OPNFV, LINARO, etc. VNFs VNFs VNFs VNFM ETSI GS NFV-IFA 002 (general framework) ETSI GS NFV-IFA 018 (switch control) NFV Infrastructure VIM 29 ETSI GS NFV-IFA 019 (acceleration management)

30 Agenda State Of the Art Technical challenges and path forward Interoperability Cloudreadiness Full automation 30

31 Cloud-native / Cloud-ready VNFs Today, these are marketing terms referring to a VNF whose software has been (re-)designed to get the most from the Cloudbased nature of the NFV technology, as opposed to just porting existing network applications to COTS 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) Several operators have developed their own set of guidelines. ETSI and the ONAP community are also developing one. See ETSI GS NFV-EVE 011 and ONAP VNF Cloud readiness requirements. 31

32 Guidelines for Cloud-native / Cloud-ready VNFs Typical guidelines Design small VNFs or VNF Components (VNFC) to enable fast instantiation and increase resource utilization Include a load balancing VNFC to facilitate scaling and resilience Minimize the number of stateful VNFCs within a VNF, to facilitate resilience. Minimize coupling between VNFCs to facilitate partial upgrades Design for coping with infrastructure failure (internal redundancy, synchronization middleware between stateful VNF Components, etc.) Reminder 1 VNFC instance = 1 VM or 1 Docker Container Challenges No one-size-fits-all solution Should not hinder vendor differentiation 32

33 Cloud-Ready, PaaS and Containers: How do these concepts fit together? Cloud-Readiness implies single-capability software units and typically small code size, which is currently regarded as a motivation for using Containers rather than virtual machines However, the differences between VMs and Containers in terms of resource consumption might vanish over time (see e.g. litevm, clear containers, just-enough-os, etc.) PaaS does not imply Containers or Cloud-Readiness but often assumes it. Cloud-Readiness do not require PaaS capabilities but can benefit from it Developers of cloud-ready VNF can focus on core business features. NFV is compatible with the 3 of them but does not require any of them. 33

34 NFV vs. Containers The NFV architectural framework does not make any assumption on the virtualisation technology used. Higher-level NFV management and orchestration functions are agnostic to the virtualisation technology. ETSI GS NFV-EVE 004 describes the use of OS Container technologies, including Containers nested in Virtual Machines. 34 Virtualisation technology-specific

35 NFV vs. PaaS Consumer VNF Instance Use Use This is one of the topics in the scope of a new ETSI work item (IFA029) Report on the Enhancements of the NFV architecture towards Cloud-native and "PaaS PaaS Instances of Dedicated Services Instances of Common Services Container Infrastructure Service Service Management Container Infrastructure Service Management NFVI 35 Scope: The report will study the potential enhancements of the NFV architecture for providing PaaS -type capabilities and supporting VNFs which follow cloud-native design principles. It will describe the related use cases and provide recommendations on the enhancements of the NFV architecture for flexible choices for the designers of VNFs. Such platform features can include, but are not limited to, common platform services, dependency management, and accessing other VNFs. An assumption is that some VNFs may be decomposed into small components (e.g., following a micro-services approach) and/or able to rely on common platform services. The study will take into account other initiatives in this space. It is not the intention of this WI to define cloud-native, nor to recommend how VNFs shall be decomposed and implemented.

36 PaaS Modelling options under study PaaS services can be modelled as special VNFs a new type of NFVI resources a new type of object specific to the PaaS layer 36

37 Agenda State Of the Art Technical challenges and path forward Interoperability Cloudreadiness Full automation 37

38 Automation in NFV Operators are looking for full automation of service lifecycle management, including FCAPS management of network applications. NFV Management and Orchestration is not sufficient to achieve this goal as the functions it provides focus on the lifecycle of virtualised resources only. Automated deployment or configuration of element management function needs to be considered as well. In many cases, the NFV Orchestrator does not have sufficient intelligence to take automated decisions upon receipt of fault management / performance management reports. 38 FCAPS: Fault, Configuration, Accounting, Performance and Security

39 NFV Orchestration Scope of E2E automation Orchestration of management tasks at different abstraction levels 39

40 NFV Orchestration vs. Service Orchestration NFV Network Service (NS) Orchestration (as performed by the NFVO) should not be confused with Service Orchestration. Service Orchestration Service Orchestration is aware of the network service semantics, and coordinates all management actions. Network Application Control & Management (Element Managers) Network Functions NFV Orchestration (NFVO, VNFM, VIM) Network Service (NS) Orchestration focuses on virtualised resources and is agnostic to the network service semantics. 40 NFV Infrastructure

41 Addressing E2E automation: Element Management (EM) functions For a VNF to become fully operational, the embedded network application needs to be configured and managed. When a new VNF is being deployed, an Element Manager (EM) needs to be deployed as well in an automated way. or the VNF needs to be manageable through generic EM functionality embedded in the OSS Quite a challenge! Other Operations Support Systems EM VNF NFV Infrastructure NFV Management & Orchestration functions 41 ETSI GR NFV-IFA 021: Report on management of NFV-MANO and automated deployment of EM and other OSS functions To be approved: January 2017

42 Industry initiatives on service orchestration in an NFV framework Almost all NFV-related open source projects have extended the NFV architecture with a service orchestration layer and/or a data analytics module. Work is ongoing in standardization bodies and fora as well: TM Forum ZOOM ETSI ENI ETSI NTECH AFI IETF ANIMA MEF LSO Convergence of these initiatives remain a bug question mark! Service Orchestration / Application Management NFV Management & Orchestration Data Analytics 42

43 43 Conclusion

44 Concluding Remarks 3 main areas of concern to be tackled to make NFV a success 1. Lack of interoperability between the components of an NFV system 2. Commercial tools enabling full automation of service lifecycle management not yet available 3. Very few cloud-ready VNFs (i.e. many VNFs not designed to take the full benefits of a cloud-based deployment) A number of topics deserve involvement of the research community New testing methods to accelerate deployment on new releases Multi-criteria resource placement algorithms (e.g. energy efficiency) Advanced security monitoring and management Multi-domains orchestration 44 The NFV market will generate revenues of some $38 billion in 2022, according to a report by ABI Research.

45 Further details ETSI NFV Technology Web page and (Drafts specifications) 45

46 Thank you 46