# Implementation Aspects of the goSDN Controller ## Why we do this in go Because it rocks, but let's see afterwards what can be written here. ## Storing Information Section XXX (Conceptual Design of a SDN Controller as Network Supervisor) discusses the need to store information about for element inventories and topology inventories. ### Element Inventories Storing information about network elements and their properties is a relative static process, at least when one considers potential changes over time. Typically such network elements are added to a network and they will remain in the network for a longer time, i.e., multiple minutes or even longer. ### Topology Inventory Every network has one given physical topology (G<sub>physical</sub> ) and on top of this at least one logical topology (G<sub>logical1</sub>). There may be multiple logical topologies (G<sub>n+1</sub>) on top logical topologies (G<sub>n</sub>), i.e., a recursion. Such logical topologies (G<sub>n+1</sub>) can again have other logical topologies as recursion or other logical topologies in parallel. A topology consists out of interfaces, which are attached to their respective network elements, and links between these interfaces. Mathematically, such a topology can be described as a directed graph, whereas the interfaces of the network elements are the nodes and the links are the edges. G<sub>physical</sub> ist a superset of G<sub>logical1</sub>. The topology inventory has to store the particular graph for any topology and also the connections between the different levels of topologies. For instance, the G<sub>logical1</sub> is linked to G<sub>physical</sub>. (needs to be clear if changes in n-1 graph has impact on n graph). For further study at this point: Which type of database and implementation of databases should be used to store the different topology graphs and their pontential dependencies? How should the interface between gosdn and this database look like? Here is an attempt to describe the above text in a graphical reprensetation (not ready YET!): ```mermaid graph TB SubGraph1 --> SubGraph1Flow subgraph "G_logical1" SubGraph1Flow(SubNode 1) Node1_l1[Node1_l1] <--> Node2_l1[Node2_l1] <--> Node3_l1[Node3_l1] <--> Node4_l1[Node4_l1] <--> Node5_l1[Node5_l1] end subgraph "G_physical" Node1[Node 1] <--> Node2[Node 2] <--> Node3[Node 3] Node4[Node 4] <--> Node2[Node 2] <--> Node5[Node 5] Node2 --> SubGraph1[Link to G_logical1] end ``` ### Potential other Inventories There may be the potential need to store information beyond pure topologies, actually about network flows, i.e., information about a group of packets belonging together. ## 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 network 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.