]> git.proxmox.com Git - ovs.git/blame - OPENFLOW-1.1+
ovs-ofctl: Document masked versions of arp_sha and arp_tha matches
[ovs.git] / OPENFLOW-1.1+
CommitLineData
bea97716
BP
1 OpenFlow 1.1+ support in Open vSwitch
2 =====================================
3
4Open vSwitch support for OpenFlow 1.1, 1.2, and 1.3 is a work in
5progress. This file describes the work still to be done.
6
7The Plan
8--------
9
10OpenFlow version support is not a build-time option. A single build
11of Open vSwitch must be able to handle all supported versions of
12OpenFlow. Ideally, even at runtime it should be able to support all
13protocol versions at the same time on different OpenFlow bridges (and
14perhaps even on the same bridge).
15
16At the same time, it would be a shame to litter the core of the OVS
17code with lots of ugly code concerned with the details of various
18OpenFlow protocol versions.
19
20The primary approach to compatibility is to abstract most of the
21details of the differences from the core code, by adding a protocol
22layer that translates between OF1.x and a slightly higher-level
23abstract representation. The core of this approach is the many struct
24ofputil_* structures in lib/ofp-util.h.
25
26As a consequence of this approach, OVS cannot use OpenFlow protocol
27definitions that closely resemble those in the OpenFlow specification,
28because openflow.h in different versions of the OpenFlow specification
29defines the same identifier with different values. Instead,
30openflow-common.h contains definitions that are common to all the
31specifications and separate protocol version-specific headers contain
32protocol-specific definitions renamed so as not to conflict,
33e.g. OFPAT10_ENQUEUE and OFPAT11_ENQUEUE for the OpenFlow 1.0 and 1.1
34values for OFPAT_ENQUEUE. Generally, in cases of conflict, the
35protocol layer will define a more abstract OFPUTIL_* or struct
36ofputil_*.
37
38Here are the current approaches in a few tricky areas:
39
40 * Port numbering. OpenFlow 1.0 has 16-bit port numbers and later
41 OpenFlow versions have 32-bit port numbers. For now, OVS
42 support for later protocol versions requires all port numbers to
43 fall into the 16-bit range, translating the reserved OFPP_* port
44 numbers.
45
46 * Actions. OpenFlow 1.0 and later versions have very different
47 ideas of actions. OVS reconciles by translating all the
48 versions' actions (and instructions) to and from a common
49 internal representation.
50
51OpenFlow 1.1
52------------
53
54The list of remaining work items for OpenFlow 1.1 is below. It is
55probably incomplete.
56
bea97716
BP
57 * The new in_phy_port field in OFPT_PACKET_IN needs some kind of
58 implementation. It has a sensible interpretation for tunnels
59 but in general the physical port is not in the datapath for OVS
60 so the value is not necessarily meaningful. We might have to
61 just fix it as the same as in_port.
4db3f50a 62 [required for OF1.1; optional for OF1.2+]
bea97716 63
4db3f50a 64 * OFPT_TABLE_MOD message. This is new in OF1.1, so we need to
bea97716
BP
65 implement it. It should be implemented so that the default OVS
66 behavior does not change.
4db3f50a
SH
67 [required for OF1.1 and OF1.2]
68
bea97716 69 * MPLS. Simon Horman maintains a patch series that adds this
ac3d64b1 70 feature. This is partially merged.
4db3f50a 71 [optional for OF1.1+]
bea97716 72
bea97716
BP
73 * Match and set double-tagged VLANs (QinQ). This requires kernel
74 work for reasonable performance.
4db3f50a 75 [optional for OF1.1+]
bea97716
BP
76
77 * VLANs tagged with 88a8 Ethertype. This requires kernel work for
78 reasonable performance.
4db3f50a 79 [required for OF1.1+]
bea97716 80
bea97716
BP
81OpenFlow 1.2
82------------
83
86189a8c
GS
84OpenFlow 1.2 support requires OpenFlow 1.1 as a prerequisite. All the
85additional work specific to Openflow 1.2 are complete. (This is based
86on the change log at the end of the OF1.2 spec. I didn't compare the
87specs carefully yet.)
bea97716 88
260aeca8
BP
89 * Action translation needs some work to transform OpenFlow 1.1
90 field modification actions into OpenFlow 1.2+ "set-field"
91 actions, because OpenFlow 1.2 dropped support for the OF1.1
92 actions.
93
bea97716
BP
94OpenFlow 1.3
95------------
96
97OpenFlow 1.3 support requires OpenFlow 1.2 as a prerequisite, plus the
98following additional work. (This is based on the change log at the
99end of the OF1.3 spec, reusing most of the section titles directly. I
b2c9b585 100didn't compare the specs carefully yet.)
bea97716
BP
101
102 * Add support for multipart requests.
ff3c2c63 103 Currently we always report OFPBRC_MULTIPART_BUFFER_OVERFLOW.
4db3f50a 104 [optional for OF1.3+]
bea97716
BP
105
106 * Add OFPMP_TABLE_FEATURES statistics.
4db3f50a 107 [optional for OF1.3+]
bea97716
BP
108
109 * More flexible table miss support.
48a5f330
YT
110 This requires the following.
111 - Change the default table-miss action (in the absense of table-miss
112 entry) from packet_in to drop for OF1.3+. Decide what to do if
113 a switch is configured to support multiple OF versions.
4db3f50a 114 [required for OF1.3+]
bea97716
BP
115
116 * IPv6 extension header handling support. Fully implementing this
117 requires kernel support. This likely will take some careful and
118 probably time-consuming design work. The actual coding, once
119 that is all done, is probably 2 or 3 days work.
4db3f50a 120 [optional for OF1.3+]
bea97716 121
e34afc3f
BP
122 * Per-flow meters. OpenFlow protocol support is now implemented.
123 Support for the special OFPM_SLOWPATH and OFPM_CONTROLLER meters
124 is missing. Support for the software switch is under review.
4db3f50a 125 [optional for OF1.3+]
bea97716 126
ac3d64b1 127 * Per-connection event filtering. OF1.3 adopted Open vSwitch's
bea97716
BP
128 existing design for this feature so implementation should be
129 easy.
4db3f50a 130 [required for OF1.3+]
bea97716 131
4db3f50a
SH
132 * Auxiliary connections. An implementation in generic code might
133 be a week's worth of work. The value of an implementation in
134 generic code is questionable, though, since much of the benefit
135 of axuiliary connections is supposed to be to take advantage of
136 hardware support. (We could make the kernel module somehow
137 send packets across the auxiliary connections directly, for
138 some kind of "hardware" support, if we judged it useful enough.)
139 [optional for OF1.3+]
bea97716
BP
140
141 * MPLS BoS matching. (Included in Simon's MPLS series?)
4db3f50a 142 [optional for OF1.3+]
bea97716 143
b2c9b585
BP
144 * Provider Backbone Bridge tagging. I don't plan to implement
145 this (but we'd accept an implementation).
4db3f50a 146 [optional for OF1.3+]
bea97716 147
b2c9b585 148 * Rework tag order. I'm not sure whether we need to do anything
4db3f50a
SH
149 for this. Part of MPLS patchset by Simon Horman.
150 [required for v1.3+]
bea97716 151
bea97716
BP
152 * On-demand flow counters. I think this might be a real
153 optimization in some cases for the software switch.
4db3f50a
SH
154 [optional for OF1.3+]
155
9fa96468
YT
156ONF OpenFlow Exensions for 1.3.X Pack1
157--------------------------------------
158
159OpenFlow 1.3 has a bunch of ONF extentions.
160Many of them are necessary for OpenFlow 1.4 as well.
161
162 * Flow entry notifications
163 This seems to be modelled after OVS's NXST_FLOW_MONITOR.
164 [EXT-187]
165 [required for OF1.4+]
166
167 * Role Status
168 [EXT-191]
169 [required for OF1.4+]
170
171 * Flow entry eviction
172 OVS has flow eviction functionality.
173 table_mod OFPTC_EVICTION, flow_mod 'importance', and
174 table_desc ofp_table_mod_prop_eviction need to be implemented.
175 [EXT-192-e]
176 [optional for OF1.4+]
177
178 * Vacancy events
179 [EXT-192-v]
180 [optional for OF1.4+]
181
182 * Bundle
183 Transactional modification. OpenFlow 1.4 requires to support
184 flow_mods and port_mods in a bundle.
185 (Not related to OVS's 'ofbundle' stuff.)
186 [EXT-230]
187 [required for OF1.4+]
188
189 * Table synchronisation
190 [EXT-232]
191 [optional for OF1.4+]
192
193 * Group notifications
194 [EXT-235]
195 [optional for OF1.4+]
196
197 * Bad flow entry priority error
198 Probably not so useful to the software switch.
199 [EXT-236]
200 [optional for OF1.4+]
201
202 * Set async config error
203 [EXT-237]
204 [optional for OF1.4+]
205
206 * PBB UCA header field
207 [EXT-256]
208 [optional for OF1.4+]
209
210 * Duplicate instruction error
211 We already have ONFBIC_DUP_INSTRUCTION.
212 [EXT-260]
213 [required for OF1.4+]
214
215 * Multipart timeout error
216 [EXT-264]
217 [required for OF1.4+]
218
219OpenFlow 1.4
220------------
221
222 * More extensible wire protocol
223 Many on-wire structures got TLVs.
224 [EXT-262]
225 [required for OF1.4+]
226
227 * More descriptive reasons for packet-in
228 Distinguish OFPR_APPLY_ACTION, OFPR_ACTION_SET, OFPR_GROUP,
229 OFPR_PACKET_OUT. NO_MATCH was renamed to OFPR_TABLE_MISS.
230 [EXT-136]
231 [required for OF1.4+]
232
233 * Optical port properties
234 [EXT-154]
235 [optional for OF1.4+]
236
237 * Flow-removed reason for meter delete
238 Report flow removal due to meter deletion with OFPRR_METER_DELETE.
239 [EXT-261]
240 [optional for OF1.4+]
241
242 * Meter notifications
243 [EXT-235]
244 [optional for OF1.4+]
bea97716 245
70d0aed3
BP
246General
247-----
248
249 * ovs-ofctl(8) often lists as Nicira extensions features that
250 later OpenFlow versions support in standard ways.
251
bea97716
BP
252How to contribute
253-----------------
254
255If you plan to contribute code for a feature, please let everyone know
256on ovs-dev before you start work. This will help avoid duplicating
257work.
258
259Please consider the following:
260
261 * Testing. Please test your code.
262
263 * Unit tests. Please consider writing some. The tests directory
264 has many examples that you can use as a starting point.
265
266 * ovs-ofctl. If you add a feature that is useful for some
267 ovs-ofctl command then you should add support for it there.
268
269 * Documentation. If you add a user-visible feature, then you
270 should document it in the appropriate manpage and mention it in
271 NEWS as well.
272
273 * Coding style (see the CodingStyle file at the top of the source
274 tree).
275
276 * The patch submission guidelines (see SubmittingPatches). I
b2c9b585 277 recommend using "git send-email", which automatically follows a
bea97716
BP
278 lot of those guidelines.
279
280Bug Reporting
281-------------
282
283Please report problems to bugs@openvswitch.org.