1. Version 0.6 Draft – For Review 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 Driver Mgr. Orchestrator Service Model Designer 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 Driver Mgr. Model Designer

4.  Sub-project1  Microservice Bus  High Availability  Log  Sub-project2  Driver Manager  Protocol Stack  Authentication

5.  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

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

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

10.  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

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

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

14.  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

15.  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

17.  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

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

20.  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

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

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

25. Driver manager works with microservice bus, routes the service call from higher layers to the appropriate driver Drivers register to driver manager and the driver manager then register service for drivers to microservice bus Microservice bus plugin asks driver manager for the destination driver based on the routing rule of driver manager and then route the API call to the specific driver

27.  1 Drivers register to driver manager  2 Driver manager register service to service registry of microservice bus

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

32. Provide an integration Authentication for OPEN-O  Authentication 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.

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

36. REST API Gateway AUTH

37.  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  Microservice Bus: Tutorial  TBA

38.  Contact person  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  Developers committed to the project  TBA  Initial Committers  meng.zhaoxing1@zte.com.cn meng.zhaoxing1@zte.com.cn  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  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  saw.jin@huawei.com saw.jin@huawei.com

39.  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.  Stretch goals  Microservices bus self HA  Service Healthy Monitoring  Milestones <TBD – align with other projects)  Identified gaps  Describe your longer-term roadmap  Microservice self-healing & scaling  Centralized logging  RBAC Access Control

40.  Link to seed code (if applicable)  Vendor Neutral  All proprietary trademarks, logos, product names, etc. have been removed.  Meets Board policy (including IPR)  Align on OPEN-O license policy

41.  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:  meng.zhaoxing1@zte.com.cn meng.zhaoxing1@zte.com.cn  huabing.zhao@zte.com.cn huabing.zhao@zte.com.cn  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  saw.jin@huawei.com saw.jin@huawei.com