X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=DESIGN;h=211292569ff038dfea63738497417728384bef25;hb=330d7cf413bf30632fa5078ab6b562792c2a663b;hp=886994b0ae1e72c31f4b9abf3e820545c1a2a308;hpb=66abb12bf48104e0d2b9be8b9d14252a3afd2a4a;p=sliver-openvswitch.git diff --git a/DESIGN b/DESIGN index 886994b0a..211292569 100644 --- a/DESIGN +++ b/DESIGN @@ -9,6 +9,142 @@ successful deployment. The end of this document contains contact information that can be used to let us know how we can make Open vSwitch more generally useful. +Asynchronous Messages +===================== + +Over time, Open vSwitch has added many knobs that control whether a +given controller receives OpenFlow asynchronous messages. This +section describes how all of these features interact. + +First, a service controller never receives any asynchronous messages +unless it explicitly configures a miss_send_len greater than zero with +an OFPT_SET_CONFIG message. + +Second, OFPT_FLOW_REMOVED and NXT_FLOW_REMOVED messages are generated +only if the flow that was removed had the OFPFF_SEND_FLOW_REM flag +set. + +Third, OFPT_PACKET_IN and NXT_PACKET_IN messages are sent only to +OpenFlow controller connections that have the correct connection ID +(see "struct nx_controller_id" and "struct nx_action_controller"): + + - For packet-in messages generated by a NXAST_CONTROLLER action, + the controller ID specified in the action. + + - For other packet-in messages, controller ID zero. (This is the + default ID when an OpenFlow controller does not configure one.) + +Finally, Open vSwitch consults a per-connection table indexed by the +message type, reason code, and current role. The following table +shows how this table is initialized by default when an OpenFlow +connection is made. An entry labeled "yes" means that the message is +sent, an entry labeled "---" means that the message is suppressed. + + master/ + message and reason code other slave + ---------------------------------------- ------- ----- + OFPT_PACKET_IN / NXT_PACKET_IN + OFPR_NO_MATCH yes --- + OFPR_ACTION yes --- + OFPR_INVALID_TTL --- --- + + OFPT_FLOW_REMOVED / NXT_FLOW_REMOVED + OFPRR_IDLE_TIMEOUT yes --- + OFPRR_HARD_TIMEOUT yes --- + OFPRR_DELETE yes --- + + OFPT_PORT_STATUS + OFPPR_ADD yes yes + OFPPR_DELETE yes yes + OFPPR_MODIFY yes yes + +The NXT_SET_ASYNC_CONFIG message directly sets all of the values in +this table for the current connection. The +OFPC_INVALID_TTL_TO_CONTROLLER bit in the OFPT_SET_CONFIG message +controls the setting for OFPR_INVALID_TTL for the "master" role. + + +OFPAT_ENQUEUE +============= + +The OpenFlow 1.0 specification requires the output port of the OFPAT_ENQUEUE +action to "refer to a valid physical port (i.e. < OFPP_MAX) or OFPP_IN_PORT". +Although OFPP_LOCAL is not less than OFPP_MAX, it is an 'internal' port which +can have QoS applied to it in Linux. Since we allow the OFPAT_ENQUEUE to apply +to 'internal' ports whose port numbers are less than OFPP_MAX, we interpret +OFPP_LOCAL as a physical port and support OFPAT_ENQUEUE on it as well. + + +OFPT_FLOW_MOD +============= + +The OpenFlow 1.0 specification for the behavior of OFPT_FLOW_MOD is +confusing. The following table summarizes the Open vSwitch +implementation of its behavior in the following categories: + + - "match on priority": Whether the flow_mod acts only on flows + whose priority matches that included in the flow_mod message. + + - "match on out_port": Whether the flow_mod acts only on flows + that output to the out_port included in the flow_mod message (if + out_port is not OFPP_NONE). + + - "updates flow_cookie": Whether the flow_mod changes the + flow_cookie of the flow or flows that it matches to the + flow_cookie included in the flow_mod message. + + - "updates OFPFF_ flags": Whether the flow_mod changes the + OFPFF_SEND_FLOW_REM flag of the flow or flows that it matches to + the setting included in the flags of the flow_mod message. + + - "honors OFPFF_CHECK_OVERLAP": Whether the OFPFF_CHECK_OVERLAP + flag in the flow_mod is significant. + + - "updates idle_timeout" and "updates hard_timeout": Whether the + idle_timeout and hard_timeout in the flow_mod, respectively, + have an effect on the flow or flows matched by the flow_mod. + + - "updates idle timer": Whether the flow_mod resets the per-flow + timer that measures how long a flow has been idle. + + - "updates hard timer": Whether the flow_mod resets the per-flow + timer that measures how long it has been since a flow was + modified. + + - "zeros counters": Whether the flow_mod resets per-flow packet + and byte counters to zero. + + - "sends flow_removed message": Whether the flow_mod generates a + flow_removed message for the flow or flows that it affects. + +An entry labeled "yes" means that the flow mod type does have the +indicated behavior, "---" means that it does not, an empty cell means +that the property is not applicable, and other values are explained +below the table. + + MODIFY DELETE + ADD MODIFY STRICT DELETE STRICT + === ====== ====== ====== ====== +match on priority --- --- yes --- yes +match on out_port --- --- --- yes yes +updates flow_cookie yes yes yes +updates OFPFF_SEND_FLOW_REM yes + + +honors OFPFF_CHECK_OVERLAP yes + + +updates idle_timeout yes + + +updates hard_timeout yes + + +resets idle timer yes + + +resets hard timer yes yes yes +zeros counters yes + + +sends flow_removed message --- --- --- % % + +(+) "modify" and "modify-strict" only take these actions when they + create a new flow, not when they update an existing flow. + +(%) "delete" and "delete_strict" generates a flow_removed message if + the deleted flow or flows have the OFPFF_SEND_FLOW_REM flag set. + (Each controller can separately control whether it wants to + receive the generated messages.) + Multiple Table Support ======================