X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=OPENFLOW-1.1%2B;h=1789f179abafe88a16a15dd026be248b8ab521fe;hb=28c5588e8e1a8d091c5d2275232c35f2968a97fa;hp=4bdd37ee1e7dfa0a788f49c248a06e3324807e95;hpb=fff22ddf266c3796451cdf3a04093d7889ae6edf;p=sliver-openvswitch.git diff --git a/OPENFLOW-1.1+ b/OPENFLOW-1.1+ index 4bdd37ee1..1789f179a 100644 --- a/OPENFLOW-1.1+ +++ b/OPENFLOW-1.1+ @@ -1,7 +1,7 @@ OpenFlow 1.1+ support in Open vSwitch ===================================== -Open vSwitch support for OpenFlow 1.1, 1.2, and 1.3 is a work in +Open vSwitch support for OpenFlow 1.1 and beyond is a work in progress. This file describes the work still to be done. The Plan @@ -54,64 +54,25 @@ OpenFlow 1.1 The list of remaining work items for OpenFlow 1.1 is below. It is probably incomplete. - * Implement Write-Actions instruction. - - * The new in_phy_port field in OFPT_PACKET_IN needs some kind of - implementation. It has a sensible interpretation for tunnels - but in general the physical port is not in the datapath for OVS - so the value is not necessarily meaningful. We might have to - just fix it as the same as in_port. - - * On OF1.1+ flow_mods, updates by MODIFY are now much better - specified. Check that OVS implements the new behavior, fix it - if not. - - * OFPT_TABLE_MOD stats. This is new in OF1.1, so we need to - implement it. It should be implemented so that the default OVS - behavior does not change. - - * Document how OVS does packet buffering. - * MPLS. Simon Horman maintains a patch series that adds this feature. This is partially merged. - - * SCTP. Joe Stringer maintains a patch series that adds this - feature. It has received review comments that need to be - addressed before it is merged. + [optional for OF1.1+] * Match and set double-tagged VLANs (QinQ). This requires kernel work for reasonable performance. + [optional for OF1.1+] * VLANs tagged with 88a8 Ethertype. This requires kernel work for reasonable performance. - - * Groups. + [required for OF1.1+] OpenFlow 1.2 ------------ -OpenFlow 1.2 support requires OpenFlow 1.1 as a prerequisite, plus the -following additional work. (This is based on the change log at the -end of the OF1.2 spec. I didn't compare the specs carefully yet.) - - * Use new OpenFlow extensible error infrastructure, on OF1.2+ - only, instead of the OVS-specific extension used until now. - - * OFPT_FLOW_MOD: - - * MODIFY and MODIFY_STRICT commands now never insert new flows - in the table. We will still need variations that do, - though, both to support older OpenFlow protocols and to get - sensible behavior for the internal implementation of the - NXAST_LEARN action. - - * New flag OFPFF_RESET_COUNTS. - - * New cookie field behavior. - - * Add ability to delete flow in all tables. - - * Update DESIGN to describe OF1.2 behavior also. +OpenFlow 1.2 support requires OpenFlow 1.1 as a prerequisite. All the +additional work specific to Openflow 1.2 are complete. (This is based +on the change log at the end of the OF1.2 spec. I didn't compare the +specs carefully yet.) OpenFlow 1.3 ------------ @@ -122,48 +83,135 @@ end of the OF1.3 spec, reusing most of the section titles directly. I didn't compare the specs carefully yet.) * Add support for multipart requests. + Currently we always report OFPBRC_MULTIPART_BUFFER_OVERFLOW. + [optional for OF1.3+] - * Add OFPMP_TABLE_FEATURES statistics. - - * More flexible table miss support. + * Add OFPMP_TABLE_FEATURES statistics. Alexander Wu has posted a + patch series. [optional for OF1.3+] * IPv6 extension header handling support. Fully implementing this requires kernel support. This likely will take some careful and probably time-consuming design work. The actual coding, once that is all done, is probably 2 or 3 days work. + [optional for OF1.3+] + + * Per-flow meters. OpenFlow protocol support is now implemented. + Support for the special OFPM_SLOWPATH and OFPM_CONTROLLER meters + is missing. Support for the software switch is under review. + [optional for OF1.3+] + + * Auxiliary connections. An implementation in generic code might + be a week's worth of work. The value of an implementation in + generic code is questionable, though, since much of the benefit + of axuiliary connections is supposed to be to take advantage of + hardware support. (We could make the kernel module somehow + send packets across the auxiliary connections directly, for + some kind of "hardware" support, if we judged it useful enough.) + [optional for OF1.3+] - * Per-flow meters. Similar to IPv6 extension headers in kernel - and design requirements. Might be politically difficult to add - directly to the kernel module, since its functionality overlaps - with tc. Ideally, therefore, we could implement these somehow - with tc, but I haven't investigated whether that makes sense. + * Provider Backbone Bridge tagging. I don't plan to implement + this (but we'd accept an implementation). + [optional for OF1.3+] - * Per-connection event filtering. OF1.3 adopted Open vSwitch's - existing design for this feature so implementation should be - easy. + * On-demand flow counters. I think this might be a real + optimization in some cases for the software switch. + [optional for OF1.3+] + +ONF OpenFlow Exensions for 1.3.X Pack1 +-------------------------------------- + +OpenFlow 1.3 has a bunch of ONF extentions. +Many of them are necessary for OpenFlow 1.4 as well. + + * Flow entry notifications + This seems to be modelled after OVS's NXST_FLOW_MONITOR. + [EXT-187] + [required for OF1.4+] + + * Role Status + [EXT-191] + [required for OF1.4+] + + * Flow entry eviction + OVS has flow eviction functionality. + table_mod OFPTC_EVICTION, flow_mod 'importance', and + table_desc ofp_table_mod_prop_eviction need to be implemented. + [EXT-192-e] + [optional for OF1.4+] + + * Vacancy events + [EXT-192-v] + [optional for OF1.4+] + + * Bundle + Transactional modification. OpenFlow 1.4 requires to support + flow_mods and port_mods in a bundle. + (Not related to OVS's 'ofbundle' stuff.) + [EXT-230] + [required for OF1.4+] + + * Table synchronisation + [EXT-232] + [optional for OF1.4+] + + * Group notifications + [EXT-235] + [optional for OF1.4+] + + * Bad flow entry priority error + Probably not so useful to the software switch. + [EXT-236] + [optional for OF1.4+] + + * Set async config error + [EXT-237] + [optional for OF1.4+] + + * PBB UCA header field + [EXT-256] + [optional for OF1.4+] + + * Duplicate instruction error + We already have ONFBIC_DUP_INSTRUCTION. + [EXT-260] + [required for OF1.4+] + + * Multipart timeout error + [EXT-264] + [required for OF1.4+] + +OpenFlow 1.4 +------------ - * Auxiliary connections. These are optional, so a minimal - implementation would not need them. An implementation in - generic code might be a week's worth of work. The value of an - implementation in generic code is questionable, though, since - much of the benefit of axuiliary connections is supposed to be - to take advantage of hardware support. (We could make the - kernel module somehow send packets across the auxiliary - connections directly, for some kind of "hardware" support, if we - judged it useful enough.) + * More extensible wire protocol + Many on-wire structures got TLVs. + [EXT-262] + [required for OF1.4+] - * MPLS BoS matching. (Included in Simon's MPLS series?) + * More descriptive reasons for packet-in + Distinguish OFPR_APPLY_ACTION, OFPR_ACTION_SET, OFPR_GROUP, + OFPR_PACKET_OUT. NO_MATCH was renamed to OFPR_TABLE_MISS. + [EXT-136] + [required for OF1.4+] - * Provider Backbone Bridge tagging. I don't plan to implement - this (but we'd accept an implementation). + * Optical port properties + [EXT-154] + [optional for OF1.4+] - * Rework tag order. I'm not sure whether we need to do anything - for this. + * Flow-removed reason for meter delete + Report flow removal due to meter deletion with OFPRR_METER_DELETE. + [EXT-261] + [optional for OF1.4+] - * Duration for stats. + * Meter notifications + [EXT-235] + [optional for OF1.4+] - * On-demand flow counters. I think this might be a real - optimization in some cases for the software switch. +General +----- + + * ovs-ofctl(8) often lists as Nicira extensions features that + later OpenFlow versions support in standard ways. How to contribute ----------------- @@ -189,7 +237,7 @@ Please consider the following: * Coding style (see the CodingStyle file at the top of the source tree). - * The patch submission guidelines (see SubmittingPatches). I + * The patch submission guidelines (see CONTRIBUTING). I recommend using "git send-email", which automatically follows a lot of those guidelines.