| commit | 66862035accde9e1dcb32f7c711465d00e543af8 | [log] [tgz] |
|---|---|---|
| author | Zsolt Haraszti <zharaszt@ciena.com> | Mon Nov 28 14:28:39 2016 -0800 |
| committer | Zsolt Haraszti <zharaszt@ciena.com> | Wed Dec 07 11:50:29 2016 -0800 |
| tree | 366f637706444a93514af802d87889d3572073b9 | |
| parent | 00d9a842344958e9361aa02f15775f9151b3eab9 [diff] |
Flow decomposition and miscellenous improvements Specifically: The biggest addition is an initial flow decomposition implementation that splits flows and flow groups defined over the logical device into per physical device flows, based on a very crude and heuristic approach. We expect this part to be much improved later on, both in term of genericness as well as speed. The flow decomposition is triggered by any flow or group mods applied to a logical device, and it consequently touches up the affected device tables. This uses the POST_UPDATE (post-commit) mechanism of core. There is also an initial arhcitecture diagram added under docs. Additional improvements: * Implemented metadata passing across the gRPC link, both in Voltha and in Chameleon. This paves the road to pass query args as metadata, and also to pass HTTP header fields back and forth across the gRPC API. This is alrady used to pass in depth for GET /api/v1/local, and it will be used to allow working with transactions and specific config revs. * Improved automatic reload and reconnect of chameleon after Voltha is restarted. * Improved error handling in gRPC hanlers, especially for the "resource not found (404)", and bad argument (400) type errors. This makes gRPC Rendezvous errors a bit cleaner, and also allows Chameleon to map these errors into 404/400 codes. * Better error logging in generic errors in gRPC handlers. * Many new test-cases * Initial skeleton and first many steps implemented for the automated testing for the cold PON activation sequence. * Convenience functions for working with flows (exemplified by the test-cases) * Fixed bug in config engine that dropped changes that were made in a POST_* callback, such as the ones used to propagae the logical flow tables into the device tables. The fix was to defer the callbacks till the initial changes are complete and then execute all callbacks in sequence. * Adapter proxy with well defined API that can be used by the adapters to communicate back to Core. * Extended simulated_olt and simulated_onu adapters to both demonstrate discovery-style and provisioned activation style use cases. * Adapter-, device-, and logical device agents to provide the active business logic associated with these entities. * Fixed 64-bit value passing across the stack. There was an issue due to inconsistent use of two JSON<-->Proto librarier, one of which did not adhere to the Google specs which recommend passing 64-bit integer values as strings. * Annotation added for all gRPC methods. All Voltha test-cases are passing. Change-Id: Id949e8d1b76276741471bedf9901ac33bfad9ec6
Voltha aims to provide a layer of abstraction on top of legacy and next generation access network equipment for the purpose of control and management. Its initial focus is on PON (GPON, EPON, NG PON 2), but it aims to go beyond to eventually cover other access technologies (xDSL, Docsis, G.FAST, dedicated Ethernet, fixed wireless).
Key concepts of Voltha:
Control and management in the access network space is a mess. Each access technology brings its own bag of protocols, and on top of that vendors have their own interpretation/extension of the same standards. Compounding the problem is that these vendor- and technology specific differences ooze way up into the centralized OSS systems of the service provider, creating a lot of inefficiencies.
Ideally, all vendor equipment for the same access technology should provide an identical interface for control and management. Moreover, there shall be much higher synergies across technologies. While we wait for vendors to unite, Voltha provides an increment to that direction, by confining the differences to the locality of access and hiding them from the upper layers of the OSS stack.
While we are still at the early phase of development, you can check out the BUILD.md file to see how you can build it, run it, test it, etc.
Contributions, small and large, are welcome. Minor contributions and bug fixes are always welcome in form of pull requests. For larger work, the best is to check in with the existing developers to see where help is most needed and to make sure your solution is compatible with the general philosophy of Voltha.
