Newer
Older
# 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.
Martin Stiemerling
committed
### 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
Martin Stiemerling
committed
(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>.
Martin Stiemerling
committed
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 (kinda of...not perfect yet):
```mermaid
graph TB
SubGraph1 --> SubGraph1Flow
Node1_l1[Node1_l1] <--> Node2_l1[Node2_l1] <--> Node3_l1[Node3_l1] <--> Node4_l1[Node4_l1] <--> Node5_l1[Node5_l1] <--> Node1_l1[Node1_l1]
subgraph "G_physical"
Node1[Node 1] <--> Node2[Node 2] <--> Node3[Node 3]
Node4[Node 4] <--> Node2[Node 2] <--> Node5[Node 5]
Net_physical[Net_physical] --> SubGraph1[Reference to G_logical1]
### 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.
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
### neo4j
Due to the fact that network topologies, with all their elements and connections,
can be represented well by a graph, the choice of a graph database for persistence was obvious.
After some initial experiments with RedisGraph, Neo4j was chosen,
because Neo4j allows the use of multiple labels (for nodes as well as edges)
and offers a wider range of plugins.
The current implementation offers the possibility to persist different network elements
and their physical topology. It became clear that within the graph database one has to
move away from the basic idea of different independent graphs (topologies) and rather see
the whole construct as a single huge graph with a multitude of relations.
The following figure shows our first idea of a persistence of network topologies with neo4j.
```mermaid
graph TD
subgraph "representation in Database"
PND[PND 1]
A --> |belongs to| PND
B --> |belongs to| PND
C --> |belongs to| PND
D --> |belongs to| PND
E --> |belongs to| PND
A[Node 1] --> |physical| B[Node 2]
D[Node 4] --> |physical| B
B --> |physical| C[Node 3]
B --> |physical| E[Node 5]
A --> |logical1| B
B --> |logical1| C
C --> |logical1| D
D --> |logical1| E
E --> |logical1| A
end
```
The basic idea is to assign the different network elements to a specific Principal Network Domain (PND).
The different topologies are represented by a neo4j relationship between the network elements that are
stored as neo4j nodes. However, with this current variant it is not possible, as required in
[Topology Inventory](#topology-inventory), to represent topologies that are hierarchically
interdependent, since neo4j does not allow relations to be stored as properties (as described [here](https://neo4j.com/docs/cypher-manual/current/syntax/values/#structural-types)
## 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.
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.