1. Open-O GS-O Project Proposal
Version 1.8
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
O-Common
GS-O
Ansible
Micro-Service
Bus
Decomposer
Abstract NBI
Compass
Common Parser
Service Lifecycle Mgr.
Service Decomposer
Service
Parser
Auth.
Runtime Engine …
SDN-O
NFV-O
Log
Model Designer
Abstract NBI
Abstract NBI HA
Catalog
SDN
Monitor
SDN Lifecycle Mgr.
NFV Monitor
NS Lifecycle Mgr.
Workflow
Inventory
VPN
VAS Mgr.
SDN Res.
Mgr.
NFV Res. Mgr.
Traffic Optimize …
Driver Mgr. …
Abstract SBI
Abstract SBI
Protocol Stack
Driver
Driver
Controller Mgr.
ACCESS/WAN SDN Controller Drivers
EMS/NMS Drivers
NFV SDN
Controller Drivers
VNFM Drivers
VIM Drivers …
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
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 GS-O to catalog
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 TOSCA project
Service description is encoded as TOSCA YAML document in CSAR archive
GS-O to Inventory
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
Catalog
GS-O
Inventory 4 5
SDN-O
NFV-O

7. Architecture – Internal details of GS-O
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 Inventory API
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 TOSCA project
Inventory API
SBI
Framework provided by Common TOSCA project
New code needed for SDN-O and NFV-O SBI drivers
BSS/Portal
Catalog API
GS-O GUI
GS-O
Catalog
NBI
Parser
API
Lifecycle Management
Decomposer
Catalog API
API
Executor
Inventory
SBI
Inventory API
SDN-O Driver
NFV-O Driver
SBI Framework
SDN-O
NFV-O
Rel 1 Scope
Dependency

8. Functional Scope
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
Design Service
Onboard Service
Create Instance
Activate Instance
Test Instance
Modify Instance
Assure Instance
Deactivate Instance
Delete Instance
Remove Service
Rel 1 Scope
Dependency
Rel 1 Stretch

9. Functional flow example (“Create NS Instance” flow)
BSS/Portal
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”.
Catalog API
GS-O GUI
GS-O
Catalog
NBI
Parser
API
Lifecycle Management
Decomposer
Catalog API
API
Executor
Inventory
SBI
Inventory API
SDN-O Driver
NFV-O Driver
SBI Framework
SDN-O
NFV-O
Rel 1 Scope
Dependency

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

11. Project roles Role Leader Project Technical Lead Brendan Hassett
Architecture
Testing ?
GS-O GUI
Dongyanyi
NorthBound Interface
Jinxin
Lifecycle Manager
Parser/Decomposer/Executor integration
Marko Milenkovic
Catalog API
ZTE ?
Inventory
Luji
SouthBound Interfaces
Houbin
Micro-services bus integration
Jiaxiangli

12. Functional responsibilities
Work area
Description
Resources
GS-O GUI
Modify the CMCC seed code to create a GUI to create/activate/deactivate/delete a Network Service instance
Jinxin
Shentao
GS-O NBI
Modify the Huawei seed code to create a RESTful interface to create/activate/deactivate/delete a Network Service instance
Lifecycle Manager
Modify the Huawei seed code to create/activate/deactivate/delete a Network Service instance
API for Parser, Decomposer, Executor
Create RESTful API to allow Lifecycle Manager to control Cloudify components
Marko Milenkovic
Tal Liron
SDN-O Driver
Create ARIA driver to control SDN-O using a RESTful interface
Houbin
NFV-O Driver
Create ARIA driver to control NFV-O using a RESTful interface
Inventory
Create RESTful API to allow Lifecycle Manager to create/update/delete/query a Network Service instance.
Luji
API for Catalog
Create RESTful API to allow Lifecycle Manager and GUI to access the catalog
ZTE?
Micro-services bus integration
Integrate all GS-O components with the micro-services bus
Jiaxiangli
Architecture
Make sure that GS-O is aligned with other Open-O components
Brendan Hassett
Testing
Make sure that units tests and integration tests are planned/executed ?

13. Release Plan Plan for Open-O Release 1 Plans for future releases
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 Vendor Neutral
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.100 BH, AB: comment “Parser decomposer and workflow not aligned” ??? Does ARIA expose specific APIs for these functions?
[BH] The Common TOSCA 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 Common TOSCA 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 Common TOSCA 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: Repo name: gso ?? Lifecycle state: Incubation
Jira project name: gso ??
Jira project prefix: gso ??
Repo name: gso ??
Lifecycle state: Incubation
Primary contact: Brendan Hassett,
Project lead: Brendan Hassett,
Mailing list tag: gso ???
Committers: