3 ** Flow table handling in ovn-controller.
5 ovn-controller has to transform logical datapath flows from the
6 database into OpenFlow flows.
8 *** Definition (or choice) of data structure for flows and flow table.
10 It would be natural enough to use "struct flow" and "struct
11 classifier" for this. Maybe that is what we should do. However,
12 "struct classifier" is optimized for searches based on packet
13 headers, whereas all we care about here can be implemented with a
14 hash table. Also, we may want to make it easy to add and remove
15 support for fields without recompiling, which is not possible with
16 "struct flow" or "struct classifier".
18 On the other hand, we may find that it is difficult to decide that
19 two OXM flow matches are identical (to normalize them) without a
20 lot of domain-specific knowledge that is already embedded in struct
21 flow. It's also going to be a pain to come up with a way to make
22 anything other than "struct flow" work with the ofputil_*()
23 functions for encoding and decoding OpenFlow.
25 It's also possible we could use struct flow without struct
28 *** Translating logical datapath actions into OpenFlow actions.
30 Some of the logical datapath actions do not have natural
31 representations as OpenFlow actions: they require
32 packet-in/packet-out round trips through ovn-controller. The
33 trickiest part of that is going to be making sure that the
34 packet-out resumes the control flow that was broken off by the
35 packet-in. That's tricky; we'll probably have to restrict control
36 flow or add OVS features to make resuming in general possible. Not
37 sure which is better at this point.
39 *** OpenFlow flow table synchronization.
41 The internal representation of the OpenFlow flow table has to be
42 synced across the controller connection to OVS. This probably
43 boils down to the "flow monitoring" feature of OF1.4 which was then
44 made available as a "standard extension" to OF1.3. (OVS hasn't
45 implemented this for OF1.4 yet, but the feature is based on a OVS
46 extension to OF1.0, so it should be straightforward to add it.)
48 We probably need some way to catch cases where OVS and OVN don't
49 see eye-to-eye on what exactly constitutes a flow, so that OVN
50 doesn't waste a lot of CPU time hammering at OVS trying to install
51 something that it's not going to do.
53 *** Logical/physical translation.
55 When a packet comes into the integration bridge, the first stage of
56 processing needs to translate it from a physical to a logical
57 context. When a packet leaves the integration bridge, the final
58 stage of processing needs to translate it back into a physical
59 context. ovn-controller needs to populate the OpenFlow flows
60 tables to do these translations.
62 *** Determine how to split logical pipeline across physical nodes.
64 From the original OVN architecture document:
66 The pipeline processing is split between the ingress and egress
67 transport nodes. In particular, the logical egress processing may
68 occur at either hypervisor. Processing the logical egress on the
69 ingress hypervisor requires more state about the egress vif's
70 policies, but reduces traffic on the wire that would eventually be
71 dropped. Whereas, processing on the egress hypervisor can reduce
72 broadcast traffic on the wire by doing local replication. We
73 initially plan to process logical egress on the egress hypervisor
74 so that less state needs to be replicated. However, we may change
75 this behavior once we gain some experience writing the logical
78 The split pipeline processing split will influence how tunnel keys
81 ** Interaction with Open_vSwitch and OVN databases:
83 *** Monitor Chassis table in OVN.
85 Populate Port records for tunnels to other chassis into
86 Open_vSwitch database. As a scale optimization later on, one can
87 populate only records for tunnels to other chassis that have
88 logical networks in common with this one.
90 *** Monitor Pipeline table in OVN, trigger flow table recomputation on change.
92 ** ovn-controller parameters and configuration.
94 *** Tunnel encapsulation to publish.
96 Default: VXLAN? Geneve?
98 *** SSL configuration.
100 Can probably get this from Open_vSwitch database.
104 ovsdb-server should have adequate features for OVN but it probably
105 needs work for scale and possibly for availability as deployments
106 grow. Here are some thoughts.
108 Andy Zhou is looking at these issues.
110 ** Scaling number of connections.
112 In typical use today a given ovsdb-server has only a single-digit
113 number of simultaneous connections. The OVN Southbound database will
114 have a connection from every hypervisor. This use case needs testing
115 and probably coding work. Here are some possible improvements.
117 *** Reducing amount of data sent to clients.
119 Currently, whenever a row monitored by a client changes,
120 ovsdb-server sends the client every monitored column in the row,
121 even if only one column changes. It might be valuable to reduce
122 this only to the columns that changes.
124 Also, whenever a column changes, ovsdb-server sends the entire
125 contents of the column. It might be valuable, for columns that
126 are sets or maps, to send only added or removed values or
129 Currently, clients monitor the entire contents of a table. It
130 might make sense to allow clients to monitor only rows that
131 satisfy specific criteria, e.g. to allow an ovn-controller to
132 receive only Pipeline rows for logical networks on its hypervisor.
134 *** Reducing redundant data and code within ovsdb-server.
136 Currently, ovsdb-server separately composes database update
137 information to send to each of its clients. This is fine for a
138 small number of clients, but it wastes time and memory when
139 hundreds of clients all want the same updates (as will be in the
142 (This is somewhat opposed to the idea of letting a client monitor
143 only some rows in a table, since that would increase the diversity
148 If it turns out that other changes don't let ovsdb-server scale
149 adequately, we can multithread ovsdb-server. Initially one might
150 only break protocol handling into separate threads, leaving the
151 actual database work serialized through a lock.
153 ** Increasing availability.
155 Database availability might become an issue. The OVN system
156 shouldn't grind to a halt if the database becomes unavailable, but
157 it would become impossible to bring VIFs up or down, etc.
159 My current thought on how to increase availability is to add
160 clustering to ovsdb-server, probably via the Raft consensus
161 algorithm. As an experiment, I wrote an implementation of Raft
162 for Open vSwitch that you can clone from:
164 https://github.com/blp/ovs-reviews.git raft
166 ** Reducing startup time.
168 As-is, if ovsdb-server restarts, every client will fetch a fresh
169 copy of the part of the database that it cares about. With
170 hundreds of clients, this could cause heavy CPU load on
171 ovsdb-server and use excessive network bandwidth. It would be
172 better to allow incremental updates even across connection loss.
173 One way might be to use "Difference Digests" as described in
174 Epstein et al., "What's the Difference? Efficient Set
175 Reconciliation Without Prior Context". (I'm not yet aware of
176 previous non-academic use of this technique.)
180 ** Init scripts for ovn-controller (on HVs), ovn-northd, OVN DB server.
182 ** Distribution packaging.
188 This is being developed on OpenStack's development infrastructure
189 to be along side most of the other Neutron plugins.
191 http://git.openstack.org/cgit/stackforge/networking-ovn
193 http://git.openstack.org/cgit/stackforge/networking-ovn/tree/doc/source/todo.rst