commit | 952bc26bc777653923d2019cc6cd7cd4f2ffd8c1 | [log] [tgz] |
---|---|---|
author | Jenkins <do-not-reply@opennetworking.org> | Tue Mar 30 07:23:28 2021 +0000 |
committer | Jenkins <do-not-reply@opennetworking.org> | Tue Mar 30 07:23:28 2021 +0000 |
tree | ad07c3baf31d2a64f57e4cf9c601c2534b136135 | |
parent | 2a72e652d7b0073e6b6778cdf779acabb0950429 [diff] |
Starting snapshot 5.4.0-SNAPSHOT with API version 5.4.0-SNAPSHOT Change-Id: Id2e8b8c2960ada400fb2a58ace321039e06a198c
When deploying at a customer there is often a need to access per-subscriber / access device information. This information is authoritatively stored by the customer and made available to the residential CORD or VOLTHA deployment. The purpose of this service is to define an optional service that provides a bridge to the customer's infrastructure to query / cache subsciber/access information and make it available to other services / applications within the ONOS/CORD infrastructure.
The below diagram is a high level block diagram for the Access Information Service that runs as an ONOS application and will be used within the CORD/vOLTHA context by other ONOS applications such as the DHCP Relay, iGMP, and AAA. The basic concept is that the service can run in two modes: local mode - in local mode the per subscriber / access device information can be established via ONOS's network configuration capability. In this mode all queries are answered based on the information from the network configuration remote mode - in the remove mode the service is configured with a URL and this URL is used to query an external source for subscriber / access device information using a URI structure that is defined as part of this service. Information retrieved from the external source is cached locally.
The cache used for the remote mode is considered a pull through cache in which all queries are answered from the cache and if there is a cache miss the remote API is used and the cache is populated.
To prevent the cache from growing indefinitely a policy, initially time/use based, will be leveraged to kick / purge items from the cache. Additionally, the cache can be influenced via manually operations of the the CLI/API exposed as part of ONOS. The time limits for cache entry purging should be configurable.
The service is configurable via both the the network configuration as well as via ONOS configuration. This configuration consists of service-wide properties such as operation mode, remote URL, cache purge options, etc.
The in memory cache is not a clustered, distributed data structure, such that each instance of ONOS in a cluster might have a different set of objects in its cache. The thought behind this is that each instance in a cluster will be a master for a different set of devices and thus needs different information.
"org.opencord.sadis" : { "sadis" : { "integration" : { "url": "http://localhost/src/test/resources/%s", "cache" : { "maxsize" : 50, "ttl" : "PT1m" } }, "entries" : [ { "id" : "uni-1", "cTag" : 2, "sTag" : 2, "nasPortId" : "PON 1", "circuitId" : "VOLT-1", }, { "id" : "211702604597", "hardwareIdentifier" : "00:1e:67:d2:ef:66", "ipAddress" : "144.60.34.89", "nasId" : "66" }] } }
%s
in the url which will be substituted with the id for that subscriber/device to retrieve the data.Entries can be for Subscribers and OLT Devices; they are differentiated by the id. If the url is specified the data for the subscribers/devices are picked from there else the local data is used.
ports
commanddevices
command