Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
goSDN
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Iterations
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Terraform modules
Analyze
Contributor analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
danet
goSDN
Commits
5befe158
Commit
5befe158
authored
4 years ago
by
Martin Stiemerling
Browse files
Options
Downloads
Patches
Plain Diff
Update 05-implementation.md
parent
9f613f64
Branches
Branches containing commit
Tags
Tags containing commit
1 merge request
!11
Update 05-implementation.md
Checking pipeline status
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
documentation/design/05-implementation.md
+16
-2
16 additions, 2 deletions
documentation/design/05-implementation.md
with
16 additions
and
2 deletions
documentation/design/05-implementation.md
+
16
−
2
View file @
5befe158
...
@@ -29,6 +29,20 @@ For now we can only use the OpenAPI 2.0 standard. This is because `go-swagger` d
...
@@ -29,6 +29,20 @@ For now we can only use the OpenAPI 2.0 standard. This is because `go-swagger` d
## Storing Information
## 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:
There seem to be two classes of information to be stored in the controller:
*
short-living information, such as, current topology
*
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, etc
*
long-time information, such as, information about principle network domains, elements in such a domain if directly learned from SBI, etc
This may or may not result in two different places to store data. Unclear yet.
### 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
*
Phyiscal Inventory Network Elements, hosts and links
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment