From 01f9463f082f95021fd6cfc2ac6f5f2334f00f81 Mon Sep 17 00:00:00 2001 From: Malte Bauch <malte.bauch@stud.h-da.de> Date: Mon, 5 Oct 2020 13:12:47 +0000 Subject: [PATCH] Update 05-implementation.md --- documentation/design/05-implementation.md | 57 ++++++++++++++++++++++- 1 file changed, 55 insertions(+), 2 deletions(-) diff --git a/documentation/design/05-implementation.md b/documentation/design/05-implementation.md index 85fff63c8..be6e70b27 100644 --- a/documentation/design/05-implementation.md +++ b/documentation/design/05-implementation.md @@ -74,8 +74,8 @@ belonging together. ### 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) +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 @@ -114,6 +114,59 @@ stored as neo4j nodes. However, with this current variant it is not possible, as [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) +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. The main difference is, that for the different topologies separate nodes are created, to which so-called links belong. The links themselves form a connection between the respective network elements. A link can have several layer protocols, like OTUCN, ODUCN etc. + +```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 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) +- ... ## YANG to code -- GitLab