1. Version 0.9 Huabing Zhao zhao.huabing@zte.com.cn

2.  Project Name: Common Service  Repository name: commonservice  Project Description Provide the common services for all the other OPEN-O components ， including Microservice bus, HA, Driver Manager, Log, Authentication and Protocol Stack.  Project Participants:  China Mobile, Huawei, ZTE  Open for others who are interested

3. In Scope SDN Driver VNFM Drivers VIM Drivers ACCESS/WAN SDN Controller Drivers NFV SDN Controller Drivers Orchestrator Service Portal TOOLs Foreman … Ansible GS-O Service Decomposer Service Lifecycle Mgr. Service Formation Abstract NBI SDN-O SDN Res. Mgr. Abstract NBI Abstract SBI NFV-O NFV Res. Mgr. NFV Monitor NS Lifecycle Mgr. Abstract NBI Abstract SBI VPN SDN Lifecycle Mgr. Traffic Optimize VAS Mgr. … SDN Monitor O-Common Lifecycle Mgr. Framework Template Mgr. Model Driven Framework Policy Driven Framework Common Res. Mgr … Compass Common Service Auth. Log Workflow … Catalog Micro-Service Bus Protocol Stack HA EMS/NMS Driver Parser NFV Driver Inventory Driver Mgr. Model Designer

4.  Integration Test Strategy  External and internal interfaces are to be agreed first  Service Registration/Unregistration Interface between Microservice bus and managed services  Interface between HA and managed services  Interface between HA and Microservice bus  Interface between Authentication and Portal  Interface between Dirver Mgr. and Microservice bus  Interface between Dirver Mgr. and drivers  Each sub-team for individual modules are responsible for unit testing separately  The modules in Common Service are independent of each other  Integration into OPEN-O Test Strategy  Common Service will be the offset 0 project and should be available earlier for integration test with depended projects in each release  Have a representative to join the testing project and make sure the testing of Common Service integrated into OPEN-O will be delivered based on OPEN-O Test Strategy defined by the OPEN-O Test Team

6.  Simplify the communication between services  Within the OPEN-O, there are a lot of service instances, e.g., Catalog, Res Mgr., LCM Mgr., Drivers. These instances are distributed on multiple hosts. That make the communicate between service instances complex because the consumers need to know the addresses of all the service providers. Besides, some services may have multiple instances, which make the consumer harder to locate the service provider. Microservice bus provide a service registration/ discovery and routing mechanism to simply the communications between services. The consumer only need to talk with microservice bus without any address information of individual service providers.  There are three kinds of communications to be supported:  Point to Point  Broadcast  Publish/Subscribe

7.  Features in release 1  Service Registration – API, file, UI  Service Discovery  Service Call Routing  API Call Logging  Asynchronous Message Routing-Comet  Features in future releases  Service Registration – proxy  Asynchronous Message Routing-Others

9.  1 Service Registration/Unregistration  2 Query service instance by service name  3 Consumer call service via API Gateway  4 API Gateway route service call to provider  5 Proxy gets service information from service container environment parameters  6 HA update service status into service registry

10. Support multiple service registration approaches with minimum invasion to the existing service implementation.  Registered via config file when deploying  Server provider registers itself when starting  Service proxy registers for the service provider  Administrator registers the service provider via UI

12. Provide HA Capability for OPEN-O Components As an E2E service orchestration platform, OPEN-O is intended to be one of the core business systems for carriers, which means that the systems should have no single point of failure, and should automatically scale out when facing increasing workload. HA component monitors the healthy of all the services of OPEN-O, for example, Res Mgr., LCM Mgr., Drivers, etc., and provides the self-healing and scaling capabilities.

13.  Access Layer Access layer HA is implemented by load balancer and microservice bus cluster  Load balancer(DNS Server/LVS etc.) –not in HA module scope, OPEN-O can use existing load balancer solution  Microservice bus cluster– in scope  Service Layer Service layer HA is implemented by HA module and microservice bus  load balancing for Stateless services  Master-slave for stateful services  DB Layer DB layer HA is implemented by the DB used by individual services or business logic of individual services- not in HA module scope

14.  Features in release 1  Microservice Bus Cluster  Load balancing for stateless service  Service healthy monitoring  Features in future releases  Master-slave support for stateful service  Service degradation(Work with Microservice Bus API Gateway)  Automatically scale out the service with increasing workload  Service self-healing

16.  1 Service healthy monitoring  KPI collecting  Heartbeat testing  Periodically call a dedicated heartbeat interface  Tell from the result of normal service invoking  2 Service scaling & self-healing  Create/Start service  3 Update service status into service registry

17. In ServiceOverloaded Failed Start Terminate KPI Abnormal Detected KPI Return to Normal Heartbeat Failed  HA changes the status of overloaded service into registry, So API Gateway will not route more incoming requests to it until its KPI return to normal  HA automatically create new service instances based on scaling policy(for example: 80% current instances are in overloaded status)  Failed Services will be isolated and terminated by HA

19.  There are a lots of services in OPEN-O, and each service may have multiple instances when deployed. As a result, logs are distributed in different servers, which make it’s difficult to looking and finding problem in logs. Log service is targeted to solve this problem by the below methods Aggregate logs into a central storage Parse& Enrich GUI Search & Visualizing tool  Support Audit log(Security, System, Operation, etc.) and Trace log

20.  Features in release 1  Define a log format standard across all services  Individual service save log in local file  Features in future releases  Centralized log collecting  Log parse & enrich  GUI for log searching & analytic

22.  1 Log collecting interface  File  Syslog  Stdin

24.  Release 1: DriverMgr provides Driver registration and query capabilities. It is based on MicroserviceBus and is not visible to SDN-O or NFV-O. SDN-O or NFV-O send requests to MicroserviceBus, which then obtains usable drivers from DriverMgr. DriverMgr finds usable drivers and returns this information to MicroserviceBus. Finally, MicroserviceBus sends the SDN-O or NFV-O requests to the specific driver.  Expanded target: DriverMgr provides registration and automatic distribution for many drivers and controllers. Vendors are moving toward providing multiple controllers with multiple drivers, and drivers and controllers will form many-to-many relationships. To meet the requirements brought by this trend, DriverMgr automatically distributes specific driver and controller. After SDN-O or NFV-O sends a request, it does not need to know where that request is finally processed. For example, SDN-O and NFV-O only needs to provide a network element ID for DriverMgr to send automatically information to that particular driver and controller.

27. RESTCONF Protocol Stack : A REST like protocol running over HTTP for accessing data defined in YANG using datastores defined in NETCONF. RESTCONF is an IETF draft that describes how to map a YANG specification to a RESTful interface. RESTCONF Protocol Stack provide standard API of RESTCONF NETCONF Protocol Stack : The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF Protocol Stack provides standard API of NETCONF

29. Provide an integrated Authentication and Authorization for OPEN-O  Auth service : As it is one of the common services, can effectively guarantee the user access to system resources. We will not support the concept of tenant in the first release, which will be discussed in the future.

30.  User Management  Login and Logout  Session Management  RBAC Access Management

33.  1 create users  2 register roles and access rights  3 verify user  4 validate/invalidate token

34.  OPENAPI  https://openapis.org/specification https://openapis.org/specification  https://github.com/OAI/OpenAPI- Specification/blob/OpenAPI.next/versions/3.0.md https://github.com/OAI/OpenAPI- Specification/blob/OpenAPI.next/versions/3.0.md  Documents  API documents and Tutorials

35.  Contact person  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  Developers committed to the project  TBA  Initial Committers  wangchengli@chinamobile.com wangchengli@chinamobile.com  denglingli@chinamobile.com denglingli@chinamobile.com  sukeshac@huawei.com sukeshac@huawei.com  tian.ming@huawei.com tian.ming@huawei.com  dongyanyi@huawei.com dongyanyi@huawei.com  meng.zhaoxing1@zte.com.cn meng.zhaoxing1@zte.com.cn  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  wang.yonggang131@zte.com.cn wang.yonggang131@zte.com.cn  tang.hua52@zte.com.cn tang.hua52@zte.com.cn

36. Sub-module/tasklead Microservice BusZTE High AvailabilityZTE Driver Mgr.Huawei AuthenticationHuawei LogZTE Protocol StackHuawei

37.  Current release plan  This is the Release 1 project  Minimum viable product  Provide integration framework for OPEN-O services  Log format standard  Simple user/name authentication  Driver mgr.  Protocol stack  Stretch goals  Microservices bus self HA  Service Healthy Monitoring  Milestones  aligned with TSC release plan  Identified gaps  Describe your longer-term roadmap  Microservice self-healing & scaling  Centralized logging & visual analysis  RBAC Access Control

38.  Link to seed code (will add to Github when LF provides)  Vendor Neutral  All proprietary trademarks, logos, product names, etc. have been removed.  Meets Board policy (including IPR)  Align on OPEN-O license policy

39.  Project name:  Jira project name: Common Service  Jira project prefix: commonservice  Repo name:commonservice  Lifecycle state: Proposal  Primary contact: huabing.zhao@zte.com.cnhuabing.zhao@zte.com.cn  Project lead: huabing.zhao@zte.com.cnhuabing.zhao@zte.com.cn  Mailing list tag:  Committers:  wangchengli@chinamobile.com wangchengli@chinamobile.com  denglingli@chinamobile.com denglingli@chinamobile.com  sukeshac@huawei.com sukeshac@huawei.com  tian.ming@huawei.com tian.ming@huawei.com  dongyanyi@huawei.com dongyanyi@huawei.com  meng.zhaoxing1@zte.com.cn meng.zhaoxing1@zte.com.cn  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  wang.yonggang131@zte.com.cn wang.yonggang131@zte.com.cn  tang.hua52@zte.com.cn tang.hua52@zte.com.cn