1. Version 1.0 Olga Havel olga.havel@huawei.com

2.  Project Name: SDN-O  Project Repository name: sdno  Project Description  Provide the network connectivity service orchestration over SDN and Legacy Networks  Implement the SDN-O Component that supports the Release 1 of the Open-O Project  Project Participants:  China Mobile  China Telecom  Huawei  ZTE  Further discussions needed:  RedHat (e.g. API, Discovery, Inventory, VIM Driver, VIM Neutron),  Intel (APIs)

3. The Main Problem for Operators is Poor Network Connectivity Service Agility. Improving Network connectivity service agility significantly decreases time to market for new service offerings and reduces CAPEX/OPEX. 1. When upgrading or replacing network devices, OSS integration commonly takes >3 months 2. When provisioning an existing network connectivity service, it can take >1 week for residential service, and >6 weeks for enterprise private line or VPN service; 3. When introducing a new network connectivity service type, it’s common to take >12 months; 4. When customers experience problems or network outages occur it can take significant effort and time to troubleshoot and diagnose the source SDN-O Release 1: Address the Problem 1 (network integration) and Problem 2 (provisioning) for network connectivity services between the enterprise and data centre via Access Network and WAN.  Stretch Goal: Problem 4 (assurance)  Post SDN-O Release 1: Address the Problem 3 (new network connectivity service type)

4.  Project Name: SDN-O  SDN-O Release 1 Features and Functionality Provisioning and activation of E2E network connectivity services inside the SDN-O Control for the selected OPEN-O Use Case Simple SDN-O Portal Basic resource management (BRS for Basic Resource Inventory) Common SBI (more on the next slide) ODL Drivers for (VLAN/VxLAN) SDN Controller for Access Network ONOS Drivers for (L3 VPN and IPSec) SDN Controller for WAN Neutron OpenStack Driver for VIM  Stretch Goals:  Drivers for SPTN Super Controller and SPTN Access Controller  Monitoring of utilization and optimization of the network path, including traffic scheduling (either using PCEP- based mechanism, or using BGP-based mechanism).  Basic network connectivity service inventory  SDN-O Release 1 APIs/interfaces E2E Network Connectivity Service inside the SDN-O Control Activation REST API Network Integration Configuration via REST/RESTCONF/YANG API (SDN Controllers) and Neutron API (VIM) Common SBI APIs to Drivers (more on the next slide)  Stretch Goal:  Integration with SPTN Super Controller  Monitoring via SNMP and NetFlow interfaces

5.  The goal of the SDN-O project is to define “common SBI” to be adopted by the industry for all overlay and underlay technologies specified in the Use Case. Includes: VxLAN/VLAN, IPSec, VPC, L3 VPN, L2 VPN  Huawei will submit the seed code with the current SBI and documentation from the current Release adapted for OPEN-O  This code will be reviewed by all partners and the gap analysis will be performed based on the following criteria  Target SBI quality, consistency and best practices  Target industry standard compliance (e.g. MEF Presto). The selection of target industry standard will be based on business requirements, industry support, industry adoption.  Based on the identified gaps, the roadmap for delivering the Target Common SBI will be agreed.  Initial SBI Version will be delivered in Release 1.  Target SBI will be planned for post Release 1, when the Drivers project will be moved outside of SDN-O and the SBI API will become SDN-O external interface  The following are the delivery roadmap options, based on the results of the gap analysis:  Leave the SBI seed code for Release 1, develop drivers using this current SBI and plan all the gaps for post Release 1. Target SBI delivery: post Release 1  (Stretch goal) Make some improvements and close some gaps in Release 1. Split gaps and requirements between Release 1 and post Release 1. Target SBI delivery: post Release 1  (Stretch goal) Deliver all the gaps in the Release 1 timeframe. Target SBI delivery: Release 1

6.  SDN-O Lifecycle Management Sub-project  SDN-O Portal  SDN-O APIs (NBI) and Common SBI  SDN-O E2E Network Connectivity Service inside the SDN-O Control Activation (with NBI RESTAPI)  This is the only API exposed to GS-O, other micro service APIs will be orchestrated internally inside SDN-O only or accessed via SDN-O Portal for Release 1. GS-O will only need POST (Create & Activate) and DELETE (Deactivate & Delete) methods for an SDN Overlay Service in Release 1.  SDN-O Network Connectivity Service 1 Type: VLAN/VxLAN Service Activation with SBI API  SDN-O Network Connectivity Service 2 Type: IP Sec with SBI API  SDN-O Network Connectivity Service 3 Type: VPC Service with SBI API  SDN-O Network Connectivity Service 4 Type: L3VPN Service with SBI API  SDN-O Network Connectivity Srevice 5 Type: L2VPN Service with SBI API  Basic network connectivity service inventory.  SDN-O Basic Resource Management Sub-project  BRS for Basic Resource Inventory  SDN-O Monitoring and Optimization Sub-project (Stretch Goal)  SDN-O L3VPN Optimization, including traffic scheduling (either using PCEP-based mechanism, or using BGP-based mechanism).  SDN-O Monitoring  SDN-O Drivers Sub-project  ODL SDN Controller for Access Network (VxLAN/VLAN, L2VPN (Stretch Goal))  ONOS SDN Controller for WAN (L3VPN & IPSec)  VIM Neutron  CMCC Super Controller (Stretch Goal)

7.  SDN-O Test Strategy  SDN-O lead will define the SDN-O integration test strategy and test plan, SDN-O sub-project leads will be responsible for implementing the SDN-O test strategy and plan  SDN-O test plan will be based on OPEN-O use cases and tests cases and shared/agreed/reviewed by other projects and approved by OPEN-O Test Team  SDN-O splits into microservices with well defined and agreed REST APIs  Automation of SDN-O deployment and testing based on the integration test plan  Iterative addition of microservices and APIs into the automated deployment and testing as they get committed  Both lab and simulation testing will be required to avoid any lab access problems  Lab must be available before lab testing can start (responsibility of the OPEN-O Test Team)  Sub-Project Test Strategy  Sub-project lead will define the sub-project test strategy and test plan, the sub-project committers will be responsible for implementing the sub-project test strategy and plan  Sub-project test plan will be based on SDN-O use cases and test cases and shared/agreed/reviewed by other sub-projects and approved by OPEN-O Test Team  Each sub-project splits into microservices with well defined and agreed REST APIs  Development in all microservices will be test driven with the goal of 50%unit test code coverage in any new code  Automation of sub-project microservices deployment and testing based on the agreed sub-project test plan (derived from SDN-O test plan and reviewed by other SDN-O sub-projects who use the API)  Integration into OPEN-O Test Strategy  Testing of SDN-O integrated into OPEN-O will be delivered based on OPEN-O Test Strategy defined by the OPEN-O Test Team

9. The SDN-O goal is to deliver the full use case from the previous slide (with SPTN), and we will plan it for delivery. In the case that underlay is not fully functional (automated), integrated and tested, we will not postpone the release date, but would deliver SPTN as a patch or a new release soon after. There are lots of integrations and dependences, we do not want to risk the delivery date if one of underlay technologies is not fully integrated. Therefore, this figure shows the minimum functional Release 1 Use Case fully integrated and ready for demo, as specified in the initial Use Case.

10. 10 Common (TOSCA) Workflow Parser Catalog Model Designer GS-O Service Decomposer Service Lifecycle Mgr. Service Formation Abstract NBI GUI Portal SDN Driver ACCESS/WAN SDN Controller Drivers SDN-O SDN Res. Mgr. Abstract NBI Abstract SBI VPN SDN Lifecycle Mgr. Traffic Optimize SDN Monitor EMS/NMS Driver VIM Drivers GUI Portal VNFM Drivers VIM Drivers NFV SDN Controller Drivers NFV-O NFV Res. Mgr. NFV Monitor NS Lifecycle Mgr. Abstract NBI Abstract SBI NFV Driver GUI Portal Common Service HA Log Driver Mgr. Micro- Service Bus Protocol Stack Auth. VNF Onboarding This project will provide SDN-O GUI Portal SDN-O NBI for orchestration of e2e network connectivity service inside the SDN-O Control only SDN-O Network Connectivity Service Lifecycle Manager E2E Overlay Network Connectivity Service within SDN-O Control over Underlay Connectivity  Traffic Optimize (stretch goal –L3 VPN path optimize)  SDN-O Monitor (stretch goal – utilization monitor) SDN-O Resource Management (BRS Release 1) SDN-O SBI – In Release 1 it will be inside SDN-O, post release 1 drivers will be outside of SDN-O project and SDN-O SBI will be public. SDN-O Controller Mgr and Drivers This project will depend on  Micro-Service Bus  Auth  Driver Mgr Rel 1 Dependency Rel 1 Scope Rel 1 Stretch Goal

11. SDN-O REST API E2E NETWORK CONNECTIVITY SERVICE INSIDE THE SDN-O CONTROL Access SDN Controller (ODL) Stretch goal REST/RESTCONF/YANG MPLS L3 VPN IPSec REST/RESTCONF/YANG VLAN/VxLAN GS-O OSS/ SDN-O Portal REST/RESTCONF/YANG NEUTRON MEF / ONF / TMF/ ETSI may be useful as reference for abstract SBI (post Release 1) Release 1 VLAN/VxLAN/L3VPN/IPSec YANG MEF / TMF / ETSI may be useful as reference for abstract NBI (post Release 1) VIM (OS)WAN SDN Controller (ONOS) Super SDN Controller (SPTN)

12.  Simple SDN-O GUI will be implemented, will be based on NFV-O GUI (same as for GS-O)  Lifecycle Management will be based on code from Huawei  Monitor and Optimize will be based on code from China Telecom (stretch goal)  SBI Interface will be based on the code from Huawei  BRS for Basic Resource Management will be based on code from Huawei  Drivers will be managed using the Driver Manager  Catalogue will not be integrated for Release 1  Some basic network connectivity service inventory may be supported (stretch goal) SDN-O Portal Lifecycle Management SDN-O GUI GS-O BSS/ APP E2E Network Connectivity Service inside the SDN-O Control Service 1: VLAN/ VxLAN Service 2: IPSec Service 4: L3VPN Monitor & Optimize SDN Monitor Optimize API (s) SDN-O Drivers VLAN/ VxLAN L3 MPLS VPN BRS IPSecSPTNVIM Rel 1 Scope Rel 1 Stretch Goal Service 3: VPC Service 5: L2VPN

13.  For Release 1, SDN-O will implement the following network connectivity service lifecycle functionality  Create & Activate Service Instance  Deactivate & Delete Service Instance  For Release 1, the following will be implemented with a single request:  Create and Activate Service as a single request  Deactivate and Delete Service as a single request  Release 1, SDN-O stretch goal  Assure Network Connectivity Service Instance : Monitor utilization  Modify Instance: modify to optimized path  Post-Release 1  Design, Onboard and Remove Service (to integrate with Catalogue)  Test Instance  Network Connectivity Service Lifecycle may be extended in the future to support some advanced states and state transitions, like  Separate advanced state engines for Catalogue versus Inventory  Separation of provision and activate  Separation of terminate and deactivate  Assure Instance for Connectivity /SLA based on both Polling & Traps & TCAs  Reserve Resources for the Instance as a separate state  Service Order without creation/decomposition  Modify Instance for Service Affecting and Non-Service Affecting Service Upgrade Design Service Onboard Service Activate Instance Assure Instance Modify Instance Deactivate Instance Remove Service Test Instance Create Instance Delete Instance Rel 1 Scope Rel 1 Stretch Goal

14.  Contact: Olga Havel olga.havel@huawei.com  Developers committed to the project (including committers)  Huawei (~20), ZTE (2), CMCC (1+?), CT (2+?), Others (+?)  Initial Committers  ZTE (SDN-O and driver)  Zhou Ming zhou.ming2@zte.com.cnzhou.ming2@zte.com.cn  Feng Jie Feng.jie2@zte.com.cn  China Mobile (driver)  Weiqiang Cheng chengweiqiang@chinamobile.comchengweiqiang@chinamobile.com  China Telecom  Chen Yan (chenyanx@ctbri.com.cn)  Fu Borui (fubr@ctbri.com.cn)  Huawei  Olga Havel olga.havel@huawei.com  Pierfranco Ferronato pierfranco.ferronato@huawei.com  Avinash avinash.s@huawei.com  Kulbhushan Rana kulbhushanr@huawei.com  Chen Cang cang.chen@huawei.com  Mark O’Keefe mark.o.keeffe@huawei.com  Huanglinkang huanglinkang@huawei.com  Potential: RedHat and Intel

15. Role Project Technical LeadOlga Havel, Huawei ArchitectureOlga Havel, Huawei TestingLiuguangming SDN-O OrchestrationLead: Pierfranco, Huawei Committer: Avinash, Huawei Committer: Mark O’Keefe, Huawei Committer: Huanglinkang, Huawei BRSLead: Chen Cang, Huawei SDN-O MonitoringLead: Chen Yan, China Telecom Committer: Fu Borui, China Telecom Committer: Huanglinkang, Huawei SDN-O DriversLead: Kulbhushan Rana Committer: Avinash, Huawei Committer: Zhou Ming, ZTE Committer: Feng Jie, ZTE Committer: Weiqiang Cheng, China Mobile

16.  This is the Release 1 project  Minimum viable product  Provision network connectivity as defined for the OPEN-O Use Case via API provided to GS-O  Stretch goals  SDN-O Monitoring and Network Optimization  Integrate with China Mobile Super Controller  Basic Network Connectivity Service Inventory  Identified gaps  VIM Provider needs to be agreed (RedHat)  We need to identify if some other RedHat modules could be included  Lab Agreed  Use Case not agreed yet (Board/TSC)

17. MilestoneDescriptionDate M0Planning Process Open8 June 2016 M1Planning Process Complete Architecture Review 1 st July 2016 M2Feature / Functionality Freeze21 st July 2016 M3Model/API Freeze Architecture Checkpoint 8 th August 2016 M4Code Freeze1 st September 2016 RC0First Release Candidate15 th September 2016 RC1Second Release Candidate29 th September 2016 RC2Third Release Candidate20 th October 2016 RC3Release3 rd November 2016

18.  Catalogue Driven SDN-O Orchestration at all network layers  Meta Model driven dynamic programmable orchestration (Capability to support orchestration of the new service type out of the box via configuration only, without need for any code changes and new software releases )  Generic lifecycle management for any network connectivity service  Alignment with external Open Source and SDOs information/data models and APIs  Advanced model driven GUI  Full Network Connectivity Service Lifecycle, including  SDN-O Inventory with Network and Service Discovery & Synch  SDN-O Service Catalogue Support  SDN-O Service Troubleshooting & Diagnostics  SDN-O Service Problem Management  SDN-O Service Quality Management  SDN-O Service Usage Management  SDN-O Service Control, including Closed Loop, Dynamic Resource Allocation/Traffic Engineering  Enhanced SDN-O Service State Engine  Batch SDN-O Service Retrieval with advanced filtering  Asynchronous API  Integration/ Support for Analytics, Policy based Management, Customer / Partner Management,..

19.  Link to seed code:  Huawei: https://github.com/KoderLee/openoseed/tree/master/sdno https://github.com/KoderLee/openoseed/tree/master/sdno  Others ….  Vendor Neutral  Huawei ensured that all proprietary trademarks, logos, product names, etc. have been removed.  Others : CT, CMCC, RedHat?  Meets Board policy (including IPR)

20.  Project name: SDN-O  Jira project name:  Jira project prefix:  Repo name:  Lifecycle state:  Primary contact: olga.havel@huawei.com  Project lead: Olga  Mailing list tag:  Committers: 