Skip to content
Snippets Groups Projects

V.0.1.0 Codename Threadbare

Closed Ghost User requested to merge v.0.1.0-codename-threadbare into master
1 file
+ 32
2
Compare changes
  • Side-by-side
  • Inline
@@ -6,10 +6,40 @@ Because it rocks, but let's see afterwards what can be written here.
@@ -6,10 +6,40 @@ Because it rocks, but let's see afterwards what can be written here.
## Storing Information
## Storing Information
Section XXX (Conceptual Design of a SDN Controller as Net- work Supervisor)
Section XXX (Conceptual Design of a SDN Controller as Network Supervisor)
discusses the need to store information about for element inventories and
discusses the need to store information about for element inventories and
topology inventories.
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 Inventories
 
 
Every network has one given physical topology and on top of this at least one
 
logical topology. There may be multiple logical topologies on top logical
 
topologies, i.e., a recursion.
 
 
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>.
 
 
 
### 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
## 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.
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.
@@ -18,7 +48,7 @@ The base of the development of goSDN are YANG modules. The RESTful API used for
@@ -18,7 +48,7 @@ The base of the development of goSDN are YANG modules. The RESTful API used for
### YANG
### YANG
YANG defines an abstract netwoprk interface. It is the foundation of the RESTCONF protocol. Several code generators exist to generate code stubs from a given definition.
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
Loading