release/1.6.rst

Aether 1.6 Release
==================

Highlights
----------

The focus of this release of Aether is expanding the Quality of Service (QoS)
feature to include the ability to have per-Slice and per-Device-by-Application
QoS settings, as well as to add a new Application Filtering feature. Aether
modeling continues to be improved as documented below, and many additional
reliability improvements have been made to the underlying subsystems.

New Features & Improvements
---------------------------

Three Levels of Quality of Service (QoS) Control
""""""""""""""""""""""""""""""""""""""""""""""""

Aether now supports Maximum Bitrate Quality of Service (MBR QoS) settings at
three different levels:

* Per-Device. Configured as part of the Device-Group abstraction. Each slice may
  contain multiple device groups, and therefore configure a heterogeneous set of
  devices. These settings are mandatory.

* Per-Device by Application. These allow the MBR to be limited for the flow
  between a pair of Device and Application. These QoS settings are optional and
  are specified as part of Application Filtering.

* Per-Slice. The per-Slice settings allow the aggregate bandwidth of all devices
  in a slice to be limited. This is enforced as part of the User Plane Function
  (UPF). These QoS settings are optional.

In addition to MBR, Aether also allows a Traffic Class to be specified at the
Per-Device (Device-Group) and Application contexts. The Traffic Class further
defines the QCI and ARP used for 5G.

Application Filtering
"""""""""""""""""""""

Aether supports application filtering performed by the User Plane Function
(UPF). The application filtering feature allows devices in a slice to have
access to only those applications allocated to the slice, and vice-versa,
thereby extending the isolation capabilities of a slice to the
edge-applications. Some applications (such as public Internet access) can also
be shared across slices.

Aether allows a total of five user-defined application endpoint filtering
rules, plus one default rule that may be set to either Allow-All or Deny-All.
The application endpoint filtering rules allow the filter to be composed of
application IP address, protocol (TCP, UDP, etc), and port. Each rule is
assigned a priority, and the rules are executed in priority order until a match
is found. The default rule (for example Deny-All), is assigned the least
priority and is executed last.

UPF Pools
"""""""""

Aether allows a set of UPFs to be created at customer onboarding, and those
UPFs may later be associated with Slices as the customer creates additional
slices. Additional UPFs may be added to the pool at any time by the operator.
The GUI maintains the invariant that a UPF may only be assigned to one Slice at
a time, that the UPF must be located at the same Site as the VCS, and assists
the user in filtering out in-use UPFs when a VCS is created.

Monitoring Support
""""""""""""""""""

The Aether GUI now displays site health statistics. These statistics are
collected by Aether using the Prometheus tool set, and are fetched on demand by
the GUI. Aether can display metrics such as the number of nodes and number of
healthy edge monitoring devices at a site.

Modeling Updates
""""""""""""""""

The following other miscellaneous modeling updates have been added:

* Standardized all bitrates to be specified as bits per second (bps).

* Several models have been updated to make it so that their names may be easily
  changed, without requiring the model to be deleted and re-created.

* The AP-List model has been renamed to Small-Cell and has been merged into the
  Site model.

Testing
-------

Aether uses automated testing based on Jenkins and Robot Framework. The tests
performed are described below.

ROC
"""

* Functional API and GUI test coverages

Jenkins jobs: `Aether Jenkins - ROC System Tests
<https://jenkins.aetherproject.org/view/ROC%20System%20Tests/>`_

System Tests
""""""""""""

* 4G

  * Functional testing includes multiple slice creations, enable/disable of device
    groups, add/update IMSI ranges, QoS validations, rate limiting tests (at UE,
    slice, application), application filtering tests, container restart tests

Jenkins Jobs: `Aether Jenkins - Aether System Tests
<https://jenkins.aetherproject.org/view/Aether%20System%20Tests/>`_

Documentation
-------------

Aether documentation is available at `docs.aetherproject.org
<https://docs.aetherproject.org>`_

Known Issues and Limitations
----------------------------

* An individual Device may participate in a 4G core or a 5G core, but not both.

* 4G Devices may each participate in a single DeviceGroup, and 4G DeviceGroups
  may each participate in a single VCS.

* Application endpoints may only specify an IPv4 address, and may not specify
  ports (either a single one or a range). As a consequence, we support the
  definition of only one application per IPv4 address. This limitation will
  be removed in Aether 2.0.

* When ROC’s sdcore-adapter-v4 pod restarts, its cached internal state must be
  manually refreshed.

* If ConfigPod is crashed/restarted then we need a manual restart of simapp pod.

* UPFs listed in the ROC should all be reachable, cannot include an unreachable
  UPF which may keep the existing UPFs to not function properly.

Limitations on modifying objects by Enterprise Administrators
-------------------------------------------------------------

The following models and fields contain information that is configured by ONF
Operations and should not be edited by an Enterprise Administrator. The GUI does
not currently prevent editing these fields.

* `Connectivity Service`. This object is fully managed by ONF. Do not add or edit.


* `Enterprise`. This object is fully managed by ONF. Do not add or edit.

* `IP Domain`.

  * `Subnet` must match the deployed UPF associated with the VCS that this
    IP Domain is used from. Do not change the subnet once it has been set. Do
    not attempt to share a Subnet or a DNN across multiple VCSes.

  * `DNN` must be unique per VCS that uses this IP Domain.

* `Site`. New sites should not be added by the enterprise, but limited editing
  of the site can take place, for example to change the `Display Name` or the
  `Description`.

  * `Small Cells` are preconfigured by ONF, but an enterprise may
    add additional small cells over time with assistance from ONF for
    configuration.

  * `Monitoring` URLs should not be changed.

  * `Edge Devices` are preconfigured by ONF, but an enterprise may add additional
    edge devices over time. These devices are specifically Aether Edge Monitoring
    Devices. Do not add non-Monitoring edge devices.

  *  The `IMSI` (`MCC`, `MNC`, `Enterprise`, and `Format`) should not be
     changed without consultation with ONF.

* `Template`. These are fully managed by ONF. Do not add or edit.

* `Traffic Class`. These are fully managed by ONF. Do not add or edit.

* `UPF`. UPFs are created at enterprise onboarding time and made available by a
  pool. There are no enterprise-modifiable attributes within the UPF object. If
  the Enterprise needs to create an additional VCS and there are no available
  UPFs, then please contact ONF and additional UPFs will be provisioned and added
  to the pool.

* `VCS`. VCSes may be added by the enterprise, up to the number of available UPFs.

  * `Device Groups`. It is recommended that only one device group be added per VCS at this time.

Component Versions
------------------

ROC:

* atomix-controller: 0.6.8

* atomix-raft-storage: 0.1.15

* onos-operator: v0.4.14

* aether-roc-umbrella: 1.4.64

`SD-Core 1.0 <https://docs.sd-core.opennetworking.org/master/release/1.0.html>`_

* sdcore-helm-chart: 0.9.17

`SD-Fabric 1.0.1 <https://docs.sd-fabric.org/1.0.1/release/1.0.1.html>`_

* sdfabric: 1.0.10

* onos-classic chart: 0.1.26

* stratum chart: 0.1.18

* pfcp-agent chart: 0.0.1

* dbuf chart: 0.0.1

* int-host-reporter chart: 0.0.1

Sercomm eNB

* Firmware version: TEST3918@210224

* Configuration file version: 0.1.0