]>
Commit | Line | Data |
---|---|---|
bea97716 BP |
1 | OpenFlow 1.1+ support in Open vSwitch |
2 | ===================================== | |
3 | ||
4 | Open vSwitch support for OpenFlow 1.1, 1.2, and 1.3 is a work in | |
5 | progress. This file describes the work still to be done. | |
6 | ||
7 | The Plan | |
8 | -------- | |
9 | ||
10 | OpenFlow version support is not a build-time option. A single build | |
11 | of Open vSwitch must be able to handle all supported versions of | |
12 | OpenFlow. Ideally, even at runtime it should be able to support all | |
13 | protocol versions at the same time on different OpenFlow bridges (and | |
14 | perhaps even on the same bridge). | |
15 | ||
16 | At the same time, it would be a shame to litter the core of the OVS | |
17 | code with lots of ugly code concerned with the details of various | |
18 | OpenFlow protocol versions. | |
19 | ||
20 | The primary approach to compatibility is to abstract most of the | |
21 | details of the differences from the core code, by adding a protocol | |
22 | layer that translates between OF1.x and a slightly higher-level | |
23 | abstract representation. The core of this approach is the many struct | |
24 | ofputil_* structures in lib/ofp-util.h. | |
25 | ||
26 | As a consequence of this approach, OVS cannot use OpenFlow protocol | |
27 | definitions that closely resemble those in the OpenFlow specification, | |
28 | because openflow.h in different versions of the OpenFlow specification | |
29 | defines the same identifier with different values. Instead, | |
30 | openflow-common.h contains definitions that are common to all the | |
31 | specifications and separate protocol version-specific headers contain | |
32 | protocol-specific definitions renamed so as not to conflict, | |
33 | e.g. OFPAT10_ENQUEUE and OFPAT11_ENQUEUE for the OpenFlow 1.0 and 1.1 | |
34 | values for OFPAT_ENQUEUE. Generally, in cases of conflict, the | |
35 | protocol layer will define a more abstract OFPUTIL_* or struct | |
36 | ofputil_*. | |
37 | ||
38 | Here 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 | ||
51 | OpenFlow 1.1 | |
52 | ------------ | |
53 | ||
54 | The list of remaining work items for OpenFlow 1.1 is below. It is | |
55 | probably incomplete. | |
56 | ||
57 | * Implement Write-Actions instruction. | |
58 | ||
59 | * The new in_phy_port field in OFPT_PACKET_IN needs some kind of | |
60 | implementation. It has a sensible interpretation for tunnels | |
61 | but in general the physical port is not in the datapath for OVS | |
62 | so the value is not necessarily meaningful. We might have to | |
63 | just fix it as the same as in_port. | |
64 | ||
65 | * On OF1.1+ flow_mods, updates by MODIFY are now much better | |
66 | specified. Check that OVS implements the new behavior, fix it | |
67 | if not. | |
68 | ||
69 | * On OF1.1+ flow_mods, DELETE now ignores buffer_id. | |
70 | ||
71 | * OFPST_PORT and OFPST_QUEUE stats. These differ little from | |
72 | OF1.0 to OF1.1 (just the size of the port number field) but do | |
73 | require abstraction (Done?). | |
74 | ||
75 | * OFPT_TABLE_MOD stats. This is new in OF1.1, so we need to | |
76 | implement it. It should be implemented so that the default OVS | |
77 | behavior does not change. | |
78 | ||
79 | * Document how OVS does packet buffering. | |
80 | ||
81 | * MPLS. Simon Horman maintains a patch series that adds this | |
82 | feature. It needs review and possible revision before it is | |
83 | merged. | |
84 | ||
85 | * SCTP. Joe Stringer maintains a patch series that adds this | |
86 | feature. It has received review comments that need to be | |
87 | addressed before it is merged. | |
88 | ||
89 | * Match and set double-tagged VLANs (QinQ). This requires kernel | |
90 | work for reasonable performance. | |
91 | ||
92 | * VLANs tagged with 88a8 Ethertype. This requires kernel work for | |
93 | reasonable performance. | |
94 | ||
95 | * Groups. | |
96 | ||
97 | OpenFlow 1.2 | |
98 | ------------ | |
99 | ||
100 | OpenFlow 1.2 support requires OpenFlow 1.1 as a prerequisite, plus the | |
101 | following additional work. (This is based on the change log at the | |
102 | end of the OF1.2 spec. I didn’t compare the specs carefully yet.) | |
103 | ||
104 | * Use new OpenFlow extensible error infrastructure, on OF1.2+ | |
105 | only, instead of the OVS-specific extension used until now. | |
106 | ||
107 | * OFPT_FLOW_MOD: | |
108 | ||
109 | * MODIFY and MODIFY_STRICT commands now never insert new flows | |
110 | in the table. We will still need variations that do, | |
111 | though, both to support older OpenFlow protocols and to get | |
112 | sensible behavior for the internal implementation of the | |
113 | NXAST_LEARN action. | |
114 | ||
115 | * New flag OFPFF_RESET_COUNTS. | |
116 | ||
117 | * New cookie field behavior. | |
118 | ||
119 | * Add ability to delete flow in all tables. | |
120 | ||
121 | * Update DESIGN to describe OF1.2 behavior also. | |
122 | ||
123 | * Implement OFPT_ROLE_REQUEST. Patch submitted by Jarno | |
124 | Rajahalme, currently under revision. | |
125 | ||
126 | * Add ability to turn off packet buffering with OFPCML_NO_BUFFER. | |
127 | ||
128 | OpenFlow 1.3 | |
129 | ------------ | |
130 | ||
131 | OpenFlow 1.3 support requires OpenFlow 1.2 as a prerequisite, plus the | |
132 | following additional work. (This is based on the change log at the | |
133 | end of the OF1.3 spec, reusing most of the section titles directly. I | |
134 | didn’t compare the specs carefully yet.) | |
135 | ||
136 | * Add support for multipart requests. | |
137 | ||
138 | * Add OFPMP_TABLE_FEATURES statistics. | |
139 | ||
140 | * More flexible table miss support. | |
141 | ||
142 | * IPv6 extension header handling support. Fully implementing this | |
143 | requires kernel support. This likely will take some careful and | |
144 | probably time-consuming design work. The actual coding, once | |
145 | that is all done, is probably 2 or 3 days work. | |
146 | ||
147 | * Per-flow meters. Similar to IPv6 extension headers in kernel | |
148 | and design requirements. Might be politically difficult to add | |
149 | directly to the kernel module, since its functionality overlaps | |
150 | with tc. Ideally, therefore, we could implement these somehow | |
151 | with tc, but I haven’t investigated whether that makes sense. | |
152 | ||
153 | * Per-connection event filtering. OF1.3 adopted Open vSwitch’s | |
154 | existing design for this feature so implementation should be | |
155 | easy. | |
156 | ||
157 | * Auxiliary connections. These are optional, so a minimal | |
158 | implementation would not need them. An implementation in | |
159 | generic code might be a week’s worth of work. The value of an | |
160 | implementation in generic code is questionable, though, since | |
161 | much of the benefit of axuiliary connections is supposed to be | |
162 | to take advantage of hardware support. (We could make the | |
163 | kernel module somehow send packets across the auxiliary | |
164 | connections directly, for some kind of “hardware” support, if we | |
165 | judged it useful enough.) | |
166 | ||
167 | * MPLS BoS matching. (Included in Simon's MPLS series?) | |
168 | ||
169 | * Provider Backbone Bridge tagging. I don’t plan to implement | |
170 | this (but we’d accept an implementation). | |
171 | ||
172 | * Rework tag order. I’m not sure whether we need to do anything | |
173 | for this. | |
174 | ||
175 | * Duration for stats. | |
176 | ||
177 | * On-demand flow counters. I think this might be a real | |
178 | optimization in some cases for the software switch. | |
179 | ||
180 | How to contribute | |
181 | ----------------- | |
182 | ||
183 | If you plan to contribute code for a feature, please let everyone know | |
184 | on ovs-dev before you start work. This will help avoid duplicating | |
185 | work. | |
186 | ||
187 | Please consider the following: | |
188 | ||
189 | * Testing. Please test your code. | |
190 | ||
191 | * Unit tests. Please consider writing some. The tests directory | |
192 | has many examples that you can use as a starting point. | |
193 | ||
194 | * ovs-ofctl. If you add a feature that is useful for some | |
195 | ovs-ofctl command then you should add support for it there. | |
196 | ||
197 | * Documentation. If you add a user-visible feature, then you | |
198 | should document it in the appropriate manpage and mention it in | |
199 | NEWS as well. | |
200 | ||
201 | * Coding style (see the CodingStyle file at the top of the source | |
202 | tree). | |
203 | ||
204 | * The patch submission guidelines (see SubmittingPatches). I | |
205 | recommend using “git send-email”, which automatically follows a | |
206 | lot of those guidelines. | |
207 | ||
208 | Bug Reporting | |
209 | ------------- | |
210 | ||
211 | Please report problems to bugs@openvswitch.org. |