@@ -9,9 +9,7 @@ This document describes the the high-level architecture of the goSDN project. Al
...
@@ -9,9 +9,7 @@ This document describes the the high-level architecture of the goSDN project. Al
On the highest level goSDn provides a gRPC northbound-interface and two types of southbound-interfaces: RESTCONF and gRPC-based. The northbound interface allows the interaction with a running goSDN daemon and may allow the stacking of multiple controllers in the future. The southbound interface (SBI) capabilities are split in `nucleus` models and plugins. The supported `nucleus` models are OpenConfig yang [openconfig-yang](https://github.com/openconfig/yang) and TAPI. Third party models and more SBI-transports can be attached using the go plugin architecture.
On the highest level goSDn provides a gRPC northbound-interface and two types of southbound-interfaces: RESTCONF and gRPC-based. The northbound interface allows the interaction with a running goSDN daemon and may allow the stacking of multiple controllers in the future. The southbound interface (SBI) capabilities are split in `nucleus` models and plugins. The supported `nucleus` models are OpenConfig yang [openconfig-yang](https://github.com/openconfig/yang) and TAPI. Third party models and more SBI-transports can be attached using the go plugin architecture.
The internal data representation uses [ygot](https://github.com/openconfig/ygot) generated go-structs.
The internal data representation uses [ygot](https://github.com/openconfig/ygot) generated go-structs.
It is important to note that these go-structs are generated from yang models and thus are not generic data structures. This in turn means that the `nucleus` code is organized in silos, i.e., one particular southbound-interfaces instance is visible in the `nucleus`, as the internal data representation depend on the used yang modes in the southbound-interface.
It is important to note that these go-structs are generated from yang models and thus are not generic data structures. This means that the `nucleus` code is organized in silos, i.e., one particular southbound-interface is visible in the `nucleus`, as the internal data representation depend on the used yang modes in the southbound-interface.
For such, the `nucleus` is not independent of the southbound-interfaces, as a southbound-interfaces agnostic `nucleus` would require an abstraction level between it and the various southbound-interfaces. Such an abstraction level is from our view hard to design and also hard to maintain the southbound-interfaces-specifics.
## Code Map
## Code Map
...
@@ -37,7 +35,7 @@ Forks of `google/gnxi/gnmi` and `arista/goarista/gnmi` for gNMI server and clien
...
@@ -37,7 +35,7 @@ Forks of `google/gnxi/gnmi` and `arista/goarista/gnmi` for gNMI server and clien
### `nucleus/device`
### `nucleus/device`
This is the representation of an `orchestratedNetworkingDevice` (OND). An `orchestratedNetworkingDevice` is the network device that is directly managed by goSDN. It holds a reference to the device's `transport` and `southboundInterface` implementation. It contains a fakeroot device based on its attached SBI. (TODO: define fakeroot device)
This is the representation of an `orchestratedNetworkingDevice` (OND). An `orchestratedNetworkingDevice` is the network device that is directly managed by goSDN. It holds a reference to the device's `transport` and `southboundInterface` implementation. It contains a fakeroot device based on its attached SBI.
**Architecture invariant:** The device is does not provide any functionality to upper API layers.
**Architecture invariant:** The device is does not provide any functionality to upper API layers.