1. Version 0.7 Draft – For Review Olga Havel

2.  Project Name: SDN-O  Project Repository name:  Project Description  Provide the network 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 Service Agility. Improving 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 service type)

4.  Project Name: SDN-O  SDN-O Release 1 Features and Functionality Provisioning and activation of network connectivity services for the selected OPEN-O Use Case Simple SDN-O Portal Basic resource management (BRS for Basic Resource Inventory) Common SBI 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:  Driver for SPTN Super 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 Connectivity Service Activation REST API Network Integration Configuration via REST/RESTCONF/YANG API (SDN Controllers) and Neutron API (VIM) Common SBI APIs to Drivers  Stretch Goal:  Integration with SPTN Super Controller  Monitoring via SNMP and NetFlow interfaces

5.  SDN-O Lifecycle Management Sub-project  SDN-O Portal  SDN-O APIs (NBI) and Common SBI  SDN-O E2E Network Connectivity Service Activation (with NBI API)  SDN-O Service 1 Type: VLAN/VxLAN Service Activation with SBI API  SDN-O Service 2 Type: IP Sec with SBI API  SDN-O Service 3-A Type: L3VPN Service with SBI API  SDN-O Service 3-B Type: L2VPN Service with SBI API (Stretch Goal)  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  ONOS SDN Controller for WAN  VIM Neutron  CMCC Super Controller (Stretch Goal)

6.  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. 9 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 Abstract NBI SDN-O Service Lifecycle Manager E2E Connectivity Network Service over Overlay/Underlay  Traffic Optimize (stretch goal –L3 VPN path optimize)  SDN-O Monitor (stretch goal – utilization monitor) SDN-O Resource Management (BRS Release 1) SDN-O Abstract SBI 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

10. SDN-O REST API E2E CONNECTIVITY 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 PRESTO may be useful as reference for abstract SBI (post Release 1) Release 1 VLAN/VxLAN/L3VPN/IPSec YANG, stretch L2VPN MEF LEGATO may be useful as reference for abstract NBI VIM (OS)WAN SDN Controller (ONOS) Super SDN Controller (SPTN)

11.  Simple SDN-O GUI will be implemented, no current seed code for that  Lifecycle Management will be based on code from Huawei  Monitor and Optimize will be based on code from CT (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 service inventory may be supported (stretch goal) SDN-O Portal Lifecycle Management SDN-O GUI GS-O BSS/ APP E2E Network Connectivity Service Service 1: VLAN/ VxLAN Service 2: IPSec Service 3a: L3VPN Service 3b: L2VPN Monitor & Optimize SDN Monitor Optimize API (s) SDN-O Drivers VLAN/ VxLAN L3 MPLS VPN BRS IPSecSPTNVIM Rel 1 Scope Rel 1 Stretch Goal

12.  For Release 1, SDN-O will implement the following service lifecycle functionality  Create Service Instance  Activate Service Instance  Deactivate Service Instance  Delete Service Instance  For Release 1, the following may 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 Service Instance monitor utilization  Modify Instance (modify to optimized path)  Post-Release 1  Design, Onboard and Remove Service  Test Instance  Service Lifecycle may be extended in the future to support some advanced states and state transitions, like  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

13.  Contact: Olga Havel olga.havel@huawei.com  Developers committed to the project  Huawei (~20), ZTE (1+?), CMCC (1+?), CT (2+?), Others (+?)  Initial Committers  ZTE (SDN-O and driver)  Zhou Ming zhou.ming2@zte.com.cnzhou.ming2@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   Potential: RedHat and Intel

14.  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  Network Connectivity Service Inventory  Identified gaps  VIM Provider needs to be agreed (RedHat)  We need to indentify if some other RedHat modules could be included  Lab Agreed

15. MilestoneDescriptionDate M0Planning Process Open8 June 2016 M1Planning Process Complete1 st July 2016 M2Feature / Functionality Freeze21 st July 2016 M3Model/API Freeze8 th August 2016 M4Code Freeze1 st September 2016 RC0First Release Candidate15 th September 2016 RC1Second Release Candidate1 st October 2016 RC2Third Release Candidate15 th October 2016 RC3Release3 rd November 2016

16.  Catalogue Driven SDN-O Orchestration at all network layers  Meta Model driven dynamic programmable orchestration  Generic lifecycle management for any 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 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  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,..

17.  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)

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

20. - 20 - Anal Prob ol v5.ppt Type/Degree of Participation Can Be Defined Individual(s) (Many) who perform an activity or take part in a decision—responsible for action/implementation. R esponsible “Doer” A ccountable “Buck Stops Here” C onsulted “In the Loop” I nformed “FYI” Individual (One!!) who has ultimate decision making and approval authority. Typically the owner of the budget. Individual(s) (Many) who need to have input into a decision or action before it occurs. Individual(s) (Many) who must be informed that a decision or action has taken place.

21. IC AR R 7.Project management/reporting IAR C 8.Program management/reporting AR R R 9.Project –level Developer onboarding/outreach I AR RR 6.Release Execution IARRR I C RR RC 1.Market strategy Participant Role Activities BoardTSCTech LeadCommitterDeveloper AR R R 2.Budget, expenses, etc. 3.Release Planning 4.Project Execution 5.Code development Release Mgr

22. - 22 - Anal Prob ol v5.ppt I I C C A A A C C I I C C R R A A I I C C R R R R C C I I R R A A C C I I A A R R I I A A RACI Charting Maps Roles with Activities Functional Role: A position assigned or assumed to accomplish an activity or sub-activity Activity: An action or decision that is one of several sequential steps in the completion of a business process. It should always result in a clear output

23. - 23 - Anal Prob ol v5.ppt CAR 7.Classify expenses AR 8.Audit CAR 9.Determine payment type RA 6.Forward to region accounting IAR C AR Region Employee Expense Statement Processing (Example) 1.Document expenses Participant Role Activities EmployeeSecretarySupervisor Region Accounting General Accounting AR RC 2.Complete expense account form 3.Forward to supervisor 4.Review 5.Approve