Open-O GS-O Project Proposal

1. Open-O GS-O Project Proposal Version 1.7 Brendan Hassett

2. Overview • Project Name – GS-O • Repository name - gso • Project Description • Implement the GS-O component for the Open-O project. • GS-O is responsible for Global Service Orchestration to provide End-to-End orchestration of any service on any network. • Participants • China Mobile, Gigaspaces, Huawei, ZTE

3. Overview • Project Scope • Problem description - A network operator needs a method to create and manage an end-to-end service across SDN and NFV domains, using a single network service description. • Architecture will be micro-services style, with RESTful APIs between components. • GS-O will be a single project, there is currently no plan for sub-projects.

4. Testing and Integration Plans • GS-O Integration Test Strategy • GS-O test team will be established to deliver the test strategy • GS-O splits into microservices with well defined and agreed REST APIs • Automation of GS-O deployment and testing will be based on the integration test plan • Integration 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 • Iterative addition of Systems 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 • It is likely that most testing can be performed using simulated SDN-O and simulated NFV-O • If possible, GS-O will use the test framework that is developed in the SDN-O project • Sub-Project / Microservice Test Strategy • There will not be sub-projects, GS-O will be a single project • Development in all microservices will be test driven with the goal of 50% unit test coverage • Integration into OPEN-O Test Strategy • Testing of GS-O integrated into OPEN-O will be delivered based on OPEN-O Test Strategy defined by the OPEN-O Test Team • GS-O will be a key component for testing End-to-End functionality in Open-O

5. Architecture Alignment Portal TOOLs GUI Portal … Foreman Common Service Orchestrator Service This project will provide • GS-O GUI Portal • GS-O Abstract NBI • GS-O Service Lifecycle Manager • GS-O Service Decomposer • GS-O Service Parser O-Common GS-O Ansible Decomposer Abstract NBI Micro-Service Bus Compass Service Lifecycle Mgr. Service Decomposer Service Parser Common Parser Auth. Runtime Engine … SDN-O NFV-O Log Model Designer Abstract NBI Abstract NBI HA Catalog SDN Lifecycle Mgr. SDN Monitor NS Lifecycle Mgr. NFV Monitor VPN VAS Mgr. Inventory Workflow NFV Res. Mgr. SDN Res. Mgr. Traffic Optimize … Driver Mgr. … Abstract SBI Abstract SBI Protocol Stack Driver Driver VIM Drivers Controller Mgr. ACCESS/WAN SDN ControllerDrivers EMS/NMS Drivers NFV SDN ControllerDrivers VNFM Drivers … This project will depend on • Micro-Service Bus • Authentication • Catalog • Inventory • Model Designer Rel 1 Scope Dependency

6. Architecture - APIs • BSS/Portal to GS -O • RESTful interface, no industry standard exists yet, ETSI NFV or MEF Legato may be useful as a reference. • GS-O to catalog • Protocol to be defined by the Common Services project • Service description is encoded as TOSCA YAML document in CSAR archive • GS-O to Inventory • Protocol to be defined by the Common Services project • GS-O to SDN-O • RESTful, JSON encoding • GS-O to NFV-O • RESTful, TOSCA model, YAML encoding • Specified by ETSI NFV Os-Ma-nfvo interface BSS/ Portal 1 2 3 GS-O Inventory Catalog 4 5 NFV-O SDN-O

7. Architecture – Internal details of GS-O BSS/Portal Catalog API GS-O GUI • GS-O GUI will be based on code from CMCC • Need to disable some NFV-specific code • Need to integrate with Catalog API • Need to integrate with micro-services bus • Lifecycle Management will be based on code from Huawei • Need to integrate with ARIA API • Need to integrate with Catalog API • Need to integrate with Inventory API • Need to integrate with micro-services bus • Parser, Decomposer and Executor will be based on ARIA from Gigaspaces • To be developed in Common TOSCA project • A local instance of ARIA will be embedded in GS-O for Release 1 • Need to develop or improve RESTful APIs • For Release 1, Decomposer and Executor are tightly bound together • Catalog API • Provided by Open-O Common project • Inventory API • Provided by Open-O Common project • SBI • Framework provided by Common TOSCA project • New code needed for SDN-O and NFV-O SBI drivers GS-O Catalog NBI Parser API Lifecycle Management Decomposer Catalog API API Executor SBI Inventory Inventory API NFV-O Driver SDN-O Driver SBI Framework SDN-O NFV-O Dependency Rel 1 Scope

8. Functional Scope Design Service Onboard Service • For Release 1, GS-O will implement the following service lifecycle functionality • Create Global Service Instance • Activate Global Service Instance • Deactivate Global Service Instance • Delete Global Service Instance • Release 1, GS-O stretch goal • Assure Global Service Instance (view status and raise alarms) • It is assumed that common components will implement the following service lifecycle functionality • Design Global Service • Onboard Global Service to catalog • Remove Global Service from catalog Create Instance Activate Instance Test Instance Modify Instance Assure Instance Deactivate Instance Delete Instance Remove Service Dependency Rel 1 Stretch Rel 1 Scope

9. Functional flow example (“Create NS Instance” flow) BSS/Portal Catalog API GS-O GUI • Consumer uses GUI to select a Global Network Service from the Catalog, submits request to GS-O. • NBI receives request (Catalog reference + parameters), passes request to Lifecycle Management. • Lifecycle Management submits request to parser, response is a graph of service components. • Lifecycle Management stores the service and service components in Inventory, with status “Creating”. • Lifecycle Management submits request to Decomposer/Executor. • Executor calculates the correct workflow sequence and send sub-graphs to each SBI driver. • SDN-O driver renders the SDN sub-graph to a JSON or XML document, sends a RESTful request to SDN-O, parses the response from SDN-O, and returns the output parameters to the Executor. • NFV-O driver renders the NFV sub-graph to a TOSCA-YAML document, sends a RESTful request to NFV-O, parses the response from NFV-O, and returns the output parameters to the Executor. • Lifecycle Management updates Inventory to status “Created”. GS-O Catalog NBI Parser API Lifecycle Management Decomposer Catalog API API Executor SBI Inventory Inventory API NFV-O Driver SDN-O Driver SBI Framework SDN-O NFV-O Dependency Rel 1 Scope

10. Resources • Contact person – Brendan Hassett • Developers committed to the project • CMCC Shentao • GigaspacesTal Liron • Huawei Brendan Hassett, Marko Milenkovic, Jinxin, Dongyanyi, Houbin, Jiaxiangli, Luni • ZTEChendong, Luji, Fanchanghu, Hewei • Initial Committers • CMCC Shentao • Gigaspaces Tal Liron • Huawei Brendan Hassett, Jinxin • ZTE Chendong

11. Project roles

12. Functional responsibilities

13. Release Plan • Plan for Open-O Release 1 • Minimum viable product • Create Global Service Instance • Activate Global Service Instance • Deactivate Global Service Instance • Delete Global Service Instance • Stretch goals • Assure Global Service Instance (view status and raise alarms) • Milestones • Planning complete 1 July 2016 • Scope freeze 21 July 2016 • API freeze 11 August 2016 • Code freeze 1 September 2016 • Release Candidates 15 September, 29 September, 20 October • Formal release 3 November 2016 • Identified gaps • Integration with catalog and micro-services bus • Plans for future releases • Add end-to-end view of resource inventory and status • Add optimization functionality

14. Other information • Seed code • GUI github.com/Open-O/NFV-O.git • NBI + Lifecycle Manager github.com/KoderLee/openoseed/tree/master/gso/org.openo.crossdomain.servicemgr • Parser, Decomposer and Executor github.com/aria-tosca • Vendor Neutral All proprietary trademarks, logos, product names, etc. have been removed • Meets Board policy (including IPR)

15. Open issues from TSC review 2016-06-08 Slide #5, #7: O.100BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIA expose specific APIs for these functions? [BH] The TOSCA Common project will define the ARIA APIs. O.101 BH: Does GS-O NBI use TOSCA YAML as an input? Interact with the Model Designer? Pls provide pointer to API [BH] Model Designer writes the Service Description (YAML in CSAR) to the Catalog. GS-O GUI allows user to select a service from the catalog. GS-O GUI sends the catalog reference to GS-O through the NBI. GS-O (actually Lifecycle Manager) reads the Service Description from the Catalog using the reference received over the NBI. O.102 BH: does the Service Decomposer take NSD+VNFFG as an input? Will it split the VNFFG? [BH] We are working with Gigaspaces on the capabilities of the parser. The current plan is that the TOSCA Simple Profile for NFV will be supported. In Release 1, there will be no functionality in GS-O to split the forwarding graph. O.103 BH: who develops the Catalog project? No commit for rel1??? [BH] ZTE will develop the Catalog in the O-Common project. Slide #6: O.104 BH: describe the proposed NB API and its potential of integration with any existing BSS. Any DM exposed north bound? How will the proposed API interact with SID? [BH] We are working with Gigaspaces on this issue. In Release 1, the GS-O NBI model will be loosely based on the NFV Simple Profile for TOSCA. O.105 BH: is Os-Ma-Nfvo not the proposed interface for 1? Vs. the interface 4 towards the NFVO? It assumes that ETSI model has NO information for the physical network! [BH] The GS-O NBI may include some connectivity information which is not part of Os-Ma-Nfvo. O.106 BH, AB: relies on Common – TOSCA catalog? CSAR is only API requirement for integration? What protocol? [BH] Waiting for APIs from the Catalog project. O.107 BH: what is the semantics of interface 3 to the SDN-O component – just E2E connectivity request? Need additional parameters… [BH] Waiting for NBI and model from the SDN-O project. Current indications are that this model will be very simple for Release 1. Slide #8: O.108 BH: define “Service” [BH] In this context, the Service is an Global End-To-End Service.

16. Risks • Data models for interfaces are not defined yet • Gigaspaces will present proposals on how the GS-O NBI could be expressed as a TOSCA/YAML document and how this document could be used to inspire the SDN-O NBI and NFV-O NBI. • Uncertainty over which workflow execution engine should be used • For Release 1, GS-O intends to use the ARIA parser with the ARIA execution engine, because this is the lowest risk solution. • Development and Integration tools are not ready • Each contributing company can use their own development and integration tools, but this will add cost and complexity to the project.

17. Key Facts • Project name: • Jira project name: gso ?? • Jira project prefix: gso ?? • Repo name: gso ?? • Lifecycle state: Incubation • Primary contact: Brendan Hassett, brendan.hassett@huawei.com • Project lead: Brendan Hassett, brendan.hassett@huawei.com • Mailing list tag: gso ??? • Committers: • brendan.hassett@huawei.com • tal@gigaspaces.com • saw.jin@huawei.com • shentao@chinamobile.com • chendong@zte.com.cn