How Standards and Open Source Interworking can Resolve Challenge

1 . How Standards and Open Source Interworking can Resolve Challenges Slowing down the Massive NFV Deployment ZHOU Nan / Senior Standards Engineer Kubi GAO / Senior Software Engineer 

2 . NFV History ETSI NFV ISG was The first whitepaper The second whitepaper In 2014, 25 PoC, founded in 2012 with was published in and 5 specs were 10+ Specs and the Intel, AT&T, DT, BT, Oct 2012 published in Oct 2013 third whitepaper etc. were published by ETSI ISG NFV. 3GPP SA5 started NFV study item. In 2017, HPE and many In 2016, ISG Chair was re- ETSI NFV ISG shifted to the Phase 2 from players reduced resource in elected, NFV commercial 2015, developing mandatory specs to ETSI NFV ISG, DT initiated deployment was expected help commercial deployment between ZSM ISG. in 2020. NFV-ITI was 2016 and 2018. 9 specs were published. initiated. A TR was published by 3GPP.  In the first whitepaper, the reason and challenges to implement NFV are given.  The famous architecture was proposed in 2013 to specify different blocks (VIM, VNFM, Orchestrator, NFVI, VNF, etc.) and interfaces in NFV system. Ideally, carriers want different providers to provision different blocks, and each block can be replaced easily in a plug-and-play way.  Interoperability was always the TOP issue needs to be resolved.  ETSI NFV ISG published many specs but most of them are optional.  Time consuming for 3GPP, TMF, ETSI negotiating NFV standards. 

3 . Traditional Technology Landing Flow Standard Interoperability Requirement Certification Development Testing 3GPP Standards . Integration ETSI ISG Development . Testing ETSI ISG NFV . Certification NFV Requirements TMF Interoperability Use cases Testing Deliver Carriers NFV ITI 

4 .Rises, the Open Source All players wanted to accelerate NFV technologies since 2012, and they found the development process is slow via traditional SDOs. Therefore, they introduced open source to make the progress faster. Huawei introduced AT&T and LF proposed OPNFV was OPNFV first ARNO Yunify to ETSI in 2013 open source plan in founded in Sept was available in May 2014 2014 April 2015. In 2018, ONAP Beijing In 2017, Open-O and In 2016, MANO open OPNFV removed was released ECOMP are combined source projects Open-O, scope constraints in to form ONAP OSM were announced Dec 2015. 

5 . OPNFV OPNFV facilitates the development and evolution of NFV components across various open source ecosystems. Through system level integration, deployment and testing, OPNFV creates a reference NFV platform to accelerate the transformation of enterprise and service provider networks. Participation is open to anyone, whether you are an employee of a member companyor just passionate about network transformation. OPNFV defines use cases, integrates & tests what other projects (OpenStack, Kubernetes, ODL, OVS, fd.io) create! OpenStack Integration Requirements Use cases Solution in . Deploy Deliver consensus . Test OPNFV OPNFV . ODL 

6 .NFV Today VNF VNF VNF VNF VNF Cloud Cloud OS OS Cloud OS Cloud OS HW HW HW Model 1 Model 2 Model 3  Most carriers choose model 1 with full stack islands.  Some carriers decouple HW from the SW stack with SW stack islands. HW is normally purchased with traditional server procurement procedures.  Few carriers, move one step further, decouple the VNFs from the rest of stacks. This requires a lot of integration work between VNF vendors and the underneath SW stack.  Carriers rarely decouple the full stack, not to mention being SI by themselves.  This is only about the vertical layers that each VNF vendor brings their own VNFM. 

7 . Challenges for NFV Massive Deployment EMS Hardware Instl. Host OS Instl. VNFM Instl. MANO VNF （Options > 5） （Options > 5） API Testing Interoperability VNF Instl. Testing Cloud OS （Options > 10） Functional Reliability …… COTS（Options > 10） Testing Testing Costly for No stable Too many vendor lock-in integration and APIs options testing There are many issues when carriers wants to massively deploy the NFV technologies:  No stable API between layers  Too many options for the full stack  Considerable cost for integration and testing  Vendor lock-in on platforms 

8 .Values Open Source Verification Bring to the NFV Industry Verification: Setup a Baseline Increase Reduce integration Avoid Vendor Lock- Interoperability and testing cost In • Many interfaces and blocks were developed in Open Source; WHY in Open Source? • Test cases are already developed in Open Source; • Faster than SDOs; • Not isolated from standards; 

9 . Consensus, the OPNFV Verification Program The Board and TSC approved the OPNFV Verified Program OPNFV Verified Program (OVP) has been launched early this year • OPNFV Verified Program (OVP) verifies that a commercial VIM/NFVI exposes the same – key APIs, – behaviors, and – characteristics as the OPNFV reference platform • Main objective: Reduce VIM selection and VNF onboarding cost – Establish industry-accepted technical baseline – Simplify RFIs and RFPs 

10 .Overview on the OPNFV Verification Program • Test scope and coverage – Based on tests developed by OPNFV – and upstream communities • Releases of OVP • Ways of Participation – Self testing: Deploy and run Dovetail in private lab – 3rd party labs: Utilize services offered by selected labs (underdevelopment) 

11 . OVP Technical Architecture Main components of OVP 1. Dovetail: automated test and reporting tool leveraging OPNFV and upstream test tools 2. OVP web portal: upload, display, and review results Dovetail instantiation configuration test case execution result collection Test Tools Functest Yardstick Bottlenecks API test HA tests System under test: VIM + NFVI controller nodes, compute nodes, SDN controller 

12 .Compliance Verification Workflow 1. Submission of participation form 2. Testing 3. Submission of results 4. Notification of reviewers 5. Community review of test results 6. Grant of use of program marks 

13 .Compliance Verification Workflow 

14 .Today’s OVP Test Suite • Os_interop：全部来自tempest测试用例 集，openstack官方认证项目osinterop的 OPNFV Verified 2018.01 2016.08测试集，涵盖network, image, compute, volume, identity Mandatory test cases • vPing：vping_ssh, vping_userdata • OpenStack interop API tests (205 tests) • HA：cinder-api, glance-api, nova-api, • Basic layer 2 packet forwarding (2 tests) neutron-server, haproxy, keystone, cpu • OpenStack control service high availability (8 tests) load, disk load. Optional test cases • IPv6：选自tempest的ipv6相关测试用例 • IPv6 tenant networks (25 tests) • BGPVPNs (4 tests) • BGPVPN：来自opnfv社区sdnvpn项目 • Fundamental VIM capabilities (30 tests) • VIM capabilities：选自tempest中的 scenario测试用例，覆盖forwarding packages, security group, dynamic network, vm lifesycle and multinode. 

15 .The Rolling Test Suite for OVP OPNFV Verified 2018.0x Functest test cases • smoke：tempest中所有标签为smoke的测试用例， • Tempest compute (smoke) 基础的API测试 • Tempest identity v2 (smoke) • Tempest identity v3 (smoke) • Neutron trunk：tempest plugin测试用例，针对 • Tempest image (smoke) neutron trunkport的测试 • Tempest network(smoke) • BGPVPN ：tempest有关bgpvpn的plugin测试用例 • Tempest volume(smoke) • Patrole：tempest plugin，检测环境的role权限管 • Tempest Neutron Trunk ports 理功能 • Tempest BGPVPN Tempest tests • Security: Patrole RBAC tests • VNF testing vIMS • vIMS：部署cloudify和ims，运行测试用例检测 • VNF testing vEPC • vEPC：使用juju部署一个vEPC，测试attach流程 Yardstick test cases • HA restart：ipmi登录控制节点shutdown • High-availability of one controller(restart) • HA message queue：杀消息队列进程 • High-availability of message queue • High-availability of Neutron L3 agent • HA neutron l3：杀neutron_l3_agent • High-availability of OpenStack database • HA database：杀数据库服务进程 • Stress：Bottlenecks瓶颈测试项目，检测同时起 Bottlenecks test cases 20组虚机的能力 • Stress Testing 

16 . Open Source Verification in Nutshell is Another Form of Standards Linux Foundation Networking • Umbrella project covering 6 networking projects propose expanding the program in 2018 to include VNF compliance Linux Foundation Networking LFN Board … Compliance TAC Verification Framewor k Committee OPNFV ONAP ONA OPNFV TSC TSC P tes VNFs t ODL FD.IO ODL FD.IO TSC tes TSC tes t t 

17 .