Changes between Version 21 and Version 22 of Internal/OpenFlow/Controllers/MultiCtl
- Timestamp:
- Oct 4, 2012, 8:56:58 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/Controllers/MultiCtl
v21 v22 186 186 187 187 !HyperFlow is what this (attempted) controller seems to resemble the most. However, the point to make is that this controller should not be just another implementation of one of these controllers, or their characteristics. The model for the currently existing distributed controller seems to assume that of multiple controllers that all run the same application, and to allow that one application to scale. This contrasts from the distribution of functions across multiple controllers e.g. having each controller run a different application to "vertically" distribute the load (Vertical - splitting of a network stack into several pieces as opposed to the duplication of the same stack across multiple controllers). 188 188 189 [[BR]] 190 End of week4 :[#iv Back to Logs.] 191 192 ==== (10/4) ==== #w5 193 Seeing that the client-side channel implementation was not working as intended, a revision that can hopefully be worked back into the source was made. 194 195 As for the documentation aspect, several use cases for a multi-controller architecture that distributes tasks based on application (protocol) need to be devised. Some points made during discussion: 196 * Many networks contain various services that belong in separate "layers", which are maintained and configured by different groups, and may even reside on different devices. 197 * Viewing an analogy of a microkernel, where the various aspects of the kernel (w/r/t a monolithic architecture) are separated into processes that pass messages amongst themselves -- various controllers may serve different protocols that make up a network stack. Not commenting on the performance of the microkernel architecture, but more so on its existence. 198 199 189 200 190 201 ----