|Team Name||Project Idea||Team Members|
|Want to make using ONOS even easier? Want to make ONOS even more secure? Then I want YOU to join this team. We will create an ONOS snap with Snapcraft (http://snapcraft.io/), put it in an actual app store, and if we're really a crack team we'll also design and implement new snapd interfaces for IPC in/out of ONOS!|
|YANG||Building new features and applications on top of YMS and YANG Tools||Gaurav Agrawal |
As part of YANG Hackathon we are planning to do the following.
1) YANG tools integration in BUCK.
2) Adapting Device and Link subsystem’s interface using YANG (NBI)
3) Adapting flow objective behavior to configure the device using YANG (SBI)
|PCE||PCE Calendering - Extensions needed to the Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage duration of a traffic service in a centralized network environment. A scheduled LSP can be setup at its starting time and deleted after its usage duration such that LSPs for the other traffic services can take over these network resources beyond that period|
|Love CORDing||A network monitor feature in ONOS which could check the latency between any two switches.|
|Roll the Control|
We want to enable the provision of an intent through a domain, so that ONOS is able to communicate with other sub-domains e.g., vendor-specific controller (ACINO and GEANT use cases), SDN domains (ICONA use case).
We would provide an extension of the Intent Framework to produce, as a compilation result, a high-level description of the policy to be applied in the network (i.e., intent), so that ONOS provides not only the installation of flowrule-specific and flowobjective-specific intent, but also the installation of "intent-specific intent". The flowrule-specific and flowobjective-specific intent are installed by generating multiple requests for each device. At the contrary, the intent-specific intent is installed as a single request for the entire domain.
An alternative strategy is to leverage on the tunnel subsystems and to carry out failure discovery of the tunnels outside the ONOS core.
If the TST vision is aligned with the former solution and willing to adopt it within the ONOS core, we would definitely prefer to develop that one. Otherwise, the second solution would be preferable, since it can be implemented within an application/provider, thus avoiding any consistency issue with future releases of the code base.