| 39 | | === (9/5) === |
| | 42 | ==== (9/5): ==== |
| | 43 | keywords: hierarchy, collaboration. |
| | 44 | |
| | 45 | We are set on having a weekly meeting, starting with this one. [[BR]] |
| | 46 | The consensus is that a general architecture is beyond the scope of what's possible within the available timespan. The design is simplified to a narrower case: |
| | 47 | |
| | 48 | * controllable topology (mobility as a change in topology). A global controller with a view of the network initially configures the topology. Lower (local) controllers can detect topology change and either update the global view or handle it themselves. |
| | 49 | * controller per service and switch |
| | 50 | * hierarchical relation between controllers. with less active protocols higher up |
| | 51 | * information distribution mechanism between controllers, namely service location (topology). Certain controllers may add context to port, depending on what is attached to them. The topology controller must be able to convey the location of the service to that controller. Possibly an request/reply/subscription based scheme, the subscription being useful for events (topology change). |
| | 52 | |
| | 53 | The course of action now is to look for the following: |
| | 54 | * Basic topology control |
| | 55 | * Test case of mobility/handoff/flow switching (!OpenRoads) |
| | 56 | * Mechanisms that can be used to exchange service/event information |
| | 57 | |
