Page tree
Skip to end of metadata
Go to start of metadata


  • In order to catch up with the schedule of release 1, developers need to align the detailed information about APIs and data model inside project and cross projects, such as interaction sequence, interface parameters, and the structure of service template.
  • Reduce the risk of misunderstanding and rework.
  • Make sure we can accomplish M3 API& Model Freeze - this date is Aug 11, 2016 before the meeting, and it has been changed to Sept 1, 2016 later according to the latest OPEN-O Sun Release Plan.






Use Case

OPENO Userstory Residential



Please refer to the URL [[GSOAPI_Documentation]]


  1. NS template adds the outputs field to indicate the outputs of the NS. NFVO and SDNO return the outputs field in the Query NS SBI's response.The Service Designer supports the outputs field.The Catalog supports the outputs fields parse and query.
  2. The structure of request or response in the SDNO NBI is the same as the NFVO NBI

OPEN-O GSO NSD Specification

OPEN-O GSO NSD Specification

Common LCM Micro Service

To add a micro Service ,named LCM Common ,provided the NBI for GUI invoke,and invoke the GSO NFVO SDNO's NBI.HUAWEI and ZTE develop the service together.

Assignment of GUI

Action Items:

  • GSO needs to complete the node type definition before Aug 18
  • GSO NFVO SDNO need to instantiation base on the OPENO use case before Aug 20
  • HLD LLD of GUI and discuss Assignment with ZTE
  • HLD LLD of Common LCM Micro Service and discuss Assignment with ZTE


NS&VNF CSAR Model Specification

NSD TOSCA Specification

VNFD TOSCA Specification

NSLCM API Specification

VNFM Driver API Specification

Align L2VPN & L3VPN adapter interfaces

We have gone through L2VPN & L3VPN sbi adapter interfaces with newest interfaces, and make all details clear save for 6 issues list below:

1. network-side static router not found in api?

2. what's the actual meaning of besteffort/sharing?

3. what's the difference between mplstepolicy in top level and mpletepolicy in ParticularConstraint, how to use it?

4. how to express underlay id in API, e.g. PW id in controller.

5. for non-protect how to express? especially for PW

6. driver how to cope with unsupported attributes? what's the rule.

Site2DC Networking clarifying

We discussed networking in site2DC scene, and made an detailed solution:

1. for SFC in POP, ZTE will provide VASes, SFF, physical Bras (only for classifier), and controller. vCPE will direct traffic into SFC with VLAN tag.

2. for SFC in POP, SFC keep vlan tag as tenant id, and firewall configure need handle VLAN tag.

3. for DC, ZTE dc controller will create VNFs, vAPPs, and VLs, Huawei Controller will convert vlan to vxlan, and make router, gateway, ipsec ,and SFC over physical devices.

Site2DC SDNO Open-Tosca Model

We discussed networking in site2DC scene, and agreed on a rough model:

1. there should be a site2DC connection in top level of model.

2. site2DC connection depends on three segment: access vxlan, wan ipsec, DC vxlan.

SDNO provide template in catalog, and provide NBI for GS-O

We discussed GS-O and agreed:

1. SDNO should provide three SSAR, for Resident2Internet(operator), Enterprise2DC(operator), and Enterprise2DC(tenant)

2. SDNO provide NBI similar to NFVO ([[File:NSLCM API Specification-v0.1.pdf]]), but not same, NFVO specified attributes will be removed, and some minor changes.

SDN-O traffice design & implementation for monitoring & visualization & Steering & Optimization

1. Introduce TE+ Traffic optimize architecture to SDN-O project team, and also workflow and key technology

2. Confirm the API and inter-action between Monitor module/Optimizer module and Common Services(Micro-service Bus)

3. Define API and parameter between Monitor module and SDN-O Resource Manager(BRS)

4. Confirm the inter-action between TE-Driver Driver Manager?in release 1 the modules register within Micro-service Bus?the Monitor and Optimizer module communicate with other modules via Micro-service Bus

5. Define TE-Driver and controller NBI , provide the document to define the NBI of controller

6. Confirm the future work and code to be submitted of the four modules following graph of architecture 1


1. SDN-O Resource Manager(sub-project:sdno-vsite-mgr),
2. SDN-O Monitor(sub-project:sdno-link-flow-monitor),
3. SDN-O Traffic Optimizer(sub-project:sdno-mpls-optimizer),
4. SDN-O Driver(sub-project:sdno-driver-te)

Common Service

Driver Mgr. API & interaction sequence with SDNO/NFVO/driver

Sequence diagram: SDNO invokes SDN Controller service

Sequence diagram: NFVO invokes VNFM service

  • SDNO will use Driver Mgr. in Sun release and SDNC Controllers must register themselves to the Driver Mgr.
  • Driver Mgr. is not a must-have feature for NFVO in Sun release, each VNFM driver sub-project can decide if the driver should be registered to Driver Mgr. according to the manpower and timeframe

External System Register(ESR)

  • ESR should check the connection between the O and the External System when it is registered to ESR
  • ESR should promote the user if O can't establish connection to the External System
  • External System should be allowed to be registered to ESR even if the connection is not ready yet
  • Driver mgr. need to add a Restful API for the connection check to be used by ESR

Action Items:

  • add a Restful API for connection check in the Driver Mgr. API document wiki page
  • Driver developers Implement the check API for drivers

Protocol scope clarification

  • Saw jin explained the functionalities and scope of Protocol Stack
  • Protocol Stack acts as a proxy between a none-NETCONf aware client and a NETCONF server. Client sends a plain request to NETCONF Protocol Stack Microservice, then NETCONF Protocol Stack Microservice translate the request to a NETCONF request and send the request to the NETCONF server
  • Restful Stack Protocol should not be included in the scope

Action Items:

  • add some diagrams and descriptions in the Common Service release plan wiki page to explain the functionalities and scope of Protocol Stack
  • remove the Restful Stack Protocol from the Common Service release plan wiki page

A repository to accommodate cross-projects utility

  • A repository is needed for cross-projects utility
  • This would be a sub-project of Common service

Action Items:

  • will propose a sub-project under Common Service to TSC to accommodate the cross-projects utility

Microservice Bus

  • Sukesh asked for the file registration of microservice.
    • Registration by file is supported but only used by Microservice Bus internally and not recommended to other services to register
    • The config files are located in a local directory of the host node of Microservice Bus
    • The config files will not be dynamically reloaded at runtime due to performance reason
  • The plugin mechanism to integrate the Auth plugin and Driver Mgr. Plugin to Microservice Bus

Action Items:

Other topics

  • presented the service list wiki page : [[OPEN-O Services List]]
  • presented the swagger and metrics mechanism of Microservice Bus : [[Common_Service:Microservice_Bus_API_DocumentationSwagger_and_Metrics|Swagger_and_Metrics]]

Action Items:

  • Developers register the services to the service list wiki page
  • Developers add swagger and metrics implementation for each microservice according to the specification

Common TOSCA

Service template

Action Items:

  • will post the SDN-O WAN service template draft for discussion in the next week
  • will post the NFV-O domain service template draft for discussion in the next week
  • will post the GS-O E2E service template for discussion as the WAN and domain service template are ready
  • identify the gap between the current implementation and desired functionality of Model Designer according to the service template draft

TOSCA simple profile extension for Plan

Plan is missing in the TOSCA simple profile, the NFVO, SDNO and Model Designer developers suggest add a keyname in the service template definition

		description: create operation of this service template
		reference: Plans/
		planLanguage: bpmn4tosca
				description: xxx
				type: string
				required: false
				default: xxx
				description: xxx
				type: integer
				required: true
				default: xxx

Action Items:

  • will talk with Arthur and Tal to confirm how the Common Parser handles the extended keyname