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

There seem to be two classes of information to be stored in the controller:
* short-living information, such as, current topology 
* long-time information, such as, information about principle network domains, elements in such a domain, etc