Summary here

Tracked in JIRA

Summary here

Tracked in JIRA

Scalable strongly consistent data store.

• For December release we went with Hazelcast as the default for many of distributed stores. It is disabled by default, but experimental version of Raft based implementation of the store consisting from a single partition (tablet) was also bundled. Raft based implementation will provide us with characteristics like durability across whole ONOS cluster restart, but single tablet implementation places a limit on read/write throughput the data store can support. We want to address this limitation and allow multiple tablets. So that updates that do not have any inter-dependencies and have keys that map to different tablets can be processed in parallel.
• Use cases that require transactional updates to keys spanning multiple tablets will need support for a nested distributed transaction.
• Support dynamic Raft cluster membership. In the initial release we went with a static cluster configuration for the distributed data store. We need to relax this and support dynamic cluster reconfiguration.

Mastership

• Migrate device mastership election to run on top of Raft based Database Service. Currently this is supported on top of Hazelcast.
• Support preferential assignment of devices to controllers by taking into account information such as current load, locality and administrator specified overrides.
• Support a protocol for automated re-balancing.

Clustering

• Migrate Cluster Management (discovery and failure detection) out of Hazelcast. Add support for a Accrual failure detector (such as Phi Accrual failure detector)

•  Support distributed queue functionality on top of Raft based database service. This will be used by intent subsystem for distributed execution of intents.

Metrics and monitoring

• Need to add metrics to measure performance across various sub systems in the distributed core and outside.
• We should be able to visualize the performance of various components in real time.

• We need to beef up our unit test and integration test coverage.
• For performance, pick concrete use cases and associated numbers from real world use cases.
• We need to set up a testbed that continually runs ONOS in a simulated real world deployment

1. Thorough testing in multi-instance cluster

2. Backup path

3. Get Bidirectional path to use same links
4. GUI to show resource utilization
5. Tunnel Intent
6. Packet optical working with real optical switch
7. Script to generate large topology
   

1. Hosts of the SDN network communicating with the hosts of the external networks

2. BGP confederation

3. Internet2 deployment

4. Full suite of integration tests

1. Integration with XOS, OpenCloud
2. Reference deployment

1. Segment Routing is currently on ONF development repo. The code needs to be adapted to and brought into ONOS master for Blackbird release.

1. IP RAN use case has been developed outside of ON.Lab by Huawei. The code needs to be adapted to and brought into ONOS master for Blackbird release

User login/logout

Extensible framework for navigation among multiple views

1. includes ability for apps to add views on the fly
2. built using AngularJS

1. devices, links, hosts
2. flows, intents, resources
3. tunnels