1. Open-O SDN-O Driver Project Proposal
Version 0.4
Draft – For Review
Avinash S

2. Overview Project Name: SDN-O Drivers
Project Repository name: <TBD LF to put a common github url>
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. Problem being Solved
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.
When provisioning network services over existing infrastructure, OSS integration requires orchestrator to communicate with existing controllers and management systems.
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 Scope 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. Testing and Integration Plans
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

6. OPEN-O vCPE Use Case Overview

7. vCPE Use Case Overview for SDN-O

8. Architecture Alignment - Drivers
Rel 1 Scope
Common Service HA
Log
Driver Mgr.
Micro-Service Bus
Protocol Stack
Auth.
Common
(TOSCA)
Workflow
Parser
Catalog
Model
Designer
GS-O
Service Decomposer
Service Lifecycle Mgr.
Service
Formation
Abstract NBI
GUI Portal
Rel 1 Dependency
SDN-O
NFV-O
GUI Portal
GUI Portal
Abstract NBI
Abstract NBI
SDN
Monitor
SDN Lifecycle Mgr.
NFV Monitor
NS Lifecycle Mgr.
VPN
SDN Res.
Mgr.
NFV Res. Mgr.
Traffic Optimize
Abstract SBI
Abstract SBI
NFV
Driver
SDN
Driver
NFV SDN
Controller Drivers
VNFM Drivers
VIM Drivers
VNF Onboarding
ACCESS/WAN SDN Controller Drivers
EMS/NMS Driver
VIM Drivers
Driver project will depend on
Micro-Service Bus
Auth
Driver Mgr
Protocol stack
Log
Driver project will address :
SDN Controller drivers
VIM drivers within the scope of the SDNO

9. Driver Architecture Scope
Portal
Portal
GS-O
GS-O
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 :
SPTN by china mobile
L2 VPN support for site network underlay?
BSS/
APP
BSS/
APP
SDN-O GUI
SDN-O GUI
SDN-O
SDN-O
API (s)
API (s)
Lifecycle Management
Lifecycle Management
E2E Network Connectivity Service inside the SDN-O Control
E2E Network Connectivity Service
BRS
BRS
Monitor & Optimize
Monitor & Optimize
Service 1: VLAN/ VxLAN
Service 1: VLAN/ VxLAN
Service 2: IPSec
Service 2: IPSec
SDN Monitor
SDN Monitor
Service 4: L3VPN
Service 3: VPC
Optimize
Optimize
Service 3a: L3VPN
Service 3b:
L2VPN
Service 5: L2VPN
API (s)
API (s)
Rel 1 Scope
SDN-O Drivers
SDN-O Drivers
Rel 1 Stretch Goal
VLAN/
VxLAN
VLAN/
VxLAN
L3 MPLS VPN
L3 MPLS VPN
IPSec
IPSec
SPTN
SPTN
VIM
VIM

10. Driver Architecture - Release-1
SDNO VPN lifecycle API (s)
Messagebus
Controller Driver Service
Rel 1 Scope
Driver Mgr.
Request to controller request/Model translator
Rel 1 Dependency
Netconf/Restconf Client
Service plugin-1
Service plugin-2 …
Service plugin-N
REST client Controller/
VIM
Controller instancr NBI
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.

11. vCPE Use Case for SDN-O – Controller/Driver responsibility
Service
Network
Controller
Ownership
Service-1: VxLAN
Overlay - Site access
Access Controller (ODL based solution)
ZTE
Service-2: IPSec
Overlay - PoP(vCPE) EGRESS
Overlay - DC GW Instance (INGRESS)
DC Controller- Openstack service
Huawei
Service-3:
BGP MPLS L3 VPN
Underlay – MPLS L3 VPN ( Between PE’s)
WAN underlay (ONOS based solution)

12. vCPE Use Case for SDN-O Stretch goal – Controller/Driver responsibility
Service
Network
Controller
Ownership L2
Underlay- Access
SPTN
CMCC/ZTE L3
Underlay – SPTN WAN network

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

14. Resources 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
China Mobile (driver)
Weiqiang Cheng
China Telecom
Chen Yan
Fu Borui
Huawei
Avinash
Kulbhushan Rana
>
Potential: RedHat and Intel

15. Current Release Plan 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. Release 1 Milestones Milestone Description Date M0
Planning Process Open
8 June 2016 M1
Planning Process Complete
1st July 2016 M2
Feature / Functionality Freeze
21st July 2016 M3
Model/API Freeze
8th August 2016 M4
Code Freeze
1st September 2016
RC0
First Release Candidate
15th September 2016
RC1
Second Release Candidate
1st October 2016
RC2
Third Release Candidate
15th October 2016
RC3
Release
3rd November 2016

17. Post Release 1 Roadmap
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. Other information Link to seed code: Vendor Neutral
Huawei:
Others ….
Vendor Neutral
Huawei ensured that all proprietary trademarks, logos, product names, etc. have been removed.
Others <TBD>: CT, CMCC, RedHat?
Meets Board policy (including IPR)

19. Key Facts Project name: SDN-O Repo name: Lifecycle state:
Jira project name:
Jira project prefix:
Repo name:
Lifecycle state:
Primary contact:
Project lead:
Mailing list tag:
Committers:
<To be added>

20. Appendix

21. Type/Degree of Participation Can Be Defined
Responsible
“Doer”
Accountable
“Buck Stops Here”
Consulted
“In the Loop”
Informed
“FYI”
Individual(s) (Many) who perform an activity or take part in a decision—responsible for action/implementation.
Individual (One!!) who has ultimate decision making and approval authority. Typically the owner of the budget.
The accountability for completing an activity or making a decision is often ambiguous because more than one person shares an element of responsibility toward it. A complex function may involve several people, all of whom see the function from their perspective or need. To clarify these complex relationships, we separate accountability from responsibility.
Responsible: “R’s” may also be delegated—particularly for larger tasks.
Accountable: the person whose neck is on the line if the activity/decision isn’t carried out. The person with the “A” may also choose to take the “R” for completing the task, or may delegate the “R” to another party. For a complex activity
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. Project roles AR R AR R AR R C I C AR R R I AR R R I A R R R I C AR R
Participant Role
Activities
Board
TSC
Release Mgr
Tech Lead
Committer
Developer
1. Market strategy AR R
2. Budget, expenses, etc. AR R
3. Release Planning AR R C
4. Project Execution I C AR R R
5. Code development I AR R R
6. Release Execution I A R R R
7. Project management/reporting I C AR R
8. Program management/reporting I A R C
9. Project –level Developer onboarding/outreach AR R R

23. RACI Charting Maps Roles with Activities
Functional Role:
A position assigned or assumed to accomplish an activity or sub-activity A C I R C I C
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 I R A
• Activities should take the following format (VAN): Verb
Adjective
Noun R A I A C A I R C A C R I

24. Region Employee Expense Statement Processing (Example)
Participant Role
Region Accounting
General Accounting
Activities
Employee
Secretary
Supervisor
1. Document expenses AR
2. Complete expense account form AR R C
3. Forward to supervisor A R
4. Review C AR
5. Approve I AR
An example of a completed RACI chart.
Let class read through and make sure they understand
Clarification of activities (if explanation needed):
#2 employee jot down information and ask secretary to put into computer format, consult with accounting if not sure of expense category.
#4 supervisor questions an expense that employee had documented.
#9 general accounting ask employees how they want to receive payment (paycheck or direct deposit).
6. Forward to region accounting R A
7. Classify expenses C AR
8. Audit AR
9. Determine payment type C AR