05-implementation.md

# Implementation Aspects of the goSDN Controller


## Why we do this in go

## YANG to code

The base of the development of goSDN are YANG modules. The RESTful API used for RESTCONF is defined in an OpenAPI 2.0 file. This API documentation is generated from the YANG module. The YANG module description is also used to generate code stubs for the goSDN RESTCONF client.

\includegraphics{gfx/yang-schematics.pdf}

### YANG

YANG defines an abstract netwoprk interface. It is the foundation of the RESTCONF protocol. Several code generators exist to generate code stubs from a given definition.

### OpenAPI

OpenAPI - formerly known as Swagger - is a framework that defines RESTful APIs. We use OenAPI documentations to define the RESTCONF server implementation of the cocsn YANG modules.

### Toolchain

We use 3 different tools for the code generation workflow. For the RESTCONF server `yanger` is used to generate the OpenAPI documentation from the YANG file. `go-swagger` is used to generate a RESTCONF server with stubs for the REST calls.

The RESTCONF  client stubs used by goSDN are generated from YANG files using YGOT.

### Dependencies

For now we can only use the OpenAPI 2.0 standard. This is because `go-swagger` does not support OpenAPI 3.0 specifications yet.

## Storing Information

This section keeps by now some loose thoughts about what information has to be stored how and where. 

There seem to be two classes of information to be stored in the controller:
* short-living information, such as, current configured network flows or obtained network configuration out of use case #1 (CoCSN)
* long-time information, such as, information about principle network domains, elements in such a domain if directly learned from SBI, etc 

Long-time information should be persistenly stored in the database and survive reboots of goSDN etc. Short-Living information doesn't have to survive reboots of goSDN


### Some more details for implementation for the database(s)

We define the principle network domain (PND) and each piece of information of any PND has to be stored in relation the particular PND. 

Specification of a PND:
* Human readable name of PND
* Textual description for further information
* Set of supported Southbound-Interfaces, e.g., RESTCONF, TAPI, OpenFlow etc
* Physical Inventory Network Elements, hosts and links, pontentially only the SBI SDN controller

A PND entry must be explicitly generated, though some information can be automatically be generated, e.g., the physical inventory for use-case #1 (CoCSN) would mean that the information about the SBI domain specific SDN controller is entered.