D[Label: 'Host,physical,logical1'] --> |Label: 'physical'| B
B --> |Label: 'physical'| C[Label: 'Host,physical,logical1']
B --> |Label: 'physical'| E[Label: 'Host,physical,logical1']
A --> |Label: 'logical1'| B
B --> |Label: 'logical1'| C
C --> |Label: 'logical1'| D
D --> |Label: 'logical1'| E
E --> |Label: 'logical1'| A
```
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)).
Furthermore, multiple links between the same nodes which belong to the same
topology are difficult to represent, since this model only provides a single
link between nodes of a certain topology.
For the reason mentioned above, a more complex idea for persistence is available
for the further development, which hopefully allows us to persist and map
network elements, PNDs and topologies with all their hirarchical dependencies.
The following figure tries to visualize this idea.
```mermaid
graph TD
subgraph "dependencies of topologies"
logical1 -->|related_to| physical
logical5 -->|related_to| physical
logical3 -->|related_to| logical1
end
subgraph "every node belongs to a specific PND"
Node1 -->|belongs_to| PND
Node2 -->|belongs_to| PND
Node3 -->|belongs_to| PND
Node4 -->|belongs_to| PND
Node5 -->|belongs_to| PND
end
subgraph "relationship between nodes (nodes can be linked by 0...n links)"
lp2[link_physical]
lp3[link_physical]
lp4[link_physical]
lp5[link_logical1]
lp2 --> |connects| Node4
lp2 --> |connects| Node2
lp3 --> |connects| Node2
lp3 --> |connects| Node3
lp4 --> |connects| Node2
lp4 --> |connects| Node5
lp5 --> |connects| Node1
lp5 --> |connects| Node2
end
subgraph "links are part of a topology"
lp1[link_physical]
lp1 --> |connects| Node1
lp1 --> |connects| Node2
lp1 --> |part_of| physical
end
subgraph "links can contain 1...n layers"
lp2 --> |contains| ODUH
lp2 --> |contains| OTUCN
lp2 --> |contains| ODUCN
end
```
The basic structure explained in the upper part remains the same.
However, the relations, which previously served as links between the respective
nodes, now become **separate nodes**. These nodes now act as links between the
respective network elements and are part of a network topology (which itself
is represented as a separate node in the graph). By this change, network
topologies can now be interdependent. Furthermore, as can be seen in the figure
above, you can add additional nodes to the link nodes by using this scheme.
So a physical link between two nodes could e.g. **contain** several cables.
All other information can be stored in the properties of the respective nodes/edges.
The above idea is not yet approved and there are still open questions.
- Is there a better solution for the assumption that there are several different physical connections between the same nodes than separate link nodes between them?
- Can topologies run over different PNDs -> membership to different PNDs?
- Where can we benefit from using different layers? (e.g. possible saving of unnecessary relations between nodes)
- Do the sdn controllers provide us with the necessary information to map the topologies in this way?
- ...
## 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.
## 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.
