diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1c0b2ccd34501fa6f7ba6a21c40ad6cedfe6796f..f349425303deb49011ea9c21fb27879088fdbb5f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,5 +1,6 @@
variables:
SECURE_ANALYZERS_PREFIX: registry.gitlab.com/gitlab-org/security-products/analyzers
+ DOCKER_IMAGE_SHA: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
stages:
- .pre
diff --git a/documentation/README.md b/documentation/README.md
index eeeb9d0197a53ce7f9f58c4b1cb4659c62badf3e..a3a240d010974156e93d387d0faba4ff1ee7dc79 100644
--- a/documentation/README.md
+++ b/documentation/README.md
@@ -1,3 +1,11 @@
+# Minutes
+
+* [2020-12-07](http://portainer.danet.fbi.h-da.de:4000/MLAkHxUCS_W4njtf2sC63Q#)
+
+* [2020-12-03](http://portainer.danet.fbi.h-da.de:4000/q1IPsSO0TnOyk7Mcq1S38g#)
+
+* [2020-11-30](http://portainer.danet.fbi.h-da.de:4000/n5W9v9p5SzWVnK_N7kDhcQ#)
+
# Markdown Design Document
Uses [pandoc](https://pandoc.org/MANUAL.html#pandocs-markdown) flavoured markdown.
diff --git a/documentation/design/00-preamble.md b/documentation/design/00-preamble.md
index f79b92f4ec298da2ea9f3be3426025b3eac771e1..3294059351cdefc1e6e16c2da217fb2b1bd68c05 100644
--- a/documentation/design/00-preamble.md
+++ b/documentation/design/00-preamble.md
@@ -2,8 +2,9 @@
title: "goSDN"
subtitle: "A networking drama"
author:
- - "Martin Stiemerling"
+ - "Malte Bauch"
- "Manuel Kieweg"
+ - "Martin Stiemerling"
bibliography: [./bibliography.bib]
header-includes:
- \usepackage{graphicx}
diff --git a/documentation/design/02-related-work.md b/documentation/design/02-related-work.md
index f19af70b0195ad0adf68fb70934d2a0d0715358d..29fc520b2654c7577d4731b664b761d335f498bb 100644
--- a/documentation/design/02-related-work.md
+++ b/documentation/design/02-related-work.md
@@ -1,5 +1,7 @@
# Related Work
## This
+- Other earlier works on SDN controllers, such as, Floodlight, ONOS, OpendayLight, POX
+- Discription of the SB-Protocols
### And that
\ No newline at end of file
diff --git a/documentation/design/04-conceptual-design.md b/documentation/design/04-conceptual-design.md
index ef3665ceef1a552e58cc2a34663665c803b6af3c..6fcdbc5437a55e3c91b3fed9ffcd59d24c5a7b1a 100644
--- a/documentation/design/04-conceptual-design.md
+++ b/documentation/design/04-conceptual-design.md
@@ -4,32 +4,32 @@
## Conceptual Structures
-This section discusses the basic conceptual organization forms for data networks, as this seems to not clear in many contexts. The main purpose is to clarify what in a network has to be managed, how it has to be managed and by what entity it has to be managed.
+This section discusses the conceptual organizationak forms of data networks, as this seems not to be clear in many contexts. The main purpose is to clarify what in a network has to be managed, how it has to be managed and by what entity it has to be managed.
### Principal Network Domain (PND)
-Any network consists out of basic components that are the collection of (network) elements used to form such particular network. These components, let it be any device attached to this network and the (physical) links, with their control-, data-, and management planes, form the Principal Network Domain (PND). A network controller can be
+#### Definition
-* directly in charge of the devices in the PND and thus be able to manage these network elements directly,
-* or connect to a different lower network controller. The network controller would be only able to indirectly communicate with the network elements via the lower network controller or even, in case of a recursion of network controllers, only be able to talk to an even lower level network controller.
+Any network consists out of basic components that are the collection of (network) elements used to form such particular network. These components, let it be any device attached to this network and the (physical) links, with their control-, data-, and management planes, form the Principal Network Domain (PND). Such a PND wil be typically under a single control, e.g., a University faculty, a company, or a data center owner.
-The differentiation between the PND and the following definitions of network domain, e.g., IP network, etc is important for the design of a network controller that is supervising a network in its whole. The PND is the concept used by the network controller to keep track of all hosts and links associated~\footnote{XXXwhat means \emph{associated} exactly?} to this controller.
+The term PND does not express anything about logical network abstractions, such as VLANS, IP addresses, forwarding capabilities, etc. It is solely a construct to give all elements in a network a home.
-A single controller may be in charge of multiple PNDs.
+For our purpose of managing a network from a network controller, we define that such a controller is
-### Network Domain (ND)
+* directly in charge of the devices in the PND and thus be able to manage these network elements directly or,
+* connected to a different lower network controller. The network controller would be only able to indirectly communicate with the network elements via the lower network controller or even, in case of a recursion of network controllers, only be able to talk to an even lower level network controller.
-A network domain is the collection of network elements and links connecting the elements while these entities, i.e., the elements and links, can be either physically or logical. Examples for
+The differentiation between the PND and the following definitions of network domain, e.g., IP network, etc is important for the design of a network controller that is supervising a network in its whole.
-* physical entities: an Ethernet switch with Ethernet links or an optical switch with fibre connections
-* logical entities: a VLAN-enabled Ethernet switch where the VLANs from a logical topology on top of the physical infrastructure.
+A single controller may be in charge of multiple PNDs at the same time, though there may be multiple instances of this controller at the same time.
+Any network element or host can only be part of a single PND. In case a device resides on the edge between two PNDs, e.g., a router, such a device will be under the control of only one of the PNDs, but it will be designated as a gateway device between these two (or more) PNDs.
-A network domain is bound to a single PND. Network domains can be part of network domains, i.e., this is a case of recursion.
+An example for a PND:
+* Ethernet switches with Ethernet links
+* DWDM optical switches with fibre connections
-## Building Blocks
-
-Some conceptual building blocks for a network supervisor:
+#### Information to handle
* **principal element inventory**
@@ -39,6 +39,23 @@ Some conceptual building blocks for a network supervisor:
This contains all known links and their connection to interfaces of elements out of the principal element inventory.
+* ** Southbound Interface (SBI) **
+ The SBI to be used for this PND. The intention is to have one SBI for any given PND in order to configure the members of the PND.
+
+### Logical Network Domain (LND)
+
+#### Definition
+
+A logical network domain (LND) is the implementation of a network domain within a PND or within a LND. Such a LND defines what protocols are to be used and builds on top of the structure of the underlying PND or LND. Two exemplary examples:
+* a LND on top a PND: a VLAN-enabled Ethernet switch where the VLANs from a logical topology on top of the physical infrastructure.
+* a LND on top of an underlying PND: an IP subnetwork based on a VLAN LND.
+
+LNDs specify the operational parameters, such as forwarding capabilities (e.g., Ethernet, VLAN Ethernet, IP, etc), which elements of a PND are part of the LND, etc.
+
+A logical network domain is bound to a single PND. Logical network domains can be part of logical network domains, i.e., this is a case of recursion.
+
+#### Information to handle
+
* **domain element inventory**
contains the elements part of a particular network domain and it has to be a (sub)-set of the elements of the principal element inventory or a logical abstraction, such as a container or a virtual machine.
@@ -47,6 +64,65 @@ Some conceptual building blocks for a network supervisor:
This contains all known logical links and their connection to interfaces of elements out of the domain element inventory.
+* ** Southbound Interface (SBI) **
+ The SBI to be used for this LND. This may be different from the SBI of the PND and allow so to span logical networks with their own SBI-implementation. One possible example is that the PND may use Ansible-scripts to setup the basic configuration of the devices, e.g., switch-on interfaces, enable Openflow etc and allow the LND to use Openflow for its operation. A second LND may use a RESTCONF-approach to configure its devices.
+
+
+
+## Different Types of Southbound Interfaces
+
+The communication with the network elements is facilitated via the Southbound Interface (SBI). The SBI allows an entity external to the network element (NE) to control all or certain behaviors of such NE. We differentiate between three basic SBI types for our further discussion:
+* Flow-based: a controller can instruct the NE to alter the forwarding of particular flows based on a fixed set of forwarding instructions and filters.
+* Topology-based: a controller can instruct the NE to alter the topology of a network, e.g., by switching interface on or off, but it may not be able to alter the forwarding of flows
+* Programmability-based: a controller can load the forwarding logic as a program on the NE and can include the forwarding rules as part of the program code.
+
+It is important to note that the basic types of SBI can stand on their own, but they can also possibly appear in combinations, e.g., a combined flow- and programmability-based SBI sounds possible.
+
+## Core functions
+
+The short description of core functionality of goSDN: Keep track of everything and be in control of everything.
+
+An half-unsorted list of core functions:
+* manage SBIs
+ * Load SBIs
+ * Use predefined SBI-Interfaces
+ * Configure SBI instance , e.g., IP/port of SBI server, certificates, etc
+ * SBI generic error handling, such as, failure of connection to SBI server
+ * Link between SBI errors and "SBI-content" (e.g., topology information), i.e., what to do if a SBI instance fails.
+ * Denote PND to SBI relationsship
+* read-only access to network information (SBI-content)
+ * learn about NEs, interfaces, links and hosts in a PND via the SBI
+ * learn about NEs, interfaces, links and hosts in zero, one or more LND via the SBI
+ * learn about changes with respect to NEs, interfaces, links and hosts in PNDs and LNDs
+ * store information about NEs, interfaces, links and hosts in PNDs and LNDs
+ * related this information to each other, such as, what interface is attached to what NE or what link is connecting which interfaces
+* write access to network information
+ * use all functions of the "read-only" part above in order to learn about what's happening in the network
+ * create a LND
+ * use the topology information to calculate possible paths between parts of the network or between attached hosts in a PND or LND
+ * write information to SBI
+ * topology information
+ * flow forwarding information
+ * general configuration information, e.g., interface up (?)
+ * handle feedback from SBI (success, failure, issues)
+ * received this type of information
+ * process it in a meaningful way
+* SBI-Interface things
+ * PND/LND differentiation needed
+ * Exchange of validity information, such as timer for information entries (i.e., NEs, interfaces, links and hosts )
+* Representation of network information (NEs, interfaces, links and hosts ) in the core
+ * Representation should be independent of SBI but requires specific information provided by or via the SBI
+ * Readling list for Representation
+ * our current shoot-through-approach (TAPI JSON dump to DB)
+ * TAPI as information model in the core
+ * No use for us: ACTN:
+ * https://www.ietfjournal.org/actn-from-standard-to-interop/
+ * Storage in the graph database
+
+
+
+## Parking Lot for pending Stuff
+
* **host configuration**
diff --git a/documentation/minutes/2021-03-01-minutes.md b/documentation/minutes/2021-03-01-minutes.md
new file mode 100644
index 0000000000000000000000000000000000000000..fa3616a554e7cc72bc29f43d4b9386b7d111ad46
--- /dev/null
+++ b/documentation/minutes/2021-03-01-minutes.md
@@ -0,0 +1,39 @@
+# Agenda / Minutes
+
+## goSDN
+
+- [ ] Unit Testing
+- [ ] Integration Testing
+ - Terraform/Docker Testumgebung
+- [ ] ARCHITECTURE.md
+- [ ] Wo wollen wir für 0.1.0 sein?
+ - abgeschlossener Testlauf im Lab / virtual Lab koennte hier sinnvoll sein (auch im Hinblick auf [MPSE](#mpse)/[OpenSource](#opensource))
+ - Releasedatum Ende März
+ - Get/Set/Subscribe w/gNMI
+
+## MPSE
+
+- [ ] Zielsetzung
+- [ ] Wo müssen wir sein, um goSDN sinnvoll für ein MPSE benutzen zu können
+ - Dokumentation vorantreiben um einen einfachen Einstieg zu ermöglichen.
+- [ ] Potentielle Inhalte
+ - Controller Dashboard Web Application
+
+## OpenSource
+
+- [ ] Wo müssen wir sein, um goSDN sinnvoll OpenSource machen zu können
+- [ ] Ist das mit Hinblick auf Hubraum zZ. grade überhaupt sinnvoll?
+
+## Telekom
+
+- [ ] Was brauchen wir fürs Pitch Deck/für Hubraum
+- [ ] Termine
+
+## Offene TODOs
+
+- [ ] Anpassen Milestone/Epic - mk
+- [ ] gRPC NBI redesign - mls/mb (nach 15.03.)
+ - Martin Skizziert
+ - Malte kommt nach Abgabe BA dazu
+- [ ] Resolve ARCHITECTURE.md document - mk
+- [ ] Epic für Semesterende mit Roadmap MPSE - mls