Dixon-Erickson OpenDaylight Merged Controller Proposal
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
 
ABCDEFGHIJKLMNOPQRSTUV
1
Priority 1 (high) - 5 (low)Difficulty 1 (hard) - 5 (easy)FeatureOpenDaylight "controller" elementsOpenDaylight net-virt-platform elementsNotesRecommendation
2
Core Services
3
11Consistency/Data StoreClusterServices
ConfigurationService
StorageServiceThe interface to these need to be redesigned to appropriately represent strong consistency with transactions and eventual consistency. Note that this is one of the few places where semantics need to be very carefully described.

Do we also need a stable storage interface or is the configuration management enough?
refine the consistency interface to allow for both eventual and strong consistency with transactions, take both backing implementations if possible?

This should also be used to back both a log service and a configuration service.
4
23Host detection, locating and trackingARPHandler
HostTracker
DeviceManager
AddressSpace?
net-virt-platform (i) offers a more general definition of a "host", rather than defining a hot by a MAC address, (ii) can learn about hosts from more than just ARP traffic, and (iii) supports multiple attachment points for hosts.use the net-virt-platform implementation
5
34Discover interconnections between switchesTopologyManagerLinkDiscoveryManagerBoth send LLDPs to discover direct links. The net-virt-platform send BDDPs (essentially broadcast LLDPs) to discover multi-hop links for OpenFlow island support.
similar functionality excepting island support, need to discuss the utility and generality of island support
6
4Gather switch and controller statisticsStatisticsManager
OFStatisticsManager
ReaderService
IOFSwitch.getStatistics()

CounterStore
PerfMon/PktInProcessingTime
net-virt-platform focuses on controller performance, "controller" implementation focuses on gathering switch statistics

net-virt-platform has an interface to query for OpenFlow statistics, but only as part of the switch
use the "controller" implementation for gathering switch statistics, generalize this to accept statistics for the controller as well, use or re-implement net-virt-platform implementation
7
3Basic L2/L3 forwardingSimpleForwardingForwarding"controller" SimpleForwarding routes on /32 IP addresses, while net-virt-platform's Forwarding routes on MAC addresseswe need both sets of functionally, either use the net-virt-platform's L2 support or re-implement it as easier
8
3Route computationDijkstraImplementationTopologyManager
BetterTopologyManager
net-virt-platform provides support for routing on consistent snapshots of the topology and for handling of OpenFlow islands. However, the island implementation has some limitations with loops in the islands.

Note that there is as much importance in getting the interface right so that others can add their own route computation engines as in the actual backing implementations we provide.
while the net-virt-platform code provides richer functionality, it does at least four separate things in one module, we either recommend factoring it apart and using it or borrowing the ideas and reimplementing them
9
22Threading support(none)ThreadPoolSome disciplined approach to thread management is required. The net-virt-platform implementation is essentially just a passthrough to Java ScheduledExecutorService.There isn't much code to borrow, probably easier just to use an existing OSGi service or roll our own. Most work is in replacing the current thread managment. This is pretty low priority, could be punted.
10
4Runtime ConfigurationConfigurationService?ModuleContext.getConfigParams()net-virt-platform provides a way to load configuration for modules from configuration files

"controller" provides a hook to notify all modules to save their configuration, but assumes it will be done through the consistency layer. It thus seems more related to consistency and is discussed there.
This feature is needed, but is highly baked into the (non-OSGi) module loading system of net-virt-platform. We should implement something similar, but probalby as a stand-alone service that takes key-value pairs and optionally stores the to stable storage for modules. Ideally backed by an improved consistent datastore.
11
2Network VirtualizationContainerManagerAddressSpace?
NetVirt?
The current plan is to factor out this functionlity from net-virt-platform as a separate project. This should be made compatible with the NB APIs we create.

The "controller" concept of containers essentially gives a tag to each module and that tag can be used in decision-making at various points around the controller. This allows for multiple logical controllers to run in the same JVM and for slicing of the network.
Implement the separate net-virt-platform app to run on whatever we ship.

We differ slightly on our views on containers. Colin thinks we should expand the containers concept beyond the current VLANs and switchports and further integrate them into the code in more places.

David thinks the idea is interesting, but thinks they require more effort to make them appropriately useful and would like to hear more about their use cases before putting significant effort into them.
12
22OpenFlow-specific switch and message managementOpenFlow protocol plugin
SwitchManager
BetterDriverManager
BetterOFSwitch*
ControllerProvider
MessageFilterManagerService
While the code is, by and large, equivalent in function, the net-virt-platform code is generally of higher quality.
Use net-virt-platform if possible

One good approach might be to start with a bundle containing the net-virt-platform Controller module (not the full controller) and LinkDiscovery module with the core dependencies on the different SwitchDrivers and converting it provide the appropriate interfaces to be a SAL plugin.
13
21SALWhile a subset of the interfaces in net-virt-platform could be declared to be a SAL, the code would need to be augmented to aggregate multiple implementers into one logical instance of those interfaces to get multiple southbound protocol support.The SAL is a good concept and one that must be present. The current SAL is a good first take at a common abstraction for L2/L3 forwarding devices.

Going forward, there will need to be more than one of these common abstractions. For example, perhaps one for device configuration including OFConfig, NETCONF and OVSDB.
14
5REST API provider*.northbound (via JAXB annotations)RestApiServiceEither solution needs better documentation for how to export REST APIs from modulessimilar functionality, use the "controller" approach
15
45Structured Log Service(none)(none)The built-in logging (slf4j in both cases) should log in a way that gives other modules/bundles programmatic access to the (semi-)structured log data. This allows modules to present users with extra information beyond the usual events created in the listener/notifier frameworks.While very useful, for instance to surface log messages to a web UI, this is not absolutely essential immedately.

Ideally backed by the consistent datastore; presumably at a low level of consistency.
16
55User added static flowsForwardingRulesManagerStaticFlowEntryBoth provide OpenFlow-like direct access to program low-level rules into switches.
The functionality is similar, use the "controller" code
17
55Authentication and user rolesUserManager(none)no conflict, use the "controller" implementation
18
19
Meta-Features
20
n/aBuild systemMavenAntMaven is superior to Ant for building in an environment where we care about versioning/publishing artifacts, which we do. The "Controller" Maven usage precludes Eclipse from save doing an autobuild, this must be fixed. Worth considering switching to Maven + Tycho for Manifest first builds that can use Eclipse's PDE infrastructureuse Maven, fix eclipse PDE infrastructure to compile on save, add support to push bundles to the Nexus repositories where needed l
21
42Modularity SystemOSGi using ActivatorsCustom Module System based on Java ServiceLoader"Controller" is manually discovering/wiring services together using the very low-level Activator functionality in OSGi (including listing setters/getters as Strings.. ugh), the functionality is necessary but it should be able to use a much more developer-friendly framework like iPOJO or similar and remove tons of manual code. Worth investigating how this could be used with declarative services/blueprint as well.use OSGi, the current Activators work for now, investigate possiblilites that enable less manual coding and uses a more robust system for binding than strings
22
23
Non-Core Services
24
Demo apps(none)Hub
LearningSwitch
no conflict, use net-virt-platform
25
Load BalancerLoadBalancerLoadBalancerkeep both after finding a common interface
26
5Python debugging interface(none)Jythonthis isn't a critical feature, somebody can provide it later if they want
27
Tunnel creation and management(none)TunnelManager
RewriteService
no conflict, use net-virt-platform
28
33Device Config Service(none)OVSDBManagerWe need an interface that will provide some generic interface for device configuration including LAG configuration, tunnel setup and the like.no conflict, port OVSDBManager
also add OFConfig support?
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Loading...