diff --git a/index.rst b/index.rst index 6203d2d..73d889f 100644 --- a/index.rst +++ b/index.rst @@ -66,6 +66,6 @@ :hidden: :glob: - release/1* - release/2* + release/2.0.rst + release/2.1.rst release/process.rst diff --git a/release/1.5.rst b/release/1.5.rst deleted file mode 100644 index f2f5186..0000000 --- a/release/1.5.rst +++ /dev/null @@ -1,202 +0,0 @@ -Aether 1.5 Release -================== - -Highlights ----------- - -The focus of this release is an update of Aether to support the 5G SD-Core. -This included a redesign of Aether modeling and workflows, integration of the -5G SD-Core into Aether, and an update of the 4G SD-Core to be compliant with -the 5G Aether API. 4G Small Cells are readily available and deployed at -multiple Aether installations. The 5G Core is part of a Deutsche Telekom SD-RAN -trial and is being used with 5G-SA disaggregated RAN components (CU/DU/RU). - -Deployment of Aether has been demonstrated on Anthos and on Elastic Kubernetes -Service. Persistent test deployments are now maintained by ONF to further -evaluate Aether functionality on those platforms. - - -New Features and Improvements ------------------------------ - -4G and 5G Connectivity Service -"""""""""""""""""""""""""""""" - -Aether supports mobile/cellular connectivity using both the 4G and the 5G -SD-Core. The Aether ROC may be used with both cores simultaneously. The 4G -modeling used by Aether-1.0 has been replaced with newer modeling that unifies -the 4G and 5G cores in a single modeling abstraction. - -Device Grouping and Network Slicing -""""""""""""""""""""""""""""""""""" - -Aether supports a Network Slicing abstraction where similar connected devices -can be aggregated together into a Device-Group, and different Device Groups can -be allocated to different network slices (Virtual Connectivity Service - VCS). - -Grouping connected devices affords ease of management - devices in the same -group are configured together and afforded the same treatment in the network. -Separating device-groups into different slices affords isolation between -groups. The data plane connectivity for different slices are realized through -different User Plane Functions (UPFs). - -Furthermore, Aether supports Access Control - devices not part of any -Device-Group are rejected by the network. - -Aether Portal -""""""""""""" - -The Aether Portal is a modern secure Single Page Application implemented in -Angular. The portal integrates both control of the Aether Network and metrics -reported by Aether components in a single pane of glass with multi-tenancy -separation. The portal allows complex control operations to be batched together -as one transaction into a convenient “basket” and then atomically committed to -the configuration. All of the functions of the Portal are also available on a -secure REST API, with an OpenAPI 3 schema. - -Role-Based Access Control -""""""""""""""""""""""""" - -The Aether control API supports role-based access control, together with -external authentication using OpenID Connect. These access controls are used in -the Aether Portal to limit which enterprises a portal user is allowed to view -or modify. The Aether Portal supports multiple enterprises simultaneously. - -Flexible Kubernetes Deployment Options -"""""""""""""""""""""""""""""""""""""" - -Fully managed Aether deployment using Rancher is officially supported. Together -with Rancher, Aether allows configuration, management, and monitoring of -Kubernetes clusters. These clusters can be used to host the Aether Connectivity -Service as well as customer edge applications. Support for other managed -Kubernetes services such as Google Anthos or Amazon Elastic Kubernetes Service -should be considered beta and not officially supported. - -Testing -------- - -Aether uses automated testing based on Jenkins and Robot Framework. The tests -performed are described below. - -SD-Core Tests -""""""""""""" - -* 4G - - * Functional Coverage: Attach,detach, dataplane traffic, handover, TAU, - paging, error scenarios, few failure/restart of network functions - - * Scale and Performance tests utilizing BESS - -* 5G - - * Functional Coverage: register, deregister, dataplane traffic scenarios, - handover, TAU, DDN, few error scenarios, few failure/restart of network - functions - - * Scale tests (BESS) - -Jenkins jobs for functional and scale tests can be found on `Aether Jenkins - -SD-Core System Tests -`_ - -ROC -""" - - * Functional API and GUI test coverage - -Jenkins jobs: `Aether Jenkins - ROC System Tests -`_ - - -System Tests -"""""""""""" - -* 4G and 5G Sanity Test coverage: - - * Configure ROC with related models for 4G and 5G - * Validate for attach/register UE, pings, detach/degister UE - -Jenkins Jobs: `Aether Jenkins - Aether System Tests -`_ - -Documentation -------------- - -Aether documentation is available at `docs.aetherproject.org -`_ - - -Known Issues and Limitations ----------------------------- - -* A given UE may participate in a 4G core or a 5G core, but not both. - -* 4G UEs may each participate in a single DeviceGroup, and 4G DeviceGroups may - each participate in a single VCS. This restriction does not apply to 5G UEs. - -* Application filtering is modeled in the API and the GUI, but application - filtering is not active in the data plane. - -* Disabling/deleting a device group from a VCS does not restrict UE from - getting attached to the network [SDCORE-467] - -Component Versions in the 1.5 Release -------------------------------------- - -Helm Chart Versions and their component charts and containers: - -* atomix-controller: ``0.6.8`` - - * atomix-controller: ``v0.6.1`` - -* atomix-raft: ``0.1.9`` - - * atomix-raft-storage-controller: ``v0.9.2`` - -* aether-roc-umbrella: ``1.3.9`` - - * config-models/aether-3.x: ``3.0.13`` - - * aether-roc-api: ``v0.7.14`` - - * aether-roc-gui: ``v0.7.22`` - - * onos-config: ``v0.9.2`` - - * onos-topo: ``v0.8.3`` - - * sdcore-adapter: ``v0.1.36`` - -* sdcore-helm-chart: ``0.6.2`` - - * omec-control-plane: ``0.6.25`` - - * hssdb: ``c3po-hssdb:master-9a5f565`` - * hss: ``c3po-hss:master-9a5f565`` - * mme: ``nucleus:master-86d2678`` - * spgwc: ``spgw:master-6aad2f2`` - * pcrf: ``c3po-pcrf:pcrf-b29af70`` - * pcrfdb: ``c3po-pcrfdb:pcrf-b29af70`` - * config4g: ``5gc-webui:onf-release3.0.5-bf0b54f`` - - * omec-sub-provision: ``0.0.6`` - - * simapp: ``simapp:main-7d20738`` - - * 5g-control-plane: ``0.2.21`` - - * amf: ``5gc-amf:onf-release3.0.5-921b890`` - * nrf: ``5gc-nrf:onf-release3.0.5-3471442`` - * smf: ``5gc-smf:onf-release3.0.5-e991983`` - * ausf: ``5gc-ausf:onf-release3.0.5-85ea075`` - * nssf: ``5gc-nssf:onf-release3.0.5-c372b24`` - * pcf: ``5gc-pcf:onf-release3.0.5-95ae49f`` - * udr: ``5gc-udr:onf-release3.0.5-bc3b287`` - * udm: ``5gc-udm:onf-release3.0.5-40055e8`` - * webui: ``5gc-webui:onf-release3.0.5-bf0b54f`` - - * omec-user-plane: ``0.3.36`` - - * bess: ``upf-epc-bess:master-fcdbc95`` - * pfcpiface: ``upf-epc-pfcpiface:master-fcdbc95`` diff --git a/release/1.6.rst b/release/1.6.rst deleted file mode 100644 index 519785a..0000000 --- a/release/1.6.rst +++ /dev/null @@ -1,226 +0,0 @@ -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 -`_ - -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 -`_ - -Documentation -------------- - -Aether documentation is available at `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 - -:doc:`SD-Core 1.0 ` - -* sdcore-helm-chart: 0.9.17 - -:doc:`SD-Fabric 1.0.1 ` - -* 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 diff --git a/release/2.0.rst b/release/2.0.rst index 26a2513..2aa68c8 100644 --- a/release/2.0.rst +++ b/release/2.0.rst @@ -1,6 +1,9 @@ Aether 2.0 Release ================== +.. note:: Aether 2.0 is no longer supported. Its Guide is archived + `here `__. + Aether Highlights ----------------- diff --git a/release/2.1.rst b/release/2.1.rst index f32abe2..12f1553 100644 --- a/release/2.1.rst +++ b/release/2.1.rst @@ -1,6 +1,10 @@ Aether 2.1 Release ================== +.. note:: Aether 2.1 is being deprecated. Its Guide is archived + `here `__. + + Aether Highlights ----------------- diff --git a/release/process.rst b/release/process.rst index 1fedd27..99e65e1 100644 --- a/release/process.rst +++ b/release/process.rst @@ -7,7 +7,7 @@ Prerequisites Aether makes the following assumptions about the components are included in a release: -Git tags +Git Tags """""""" Code receives Git tags as a part of the CI process @@ -25,7 +25,7 @@ Code receives Git tags as a part of the CI process * You can't re-release or "fix" a version that has problem - make a new version with fixes in it. -Docker container images +Docker Container Images """"""""""""""""""""""" All docker images are tagged based on their git tags. @@ -41,7 +41,7 @@ All docker images are tagged based on their git tags. * Increases repeatability of the process, and prevents human accidents. -Helm charts +Helm Charts """"""""""" * Each chart may only contain references to released, SemVer tagged container images @@ -57,7 +57,7 @@ All Helm charts are checked that the containers they use have a SemVer version tag A branch is created on the Helm charts repo, with the abbreviated name of the -release - for example **aether-1.5**. +release - for example **aether-2.1**. To allow for future patches to go into the repo in a way that does not conflict with the version branch, each component repo's **VERSION** file should have it's @@ -70,10 +70,10 @@ requires that every new chart version be unique and unsuffixed SemVer is a more consistent release numbering pattern. Finally, the ``aether-helm-charts`` repo overall **VERSION** should also be incremented -to the next minor version (1.6.0-dev) on the **master** branch, so all 1.5.x -releases of the overall charts repo will happen on the **aether-1.5** branch. +to the next minor version (2.2.0-dev) on the **master** branch, so all 2.1.x +releases of the overall charts repo will happen on the **aether-2.1** branch. -Creating releases on the 1.5.x branch +Creating Releases on the 2.1.x Branch """"""""""""""""""""""""""""""""""""" If a fix is needed only to the helm charts: @@ -81,23 +81,23 @@ If a fix is needed only to the helm charts: 1. Make the fix on the master branch of aether-helm-charts (assuming that it is required in both places). -2. After the master tests pass, manually cherry-pick the fix to the **aether-1.5** +2. After the master tests pass, manually cherry-pick the fix to the **aether-2.1** branch (the Chart version would be different, requiring the manual step). -3. Cherry-picked patchsets on that branch will be checked by the **aether-1.5** +3. Cherry-picked patchsets on that branch will be checked by the **aether-2.1** branch of tests. -4. When it passes, submitting the change will make a new 1.5.x release +4. When it passes, submitting the change will make a new 2.1.x release 5. Update the documentation to reflect the chart changes, a description of the - changes m, and increment the tag on the docs from 1.5.n to 1.5.n+1, to + changes m, and increment the tag on the docs from 2.1.n to 2.1.n+1, to reflect the patch change. 6. If all the charts are updated and working correctly, create a new charts - point release by increasing the 1.5.n **VERSION** file in the + point release by increasing the 2.1.n **VERSION** file in the aether-helm-charts repo. This should be the same as the version in the documentation. Immediately make another patch that returns the - ``aether-helm-charts`` **VERSION** to 1.5.n+1-dev, so that development + ``aether-helm-charts`` **VERSION** to 2.1.n+1-dev, so that development patches can continue on that branch. If a fix is needed to the components/containers that are included by the helm charts: @@ -105,13 +105,13 @@ If a fix is needed to the components/containers that are included by the helm ch 1. Develop a fix to the issue on the master branch, get it approved after passing master tests. -2. If it doesn't exist, create an **aether-1.5** branch on the component repo, - starting at the commit where the **VERSION** of the component used in 1.5 was +2. If it doesn't exist, create an **aether-2.1** branch on the component repo, + starting at the commit where the **VERSION** of the component used in 2.1 was created - this is known as "lazy branching". -3. Manually cherry-pick to the **aether-1.5** branch of the component, incrementing - the patch version, and test with the **aether-1.5** version of +3. Manually cherry-pick to the **aether-2.1** branch of the component, incrementing + the patch version, and test with the **aether-2.1** version of aether-system-tests and helm charts. 4. Update helm charts and go through the helm chart update process above diff --git a/testing/about_system_tests.rst b/testing/about_system_tests.rst index 0caa603..7600a02 100644 --- a/testing/about_system_tests.rst +++ b/testing/about_system_tests.rst @@ -9,7 +9,7 @@ The Aether Project is transitioning to a new automated testing regime, consistent with its transition from being a managed service to being a platform anyone can deploy. Information about the previous framework can be found in the `Version 2.1 Guide -`__, +`__. The major changes include: