1. Version 0.3 Draft – For Review Avinash S

2.  Project Name: SDN-O Drivers  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  Huawei  ZTE  Further discussions needed:  RedHat (e.g. VIM Driver, VIM Neutron),

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. The SDN-O Drivers project would help Operators to adopt their existing and new SDN Controllers, NMS and EMS systems for End to End network connectivity spanning across WAN. 1. When provisioning network services over existing infrastructure, OSS integration requires orchestrator to communicate with existing controllers and management systems. 2. Introducing a new Software Defined Network Controller, requires OPEN-O SDN Orchestrator to communicate with new controller at least possible time, SDN-O Release 1: Achieve network connectivity using controllers for access and WAN controllers. Achieve End-To-End connectivity spanning Site, WAN and DC network using open source and Operator provided SDN controllers and Cloud manager.

4.  Project Name: SDN-O  SDN-O Release 1 Features and Functionality ODL Drivers for (VLAN/VxLAN) SDN Controller for Access Network Access L2VPN VLAN Service with SDNO common SBI overlay API (Stretch Goal) ONOS Drivers for (L3 VPN and IPSec) SDN Controller for WAN WAN L3VPN Service with SDNO common SBI underlay API (Stretch Goal) Neutron OpenStack Driver for VIM  Stretch Goals:  Driver for SPTN Super Controller  SDN-O Release 1 drivers and APIs/interfaces Support for L3 Overlay for site access network (by ZTE SPTN) Support for WAN overlay IPSec between Site-GW to DC Gatway via PE’s (Static routing)  Common IPSec with SBI API Support for DC Gateway configuration for Neutron router instance. Configuration via REST for Rest based controller applications and Neutron API. Support for RESTCONF/YANG API (SDN Controllers) Support common SBI APIs at each driver service.  Stretch Goal:  Support for L2 underlay for site access network (by ZTE SPTN)  L2VPN Service with SDNO common SBI L2 underlay API (Stretch Goal)  Integration with SPTN Super Controller  Monitoring via SNMP and NetFlow interfaces

5.  Driver Sub-Project Test Strategy  Driver 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  Driver 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  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  Driver sub-project test splits into microservices with well defined and agreed REST in nothbound interface and with RESTCONF/Netconf in the south bound API’s  Development of driver code and integration with common services will be test driven with the goal of 50%unit test code coverage in any new code  Automation of Driver 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 as well)  Automation of SDN-O deployment and testing based on the integration test plan  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 Tes Team

8. 8 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 Driver project will depend on  Micro-Service Bus  Auth  Driver Mgr  Protocol stack  Log Rel 1 Dependency Rel 1 Scope Driver project will address :  SDN Controller drivers  VIM drivers within the scope of the SDNO

9.  VLAN/VxLAN & IPSec for Site access controller  L3 VPN for WAN underlay VPN  VIM driver to interact with Neutron for vDC gateway instance for IPSec configuration.  VPC service driver to create DC Gateway instance (Neutron router instance) Stretch goal : 1. SPTN by china mobile 2. L2 VPN support for site network underlay? 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 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 Service 3: VPC Service 5: L2VPN

10. SDNO VPN lifecycle API (s) Request to controller request/Model translator Netconf/Res tconf Client REST client Controller/ VIM  One driver instance for a type of controller.  Multiple services can possibly communicate with one driver for a service(release-1 scope only). Plugins can be made of client/agents  One driver framework can work with multiple plug-ins to deliver different services with the controller.  Service Request tranlsated to Controller/VIM interface Model translator.  REST/Restconf/Netconf client to communicate with controller. Post Release -1 :  Support for independent plugin development with near-zero dependency over driver framework (example: model based)  Support for device discovery. Controller Driver Service Rel 1 Scope Service plugin-1 Service plugin-2 … Service plugin-N Rel 1 Dependency Driver Mgr. Messagebus Controller instancr NBI

11. 11 ServiceNetworkControllerOwnershi p Service-1: VxLAN Overlay - Site accessAccess Controller (ODL based solution) ZTE Service-2: IPSecOverlay - PoP(vCPE) EGRESS Access Controller (ODL based solution) ZTE Service-2: IPSecOverlay - DC GW Instance (INGRESS) DC Controller- Openstack serviceHuawei Service-3: L3 VPN Underlay – MPLS L3 VPN ( Between PE’s) WAN underlay (ONOS based solution) Huawei

12. vCPE Use Case for SDN-O Stretch goal – Controller/Driver responsibility ServiceNetworkControll er Ownership L2Underlay- AccessSPTNCMCC L3Underlay – SPTN WAN network SPTNCMCC

13. 13 1.DriverMgr register with micro-services bus 2.Message bus query to driverMgr for driver URL destination. SDN Orchestration Lifecycle service – Overlay/Underlay Message bus Driver manager Controller Type Driver SDNO Controller Type Instance VLAN VXLAN IPSec VXLAN VLAN overlay underlay MPLS BGP L3VPN VPN Service Instance Register driver instance SDNO Service Id : N/W service Id ServiceProbable Mapping Controller Device Id : VPN service instance Id Driver service VPN Orchestration Instance Id : Controller Id, VPN service instance Id, Device Id SDN Orchestratio n lifecycle Service Orchestration connection id : Device Id, Controller Id OPEN-O REST / RESTCONF Release-1 Orchestration to VPN Service mapping Infrastructure Driver manager interface with message bus is under discussion with common-services team. This would impact on URL routing rules across mircoservices RE S T

14.  Contact: Olga Havel olga.havel@huawei.com  Developers committed to the project  Huawei (~20), ZTE (1+?), CMCC (1+?), CT (?), 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  Avinash avinash.s@huawei.com  Kulbhushan Rana kulbhushanr@huawei.comkulbhushanr@huawei.com  >  Potential: RedHat and Intel

15.  This is the Release 1 project  Minimum viable product  Provision network connectivity as defined for the OPEN-O Use Case.  Stretch goals  SDN-O Monitoring and Network Optimization  Integrate with China Mobile Super Controller  Network Connectivity Service Inventory from Controller and management services.  Identified gaps  VIM Provider needs to be agreed (RedHat)  We need to indentify if some other RedHat modules could be included  Lab Agreed

16. 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

17.  Model driven mapping between VPN lifecycle and south bound interface model.  Discovery of Resource, Services and VPN status query from Controllers.  Service instance to Driver mapping for complex atomic life- cycle requests spanning multiple drivers.  Extending drivers for more operator use cases.

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

19.  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: 

21. - 21 - 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.

22. 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

23. - 23 - 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

24. - 24 - 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