AtlanticWave-SDX Data Model

This is a Python library that contains a collection of classes that is shared between AtlanticWave-SDX components. The intention is to provide a common vocabulary of nodes, ports, services, links, connections, topologies, etc., and means to parse and validate descriptions of such objects.

System

Each domain, proxied by the customized SDX-LC who communicates between the SDX-controller and the domain (1) provisioning system (eg, Kytos) and (2) monitoring system (BAPM).

Topology Models

In the whole SDX system, two types of topology models are needed:

1. Domain substrate description model

It's used by the intra-domain provisioning system.

2. Domain declaration/advertisement model

Based on the information from the domain provisioning system, tt's abstracted, generated, and passed by SDX-LC to the SDX-controller for inter-domain topology assembly to support (a) inter-domain path computation; and (b) inter-domain path monitoring and reconfiguration.

It would consist of three types of information:

1. Topology abstraction

2. Network resources available for inter-domain connections and their QoS metrics (eg, bw, latency, packet loss, vlan ranges, etc)

3. Switching capability (eg, vlan, Q-in-Q, etc).

There is a service attribute in the topology object, which is an object that describes domain service meta information like owner, provisiong system, and security features.

Domain topology and state update

Topology update

On the events of addition, removal, and/or maintenance of ports, nodes, links, an updated domain topology with version and timestamp needs to be sent to the LC and subsequently the SDX controller. A new topology object is supposed to be generated and passed on to the SDX controller.

Topology link state update

This set of updates mainly come from the domain monitoring system which is supposed to stream periodical measurement information on the links, like bandwidth, latency, and packet loss. A new link object is supposed to generated and pass on to the SDX controller.

Topology description schemas

There are some JSON schemas defined in the schemas subfolder. These are meant to guide and validate model development.

Some attributes of each objects are requied (can be found in the API definition) while some are optional. Two attributes are worth mentioning:

1. In the service object, there is a vendor attribute for the domain to list device vendors that are NOT in its domain.

2. In topology, link, node, and port objects, there is a private attibute for the domain to list attributes that need to kept private.

There are some unit tests to validate JSON blobs we have against their corresponding schemas. Another nifty tool is check-jsonschema:

$ check-jsonschema --schemafile schemas/Topology.json \
    src/sdx_datamodel/data/topologies/amlight.json

Developing the library

Running tests

When developing and testing datamodel, using a virtual environment is a good idea, like so:

$ git clone https://github.com/atlanticwave-sdx/datamodel.git
$ cd datamodel
$ python3 -m venv venv
$ source venv/bin/activate
$ pip install --editable .[test]

To run tests, use pytest:

$ pytest

Or use Python's unittest module:

$ python -m unittest

If you want to run some specific tests:

$ python -m unittest -v tests.test_topology_handler
$ python -m unittest -v tests.test_topology_validator